AAMI TIR 57: IT security and risk management

TIR 57 is a “Technical Information Report” from the American AAMI.

It is intended to assist in recognizing and controlling risks due to inadequate IT security of medical devices, thus fulfilling the requirements of ISO 14971 for risk management.

TIR 57: Summary for readers in a hurry

The AAMI TIR 57 is a guidance document that aims to show manufacturers how to meet the requirements of ISO 14971. For each sub-chapter of ISO 14971, the TIR 57 names the activities necessary to identify, assess, and control IT security risks.

TIR 57 does not examine the technology in-depth or provide guidance on how manufacturers can identify buffer overflow vulnerabilities, for example, or avoid them from the outset during development.

If manufacturers do not have a dedicated risk management process or risk management plan for IT security, it is advisable to supplement these standard operating procedures or plans with the aspects mentioned in TIR 57.

Liability of the TIR 57

The AAMI TIR 57 is a “Technical Information Report” (TIR) and is therefore not binding per se. However, all relevant regulations require manufacturers to identify risks in accordance with the “state of the art.” For example, the EU Medical Device Regulation (MDR) states:

“For devices that incorporate software or for software that are devices in themselves, the software shall be developed and manufactured in accordance with the state of the art taking into account the principles of development life cycle, risk management, including information security, verification and validation.”

MDR, Annex I, Paragraph 17.2

The FDA includes the AAMI TIR 57 among the “Consensus Standards” and cites it in its own guidance documents on “cybersecurity.”

Therefore, manufacturers should not see TIR 57 as another “annoying” regulatory requirement but rather as an aid to improving the IT security of their own devices.

Interaction of TIR 57 and ISO 14971

The TIR 57 deliberately adopts the chapter structure of ISO 14971 and adapts the chapter headings accordingly (see Fig. 1).

In contrast to ISO 14971, TIR 57 extends the protection objectives to include IT security and defines the term “harm” somewhat more broadly:

Content and requirements of TIR 57 at a glance

Chapter structure

The technical report maps ISO 14971 and specifies and supplements its requirements specifically for risks due to a lack of IT security.

Requirements of each chapter

Chapter	Claims, comments
3.1 Security risk management process	Add IT security aspects to the process   Observe changed protection goals (see above)
3.2 Management responsibilities	Define acceptance criteria, check process
3.3 Qualification of personnel	Ensure experience with own IT security devices and techniques. Document this!
3.4 Security risk management plan	Supplement the risk management plan. For example, IT security tests such as fuzz or penetration testing should be added. Other methods include systematically evaluating error databases, static code analysis, and code reviews. The planning of the post-production phase must also take IT security risks into account.
3.5 Security risk management file	Contains the plan, the measures and their verification, analogous to 14971.
4.1 Security risk analysis process	The process must be carried out in accordance with chapters 4.2 to 4.4. It should be noted that not only the device itself is analyzed, but also its context.
4.2 Intended use and identification of characteristics related to the security of the medical device	The protection goal is no longer just to prevent physical harm, but also IT security. During the analysis, manufacturers must consider the entire context in which the device will later be used by the operators.
4.3 Identification of threats, vulnerabilities, assets, and adverse impacts	This chapter is one of the most specific for IT security. Similar to the BSI basic protection catalog manufacturers must identify threats (e.g., attacks), vulnerabilities (e.g., lack of protection against buffer overflow), and objects (e.g., the device, data, systems, components, and networks). Methods such as attack trees, the systematic evaluation of publications or threat modeling are also specific.
4.4 Estimation of the risk(s) for each applicable threat and vulnerability combination	The challenge is estimating the probability. This results primarily from the combination of threats and vulnerabilities. These combinations must be “thought through”.
5. Security risk evaluation	No new or specific requirements
6.1 Security risk reduction	No new or specific requirements
6.2 Security risk control option analysis	No new or specific requirements  Reference to the ISO 80001-1 concept of responsibility agreements, e.g., between manufacturers and operators. The TIR 57 does not consider “security by obscurity” an appropriate option, although this is only mentioned in section 6.5.
6.3 Implementation of risk control measure(s)	No new or specific requirements
6.4 Residual risk evaluation	No new or specific requirements
6.5 Risk/benefit analysis	No new or specific requirements  In the case of risks due to a lack of IT security that cannot(!) mean harm to patients, decisions may be made on the basis of a cost-benefit analysis. Conflicting objectives such as safety and security (e.g., confidentiality) are particularly challenging.
6.6 Risks arising from risk control measures	Here, too, contradictory objectives come into play: an additional password request can increase IT security, for example, but reduce safety because processing is delayed. Fig. 1 illustrates these dependencies with the red arrows.
6.7 Completeness of risk control	No new requirements. The measures through review of effectiveness now relate to IT security.
7. Evaluation of overall residual security risk acceptability	No new or specific requirements. However, conflicting objectives (see above) should be discussed.
8. Security risk management report	Essentially no new requirements. However, some aspects need to be documented more specifically: – Threats, vulnerabilities – Assets – Environment of use (e.g., networks) – Dealing with security patches and malware
9. Production and post-production information	No new requirements. More specific aspects include: – Evaluation of logs – Dealing with malware – Information from software and hardware manufacturers, security researchers, etc.

Other

Most of the pages of TIR 57 are devoted to the annexes. These explain the following aspects, among others:

Special features of IT security for medical devices

The authors point out the special features of IT security for medical devices, such as:

• IT security must be weighted lower than “safety” in emergencies
• Decentralized management of access to data, which must also be patient-specific
• Devices have been used for decades
• Safety has priority over economic considerations
• Heterogeneous deployment scenarios among operators

Models and processes

The Technical Information Report discusses various threats and recommends examining the types of attackers, their motivations, objectives, and capabilities. In a six-level category, TIR 57 sees state attackers at the two most dangerous levels.

The guidance document also contains (check) lists, although these do not always appear to be complete or systematically derived:

• Physical assets
• Information assets
• Threats
• Vulnerabilities
• IT security issues, e.g., relating to performance intended purpose, data storage, data transmission, authentication/authorization, auditing, updates, malware protection, etc.

Conclusion and recommendations

Anyone expecting concrete instructions on which vulnerabilities in which devices are to be identified and eliminated using which procedures will be disappointed by TIR 57. It does not contain a checklist with specific test aspects. Here, manufacturers are recommended to refer to IEC ISO 15408. One exception is the checklist in Annex D, which allows a quick initial assessment of the IT security of (medical) devices.

The TIR 57 is a valuable resource for supplementing and specifying your processes, particularly the risk management and post-market processes, with aspects of IT security. Use it for this purpose.