Compliance with the Health Insurance Portability and Accountability Act (HIPAA) is a must for organizations that handle protected health information (PHI). This article addresses how to ensure that your application(s) and the surrounding infrastructure is (and stays) compliant with examples of what can go wrong.
Compliance with the Health Insurance Portability and Accountability Act (HIPAA) is a must for organizations that handle protected health information (PHI). Much of the focus is placed on policies, access controls, and encryption, with goals described on a high level for affected systems.
But how do you ensure that your application(s) and the surrounding infrastructure is compliant?
Since we are talking about some of the most sensitive data any organization may be entrusted with, it is important to have a second look and ensure safeguards are in place at every layer. While most organizations do place special care on security, there are hidden areas which are often overlooked. And these are where the breaches happen. We are going to talk about misconfigurations, and some ways you may not have thought you could be hacked.
Let us take a look at a sample set of prominent breaches in the health sector over the last couple of years.
These examples were picked to show a variety of different flavors of misconfigurations and how they played a role in a breach. It is to be noted that misconfigurations are often at the root of breaches, even when the official root cause label was “Ransomware attack” (see e.g. this article).
Now, how could these breaches have been prevented? All of them had some monitoring in place, but no alarms were raised. In some cases, it took years to detect an anomaly. A cloud security posture management (CSPM) solution would have not been enough, since many of the misconfigurations are based on application level configurations. More is needed here.
Going through reports, it is also clear that the technology stack in health companies varies. Hence, In order to tackle the problem across different organizations, one needs to be able to support all these tools and their configuration files.
Let’s go a bit further and have a look at which parts of HIPAA requirements can usually be found in configuration files. To most people’s surprise, a lot of violations of the HIPAA paragraphs can be detected by simply looking into the different configuration files of a network. Let’s consider some of the definitions as per § 164.304 in this section and their connection to configuration files.
Most configuration files also extend to so-called access control lists (ACLs) or refer to an OICD system which has roles specified. From that system, Role-based access control (RBAC) can be established, which is considered the most robust method of access control.
Authentication is not just something your users have to do. Most of the time, user authentication is not the problem. The services communicating to one another are the problem. By default, many systems allow unauthenticated access or some default username/password combination.
These configurations are often deployed without a change to production systems (or sysadmins not even being aware of them), and the protection which is relied on is that these systems are within the same, private network. That of course opens them up for attack if another, less important and less well managed system on the network is compromised. Or if the network is accidentally opened to the public. Every service has the ability to create a proper inter-service authentication mechanism, and it should be enabled. And that is enabled inside configuration files.
Example:
Take MongoDB as an example. By default, no authentication is required (documentation), and many instances used in production today are maintaining this dangerous default.
Availability strategies, such as failover, load balancing or shared-state broker mechanisms are set within configurations. For each software you use in your environment, you can detect availability considerations either in the orchestration scripts (e.g. Kubernetes) or in the application configuration themselves.
Example:
One has multiple scaling mechanisms available in Kubernetes, such as the `HorizontalPodAutoScaler`. Additionally, one can see if multiple copies of the same service are being used behind a load-balancer such as NGINX.
Similar to the section about access, this can be achieved via a role-based access control mechanism. Depending on the application, labeling of data can be enforced. In this way, even after e.g. the termination of an employee, there is no risk of them getting unauthorized access after the off-boarding is complete. Role based access is defined in access control lists.
Example:
In Postgres, using the `pg_hba.conf`, authentication and access can be defined in a fine-grained way. Available filters are by network origin, username and specific database.
Encryption in transit is disabled in most server software today by default, and needs to be actively enabled. Encryption at rest is normally handled via a hard-disk encryption and this is facilitated via cloud provisioning layer or the overall container configuration. Keep also in mind that unencrypted communication within a private network is not a good solution in case someone gains access to one node on the particular network.
What measures are there in distributed systems that prevent data from accidentally being destroyed or not being recorded in the first place? While we are used to systems “just working”, this piece is often overlooked. Especially in distributed systems. Some NoSQL databases are placing things in temporary storage before batch-writing it to the hard-disk, leaving the potential for data loss.
Example:
By default, AWS MSK actually chooses uptime over data integrity (see this article). It can be changed in the respective configuration for the resource.
Example 2:
Databases like MySQL have additional audit logging capabilities (documentation) in the configurations where any insert, deletion or change of data is captured.
Malicious software needs to make it into the system first. A first line of protection is to ensure that any endpoint that accepts file inputs ensures that only files of a desired format are accepted. If files are of executable nature, any uncontrolled execution can be prevented by configuring the respective folder.
Example:
Microsoft IIS can be configured to only accept certain MIME types and reject others.
Example 2:
Every Linux benchmark requires to e.g. disable any execution of files from the `/tmp` folder.
The HIPAA paragraphs are formulated in a very open-ended way, and yet each mistake can result in a costly law-suit. Hardening your configurations is considered part of your best efforts to protect the sensitive data you are storing. Frameworks like Fedramp are now including hardening of configurations as part of their requirements (see revision 5 of Fedramp). You should stay ahead of the game.
If you find any of the following tools in your infrastructure, you are likely having a blind-spot with regards to misconfigurations:
Building a secure and compliant infrastructure is a journey that benefits from expert insights. If you're looking for guidance or want to explore how to strengthen your configurations, we are here to help. Reach out to learn more at info@coguard.io or explore a test environment here: portal.coguard.io.
