Chapter 7: Security Risk Management
76 Regulatory Affairs Professionals Society
assurance, and conduct appropriate testing, such as
but not limited to vulnerability scanning, fuzz testing,
penetration testing, resource attacks, and security rule
violations.
• Documentation of the security capabilities and security
requirements for the intended use environment to sup-
port the users in the correct, secure use and their security
risk assessments.
• Security monitoring to ensure that security issues that
might impact safety, effectiveness, or data and system
security are discovered and addressed without undue
delay during the total product lifecycle. Security moni-
toring includes, but is not limited to, newly discovered
vulnerabilities, security incidents that occurred in the
field, end-of-support declarations for components,
continuous testing reports, coordinated vulnerability
disclosure and other relevant documents.
• Security issue management is the treatment of any secu-
rity issues without undue delay to determine mitigating
actions (e.g., updates, upgrades, recalls) and the necessity
of customer/regulatory reporting obligations.
IEC 81001-5-1:2021 Safety, security and effectiveness in
the implementation and use of connected medical devices
or connected health software–Part 5: Security–Sub-Part
5-1: Security -Activities in the product lifecycle is a health-
care-specific process standard that extends the IEC 62304
with the activities for security risk management.13 This
standard is recommended for the US and Europe, and is a
regulatory requirement for Japan. An alternative standard
recognized by the US Food and Drug Administration (FDA)
is NIST SP 800-218.14
The FDA guidance for Cybersecurity in Medical
Devices: Quality System Considerations and Content of
Premarket Submissions provides further guidance on the
expectations manufacturers have regarding security risk man-
agement.15 The FDA eSTAR form for 510(k) submissions
contains detailed information on the documentation and
evidence that manufacturers need to provide.16
Threat Modeling
Threat modeling is a systematic approach for analyzing an
item’s security in a structured way, such that weaknesses
can be identified and prioritized. Manufacturers can apply
threat modeling to a wide range of items, including software,
devices, systems, networks, distributed systems, and business
processes. Threat modeling typically identifies attack vectors
and assets most desired by an attacker. It requires a decompo-
sition of the items (software, device, system, etc.) to examine
each possible attack vector for each item individually, and to
determine the type of attacks for which they are vulnerable.
The created list of vulnerabilities can be ordered in terms of
risk, potential to impact safety, effectiveness, or any other
criteria deemed appropriate, such as privacy. Various threat
modeling techniques are available, ranging from making a
simple list of known vulnerabilities, common attack methods,
and common programming mistakes for the components and
design, such as the Open Web Application Security Project,17
Common Attack Pattern Enumeration and Classification,18
and Common Weakness Enumeration,19 or specific threat
modeling frameworks can be adopted, such as DREAD,
OCTAVE, STRIDE, TRIKE, and VAST. Annex A of the
white paper, IEEE Personal Health Devices Cybersecurity
Standards Roadmap,20 provides an overview of several frame-
works and methodologies.
Threat modeling typically includes the development
of detailed architecture diagrams and data flow diagrams,
including data classification. A threat modeling playbook,
developed by MITRE with support from the FDA, provides
a thorough introduction.21
If a new vulnerability adds to a specific attack vector,
compromises a previously unseen use case, or introduces a
new risk that has not been previously assessed in the safety
risk assessment, then an update of the safety risk assessment
is also necessary. However, many security vulnerabilities have
the same attack vectors and impact. Instead of documenting
dozens of almost similar security issues, one could choose to
combine these vulnerabilities into specific groups or classes
with a common impact on safety, confidentiality, integrity,
and availability, as in the following:
• Network access vulnerabilities:
o Resulting in root access without authentication
o Resulting in root access for any authenticated user
• Elevation of privilege:
o To root for any authenticated interactive local users
o To obtain unauthorized access to patient data
• Draining systems resources:
o Central Processing Unit (CPU)
o Memory
The IMDRF document, Principles and Practices for Medical
Device Cybersecurity, provides additional guidance.22
Vulnerability Handling and Security
Monitoring
SaMD relies on third-party software components, on which
functionality might even be provided by services running
on other systems and even other infrastructures. In the
2019 update of the off-the-shelf software (OTS) guidance,
the FDA acknowledges that the use of OTS software has
expanded in tandem with the widespread adoption of gen-
eral-purpose computer hardware.23 In the introduction, the
FDA states the following: “The medical device manufacturer
using OTS Software generally gives up software lifecycle
control, but still bears the responsibility for the continued safe
and effective performance of the medical device.”
From a security perspective, there is a need to understand
the contents of any third-party software in more detail for
instance, an imaging library may combine several other open-
source software packages, each of which might have specific
security vulnerabilities. In this respect, the detail of software
decomposition required for adequate security analysis may
extend beyond what is typically provided in a list of software
76 Regulatory Affairs Professionals Society
assurance, and conduct appropriate testing, such as
but not limited to vulnerability scanning, fuzz testing,
penetration testing, resource attacks, and security rule
violations.
• Documentation of the security capabilities and security
requirements for the intended use environment to sup-
port the users in the correct, secure use and their security
risk assessments.
• Security monitoring to ensure that security issues that
might impact safety, effectiveness, or data and system
security are discovered and addressed without undue
delay during the total product lifecycle. Security moni-
toring includes, but is not limited to, newly discovered
vulnerabilities, security incidents that occurred in the
field, end-of-support declarations for components,
continuous testing reports, coordinated vulnerability
disclosure and other relevant documents.
• Security issue management is the treatment of any secu-
rity issues without undue delay to determine mitigating
actions (e.g., updates, upgrades, recalls) and the necessity
of customer/regulatory reporting obligations.
IEC 81001-5-1:2021 Safety, security and effectiveness in
the implementation and use of connected medical devices
or connected health software–Part 5: Security–Sub-Part
5-1: Security -Activities in the product lifecycle is a health-
care-specific process standard that extends the IEC 62304
with the activities for security risk management.13 This
standard is recommended for the US and Europe, and is a
regulatory requirement for Japan. An alternative standard
recognized by the US Food and Drug Administration (FDA)
is NIST SP 800-218.14
The FDA guidance for Cybersecurity in Medical
Devices: Quality System Considerations and Content of
Premarket Submissions provides further guidance on the
expectations manufacturers have regarding security risk man-
agement.15 The FDA eSTAR form for 510(k) submissions
contains detailed information on the documentation and
evidence that manufacturers need to provide.16
Threat Modeling
Threat modeling is a systematic approach for analyzing an
item’s security in a structured way, such that weaknesses
can be identified and prioritized. Manufacturers can apply
threat modeling to a wide range of items, including software,
devices, systems, networks, distributed systems, and business
processes. Threat modeling typically identifies attack vectors
and assets most desired by an attacker. It requires a decompo-
sition of the items (software, device, system, etc.) to examine
each possible attack vector for each item individually, and to
determine the type of attacks for which they are vulnerable.
The created list of vulnerabilities can be ordered in terms of
risk, potential to impact safety, effectiveness, or any other
criteria deemed appropriate, such as privacy. Various threat
modeling techniques are available, ranging from making a
simple list of known vulnerabilities, common attack methods,
and common programming mistakes for the components and
design, such as the Open Web Application Security Project,17
Common Attack Pattern Enumeration and Classification,18
and Common Weakness Enumeration,19 or specific threat
modeling frameworks can be adopted, such as DREAD,
OCTAVE, STRIDE, TRIKE, and VAST. Annex A of the
white paper, IEEE Personal Health Devices Cybersecurity
Standards Roadmap,20 provides an overview of several frame-
works and methodologies.
Threat modeling typically includes the development
of detailed architecture diagrams and data flow diagrams,
including data classification. A threat modeling playbook,
developed by MITRE with support from the FDA, provides
a thorough introduction.21
If a new vulnerability adds to a specific attack vector,
compromises a previously unseen use case, or introduces a
new risk that has not been previously assessed in the safety
risk assessment, then an update of the safety risk assessment
is also necessary. However, many security vulnerabilities have
the same attack vectors and impact. Instead of documenting
dozens of almost similar security issues, one could choose to
combine these vulnerabilities into specific groups or classes
with a common impact on safety, confidentiality, integrity,
and availability, as in the following:
• Network access vulnerabilities:
o Resulting in root access without authentication
o Resulting in root access for any authenticated user
• Elevation of privilege:
o To root for any authenticated interactive local users
o To obtain unauthorized access to patient data
• Draining systems resources:
o Central Processing Unit (CPU)
o Memory
The IMDRF document, Principles and Practices for Medical
Device Cybersecurity, provides additional guidance.22
Vulnerability Handling and Security
Monitoring
SaMD relies on third-party software components, on which
functionality might even be provided by services running
on other systems and even other infrastructures. In the
2019 update of the off-the-shelf software (OTS) guidance,
the FDA acknowledges that the use of OTS software has
expanded in tandem with the widespread adoption of gen-
eral-purpose computer hardware.23 In the introduction, the
FDA states the following: “The medical device manufacturer
using OTS Software generally gives up software lifecycle
control, but still bears the responsibility for the continued safe
and effective performance of the medical device.”
From a security perspective, there is a need to understand
the contents of any third-party software in more detail for
instance, an imaging library may combine several other open-
source software packages, each of which might have specific
security vulnerabilities. In this respect, the detail of software
decomposition required for adequate security analysis may
extend beyond what is typically provided in a list of software