Understanding The Cyber Resilience Act (CRA)

The 2020 EU Cybersecurity Strategy, published by the European Commission and the High Representative of the Union for Foreign Affairs and Security Policy, aimed to establish safeguards against security risks arising from increased digital connectivity. As part of the strategy, the strategy included updates to Directive (EU) 2022/2555 on measures for a high common level of cybersecurity across the Union (NIS2).

In response to supply chain attacks, the Commission published the Cyber Resilience Act (CRA) seeking to establish software development life cycle (SDLC) best practices for a comprehensive approach across the geographic region.

What is the Cyber Resilience Act (CRA)?

In September 2022, the European Commission published its proposal for a set of cybersecurity requirements that would apply to “products with digital elements.” The regulations define this as any software or hardware product and its remote data processing solutions. Essentially, CRA exists to establish a standardized framework for handling security across a product’s life cycle.

CRA states its primary purpose is to create conditions where:

• hardware and software has fewer vulnerabilities when bought to market by incorporating security into the product life cycle
• Users can incorporate cybersecurity into decision-making when selecting and using products

It outlines four specific objectives that will help achieve its primary purpose:

• Improve security throughout the product life cycle, beginning with design and development phase
• Create a coherent cybersecurity framework for compliance across hardware and software
• Enhance transparency for product security
• Enable businesses and consumers to use products securely

Who needs to comply with the CRA?

The CRA defines the two different classes of manufacturers in Annex III.

Class I defines the following twenty-three categories of “critical products with digital elements” that CRA holds to a higher security standard:

1. Identity management systems software and privileged access management software;
2. Standalone and embedded browsers;
3. Password managers;
4. Software that searches for, removes, or quarantines malicious software;
5. Products with digital elements with the function of a virtual private network (VPN);
6. Network management systems;
7. Network configuration management tools;
8. Network traffic monitoring systems;
9. Management of network resources;
10. Security information and event management (SIEM) systems;
11. Update/patch management, including boot managers;
12. Application configuration management systems;
13. Remote access/sharing software;
14. Mobile device management software;
15. Physical network interfaces;
16. Operating systems not covered by class II;
17. Firewalls, intrusion detection and/or prevention systems not covered by class II;
18. Routers, modems intended for the connection to the internet, and switches, not covered by class II;
19. Microprocessors not covered by class II;
20. Microcontrollers;
21. Application specific integrated circuits (ASIC) and field-programmable gate arrays (FPGA) intended for the use by essential entities
22. Industrial Automation & Control Systems (IACS) not covered by class II, such as programmable logic controllers (PLC), distributed control systems (DCS), computerised numeric controllers for machine tools (CNC) and supervisory control and data acquisition systems (SCADA);
23. Industrial Internet of Things not covered by class II.

Class II consists of the following fifteen product categories:

1. Operating systems for servers, desktops, and mobile devices;
2. Hypervisors and container runtime systems that support virtualised execution of operating systems and similar environments;
3. Public key infrastructure and digital certificate issuers;
4. Firewalls, intrusion detection and/or prevention systems intended for industrial use;
5. General purpose microprocessors;
6. Microprocessors intended for integration in programmable logic controllers and secure elements;
7. Routers, modems intended for the connection to the internet, and switches, intended for industrial use;
8. Secure elements;
9. Hardware Security Modules (HSMs);
10. Secure cryptoprocessors;
11. Smartcards, smartcard readers and tokens;
12. Industrial Automation & Control Systems (IACS) intended for the use by NIS2 essential entities, such as programmable logic controllers (PLC), distributed control systems (DCS), computerised numeric controllers for machine tools (CNC) and supervisory control and data acquisition systems (SCADA);
13. Industrial Internet of Things devices intended for the use by NIS2 essential entities
14. Robot sensing and actuator components and robot controllers;
15. Smart meters.

What are the CRA’s key requirements?

The CRA breaks down product security into two specific groups. The products shall have certain capabilities or configurations that make them compliant, and the manufacturer will manage vulnerability identification and software updates responsibly. However, buried within the text, manufacturers also need to consider how they secure their development and testing environments.

Essential Cybersecurity Requirements

Products with digital elements shall:

• Be delivered with secure-by-default configurations
• Have appropriate authentication mechanisms, like authentication, identity or access management systems
• Use mechanisms for data confidentiality, like encrypting data at rest or in transit
• Use mechanisms for data integrity across personal data, other data, commands, programs, and configurations
• Process the minimum amount of data necessary
• Protect essential function availability, including against denial of service (DoS) attack
• Minimize their own negative impact on other device or network services
• Be designed developed, and produced to limit attack surfaces
• Be designed, developed and produced to reduce an incident’s impact
• Provide security related information by recording and/or monitoring relevant internal activity
• Ensure users can address vulnerabilities through updates

Vulnerability Handling Requirements

Manufacturers shall:

• Identify and document vulnerabilities and components in the product
• Address and remediate vulnerabilities in relation to the risks posed to the products
• Apply effective and regular tests and reviews of the products security
• Publicly disclose information about fixed vulnerabilities after making the security update available
• Implement and enforce a policy on coordinated vulnerability disclosure
• Facilitate information sharing about potential product vulnerabilities, including those from third-party components
• Provide mechanisms to distribute products updates in a secure and timely way that fix or mitigate risks from exploitable vulnerabilities
• Ensure security patches or updates are disseminated without delay and free of charge

Securing Development and Testing Environment

Throughout CRA, the regulation references its sibling, NIS2. Although the majority of CRA focuses on secure software development processes, it does state the following in Article 11 Reporting obligations of manufacturers:

2. The manufacturer shall, without undue delay and in any event within 24 hours of becoming aware of it, notify to ENISA any incident having impact on the security of the product with digital elements. ENISA shall, without undue delay, unless for justified cybersecurity risk-related grounds, forward the notifications to the single point of contact designated in accordance with Article [Article X] of Directive [Directive XXX/XXXX (NIS2)] of the Member States concerned and inform the market surveillance authority about the notified incidents.

4. The manufacturer shall inform, without undue delay and after becoming aware, the users of the product with digital elements about the incident and, where necessary, about corrective measures that the user can deploy to mitigate the impact of the incident.

Monitoring Security and Documenting Compliance for CRA

To protect their development, testing, and production environments, manufacturers should need solutions that help document their threat monitoring, detection, and response activities.

Access Monitoring

With a threat detection and incident response (TDIR) platform, manufacturers can monitor their development and testing environments to mitigate risks arising from malicious actors compromising their digital elements.

Security analytics tie user and entity behavior analytics (UEBA) with log data so that organizations can handle security functions like:

• Privileged access management (PAM)
• Password policy compliance
• Abnormal privilege escalation
• Time spent accessing a resource
• Brute force attack detection

Network Monitoring

If malicious actors compromise the development, testing, or production environments, manufacturers need to correlate and analyze data from various network security monitoring  tools like:

• Firewalls: inbound and outbound traffic
• Intrusion detection system (IDS)/Intrusion prevention system (IPS)

After defining baselines for normal network traffic, organizations can more rapidly detect anomalies that may indicate a security incident.

MITRE ATT&CK Aligned Detections

With detections built around ATT&CK tactics, techniques, and procedures (TTPs), security teams can correlate the activities occurring in their environments with real-world malicious actor motivations and next steps. With high-fidelity Sigma rule detections, security teams can respond to incidents faster, reducing time attackers spend in systems and minimizing impact.

API Security Monitoring

For manufacturers who provide customers with Application Programming Interfaces (APIs) as part of the digital elements, monitoring API security takes on an additional importance. These companies need to secure the APIs in their environment while ensuring that they provide customers with secure APIs.

To achieve these objectives, organizations need to capture the full, unfiltered API request and response to identify common threats, including identifying vulnerabilities.

Graylog Security and API Security: Enabling Compliance with CRA

Using Graylog Security, you can rapidly mature your TDIR capabilities without the complexity and cost of a traditional Security Information and Event Management (SIEM) technology. Graylog Security’s Illuminate bundles include detection rulesets so that you have content, like  Sigma detections, enabling you to uplevel your security alert, incident response, and threat hunting capabilities with correlations to ATT&CK tactic, techniques, and procedures (TTPs).

By leveraging our cloud-native capabilities and out-of-the-box content, you gain immediate value from your logs. Our anomaly detection ML improves over time without manual tuning, adapting rapidly to new data sets, organizational priorities, and custom use cases so that you can automate key user and entity access monitoring.

With our intuitive user interface, you can rapidly investigate alerts. Our lightning-fast search capabilities enable you to search terabytes of data in milliseconds so that you can reduce dwell times, shrinking investigations by hours, days, and weeks.

To learn how Graylog Security can help you implement robust threat detection and response, contact us today.