TACKLING SOFTWARE SUPPLY CHAIN RISKS WITH IEC 62443 AND SBOM
This whitepaper targets security teams of industrial automation and control systems (IACS) asset owners and product suppliers.
.avif)
Table of content
Product Security Lifecycle for Industrial Automation & Control Systems
Mitigating supply-chain risks is one core requirement of IEC 62443
Integrate automated SBOM into processes automate SBOM generation & link to known vulnerabilities
No shortcut to IEC 62443 compliance!
EXECUTIVE SUMMARY
Components used in an IACS Environment must meet elevated security requirements while preserving essential functions and services. The IEC 62443 standard series provides with part 4-1 a comprehensive framework for product suppliers to build a secure product development lifecycle. While the defense in depth approach implied by this framework can mitigate the impact of vulnerabilities, some vulnerabilities must still be fixed through the product life cycle.
SBOMs help to increase the visibility of the entire supply chain and strengthen the security posture of IACS suppliers and operators by allowing a risk-based patching strategy when new vulnerabilities emerge. The whitepaper discusses how the IEC 62443-4-x proposes to mitigate these risks and how the software development process needs to mature to encompass these mitigating controls. Finally, to reduce time to market, cost and resources due to manual overhead, a high level of automation is required when generating SBOMs and performing security analysis to manage security related issues in compliance with IEC 62443-4-1.
ATTACKS ON IACS ARE ON THE RISE
Cyber-attacks on industrial automation and control systems (IACS) are on the rise.1 In the past, IT and IoT systems were predominantly targeted by cyber criminals. But the same threats, such as ransom- ware attacks and devices being joined into massive botnets, increasingly affect IACS and OT too. The reason for this is simple - before IACS got smart and connected, they were mostly operated in air-gapped environments, not connected to the Internet and mostly not even connected to local corporate networks.
INTERCONNECTION OF IACS INCREASES, SO MUST THEIR CYBER-RESILIENCE
To control IACS components or make changes to their configuration, an engineer would need to physically interact with the machine. With increased digitalization, this is changing rapidly. IACS environments are connected to internal networks and the Internet to feed data into other business processes and to allow for remote configuration and management.
While improved connectivity generally increases productivity and eases administration of IACS environments, those advances go hand in hand with an increased cyber-risk posture: the threat landscape is changing. It is no longer feasible to solely rely on security controls provided by the environment and the perimeter.
As such, the same security principles that apply to IT systems must be adapted to the industrial world. Defense in depth, security by design, and zero trust must be applied to increase resilience of IACS to cyber-attacks while preserving essential functions and services. While traditional IT security mainly deals with confidentiality of data a IACS security solution must protect the integrity and availability of physical assets essential to the controlled process.
HINTERGRUND
DER NEUE EUROPÄISCHE CYBER-RESILIENZ-Act (CRA) ZIELT AUF DIE ERHÖHUNG DES SICHERHEITSNIVEAUS UND DER TRANSPARENZ AB
Am 15. September 2022 veröffentlichte die Agentur der Europäischen Union für Cybersicherheit (ENISA) den Entwurf des neuen Cyber Resilience Act (CRA), welcher nach Anpassungen und Beschluss der EU per 10. Dezember 2024 in Kraft getreten ist. Der CRA gilt in der gesamten Europäischen Union und weltweit für alle Hersteller, Importeure und Händler von Produkten mit digitalen Elementen, die ihre Produkte in der EU vermarkten. Der CRA zielt darauf ab, das Sicherheitsniveau aller Produkte mit digitalen Elementen in der Europäischen Union zu erhöhen, indem sie die Hersteller verpflichtet, einen Cybersicherheitsrahmen zu implementieren und aufrechtzuerhalten und diesen Rahmen während des gesamten Produktlebenszyklus einzuhalten. Darüber hinaus wird eine verbesserte Transparenz in Bezug auf Sicherheitseigenschaften es Verbrauchern und Unternehmen ermöglichen, sicherheitsbewusste Entscheidungen zu treffen und Produkte mit digitalen Elementen sicherer zu verwenden.
BEGRENZTE HANDLUNGSZEIT FÜR PRODUKTE MIT DIGITALEN ELEMENTEN
Diese Initiative der ENISA folgt auf die zunehmenden Schäden durch Cyberkriminalität, die 2021 zu weltweiten Kosten von mehr als 5,5 Billionen Euro führten. Viele dieser Cyberangriffe werden durch Sicherheitslücken in Produkten mit digitalen Elementen verursacht und durch die mangelnde Transparenz der Hersteller in Bezug auf relevante Sicherheitseigenschaften noch verschärft. Während die CRA ein breites Spektrum an „Produkten mit digitalen Elementen“ ins Visier nimmt, das von Betriebssystemen, Desktop- und mobilen Anwendungen bis hin zu Hardwaregeräten und Netzwerkgeräten reicht, konzentriert sich dieses Whitepaper auf vernetzte Geräte und richtet sich an Hersteller, Händler und Importeure solcher Geräte.
Der CRA wurde in 2024 von der Europäischen Kommission als Europäische Richtlinie verabschiedet und ist per 10. Dezember 2024 in Kraft getreten. Dadurch bleibt — selbst mit der Übergangsfrist bis 10. Dez 2026 — nur wenig Zeit, um die erforderlichen Berichtspflichten zu verabschieden und die verbleibenden grundlegenden Anforderungen zu erfüllen. Aufgrund mehrjähriger Konstruktions- und Entwicklungszyklen müssen alle Hersteller jetzt handeln. Nur Geräte, die durch die Verordnung (EU) 2018/1139 (Zivilluftfahrt), die Verordnung (EU) 2017/745 (Medizinprodukte) und die Verordnung reguliert werden (EU) 2017/746 (medizinische In-vitro-Diagnostika) oder gemäß der Verordnung (EU) 2019/2144 zertifizierte Geräte (Typgenehmigung von Kraftfahrzeugen und ihren Anhängern sowie für solche Fahrzeuge bestimmte Systeme, Bauteile und selbstständige technische Einheiten...) sind ausgenommen von der CRA. Angesichts der durchschnittlichen mehrjährigen Zeitspanne zwischen der Entwicklung und der Produktion der angeschlossenen Geräte bleibt nur wenig Zeit für die Annahme und Anwendung der notwendigen Sicherheitsänderungen.
ÜBERBLICK ÜBER DIE CRA ANFORDERUNGEN
Während der CRA erweiterte Sicherheitsverpflichtungen für die Erfüllung der grundlegenden Sicherheitsanforderungen festlegt, wie z. B. Konformitätsbewertungen durch Dritte für kritische Produkte (sowohl für Klasse I als auch für Klasse II), bleiben die zugrunde liegenden Anforderungen für alle Produkte gleich. Die neuen Anforderungen der CRA lassen sich grob in die drei Kategorien Governance, Produktentwicklung und Berichterstattung einteilen:
ANFORDERUNGEN AN DIE PRODUKTENTWICKLUNG
1. Anforderungen, die das Produkt selbst betreffen, definieren ein Mindestmaß an Sicherheitseigenschaften, um das Produkt vor Cyberangriffen zu schützen und sein Sicherheitsniveau zu erhöhen.
ANFORDERUNGEN AN DIE UNTERNEHMENSFÜHRUNG
2. Anforderungen, die sich auf die Prozesse des Softwareentwicklungszyklus (SDLC) des Herstellers auswirken, wie Konzept und Design, Entwicklung, Produktion und Markteinführung sowie Service und Support, sollen die Sicherheit erhöhen, sichere Produkte zu entwickeln und ihr Sicherheitsniveau auf wiederholbare, transparente und nachhaltige Weise aufrechtzuerhalten, die mit angemessenen Sicherheitskontrollen messbar ist.
ANFORDERUNGEN AN DIE BERICHTERSTATTUNG
3. Melde- und Informationspflichten gegenüber den Überwachungsbehörden und Nutzern von Produkten über ausgenutzte Sicherheitslücken und Vorfälle, die das Produkt betreffen, stellen sicher, dass Maßnahmen zur Schadensbegrenzung zeitnah umgesetzt werden können. Ziel ist es, den Zeitrahmen, in dem sowohl Endnutzer als auch Anbieter kritischer Infrastrukturen durch kritische Sicherheitslücken Cyberbedrohungen ausgesetzt sind, zu minimieren, um das allgemeine Sicherheitsniveau der europäischen digitalen Infrastruktur zu erhöhen, indem bereitgestellte Korrekturen oder Zwischenmaßnahmen ergriffen werden, um die Auswirkungen der Sicherheitslücke zu verringern.
CRA-ANFORDERUNGEN DECKEN SICHERHEITSLÜCKEN IN DER LIEFERKETTE AB
Die folgende Abbildung gibt einen Überblick über die wichtigsten Anforderungen und deren Zusammenhang mit den jeweiligen Phasen des Produktsicherheitslebenszyklus. Ihr Zweck besteht darin, tiefgreifende und sichere Schutzansätze zu unterstützen und zu gewährleisten, mit dem Ziel, die Gewissheit zu schaffen, dass die Produkte die erhöhten Sicherheitserwartungen des europäischen Marktes erfüllen. Eine zentrale Anforderung des CRA ist das Risikomanagement in der Lieferkette.
.avif)
INTEGRATE AUTOMATED SBOM INTO PROCESSES AUTOMATE SBOM GENERATION & LINK TO KNOWN VULNERABILITIES
The following section delves deeper into those aspects of supply-chain risk and how binary software composition analysis can significantly contribute to automating mitigating controls demanded by IEC 62443-4-1, while reducing manual efforts associated with achieving those requirements at the same time.
Software composition analysis (SCA) describes the automated process of determining the software components (open source and COTS), which are included in a final product. The result of a SCA is a SBOM. As it cannot be assured that source code is available for all software components provided by third parties along the supply-chain, SCA can often only rely on compiled binary representations of a software component.
SM-9: Security requirements for externally provided components By including binary SCA as part of the process to identify and manage security risks associated with third-party components used within the product, the generation of an inventory of software components from third-party suppliers can be automated. This is achieved by deconstructing the binary firmware to assure that all software components, which will eventually be delivered to the users of IACS, can be identified. Static and dynamic methods can be utilized to build a SBOM by identifying software components, associated versions, as well as applied patches. Based on this information, known vulnerabilities, affecting those software components can be identified and further investigated.
SM-11: Assessing and addressing security-related issues Implementing an automated security quality gate with binary SCA as part of the release process will assist the process of verifying that a product or product upgrade is not released until its secu- rity-related issues have been mitigated. To identify such issues as early as possible in the software development process, this security quality gate must be integrated into the build process. By automatically failing release pipelines if the identified security issues exceed previously accepted risk levels appropriated to the intended use-cases and security context, it can be assured that security- related issues originating from third-party software are addresses as early as possible.
SVV-3: Vulnerability testing Performing binary SCA on all executable files to identify known vulnerabilities in the product’s software components and libraries is explicitly mentioned as a requirement as part of vulnerability testing. Additionally, extending SCA by automating analysis of system configuration to highlight misconfigured and insufficiently hardened services, and investigate compiler settings to avoid insecure configurations that foster vulnerabilities can significantly reduce manual efforts and provide a head-start on subsequent penetration tests.
DM-1, DM-2, DM-3 Receiving notifications, reviewing, and assessing security-related issues
Security is not just a one-off effort. It is a process and requires continuous maintenance. Regularly assessing the SBOM of a firmware for newly published vulnerabilities, pro-actively ad- dresses this requirement and supports reviewing and assessing phases of security- related issues by validating applicability to the product and determining impact.
The table summarizes the supply chain risks, the requirements that IEC 62443-4-1 imposes on software development processes of IACS vendors to mitigate these risks, and how ONEKEY’s automation for firmware security analysis supports complying with these requirements.
No shortcut to IEC 62443 compliance!
Stringent security practices as required by IEC 62443-4-1 add significant overhead to existing development life cycles.
Nevertheless, they are a necessity to address today’s elevated security requirements and address the ever-increasing threat landscape. Unfortunately, there is - in general - no shortcut to implement IEC 62443 and related compliance.
There are various tools available to improve documentation, processes and cybersecurity. To simplify and support your IEC 62443 implementation, ONEKEY provides expert ‘s advice and offers consulting resources to support product suppliers.
Check out the key takeaways on the next page and learn how to substantially reduce your efforts during implementation and maintaining compliance with IEC 62443.
ONEKEY 360: Consulting and Automation
In addition to reducing manual efforts by adding automated controls to processes required by IEC 62443-4-1, ONEKEY aids product suppliers in adopting IEC 62443-4-1 with gap analyses and implementation support.
ONEKEY also offers IEC 62443-4-1 compliant managed services to conduct security verification and validation testing, covering requirements of practice 5, and to manage security-related issues, as required by practice 6, supporting with validation, triage, and impact assessments of reported vulnerabilities.
ONEKEY’s technical experts and security researchers are also available to identify gaps to a product’s adherence to IEC 62443-4-2 and to conduct penetration tests and vulnerability assessments on IACS applications, embedded devices, network components, and host devices.
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
Bereit zur automatisierung ihrer Cybersicherheit & Compliance?
Machen Sie Cybersicherheit und Compliance mit ONEKEY effizient und effektiv.