Attacks on electronic health records (EHRs), ransomware blocking access to treatment in the UK’s National Health System, and vulnerabilities in medical devices have all been in the news recently. Settlements and penalties for HIPAA violations are becoming more common as well.
For software and device manufacturers attempting to comply with HIPAA and FDA guidelines, the answers aren’t always easy. Building secure applications and devices requires a new way of thinking about requirements. It also requires a new approach to identifying weaknesses in software and devices that could result in security issues.
We will cover this in detail in our upcoming webinar, Healthcare and Open Source – Balancing Innovation Against Risk. In the meantime, here’s a preview.
What Does HIPAA Require?
HIPAA, like all regulatory standards, requires organizations to have a vulnerability management plan. The reason for this is obvious. If you aren’t aware of a risk/vulnerability, you can’t defend against it. HIPAA spells this out by requiring organizations to conduct a “risk analysis” and implement “risk management” controls. The former is intended to provide “an accurate and thorough assessment of the potential risks and vulnerabilities to the confidentiality, integrity, and availability of electronic protected health information held by the covered entity.” The latter introduces controls to reduce risks to appropriate levels.
Remember, this HIPAA compliance requirement goes beyond when the software was developed. It includes any software covered by HIPAA, at any time. Keeping up with new vulnerabilities is a challenge to organizations.
Does Vulnerability Scanning Help?
Vulnerability Assessment tools are used to identify unpatched software and specific vulnerabilities in commercial applications. This certainly could have helped in the WannaCry and NotPetya ransomware attacks. A good scanner could easily recognize the old versions of Windows targeted by the EternalBlue exploit used in the attacks. Once identified, installing the patch issued by Microsoft in March would have “immunized” systems against the exploit.
These should be the easy items to defend against, however. Most of these applications will have support agreements from the vendors. These agreements obligate the vendors to “push” software updates and patches to their customers. From there, it’s “simply” a matter of installing the updates.
I say “simply” because large organizations run a lot of software, and all of it requires occasional patches. Keeping up with this can be a challenge, not to mention the technical risks (Will it work correctly? Will it break other processes?). The NHS hospitals and others compromised by these ransomware attacks neglected to recognize the risk associated with not patching, and paid a price for it.
Companies that rely solely on vulnerability scanners for update information have a blind spot. They have no knowledge about the software you build and use internally, much less vulnerabilities in the hundreds of open source components used in those applications. Black Duck’s Open Source Security Risk Analysis report found that the average commercial application used almost 150 individual open source components, and a recent Forrester Research report called attention to open source’s preeminence in application development, with new custom code comprising only 10% to 20% of applications.
With open source components, nobody is “pushing” updates to you. Instead, open source has a “pull” model of support. You need to know precisely what open source components you are using, and track all of them for security updates or vulnerabilities. With hundreds of components in a single application, and over 3,600 vulnerabilities reported in open source every year, this represents an enormous blind spot.
There's More to Come
Healthcare applications and devices now have the attention of both hackers and security researchers, so expect more and more reports on vulnerabilities. Also, expect regulatory bodies to continue to crack down on violations.
Want to learn more? Join us for our webinar on July 20.