With the rapid proliferation of IoT technologies, security concerns have increased due to the opaque nature of supply chains. Operators often lack comprehensive knowledge about the security status of their devices. The DOSS framework addresses this gap by providing a system that facilitates transparency, reliability, and timely security information exchange among stakeholders of the IoT supply chain, including manufacturers, vendors, and integrators.
DOSS integrates various security modules, including a component tester, a digital cybersecurity twin, and an architecture security validator. These modules work together to test software and hardware, identify vulnerabilities, and ensure compliance with security standards.
The Device Security Passport (DSP) is a key component of the DOSS architecture. It serves as a machine-readable document and consolidates all available security related information of an IoT component, providing a structured and easily accessible format for all relevant parties. It comprises a number of the already available, but dispersed documents like SBOM, HBOM, MUD file, VEX/VDR documents, as well as includes extended or completely new elements defined by the DOSS project. The DSP is based on the Open Security Controls Assessment Language (OSCAL), ensuring an actionable and standardized format for device security data.
DSPs are created by manufacturers and exist in three primary forms:
- Generic DSP (genDSP) – Contains manufacturer-related information, security posture, product composition, and operational details. It follows established standards, is signed for authenticity, and is stored in the DSP Platform (DSPP). Some sections are publicly available, while other parts of the document require authorization.
- Instance Level 1 DSP (IDSP1) – Provides specific instance-level information about a product, such as unique identifiers and public keys. IDSP1 records are linked to genDSP files but do not duplicate their content.
- Instance Level 2 DSP (IDSP2) – Extends IDSP1 with additional operation-related and proprietary information added by system integrators and operators. IDSP2 is stored locally by the operators.
The DSP framework encompasses three key phases in the device lifecycle:
- Device Manufacturing
- The manufacturer generates a genDSP containing essential security information such as SBOM, HBOM, VEX, and a MUD file.
- The Component Tester (CT) tool analyzes vulnerabilities and generates reports that are referenced in the genDSP.
- An IDSP1 is created for each device instance, linked to the genDSP and incorporating unique identifiers.
- Device Integration
- Integrators register with manufacturers to gain authorized access to IDSP1.
- They may update or add new security information, generate new SBOMs or VEX/VDR documents, and create an IDSP2 reflecting these modifications.
- The Digital Cybersecurity Twin (DCT) and Architecture Security Validator (ASV), using the IDSP2 as input, assess the cybersecurity posture of a planned architecture and report potential vulnerabilities.
- If new vulnerabilities are identified reports are generated and manufacturers can take the necessary actions and update genDSP accordingly.
- Device Operation
- The Onboarding Platform (ObP) authenticates and securely configures devices using information from the DSP.
- Security modules monitor device behaviour and detect irregularities, feeding this data back into the DSP.
- Operators can update IDSP2 with new configurations or security findings, ensuring continuous security assessment and mitigation.
Figure 1 – The DSP framework
Key Security Components Integrated in the DSP
The DSP, based on the OSCAL framework (Open Security Controls Assessment Language), incorporates multiple standardized security descriptors:
- Software Bill of Materials (SBOM) – A detailed inventory of software components, enhancing transparency and security assessment.
- Hardware Bill of Materials (HBOM) – Lists all physical components, aiding supply chain management and risk assessment.
- Cryptography Bill of Materials (CBOM) – Identifies cryptographic assets like algorithms and keys, ensuring compliance and security.
- Manufacturer Usage Description (MUD) – Specifies expected network behaviour to mitigate IoT threats.
- Threat Manufacturer Usage Description (Threat MUD) – Provides real-time threat intelligence and mitigation policies.
- Vulnerability Exploitability eXchange (VEX) and Vulnerability Disclosure Reports (VDR) – Provide insights into vulnerabilities and their exploitability, aiding in proactive security management.
Security and Integrity of DSP
Given its sensitive nature, DSP files must be digitally signed to ensure authenticity and prevent tampering. Signatures are verified before processing, and updates are meticulously logged. Each DSP owner (e.g., manufacturer or integrator) is responsible for maintaining and securing the document.
The Device Security Passport (DSP) is a pivotal innovation in IoT security, offering an automated, structured, and transparent approach to security information sharing across the supply chain. By integrating multiple security standards and assessment tools, DSP enhances the ability of stakeholders to manage risks, maintain resilient IoT ecosystems and enforce compliance with the Cyber Resilience Act’s documentation standards, including the requirement for SBOMs.
