OT & IoT Cybersecurity Report 2024
This whitepaper targets product owners, product security managers and compliance professionals of manufacturers worldwide who need to understand and to achieve an effective & efficient SBOM management to comply with international regulations.
EXECUTIVE SUMMARY
Industrial control systems, known as Operational Technology (OT), along with the Internet of Things (IoT) and Industrial IoT (IIoT), form the digital backbone of Industry 4.0. Today’s production,logistics, and operational processes are virtually unimaginable without OT and IoT. Connected devices, machines, and systems that continuously exchange dataare at the heart of modern industry.
However, this growing connectivity and digitalization also brings new challenges: robust cybersecurity measures are essential, as IoT, IIoT, and OT systems often need to meet high security requirements despite vulnerable software. In 2024, the cybersecurity company ONEKEY surveyed over 300 IT decision-makers and C-level executives about their perspectives and strategies in cybersecurity. The findings from this comprehensive survey are presented in the OT & IoT Cybersecurity Report 2024.
Growing Awareness of Cyber Threats: Nearly 75% of companies recognize that hackers are increasingly targeting industrial control systems and IoT devices.
Insufficient Protective Measures: Many companies lack adequate defenses against cyberattacks, with gaps in realistic risk assessment, effective prevention strategies, and actionable response capabilities.
Compliance Knowledge Gaps: Numerous companies are insufficiently informed about relevant compliance requirements, with nearly half unaware of technical cybersecurity standards.
Outdated Firmware as a Vulnerability: Outdated firmware in devices and machines is increasingly exploited by hackers as an entry point. Attacks on unprotected firmware can be devastating, potentially halting entire production batches.
Lack of Software Bill Of Materials(SBOM): Over half of companies lack complete SBOMs, even though they are essential for effective cybersecurity.
Budget Constraints: 60% of companies rate their cybersecurity budget as inadequate oruncertain, with only 34% considering it “sufficient” or “significant.”
Insufficient Cybersecurity Processes: Only about a quarter of companies rate the maturity of their cybersecurity processes as adequate, with many lacking measures to enhance security practices and meet compliance requirements.
UNDERESTIMATED RISK: OT AND IOT
The study clearly shows that cybersecurity in OT and IoT poses significant risks, yet many companies are still under prepared. More than half of respondents (52%) have already experienced cyberattacks through OT or IoT devices, with just as many suspecting that cybercriminals are specifically targeting these devices as entry points. Nonetheless, OT and IoT cybersecurity is often considered less critical.
"With over 2,000 new software vulnerabilities identified each month, companies that fail to keep their software updated aren't asking if they'll be targeted by cyberattacks, but when— and how severe the consequences will be." Jan Wendenburg, CEO ONEKEY
Instead, many companies are focusing more on protecting payment and financial systems (42%), corporate networks and datacenters (39%), as well as customer data (36%). Email, cloud services, and appsare also perceived as greater threats, while the risks to OT (OperationalTechnology) and IoT (Internet of Things) are often underestimated.
As digitalization advances at the production and logistics level in German industry, a growing number of security gaps are emerging — creating new points of attack for cybercriminals.
CYBER RESILIENCE: A REALISTIC SELF-ASSESSMENT
Over a quarter (26%) of companies consider their cybersecurity maturity in product and project development to be 'adequate,' thanks to a defined and active security process. An additional 12% have security processes in place but deem their control measures insufficient. Meanwhile, 9% of companies report having no such processes at all.
Companies focus on a variety of measures to enhance their cyber resilience: 36% conduct threat analyses, 23% use penetration testing, 22% rely on intrusion detection systems, and 15% focus onvulnerability assessments. Network segmentation to limit the impact of attacks is implemented by 19% of companies. Notably, 38% of companies consider the security guarantees of their IT service providers and suppliers to be the 'most important' measure.
Regarding budget allocation, one-third of respondents consider the funds for defending against cyberattacks to be 'limited' and see room for improvement. In 27% of companies, the cybersecurity budget situation is unclear. Only 34% have an 'adequate' or 'significant' budget to strengthen their cyber resilience.
"Many companies appear to prioritize cybersecurity only after an incident has already taken place." Jan Wendenburg, CEO ONEKEY
Less than a third (32%) of the companies surveyed in the study have implemented procedures to learn from security incidents and make necessary improvements. Given the ongoing threat landscape, predefined business processes that govern how to handle cyberattacks both during and after an incident should be part of every company’s security repertoire.
On a positive note, a good third (34%) of companies conduct a thorough analysis and assessment of a security incident following a cyberattack, in order to derive concrete improvement measures.
LACK OF KNOWLEDGE OF LEGAL CYBERSECURITY REQUIREMENTS
Starting in 2026/2027, the EU Cyber Resilience Act (CRA) will require all manufacturers of devices, machinery, andequipment selling products in the EU to meet enhanced cybersecurity requirements. However, the study reveals that many companies are not yet adequately prepared for this. Only 28% of the surveyed companies have specific compliance regulations for the security of industrial control systems or IIoT devices. For a third (34%), OT or IoT security regulations are part of the company's general cybersecurity policies but are not specifically addressed. Alarmingly, 19% of companies have made no special provisions in this area. One-fifth of respondents were either unable or unwilling to provide information, indicating significant uncertainty and a high level of unknowns.
Less than a third (29%) of respondents report being familiar with the regulations and cybersecurity standards relevant to their industry. About a third (34%) have limited knowledge, while 25% have no knowledge at all. Given typical development times of two to three years, companies that do not act in time risk being unable to sell their products in the EU starting in 2027 if they have not met the requirements by then.
Additionally, 46% of the surveyed companies were unable to specify which cybersecurity standards are relevant to their product development. The importance of these standards is often under estimated: only 23% consider the EU Cyber Resilience Act (CRA) to be relevant. Other standards, such as IEC62443 (20%), EN 303 645 (16%), EN 21434 (14%), and UNR155 (8%), are also seen as important by only a minority. This highlights the significant information gap regarding compliance.
INADEQUATE SECURITY TESTING AND PATCH MANAGEMENT FOR IOT DEVICES
When procuring IoT devices, only 29% of industrial companies conduct thorough security tests. 30% limit themselves to superficial tests or sampling, while 15% perform no security checks at all. There maining companies did not provide any information on this matter.
A similar pattern emerges when analyzing device firmware: less than a third (31%) of companies conduct regular security tests to identify vulnerabilities in the embedded software. 47% test the firmware only occasionally or not at all, and 22% did not provide any information on this matter.
"Anyone who delays applying a patch exposes themselves to significant risk, as cybercriminals specifically exploitthe time window between discovery and resolution." Jan Wendenburg, CEO ONEKEY
Regarding software updates, 33% of companies update their devices immediately after a patch becomes available. In contrast, 31% wait until the next scheduled release, while 10% provide no further updates after delivery. An additional 26% of respondents are unsure about their devices' update policies.
When asked if the cybersecurity of already deployed devices is checked, 28% of companies respond that they do so automatically. 30% conduct occasional manual checks, while 17% perform nofollow-up security assessments. However, waiting for scheduled updates poses significant risks, as cybercriminals often exploit the time window between discovery and resolution.
SBOM: IMPLEMENTATION STILL LACKING
According to the survey, fewer than a quarter (24%) of industrial companies maintain a complete Software Bill Of Materials (SBOM). While software for computers and networks is usually documented, many companies lack an overview of the software in devices, machinery, and equipment. This is problematic, as outdated software in controlsystems is a common entry point for hackers. Typical examples include manufacturing robots, CNC machines, and building automation systems. These systems are connected to the company network, creating a significant attack surface. However, the majority of companies either have no SBOM or only an incomplete one.
TRAINING AND AUDITS: ESSENTIAL FOR STRONG CYBERSECURITY AWARENESS
A positive trend is emerging, but there is still significant room for improvement. 40% of industrial companies offer their employees regular cybersecurity training and workshops. 27% have integrated cybersecurity rules into their employee handbooks and company policies.
Additionally, 62% of the surveyed companies conduct regular cybersecurity audits. 24% rely on external assessments, 18% on internal audits, and 20% use a combination of both approaches. However, formore than a third of companies, it is unclear whether and to what extent regular cybersecurity reviews are conducted.
BACKGROUND
NEW EUROPEAN CYBER RESILIENCE ACT (CRA) AIMS AT INCREASING SECURITY LEVEL AND TRANSPARENCY
On September 15, 2022, the European Union Agency for Cybersecurity (ENISA) published the draft of the new Cyber Resilience Act (CRA), which came into force on December 10, 2024, following adjustments and approval by the EU. The CRA applies throughout the European Union and worldwide to all manufacturers, importers and distributors of products with digital elements that market their products in the EU.
The CRA aims at increasing the level of security of all products with digital elements within the European Union by requiring manufacturers to implement and maintain a cybersecurity framework and to follow this framework throughout the product’s lifecycle. Additionally, enhanced transparency about security properties will enable consumers and businesses to take security-conscious decisions and use products with digital elements more securely.
LIMITED TIME TO ACT FOR PRODUCTS WITH DIGITAL ELEMENTS
This initiative by the ENISA follows increasing damage caused by cybercrime, which resulted in global costs of more than EUR 5.5 trillion in 2021 . Many of these cyberattacks are caused by vulnerabilities in products with digital elements and aggravated by lack of transparency by manufacturers about relevant security properties. While the CRA targets a broad scope of “products with digital elements”, ranging from operating systems, desktop and mobile applications to hardware devices and network equipment, this whitepaper will focus on connected devices and target manufacturers, distributors, and importers of such devices.
The CRA was adopted by the European Commission as a European Directive in 2024 and came into force on December 10, 2024. This leaves little time – even with the transition period until December 10, 2026 – to adopt the necessary reporting requirements and fulfill the remaining fundamental requirements.Due to multi-year design & development cycles, all manufacturer need to act now. Only devices regulated by Regulation (EU) 2018/1139 (civil aviation), Regulation (EU) 2017/745 (medical devices), Regulation
(EU) 2017/746 (in vitro diagnostic medical devices), or devices certified in accordance with Regulation (EU) 2019/2144 (type-approval motor vehicles and their trailers, and systems, components and separate technical units intended for such vehicles...) are exempt
from the CRA. With the average multi-year timespan between design and production of connected devices this leaves little time
for adoption and applying necessary security changes.
UNDERSTANDING SBOM CONTENT AND RELATED CHALLENGES
NTIA'S MINIMUM REQUIREMENT FOR SBOMS
The National Telecommunications and Information Administration (NTIA) in the United States has made significant contributions to the understanding of SBOMs. According to the NTIA, the primary purpose of an SBOM is to identify components and their relationships uniquely and unambiguously3. For this purpose, the minimum required data elements4 include the supplier, component name, component version, other unique identifiers, depend- ency relationships, author of SBOM data, and timestamp5. In addition to these minimum elements, an SBOM may also include additional data elements, such as SPDX license short ID and/or license text, depending on the specific needs and preferences of the stakeholders involved.
IDENTIFIERS ARE BENEFICIAL FOR EFFECTIVE VULNERABILITY SEARCHES
One crucial application of Software Bill of Materials (SBOMs) is the identification of vulnerabilities from databases. To enable efficient vulnerability searches, it is beneficial for an SBOM to incorporate identifiers that correspond to components within those databases. For instance, the United States‘ National Vulnerability Database (NVD) employs Common Platform Enumerations (CPEs) as identifiers6. Initially, CPEs were assigned to components when vulnerabilities were first reported, which posed challenges for setting up proactive automated searches. Howev- er, one possible solution is for library and device maintainers to pre-register a CPE.7 Nonetheless, it is anticipated that NVD might phase out CPEs in favor of Software IDentification (SWID) tags.8
A recommended approach is to locally generate a SWID and derive a CPE9 from it, incorporating both as unique identifiers
in SBOMs shared with customers. Subsequently, the CPE name, SWID, or both can be registered in the NVD or any other relevant vulnerability database as required. However, the NTIA recognizes the impracticality of establishing a global naming scheme and suggests that software and device maintainers define and con- sistently employ unambiguous supplier, component, and version names. Ideally, these names should be supplemented with hash- es, UUIDs, or other unique identifiers.
In cases where the original supplier of a component has not provided their preferred component names in an SBOM, down- stream integrators are allowed to make an educated guess and document this fact using the „Author of SBOM Data“ element.
In the following sections, we will delve deeper into the main SBOM standards, discuss how IoT/OT vendors can generate and share SBOMs, and explore how stakeholders in the IoT/OT supply chain can effectively utilize SBOMs to reduce cyber risks for IoT/ OT operators.
FOUR POTENTIAL SOURCES FOR INFORMATION
Streamlining SBOM Generation in CI/CD Pipelines: Automation and Information Sources
Automating the generation of Software Bills of Materials (SBOMs) in continuous integration/continuous deployment (CI/ CD) pipelines is crucial. There are four potential sources of information for SBOM generation, each with its own tools and advantages.
- Package managers: Commonly used package managers such as pip, Maven, npm, and Cargo can list dependencies and provide valuable information for generating an SBOM. Even in embedded C/C++ environments where package management is less com- mon, build systems like Cmake or utilities such as Zephyr pro- ject‘s West can be leveraged.
- Source code scanning: Source code analysis tools and scripting can efficiently identify dependencies, linked libraries, and embedded code. Commercial source code analysis (SCA) tools can also detect copy-pasted code snippets. While this approach requires initial setup and ongoing maintenance, it is highly effective and easily automated in CI/CD pipelines.
- Binary analysis: Binaries can be analyzed to extract SBOM information when source code is not available. Reverse-engineer- ing tools can extract symbol names and strings from ELF files and object files but resolving them into component identities
is challenging. Specialized analysis approaches are needed for different types of executable files, microcontroller and Linux disk images, patch files, packages, and over-the-air update wrappers. - SBOM documentation from the supply chain: SBOMs can be generated by each participant in the supply chain, utilizing original metadata, sources, and upstream SBOM documentation. Sharing SBOMs downstream can provide a completer and more accurate device SBOM, overcoming limitations in single-source visibility. However, the practice of comprehensive SBOM documentation is still evolving, and it is common for projects to lack SBOMs for all imported components.
Automating the generation and sharing of SBOMs requires investment in time and effort, but the availability of tooling has made the process easier. The level of effort scales with the project size and complexity. Smaller IoT library developers can add a command to their release script, while larger embedded projects may require several engineer-months of detective work, consolidation of information sources, transformation into a standard format, and automation. The positive benefits of automating SBOM generation justify the effort in both cases.
CONCERNS REGARDING SECURITY INFO IN SBOMS?
Sharing SBOMs: Advantages for Defenders Outweighing Security Concerns
Sharing SBOMs downstream should be automated and done consistently using a small number of recommended methods10 for different types of components.
Concerns may arise regarding the security sensitivity of SBOMs, especially for binaries and device images. Could access to a device SBOM assist attackers in identifying imported vulnerabili- ties, exploiting them, or planning supply chain attacks?
While transparency does present some risks, it is crucial to understand that SBOMs primarily benefit defenders rather than attackers. Attackers do not necessarily require an SBOM to find vulnerabilities; they often target unpatched vulnerabilities they are already aware of. Defenders, on the other hand, can leverage SBOMs as a systematic defense against software supply chain risks. Even organizations that distribute SBOMs only to their customers do not view disclosure as a disaster and do not seek to further secure them.
In summary, sharing SBOMs provides significant advantages for defenders in addressing software supply chain risks, and con- cerns about attackers leveraging SBOMs are outweighed by the benefits they bring to defense efforts.
THE TWO LEADING SBOM STANDARD FORMATS
Standardizing SBOMs: CycloneDX and SPDX
To facilitate sharing and encourage the development of inter- operable tools and services, the adoption of SBOM (Software Bill of Materials) standards is essential. Embracing one of these standards simplifies the generation, utilization, and sharing of SBOMs while reducing costs. A comprehensive review of current standards has been published by the NTIA 11.
The two leading standards in this field are CycloneDX and the Software Product Data Exchange (SPDX). CycloneDX originat- ed in the OWASP information security community, while SPDX emerged from the OSS community. Although SWID tags have also been considered, their primary use case is to provide unique and unambiguous identifiers for software components.
The original purpose of SPDX is to ensure license compliance. It is maintained by a working group within the Linux Founda- tion. The initial draft was introduced in 2010, and the current specification is freely available as the ISO/IEC standard ISO/ IEC 5962:2021 12. Ongoing development progress can be tracked through the group‘s public GitHub repository.
CycloneDX, on the other hand, was initially developed to address vulnerability identification, license compliance, and outdated component analysis. It follows an open governance model. The first draft specification was introduced in 2017, and the standard has now reached version 1.4. Both standards have undergone extensive use, resulting in their maturity. They boast active communities and are continuously being developed.
RICH SBOMS ARE THE BEST
They strive to support all SBOM use cases and enjoy broad support from various compatible tools. Many tools even offer support for both standards. However, neither of them provides specific advantages for embedded projects.
SBOM Completeness: Challenges and Considerations
The usefulness of an SBOM (Software Bill of Materials) increases with its accuracy, level of detail, and completeness. However, it is important to acknowledge that SBOMs are rarely able to achieve all these attributes, and objectively measuring their quality can be challenging.
An internal effort to generate an SBOM may provide some metrics, such as the fraction of attributed code artifacts or the number of identified components with detected incompatible licenses. However, these metrics may overlook significant sets of components, including „unknown unknowns“ that have not been considered yet.
Even non-embedded software projects face difficulties in identifying and documenting software components of various types and layers, such as binaries, source code, package-managed and non-package-managed components, containerized applications, static and dynamic libraries.
IOT DEVICES HAVE ADDITIONAL CHALLENGES
IoT devices present additional challenges, as they encompass the entire stack from bare metal boot and often include deep- ly embedded firmware in network interface controllers (NICs), secure elements, and other integrated circuits. Creating a de- liberate and meticulous inventory of opaque and „hidden“ soft- ware components is the only way to transform them into „known unknowns.“
When an upstream supplier provides an SBOM to downstream consumers, there is no easy way to ensure that it meets their standards. Currently, no standard or certification scheme exists for this purpose. Some consumers generate and analyze SBOMs themselves using their own Software Composition Anal- ysis (SCA) tools, which can motivate suppliers to improve their SBOMs. However, consumers still rely on suppliers for interpretation, and for many, the effort required may not be justifiable.
Ultimately, it is important to remember that even an incomplete SBOM is better than having no SBOM at all. While the use of SBOMs can significantly reduce compliance issues and known vulnerabilities, it is unlikely to eliminate them.
STRENGTHENING SOFTWARE SUPPLY CHAIN SECURITY AND COMPLIANCE
FAILED COMPLIANCE TO OPEN-SOURCE LICENSES EXPOSE RISK OF LEGAL ACTION
Streamlining Open-Source Software License Compliance in IoT/OT
The embedded software of an IoT device is often com- posed of complex but essentially standard functions, which can account for up to 90% of its codebase. However, the cost involved in developing and maintaining such a software stack is often beyond the means of most embedded product manufac- turers. As a result, original equipment manufacturers (OEMs) acquire this software from library and operating system vendors, as well as open-source software (OSS) projects. Consequently, the majority of IoT devices incorporate a significant amount of third-party software, the copyright of which remains with its creators. Users and operators of these devices can only use this software within the boundaries set by the copyright holders‘ licensing agreements. While licenses can specify any terms chosen by the copyright holder, most open-source software projects employ standardized license forms to simplify compliance.
Failure to comply with the terms of these licenses exposes users and operators of IoT devices to the risk of legal action by the copyright holders. While most cases related to OSS are resolved amicably, situations involving commercial software, breakdowns in goodwill, or copyright trolling scenarios.13 can lead to substantial financial consequences and operational disruptions. Driven by a few prominent litigation cases, many organizations have adopted SBOMs with the aim of reducing license compliance risks. Interestingly, it is often the General Counsel rather than the CTO or CISO who has spearheaded this initiative.
OPEN CHAIN RECOMEDED FOR OWN OSS LICENSE PROGRAMS
During procurement, operators have started demanding evidence of full license compliance from suppliers. In response, sup- pliers have partially addressed this demand by providing SBOMs that list software components and their respective licenses. However, operators have no guarantee of the completeness
and accuracy of such SBOMs, prompting them to seek indemnification against copyright claims. While indemnification is not a concept that General Counsels are comfortable with, over time, legal teams at software vendors have found a middle ground with engineering teams. If the inventory of OSS software is comprehensive and well-maintained, and engineers are vigilant in identifying unusual licenses for review, General Counsels can be assured regardless of the number of OSS components involved. For IoT/OT vendors in need of their own OSS license compliance program, implementing the OpenChain standard (ISO/IEC 5230)14 is recommended. This standard has been developed as a community service by pioneers in such programs. Like SPDX, it is a freely available ISO standard that is widely embraced by engineering departments, corporate legal teams, and the OSS community due to its simplicity and proven effectiveness.
VEX HELPS ON EXPLOITABILITY EVALUATION
Enhancing Vulnerability Management in IoT/OT Supply Chains
IoT/OT faces an increasing risk of cyberattacks, with unpatched software vulnerabilities posing a significant threat. In the broader IT landscape, these vulnerabilities are known to contribute to one in three information security breaches 15 16. Consequently, reducing the time between vulnerability discovery and implementing mitigations has become a crucial goal for the entire IoT/OT supply chain.
While tools and best practices are emerging, establishing an effective vulnerability management program remains challenging. Despite vulnerabilities being typically announced alongside patches or mitigations, IT organizations take an average of 60 to 200 days to apply these patches. Factors contributing to this delay include a lack of situational awareness, resulting in over- looked vulnerabilities, and overwhelming SecOps teams when improved awareness reveals numerous vulnerabilities.
However, IoT/OT suppliers committed to securing their products aim to avoid the risks associated with unpatched vulnerabilities. In the realm of vulnerability management, the National Telecom- munications and Information Administration (NTIA) is developing the Vulnerability Exploitability eXchange (VEX see 17 ). VEX com- plements Software Bill of Materials (SBOMs) and allows device manufacturers to communicate the exploitability of vulnerabil- ities discovered in their software components. By using VEX, organizations can determine if a vulnerability listed in an SBOM affects their products without the need for extensive investigation.
VEX enables OEMs to assess whether vulnerabilities in the components they use are exploitable in the product. Factors such as code execution, conditional compile statements, and existing security controls determine if a vulnerability poses a risk. This knowledge saves developers time by focusing on addressing vul- nerabilities that pose a genuine threat, rather than unnecessary fixes.
VEX ALONE DOES NOT MAKE THE (EXPLOITABILITY) STORY
While VEX provides valuable insights, it is recommended to combine it with context-based analysis to further mitigate supply chain risks. Advanced context-based analysis encompasses hard- ware architecture, OS configurations, encryption mechanisms, control flow, and API calls, providing a comprehensive understanding of a product‘s vulnerabilities.
To enhance transparency and visibility, the NTIA suggests ex- panding SBOM use cases and encourages organizations to request additional data fields, such as component hash, lifecycle phase, relationships, and license information.
It also emphasizes the need to create and maintain SBOMs for cloud-based software and SaaS, ensure integrity and authentic- ity through mechanisms like digital signatures, link to external vulnerability data sources, assess vulnerabilities and exploita- bility in dependencies using VEX, employ binary analysis tools for legacy software, and maintain implementation flexibility and uniformity.
By combining automated tools like VEX, comprehensive SBOMs, and context-aware vulnerability analysis, organizations can effi- ciently manage supply chain vulnerabilities and strengthen their overall security posture.
SBOMS AS A TO-LIST
Ensuring Supply Chain Security in IoT/OT Environments
Managing supply chain risks often involves suppliers demonstrat- ing compliance with specific policies. This includes rules of ori- gin, secure software development standards, and maintenance commitments. Ideally, software suppliers would self-report their performance on supply chain security compliance using widely accepted metrics, optionally certified by independent third par- ties. However, organizations currently need to conduct their own research and map results into their own metrics, using an SBOM as a to-do list. IoT/OT software suppliers aim to deliver high-quality software to satisfy customers, boost sales, reduce support costs, and fo- cus on new product development. However, ensuring consistent quality and security from upstream developers is challenging, as many do not have formal requirements.
After implementing internal policies, imported components should be brought up to the same compliance level. Full com- pliance may take time, but an SBOM can serve as a to-do list to record compliance plans and progress. Collaboration is rec- ommended for small open-source software (OSS) components, either by forking them and integrating compliance within the product or by contributing improvements upstream.
Informal OSS components may struggle with maintenance commitments, but recent activity and defect handling can be used to extrapolate maintenance expectations or explore maintenance contracts. Balancing OSS and software supply chain security is an evolving practice requiring further details to be worked out.
When implementing supply chain security programs, IoT/OT device original equipment manufacturers (OEMs) should consid- er multiple factors, such as device design, manufacturing, pro- visioning processes, and the software supply chain. Conversely, operators must be conscious that working with suppliers who have not made adequate investments in quality and security exposes them to increased vulnerabilities.
PRIORITIZE YOUR SBOM PROJECT ACCORDING TO YOUR PRODUCT CRITICALITY
The urgency of evaluating supply chain security during the procurement process depends on the criticality of the applications involved. To initiate this assessment, it is advisable for operators to inquire about the supply chain, including the software sup- ply chain, from OEM suppliers using a Software Bill of Materials (SBOM). Additionally, it is important to ensure the integrity and quality of assets. While a comprehensive standard for IoT/ OT OEM certification does not currently exist, operators should establish their own criteria based on different aspects, such as device resilience against attacks, software asset integrity, confidentiality of device secrets, and controls over certificate chains of trust. When addressing security requirements in the software supply chain, it is advisable to articulate them in terms of measurable outcomes, like other requirements. Since the exact number of exploitable vulnerabilities cannot be determined, it is useful to rely on proxy measures such as code quality metrics, mean time to response, and adherence to best practices. For IoT/OT operators, it is important to choose or create a specific set of metrics that align with their needs, like the approach adopted by the US federal government through EO 14028.
An outlook to CSAF
Integrating the Cybersecurity Assurance Framework (CSAF) into supply chain security efforts adds an additional layer of robust- ness. CSAF provides a structured approach for assessing and enhancing cybersecurity practices across the supply chain. By leveraging CSAF, organizations can establish clear benchmarks for compliance and performance, facilitating smoother collabo- ration with suppliers.
This framework offers standardized language for discussing cybersecurity measures and ensures a more comprehensive evaluation of security posture. Implementing CSAF alongside SBOMs and other metrics can significantly strengthen the overall security posture of IoT/OT environments.
Moving forward, organizations should explore the synergies between CSAF and existing supply chain securi- ty strategies to establish a more resilient and secure ecosystem.
KEY TAKEAWAYS TO ACHIEVE EFFECTIVE & EFFICIENT SBOM MANAGEMENT:
- Centralize SBOM Management - Achieve comprehensive insight into your supply chain, third-party software, and in- house code throughout all components, products, and divi- sions.
- Simplify Compliance Procedures - Swiftly create, verify, and generate reports to effortlessly adhere to industry stand- ards, such as those set by the FDA, ISO, and other entities.
- Incorporate SBOM Creation into Current Workflows - Integrate smoothly with your existing systems like PLM, CI/CD, and software update mechanisms, while supporting all SBOM and VEX formats, including CycloneDX and SPDX, with capa- bilities for import and export.
- Go Beyond Basic SBOMs - Reveal all related risks extending beyond mere SBOMs, encompassing HW BOM, cryptography, passwords, PII, OS configurations, and more.
- Prioritize Security Research Over SBOM Verification - Avoid the expensive and labor-intensive process of manual audits, enabling you to allocate your time effectively towards mini- mizing risk and addressing crucial vulnerabilities.
- Be Audit-Ready - Ensure SBOMs are prepared for compliance and can be swiftly shared or exported, allowing you to concentrate on securing future endeavors.
Are you interested in further discussion with our security experts on how to achieve product cybersecurity compliance through effective and efficient SBOM management?
Please contact our security experts at: experts@onekey.com
AUTOMATION & SUPPORT TO ACHIEVE & MAINTAIN CRA SECURITY REQUIREMENTS & COMPLIANCE
ONEKEY’S SECURITY EXPERTS’ ADVICE & AUTOMATION
In addition to reducing manual efforts by adding automated controls to processes required by the CRA, ONEKEY aids manufacturers, importers, and distributors of products with digital elements in adopting processes required by the CRA with gap analyses and implementation support.
ONEKEY‘s automated firmware security analysis platform can automatically detect and report violations of essential cybersecurity requirements as defined in Section 1 of Annex I of the CRA. Expanding on ONEKEY’s automated capabilities, ONEKEY’s technical experts and security researchers are also available to identify gaps to a product’s adherence to the CRA and to conduct penetration tests and vulnerability assessments on affected connected devices.
KEY TAKE AWAYS
Manufacturers need to act now to ensure product compliance:
- With attacks on connected devices on the rise, ENISA has defined essential requirements to increase the level of security of connected devices and established a framework to foster cooperation and information sharing on new vulnerabilities and emerging threats.
- CRA provides the toolset to produce such cyber-resilient connected devices, especially from a supply-chain risk’s perspective.
- To meet elevated security and compliance requirements and to tackle supply-chain risks, implementation of automated security and compliance controls, i.e., holistic binary software analysis, are required. Automated initial software analysis and continuous monitoring will substantially reduce efforts for implementation and maintaining CRA compliance.
- The ONEKEY platform automates essential cybersecurity and compliance processes, as required by the CRA. Vulnerability management, assessment, prioritization and monitoring are practically automated, and the required reporting obligation is also met through extensive reporting.
Interested in further discussion with our security experts on how to achieve and maintain your CRA product security compliance? Please contact our security experts at: experts@onekey.com
Ready to automate your Product Cybersecurity & Compliance?
Make cybersecurity and compliance efficient and effective with ONEKEY.