Enjoying our content? Subscribe:
HIPAA Compliance for Microservices Environments
All about HIPAA compliance for microservices environments in 2022
The Health Insurance Portability and Accountability Act (HIPAA) of the US was enacted on August 21, 1996, to help more Americans gain health insurance coverage and make it easier for them to get health insurance from a new employer where they switch jobs. HIPAA strives to make healthcare delivery more efficient by providing for hassle-free transfer (portability) of healthcare data between healthcare organizations and insurers. The legislation aims to combat health care frauds and abuse such as filing false claims and obtaining undeserved benefits from federal and state healthcare programs. Most importantly, HIPAA aims to secure patients' protected health information (PHI) and the illegal use of such information by scamsters to file fraudulent claims with the federal/state health coverage programs and health insurers. With this in mind, HIPAA lays down national standards ("HIPAA Privacy Rule"), the first of its kind, to secure individuals' PHI.
The HIPAA Privacy Rule requires "covered entities," namely, health plans, health care providers, and their business associates to have in place appropriate safeguards, including technical ones, to ensure the confidentiality, integrity, and security of a patient's PHI. In the unfortunate event of disclosure, impermissible use, or exposure (such as in a cyberattack) of PHI, the covered entities must notify the patient to that effect within 60 calendar days from the date of discovery of the breach. Where the breach involves unsecured PHI of more than 500 individuals, a covered entity must notify a prominent media outlet serving the jurisdiction in which the breach has occurred, apart from notifying the Department of Health and Human Services (HHS).
The HIPAA Privacy Rule requires "covered entities," namely, health plans, health care providers, and their business associates to have in place appropriate safeguards, including technical ones, to ensure the confidentiality, integrity, and security of a patient's PHI. In the unfortunate event of disclosure, impermissible use, or exposure (such as in a cyberattack) of PHI, the covered entities must notify the patient to that effect within 60 calendar days from the date of discovery of the breach. Where the breach involves unsecured PHI of more than 500 individuals, a covered entity must notify a prominent media outlet serving the jurisdiction in which the breach has occurred, apart from notifying the Department of Health and Human Services (HHS).
Covered Entities Under HIPAA Rules
* This applies where the healthcare provider transmits any information in electronic form in connection with a transaction for which the Department of Health and Human Services (HHS) has established certain standards.
** This applies where the business associate is privy to PHI shared by the covered entity to carry out one or other healthcare function.
** This applies where the business associate is privy to PHI shared by the covered entity to carry out one or other healthcare function.
In case of violation of the HIPAA provisions by covered entities or business associates, be it deliberate or unintentional, the HHS' Office for Civil Rights (OCR) can issue financial penalties ranging from $100 per violation (or per record) to a maximum fine per violation per category per year amounting to $1.5 million! These penalties depend on the degree of wrongdoing (lack of knowledge, reasonable cause, willful neglect) on the part of the covered entity or business associate as well as the extent of harm caused by the violation.
Worse still, HIPAA violations might also attract criminal charges and jail times of up to 10 years for willful negligence and PHI thefts for personal gain or with malicious intent. Furthermore, depending on the nature of the violation, an employee of a covered entity could be suspended from work, pending the outcome of an investigation, which could end with a warning or termination. Their liabilities may not end there. For serious HIPAA violations, such as data theft, healthcare staff might face criminal prosecution by the Department of Justice. A single healthcare record is estimated to be worth up to $250 (2019) in the cybercrime black markets on the darknet, so the lure of monetary gain can be very tempting.
Worse still, HIPAA violations might also attract criminal charges and jail times of up to 10 years for willful negligence and PHI thefts for personal gain or with malicious intent. Furthermore, depending on the nature of the violation, an employee of a covered entity could be suspended from work, pending the outcome of an investigation, which could end with a warning or termination. Their liabilities may not end there. For serious HIPAA violations, such as data theft, healthcare staff might face criminal prosecution by the Department of Justice. A single healthcare record is estimated to be worth up to $250 (2019) in the cybercrime black markets on the darknet, so the lure of monetary gain can be very tempting.
18 HIPAA identifiers that make health information "PHI"
1. Names
2. Dates, except year
3. Telephone numbers
4. Geographic data
5. FAX numbers
6. Social security numbers
7. Email addresses
8. Medical record numbers
9. Account numbers
10. Health plan beneficiary numbers
11. Certificate/license numbers
12. Vehicle identifiers and serial numbers, including license plates
13. Web URLs
14. Device identifiers and serial numbers
15. Internet protocol addresses
16. Full face photos and comparable images
17. Biometric identifiers (i.e., retinal scan, fingerprints)
18. Any unique identifying number or code
know it, and apps come with some clear advantages. Apps are making it possible for healthcare organizations to provide patients with 24/7 support, home care, and telemedicine visits, especially during weekends and past normal business hours. Mobile health technology supports the collection of the patient's health data and electronic transmission of the same to the healthcare provider to identify potential risk and ensure timely medical treatment. That brings the question: Are mobile health apps required to be HIPAA-compliant? A big yes, where the personal data collected by the app is shared with a medical professional, or a HIPAA-covered entity, or if the app is providing a service on behalf of a covered entity. This is a very daunting scenario, no doubt, for app makers since they are going to be liable for civil and criminal penalties for unauthorized PHI disclosures if any!
Since app developers increasingly turn to open-source platforms (e.g., Kubernetes) to help automate many of the manual processes involved in deploying, managing, and scaling large-scale apps, including healthcare apps, it's important to configure such app orchestration platforms for HIPAA compliance in the first place. Kubernetes boasts some inherent security advantages and is by far the most popular system for container orchestration at scale, but it isn't HIPAA-compliant by default. Here're some additional technical safeguards to further "bulletproof" Kubernetes security and bring it strictly in alignment with HIPAA's compliance mandates. This will secure PHI properly at all times and make sure it is accessible only by persons who need it to perform their assigned job responsibilities at covered entities.
2. Dates, except year
3. Telephone numbers
4. Geographic data
5. FAX numbers
6. Social security numbers
7. Email addresses
8. Medical record numbers
9. Account numbers
10. Health plan beneficiary numbers
11. Certificate/license numbers
12. Vehicle identifiers and serial numbers, including license plates
13. Web URLs
14. Device identifiers and serial numbers
15. Internet protocol addresses
16. Full face photos and comparable images
17. Biometric identifiers (i.e., retinal scan, fingerprints)
18. Any unique identifying number or code
know it, and apps come with some clear advantages. Apps are making it possible for healthcare organizations to provide patients with 24/7 support, home care, and telemedicine visits, especially during weekends and past normal business hours. Mobile health technology supports the collection of the patient's health data and electronic transmission of the same to the healthcare provider to identify potential risk and ensure timely medical treatment. That brings the question: Are mobile health apps required to be HIPAA-compliant? A big yes, where the personal data collected by the app is shared with a medical professional, or a HIPAA-covered entity, or if the app is providing a service on behalf of a covered entity. This is a very daunting scenario, no doubt, for app makers since they are going to be liable for civil and criminal penalties for unauthorized PHI disclosures if any!
Since app developers increasingly turn to open-source platforms (e.g., Kubernetes) to help automate many of the manual processes involved in deploying, managing, and scaling large-scale apps, including healthcare apps, it's important to configure such app orchestration platforms for HIPAA compliance in the first place. Kubernetes boasts some inherent security advantages and is by far the most popular system for container orchestration at scale, but it isn't HIPAA-compliant by default. Here're some additional technical safeguards to further "bulletproof" Kubernetes security and bring it strictly in alignment with HIPAA's compliance mandates. This will secure PHI properly at all times and make sure it is accessible only by persons who need it to perform their assigned job responsibilities at covered entities.
Access Controls
Kubernetes' Role-Based Access Control (RBAC) involves great attention to detail and works on the tried and tested security practice of giving the lowest possible access level to a container for each user (e.g., healthcare employee, in this case) or service (e.g., a mobile app). This principle of least privilege also means allowing connectivity only between containers that really need it. No more, no less. More finegrained pod security policies can be defined at the cluster-level with respect to running of privileged containers and usage of host namespaces and volume types. This determines how each pod running sensitive applications should be run. As a matter of abundant caution, containers shouldn't be allowed to run as "root." To the extent possible, root privileges should be extended to developers only on a need-basis.
The authorization modules, previously mentioned, are based on roles, attributes, special-purpose authorizations for node agents, and use of custom codes for authorization. To a great extent, they provide access control to PHI data and prevent sensitive data breaches and theft. By so doing, these security mechanisms enable organizations to meet many of the local, state, and federal regulations. Even so, they still fall short at meeting the need to implement security policies involving greater attention to detail. For instance, working with these security features, it's tough to enforce access control based on time of day or location of a user. This is where Open Policy Agent (OPA), an open-source general-purpose policy engine comes handy in helping covered entities meet fine-grained compliance requirements for applications and stay within HIPAA's strict mandates.
All things considered, Kubernetes' information security environment might be able to deal with traffic filtering and listen to the messages from the API server. RBAC/ABAC also can help limit access for certain roles. In real life, some more rights and privileges need to be in place in microservices environments to control and regulate access to sensitive data by users, apps, and projects. Several of the APIs use sensitive data, so identifying applications that call up these APIs using routine unique identifiers is just not enough, given the risks involved. It is critically important to establish that users are indeed who they say they are before their usernames are passed to an app, along with access tokens, to indicate they have been authenticated to obtain or retrieve data. In practice, the actual authentication is performed by an identity provider (IdP), an entity with a separate existence that exchanges user information with the service provider (SP). SAML open protocol and OpenID connect, with the OAuth 2.0 framework, will ensure only users authenticated by an IdP have access to a certain application. The users' right of access is defined by tokens. In short, SAML and OpenID, in conjunction with RBAC/ABAC, provide a dependable method to establish users' identity and, where applicable, restrict them from accessing data that is not relevant to them. Such automated admission validation processes serve as protective railing to prevent unwanted changes to workloads.
Essentially, OPA policies are expressed in Rego, a declarative computer language with simple syntax, in which the instructions (codes) responsible for making policy decisions are decoupled from policy enforcement as such. In the OPA scheme of things, the policy decision-generating piece devotes itself exclusively to that purpose and exists separately without being hard-coded into the source code of the program. When an instruction, data, or program needs to enforce a policy decision, it queries OPA, which accepts arbitrary structured data (e.g., Can this user access be allowed access to certain data, or allowed to carry out a particular operation or run a specific containerized application?) as input. OPA then evaluates the input against various policies and generates a decision, which is an answer to the query. The policy decision is then returned to the software for enforcement. The Kubernetes API server admission controller allows addition of new functionalities. The OPA policy engine takes advantage of this extensible design to achieve more granular policy enforcement over and above what RBAC is capable of. This covers a huge number of user scenarios involving access to PHI.
The authorization modules, previously mentioned, are based on roles, attributes, special-purpose authorizations for node agents, and use of custom codes for authorization. To a great extent, they provide access control to PHI data and prevent sensitive data breaches and theft. By so doing, these security mechanisms enable organizations to meet many of the local, state, and federal regulations. Even so, they still fall short at meeting the need to implement security policies involving greater attention to detail. For instance, working with these security features, it's tough to enforce access control based on time of day or location of a user. This is where Open Policy Agent (OPA), an open-source general-purpose policy engine comes handy in helping covered entities meet fine-grained compliance requirements for applications and stay within HIPAA's strict mandates.
All things considered, Kubernetes' information security environment might be able to deal with traffic filtering and listen to the messages from the API server. RBAC/ABAC also can help limit access for certain roles. In real life, some more rights and privileges need to be in place in microservices environments to control and regulate access to sensitive data by users, apps, and projects. Several of the APIs use sensitive data, so identifying applications that call up these APIs using routine unique identifiers is just not enough, given the risks involved. It is critically important to establish that users are indeed who they say they are before their usernames are passed to an app, along with access tokens, to indicate they have been authenticated to obtain or retrieve data. In practice, the actual authentication is performed by an identity provider (IdP), an entity with a separate existence that exchanges user information with the service provider (SP). SAML open protocol and OpenID connect, with the OAuth 2.0 framework, will ensure only users authenticated by an IdP have access to a certain application. The users' right of access is defined by tokens. In short, SAML and OpenID, in conjunction with RBAC/ABAC, provide a dependable method to establish users' identity and, where applicable, restrict them from accessing data that is not relevant to them. Such automated admission validation processes serve as protective railing to prevent unwanted changes to workloads.
Essentially, OPA policies are expressed in Rego, a declarative computer language with simple syntax, in which the instructions (codes) responsible for making policy decisions are decoupled from policy enforcement as such. In the OPA scheme of things, the policy decision-generating piece devotes itself exclusively to that purpose and exists separately without being hard-coded into the source code of the program. When an instruction, data, or program needs to enforce a policy decision, it queries OPA, which accepts arbitrary structured data (e.g., Can this user access be allowed access to certain data, or allowed to carry out a particular operation or run a specific containerized application?) as input. OPA then evaluates the input against various policies and generates a decision, which is an answer to the query. The policy decision is then returned to the software for enforcement. The Kubernetes API server admission controller allows addition of new functionalities. The OPA policy engine takes advantage of this extensible design to achieve more granular policy enforcement over and above what RBAC is capable of. This covers a huge number of user scenarios involving access to PHI.
Data Encryption
Kubernetes, with the right set of modules, will allow you to encrypt data and containers through at-rest encryption, which applies to data on a hard drive. However, HIPAA requires patient data to be "rendered unusable, unreadable, or indecipherable to unauthorized persons," (i.e., encrypted) both at rest and when in transit. By default, Kubernetes stores sensitive information ("secrets"), like usernames and passwords, as well as encryption keys in the form of readable data in an open-source distributed key-value store, namely, "etcd." This way the secrets are managed independently of the pods, but made available to them as needed.
Most of the time, PHI data is stored in a cloud storage service outside the Kubernetes infrastructure. It's important to ensure data en route to the cloud is protected from unauthorized and malicious access, loss, or exposure on the server. This means the cloud service provider must provide end-to-end encryption for all data that passes between the sender and receiver. In addition, the cloud backup service must be capable of retaining several versions of the same data files simultaneously, and, ideally, this should happen automatically on a continuous basis. So, in the unfortunate event of an accident or some malicious action, the data can be restored to any previous file version or its original state.
The Kubernetes platform protects data in transit between various platform components (e.g., nodes, etcd, API server) using the "https" encryption protocol. All communications with the control plane, responsible for managing nodes that run containerized applications and pods, are sent via the transport layer security (TLS) protocol, which helps establish the authenticity of a device, server, or user as well as data integrity and privacy. It is recommended that credentials, such as cluster root certificate authority (CA), private keys, and platform certificates, be rotated to enhance security for transit data. Kubernetes includes a wide variety of long-term storage plug-ins, such as remote cloud-based storage services and on-premise hardware attached to nodes, and these persist data even after the pods accessing them have shut down.
Here, it is important to bear in mind that stored PHI (data at rest) needs to be protected by encryption at all times, and this is an important mandate under HIPAA. Open-source "service meshes" enable secure sharing of data between microservices. In its data plane (user plane or data forwarding plane), the mesh provides a proxy instance ("sidecar"), which abstracts features, like inter-services network communication and security, away from the main microservice architecture. The sidecar works alongside the individual service to route requests to and from other proxies. Together, this bunch of proxies controls how microservices share data with one another. The control plane of the service mesh coordinates the behavior of these proxies and enforces policies that decide how data is forwarded by the data plane.
In order to exercise tighter control over secrets, these can be stored in vaults and various systems for managing identity-based secrets and encryptions. Secret management tools, like Hashicorp vault, will ensure secrets (e.g., usernames, passwords, database credentials, API tokens, TLS certificates) are encrypted while at rest inside the vault. Thereafter, secrets are accessible only to human users/servers whose identity and permission to use a Kubernetes resource has been established using RBAC or the secret value users are logged in with. Vaults also make sure sensitive data is encrypted during transit between the vault and any client.
Besides, vaults maintain a detailed log of all API requests and responses to the vault, and this ensures access to the secrets is not just tightly controlled but also auditable. These encryption management systems are also flexible enough to generate secrets that work for a limited period of time. They also revoke access to a secret for exiting employees and rotate access to a new employee. In respect of every secret, the system creates a lease, a metadata containing information on how long a data should exist on a computer or a computer network before being discarded. This allows for automatic expiry of database records, thus curbing their indefinite circulation. As soon as the lease ends, the vault automatically revokes a secret, invalidating the associated access keys.
Hashicorp vault centralizes the storage and management of secrets, and, by so doing, eliminates the risk of critical data being exposed in plain text, including in source-code repositories like GitHub/GitLab! By integrating the service mesh, discussed earlier, with a Vault Certificate Authority (CA), certificates can be issued for authorized applications running in the mesh.
Furthermore, to make sure the Kubernetes environment stays on the right side of the HIPAA legislation, it is important to ensure communication between pods is encrypted when transmission of sensitive data is involved. For the same reason, incoming traffic to a pod from outside a Kubernetes cluster and outgoing traffic from the pod should also be encrypted where confidential information is transmitted.
Most of the time, PHI data is stored in a cloud storage service outside the Kubernetes infrastructure. It's important to ensure data en route to the cloud is protected from unauthorized and malicious access, loss, or exposure on the server. This means the cloud service provider must provide end-to-end encryption for all data that passes between the sender and receiver. In addition, the cloud backup service must be capable of retaining several versions of the same data files simultaneously, and, ideally, this should happen automatically on a continuous basis. So, in the unfortunate event of an accident or some malicious action, the data can be restored to any previous file version or its original state.
The Kubernetes platform protects data in transit between various platform components (e.g., nodes, etcd, API server) using the "https" encryption protocol. All communications with the control plane, responsible for managing nodes that run containerized applications and pods, are sent via the transport layer security (TLS) protocol, which helps establish the authenticity of a device, server, or user as well as data integrity and privacy. It is recommended that credentials, such as cluster root certificate authority (CA), private keys, and platform certificates, be rotated to enhance security for transit data. Kubernetes includes a wide variety of long-term storage plug-ins, such as remote cloud-based storage services and on-premise hardware attached to nodes, and these persist data even after the pods accessing them have shut down.
Here, it is important to bear in mind that stored PHI (data at rest) needs to be protected by encryption at all times, and this is an important mandate under HIPAA. Open-source "service meshes" enable secure sharing of data between microservices. In its data plane (user plane or data forwarding plane), the mesh provides a proxy instance ("sidecar"), which abstracts features, like inter-services network communication and security, away from the main microservice architecture. The sidecar works alongside the individual service to route requests to and from other proxies. Together, this bunch of proxies controls how microservices share data with one another. The control plane of the service mesh coordinates the behavior of these proxies and enforces policies that decide how data is forwarded by the data plane.
In order to exercise tighter control over secrets, these can be stored in vaults and various systems for managing identity-based secrets and encryptions. Secret management tools, like Hashicorp vault, will ensure secrets (e.g., usernames, passwords, database credentials, API tokens, TLS certificates) are encrypted while at rest inside the vault. Thereafter, secrets are accessible only to human users/servers whose identity and permission to use a Kubernetes resource has been established using RBAC or the secret value users are logged in with. Vaults also make sure sensitive data is encrypted during transit between the vault and any client.
Besides, vaults maintain a detailed log of all API requests and responses to the vault, and this ensures access to the secrets is not just tightly controlled but also auditable. These encryption management systems are also flexible enough to generate secrets that work for a limited period of time. They also revoke access to a secret for exiting employees and rotate access to a new employee. In respect of every secret, the system creates a lease, a metadata containing information on how long a data should exist on a computer or a computer network before being discarded. This allows for automatic expiry of database records, thus curbing their indefinite circulation. As soon as the lease ends, the vault automatically revokes a secret, invalidating the associated access keys.
Hashicorp vault centralizes the storage and management of secrets, and, by so doing, eliminates the risk of critical data being exposed in plain text, including in source-code repositories like GitHub/GitLab! By integrating the service mesh, discussed earlier, with a Vault Certificate Authority (CA), certificates can be issued for authorized applications running in the mesh.
Furthermore, to make sure the Kubernetes environment stays on the right side of the HIPAA legislation, it is important to ensure communication between pods is encrypted when transmission of sensitive data is involved. For the same reason, incoming traffic to a pod from outside a Kubernetes cluster and outgoing traffic from the pod should also be encrypted where confidential information is transmitted.
Deep Packet Detection
Unauthorized and unintentional transmission of unencrypted PHI data is a risk that is often beyond the scope of the encryption approaches previously discussed. It would take a layer-7 (application layer) deep packet inspection to detect where in the Kubernetes environment and exactly in which components or connections sensitive data is present. Plain packet filtering limits itself to examining the header of a block of data entering or leaving a network asset (e.g., a router, computer terminal, or an app) to identify data or requests with malicious intent. By contrast, deep packet inspection considers the data part of a block of data, in addition to the header, to deny access to unsolicited messages. It also guards against unauthorized intrusions, viruses, or any data that is in violation of any defined protocol or criterion. Deep packet inspection brings unencrypted connections to light and block them where PHI transmission is involved. Furthermore, it is possible to enforce network segmentation within the Kubernetes environment to prevent unauthorized connections from executing commands in containers.
Network Segmentation
In network segmentation, containerized apps, for instance, are grouped into small zones, in the interest of security, such that they talk across zones on a need-basis only. Specific security protocols apply to each zone. A security policy could be enforced such that the front-end zone (user interface) is disallowed from talking directly to the database subsystem. Likewise, the database could be air-gapped from external networks. Calico, open-source network security solution, for example, takes Kubernetes' network policy beyond pods and applies the same across multiple endpoints, including VMs. It also hosts interfaces as well as ingress/egress and provides a richer set of network policies.
Regular, Automated Data Backups
Kubernetes backup support provides mechanisms for writing sensitive data at rest to etcd and restoring such data to their original condition in case of any eventuality. However, this data protection mechanism for containers doesn't necessarily include any additional layer of security beyond what is specified by the cluster. After all, Kubernetes, in itself, is not a backup solution. Kubernetes-specific open-source tools, like KubeDR tool and Velero, are ideal for backing up cluster configuration data, metadata, certificates, clusters, namespaces and labels. For long-term storage of data in line with strict HIPAA mandates, a data protection solution with a backup server that is enabled for encryption of data at rest is highly recommended.
Have an awesome day. Will be back soon!
Have an awesome day. Will be back soon!
Cyberlands.io Team