HIPAA vs Security: Building security into medical purchasing decisions

What the security community says about a specific industry vertical usually holds true for a good percentage of what is seen in the wild. You can ask any hacker, defender, CISO, etc what industries struggle the most and there are common themes in their answers. Top of the list includes healthcare, manufacturing, government, and financial. Some of the most heavily compliance controlled and regulated are also some of the least secure. Why is this? Is it due to administrators and senior management taking compliance standards as gospel? Maybe it’s a lack of knowledgeable staff like the blind leading the blind.

Rapid technology growth in the healthcare space definitely has not helped. Decision makers are slowly working security practices into business initiatives, but that doesn’t account for all of the security debt that has built up in this technology boom. So now what? How can business work to quickly protect their customer’s data, their own data, their products, while still doing what they do best? Do not fall into the habit of performing tasks, going through routines, or completing configuration with the mindset of “This is how we’ve always done it.” That type of mindset will only hinder progress and decrease security posture in the long run.

Humans are allergic to change. They love to say, “We’ve always done it this way.” I try to fight that. That’s why I have a clock on my wall that runs counter-clockwise.” — Grace Hopper, “The Wit and Wisdom of Grace Hopper” (1987)

How and why should security be tied to HIPAA?

The requirement to comply with one standard or the next does provide a few benefits to your organization. Certain standards leave significant room for interpretation, giving you the ability to tie security measures that should be implemented to a portion of that same standard. When compliance is involved there are now social, political, and legal components added that can be leveraged to implement security controls and process changes that may not have been possible otherwise. It also may present the opportunity to piggyback off another department that has excess budget for a project.
The Health Insurance Portability & Accountability Act (HIPAA) was enacted in 1996 as law and establishes national standards for electronic healthcare records. It includes any organization that stores or processes ePHI (Electronic Protected Health Information) healthcare providers, health plans, and clearinghouses. There are fifty “implementation specifications,” divided into administrative, physical, and technical safeguards. Most specifications listed involve having policies and procedures in place. Addressable specifications involve performing a “risk assessment” and then taking steps to mitigate the risks in a way that’s appropriate for your organization. One of the largest HIPAA penalties against a small organization was levied not because an event occurred, but because the organization failed to address the possibility. Loss of ePHI can cause significant harm to not only the patients whose data has been compromised, but also the provider and individuals at fault as they are required to report violations to the US Department of Health and Human Services (HHS), the Federal Trade Commission (FTC), and are susceptible to extremely large fines and jail time. The HHS provides a breakdown of each portion of the security rule portion of HIPAA and assistance with the implementation of the security standards.

Is HIPAA enough?

HIPAA has been put in place as law as a standard of compliance. It has *not* been put into law as an exact roadmap to secure infrastructure. It is a guarantee that with a secure infrastructure, compliance will follow. For example, the HHS points out

Four implementation specifications are associated with the Access Controls standard.
1. Unique User Identification (Required)
2. Emergency Access Procedure (Required)
3. Automatic Logoff (Addressable)
4. Encryption and Decryption (Addressable)

While both 3 and 4 are both addressable, they are not a requirement, rather you're permitted to have a compensating control, or documentation on why you can not meet them. Doing that as opposed to implementing them, would be akin to "accepting risk" on something you shouldn't be accepting risk on. Not only are there some items that aren’t specific requirements, but the documentation also leaves a lot of room for interpretation. Security practitioners will often look down on HIPAA as a standard. However every environment is different, so there is no standard or guidelines out there that are going to be the “end all, be all” answer. HIPAA can definitely be incorporated into a security architecture plan that includes in-depth knowledge and strategy, so can most other compliance standards. By using it as a guideline to implement a proper design both compliance and security can be achieved.

Building security into medical purchasing decisions

Malicious attackers are using multiple vectors including exploiting vulnerabilities in medical devices and printers. Networked medical devices represent a significant security challenge for hospitals, because their IT teams cannot upgrade the underlying operating system and third party applications embedded into these devices. Many medical devices using older versions of Windows and Linux have known security vulnerabilities and are at risk of malware contamination. The vendors supplying these devices sometimes will not allow them to be updated, or have their own remote process and procedure to do any type of update at all. When a third party vendor comes in to show off their new product, here are a few questions that should be asked prior to any purchasing decisions being made as well as a general secure answer.

Support:

Is remote access required for support? If remote access is needed for support, it should be only enabled when needed, and segmented from accessing any other devices in the environment. Remote access clients should not be installed on any endpoints as that scenario gives unmonitored and possibly unlogged access into the network. All remote access should be over a secured network, logged, using multi-factor authentication, and segmented to least access needed.

Updates:

Who is in charge of endpoint software updates? No matter if software updates are provided by the vendor to be applied by an internal team, or applied by the vendor themselves, they should be tested in the environment prior to deployment.

Who is in charge of endpoint OS updates? It is recommended that updates are distributed in the same manner as the rest of the enterprise. If using WSUS, separate deployment groups can be created if needed.

Application/Device:

Does it require any third party applications? (Java, Adobe Acrobat, any type of SQL server, etc) Hopefully not. Having third party applications such as Java, Adobe Reader, etc significantly reduces the overall security of the endpoint. If there is no way of getting around this, third party software updates should be managed automatically and timely. Configurations on any type of database, web, or other service server should be hardened and patched to sufficient standards as well.

Is there support for upgrading third party applications to the latest patched version? If the vendor doesn’t support upgrades, move on to another vendor. As time moves on, more and more vulnerabilities will be discovered and the application’s security will continue to decline.

Do any firewall ports (host or network) need opened? If they have specifics that’s great! A good vendor should have the specific incoming and outgoing ports documented as well as what external IP address they will need access to. This complies with least access. Port forwarding should never be an approved option, and any direct communication involving sensitive data should traverse over a secure connection.

What data access is required? Many medical devices need interface access to other portions of the infrastructure. Whether it be data in an EMR, scheduling data, x-rays, etc knowing what type of data access is needed and in what matter it will be obtained is valuable information for asset management and documentation.

Is data stored on disk or in memory on the device, and if so, what type? You can’t protect data if you don’t know where it resides or how it moves throughout the organization. Knowing where the sensitive data is and how it is structured will go a long way in ensuring the correctly formatted rules are in place.
Data at Rest: Data in databases, on file servers, or in custom applications not only should be identified as previously stated, but also encrypted and in a secure physical location.
Data in Motion: Common avenues of data access to pay attention to (and their ports) are FTP (21), SFTP(22), SMTP(25), HTTP/APIs(443/80/8080), SMB(445). Any network monitoring solution should be able to alert on sensitive data in transit.
Data in Use: Data that can be exfiltrated using things like CDs, USB drives, or with copy/paste to external websites from the user endpoints.

What security testing is applied? Software should go through regular penetration tests and code audits. Usually companies that have bug bounties are more security conscious as well.

Are the endpoints added to the domain? In a windows environment (which the majority if not all of medical organizations are) adding all endpoints to the domain or a subdomain is preferred to leaving them to be managed manually. The security options are far greater when a client is domain joined as opposed to just sitting on the network doing its own thing. However, prior to even connecting a vendor device to the network, it should be offline scanned for malware and viruses.

Is there any application/device specific logging? If so, this could be helpful to collect into a SIEM or managed detection service for alerting or aggregating for later use in the event of any IR performed.