Readying Your Organization for the FDA’s Medical Device Security Recommendations
The U.S. Food and Drug Administration (FDA) recently presented guidance for healthcare to address cyber security vulnerabilities in medical devices, including both stand-alone and IoT devices types. The intentions of the FDA’s recommendations are to serve as a non-binding framework around which healthcare organizations can use to assess their medical device security posture. These recommendations will be helpful in that it shows how serious the FDA is in securing medical devices.
Terms Of Secure Engagement
The key component of the recommendations is to inspire healthcare organizations to develop a framework based around medical device risk assessment. This is especially important when vulnerabilities on these devices are discovered and announced. These announcements are often times immediately followed by the development and execution of exploits by attackers, making it imperative that these events are resolved in a timely manner.
With these recommendations comes a better understanding of the “what” and “how” behind vulnerability reporting to the FDA, as well as a concise listing of potential circumstances which indicates what the FDA intends to enforce regarding the reporting of security items. The guidance in general will revolve around two key aspects of security management, both of which we recommend to our clients to consider in their own security policies.
- Medical devices that have software, including BIOS and firmware, or run any sort of an executable program.
- Any software that is considered to be a medical device, such as a mobile app that tracks a patient’s blood pressure or blood sugar levels.
To put into a short and sweet statement, this includes everything in your organization which touches a patient or is involved in any treatment or diagnostic plan. The protection of a patient’s PHI and PI data is an imperative piece of a healthcare organization’s security puzzle, a puzzle that is growing more complex by the day.
Putting Together Policy Pieces
To add to this overview, there are a number of great call outs that make this a worthwhile set of recommendations. And although many of these aspects may seem fairly obvious, we see many of these falling through the cracks, mostly because organizations assume that the obvious is already in place. So, let’s take a look at a couple of the puzzle pieces that are in play.
The place to start is to ensure that your security policy includes these key items:
- Creating internal processes around vulnerability detection and remediation
- Plans around the setting and deploying of remediation rules and strategies
- Establishing a risk and vulnerability monitoring system to identify and log potential security risks
- Having disclosure policies and procedures in place in the event of an attack or breach
- Utilize threat modeling, especially in regards to data flow and processes, and taking into consideration any trust boundaries your organization may have in place
- Setting and enforcing software lifecycles with an emphasis on software patching and version updates
Many of these are probably already in place within your security policy, but it is always helpful to review and audit your security policy against the FDA recommendations.
Understanding Vulnerability Classifications
The second part of this article has to do with vulnerability classifications. Unfortunately, there is far too much around this point to cover in the space we have here, so we will dive into the some of the more important quick takes here.
The FDA is looking towards device and software manufacturers in this area to determine the level of risk around any discovered vulnerability. The primary categories in vulnerability reporting are either acceptable or unacceptable risks. Acceptable risks are considered minimal and can be patched on a best effort basis. Vulnerabilities which are classified as unacceptable means that the vulnerability poses an imminent danger to an environment and will need to be resolved as soon as possible.
The FDA further breaks this down into two secondary categories: controlled and uncontrolled risks. Controlled risks are considered acceptable risks, while uncontrolled risks mean that the discovered vulnerability is able to adversely affect your infrastructure, most critically patient data, and are categorized as unacceptable.
The most important aspect of these vulnerability classifications is the reporting of these risks. The FDA recommends that uncontrolled security risks and vulnerabilities be reported to both the FDA and the organization’s client/customer base. It is important to note that there are a few exceptions to this rule. These exceptions include:
- Minimal overall adverse effects
- The hardware or software provider resolves the issue within 30 days, whether it be a temporary workaround or a permanent resolution
- The device or software vendor resolves the issue within 60 days and shares the information with an appropriate information sharing analysis organization (ISAO), a list of which can be found on the ISAO Standards Organization’s website
As you can see, while the FDA is attempting to better classify vulnerabilities and the effects of any given risk, there are a number of nuances and organizational maneuvering which will be required in order to meet all of the recommendations as laid out by the FDA.
Seek Out an Experienced Partner
The release of the FDA’s guidance for medical device security is both a welcome and yet confusing addition to a healthcare organization’s security policy. As IoT and consumer devices are being leveraged as patient treatment and diagnostic options, the need exists to follow and adhere to the recommendations even though the FDA at this time is not actively enforcing them.
It is important for you to enlist the help of an experienced partner to incorporate these elements within your own security policies. Contact Champion today to learn more around how can help you implement these recommendations into your environment.