Overview

CRA is a law that applies to products shipped to the EU. What makes it significantly different from previous laws, regulations, and industry standards related to product security is its binding force, which is directly linked to the acquisition of the CE mark, and the wide range of impacts that it covers, including "products that contain digital elements." When reading the CRA glossary, it is best to interpret the definition of the products that it covers as being highly likely to cover equipment that contains electronic circuits.

Requirements set out in the Articles and Annexes

Requirements that product manufacturers must comply with include Articles 13 and 14. The details of the contents are included in the appendix, and are broadly divided into three types: "security characteristic requirements," "vulnerability response requirements," and "technical documentation requirements."

Product manufacturers are currently working to meet these requirements. However, manufacturers with product groups such as industrial equipment, for which security measures have not been strongly required by the market, are often struggling to meet these requirements.

Establishing a system for addressing product security

Unlike information security, which has a specific department that should handle the issue, product security is handled across various departments within the company. Naturally, the development department is one of the parties involved, but there are also other matters to be carried out outside of the development process, such as the establishment of internal regulations, pre-shipment inspections, and vulnerability management of products after shipment.
The question here is, "Which department should be in charge?" Considering the normal process leading up to the release of a product, some believe that the quality department should be actively involved in the establishment of regulations and inspections. However, there are also some who have sufficient knowledge of embedded software and security.
The reality is that there are still not many quality departments. By proceeding with the issue without considering how to deal with the situation, simply because it is a requirement, there are many cases where the following situation occurs.

• Example 1) As a result of trying to handle the issue on its own, the development department ended up allocating resources that should have been allocated to new product projects to testing and vulnerability management.
• Example 2) There is no review to determine whether the initiatives implemented by the development department are correct.
• Example 3) The quality department is assigned tasks outside of the development process, but they do not have the expertise to carry them out, so the burden falls on the development department.

In order to improve this situation, it is essential to establish a management system that is suited to the culture and resource situation of each individual company. For example, there are cases where product security is treated as being on the same level as a quality issue, a three-line model has been established, and a governance system has been established by establishing not only a quality department but also a dedicated organization (PSIRT).

In this type of structure, it is common for information security and development departments to take steps such as assigning personnel with security knowledge to dedicated organizations.
This system is not necessarily the correct one, but it is important to create an approach that suits your company.

Incorporating security into existing development processes

As mentioned briefly in the section on organizational structure, the development department will bear the greatest burden in terms of product security. At each stage of the currently constructed development process (from planning to operation and maintenance), new work will arise from the perspective of product security. This is called the secure development process.
The diagram below shows examples of actual efforts, which can be categorized into three categories: "Consideration and implementation of security measures," "Verification of correctness of measures," and "Continuous management of vulnerabilities." It is important to carry out these steps reliably, but there are challenges in implementing each of them.

• Consideration and implementation of security measures

  This step refers to the process of comprehensively visualizing risks, determining whether measures should be taken or are acceptable, and implementing technical measures based on the results, which is expected to have the effect of minimizing security costs. At the risk visualization stage, it is common to conduct a desk-top analysis called a threat analysis, but since it requires both knowledge of the usage environment of the company's products and specialized knowledge of product security, it is a high hurdle for development departments with no experience to carry it out.

• Verify the correctness of the measures

  This step involves functional testing to check whether the countermeasures have been implemented correctly, and security testing to check whether any vulnerabilities remain in the product. In particular, penetration testing, which is carried out to verify the sufficiency of the countermeasures, requires more advanced security expertise, such as creating test scenarios and ensuring the technical capabilities to execute the scenarios.

• Ongoing Vulnerability Management

  Compared to the other steps, this step can be automated using tools, but one difficult aspect is judging the impact of the discovered vulnerability. There are two aspects to this assessment: 1) whether the software component in question is in use, and 2) whether the vulnerability can be reproduced in the company's own products.

  Regarding ①, the accuracy of the judgment depends on whether the SBOM of the company's products can be generated and managed. On the other hand, regarding ②, it is necessary to judge whether the discovered vulnerability can be reproduced in the product specifications using dynamic testing, so a deep knowledge of security is required.

I have talked about each of these three initiatives, but in summary, the goal of a secure development process is to combine sufficient knowledge of your own products with expert knowledge of product security.