T-030-001 Cyber Security Management Plan

Instructions

This is a template for the Cyber Security Management Plan. It's designed to provide a comprehensive structure and example content for a new plan record in the Quality Management System (QMS).

All sections and text within this template must be reviewed and modified to accurately represent the specific risks and mitigation strategies for your product. Once complete, please delete this instructional section before finalizing your document.

Scope

This document contains the security risk management plan for the device. It covers the management all security-related risks during the lifecycle of the device, in design and development, and in maintenance. It also contains the provisions about relationships with the ISO 14971 safety risk management process, and IEC 62366-1 usability engineering process.

Reference documents

Standard and regulatory references

• ISO 14971:2019
• ISO 27005:2022
• IEC 81001-5-1
• IEC 62366-1 :2015
• IEC 62366-2 :2016
• Cybersecurity in Medical Devices: Quality System Considerations and Content of Premarket Submissions
• Cybersecurity for Networked Medical Devices Containing Off-the-Shelf (OTS) Software

Terms and definitions

Term	Definition
Information security risk	Potential that a given threat will exploit vulnerabilities of an asset or group of assets, and thereby cause harm to the organization
Activity	Set of one or more interrelated or interacting tasks
Asset	Physical or digital entity that has value to an individual, an organization or a government
Attack	Attempt to destroy, expose, alter, disable, steal or gain unauthorized access to or make unauthorized use of an asset
Availability	Property of being accessible and usable on demand by an authorized entity
Confidentiality	Property that information is not made available or disclosed to unauthorized individuals, entities, or processes
Control	a control refers to any measure, mechanism, or action implemented to prevent, detect, mitigate, or respond to security threats and vulnerabilities. These controls are designed to protect the confidentiality, integrity, and availability of information systems and data
Integrity	property of accuracy and completeness
ISAO	Information Sharing and Analysis Organizations
Process	Set of interrelated or interacting activities that uses inputs to deliver an intented result (outcome)
RPN	Risk Priority Number
Security, Cyber security	state where information and systems are protected from unauthorized activities, such as access, use, disclosure, disruption, modification, or destruction to a degree that the related risks to violation of confidentiality, integrity, and availability are maintained at an acceptable level throughout the lifecycle
Task	single piece of work that needs to be done to achieve a specific goal
Threat	Potential for violation of security, which exists when there is a circumstance, capability, action, or event that could breach security and cause damage to confidentiality, integrity, availability of information assets
Vulnerability	Flaw or weakness in a system design, implementation, or operation and management that could be exploited to violate the system's security policy.
Weakness	Kind of deficiency

Conventions

Security risk and Cybersecurity risk are used indifferently in this document as synonyms of Information security risk according to the definition above.

Responsibilities

Role	Responsibility
JD-007 Technology Manager	Overall security risk management process responsibility
JD-007 Technology Manager	Software security risks
JD-004 Quality Manager & PRRC	Interface with the safety risk management process
Security expert	Perform penetration testing

Risk management process

The process described below is from the risk management process presented in AAMI TIR57 and AAMI SW96.

The risk management process is an iterative process allowing to increase the depth and details of risk assessment at each iteration.

Context establishment and threat modelling

The context establishment and threat modelling allows to define the context of use of the device, the assets to protect, and the threats that may impact these assets.

Define the assets

An asset is anything of value for the manufacturer or for the end-user.

Assets can be:

• Hardware,
• Software,
• Data,
• SW Services in interface with the device,
• SW development platform,
• Other supporting services,
• Other tangible or intangible assets.

Knowing the assets contributes to identify the magnitude of the consequences of an attack. Eg: the consequences won't have the same order of magnitude if the device is a simple object, a cloud server, or a $1M x-ray scanner.

Define the threats

A threat is anything (human, phenomenon, accidental, deliberate) susceptible to result in a damage on one or more assets.

Examples:

• Criminal organizations, advanced persistent threats,
• Inexperienced users (the patient, a caregiver, a dismounted employee).
• Natural events.

This context allows to identify the threats, documented in the threat modelling. The context and threat modelling can be described in data flow diagrams (DFD), use cases, hardware architecture, system architecture, software architecture, as appropriate.

Risk assessment

Based on the threat model documented in the previous step, the risks shall be identified, analyzed and evaluated according to the objectives of the risk management process and the ranking system for security risk analysis.

A preliminary risk assessment, together with the threat modelling, may be documented at the beginning of the design project, or before design (e.g. in feasability / mock-up, etc.) and reviewed in the design input data.

Existing controls

Existing or planned controls should be identified. They can be identified inside the manufacturer’s organization or in the target environments or other environments (healthcare provider, datacenter service supplier…).

Existing or planned controls should be assessed to determine if they are effective, sufficient and justified.

Weaknesses and vulnerabilities

Weaknesses and Vulnerabilities shall be identified.

• Weaknesses may come from design decisions, anticipated misuse of the device, organizations, processes, etc.
• Vulnerabilities can be found in catalogs like:
  • MITRE Common Vulnerabilities and Exposures List
  • CISA Known Exploited Vulnerabilities
  • NIST National Vulnerability Database

Consequences

The consequences that loss of confidentiality, integrity and availability may have on the assets shall be identified. The consequences on patient safety shall also be identified.

Records

Assets, threats, vulnerabilities, existing controls and consequences shall be recorded in the [T-030-003 Cyber Security Risk Matrix].

Analysis

The risk analysis is performed with the use of the ranking system described in the section Ranking system for security risk analysis of this document, and with the data collected in the previous steps:

• The identification of the consequences on assets allow to determine the impact magnitude of the risk,
• The identification of threats, vulnerabilities, and incident scenarios allow to determine the likelihood of a risk.

Records

For each incident scenario, probability of ocurrence, severity, other criteria and RPN are recorded in the [T-030-003 Cyber Security Risk Matrix].

Evaluation

The RPN are compared against risk acceptance criteria described in section Ranking system for security risk analysis of this document. Legal and regulatory requirements shall be included in the evaluation of the acceptance of risks.

Records

For each incident scenario: risk acceptance class and decision are recorded in the [T-030-003 Cyber Security Risk Matrix].

Risk treatment

The term “risk treatment” is used in ISO 27005. Note that the meaning of “risk treatment” is broader than “risk control” or “risk mitigation” commonly used in medical device industry.

For information, risk treatment options are:

• Mitigate (thus risk control): take action to reduce the likelihood that the threat will materialize.
• Eliminate (kind of inherent security by design): simply remove the feature or component that is causing the threat.
• Transfer (kind of information to users): shift responsability to another entity such as the consumer or the integrator of the device.
• Accept (thus, need of information to users): do not mitigate, eliminate or transfer the risk because none of those options are acceptable given business requirements or constraints.

Note that risk transfer and acceptance shall be acceptable from a safety (ISO 14971) point of view. These two kind of actions couldn't be possible for security risks with a safety impact.

Risk controls shall be sought in this order of precedence (see AAMI SW96):

• Inherent security by design.
  • Example: Design change in hardware or software, documented in a HRS or SRS
• Inherent security by manufacturing process.
  • Example: Documented process step making use of state-of-the-art security feature, e.g.,use of digital signature to verify the authenticity and integrity of a software installation bundle
• Protective threat mitigation measures added into the medical device.
  • Example: Hardware or software mitigation added to the device, e.g., delivering the device with a firewall
• Protective threat mitigation measures added to the manufacturing process.
  • Example: Documented process step making use of less effective security feature (Compared to inherent security by manufacturing process), e.g., ensuring software authenticity by organizational measure, testing software after install
• Security risk disclosure (i.e., providing needed security information to users) and/or security risk transfer to users.
  • Example: Secure operations guidelines or warnings about secure use of the device, for example, reminder in the Secure operations guidelines to activate security windows updates by default-
• Where appropriate, security training to users.
  • Example: Training to users is deemed poorly effective

Risk control should be carried out to decrease the RPN of the residual risk As Low As Reasonably Practicable (ALARP), with economic considerations. If the risk has an impact on patient safety, the risk treatment (risk control) shall be carried out with acceptance criteria related to patient safety.

The security vulnerabilities or impacts on patient safety arising from risk treatment shall also be assessed.

Records

For each incident scenario: the risk treatment plan is recorded in the security risk assessment report.

Risk acceptance

The reevaluation of the risk is performed with the use of the ranking system described in section Ranking system for security risk analysis of this document and with the risk treatment plan.

A security risk may be deemed accepted even if it doesn’t match the risk acceptance criteria of section Ranking system for security risk analysis of this document, with a justification based on the risk/benefit ratio, to override the acceptance criteria.

Records

For each incident scenario: the risk acceptance and justification as appropriate are recorded in the [T-030-003 Cyber Security Risk Matrix].

Risk communication

The [T-030-004 Security Risk Assessment Report] and the [T-030-003 Cyber Security Risk Matrix]:

• are communicated internally to the design team,
• shall be agenda items of the design and validation reviews of the software development plan.

Parts of the security risk assessment report may also be communicated externally to service providers or suppliers, as appropriate. When a supplier requires knowledge of the security risk assessment report, it should be determined if this supplier shall be placed in the list of critical suppliers.

Post-production monitoring and review

The Risk Management File is sistematically reviewed and updated, especially when:

• The product is modified,
• The context changes,
• Assets, threats, vulnerabilities change,
• Analysis of data of post marketing surveillance triggers a reevaluation (internal defects, customer requests, maintenance, vigilance bulletins, security incidents, field information from any source).

The review of post-marketing data is performed annually. Reviews and updates to any risk will be documented, approved, and included within the Risk Management File.

The review includes an evaluation of the relevance of the ranking system and the need to update it upon business or regulatory context.

Ranking system for security risk analysis

This section describes how the risk priority number is deduced from the characteristics of the risk:

• Likelihood of occurrence of the risk,
• Severity of the risk.

Likelihood of occurrence

The likelihood is assessed from the probability of occurrence of the threat, the probability that the vulnerability can be exploited by the threat, and the probability that the attack scenario leads to a security breach.

Severity

The severity is assessed from the consequences on confidentiality, integrity, availability and economic consequences of the attack scenario.

Risk Priority Number (RPN) and acceptability

Risk priority number = Severity x Likelihood

Ranking system of safety risks when security breach is the hazardous phenomenon

According to Annex F of ISO 24971:2020, in case of security risks with impact on safety, the probability of risks can be split into:

• P1 = Probability that a vulnerability can be exploited by the threats (the hazardous situation),
• P2 = Probability that the hazardous situation (a vulnerability can be expoliuted by the threats) leads to a harm.

The probability of safety risk where the hazardous situation is a security breach is based on the likelihood of the security breach and the probability of the breach to give rise to a harm.

Communication

Communication with safety risk management team

Communication with the safety risk management team shall be performed in a timely manner when:

• A security risk has a potential impact on safety,
• Security controls may affect safety,
• A security incident may affect safety.

In case of security incident, which may affect safety, the information shall be immediately reported to the person in charge of medical device reporting.

Communication with usability engineering team

Communication with the usability engineering team shall be performed in a timely manner when:

• A security risk has a potential impact on usability,
• A security control may affect or have an impact on usability.

When a security control has an impact on usability, the assessment of the effectiveness of the security control shall take account of results of usability assessment. Eg, the use scenario where the security control appears may be included in the summative evaluation.

Security testing

Security testing may be conducted both during design modifications and after the product has been released to the market. This testing may involve a combination of verification and validation of security requirements for design changes, as well as broader security testing activities carried out by either internal teams or third-party experts. |

Records

The report of the security testing should be recorded in the [T-030-005 Cyber Security Risk Testing Report].

Overall residual security risk acceptability

Overall residual security risk acceptability is based on the following items:

• The intended context of use and treat model,
• Design considerations pertaining to security risks and unclosed weaknesses (can be backed by architecture design charts, design reviews, and traceability matrixes b/w mitigation actions and HW/SW requirements specifications),
• The acceptability level of each residual risk,
• The presence of unresolved anomalies with possible security consequences,
• The presence of unclosed vulnerabilities (especially vulnerabilities in COTS/SOUP, and vulnerabilities identified lately in the design, like in pen tests),
• The impact (or absence of impact) of security risks or their mitigation on safety risks or usability,
• When some security risks are tolerable or non-acceptable, the security risk vs clinical benefit ratio.

Records

The overall security risk acceptability discussion should be recorded in the [T-030-004 Cyber Security Assessment Report].

Post-market management of fielded devices

Review, analysis and decision

The following activities are performed annually when devices are placed on the market:

• Review production and post-production information related to security,
• Analyze information to identify the need to update the threat model, reassess security risks and potential safety impact:
  • On the device subject of information,
  • On other devices in our product portfolio,
  • On COTS/SOUP used with these devices,
  • On third party systems interfaced with these devices, as appropriate.

And, if needed:

• Update the threat model,
• Perform the security risk reassessment,
• Communicate to the safety team potential safety impact,
• Trigger the coordinated vulnerability disclosure process,
• Decide to release a security patch or minor update on device software,
• Communicate the issue(s) to third party systems owners.

The reassessment shall include (but not limited to):

• The relevance of the threat model,
• The effectiveness of existing security controls,
• The acceptable level of pre-market residual vulnerabilities,
• New or revised vulnerabilities or weaknesses.

External Sources

Customers

Customer may report product security concerns according to the described in [GP-014 Feedback and complaints]either because of a security incident or from testing and monitoring conducted at their own facilities.

Security researchers

Security researchers may report vulnerabilities to AI LABS via public-facing channels. When such reports are received, the product security incident must be formally documented and assessed in accordance with the [GP-017 Technical assistance service]. Prompt notification to the appropriate cross-functional team is required to ensure timely evaluation and response.

CISA Known Exploited Vulnerability Catalog

On a recurring basis—at least once a month—the CISA Known Exploited Vulnerabilities (KEV) database shall be reviewed for any new vulnerabilities that could affect the device. It will be accessed to this website https://www.cisa.gov/known-exploited-vulnerabilities-catalog and examined the catalog for newly listed vulnerabilities relevant to the components used in the solution. If a relevant new vulnerability is identified, the Incident Response Plan must be initiated, beginning with the initial evaluation and triage of the vulnerability.

Information Sharing and Analysis Organizations (ISAO)

ISAOs play a crucial role in the sharing of threat intelligence and vulnerabilities among organizations. AI LABS participates in ISAO initiatives to stay informed about emerging threats and vulnerabilities that could impact the device.

National Vulnerability Database (NVD)

The NVD is a comprehensive repository of known vulnerabilities. AI LABS regularly monitors the NVD for vulnerabilities that may affect the device, ensuring that any relevant vulnerabilities are addressed promptly.

Internal Sources

Post market surveillance methods

Post market surveillance methods described in [GP-018 Post Market Surveillance] are used to collect security-related information from the field.

Cybersecurity metrics

In order to follow the effectiveness of cybersecurity processes for the device, the following cybersecurity metrics are tracked and recorded annually throughout the device lifecycle:

• Percentage of identified vulnerabilities that are updated or patched (defect density)
• Average duration from vulnerability identification to when it is updated or patched; and
• Average duration from when an update or patch is available to complete implementation in devices deployed in the field, to the extent known.

Periodic security testing

In order to confirm the effectiveness of security controls of the device, to confirm the acceptable level of residual risks, and to track new security pitfalls, security requirements testing, threat mitigation testing, vulnerability testing, and penetration testing are performed annually.

Records

The report of the periodic security testing should be recorded in [T-030-005 Cyber Security Testing Report].

Coordinated vulnerability disclosure

AI LABS's coordinated vulnerability disclosure process is composed of 4 steps:

1. Receive the vulnerability report,
2. Identify the vulnerability,
3. Communicate to the submitter the findings and outcome of his vulnerability report,
4. Report the vulnerability to customers, ISAO and FDA.

Receive the cybersecurity issue from the submitter

A report concerning a vulnerability is received via e-mail. E-mail reports are received at support@legit.health.

Identify the vulnerability

The support team acknowledges the receipt of the vulnerability report to the submitter within 5 business days.

Communicate to the submitter the findings and outcome of his vulnerability report

AI LABS evaluates the vulnerability report and determines if the report is valid. AI LABS communicates the findings to the submitter no later than 30 days after learning of the vulnerability.

Report the vulnerability to customers, ISAO and FDA

If the vulnerability is confirmed and leads to an uncontrolled risk, AI LABS reports the vulnerability to customers, ISAO and FDA according to the communication process described in the section Communication of this document.

Timelines to develop and release patches

There are 2 timelines identified:

1. A vulnerability leading to an uncontrolled risk, the Out-of-Cycle Patch Cycle is engaged.
2. A vulnerability leading to a controlled risk, the Regular Patch Cycle is engaged.

Both are described below.

Regular Patch Cycle (Planned Updates)

The device will follow a regular patch cycle every 6 months, in which AI LABS will release cumulative security updates and software improvements. This schedule balances the need for timely security updates with operation feasibility, minimizing disruption to users.

Out-of-Cycle Patch Cycle (Emergency Updates)

In the event of a critical vulnerability that poses an immediate threat to the security of the device, AI LABS will initiate an out-of-cycle patch cycle. The goal is to develop, test, and deploy an emergency patch within 30 days of identifying the vulnerability. This rapid response is crucial to mitigate potential risks and protect users.

Software development process

All security related changes will be subject to the organization's established change control process outlined in [GP-024 Change control management]. The urgency and complexity of the change will determine the appropriate way to declare change control depending on the required resolution time described above.

• Regular Patch Cycle
  • Integration into Software Roadmap: regular patch will be included in the overall software roadmap
  • Existing Change Control: regular patch cycle will be included in existing Change Control record accordingly to the roadmap
• Out-of-Cycle Patch Cycle
  • Existing Change Control : if the closure time of the current change control is compatible with the required resolution time, the emergency patch could be incorporated as a new change within the existing record
  • New Change Control: if the existing change control is nearing completion or if the emergency patch requires a significant deviation from the original plan, a new change control record will be created
  • Prioritization: emergency patches will be treated as high-priority

Once a change control is approved, the software development team will follow the software development plan to implement the changes as outlined in Software Development Plan. This includes design, risk assessments, development, verification and validation. It’s important to mention that any patch, whether regular or emergency, will undergo rigorous testing to ensure it doesn’t introduce new vulnerabilities or impact device functionality.

Release and Commissioning

We deploy all updates to our servers using the Semantic Versioning (SemVer) standard. The version number is formatted as $MAJOR.MINOR.PATCH$.

• $MAJOR$ ($X$): Incremented for incompatible API changes (breaking changes).
• $MINOR$ ($Y$): Incremented for new, backward-compatible functionality.
• $PATCH$ ($Z$): Incremented for backward-compatible bug fixes.

Our API endpoints are versioned using the $MAJOR$ and $MINOR$ numbers, like so: https://api.example.com/vX.Y/

Patch Releases ($X.Y.Z -> X.Y.Z+1$)

Patch releases are used to address security vulnerabilities that do not require changes to the API contract or introduce new functionality. These releases focus on fixing bugs and vulnerabilities while maintaining full backward compatibility.

Minor Releases ($X.Y.Z -> X.Y+1.0$)

This method is used when a security fix necessitates adding new, backward-compatible functionality or altering the API contract in a non-breaking way.

Communication

When a security patch is released, AI LABS will notify customers through email and update the relevant documentation on the company website. The notification will include details about the vulnerability addressed, the importance of applying the patch, and instructions for installation.

Traceability matrixes

Traceability matrixes are documented in the T-030-004 Security Risk Assessment Report.

• Risks, software requirements and test plan. A risk is deemed mitigated when the test status is set to "Passed" in the corresponding test report.
• Types of cyber security controls:
  • Authentication controls
  • Authorization controls
  • Cryptographic controls
  • Code, data and execution integrity controls
  • Confidentiality controls
  • Event detection and logging controls
  • Resiliency and recovery controls
  • Firmware and software update controls