R-TF-024-004 Security Risk Assessment Report
Scope
This document covers the security risk assessment report of the medical device.
It contains:
- The security risk analysis,
- The security risk assessment report,
- The security risk traceability matrixes with software requirements and test cases.
Terms and definitions
| Term | Definition |
|---|---|
| API | A set of rules and protocols that allows different software applications to communicate and interact with each other. |
| Health Care Provider | Organization that delivers medical services to individuals |
| REST API | Representational State Transfer Application Programming Interface, a type of web service that allows communication between systems over HTTP. |
| Security Level (SL) | It represents the degree to which a system or component can withstand threats and potential attacks. |
| Capability Security Level (CSL) | It specifies the degree to which a component, such as a device, system or application, meets the security requirements necessary to resist certain threats |
| Transport Layer Security (TLS) | A cryptographic protocol designed to provide secure communication over a computer network. It is widely used to secure communications over the internet. |
Risk analysis
Intended use
The intended use is available in the Device description and specifications document.
Context of risk assessment
The context of risk assessment is the environment in which the device operates, including the hardware, software, network, and any external systems it interacts with. This context helps to identify potential threats and vulnerabilities that could impact the security of the device.
Assets
Provide a list of assets that are relevant to the device, including hardware, software, data, and any other components that are critical to its operation.
Actors
Actors are individuals or entities that interact with the device, such as users, administrators, and external systems. Identifying actors helps to understand their roles and responsibilities in relation to the device's security.
Diagrams
Connection diagrams
The connection diagrams show how the system components are connected together and what are the type connections.
They are available in the section Global System Views of the document T-012-029 Software Architecture Description.
Data flow diagrams
The data-flow diagrams show the data exchanged between the system components.
They are available in the section Global System Views of the document T-012-029 Software Architecture Description.
Threat model diagram
The threat model diagram provides a visual representation of the potential threats to the system, including the assets, actors, and their interactions. It helps to identify vulnerabilities and assess the risk associated with each threat.
Multi-patient harm view
The multi-Patient harm view is available in the section view Multi-Patient Harm View of the document T-012-029 Software Architecture Description.
Updatability / Patchability view
The updatability/patchability view is available in the section Updatability / Patchability View of the document T-012-029 Software Architecture Description.
Security use case views
The security use case views are available in the section Security Use Case Views of the document T-012-029 Software Architecture Description.
Threat analysis
The threat analysis identifies potential threats to the system and assesses their impact and likelihood. It helps to prioritize security measures and allocate resources effectively.
Threats
Threats are potential events or actions that could compromise the security of the device. They can be categorized into different types, such as external threats (e.g., hackers, malware) and internal threats (e.g., insider attacks, misconfigurations).
Capability Security Level (CSL)
The Capability Security Level (CSL) is a measure of the security capabilities of a component or system. It indicates the level of protection against specific threats and vulnerabilities. The CSL is determined based on the security requirements and the effectiveness of the implemented security controls.
Security risk matrix
The Security Risk Matrix is available in the document T-024-003 Cyber Security Risk Matrix.
Risk traceability matrixes
Risks/Software Requirements/Test Cases
The risk traceability matrix below contains the connections between the risk analysis, software requirements and test plan.
A risk is deemed mitigated when the test status is set to PASSED in the test report.
| Security Risk | Software or Regulatory requirement | Test cases | ||||
|---|---|---|---|---|---|---|
| Unique ID | Key | Summary | Key | Summary | Key | Summary |
Controls category/Risks
The risk traceability matrix below contains the connections between categories of risk controls and risk controls in the device
| Identifier | Category | Risk Control | Comment |
|---|---|---|---|
Overall assessment of residual security risks
This section should provide a concise and comprehensive summary of the security posture of the product after all risk control measures have been applied. It should clearly articulate the findings from various security assessments and the rationale for the final risk classifications.
Key elements:
- Overall Security Posture: High-level statement on attack surface and security from assessments (e.g., penetration testing). Reference detailed reports.
- Vulnerabilities & Resolutions: List identified vulnerabilities (e.g., from pen testing, static analysis, SOUP/SBOM). Describe decisions and actions taken (e.g., addressed, upgraded, backlog) with rationale. State if new risks were found.
- Component & Code Quality: Summarize SOUP/SBOM analysis and static code analysis (e.g., SonarQube) findings. Confirm if issues impact prod
- Residual Risk Classification: State final risk status (e.g., "all acceptable," "X tolerable risks").
- For Tolerable Risks: List each risk, its control measure, and justification for its sufficiency and tolerability.
- Risk Transfer & Responsibilities: Detail transferred risk controls and define responsibilities of manufacturer, healthcare organization, and users (e.g., secure device configuration, network security, IFU adherence).
- Safety Risk Link: Briefly state if safety risks linked to security are acceptable post-controls.
Analysis and decisions
Penetration testing vulnerabilities
This table provides a short analysis and the decision regarding each vulnerability identified during the penetration testing:
| Vulnerability | Analysis | Decision |
|---|---|---|
Risk communication
Internal communication
The Overall assessment section and Security Risk Matrix are communicated to the safety risk management team when there are new patient risks introduced by security risks.
The Security Risk Matrix is communicated to the usability engineering team when security risk mitigations may imply usability modifications.
User and institutions
The Instructions for Use of the device informs the user that the security and cybersecurity policies of their institution should be followed.