Back
New FDA Recommendations for Health Care – It’s a Start, but It’s Not Enough!
I saw this news article last week about the new FDA recommendations for health care; specifically Cybersecurity for Medical Devices and Hospital Networks, and could not let this go.
If you read my last blog entry – Top Five Security Threats to HIPAA and Meaningful Use Compliance you will see that I outlined the majority of the same threats that the FDA is now recommending hospitals and medical solution vendors start to address
Since this topic is near to us here at DirectDefense, as we support several clients in the Medical Industry, I would like to cover where the FDA got things right, but also bring to your attention the larger areas they seem to have missed.
Where the FDA recommendations for health care get it right…
If you distill their recommendations down to the basics, what the FDA is recommending is as follows:
Hospitals –
- Limit network access through network separation and firewalls
- Password protect access
- Remove all default passwords from solutions
- Maintain malware inspection on devices
- Apply patches when they are released
- Monitor the network for abuse
- Have an incident response program
- Medical Vendors –
- Minimize use of shared or hard-coded passwords
- Provide security patches in a timely manner
- Provide a fail safe mode, even if compromised
- Provide solutions to assist in incident response programs
Overall, it is not a bad list of things to accomplish. Keeping untrusted people out of your network is a commendable goal, and for the most part this list outlines a very simple framework or starting point for providing network access to a medical solution.
The biggest take away from this recommendation is based on how you read this. At a minimum, the FDA has finally empowered vendors to start addressing their security problems and releasing patches (and supporting patches) for their issues versus using the old standard of “We can only support XX configuration due to FDA requirements.” Yes, we’ve heard that one a lot over the years.
Where the FDA got it wrong…
Additional Vendor Improvements:
- Better Monitoring and Alerting Solutions –Provide native monitoring solutions to help hospitals identify abuse and internal threats better. Case in point: With the HIPAA standards today, there is a HIPAA certification standard for solutions. This basically means there is some level of audit and reporting going on in these certified solutions. At issue is implementation of these audit features. In many cases they are native to the solution and not proactive in any way. Have a feeling that maybe a doctor or nurse looked up a famous patient’s information? Sure they can generate that report, but it is after the fact. Why can’t we have a solution that actively alerts an Administrator while the abuse of access is going on? Got a hacker trying to brute force accounts or access an EMR solution? It would be nice to get an alert in this type of event.
- Demand Vendors Adopt a Secure Development Lifecycle Program –Based on the recommendations by the FDA, there are no security requirements being enforced from a Secure Development Lifecycle with regards to making sure vendors are proactively testing their products before they ship. Sure they demand the vendors to release patches in a timely manner, but that is after the product has shipped and typically the issue is discovered by either a security researcher or because the hospital/medical organization decided to have a vendor’s solution tested on their own accord.
- Demand Vendors Provide Solutions that Offer Secure Data Transmissions and Storage –One of the glaring omissions in the FDA requirements was a lack of requiring vendors (and hospitals) to provide and deploy solutions that provide secure data transmission and secure data storage natively. As noted in our previous blog, this omission is a major weakness that has yet to be mandated or demanded.
Note: It has been our experience when doing penetration testing against hospitals and medical solutions, that if an attacker simply targets the network communications to the database server or attacks the database server directly, they can easily bypass any native protection scheme a medical solution may have and have unauthorized access to any sensitive data they wish to look at.
This is due to the fact that many medical solutions do not natively encrypt their communications between the various components, nor does sensitive data get encrypted or hashed once it lands in the database.
Additional Hospital and Vendor Improvements:
- Implement an Application Security Program –While the FDA does mention SQL injection in their background for their recommendations, none of their recommendations directly says that you should be testing your applications during development and after they have been installed.
It has been our experience in the past three years that a majority of hospitals have most of the recommendations the FDA outlined, which are basic network security recommendations. However, with that said, very few of them have even started to address the issue of application security. This problem is getting larger with the move to mobile access solutions and cloud-based solutions. The more access you provide, the larger the attack surface becomes. Remember the firewall that they recommend is supposed to allow access to these applications, so it has done its job. It does not care what happens after you let someone into the application.
At a minimum, you should be testing all of your accessible applications for the OWASP top 10 vulnerabilities, as well as making sure they transmit and store data in a secure manner.
As stated previously, at least this is a start in the right direction for the FDA; alas it is about five years late at this point.
However, this initial list was not detailed enough and in our opinion, had some serious omissions based on the challenges of our medical clients are currently dealing with and are areas we recommend all of our clients (medical related or not) start addressing.
06.18.13