In a few words, if you either manufacture, import or resell a product with digital elements, you will surely be affected by the CRA, and need to ensure compliance. This article is intended to shed light on: What does this regulation entail? Who is affected? How can compliance be achieved? 

What is the cyber resilience act and what does it entail?   

To understand the necessity of the Cyber Resilience Act, it’s crucial to consider the broader context of cybersecurity in Europe. The CRA is an ambitious regulation designed to ensure the security of EU citizens by addressing the currently observed low levels of cybersecurity in products with digital elements through a European Union policy intervention. In response, comprehensive studies focusing on the cybersecurity of digital products were conducted, leading to the proposal of legislation defining the obligations for the whole products supply chain actors, from manufacturers to distributors.  

Wavestone’s involvement in this process underscores its commitment to enhancing cybersecurity standards. We participated in an in-depth exploratory study commissioned by the EU, engaging with a broad spectrum of stakeholders involved to varying degrees in the products ecosystem, including national authorities, EU bodies, hardware and software manufacturers, trade associations, consumer organizations, researchers, academia, and cybersecurity professionals.  

Through Wavestone’s position as a global, and particularly European leader in the field of cybersecurity, several interviews, focus groups and workshops were conducted.  Valuable insights were gathered from a wide range of different interlocutors, providing a comprehensive view that takes into account the perspectives of all stakeholders and allowed the foundation for the development of the CRA. 

Definition and Scope 

The Cyber Resilience Act is a legislative proposal defining the obligations of manufacturers, importers, and distributors of products containing digital elements marketed in the EU, all of which must bear the CE mark across all sectors. As defined in the regulation, this includes “any software or hardware product and its remote data processing solutions, encompassing components that can be marketed separately”. The regulation’s aim is not only to secure standalone products but also to ensure the security of data transmission chains and central infrastructures through the application of this standard. 

To this notion of product is added a notion of criticality, therefore the CRA differentiates two types of products: products with digital elements and critical products with digital elements. As detailed below in “Checklist for CRA compliance”, it will affect how compliance can be achieved. 

A few examples of products with digital elements include consumer products, smarts cities and non-essential software. Critical products with digital elements include for example industrial control systems and firewalls. The detailed list of concerned products can be found in the regulation’s annexes. 

However, as is detailed below in “A complex ecosystem”, the CRA does not apply universally; products in some specific sectors do not have to comply to the requirements 

Stakeholders and Responsibilities 

The CRA impacts the entire lifecycle of digital products, from development by manufacturers, importers, distributers to the final consumer, but also the vulnerability management from conception to the product end-life, through a share responsibility. 

Essential Requirements 

As said earlier, the CRA’s objective is to allow a sufficient level of cybersecurity in products with digital elements. To do so, it introduces essential requirements built on three pillars: 

• Product Security: Ensuring products are designed, developed, and manufactured to meet appropriate cybersecurity levels and are free from known exploitable vulnerabilities. 
• User Documentation: Providing documentation to ensure safe use from commissioning to end of life. 
• Vulnerability Management: Identifying and documenting vulnerabilities, conducting regular security tests, and implementing a vulnerability disclosure policy. 

In the event of non-compliance with the essential requirements, sanctions may be applied on any of the three stakeholders. Like GDPR, each Member State shall determine the penalties applicable to infringements of this Regulation. Penalties are based on the company’s annual turnover and the severity of the infraction, with fines reaching up to 15 million euros or 2.5% of the total worldwide annual turnover for significant breaches.  

How to achieve compliance with the CRA? 

Timeline of the CRA 

The CRA has been a long-term project, with almost 10 years from identification of the need to application, reflecting the complexity of establishing comprehensive cybersecurity regulations: 

Businesses have until the 2026 to achieve compliance, with interim obligations. Similar requirements can be found in other regulations, such as NIS2, but contrary to other regulations, the CRA does not need a national transposition. The CRA was passed by the European Parliament in March 2024, and it is awaiting a vote by the European Council to become a law. 

A complex ecosystem 

One of the major concerns raised during the preparation of the Cyber Resilience Act was how to navigate the multitude of existing regulations and achieve regulatory harmony, particularly in sectors where safety, privacy, and cybersecurity standards intersect.  

The CRA aims to foster interoperability by aligning with the general product safety framework, the Cyber Security Act’s requirements for ICT products, processes, and services, and the CE marking standards for European compliance. 

To streamline compliance, the CRA includes presumptions of conformity with existing regulations such as the RED Directive, the AI Act, and certain sector-specific rules.  

However, the CRA does not apply universally; some sectors, such as medical, aviation, and automotive, are already governed by established regulations and are thus exempt from the CRA’s provisions. 

Checklist for CRA compliance 

Compliance with the CRA involves a thorough understanding of the regulation’s core text and two annexes, which detail: the list of concerned products, essential requirements, the obligations for manufacturers, importers, and distributors and national competent authorities and sanctions.  

The certification process varies based on product criticality: 

• For non-critical products : a self-assessment is necessary 
• For critical products  : third-party assessment is necessary, meaning the product compliance to the CRA will be assessed by a certified entity. At the time of writing this article, the exact certification schemes have yet to be specified but in France, the CESTI certification is in discussion.  

Five main checkpoints are to be considered to achieve compliance:  

1. Legislative Gap Analysis: Identify discrepancies between current practices and the requirements of the CRA by reviewing existing cybersecurity policies, processes, and controls to pinpoint areas needing improvement. 
2. Product Security Assessment: Conduct thorough assessments to ensure product identification and security.  
3. User Instructions Update: Provide clear and comprehensive user documentation by ensuring that all products are accompanied by documentation in adequation with the regulation standards. 
4. Vulnerability Management: Set up a process for identifying and sharing vulnerabilities. 
5. Internal Organization Review: Implement a permanent procedure to ensure compliance, covering the above-mentioned key points and enforce a watch on product or legislation changes that may imply new gaps to remediate.

In conclusion, the Cyber Resilience Act represents a comprehensive framework to enhance the cybersecurity of digital products within the EU. Compliance with this legislation requires thorough preparation. For businesses, adhering to the CRA is not just a legal obligation but also an opportunity to enhance their standing in a market increasingly aware of cybersecurity issues.  

Cet article Cyber Resilience Act: A revolution redefining product security and transforming the ecosystem est apparu en premier sur RiskInsight.

Industrial systems are a category of information systems of their own, with codes and properties that differ from “classic” IT systems. It is well known that the level of maturity of the industrial sector in terms of cybersecurity is generally lagging in comparison with what is done in IT systems. This delay can be explained by several factors, one of which being the historical legacy of industrial systems that sometimes are in place since several decades. This article will focus on one of these historical aspects which can be found in many industrial networks today: which are known as ‘PLC’ or ‘field’ networks. We will first look at the history that led to the existence of these networks, then examine the strengths and weaknesses of the model with respect to current and future cybersecurity needs, to answer the following question: Are field networks adapted to new cyber security needs?

History

Let’s go back in time: we are not going to talk about the different industrial revolutions, but our story begins at the start of the 70s. At the time, there was no Ethernet network, OSI model or even IT. Industrial production systems relied on physical mechanisms using pneumatic or electrical signals. The 1970s saw the arrival of the first principles of automation, and the integration of the first intelligent equipment: the programmable logic controllers (PLC). This equipment allows resources to be pooled, as a PLC can manage several electrical inputs and outputs, and therefore centralise the management of processes. PLCs also incorporates communications modules, and this led to the appearance of the firsts bus networks in industrial systems, using serial communications protocols.

This architecture model will continue to develop in the 80s with the increase of industrial protocols, based on the “Controller-Workers” model: A main PLC contains the centralised database and plays the role of an orchestrator by being linked to the “Workers”, corresponding to other PLCs, remote input/output cards, etc… This architecture simplifies process programming at a single point, as well as communication with supervisory devices such as the man-machine interface or proprietary SCADA.

The 1990s brought the democratisation of the TCP/IP model and the integration of ‘traditional’ IT into industrial environments: no more need for proprietary equipment, SCADA software can now be installed on conventional systems… but these computers still need to be able to communicate with the PLCs! Serial network cards exist, but industrial protocols are beginning to adapt to operate on a conventional Ethernet network. Master controllers are gradually being replaced to enable them to use TCP/IP protocols on the main network, while continuing to have serial network cards for field equipment. Then it was the turn of field equipment to adapt to the standardisation of TCP/IP use everywhere, so that today the use of serial communications is minimal. Even electrical inputs/outputs are now tending to be replaced by IP links on sensors and actuators, via the use of “Single Pair Ethernet” connectors, for example, which provide a low-cost and space-saving connection.

Evolution of field architectures

As a result, the following architecture is now commonplace: A “main” industrial physical network (in star or ring topology) containing all the supervision and external communications equipment (SCADA, Data Historian, operator station, etc.) as well as the PLC controllers, each of which has a second network port. This second network port makes it possible to create an isolated sub-network on each PLC on which the equipment closest to the physical process is located. The PLC controller then acts as a “functional pivot”, exchanging data with the SCADA system on the one hand, and with field equipment via the PLC’s data registers on the other. This architecture can be adapted in several ways, for example, by replacing the pivot PLC with a server, or by combining several layers of isolated networks with a SCADA server having two network ports, separating the main industrial network and the supervision network in which the controller PLCs are found, on which a new separation is made with field networks.

Example of industrial architecture integrating field networks

Now that we’ve looked at the past, let’s talk about the present, and in particular the three evolutions that are leading us to question the relevance of this architectural model today:

• Industry 4.0, which has changed the face of industrial networks, moving from an isolated model to an ultra-connected model to meet the challenges of Big Data, interconnection with the Cloud, the digital twin, etc…
• The standardisation of industrial technologies, enabling us to move away from industrial suppliers, via the development of “Soft PLCs” on Linux or onboard Windows, or the use of standardised industrial protocols such as OPC-UA.
• The introduction of cybersecurity solutions at the core of the industrial network, such as update servers, firewalls, antivirus and even EDR or network probes, whose presence makes sense with the modernisation of IT infrastructures and the development of cybersecurity in the industrial environment.

To study the relevance of field networks in the light of these new challenges, we are going to look at four operational security issues: network security, remote access, update management, and detection and mapping.

Network security

The first question to ask is simple: What are the advantages of field networks from a cyber security point of view? This advantage is reflected in the very principle of the architecture model: the use of pivot equipment provides physical isolation between an industrial network and a field network. In principle, therefore, it is not possible for the two networks to communicate directly, as information is transmitted via a database (registers for PLCs, OPC database for a server, etc.). There is no need for a firewall or diode: no flow can go from one network to another, which is the best way of protecting against propagation to field equipment.

But is this separation, made using a physical equipment not dedicated to the network, foolproof? On equipment operating on a ‘classic’ Windows or standard Linux system, the answer is no. There are many examples of attacks that convert these systems into pivots, exploiting the many possibilities offered: exploitation of remote access protocols such as RDP, VNC or SSH, RAT, C2C implants, etc. As a result, a separation with this type of system will slow down an attacker but does not significantly reduce the possibilities of reaching field networks that would exist on other network cards.

In the case of a “classic” PLC, this is usually a piece of equipment running on a proprietary operating system that offers few functions: at the very least it can run industrial programs and communicate with one or more industrial protocols and can optionally contain more traditional HTTP or FTP type servers. The equipment therefore offers far fewer functions than a computer or server and is not designed to provide gateways between its various network cards… or so we tend to think. However, it has been shown that it is possible to create gateways between the various network ports of a PLC: via research work such as that by Nicolas Delhaye and Flavian Dola presented at GreHack 2020 (the video here), but more concretely via the Pipedream malware discovered in 2022. This malware enables network routes to be created on Schneider PLCs, transforming them into proxies and giving them the ability to route any protocol to field networks.

Illustration of how the Pipedream module targeting Schneider equipment works.

We have therefore proved that, even in the case of separation by a PLC, the model is not infallible, but it still makes it possible to greatly reduce the risks by only exposing the field networks to very advanced attacks.

Mapping and supervision

Following the previous paragraph, a question naturally comes up: how do you supervise a network whose strong point is its isolation? Firstly, about logging, the current observation is that PLCs and industrial equipment are still very rarely included in security supervision perimeters: for technical reasons, as not all equipment is necessarily capable of sending back syslog-type logs, but also for organisational reasons, as SOC teams still lack the maturity to make proper use of event logs from this type of industrial equipment.

To overcome this lack of visibility, industrial environments are becoming increasingly subject to the installation of a network probe, enabling supervision and mapping requirements to be met. In particular, systems falling within the scope of the French Military Programming Laware required to install an ANSSI-qualified detection probe. Technically, it is possible to make isolated networks communicate with a probe by using network TAPs, whose function is to passively copy network traffic so that it can be listened in on. Strategically, field networks are rarely the place to monitor the network side. Priority should be given to interconnection points with other networks (company, supplier, etc.) or critical control equipment such as SCADA.

 
Example of a supervision architecture integrating field networks

However, the TAPs solution is not applicable to “active” probes, which seek to map by questioning the various devices on the network. But this type of solution is rarely implemented in an industrial context, to avoid ‘stressing’ the network and the equipment.

The field network model therefore remains compatible by focusing on network supervision with the installation of probes for detection, as well as passive mapping. The feedback of system logs from PLCs and industrial equipment is still not sufficiently relevant to the analysis capabilities of SOCs.

Update

To be able to make updates, it is necessary to have a network interconnection with a system allowing these updates to be sent to endpoints, which is opposed to the isolation of field networks. Does the need for updates in an industrial environment make the field network model obsolete?

Maintaining security is a complex issue when it comes to industrial systems: the high level of availability prevents any major intervention, systems that are isolated from the Internet mean that updates cannot be downloaded over the network, etc. In the case of networks made up mainly of PLCs, update mechanisms have evolved to take account of these constraints, with the result that today the number of PLCs kept up to date is very small (even on an annual basis), and these updates are mainly deployed manually by maintenance staff. The use of field networks to partition the architecture does not prevent these same mechanisms from being applied to PLCs.

On the other hand, the integration of IT technologies is changing the rules: one of the first security solutions recommended for a Windows installation is to set up a WSUS server to centralise the deployment of updates, and the same principle is also applicable to Linux technologies. This brings us to a new constraint for field networks with equipment such as Soft-PLCs or dedicated operator PCs: partitioning by dual network cards prevents centralised management of updates, forcing the implementation of a manual patching process that can be complex and time-consuming for many devices.

However, this constraint must be evaluated in relation to the need. The main argument in favour of updates is that they enable vulnerabilities to be corrected that increase the attack surface of an equipment. As the field network model strongly isolates systems, their attack surface is already greatly reduced. It is therefore acceptable for systems not to be constantly updated, and in this case a manual annual update of the equipment meets the need.

However, this model is not suited to the need for antivirus software to be constantly updated to guarantee optimum protection. This is why it is necessary in this case to rely on systems that move very little over time, which makes it easier to use whitelisted application filtering solutions such as AppLocker or WDAC (see our article on application filtering).

Finally, updating practices in industrial environments have adapted to the very principle of network isolation, enabling these needs to be reduced. These practices do, however, require equipment to be hardened when installed, and solutions to be put in place to maintain system security levels with a minimum of maintenance.

Remote access

Having looked at “automated” update flows, what about flows initiated by a user to access remote equipment for business or maintenance operations? For PLCs, such access is rare: they do not need human intervention to perform their tasks, and in the case of internal maintenance, this is often carried out by accessing the PLC from the network on which it is located (dedicated administration networks for PLCs are still very rare). If the PLC is accessible from the main production network, maintenance can be centralised from a single connection point. On the other hand, since field networks are isolated from the production network, the PLCs located there can be accessed by connecting the maintenance laptop to the ‘right’ switch, interconnecting the various items of equipment on the sub-network, or even directly to the PLC’s USB port with a serial link.

On the other hand, there are limits when it comes to field networks with equipment maintained by a supplier or maintenance service provider. This is because remote maintenance has become the preferred method, and it is quite rare these days to have third-party maintenance staff available to physically visit the site at any time. The most common solution to this problem is to install a VPN termination directly on a field network, with a tunnel connected to the service provider. This effectively addresses the problem, but also bypasses the whole principle of isolating field networks, which are then exposed in the event of the service provider being compromised.

This is where we reach the biggest limitation of the field network model, reinforced by the trend towards centralising remote access and installing bastion-type solutions that cannot cover access to field networks due to their isolation.

Conclusion

The existence of field networks is mainly historical, due to the old controller/worker architecture models and the gradual introduction of the TCP/IP model in industrial networks. These architectural models have adapted to the life cycle of systems: they are accessed very little by users and are designed to operate autonomously by sending data back to the controller.

Partitioning is the main strength of field networks: transforming a PLC in a rebound equipment to two different network interfaces is a highly advanced attack technique. To detect possible attacks, solutions exist for setting up supervision on isolated networks, in particular with TAPs.

The other advantage of network isolation is that it reduces the effort required to maintain security. The need to update isolated equipment is not necessarily the same as for equipment used by humans and interacting with third-party networks. Since isolated equipment has a lifecycle with few changes, the focus should be on hardening when it is brought into service.

However, the isolation of these networks poses several problems in terms of remote access: it is possible to limit this when the industrial estate is managed internally, but it is essential when a service provider needs to intervene remotely. To avoid local initiatives or third-party solutions, it is advisable to implement a controlled remote access solution (VPN, bastion, etc.), with the accessed equipment placed on a dedicated sub-network with a filtered and controlled entry point.

In conclusion, the field network model is still relevant today. However, recent trends, particularly those linked to Industry 4.0, will raise new issues: the emergence of Industrial IOTs, involving the implementation of IoT network buses interconnected with the outside world, calls into question the relevance of having isolated IP networks cohabiting with more exposed IoT buses.

Source

Dragos Analyzing PIPEDREAM: Results from Runtime Testing
https://www.dragos.com/blog/analyzing-pipedream-results-from-runtime-testing/

GreHack 2020: A full chained exploit from IT network to PLC’s unconstrained code execution
https://www.youtube.com/watch?v=PfdoaxYkmUE

Cet article PLC network: the history of industrial systems  facing up to the challenges of the future est apparu en premier sur RiskInsight.