R-TF-024-002 Cyber Security Risk Management Plan

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 Cyber security 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 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

This phase allows to identify assets and threats based on the device description and specifications.

Establishing the context consists in defining the scope and boundaries, and describing the following items, as appropriate:

• The medical device (hardware, software, network).
• Its accesories,
• Its environment
• The processes involved in the lifecycle of the device:
  • Internal processes
  • Outsourced processes
  • Client/user processes
• The users and user profiles
  • Client users
  • Users of the manufacturer (e.g. support, maintenance, development)
• The level of education of users
• The use cases associated to the users and user profiles
• The types of data handled in the device
  • Medical data
  • Configuration data
  • Logs
• The software network interfaces and protocols
  • HTTP, TCP...
  • REST
• The data input/output streams
• The SOUP used in software
  • Maintained software
  • Supported software (see IEC 81001-5-1)
• The constraints affecting the device
  • On the device
  • On manufacturer processes
  • On user processes
  • Regulatory requirements: GDPR, HIPAA...
• Constraints regarding emergency access to the device for patient safety, bypassing security measures.

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.

Define the threats

A threat is anything—whether human, natural, accidental, or deliberate—that could potentially damage one or more assets. Examples include:

• Criminal organizations and advanced persistent threats.
• Inexperienced or malicious users (e.g., patients, caregivers, disgruntled employees).
• Natural events.

Threats are identified based on the established context and are formally documented in a threat model. This model can be described using appropriate methods such as data flow diagrams (DFDs), use cases, or various architectural diagrams (hardware, system, software).

The threat modeling process must account for specific constraints, such as provisions for emergency access that bypass standard security measures. Furthermore, any elements excluded from the scope of this risk management plan must be clearly identified and justified by

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

All existing and planned controls must be identified. These can be internal to the manufacturer’s organization or exist within external environments, such as those of a healthcare provider or a datacenter service supplier.

Following identification, each control shall be assessed to determine if it is effective, sufficient, and justified.

Weaknesses and vulnerabilities

• 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 analysis shall identify all potential consequences of a security breach. This includes assessing the impact on assets by evaluating any loss of confidentiality, integrity, and availability. Furthermore, all potential consequences for patient safety must be separately identified.

Records

Assets, threats, vulnerabilities, existing controls and consequences shall be recorded in the R-TF-024-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 R-TF-024-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 R-TF-024-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.

info

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 R-TF-024-003 Cyber Security Risk Matrix.

Risk communication

The R-TF-024-004 Security Risk Assessment Report and the R-TF-024-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 Cyber security 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 Cyber security File. This review should include 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 exploitability of the vulnerability or weakness, and thus ease of the attack scenario:

Ranking	Definition	Likelihood of occurrence
1	Exploitability is very low, the attack is very uneasy	Very low
2	Exploitability is low, the attack is uneasy	Low
3	Exploitability is moderate, the attack is somewhat easy	Moderate
4	Exploitability is high, the attack is easy	High
5	Exploitability is very high, the attack is almost certain	Very high

Severity

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

Ranking	Definition	Severity of the risk
1	Recoverable data loss, system availability/integrity loss, Non-sensitive data leak. Negligible cost	Negligible
2	Isolated, limited leak of non-sensitive data. Isolated loss of data/system integrity of system availability. May incur costs to recover leaked data.	Minor
3	Small, isolated loss of confidentiality or data/system integrity of system availability. Small consequences on financial health of manufacturer.	Moderate
4	Some loss of confidentiality or data/system integrity of system availability. Some consequences on financial health of manufacturer.	Critical
5	Significant loss of confidentiality or data/system integrity of system availability. Threatens financial health of manufacturer.	Catastrophic

Risk Priority Number (RPN) and acceptability

Risk priority number = Severity x Likelihood

CROSS TABLE OF RISK PRIORITY NUMBER
	Negligible (1)	Minor (2)	Moderate (3)	Critical (4)	Catastrophic (5)
Frequent (5)	Tolerable (5)	Tolerable (10)	Unacceptable (15)	Unacceptable (20)	Unacceptable (25)
Probable (4)	Acceptable (4)	Tolerable (8)	Unacceptable (12)	Unacceptable (16)	Unacceptable (20)
Occasional (3)	Acceptable (3)	Tolerable (6)	Tolerable (9)	Unacceptable (12)	Unacceptable (15)
Unlikely (2)	Acceptable (2)	Acceptable (4)	Tolerable (6)	Tolerable (8)	Tolerable (10)
Very Unlikely (1)	Acceptable (1)	Acceptable (2)	Acceptable (3)	Tolerable (4)	Tolerable (5)

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.

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 is conducted throughout the device lifecycle, including during design modifications and after market release, to verify and validate the effectiveness of security controls. These activities may be performed by internal teams or third-party security experts.

Verification and traceability

All cybersecurity-related requirements are tested according to the organization's established verification and validation (V&V) processes. To ensure full traceability, each security requirement must be linked to a specific test case within the corresponding unit or integration test plan. The execution of these tests provides the supporting evidence needed to confirm that security functionality is implemented correctly.

Testing Methods and Handling of Findings

The testing process employs various techniques to identify potential security issues. Any vulnerabilities or weaknesses discovered through these methods will be formally assessed for cybersecurity risk. All identified residual risks must be documented in the R-TF-024-003 Cybersecurity risk matrix and addressed with appropriate mitigation or corrective actions.

The following table summarizes the primary security testing activities planned for the product:

Test	Test Description
Software Composition Analysis (SCA)	Identify vulnerabilities in third-party and open-source components to ensure they are secure and up to date.
Static Application Security Testing (SAST)	Scan source code for security vulnerabilities before compilation.
Dynamic Application Security Testing (DAST)	Test the application in a runtime environment to detect vulnerabilities.
Fuzzing	Conduct fuzz testing to find unexpected security vulnerabilities by providing invalid, unexpected, or random data input.
Penetration Testing	Simulate real-world attacks to identify security weaknesses and validate the effectiveness of security controls.
Vulnerability Scanning	Use automated tools to identify known vulnerabilities in software components and configurations.
Security Review	Conduct final security assessment to confirm all identified vulnerabilities have been remediated.

Records

The report of the security testing should be recorded in the R-TF-024-005 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 R-TF-024-004 Security Risk 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.

Threat Monitoring

These are the employed sources for identifying potential vulnerabilities.

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

The following internal processes are used to collect security issues:

• CAPA system (see GP-004 Corrective and Preventive Action),
• SOUP security issues (see R-TF-012-019 SOUP),
• Servicing or maintenance reports by product support team,
• Cybersecurity metrics (see next section)

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
• 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 risk testing should be recorded in R-TF-024-005 Security Risk 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

complete

AI LABS's policy and procedure for Coordinated Vulnerability Disclosure for AI LABS is published on ...

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.

As explained in the AI LABS policy and procedure, the report should contain the following information:

• Contact information of the submitter (e.g., name, address, phone number)
• Date and method of discovery
• Description of potential vulnerability
• Product name
• Version number
• Configuration details
• Steps to reproduce
• Tools and methods
• Exploitation code
• Privileges required
• Results or impact

The support team is responsible for:

• Creating a security support request in Jira
• Sending a confirmation of receipt of the report to the submitter within 48 working hours
  • This is not a confirmation of the validity of the leak by confirmation of the start of the investigation
• Notifying the CTO about the security support request so that the CTO can start the identification of the vulnerability

Identify the vulnerability

The CTO and his team try to verify the suspected vulnerability based on the information provided in the security support request. They create a dedicated task in the Jira project in order to trace all the performed verifications. The CTO and his team perform their verification based on the available sources of information listed in Threat monitoring section. The verification phase leads to determine the legitimacy and seriousness to the reported vulnerability.

If the reported vulnerability is legitimate, the exploitability and severity of patient harm are assessed in order to determine if the risk is controlled (acceptable) or uncontrolled (unacceptable):

• If the risk is uncontrolled, an Out-of-Cycle Patch Cycle is engaged
• If the risk is controlled, the patch will be integrated in a Regular Patch Cycle

The verification may also identify remediation actions that may include complete solutions to remove the cybersecurity vulnerability from the device or compensating controls that adequately mitigate the risk.

The verification may also lead to the following outcome that terminates the investigation:

• Double reporting: The problem is as previously reported and is already being handled via a Coordinated Vulnerability Disclosure procedure, via some other incident handling procedure, via scheduled maintenance, or is already remedied.
• Out-of-date: The vulnerability is only present in a version of the device that is no longer supported by the organisation.
• Non-security vulnerability: The reported vulnerability has no implications for data or patient security or is no capable of abuse using existing techniques.
• Third party vulnerability: The vulnerability is present in the product or service of a third party. In consultation with the submitter, contact may be made with the third party.

Finally, the verification could may lead to a Can not reproduce situation: It has not been possible to reproduce the vulnerability based on the report information.

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

Once the verification of the vulnerability is completed, the support team informs the submitter of the findings depending on the verification outcome:

• The support team informs the submitter why the investigation has been terminated and the actions he/she may take based on the reason of termination (known remediations, update the version of the device, etc.).
• The support team informs the submitter that more information (evidence) is required by AI LABS to prove this is a patient and/or security problem
• The support team informs the submitter that the validity of its report and the next steps in the investigation or about the remediation development plan

The remediation development plan is started from this step.

Report the vulnerability to customers, ISAO and FDA

If the vulnerability leads to an uncontrolled risk and there is no known serious adverse event, AI LABS communicates the vulnerability no later than 30 days after learning of the vulnerability to:

• the customers by email
• the ISAO by email: Health-ISAC

The communication:

• describes the vulnerability including the impact assessment according to AI LABS's understanding of the report
• explains AI LABS's effort to address the risk of patient harm as quick as possible
• describes the interim compensating controls, if any
• explains the remedation development plan to bring the residual risk to an acceptable level

In the case there is a known serious adverse event or AI LABS was unable to communicate about the uncontrolled risk before 30 days the AI LABS will report the vulnerability to the FDA according to 21 CFR part 806.

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 identifying an uncontrolled risk, an out-of-cycle security patch will be released within 7 to 60 days, depending on the severity and complexity of the issue. This rapid response is crucial for maintaining the security and safety of the device in a dynamic threat environment.

The 7-day window is reserved for vulnerabilities with known exploits in the wild or that could severely impact device functionality, while the 60-day window is for vulnerabilities that require more complex testing and validation to ensure the patch does not introduce new risks.

Emergency patchs will be treated as high priority changes and will expedite the review and approval process.

Software development process

All security related changes will be subject to the organization's established change control process (outlined in GP-023 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 T-012-023 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$)

This is the standard method for deploying urgent, out-of-cycle, and regular security fixes that are fully backward-compatible and require no changes to the API contract.

• Description: Patches are for critical security updates and bug fixes that are applied directly to the existing codebase without altering its external behavior.
• Impact: No client-side action is required.
• Reasoning: The update is applied to the active API endpoint (e.g., api/v1.2/). All client integrations pointing to this version automatically benefit from the security fix without any modification or downtime.

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.

• Description: A minor release is required when the resolution for a vulnerability involves, for example, adding a new, more secure endpoint or enriching an existing one with new security-related fields.
• Impact: Client action is required to adopt the security enhancements.
• Reasoning: The enhanced, more secure version is deployed as a new API endpoint (e.g., api/v1.3/). To receive the security benefits, clients must update their integration to target this new endpoint. The previous endpoint (e.g., api/v1.2/) will remain operational for a transition period but will not contain the security improvements of the new version.

Communication

In the case of releasing a patched version to mitigate an uncontrolled risk, an email is sent to the customers to confirm the vulnerability previously identified has been fixed in the upcoming version.

In other case, for regular patch, the communication will follow the common process as stated in the GP-021 Communications.

Traceability matrixes

Traceability matrixes are documented in the R-TF-024-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