Software in Medical Devices, by MD101 Consulting

Before AAMI SW96

If we start with a review of guides and standards on security risk management for medical devices, published before SW96, we have:

• AAMI TIR57 and TIR97: two guides (technical reports) on security risk management, for pre- and post-market. Lots of concepts and principles coming from these guides have been put in SW96. This is a classic lifecycle for AAMI documents: starting with guides, when the ground is still moving, and continuing with standards, when the subject is more mature^[1].
• UL 2900-2 and UL 2900-2-1 for Network Connectable Components: clause 12 of these standards gives a brief description of what a security risk management process should be for connected medical devices.
• IEC 81001-5-1 for Health software and health IT systems safety: clause 7 gives an even briefer description of what a security risk management process should be.
• Guidances from regulatory authorities and international consortiums, like FDA, MDCG, TGA, and IMDRF. They present an overview or very brief description of what a security risk management process should be.
• And more general: ISO 27005 for information systems. This standard contains a thorough description of a security risk management process, but not tweaked for medical devices.

AAMI SW96 overview

It takes 14 pages in AAMI SW96 to describe a security risk management process for medical devices! Its level of description is far above the aforementioned documents (excepted ISO 27005, but not specific to MDs). We are more at the level of details of ISO 14971, if we try to make a comparison.
This is actually the authors' intent: to specify requirements (...) on how medical device manufacturers should manage security risk throughout the life cycle of a medical device within the risk management framework defined by ISO 14971.

The scope of the standard tells us what requirements are covered. They can be grouped in four sets (my analysis, this separation isn't in the standard).

1.Risk management process in design:

Here we retrieve the classical steps of a risk management process described in AAMI TIR57. Identifying, assessing, determining risk controls, verifying risk controls effectiveness, overall residual risk acceptability, and risk/benefit balance.

2.Risk management process in post-production:

The standard requires establishing an enterprise-wide process to manage security post-production (...) and creating design features that enable production and post-production management of security risk and effective integration with healthcare delivery organization (HDO) network security policies and technologies
These two topics are very important to establish an effective security risk management process in production and post-production. It is a combination of the appropriate processes, and appropriate features in the medical device. Thus, such features shall be present in product requirement specification (high-level requirements) and software requirement specification (more detailed requirements).

3.Monitor, control and coordinate

An effective risk management process requires coordination with users, customers, and integrators. It comes with (partial quote of the standard): coordinating communications with HDOs for security risks; understanding and communicating the security expectations from manufacturers to those who deploy their medical devices in a user environment.

4.Delivery of patches, and end-of-life

Risk management works with change control and design process, to deliver in a timely manner security patches. Last, the manufacturer shall anticipate the safe and secure decommissioning, and end-of-life of the device.


Here are below some other striking points of the standard that I gathered. Buy it and read it to make your own judgement.

Risk management in design

This is probably the subject with most of information already present in existing standards and guides. First, AAMI SW96 borrows the figure from AAMI TIR57, where the ISO 14971 process is copied into a security risk management process, with interactions between the two.
Looking at other standards:

• IEC 81001-5-1 defined this process in a very laconic manner, and high-level risk controls can be found in IEC/TR 60601-4-5.
• UL 2900-2-1 defines this process in section 12, with details on risk controls (a bit equivalent to IEC/TR 60601-4-5) and lots of technical details on coverage of security risk analysis. Cherry on the cake, UL 2900-2-1 in its 2023 version adds rationale on these detailed requirements.
  

If you already apply UL 2900-2-1 in design, AAMI SW96 won't tell you something so much new about risk management in design. If you already apply the laconic IEC 81001-5-1, you will learn something.

Risk evaluation

Contrary to other standards, AAMI SW96 doesn't reference in its normative part, neither CVSS, nor MITRE, nor NIST frameworks as possible ranking systems for security risks. We see here a position similar to ISO 14971, confining the standard to a process, excluding practical contingencies.
CVSS, MITRE, and NIST frameworks are quoted in the appendixes of the standard.

The standard also requires implementing recurring / periodic security testing during design and development. Such testing strategy, implemented in the CI/CD for example, allows to identify new security vulnerabilities.

Security controls

However, AAMI SW96 remains mute on security controls, pointing vaguely to relevant standards, technical reports and security frameworks. A position opposite to IEC 81001-5-1 and UL 2900-2-1, which point to their own set of risk controls. This is probably a deliberate choice. AAMI SW96 is a process standard, technical requirements relevant to products have to be found elsewhere.

Security controls order of priority

Like ISO 14971, we retrieve the requirement on order of priority of risks controls, adapted to a security risk management process. It's worth quoting the standard:
a) inherent security by design;
b) inherent security by manufacturing process;
c) protective threat mitigation measures added into the medical device;
d) protective threat mitigation measures added into the manufacturing process;
e) security risk disclosure (...) and/or security risk transfer to users; and
f) where appropriate, security training to users.

Misuse

The standard includes the topic of reasonably foreseeable misuse. It requires to consider as reasonable foreseeable misuse:

• Exploit scenarios by threat actors,
• Failure of some end-user populations to follow security best practices.

The idea is not to inject all possible security compromising scenarios in the usability file. It is more to take from the usability file the user profiles, to take into account such intended actions from threat actors (obviously) and unintended actions from end-users (less obvious) compromising security.

Benefit-risk analysis

AAMI SW96 offers the possibility to perform a benefit/risk analysis when a security risk isn't acceptable after practical risk controls. That could be the case with legacy devices. For example, in medical imaging with DICOM connectivity in clear format, when legacy PACS servers don't accept cyphered DICOM protocols.

Overall security residual risk acceptability

Last, AAMI SW96 brings a new and interesting concept in this section. Curiously, this is a note and not a requirement. It recommends to consider the balance of direct medical benefits and overall security residual risk of a device connected to a network. This balance evaluation is not found in other security risk management processes for other purposes, like privacy impact assessment, or other industries where the medical benefit doesn't exist. I warmly recommend to read twice this note, which could save your legacy devices from the trash container!

Risk management production and in post-production

AAMI SW96 defines the security risk management process throughout the medical device lifecycle. Conversely to risk management in design, IEC 81001-5-1 aligns better with AAMI SW96, by defining similar requirements on management responsibilities, and process periodic review. Something not so clearly present in UL 2900-x, more focused on the product.
The standard goes even further, with requirements on maintaining awareness on new threats, having a security incident response plan, and vulnerability disclosure plan. Something present in FDA guidances on cybersecurity (in a precise manner) and present in MDCG 2019-16 (more generic).

Supply chain, 3rd party medical devices

AAMI SW96 also addresses supply chain management and risk from thrid-party medical devices. Something also present in other standards, but less specific. Here, the standard requires to document supply chain management in the security risk management plan and 3rd party medical devices security in the security risk management file.

Production phase

The level of details of AAMI SW96 requirements is far more precise than any other standard. If a risk control measure is established in production, its effectiveness shall be monitored. Thus, information coming form production processes shall be collected and analysed, to confirm the effectiveness of risk control measures.
This standard brings detailed requirements on information collection, review and subsequent actions.

Note 1: "Production" shall be understood as "manufacturing“ for software embedded in medical devices (SiMD). "Production" shall be understood as "installation and deployment" before use for SaMD.
Note 2: For SaMD, when the manufacturer completely manages the infrastructure and servers, a complete set of security measures on the production environment and the supporting infrastructure should require the implementation of an ISMS, like ISO 27001 or, less heavy, SOC2.

Post-production

Likewise, the level of details of AAMI SW96 requirements for the post-production phase is far more precise than any other standard. Especially on information monitoring, the list of information sources contains 7 bullets, with sources like independent security researchers. This degree of precision on information collection looks like what is required on information collection for PMS / PMCF of CE marked devices: don't miss anything otherwise you won't be compliant!
And the possible actions to perform upon review of collected informations is also a very extensive list: RMF review, threat model review, and so on. The intent is clearly to avoid missing a vulnerability identified somewhere by any stakeholder.
The standard also introduces the concepts of End Of Guaranteed Support (EOGS) and End Of Support (EOS) to progressively withdraw from the market devices coming to their end of life. EOGS and EOS are present in the IMDRF document on principles and practices for the cybersecurity for legacy medical devices. A document to read to better understand EOGS and EOS.

Conclusion

AAMI SW96 2023 is definitely made to be the standard defining the security risk management process for medical devices. Its level of abstraction is made to be applied by any manufacturer having SaMD or SiMD in their product portfolio. We can bet this standard will be recognized soon by the FDA.
It deserves to be converted to an ISO or IEC standard, at international level.

You can apply it for CE marking too. Notified Bodies will roll their eyes at first sight. But they will understand the importance of this standard when they read it. Needless to say that a few years will pass before the international version of this standard is harmonized (2030? 2040? :-) ).

Post-Scriptum: ANSM guidance on cybersecurity is quoted in the annexes. Woohoo! French cyber cooking tastes good!