Back
Top Five Threats to HIPAA Security and Meaningful Use Compliance
Last month a new omnibus HIPAA security and privacy rule was released that increased the number of items to be audited as well as the potential penalties if compliance is not adhered to.
You can read the new rules here – http://www.hhs.gov/news/press/2013pres/01/20130117b.html
What is interesting to note is while the requirements or things to audit for have been updated for the health care providers, one area that doesn’t appear to be catching up as quickly is the technical requirements for vendors and their solutions to meet or exceed these new standards.
I’m specifically referencing the various solutions that are used day in and day out in healthcare facilities. Be it electronic medical records (EMR) solutions, prescription management solutions, medical imaging solutions, or even the various IV and infusion pumps in use at medical facilities; many of these solutions are now integrated with each other and log or maintain lots of data that is classified as PHI, PII, or simply “sensitive information”.
So where do the threats lie in these solutions? Well from DirectDefense’s experience, we can tell you that it does not come from a lack of policy or procedural documentation. At this point in time, it is pretty rare that most healthcare organizations do not have policy and procedural documentation in place. Granted there will be gaps or omissions, but all in all the issues are not policy or procedural related. The threats stem from a lack of technical understanding of the various solutions in use and how they communicate and integrate with each other. In other words, the threats require an understanding of the solutions and security options they utilize, such as Databases, communication protocols, authentication mechanisms, and memory management.
So after performing numerous penetration tests and application security assessments against many of these types of solutions, here is our list of the top five threats to complying with the new rules for HIPAA and Meaningful Use.
#1 – Default Configurations and Passwords – Many healthcare organizations outsource the installation and management of specific medical solutions to the vendor (or the vendor’s chosen partner) for deployment and maintenance. The issue is that the majority of these installers and administrators are deploying these various solutions “by the book”, literally. Want to break into an EMR solution?
Step one, go download the latest installation and maintenance manual from the vendor’s support site and search for passwords or usernames. Step two, break in.
It is that easy!
Shouldn’t vulnerability scanners identify these vulnerabilities? Yes! The problem stems from the lack of security research and/or security disclosure being performed within the healthcare industry. Because of this, vulnerability scanners are missing signatures that could be used to identify these types of low-hanging fruit vulnerabilities.
In our experience this attack works about 85% of the time when conducting penetration testing against medical solutions.
#2 – Patching – Ah, that common dirty word of information security!
While most healthcare providers are struggling to take care of patching from a basic IT function (just like every other vertical/industry out there), a common gap in the patch management process is the patching of the actual medical device or solution itself.
As previously stated, not a lot of security research or security disclosure has occurred within this industry when compared to other industries, however some has, and there is more starting to occur. With these disclosures, patches and updates for specific medical solutions are being released and will be required to be installed.
Case in point, Phillips disclosed vulnerabilities within the XPER ICS service as well as a potential default password used on the XPER solution.
These types of disclosures are going to happen more frequently and will need to be addressed.
#3 – Input Validation and Logic Vulnerabilities in Applications – While the majority of medical software and applications are still heavily based on the older client / server model for access and delivery, there is quite a bit of development going into providing mobile and web access to these applications. Regardless of client access methods, they all appear to have some common classes of vulnerabilities.
These vulnerabilities include the more traditional application injection vulnerabilities such as SQL, XPATH, and Command injection, cross site scripting vulnerabilities, and our favorite, Insecure Direct Object References due to the insecure handling of uploads to the application.
The more sophisticated application vulnerabilities include logic vulnerabilities such as Abuse of Function and Denial of Service.
It has been our experience that 9 out of 10 medical applications we assess fall victim to at least one of these types of vulnerabilities if not multiple vulnerable conditions.
#4 – Insecure Protocols In Use for Data in Transit – Just want to hang out and sniff some network traffic to see what can be seen? Unfortunately the majority of medical solutions out there make this attack vector really easy, due to the reliance of insecure protocols.
In most solutions, the various types of clients or application servers communicate to a backend database over an ODBC connection. This is good old fashion SQLNet, which in the majority of cases we’ve seen has been deployed with the default settings enabled. This means that the communication is not encrypted.
Be it MS SQL, MySQL, Oracle, or DB2 (among others), all of these solutions support SSL encryption on their SQL communications; however it is not turned on by default.
In the case of web applications, many deployment manuals still do not recommend or even step the installer through the process of enabling HTTPS for the delivery of access to the application and the sensitive data it transmits.
This is also true for mobile applications, which just like every other industry out there, seem to think the majority of usage will happen over cellular networks versus wireless networks, so common application security controls, such as requiring HTTPS access, are usually missing from the deployment.
#5 – Insecure Storage or Handling of Data At Rest – While we have to admit some of this is changing, namely in the last year we’ve finally started seeing some vendors talk about what they do to protect data at rest, for the larger majority of medical solutions, there simply is nothing being done to securely store the data once it lands in the database.
Granted in some cases the data is not very “human readable”, yes you can pick out the Medical Record code and maybe the patient name, but that’s about it. But in the majority of the cases, such as EMR solutions, the data is easily readable and rarely protected properly.
It has been our experience, that the majority of medical solutions simply do nothing to secure or obfuscate sensitive data from within the applications themselves.
This is made even worse when vendors push back and refuse to support enabling database features such as table encryption, one-way hashing, or simple file or disk encryption as a potential mitigating control due to additional regression testing they’d have to conduct to support these security features. It’s the age old, “if it’s not broken then don’t fix it,” thought process. The solution is working fine how it is, and since vendors are not being forced to implement security, the service gets left unencrypted.
Where do we go from Here?
So now that you know what to look for. How can you start looking into your own environment and addressing these issues? Here are our recommendations:
Establish an application or solution security baseline program – As in other industries, the medical industry needs to update existing testing and base lining procedures to include testing and auditing of the technologies that enable their various applications and solutions.
This is a common gap we see across our clients within the healthcare industry. We see the majority of attention being paid to the network side of security, with most organizations just starting to look at the application side of security.
This is something that needs to be addressed and prioritized across the board.
Update your deployment procedures – At the very least, make sure your organization’s deployment procedures include the removal of all default accounts and sample data from your production solutions. This includes any usernames and passwords that can be found online or in the solution’s deployment manuals.
Update your remote management procedures – In the case of remote support, set your own unique passwords with your support vendor for remote administrative services such as PCAnywhere, VNC, or RDP.
We have found way too many passwords that allowed us to get in via remote management services simply by doing a Google search for typical passwords used by support vendor X.
Update your contracts and service level agreements – Candidly, vendors typically need a wakeup call to start changing their culture when it comes to security. So take a page from the financial industry and start demanding that your vendors meet or exceed your own security standards as part of their contractual obligations.
This will help you in the long run as you identify issues with your various solutions and establish mitigating controls that your vendors are now required to assist with and support. Basically this will eliminate a lot of the pushback that vendors given when you request that they support your mitigating controls for security deficiencies in their products.
Demand better or more secure solutions from your vendors – With the latest changes in the omnibus rules, the proof of compliance and lack of negligence is squarely on you and your organization’s shoulders. At the very least demand that your vendor’s solutions help you maintain compliance versus hinder your ability to stay compliant.
As an example, in the payment card industry (PCI), all point of sale solutions especially pin pads have to meet the PIN Transaction Security (PTS) Program on handling card data security throughout the capture, transmission, processing and storage processes. This was done three years ago, and it works!
When you hear about large credit card breaches due to pin pad modification or abuse, in every case (so far) it was because the merchant had not updated their pin pads and were still using older “non certified” solutions.
By establishing these guidelines and standards, you are forcing your vendors to enable you to meet your compliancy requirements in the long run, and establishing a more secure process for meeting the original goals of the Meaningful Use rules.
02.25.13