Vulnerability Assessments and Penetration Testing Can Bolster Healthcare Defenses

In today’s healthcare environment, the boundaries of the data center no longer exist — data moves in and out and across the organization. Two helpful tools for a health IT group are vulnerability assessments and penetration tests.

Every system is vulnerable to some sort of attack. Because health IT systems undergo continuous change, their vulnerability is greater than systems in a more static environment. Each change brings the possibility of errors that open the organization to attack.

To manage vulnerabilities, provider organizations should follow several steps.

SIGN UP: Get more news from the HealthTech newsletter in your inbox every two weeks!

Identify All of a Healthcare Organization's Assets

This inventory is usually created and maintained by an automated system that populates a database with the collection of IP addresses it has discovered. Be sure to include all network-connected devices, not just servers, storage and PCs.

Personal devices and medical devices are often overlooked. The latter, in particular, can be a real challenge to inventory, so you’ll need to work with your clinical engineering team to identify network-connected devices via a noninvasive scanning method.

Once you’ve identified assets, you should review where they’re located, how they’re used and what data they contain so you can prioritize your efforts.

Clearly, some data types are more critical to protect. Personally identifiable information, protected health information and credit card data all must be protected by law.

Security professionals then must determine the weaknesses of each asset.

Vulnerabilities generally can be broken down into four areas:

1. Human error
2. System changes
3. Configuration errors
4. Software (application, operating system, firmware, patches)

Rank your risks so you can focus on your biggest vulnerabilities first. Start with common ones — unpatched operating systems, weak passwords or configuration errors. These are often the most pressing concerns precisely because they are widely known. Some vulnerabilities are specific to a particular technology; for example, storage solutions. You should investigate these issues with your vendors.

Track and Prioritize Risks and Remediation

Automated systems will look for unpatched systems and configuration errors, and generate a report for remediation. In today’s risk environment, it’s almost a requirement to automate this process; manual efforts are too time-consuming and error-prone.

Use a system to track your risks and then work on your highest risks first. Track remediation efforts as well as results. There will always be open risk items; the key is to have a consistent plan. Document remediation actions and note any countermeasures adopted to prevent recurrence of an issue.

Risk remediation is an ongoing operational duty, not an optional add-on. When your teams look at change management, vulnerability management and risk mitigation as tasks they own, you’ll have a more secure environment.

The key to managing vulnerabilities is to be aware of what devices are in your environment and know their weaknesses. Scanning, patching and risk management processes will help you reduce your vulnerabilities consistently and methodically.

Launch an Attack on Healthcare Security Systems

Penetration tests essentially determine how exposed your systems are to the exploitation of existing vulnerabilities using various attack vectors. Whether you have internal or external resources tested, it’s worth trying to attack your organization periodically so you can discover your weaknesses before the bad guys do.

One of the challenges with penetration testing — and one of the weaknesses of relying solely on such methods as a measure of security — is that the test essentially pits an attack against a particular system or attack vector.

Weak passwords, open ports on the firewall, URL redirects and SQL injections are security basics that can and should be tested. More sophisticated attacks depend on which systems you have in place, so hiring a third-party tester with associated credentials and experience is valuable.

Set Boundaries for Penetration Tests

You must develop a clear scope document with defined goals and boundaries for penetration testing. This will serve as your tester’s legal document.

It should give them explicit permission to attack in a specified manner, during a defined period of time and within the bounds you have agreed to. Without this document, both your organization and the tester carry legal risk. The document should be signed by an executive in your firm (or by your legal representative) and should be kept on file.

Next, you should identify potentially sensitive systems that may be off-limits. For example, some medical devices may be negatively affected by an intrusive attack. The agreement might state that if the tester is able to access such a device, they should cease and report immediately. This way, patients and medical devices remain safe, and the issue can be addressed quickly.

Focus on Easy Security Targets First

Use in-house penetration testers if you have the skill set and cost is a concern. You might begin with scattered tests across your environment.

Focus on the easy targets first, such as systems exposed to the internet or weak passwords. The potential downside to an internal resource is that they may inadvertently use insider knowledge to attack or may lack high-end skills — thus reducing the potential effectiveness of the test — so evaluate the risks and benefits carefully.

If you’re using an external firm, get references from other health IT departments or other IT colleagues you trust. The skills and costs can run the gamut, so starting off with a trusted provider will make things much simpler.

Finally, be sure to inventory all findings from the penetration test and add them to your risk tracking system. Remediate them according to your risk management process. Auditors always want to know what you knew and when you knew it — so it becomes indefensible to indicate you knew about a critical risk but took no action to resolve it.

It’s even harder to claim that you were completely unaware of a critical risk.