Cyber Resilience Act –
Technical implementation of security requirements

For MicroControl, the CRA is particularly relevant in the field of industrial communication systems. Our products and software components, including CANopen, CANopen FD, J1939 and bootloader solutions, are used in embedded systems and industrial applications. It is precisely in this environment that new requirements arise for risk assessment, vulnerability management, secure updates, technical documentation and traceable communication of security information.

The bootloader plays a special role here. It is a security-relevant basic component for firmware updates, integrity checks and the controlled start-up of an embedded system. As part of CRA implementation, MicroControl is therefore also working on concepts for Secure Boot. The aim is to ensure that only authorised and unmodified firmware is executed on a system. Technical approaches for this include cryptographic signatures, firmware integrity checks and a defined chain of trust from the bootloader through to the application.

MicroControl is not implementing the requirements in isolation, but is closely aligning its approach with the provisions of the CRA and the recommendations of the German Federal Office for Information Security, known as the BSI. The BSI describes the CRA as a European regulation that establishes a minimum level of cyber security for connected products placed on the EU market.

An important technical building block is the structured provision of security information. For this, the BSI recommends, among other things, the Common Security Advisory Framework, or CSAF for short. CSAF is a standardised, machine-readable format for providing security advisories. It enables manufacturers to publish information on vulnerabilities, affected products, versions, severity levels, remediation measures and references in a consistent manner. For users and operators, this makes automated evaluation easier and enables them to assess quickly whether specific products or versions are affected.

MicroControl is already taking these requirements into account in its own security documentation. On our security policy page, we describe how security vulnerabilities can be reported, what information is helpful for an assessment and how we handle reports as part of coordinated disclosure.

A central element of CRA implementation is a robust vulnerability management process. This includes the ability to record reported vulnerabilities in a structured manner, validate them technically, assess their impact and derive suitable measures.

For this, MicroControl uses a Coordinated Vulnerability Disclosure process, i.e. coordinated disclosure of vulnerabilities. Once a report has been received, the information provided is reviewed, the issue is analysed and potential effects on products, software versions or configurations are assessed. On this basis, measures for remediation or mitigation are defined.
The following information is particularly relevant for a technical assessment:

• affected products and product versions;
• affected firmware, software or hardware versions;
• description of the vulnerability;
• steps to reproduce it;
• possible impact on availability, integrity or confidentiality;
• existing proofs of concept, log files or protocol traces;
• references to already known CVE entries or comparable vulnerabilities.

Security advisories may subsequently contain information on affected versions, severity ratings, updates, workarounds, CVE references and a revision history. Where appropriate, such information may also be provided in standardised formats such as CSAF.

The CRA is also relevant for products and software components in the CAN environment. This creates the need for a system- and application-specific risk assessment. CAN in Automation e.V., or CiA for short, points out in a position paper that SL2 can be achieved in CAN networks with minimal effort.

For CAN-based systems, the assessment always depends on the specific usage scenario. Security measures must therefore be supplemented depending on the system architecture, access options, interfaces, operating environment and required security level. In industrial applications, the following aspects, among others, play a role:

• physical access to the CAN network;
• network segmentation and gateway concepts;
• protection of external interfaces;
• separation of service, diagnostic and production access;
• access protection for configuration and update functions;
• integrity checking of firmware and configuration data;
• monitoring of communication;
• authentication and authorisation of security-relevant functions.

For MicroControl, this context is especially important because our protocol stacks are typically integrated into customer-specific devices, controllers or machines. CRA compliance must therefore not be considered only at the level of individual software components, but always in conjunction with the target hardware, firmware, bootloader, update process, network topology and application.

When processing security reports, the question often arises of how a component mentioned in a vulnerability report can be reliably found again in an existing SBOM. Especially when companies want to evaluate security information automatically, unambiguous identification of the affected products or components is crucial. Without standardised identifiers, matching a security advisory with an SBOM remains prone to error and is often only possible manually.

Security information is increasingly provided in CSAF format. CSAF stands for Common Security Advisory Framework and is a standardised format for the structured publication of security advisories. The CSAF format includes, among other things, the product_tree section. This can be used to describe affected products and components.

An important component here is the product_identification_helper field. This field is not mandatory, but provides a very helpful way of specifying additional identifiers for a product or component. The product_identification_helper field facilitates automatic matching between:

• a component in a security advisory;
• and a component in an SBOM.

This enables a tool to check automatically whether a particular vulnerability is relevant to a product or software component. The use of standardised identifiers such as the Package URL, or PURL for short, is particularly helpful here.

Package URL as an identifier

The Package URL is a widely used standard for identifying software packages across different ecosystems. A PURL describes a package in a structured form. This allows it to be read by machines and used for automated comparisons.

For MicroControl protocol stacks, the PURL follows the following scheme:

Scheme of a PURL for protocol stacks

– pkg: designation as a Package URL;
– generic: package type when no specific ecosystem such as npm, Maven or PyPI is used;
– microcontrol: namespace or manufacturer/organisation reference;
– <stack-prefix>-protocol-stack: name of the protocol stack;
– <version-string>: specific version of the component.

Supplementary identification via SKU

In addition to the PURL, an SKU can also be specified. In this case, the SAP article number is used as the SKU. This creates a second identification option, which is particularly helpful when internal ERP, purchasing or product data are to be matched with security information.

For a J1939 Protocol Stack in version 4.12.00 with the SAP article number 50.04.002, the entry in the CSAF document looks as follows:

The Cyber Resilience Act fundamentally changes the requirements placed on manufacturers of products with digital elements. For MicroControl, this development is closely linked to industrial communication, embedded software, bootloader technologies and CAN-based systems.

We are consistently implementing the provisions of the CRA, the recommendations of the BSI and the guidance from the CAN/CANopen environment. The focus is on structured security processes, coordinated vulnerability handling, standardised security advisories, technical documentation and secure update and boot concepts. With our protocol stacks and bootloader solutions, we operate in a technical environment in which cyber resilience is increasingly becoming an integral part of product development. The implementation of Secure Boot approaches, clear vulnerability processes and traceable documentation is therefore an important step for us in supporting customers in the development of secure and future-proof industrial products. Further information on the reporting channel and on the handling of security vulnerabilities can be found on our security policy page.

[1] MicroControl Security Policy
[2] BSI: Cyber Resilience Act
[3] BSI: Common Security Advisory Framework, CSAF
[4] CAN in Automation e.V.: EU Cyber Resilience Act
[5] European Commission: Cyber Resilience Act