Guest Column | October 30, 2017

What Does the Federal Risk Management Framework Mean for Medical Device Developers?

By Kevin Stoffell, Battelle

Federal buyers make up an enormous and attractive market for medical device manufacturers. The two largest federal buyers, the Department of Defense (DoD) and the Veterans Administration (VA), spend hundreds of millions of dollars on medical device procurement annually to support their systems of hospitals and medical centers, as well as provide care for soldiers and veterans.

But tapping into this market can have unexpected pitfalls for medical device developers. Medical devices sold to federal buyers must meet security requirements defined by the Federal Risk Management Framework (RMF). The RMF overlaps with, but is not identical to, cybersecurity guidelines manufacturers must follow for FDA approval of medical devices; getting FDA approval is not a guarantee that the device will meet RMF requirements. Manufacturers who want to make federal agencies part of their sales strategy need to understand the difference and know how to apply RMF requirements to their devices.

RMF vs. FDA Requirements For Secure Design: What’s The Difference?

Most medical device manufacturers are well-acquainted with the FDA’s premarket and post-market guidance for medical device manufacturers. These documents detail the FDA’s expectations for secure design, cybersecurity testing, and risk management. They are very specific to the medical device industry and the documentation that manufacturers are expected to provide during the submission process. The FDA’s main priority is making sure that devices do not put patient safety or data privacy at risk.

The RMF is a different animal. The Federal RMF applies broadly to all categories of Information Technology (IT)-based devices sold to federal clients, from desktop computers to digital door locks. The RMF is focused on ensuring that devices used by federal agencies do not introduce security vulnerabilities that could affect (or infect) the overall IT environment.

While both address cybersecurity risks, their focus, emphasis, and specific requirements are very different. It is entirely possible to meet FDA requirements while failing to comply with the federal RMF — and vice versa.

RMF Basics: What Is Covered?

The RMF covers three basic aspects of data security: confidentiality, integrity, and availability. In other words, it was developed to ensure that data cannot be shared or accessed without authorization, cannot be accidentally or maliciously changed, and is available to authorized personnel when and where they need it.

To meet these objectives, the RMF uses a six-step process:

  1. Categorization of information systems
  2. Selection of security controls
  3. Implementation of security controls
  4. Assessment of security controls
  5. Authorization of information systems
  6. Monitoring of security controls

The RMF is heavily based on cybersecurity standards and guidelines developed by the National Institute of Standards and Technology (NIST). The RMF references and assigns controls from the NIST SP800-53 control catalog to systems. These controls also map to the cross-industry NIST Framework for Improving Critical Infrastructure Cybersecurity (commonly known as the Cybersecurity Framework), which provides a consistent method for planning organizational cybersecurity goals and risk reporting. The NIST standards and guidelines define requirements for various aspects of device design and software architecture, such as the use of cryptography, access control, threat monitoring, and data storage and management.

Some requirements identified in the RMF also map to other, more detailed standards or guidelines. For example, cryptography is further governed by Federal Information Processing Standard (FIPS) 140-2. The standard details four levels of security, increasing with the sensitivity of the data to be protected, and provides guidelines on the use of cryptography at each level. It also requires that all cryptographic functions used to protect government data undergo validation testing under the NIST Cryptographic Module Validation Program (CMVP). This is one of the significant requirements managed by and assessed as part of the RMF that requires investment and preplanning to ensure success. Full compliance with FIPS 140-2 cryptographic requirements may require the investment of tens of thousands to hundreds of thousands of dollars for each product version.

Navigating the RMF Process for Federal Agency Sales

Under the Federal Information Security Management Act of 2002 (FISMA-2002) and its replacement, the Federal Information Security Modernization Act of 2014 (FISMA-2014), all federal agencies and departments  — including DoD, civil agencies, and the intelligence community — must follow the RMF when evaluating and purchasing software-based devices. President Trump’s May 2017 Presidential Executive Order on Strengthening the Cybersecurity of Federal Networks and Critical Infrastructure further strengthens cybersecurity enforcement across the federal government. NIST has subsequently released updated guidance on RMF implementation to fit within this executive order.

Most federal acquisitions include a cybersecurity assessment of proposed systems or devices to ensure they will meet federal requirements and be successful in achieving an Authority to Operate (ATO) as an outcome of the RMF. In many cases, DoD or federal customers will limit system or device purchases until they are certain the device will pass the rigorous assessment process in the RMF and be granted an ATO. Without an ATO, a device cannot be operated by the DoD or VA in a networked environment and, in many cases, may be prohibited from all or most stand-alone device functionality.

When new devices are evaluated for purchase, specialized reviewers at the purchasing agency go through all aspects of device security covered by the RMF and determine whether the device meets the requirement. Unfortunately, the assessment process is often checklist based, without a nuanced view into whether applying the standard makes sense for the device in question. This is particularly problematic for embedded type devices that have a limited-functionality operating system and have difficulty applying security controls written for a general-purpose computing system (e.g., a laptop computer). Due to the unique form factors and interfaces of many medical devices, it can be a challenge to properly articulate security features of a device that may, in fact, provide adequate security, but is not technically compliant with controls designed for general-purpose computing systems.

While all federal departments and agencies must use the RMF to evaluate potential technology purchases, each agency has a degree of leeway in how it applies the RMF for its own needs. For example, all agencies must meet a defined level of security for wireless networking, but each may customize the exact methods and configurations of wireless networking it utilizes. Additionally, the DoD follows a much stricter method of assigning cybersecurity controls to systems, which results in significant differences between DoD and non-DoD federal agencies. Medical device manufacturers wishing to sell to DoD or other federal agencies will first need to understand the specific configuration guidelines required by the purchasing agency that may impact the technologies employed in their device.

Finally, manufacturers should be prepared for increased vendor support requirements when selling to federal agencies. For example, agencies may have very specific and aggressive requirements for patch or update intervals and may require validation for software distribution mechanisms. They may also require non-standard warranty and support timelines beyond what is typical for commercial sales

Navigating these requirements can be both expensive and difficult for device manufacturers that have never dealt with federal and DoD requirements. The publicly available documentation, while complete, is voluminous and difficult to navigate. The NIST SP800-53 that defines the federal controls is nearly 500 pages of text, and it does not specify many of the individual variables (e.g., length of time allowable before a screen must automatically lock), which are left to individual agencies to define. The DoD uses a 96-page manual just to implement the portions of the RMF unique to the DoD, in addition to publishing more than 400 individual technical implementation guides for different technologies.

Applying The RMF To Medical Devices

Applying the RMF requirements to a specific device is not a one-size-fits-all proposition. Medical device manufacturers will need to interpret the framework and requirements for their device characteristics and determine how different aspects of the RMF apply.

Implementing the security controls outlined in the RMF can be both tricky and expensive. Much of the framework was written around devices with full operating systems, such as desktop or laptop computers. There is limited guidance for manufacturers of devices that do not use a general-purpose Operating System (OS), such as Windows or Mac OS. Even devices that use a general-purpose OS or an embedded version of a general-purpose OS may have difficulties applying the security guides associated with that OS, since the guides assume a standard configuration and are not designed for devices that provide real-time patient care.

For this reason, many off-the-shelf medical products have operating systems that are not configured to support government security controls. Embedded systems using a limited-function operating system or custom OS generally cannot be made fully compliant with all RMF requirements through normal configuration. When embedded systems are configured to government specifications — especially when it comes to network configurations and communication protocols — there often is a loss of functionality, or system behavior that is incompatible with patient care imperatives. Depending on how critical the functionality is for patient safety and device performance, the tradeoffs made for compliance may be unacceptable. Conversely, tradeoffs made for patient care and performance may be considered unacceptable by government cybersecurity approvers without significant explanation by the device manufacturer.

The easiest way for medical device manufacturers to ensure that their device will be RMF-compliant is to build this compliance into the device from the start. For existing devices, manufacturers will have to weigh the potential benefits of compliance (in the opening of new markets) against the costs and risks of changing their existing design or the potential loss of functionality in the device. Medical device manufacturers who do not have extensive expertise in the RMF on staff will benefit from an expert review by a third party.

While the barriers to federal sales may seem daunting, the new market opportunities opened up by successful navigation of the RMF process can be well worth it. Manufactures shouldn’t count themselves out of DoD or VA sales without a closer look at how the RMF would apply to their device. The changes they would need to make to qualify for federal sales may be easier than they think.

About The Author

Kevin Stoffell is a Cybersecurity Architect in Battelle’s Cyber Innovation Unit. He has more than 20 years of experience in information systems operations and information systems security in academia, military and commercial environments. Prior to joining Battelle, Mr. Stoffell served in the U.S. Marine Corps for 21 years, during which time he designed, implemented and maintained complex communications and computer networks in both garrison and deployed environments. His background has given him extensive experience executing a variety of Risk Management and System Authorization processes and implementing the NIST Cybersecurity Framework for Critical Infrastructure. Mr. Stoffell is an Authorized Instructor with the International Information Systems Security Certification Consortium (ISC)2. He holds a B.S. in Computer Engineering from the University of South Carolina and an M.S. in Electrical Engineering from the Naval Postgraduate School and has earned numerous professional certifications.