The Health Insurance Portability and Accountability Act (HIPAA) regulates covered entities and their business associates operating in the US healthcare and healthcare insurance market. Title II allows regulated entities to process, store and exchange healthcare information, in exchange for handling Protected Health Information (PHI) – such as names, email addresses, social security numbers – according to rules.
In this series, we focus on complying with the Privacy and Security Rule with cloud native technologies and Kubernetes.
Privacy Rule
The Privacy Rule essentially states that individuals have full control over their PHI. Among others, HIPAA-regulated entities must – in most cases –obtain authorization from the individual before transmitting PHI.
A consequence of the Privacy Rule is that regulated entities are liable for breaches leading to unauthorized disclosure of PHI. The burden of proof lies upon the regulated entity to show that no breaches have occurred. Alternatively, the liability can be reduced by proving that the breach affected a limited number of individuals. In fact, the magnitude of the harm, i.e., the amount of PHI that leaked, determines the fines applied.
Privacy Rule with Kubernetes
For complying with the Privacy Rule on top of Kubernetes, regulated entities need to deploy intrusion detection systems. Furthermore, the Kubernetes cluster needs to collect application logs and Kubernetes API logs in a tamper-proof logging environment.
Intrusion detection systems, such as Falco, tap into low-level Linux kernel facilities, such as eBPF-based syscall tracing. They use such traces to detect suspicious activities, such as exec-ing into a production Pod or writing to /etc. Some of these activities are benign, merely indicating that the engineering team is investigating a bug in production. Others may be signs of an attempted attack or an ongoing attack aimed at stealing PHI. When in doubt, “scraming” the application, i.e., taking it offline, may cull a potential leak of PHI, and reduce liability.
The application should log all significant boundary events in a tamper-proof logging environment. Boundary events include logins, logouts, API requests and database queries. Tamper-proof means that, even if an attacker gained full control over the production environment, they cannot change logging records. Having a separate service Kubernetes cluster which hosts Elasticsearch can be an effective implementation. Fluentd can forward application logs from the production Kubernetes cluster to Elasticsearch.
As with application logs, the Kubernetes cluster should forward its API logs to the same tamper-proof logging environment. Logs should identify the engineer or system that made the API call. This can be achieved by connecting the Kubernetes cluster to the regulated entity’s identity provider (IdP) via Dex. Dex supports both OpenID and SAML integration.
Compliant Kubernetes
To help HIPAA-regulated entities, Elastisys has carefully integrated all of the above in our open-source Compliant Kubernetes (CK8s) distribution. We provide 24/7 support or should you want to keep in-house resources dedicated to your core business, we also offer CK8s as a managed service with enterprise grade SLAs and Business Associate Agreements (BAA).
Contact us to find out more!
Of course, breaches are better prevented than dealt with. Our next post discusses the Security Rule and how HIPAA-regulated entities can comply with it on top of Kubernetes.
