Nouveauté ! Développez votre produit SxMD avec un eQMS structuré comprenant des modèles SxMD prêts à être audités et conformes aux normes EU et US. En savoir plus !
SBOM, CBOM, OTS, COTS, SOUP The complete guide Part. 2
![](/_next/image?url=https%3A%2F%2Fa.storyblok.com%2Ff%2F229980%2F880x528%2Fa3627bb289%2Fsbom-cbom-ots-cots-soup.png&w=3840&q=75)
There are many of names used in different regulations and standards to describe software components not developed according to your own IEC 62304 inspired processes.
This article explains what these terms mean, how the work you're doing is related to them & what you need to do to ensure efficiency.
The first article handled the most commonly used terms that occur in regulations about medical device related software, and some abbreviations that are very often used in this context. The goal is to help you understand what they mean, where they come from and what are the differences / overlaps.
This article is mainly focussing terms specified to talk about Cybersecurity.
Most important terms for Cybersecurity
Regulation on Cybersecurity cover the design of devices and processes in the manufacturers, the operator's and the user's environment. In this article, we refer to the regulations on cybersecurity for medical devices for medical device manufacturers for the US and the EU market.
The goal of this article is not a comprehensive guide on cybersecurity, but rather an overview regarding certain terms and abbreviations that can be found in such guides.
FDA and EU commission both demand from medical device manufacturers to provide devices that mitigate risks to patients and users to the lowest as possible level. This includes risks that may arise from data and connections to other devices which is especially the case for software based devices and devices with connectivity to the internet or other computer networks.
Manufacturers have to analyse and manage the potential risks for the devices and the data processed, as well as the potential risks that these devices can pose to connected devices.
The most basic standard for medical device cybersecurity for USA and EU is ISO/IEC 27000:2018 - most terms in this article will refer to this standard.
Security / Cybersecurity
Security / Cybersecurity describes the level to which a device is safe against hazards from failures and manipulative attackers within its operational IT environment regarding computer and computer network technology.
State where information and systems are protected from unauthorized activities, such as access, use, disclosure, disruption, modification, or destruction to a degree that the risks related to violation of confidentiality , integrity , and availability are maintained at an acceptable level throughout the life cycle.
Actor
Any user, interface, hardware or software function that accesses the software system / device is an actor in that system and can potentially be the cause for a risk, willingly or not.
Authorization
The authorization is the collection of access rights / actions allowed to a user of a Software system. Authorization is usually managed for system users based on users, groups and roles in a user management functionality of a software application.
Authorization must also be managed when no distinct user management function is used, for instance in a firmware that has interfaces to manage configurations or data. Also the update of software needs authorization and so must be considered when designing authorization features for a software system.
Authenticity
The authenticity of an actor means, that the actor can be trusted regarding its source and the communicated content.
The method of authentication is to make sure the user that acts on the software system (actor) is really the person / interface that it claims to be, and that the response of the system to the actor is really coming from that (software) system.
The authentication mechanism must make sure that the source of the information can be truly identified as the claimed actor, and that the information is correct - which is also called data integrity.
Integrity
Integrity of data or information is given when it can be sure they have not been changed or manipulated in any way.
Integrity must not only cover the completeness of data provided by an actor in the system, but also freedom from additions (like viruses loaded with a data package) or other manipulations (exchange of contents like intrusions of executable code or different URLs).
The integrity of data and information of a medical device software is a main goal of data and system security design of the device.
Availability
Availability is the state when a resource is accessible for authorized actors on demand for the requested function.
For medical devices and IVDs, this is the provision of the intended use to the patient.
The degree of availability of a software system can be defined by its manufacturer. However, since the availability is a major safety aspect of the device, the availability is one of the main goals of data and system security design of the device.
Confidentiality
The confidentiality of the system is that information is not made available or disclosed to unauthorized individuals, entities, or processes.
This means, that the process of actor identification and authorization must be well designed and beeing carefully analysed regarding potential risks of errors with identity prove and authorization provision.
Especially undefined states of the system and error responses should be checked against hazards to the confidentiality of data.
Additionally, the system must be analysed for potential access methods for actors who willingly attend to enter the system (attackers). Penetration testing is the method to prove confidentiality of a software system as medical device, and it should be done in the intended clinical network environment (Healthcare IT network) or a simulation of such an environment.
Healthcare IT network
Healthcare IT networks are networks of computers in hospitals or any other healthcare organisation. ISO 80001-1 and related are especially covering these environments and their security requirements, but also the ISO/IEC 27000 series can be used to find process and product requirements for these special environments.
For manufacturers, it is necessary to derive requirements from these standards for their product design.
The safety of the devices should be validated for healthcare IT network conditions.
SBOM
The Software Bill of Material (SBOM) is required for every device with a software that shall become part of a healthcare IT network.
This means, every software or device with software needs a documentation about their items that can be used to identify and update or patch the respective software item by the operators of the healthcare IT network.
Since the operators of healthcare IT networks are responsible for the safety of the network, they need to be able to check if known vulnerabilities or exploits apply to devices / software they are using, in order to manage such incidents. This also means, that the manufacturer of a (device) software must publish vulnerabilities or exploits of their software to relevant organisations or databases, based on their SBOM items for identification (software name, version, manufacturer). One example of such databases is the Common Vulnerabilities and Exposures (CVE) repository https://www.cvedetails.com/ that is run by the MITRE organization.
GDPR
The GDPR is a regulation in the EU to ensure the privacy of personal data. This regulation applies to all software systems that are used in the EU member states.
That means, requirements from GDPR also apply to all medical device software, especially since health data are classified as data with a high need for protection of their confidentiality.
Manufacturers os medical device software must prove their devices and software systems they are using to store patient data are compliant with requirements of the GDPR as part of their MDR compliance. This not only applies to the device design, but also to their organizations (if they are managing patient data).
The way to ensure compliance with GDPR regarding the use of patient data is to archive the consent of each patient (device user) to the intended use of their data in the scope of the medical device (for instance an app to diagnose symptoms) and its functionality.
In the USA, there is a similar federal law that applies to the healthcare industry: it is the Health Insurance Portability and Accountability Act (HIPAA).
Consent
Consent is a term that includes a written and explicit allowance of a natural person to a software operator or data processing service company, to collect and process that person's data for a dedicated purpose. The logical part of that consent is an implicit definition of access rights for staff or service providers (actors) of that software operator on the data - independent from which interface is used to access the data.
Consent management is necessary in every software system that processes patient data.
The above terms describe computer device security aspects, and the terms of legislation in the EU for the topic.
The main goal of secure computer device operation is the protection of data and information. GSPR is the EU regulation that sets the requirements that need to be met for device security.
Cybersecurity is the state which allows evaluation how much a computer device meets the requirements for secure device operation. The other terms in this chapter describe the aspects of secure data management - base of activities to evaluate and establish cybersecurity.
Stay tuned for Part. 3 that will cover more cybersecurity risk management terms.