Cybersecurity terminology
CA
Certificate Authority. This is the organization which issues a certificate.
CEP
Component Environment Profile. This includes characteristics such as maximum impact of the component, whether the component is on the attack surface, whether there is data flow (and what data) to the component, etc.
CeQ
Our Cybersecurity-Enabled Quality System is a Medcrypt service offering.
CISA KEV
Cybersecurity & Infrastructure Security Agency Known Exploit Vulnerabilities
COTS
Commercial Off-the-Shelf Software. This is a software or hardware product that is commercially ready-made and can be bought, licensed, or rented by the general public. This is also referred to as Off-the-Shelf Software. See that definition in this table for more information.
CNA
CVE Numbering Authority, such as Microsoft.
CPE
Common Platform Enumeration.
Vulnerabilities can be identified through the use of three fields: CPE, PURL, and SWID. Helm supports CPE and PURL.
NIST defines CPE as a structured naming scheme for IT systems, software, and packages. It is based on the generic syntax for Uniform Resource Identifiers (URI) and includes a formal name format, a method for checking names against a system, and a description format for binding text and tests to a name. The CPE specification was designed for operating systems, applications, and hardware devices. It is maintained by the NVD.
CPE is recommended for use in identifying a client or server application, firmware, or operating system.
CQI
Continuous Quality Improvement
CSAF
Common Security Advisory Framework is a standard for machine-readable security advisories developed by the OASIS Open CSAF Technical Committee.
CSR
Certificate signing request
CycloneDX
This is derived from CycloneDX specification and use case information.
CycloneDX is a machine-readable SBOM format that describes the following types of components: applications, containers, devices, libraries, files, firmware, frameworks, operating systems. It also describes services. Helm supports CycloneDX.
CWE
Component Weakness Enumeration
EPSS
Model that tries to predict how often a vulnerability could be exploited in the wild.
HDO
Health Delivery Organization, such as a group of physicians working together.
HSM
Hardware Security Module. An HSM is a special 'trusted' computer performing a variety of cryptographic operations such as key management, key exchange, encryption/decryption etc.
NTIA
National Telecommunications and Information Administration
OSS
Open-Source Software. The FDA wants to make sure that you know what components are COTS or OSS. OSS and SOUP are often incorrectly used interchangeably. If you have OSS components, you will need to provide documentation to the FDA that it is either being actively maintained, or if it not being actively maintained or is EOL, you’ll need to provide information on how you are mitigating any vulnerabilities with that component.
OTS
Off-the-Shelf Software.
As the use of general-purpose computer hardware becomes more prevalent, OTS software is being used more often in medical devices. However, it may not be appropriate for a specific use in a medical device. As an MDM, you give up software lifecycle control with OTS, but are still responsible for your device to continue to operate safely and effectively.
What do I need to document?
This will differ depending on your medical device and the impact on the patient, operator, or bystander safety if the OTS software fails. You will need to do a risk analysis to determine the level of documentation detail you need to provide to the FDA and the level of lifecycle control you will need as the severity of harm from OTA software increases.
PKI
Public Key Infrastructure provides secure encrypted communications and mutual authentication between devices, services and users. Through the use of digital certificates every connected 'thing' can be bound, by the use of public keys, to entities such as people and organizations. The use of these certificates creates a chain of trust between the connected device and a certificate authority that issued the certificates.
For PKI to work, you need a randomly generated cryptographic key pair to be generated for every single device manufactured. The key pair must be provisioned into the Root of Trust (RoT) of the microcontroller. The private key must be protected by the hardware RoT and the public part is held in a certificate, both of which are provisioned during manufacturing. The certificate will be signed by a certificate authority, thus providing a means of authentication for the identity.
Thus, the identity is not a unique ID or a Universal Unique Identifier (UUID), but the way in which the device or other component is identified by a randomly generated key pair. The public part of the key pair is provided in the form of a certificate which has been signed (authenticated) by a trusted certificate authority. The private part of the key pair is used to prove the identity.
PURL
Vulnerabilities can be identified through the use of three fields: CPE, PURL, and SWID. Helm supports CPE and PURL.
Package URL (PURL) standardizes how software package metadata is represented so that packages can universally be located regardless of what vendor, project, or ecosystem the packages belongs to. A PURL is an attempt to standardize existing approaches to reliably identify and locate software packages. It is a URL string used to identify and locate a software package in a mostly universal and uniform way across programming languages, package managers, packaging conventions, tools, APIs and databases.
QMS
Quality Management System. This is a structured system that documents processes, procedures, and responsibilities for continuously delivering high-quality products and services that meet regulatory and customer requirements. Its objective is to provide a framework that improves communication, collaboration, and consistency across your company, while also reducing waste and promoting a culture of continuous improvement.
QSR
Quality System Regulations
RA
Registration Authority
RDP
Remote Desktop Protocol. Allows users to remotely connect to and control another computer or device.
RoT
Root of Trust
SBOM
Software Bill of Materials. This encompasses all components that exist across your software supply chain, including components, licenses, copyrights, and security references.
SMB
Server Message Block is Windows computers in file, port, and printer sharing and other network services. If these protocols are not properly secured, an attacker could potentially gain access to a network and cause significant damage.
SOUP
Software of Unknown (or Uncertain) Pedigree (or Provenance) is a term often used in the context of safety-critical and safety-involved systems such as medical software. SOUP is software that has not been developed with a known software development process or methodology, or which has unknown or no safety-related properties.
SPDX
Software Package Data Exchange. SPDX is an international open standard from Linux enabling communication of SBOM information, including provenance, license, security, and other related information. It provides a machine-readable SBOM, as well as a human-readable one enabling you to share important data about your software ecosystem and improve transparency and cybersecurity risk mitigation.
SPDX is recognized as the international open standard for security, license compliance, and other software supply chain artifacts as ISO/IEC 5962:2021.
Helm does not currently support SPDX, though it is currently in design.
SSVC
This vulnerability analysis methodology accounts for a vulnerability’s exploitation status, impacts to safety, and prevalence of the affected product in a singular system.
CISA uses its own SSVC decision tree to prioritize relevant vulnerabilities into four possible decisions:
Track: Vulnerability does not require action at this time. Continue to track the vulnerability and reassess if new information becomes available. CISA recommends remediating these vulnerabilities within standard update timelines.
Track*: Vulnerability contains specific characteristics that may require closer monitoring for changes. CISA recommends remediating these vulnerabilities within standard update timelines.
Attend: Vulnerability requires attention from your internal supervisors, including requesting assistance or information about the vulnerability. This may involve publishing an internal or external notification. CISA recommends remediating these vulnerabilities sooner than standard update timelines.
Act: Vulnerability requires attention from internal supervisors and leaders, including requesting assistance or information about the vulnerability. This may involve publishing an internal or external notification. CISA recommends remediating these vulnerabilities as soon as possible.
These decisions are based on the following values: exploitation status, technical impact, automatable, mission prevalence, and public well-being impact.
SWID
Vulnerabilities can be identified through the use of three fields: CPE, PURL, and SWID. Helm supports CPE and PURL Helm does not currently support SWID.
SWID is recommended to be used for a container (as is PURL, which we do support), firmware (as is CPE, which we do support), library or framework (non-package), operating system (as is CPE), and operating system package (as is PURL).
TQM
Total Quality Management. This focuses on quality throughout your company, from design to customer satisfaction.
UUID
Universally Unique ID that is readable from most microcontrollers available today. This is not an identity, only an identifier. See PKI definition for more information.
V&V
VEX
Vulnerability Exploitability eXchange. This is the security advisory that a supplier will communicate regarding their analysis on a particular vulnerability as it relates to their software. Suppliers’ customers, such as hospitals, need to know whether this vulnerability is impacting the use of the device or not. Helm does not use VEX status conventions, but it is currently in design.
A VEX provides additional information on whether a product is impacted by a specific vulnerability in a dependency. If so, recommends actions to remediate. For example, a vulnerability in an upstream dependency is likely not exploitable in the final product for reasons including the affected code not being loaded by the computer or inline protections existing elsewhere in the software. Dependency suppliers issue a VEX to assert the status of a vulnerability in specific products. These statuses are:
Not affected: No remediation is required for this vulnerability
Affected: Actions are recommended to remediate or address this vulnerability.
Fixed: These product versions contain a fix for the vulnerability.
Under investigation: It is not yet known whether these product versions are affected by this vulnerability. An update will be provided in a future release.
VEXes are machine-readable, so users can integrate dependency data from SBOMs with vulnerability status information from VEXes to provide a current view of vulnerability status. This enables users to take a much more targeted approach to finding and remediating vulnerabilities in their software.
A VEX can cover more than one vulnerability in a product or across multiple products.
These are defined by CSAF, and can provide information such as remediation, workarounds, restart/downtime required, scores, and risks provided from vendors, system integrators, and operators.
VLCDB
Vulnerability Lifecycle Database
Last updated