Recently, Trustonic hosted a webinar titled ‘The Impact of Food & Drug Administration [FDA] Medical Device Cybersecurity Regulations’. This session, attended by over 190 participants, was held in partnership with software development company ICS and IoT security software firm BG Networks.
Its purpose was to inform original equipment manufacturers [OEMs] about the FDA’s new cybersecurity requirements for medical devices. These new requirements have been prompted by a series of high-profile cyberattacks on U.S. medical organizations by criminals exploiting vulnerabilities in device security.
Not only have such attacks caused widespread disruption to hospital services, but they have also put the health of countless patients at risk. This led to the FDA signing the Consolidated Appropriations Act 2023 [‘Omnibus’] into law in December 2022. Section 3305 of the Omnibus – titled ‘Ensuring Cybersecurity of Medical Devices’ – added an amendment to establish a new refuse-to-accept [RTA] policy for cyber devices.
Since October 2023, the FDA has been actively issuing RTA letters for device submissions that fail to meet its requirements. As such, OEMS must understand what cybersecurity measures they must implement to ensure access to the U.S. market.
Here are the key points that were covered in our webinar, and which manufacturers need to bear in mind.
Secure Product Development Framework [SPDF]
To help OEMs ensure their devices meet the FDA’s regulations, we recommend incorporating a Secure Product Development Framework [SPDF] based on IEC 81001-5-1. Essentially, an SPDF is a set of processes that help identify and reduce the number and severity of vulnerabilities within a product. It encompasses all aspects of a device’s lifecycle, from design and development, to release, support, and decommission.
An SDPF based on IEC 81001-5-1 is advisable because this standard, developed by the International Organization for Standardization [ISO], is globally recognized for its robustness.
On top of this, it is regarded as a consensus standard by the FDA. As such, using this approach focuses on the need for software lifecycle consideration of IT security. IEC 81001-5-1 does this by adding specific activities and tasks to the lifecycle processes of healthcare software. This plays a critical role in helping OEMs to strike a proper balance between the safety, efficiency, and security of medical devices.
Despite the effectiveness of IEC 81001-5-1, OEMs should supplement their SDPF with a risk analysis process, such as ANSI/AAMI SW96:2023. Put forward by the American National Standards Institute [ANSI], this standard provides requirements and guidance on methods for performing security risk management for medical devices. Crucially, ANSI/AAMI SW96:2023 is applicable to a device’s entire lifecycle, including post-production phases, meaning the potential for the emergence of security vulnerabilities is greatly minimised.
Security by Design
A core component to meeting the FDA’s regulations is making sure that devices are ‘secure by design’. This is the philosophy cybersecurity should be a primary consideration during the design phase, rather than being treated as a mere afterthought.
By baking security into the design of their devices, OEMs can better protect their products from attack throughout their entire lifecycle. Key to achieving this is ensuring that responsibility for cybersecurity risk at all stages is created within a manufacturer’s organization.
This involves demonstrating that they are specifically focused on managing security, and monitoring this across the device’s lifecycle. Furthermore, OEMs should ensure that the components that they may source for use in devices are secure. If they don’t, it becomes extremely difficult to guarantee the continuity of a product’s security. It’s not enough, however, to simply implement a single layer of security to safeguard against attackers. Given the frequency with which cyberattacks are now committed, it’s a fair assumption that they will happen, and some may successfully penetrate the defences.
Manufacturers must therefore aim to ‘defend in depth’. This means ensuring there’s not just a single security mechanism to keep devices safe, and that several layers are in place. This is to ensure that, if the first is compromised, additional protection measures are in place in order to minimize the risk of any breach.
Software Bill of Materials [SBOM]
Another key focus of the FDA is ensuring OEMs have full awareness and governance over their Software Bill of Materials [SBOM]. This is a list of all open source and third-party components present within a device’s codebase. In addition to this, SBOMs also list the licenses that govern those components, the versions used in the codebase, and their patch status.
The purpose is to facilitate security teams to identify any associated security or license risks more easily and quickly. It also enables such teams to understand if all of their devices are at risk or just a subset based on the devices’ current software state.
From the FDA’s perspective, the expectation is that SBOMs are presented in a standardized format. This allows for automated scanning so that the components present within a device can be reviewed against the U.S. National Vulnerability Database [NVD]. However, it should be noted that not all vulnerabilities are present within the NVD – partly because new ones are constantly being discovered. As such, this can make the task of identifying potential vulnerabilities all the more complex.
Nonetheless, referring to the NVD is an effective way of mitigating risk, and is something that the FDA expects OEMs to do. It also enables great sharing of threat/risk intelligence between industry verticals that are using the same software components.
Once they have assessed their SBOM against the NVD, manufacturers are then required to triage any vulnerabilities discovered within their devices. This involves providing justifications as to how they expect these vulnerabilities will impact the product. All of this must then be presented in a security risk management report, outlining every potential security risk a device may face throughout its lifecycle.
How Trustonic ensures OEMs comply with the FDA’s requirements
The introduction of the FDA’s new requirements should be seen as a positive development for the medical device industry. The introduction of more robust legislation helps to significantly raise the standard for cybersecurity, giving customers greater assurance that devices are better protected from attackers.
This is fundamental to building trust in an industry where the cost of attacks is measured in dollars, and people’s lives. Put in these terms, the need for better cybersecurity is plain. While OEMs may have a strong desire to enhance security in line with the FDA’s requirements, actually going about doing so isn’t straightforward.
Manufacturers must focus much more on ensuring a device’s cybersecurity throughout its entire lifecycle than ever before. On top of this, many OEMs must deal with meeting regulations in various different markets around the world.
Fortunately, Trustonic has the expertise to help them navigate the process of achieving compliance with the FDA’s legislation – and any other industry cybersecurity requirements. After all, this ruling has been influenced by similar regulations in the automotive industry – such as UNECE WP.29 – which we’ve helped many automakers comply with.
Our Trusted Execution Environment [TEE] has already helped countless OEMS ensure their devices are ‘secure by design’ – which is one of the FDA’s key requirements. This is because the TEE allows for critical code and data to be isolated from the less secure parts of the device. Its ability to offer isolated safe execution of authorized security software enables it to provide end-to-end security by enforcing protection, confidentiality, integrity, and data access rights.
Additionally, the TEE provides a mechanism for secure storage of data hidden from the leading Operating System, making it the ideal solution for storing SBOM information. For example, a TEE present in an insulin pump, could simultaneously protect data, instruct the device when to provide doses, and deliver a tamper-proof record. As such, the TEE is highly effectively at providing a 360º approach to device security.
The solution provides a high level of protection against software attacks, generated in the Rich Operating System [OS] environment. It assists in the control of access rights and house sensitive applications, which need to be isolated from the Rich OS. Indeed, our TEE is already used in hundreds of millions of devices running the Linux OS. This provides these OEMs with the ability to leverage OSS for innovation, while backing it up with world-class secure world technology.
By integrating our TEE, OEMS can simultaneously ensure that they’re compliant with cybersecurity regulations, and that consumers have high levels of trust in their products.
