Plug & Charge is being promoted precisely to address this challenge. Enabled by the ISO 15118 standard, this mechanism allows the charging station to automatically authenticate the user and initiate charging without the need for a badge or mobile application. Originally designed to standardize communication between the vehicle, the charging station and the grid, ISO 15118 paves the way for a more seamless charging experience—often summed up by the promise: “plug in and it charges.” 

However, this apparent simplification on the user side actually relies on a significant increase in complexity across the underlying trust chain and technical mechanisms: digital certificates, Public Key Infrastructure (PKI), ISO 15118 communications, new authentication flows, and dependencies on trusted third parties. In other words, behind a frictionless charging experience, Plug & Charge introduces new points of failure and expands the attack surface that operators must now address as critical cybersecurity concerns. 

In this article, we take a closer look at three risks directly associated with the deployment of Plug & Charge and ISO 15118: 

• availability loss resulting from a compromise of the V2G (Vehicle-to-Grid) PKI; 
• availability loss caused by the exploitation of vulnerabilities on the ISO 15118 interface; 
• the theft of charging station certificates and its implications in terms of fraud. 

Risk 1: availability loss resulting from a compromise of the V2G PKI 

To understand this risk, it is first important to recall that Plug & Charge relies on a digital trust chain that enables the vehicle and the charging station to automatically authenticate each other using certificates and then initiate charging without any manual action from the user. 

As illustrated in Figure 1, a Plug & Charge session follows a multi-step sequence: 

1. Establishment of the ISO 15118 communication channel between the vehicle and the charging station, along with mutual authentication,  
2. Verification of the mobility contract followed by authorization, 
3. Start of charging session. 

If any of these steps fails due to a breakdown in digital trust, the charging session cannot be initiated. 

Figure 1: Steps of a Plug & Charge session 

This mechanism relies on a shared PKI across the ecosystem, known as the V2G PKI, whose role is to ensure interoperability between vehicles, charging stations, and operators. This architecture is built on root and intermediate certificate authorities that issue and validate the certificates used throughout the charging session (Figure 2). 

Figure 2: V2G PKI architecture 

In Europe, this ecosystem currently relies on a limited number of key trusted players—such as Hubject, Gireve, and Irdeto—which combine the role of root certification authority (V2G Root CA) with Plug & Charge certificate management and interoperability services. 

Within this architecture, the CPO holds a pivotal position: charging stations must be integrated into this trust chain and, depending on the chosen model, the operator may run certain PKI components in-house (make) or rely on a specialized provider (buy). In both cases, the CPO becomes dependent on a trust infrastructure whose compromise, misconfiguration, or unavailability can have a direct impact on service availability. 

The risk, therefore, lies in a loss of service availability caused by an incident affecting the V2G PKI. Several scenarios are plausible: compromise of a root or intermediate authority, expired certificates that were not renewed, corruption of a trust store, or unavailability of a component involved in the certificate lifecycle. In all these situations, the operational outcome is the same: the charging station or the vehicle can no longer establish a valid trust relationship, and the Plug & Charge session fails before charging even starts. 

Key takeaways 

With Plug & Charge, PKI no longer only secures communications, it becomes a critical production component. An incident affecting the trust infrastructure is therefore not just a security or compliance issue, but a potential source of partial or large-scale service disruption. 

The choice between make and buy does not eliminate this risk; it shifts where control lies. A make strategy provides greater control to the CPO, but requires mature PKI governance, robust operational capabilities, and strict discipline over certificate lifecycle management. A buy strategy accelerates deployment but increases dependence on a third party for what has become a critical function, implying stronger requirements in terms of contractual oversight, auditability, and monitoring. 

From a cybersecurity standpoint, the implication is clear: the V2G PKI must be treated as a critical operational asset within the charging stations information system. This entails explicit governance of trust roles, continuous monitoring of certificate lifecycles, regular resilience and continuity testing, and the definition of degraded operating modes to prevent a PKI incident from escalating into large-scale service disruption. 

Risk 2: loss of charging infrastructure availability through the exploitation of vulnerabilities in ISO 15118 communication 

This risk stems directly from the increasing complexity of the communication channel. Where charging historically relied on relatively simple interactions—primarily based on electrical signaling and a limited set of basic messages—ISO 15118 introduces a high-level dialogue built on a much richer protocol stack (Figure 3). 

Figure 3: OSI model applied to ISO 15118 

This shift from a minimalist protocol to a full-fledged application layer—including device discovery, IPv6 address allocation, authentication, certificate management, and cryptographic operations—mechanically expands the attack surface. This is particularly true because the communication interface via the charging connector is inherently accessible, with no physical barriers. Any vulnerability in these exchanges (e.g., manipulation of application messages, injection into PLC traffic, improper certificate validation) could disrupt the charging session—or, in a worst-case scenario, lead to a full compromise of the charging station. 

Exploiting such vulnerabilities, however, requires physical access to the charging point: the attacker must be able to interact with the communication channel between the vehicle and the station. In practice, this involves specialized equipment to connect to the PLC network, such as a HomePlug Green PHY compatible interface and a physical adapter for the charging connector. While this constraint makes the exploit harder, it does not eliminate the risk. Several research efforts have demonstrated the feasibility of lab setups capable of observing, relaying, or disrupting ISO 15118 communications directly at the cable or connector level. 

 Figure 4: Equipment required to exploit a vulnerability on the ISO 15118 interface 

Key takeaways 

To mitigate these risks, CPOs must ensure the security level of their vendors’ products, for example through audits, and assess their cybersecurity maturity, particularly regarding processes for maintaining security over time. 

They must also implement vulnerability management processes across their asset base, including maintaining inventories such as SBOMs and HBOMs (Software and Hardware Bills of Materials), as well as robust patch management practices. This enables operators to identify vulnerable assets and respond effectively when attackers attempt to exploit vulnerabilities on this new communication channel. 

Risk 3: theft of charging station certificates 

The theft of a charging station certificate is not only a cryptographic incident: in an ecosystem built on digital trust, it amounts to a compromise of machine identity. For a CPO, such an incident directly impacts the integrity of exchanges and may open the door to charging fraud. 

Two attack scenarios must be distinguished here: 

• Extraction of the private key associated with the certificate, following a software compromise or a physical attack on an insufficiently protected component, 
• Impersonation of a charging station when obtaining a certificate, for example through an insufficiently authenticated enrolment process between the station and the CPMS (Charge Point Management System).  

Figure 5: attack paths to obtain a charging station V2G certificate 

Once in possession of a valid certificate, an attacker can impersonate a legitimate charging station and abuse the ecosystem’s trust for malicious purposes. In a Plug & Charge context, this could allow an attacker to make a vehicle believe it is establishing a normal session, and then relay the proof of possession of the victim’s contract certificate into another session—effectively charging a different vehicle at the victim’s expense. This relay attack scenario has been demonstrated in academic literature and illustrates how a single compromised charging station certificate can enable tangible, operational fraud. 

Figure 6: exploitation of fraud through relay of the EV’s proof of possession 

This type of attack is facilitated in implementations based on ISO 15118-2, where Plug & Charge security relies on a more limited model, particularly in terms of end-to-end authentication and certificate handling. By contrast, ISO 15118-20 strengthens communication security—especially through the widespread use of TLS and a move toward mutual authentication—making such fraud more difficult to exploit, although not eliminating it if machine identities are not properly protected. 

This risk is all the more realistic because it does not require large compromise: a single valid certificate can be sufficient. An attacker may therefore target the least protected charging station or attempt to fraudulently obtain a certificate through a weak enrolment process or inadequately secured backend. For the CPO, the challenge is not only to protect already deployed certificates, but to secure the entire lifecycle of charging station identities from issuance to storage and renewal. 

Key takeaways 

To mitigate the risk of private key compromise, CPOs must ensure that charging stations provide secure storage capabilities for cryptographic material, for example by integrating a TPM (Trusted Platform Module). 

Preventing impersonation during certificate issuance requires a different approach. CPOs must guarantee the authenticity of certificate requests processed by the V2G PKI. 

This relies on authenticating the charging station when establishing the communication channel with the CPMS. In practice, the protocol used on this channel, OCPP, supports mutual certificate-based authentication (mTLS) from version 2.0.1 onwards. The charging station therefore presents a certificate to authenticate itself to the CPMS. Once the session is established, certificate enrolment requests (including ISO 15118 certificates) are authenticated, significantly reducing the risk of impersonation. 

However, this architecture introduces a prerequisite: deploying a dedicated certificate used to authenticate the charging station on the CPO network. This certificate is distinct from the ISO 15118 certificate used for Plug & Charge, as it serves a different scope and purpose. 

It is therefore necessary to implement a dedicated PKI, operated by the CPO, which can be referred to as a “Product PKI.” This PKI issues the certificates used to secure OCPP communications. The certificate management challenges described earlier also apply to this PKI. CPOs must therefore establish the organizational and technical capabilities required to operate such an infrastructure, including certificate lifecycle management, incident handling, and upskilling of teams. 

We thus arrive at a target architecture in which each charging station embeds multiple certificates issued by distinct PKIs, each serving a specific role in authentication across critical communication channels involved in the charging session (Figure 7). 

 Figure 7: target architecture for Plug & Charge deployment 

Risk summary 

The introduction of Plug & Charge and the ISO 15118 standard is progressively transforming charging infrastructures into a true digital trust chain, where service availability now depends as much on cybersecurity as on the electrical operation of the stations. 

The scenarios analyzed show that the main risks no longer relate solely to technical compromise of isolated components, but have broader impacts on: 

• Service continuity, 
• Charging fraud, 
• User trust, 
• And, ultimately, the operator’s reputation. 

The table below summarizes the identified risks using an approach inspired by EBIOS Risk Manager, based on an assessment of: 

• The likelihood of each scenario (scale from 1 to 4), 
• Its severity for the operator (scale from 1 to 4), with the highest impact being a nationwide loss of trust in the charging infrastructure, for instance, in a scenario where a significant portion of charging stations would no longer allow charging, 
• And the resulting overall risk level. 

Table 1: Summary of risks related to Plug & Charge on charging infrastructure 

This analysis, however, should be nuanced: the scenarios presented deliberately take a cautious, even pessimistic, view of likelihood. In practice, such attacks remain difficult to carry out. They often require advanced technical skills, specific physical or logical access, a deep understanding of ISO 15118, and the capability to exploit or manipulate complex trust mechanisms. 

As such, these risks should be seen as plausible scenarios to anticipate, rather than threats that are currently trivial or widely observed in real-world operations. Their “medium” to “low” risk level reflects this balance: a still-limited probability, but potentially significant impacts if such attacks were to scale. 

Conclusion 

Plug & Charge simplifies the charging experience but introduces a strong dependency on a digital trust chain built on ISO 15118, the V2G PKI, and charging station certificates. This dependency creates new risks for charging infrastructures, potentially leading to service disruptions and, ultimately, a loss of trust from users toward the CPO. 

While these attack scenarios remain difficult to execute, their potential impact justifies addressing them early starting from the design phase. For CPOs, the challenge is therefore no longer limited to securing charging stations but extends to securing the entire identity and trust chain that underpins the charging process. 

Cet article Plug & Charge and ISO 15118: what are the new cyber risks for charging stations?  est apparu en premier sur RiskInsight.

This trajectory, however, relies on the availability of a dense, reliable, and properly dimensioned charging network across the entire territory. Whether for public charging (motorways, public roads, shopping centers) or private charging (homes, businesses), this infrastructure forms the backbone of the electric mobility ecosystem. At the heart of this ecosystem, Charging Point Operators (CPOs) play a structuring role, being responsible for the installation, operation, and maintenance of charging stations. 

Cyber risk is now emerging as a major threat to charging infrastructures, in a context where electrical networks are increasingly targeted by cybercriminal groups and state-sponsored actors12.  For CPOs, this reality is a game changer: mastering cyber risk becomes a prerequisite for service reliability and ecosystem protection. As charging networks expand and grow more complex, cybersecurity challenges become central: data protection, service continuity, securing financial flows, and managing third‑party risks. 

This article is part of a series of three papers exploring three structuring challenges faced by electric mobility stakeholders, with the aim of analyzing their implications from a cybersecurity perspective. 

Rethinking charging infrastructure: balancing operational requirements and emerging cyber constraints 

In the context of strong growth combined with the gradual structuring of the market, CPOs are facing a demanding economic equation. The deployment of charging infrastructures requires significant upfront investments – land acquisition, grid connection, purchase and installation of charging points, supervision, and maintenance – while utilization rates remain heterogeneous across regions and site typologies. Added to this are the volatility of electricity prices, increasing competitive pressure, and the rapid evolution of technological standards, which require regular upgrades. 

As public subsidies tend to be streamlined and investors increasingly expect clearer profitability trajectories, optimizing the economic performance of assets becomes imperative. Maximizing availability rates, fine‑tuning operating costs, improving utilization levels, and diversifying revenue streams are no longer secondary levers, but essential conditions for the long‑term sustainability of CPOs’ business models. 

Charging infrastructures, as designed today, illustrated in Figure 1, generally rely on static power control managed by a central supervision system, the Charging Point Management System (CPMS). This operating model does not allow, or significantly limits, the CPO’s ability to adapt power distribution in real time to usage patterns and site-specific constraints. 

Figure 1: Architecture of a conventional charging infrastructure 

Therefore, several optimization levers can be implemented. 

First, it is possible to enhance the site’s energy flexibility, particularly to support fast charging without having to oversize the grid connection. To achieve this, the deployment of a Battery Energy Storage System (BESS) proves to be an effective solution: this stationary battery storage acts as a buffer, capable of storing energy when it is available and releasing it during peak demand, thereby improving the site’s stability and resilience. 

The next step consists in integrating local, low‑carbon energy production directly at charging sites, making it available for immediate use or storage through the addition of photovoltaic systems. Solar panels, installed on rooftops or canopies, provide this renewable generation layer. Their effectiveness, however, relies on their integration with appropriate control and storage systems, ensuring the environmental coherence of electric mobility. 

Finally, to enable the proper integration of these energy production and storage assets at charging sites, a global control system has emerged: the Energy Management System (EMS). This system supervises and adjusts energy flows on site in real time, aligning them with demand, local constraints, and grid connection agreements. It controls power distribution, anticipates variable charging demand, and maximizes the use of local energy production, thereby transforming a conventional electrical installation into a dynamic and intelligent system. 

Thanks to intelligent energy management via an EMS, battery storage, and the integration of solar generation, this architecture (illustrated in Figure 2) enables performance optimization while keeping costs under control and thus represents a key step towards the next phase of the energy transition. 

Figure 2: Architecture of a next-generation charging infrastructure 

In the remainder of this article, we will focus on three new sources of cybersecurity risk introduced by the integration of Energy Management Systems (EMS) into CPOs’ charging infrastructures. 

The EMS: an optimization lever that has become a critical risk point 

EMS have become a key component of charging infrastructures, enabling CPOs to finely optimize power management and charging strategies. This central role makes EMS a critical point in terms of cybersecurity – their compromise can result in major operational impacts for a CPO: 

• Unavailability of a part of the charging stations. 
• Degradation of energy optimization, resulting in direct financial impacts. 
• Load imbalances that may lead to service limitations or outages at site level. 

Beyond these incident scenarios, the introduction of EMS also fundamentally reshapes the risk landscape to which charging infrastructures are exposed. 

Increased reliance on third‑party infrastructures 

The deployment of EMS solutions is most often based on turnkey offerings, combined with vendor‑operated management platforms hosted in cloud environments. These platforms enable CPOs to centrally manage their entire EMS fleet and support a range of use cases, including optimization of available power, performance monitoring, and remote control of charging strategies. 

This architecture, however, introduces a direct dependency on third‑party infrastructures that lie outside the CPO’s perimeter of control. As a result, it expands the attack surface and increases CPOs’ exposure to supply‑chain‑related risks. 

This issue is further compounded by the fact that these vendors are often small, highly specialized players whose level of cybersecurity maturity can be heterogeneous. A compromise of these platforms may therefore lead to widespread impacts, potentially resulting in the unavailability of a significant share of the EMS fleet operated by a CPO and, by extension, a risk of charging station outages. 

In addition, the compromise of EMS cloud platforms may also lead to breaches of data confidentiality, as it could enable an attacker to collect sensitive operational information, which could notably be exploited for espionage purposes, including: 

• Detailed mapping of charging sites and deployed energy assets. 
• Energy management strategies, revealing the optimization logics implemented by the CPO. 
• Consumption and power data across the CPO’s entire portfolio of sites. 

Local communications relying on weakly secured protocols 

These new architectures also extend the attack surface at the local network level, particularly through communications with energy-related equipment, which still largely rely on weakly secured industrial protocols.  

Unlike exchanges between supervision systems (CPMS) and charging stations, which benefit from the standardization provided by OCPP, communications between the EMS and other components (BESS, charging points, etc.) still predominantly rely on Modbus. 

Originally designed for closed industrial environments, this protocol does not natively implement security mechanisms such as authentication or encryption. In practice, each EMS vendor deploys its own protective measures, resulting in heterogeneous security levels. For CPOs, this diversity complicates the securing of the fleet and may introduce new exploitable weak points within the local network. 

Levers to secure next‑generation charging infrastructure 

Securing next‑generation charging infrastructures relies on a structured approach that makes it possible to reconcile operational performance with effective cybersecurity risk management. 

Ensuring the resilience of charging architecture 

The evolution of charging infrastructures introduces a single point of failure for CPOs: the EMS. To address this risk, it is necessary to design resilient architectures capable of maintaining continuity even in the event of an EMS failure. This can notably be achieved through: 

• The implementation of monitoring and alerting mechanisms, enabling rapid detection of EMS failures and activation of fallback mechanisms. 
• The deployment of degraded operating modes, allowing charging stations to continue operating even in the event of EMS unavailability. 
• The definition of business continuity and disaster recovery strategies that explicitly include EMS failure scenarios. 

Securing dependencies on unmanaged third–party infrastructures 

The evolution of charging infrastructure architectures requires CPOs to address both supply‑chain‑related risks and risks inherent to the interconnection between the CPMS and EMS vendors’ cloud infrastructures. 

To reduce supply‑chain risks, CPOs must implement robust vendor qualification processes, including in particular: 

• Assessment of the vendor’s cybersecurity maturity level. 
• Evaluation of product security, notably through penetration testing. 
• Contractual governance of supplier relationships, including, where appropriate, the implementation of Security Assurance Plans (SAPs). 

Beyond supply‑chain risk management, CPOs must also account for the risks introduced by the interconnection of their infrastructure with EMS vendors’ environments (EMS cloud). Securing these interconnections requires a strong control of data flows between the CPO infrastructure and these external environments. This can be achieved through three main levers: 

• Implementing traffic filtering and control mechanisms between the local charging infrastructure network and external networks, to restrict communications strictly to legitimate third‑party infrastructures. 
• Formalizing secure architectural standards and ensuring their effective implementation during EMS deployment in the field, guaranteeing a consistent application of cybersecurity best practices. 
• Implementing isolation mechanisms to contain potential EMS cloud failures and prevent their propagation across the entire charging infrastructure fleet. 

Securing communications relying on industrial protocols 

Communications between EMS and energy‑related equipment, particularly BESS, still largely rely on industrial protocols such as Modbus, which do not provide native security mechanisms. In this context, securing these exchanges cannot rely on the protocols themselves, but must instead be addressed at the infrastructure architecture level. 

This notably involves: 

• Implementing strict network segmentation within the local network, isolating EMS, BESS, and other components to limit exposure surfaces. 
• Applying fine‑grained control over communications by locally restricting data flows to strictly necessary exchanges (filtering, whitelisting, limitation of authorized commands). 
• Deploying communication monitoring mechanisms to detect abnormal or unauthorized behavior. 

Establishing a structured cybersecurity governance 

To address the diversity of components and infrastructures operated across their charging networks, it is essential for CPOs to structure their environment around clear governance, including in particular: 

• Clarification of cyber roles and responsibilities across the entire value chain (CPOs, suppliers, service providers, etc.). 
• Definition of security standards applicable to all projects and suppliers, ensuring overall architectural consistency. 

By combining rigorous supplier risk management, a solid governance framework, and strict control of data flows, CPOs can fully leverage the operational gains offered by EMS while securing their infrastructure in a sustainable manner. 

Optimizing without compromising: the challenge of charging infrastructure 

To conclude, the rise of Energy Management Systems (EMS) is profoundly transforming charging infrastructures, providing essential optimization levers while also introducing new cybersecurity risks. For CPOs, the challenge is no longer limited to deploying these solutions but extends to securing them within a comprehensive approach that encompasses supplier risk management, the definition of secure architectures, and the establishment of structured cybersecurity governance. In this context, cybersecurity is now emerging as a prerequisite for the sustainable performance of charging infrastructures. 

Cet article Electric vehicle charging infrastructure: energy performance and new cybersecurity challenges est apparu en premier sur RiskInsight.

Where does the sector stand? 

The rise of Part-IS has been gradual. After the progressive entry into force of the texts in 2022 and 2023, 2025 was marked by the preparation of compliance files and the structuring of ISMS.

Since 22 February 2026, the implementing regulation has been fully applicable, meaning that new scopes are now covered — in particular, maintenance and repair activities through Part-145. Part-IS now applies across the entire operational chain, from design through to operations and support. 

Today, the organisations concerned by Part-IS have acknowledged the subject and submitted their ISMS. In this context of broad engagement, EASA has on its side adjusted the framework by clarifying and easing certain modalities through the update of the Part-IS AMC and GM. 

EASA provides for an 18-month development phase after the applicability date to reach a fully operational implementation. This progression can be read simply in three steps: a system that is first present and suitable (P+S), then operational (O), before reaching effective long-term functioning (E). 

EASA updates: What you need to know in practice

In late 2025, EASA updated the AMC and GM relating to Part-IS and consolidated these changes in a new version of the associated Easy Access Rules. 

In concrete terms, these changes introduce several significant easements: 

• Declared organisations no longer need prior approval of their ISMS.
  • As a reminder, approved organisations are subject to a formal approval process by the authority (EASA or national authority). They must obtain approval, have their ISMS manual approved, and submit certain modifications for prior validation — unlike declared organisations, which are supervised ex post by the authority. The list of declared organisations subject to Part-IS can be found here. 
• ISMS modifications, when covered by a defined internal procedure, no longer require formal sign-off from the authority: a notification is sufficient. 
• The role of the authority is refocused on supervision and audit, rather than on a systematic approval logic. 

However, expectations remain the same: the ISMS (SGSI in the regulatory sense) must be robust, consistent, traceable, and genuinely applied. The relief brought by the AMC and GM update is therefore administrative, not operational. 

On the ground, this resonates with the first OSAC feedback on ISMS: governance around the ISMS appears as a central point. Authorities are paying increased attention to the cybersecurity dimension that identified actors must demonstrate. Document quality is also scrutinised — not only in substance, but also in form (structure, consistency…). 

The five key challenges for scaling Part-IS across the sector 

Beyond these initial observations, we have seen during our support engagements that the implementation of Part-IS brings five recurring challenges for most organisations: governance & coordination, inventory validation, completion of risk analyses, training of managers and teams, HR constraints and personnel controls. 

The most time-consuming, however, remains the risk analysis — particularly for large multi-site organisations. This can no longer be purely centralised; it must be broken down locally, integrating the realities of each site, functional chains, and subcontractors. This holistic approach is demanding, but essential to demonstrate consistent application of Part-IS. 

A pragmatic approach to scaling up 

Faced with these challenges, the key lies in anticipating deployment. An effective ISMS relies on a solid common foundation, but also on concrete tools enabling local adaptation: templates, guides, risk analysis methods tailored to operational realities. 

The success of Part-IS depends on coordination between cybersecurity teams, business teams, and quality and compliance functions. Part-IS is not an additional layer: it is a cross-cutting framework that durably structures cyber risk management in the service of aviation safety. 

Conclusion 

In 2026, Part-IS enters its implementation phase. The consolidation of the AMC/GM sets a clear baseline and reduces the administrative burden compared to the first version. 

In addition, the late-2025 updates notably extended the scope of Part-IS.D.OR to ground handling service providers via Delegated Regulation (EU) 2025/22 amending (EU) 2022/1645, applicable from 27 March 2031. No immediate operational impact in 2026, but a useful signal to anticipate interface mapping — with no short-term urgency. 

Cet article Part-IS in 2026: from regulatory framework to operational reality est apparu en premier sur RiskInsight.

This guide directly follows the publication of the second version of ANSSI’s Industrial Systems Classification Method in March 2025, which we had already analyzed in a previous article. 

An update built on continuity: the same structure, the same underlying logic

Key differences between the first and second versions of the detailed measures guide 

In terms of structure, the 2025 guide remains very close to the 2014 version. It opens with a reminder of the constraints and weaknesses specific to industrial environments, followed by a clear separation between organizational and technical measures. The themes themselves will come as no surprise: governance, access control, network segmentation, remote access, backups, supervision, vulnerability management, cybersecurity integration throughout the system lifecycle, and incident preparedness. Continuity is clearly intentional. 

This stability has an advantage: organizations already aligned with the 2014 guide do not have to start from scratch. At the same time, it also highlights the fact that most of the “core topics” were already well identified more than a decade ago. The real question is therefore less “what is new?” than “what has become more actionable — and at what cost?”. 

On this point, the guide is explicit about its scope. It proposes a minimum baseline intended, among other things, to support security accreditation processes. However, it does not claim to replace IEC 62443, nor does it position itself as a certification framework. It simply reuses some of its principles and requirements, while clearly stating that the measures alone are not sufficient for the most critical systems. 

What has changed in concrete terms 

The most visible change is not the introduction of new topics, but a new way of expressing requirements. 

In 2014, the guide relied on a structuring distinction between recommendations (R) and directives (D), with a hardening mechanism depending on the cybersecurity class. In 2025, this grammar disappears. The guide now introduces a class based reading (C1 to C4) and several variants: 
– state of the art recommendations, 
– lower level alternatives, indicated by a “–”, 
– and reinforced complementary recommendations, indicated by a “+”. 

Typical structure of a recommendation 

A second major evolution is the explicit introduction of a fourth cybersecurity class and the strengthened alignment with IEC 62443, in line with the updated classification method. For each recommendation, a correspondence with an IEC 62443 requirement is indicated when it exists and referenced in a dedicated appendix. 

According to Appendix B, a large proportion of the 214 recommendations have a direct equivalent in the previous version. This confirms that the overhaul is primarily based on reorganization and reformulation rather than a fundamental shift in doctrine. After analyzing the 35 measures identified as having no direct equivalence, it appears that they are not necessarily new. They typically reflect: 

Categories of reasons for no direct equivalence, with illustrated examples 

Summary of recommendations with no direct equivalents in Annex B 

A more architecture-driven doctrine on interconnections and remote access 

Where the 2025 version truly changes the dynamic is in certain topics that are handled in a more structured way. In the first version, the doctrine on interconnections and remote access was already relatively prescriptive: it emphasized that remote management greatly increases the attack surface, set out operational rules, and even went as far as banning remote maintenance in class 3, using a logic of one-way (unidirectional) data flows. 

The modernization brought by the 2025 version makes the whole set more coherent and better structured: it moves from a reasoning mainly centered on components and means (firewalls, VLANs, data diodes, VPNs) to an interpretation in terms of security functions that must be combined and positioned according to the classes and the flow directions in Table 3. The rows of the latter correspond to the issuing class (“from”) and the columns to the receiving class (“to”); the icons indicate the security functions to implement in order to authorize the flow in that direction. For example, from class C1 to IT, only a system that can verify whether the data comes from an authorized source—Aut(IT)—is required. 

Summary of Table 3 – Section 4.2.1: all listed measures are associated with a data transfer unidirectionality function 

It should be noted, however, that the definition of Inno (OT) is not explicitly provided in the document. 

From framework to on-the-ground implementation 

The 2025 version of the Detailed Measures logically brings to a close the overhaul initiated with the publication of the second version of the classification method, and it strengthens compatibility with IEC 62443. In a context where the threat to industrial environments is now highly visible, this document comes at just the right time: it’s an opportunity to adjust your action plan—or even to launch a full 2030 roadmap. A guide that isn’t put into practice has never stopped an attacker! 

Among the priority workstreams that are regularly identified, we often see: 

• Revisit the IT mapping and the business’s dependencies on IT 
• Adapt the technical architecture by trading “new authorizations” for stronger authentication and better content control 
• Harden and centralize remote access, especially given the many suppliers present in industrial environments 
• Strengthen industrial environments or connect them to your SOC 

Cet article Industrial cybersecurity: the ANSSI “Detailed Measures” guide overhaul  est apparu en premier sur RiskInsight.

Quantum Threats: a new era for industrial cryptography 

Quantum computing represents a threat to traditional cryptographic algorithms which guarantee integrity, authenticity and confidentiality of communications, including those of OT systems and products. Even if “Q-Day” (the day quantum computers will break current cryptography) is still several years away, the risk is already present: threat actors can already use « Harvest Now, Decrypt Later » attacks by storing encrypted data today to decrypt them as soon as current cryptographic algorithms are broken. Another risk, just as critical, is already appearing: « Trust Now, Forge Later ». Digital signatures or certificates seen as reliable today could be falsified tomorrow, allowing transparent deployment of malwares or even compromising supply chains. Unlike progressive data breach, this attack triggers an immediate collapse of trust and integrity, with massive impacts on industrial environments and smart products. With the European roadmap, structuring 2026, 2030 and 2035, the question hinges on the sequencing of the transition. 

Within the industrial sector, where assets are used for multiple decades, this represents a major concern: OT environments and embedded products depend on critical cryptographic usage that will be directly impacted by the arrival of post-quantum algorithms. 

Key OT and product use cases include: 

• Secure administration of OT systems and products: guarantee the integrity and confidentiality of operations. 
• Digital signatures and firmware integrity: guarantee the reliability of software updates (secure boot, code signing, X.509…). 
• Secure remote access to industrial assets and products: protect VPN, SSH, RDP connections as well as other protocols from future attacks. 
• Data exchanges IT/OT: secure flows between information systems and industrial environments (TLS, MQTTS, HTTPS…). 
• Data confidentiality of industrial processes: preserve the confidentiality of sensitive data in transit or at rest. 
• Secure logging and event history: ensure the traceability and integrity of logs and historical data. 

PQC for OT & Products: Address the constraints while preserving crypto-agility 

OT & Products context: specific constraints 

OT systems and products were never conceived for crypto-agility. Numerous industrial protocols, for instance DNP3, Modbus or MQTT, are not encrypted as of today because OT architecture historically depends more on network isolation than on cryptography, thus there is no reason to think they will be encrypted tomorrow with post-quantum algorithms. 

Nevertheless, encrypted communications will undergo this cryptographic disruption. 

In a second step, multiple OT devices face significant hardware constraints (CPU, memory, storage capacity) and have a very long lifespan, often between 10 and 30 years. Those characteristics make updates difficult and expensive: secure remote update mechanisms are still rare, and firmware signing is not consistently implemented, which is in fact bad practice. 

Those constraints explain why OT environments cannot integrate new cryptographic primitives at the same speed as IT, and why PQC isn’t yet natively considered. 

Nevertheless, even if current products and OT systems aren’t conceived for post-quantum cryptography, the emergence of PQC standards, the evolution of regulatory obligations and the rise of risks linked to quantum computing make this transition essential in the medium term. 

Making crypto-agility operational for the industry and products 

The scoping of the PQC project for Products and OT can be broken down into four main components: 

1. Conduct the cryptographical inventory and prioritize critical assets  

Start the dialogue with your cryptographic platform providers (PKI, KMS, HSM) now, to anticipate the migration. 

2. Conceive and deploy crypto-agile architectures 

Rely exclusively on NIST-standardized algorithms (for instance: ML-KEM, ML-DSA, SLH-DSA) and prohibit any internal development or non-standard library for cryptographical components; prioritizing validated and proven solutions. 

Conceiving crypto-agile architecture implies accounting for the embedded aspect and its constraints (limited memory, PCBs, energy resources). The implementation of PQC algorithms on those systems remains uncertain. Nevertheless, optimized algorithms for embedded systems are starting to emerge and open the way to its realistic adoption. 

3. Progressively migrate through hybridization and iteration  

Transition towards post-quantum cryptography cannot be approached as a one-off project or a “one-shot” migration. It is an iterative process that must be managed and governed over time, by starting with hybridization of algorithms: this is explicitly recommended by ANSSI (France’s National Cybersecurity Agency) and the European Commission. 

Crypto-agility isn’t an option, but a necessity to ensure resilience and compliance for industrial environments and products from the quantum threat. This depends on a structured approach, driven by inventory, architecture, hybrid migration and governance.  

Operational feedback & concrete use cases: stakeholders at different stages 

Our field experience reveals a noteworthy maturity gap between two industrial organizations when dealing with post-quantum cryptography: 

1. Organizations with a rudimentary understanding 

•  Observation: In numerous industrial environments, PQC remains an abstract concept, often seen as distant or limited to experts.  
• Symptoms:  
  • Operational and business teams aren’t part of strategic deliberations on cryptography. 
  • Current roadmaps lack maturity and clarity; the underlying projects costs are often underestimated. Priority remains on service availability; quantum security is therefore deprioritized. 
  • HNDL & TNFL concepts are poorly understood, if not outright ignored.  
• Risks:  
  • Disruption of industrial production processes and data breaches: vulnerable communications between critical assets, based on outdated algorithms, expose sensitive data and can cause interruptions or major disturbances in industrial operations (loss of integrity of the data). 
  • Production downtime caused by abrupt migration: A forced transition towards post-quantum cryptography, without preparation nor crypto-agility, can lead to production interruptions, significant additional costs and severe impacts on operational continuity. 

2. Product suppliers: pioneers already undergoing industrialization 

• Observation: On the contrary, some product suppliers are already ahead (including automotive and smart objects). 
• Symptoms:  
  • PQC projects are prioritized over critical use cases: firmware and update signatures (OTA), device identity management, secure remote access, etc. 
  • Pilot projects are being launched on product lines or representative environments, with concrete feedback on performance, compatibility and robustness of hybrid solutions  
  • The process is being industrialized: Integration of PQC clauses in supplier contracts, automation of cryptographic inventory CBOM, team upskilling, and dedicated governance.

Conclusion & Roadmap: Take action to build a quantum-safe future 

Quantum threat is no longer a distant prospect: it already demands a significant transformation of industrial and product cybersecurity. 

1. Plan ahead to protect the future 

Demystify quantum concepts and incorporate them in your cybersecurity processes, including your products, your OT environments or your IT systems. Planning ahead is the key to preventing a major disruption. 

2. Make crypto-agility a strategic vision

Stop viewing it as merely a technical project, but as a pillar of your resilience and of your digital sovereignty. Build a clear roadmap, with milestones in the short, medium and long term. 

3. Rely on trusted partners 

The market is ready: experts and solutions exist to support you through the modernization and securing of your critical infrastructure. Don’t face complexity on your own.  

4. Industrialize the process

Move from pilot projects to broader rollout:  

• Implement a PQC strategy to map out, prioritize and pilot the migration of critical uses (include PQC clauses in contracts). 
• Start a transition program to modernize trust infrastructure components (PKI, CLM, HSM), automate the inventory and ensure the operational continuity. 
• Rely on peers’ feedback as well as feedback from sectors already engaged in PQC. 

Quantum risk is already there: weakened asymmetric encryption, leaving signatures and data exposed. 

As mentioned previously, we start from the observation that elements that aren’t encrypted today in OT environments are not meant to be encrypted tomorrow with post-quantum algorithms, because already existing measures ensure a risk level judged acceptable. 

In other words, PQC doesn’t aim to transform the entirety of OT, but to protect the uses that really rely on cryptographical components exposed to quantum risk. 

However, this observation doesn’t reduce the importance of planning. 

The two priorities remain as follows: 

• Migrate your assets before 2030 and act today to protect data confidentiality 
• Define your perimeter, build your roadmap, and above all, begin the migration process today. 

Cet article Post-Quantum Cryptography for products & OT: From trends to industrial reality est apparu en premier sur RiskInsight.

Cyberattacks no longer target only internal information systems. They increasingly exploit external dependencies, where governance, visibility, and control are often weaker. A vulnerability affecting a third party can now lead to direct impacts on production, personnel safety, regulatory compliance, or the organization’s reputation. 

The attack suffered by Jaguar Land Rover in 2025 illustrates this reality: the shutdown of systems paralyzed the production chain and its partners, preventing the manufacture of more than 25,000 vehicles and resulting in estimated losses of nearly one billion pounds. 

Managing third-party cyber risks is therefore no longer a peripheral issue. It is a central component of any industrial cybersecurity strategy, commonly referred to as TPRM (Third-Party Risk Management) or TPCRM (Third-party Cyber Risk Management). These concepts cover the overall management of third-party risks and its specific application to cyber risks. 

Third parties driving the industrial value chain 

The concept of a “third-party” refers to any external entity or individual that collaborates with an organization and interacts with its systems, data, or processes. These actors contribute directly or indirectly to the company’s activities and collectively form what is known as the supply chain. 

In industrial environments, third parties can generally be grouped into five major categories, reflecting the diversity of roles they play in the operation and maintenance of industrial systems: 

Mapping third parties across the supply chain 

To ensure seamless operational continuity, industrial organizations rely heavily on external service providers. This dependency, driven by the outsourcing of critical activities and regulatory requirements, turns each supplier into an essential link in the chain. A single compromise affecting a third-party can be enough to halt production, disrupt operations, and expose the organization to major risks. 

An extended supply chain: difficult to manage and vulnerable 

The diversity and number of third parties present several major challenges for organizations. First, the third-party ecosystem is often extremely large: a single organization may rely on hundreds or even thousands of partners. 

This scale is compounded by significant complexity, as the supply chain does not stop with direct third parties, but also includes their own service providers, which are essential to their business continuity. As one moves down these successive levels (fourth parties, n-parties and beyond), the client organization’s visibility into its third parties decreases sharply: 

An illustration of supply chain complexity  

This combination of breadth and depth makes it particularly difficult to maintain overall control of the ecosystem. For example, it is estimated that only 3% of organizations have full visibility across their entire supply chain (Panorays, 2025). This lack of visibility creates a broad and difficult-to-manage risk surface. 

Third party risks: a growing threat under regulatory pressure 

In recent years, there has been a significant increase in cyberattacks involving third parties. This trend is particularly pronounced in industrial environments, where third parties are often involved in critical and vulnerable processes: remote access to systems, physical access on site, identity and access management, and the integration of software or hardware components. 

These figures highlight two key observations. First, third-party risks are very real and represent a growing threat to the cybersecurity ecosystem. Second, the maturity level of organizations remains globally insufficient, even as TPCRM emerges as a strategic lever for risk reduction. 

These findings are now reflected in regulatory frameworks. The European NIS 2 Directive, currently being transposed into national laws across EU Member States, requires affected organizations to manage risks related to their supply chains. Managing cyber risks linked to third parties is thus becoming a full-fledged regulatory requirement, with potential penalties of up to €10 million or 2% of global annual turnover in the event of non-compliance. 

Adapting third party risk management to  industrial needs 

In light of these challenges, how can organizations structure effective third-party cyber risk management? While approaches vary, several key principles consistently emerge: 

• Cross-functional stakeholder involvement: Third-party risk management cannot be the sole responsibility of IT or cybersecurity teams. Procurement, operational teams, and business units must be fully involved, as third parties operate across all levels of the organization. 
• Lifecycle-based approach: Risk must be considered from supplier selection through to the end of the commercial relationship. Each phase (contracting, onboarding, operations, and offboarding) should be governed by appropriate security requirements. 
• Clear contractual requirements: Contracts should formally define and include explicit cybersecurity obligations to ensure a consistent level of protection throughout the collaboration. 
• Third-party prioritization: Security efforts must be proportional to the criticality of partners (e.g., level of system integration, operational dependency, sensitivity of exchanged data, relationship history). Assessing their operational role and cyber maturity helps focus resources on the most critical third parties. 
• Collaboration and information sharing: Supply chain resilience depends on the ability of stakeholders to share information and coordinate responses in the event of an incident. 
• Tooling and automation: Given the volume of third-parties, automation, continuous assessment, and the use of specialized tools are becoming essential enablers. 

To support organizations in this approach, several authoritative references exist, including NIST SP 800-161 Rev. 1 “Cybersecurity Supply Chain Risk Management Practices for Systems and Organizations” (2022) and ENISA’s “Good Practices for Supply Chain Cybersecurity” (2023). 

TPCRM: strengthening industrial resilience 

In an industrial context where cyber risks are becoming systemic, supply chain security can no longer be addressed through a purely technical lens. It is now a strategic issue of governance and resilience. 

A mature TPCRM approach not only supports regulatory compliance but, more importantly, enables organizations to better anticipate crisis scenarios, limit operational impacts, and strengthen trust across their partner ecosystem. 

By combining governance, processes, technologies, and collaboration with the wider ecosystem, TPCRM establishes itself as a key strategic lever for sustainably securing industrial environments. 

Cet article TPCRM for OT: managing cyber risks across the supply chain est apparu en premier sur RiskInsight.

Industries such as pharmaceuticals, chemicals or agri-food heavily rely on laboratory equipment, especially for quality control, R&D or chemical analysis. These instruments are vital for numerous business processes, many of which are critical for operational and regulatory compliance (i.e. in pharmaceutical industries, quality control of raw materials and finished products for batch release, or the production of regulatory reports). As a result, ensuring the availability and reliability of laboratory equipment is a top priority for these companies. However, these devices—originally designed to operate in isolation—are now increasingly connected to improve operational efficiency through automated data collection and harmonized analytical methods across sites.

These operational requirements have driven the widespread adoption of Laboratory Information Management Systems (LIMS). In pharmaceutical settings, LIMS manages analytical batch records, monitors quality parameters, and provides full traceability for regulatory audits. In environmental testing, they streamline data collection, validation, and reporting, reducing manual errors. In food safety labs, LIMS automate compliance reporting and trigger alerts when contamination thresholds are exceeded.

Centralizing the management of laboratory equipment data with LIMS requires instruments to be networked, even when this was not initially anticipated by manufacturers. This increased connectivity thus brings new cybersecurity challenges, as many laboratory systems are based on outdated technologies and thus potentially increase the attack surface.

Obsolete Systems: A Growing Security Risk

Many laboratory devices still run on proprietary or outdated operating systems (such as Windows XP) that no longer receive security updates. These legacy systems are highly vulnerable to known exploits and are difficult to patch.

Manufacturers rarely release patches for obsolete equipment, despite the long lifespan of these devices. Once deployed, patching is further complicated by governance issues—specifically, determining who is responsible for applying updates.

Most laboratory instruments also have limited built-in security features. They often use unsecure or outdated communication protocols (such as HTTP, FTP, or SMBv1/v2) and are frequently deployed with poor configuration practices, further weakening their security. Although newer models support secure standards like OPC UA or SFTP, these features are not always enabled or properly configured.

Figure 1: Typical industrial network architecture in pharmaceutical manufacturing.

Identity and access management is another major challenge in laboratory environments. Many devices still rely on default or shared local accounts and cannot enforce proper authentication mechanisms. These systems are rarely compatible with centralized directories through protocols such as LDAP, making it difficult to enforce consistent security policies across multiple sites. While from an operational perspective authentication may not seem necessary, when combined with obsolete operating systems, insecure communication protocols, and limited access control, these weaknesses turn laboratory devices into easy entry points for cyberattacks.

As laboratories increasingly interconnect their instruments with LIMS, cloud analytics, and centralized data historians, this lack of cybersecurity hygiene not only directly exposes devices but also puts the broader corporate network at risk.

Securing Laboratory Systems with Isolation and Gateways

When laboratory equipment cannot be secured due to its inherent limitations, exposure must be minimized as much as possible. This involves placing such devices behind secured intermediary systems—such as dedicated gateways or workstations—and defining specific network zones to limit the surface of a potential compromise. By segmenting the network and filtering data flows, potential compromises can be better contained and the impact on other critical systems limited.

Three key solutions can enhance security in this context:

• Workstations equipped with cybersecurity tools to ensure compatibility between lab equipment and secured networks. This approach works best when modern workstations act as intermediaries, translating data securely and enabling monitoring. In reality, this approach has been the historical way to interconnect laboratory devices to manage them and manipulate their data.
• Laboratory equipment isolation from broader network environments to limit exposure. This approach extends standard network segmentation practices to laboratory systems, controlling their exposure without fully isolating them, and maintaining necessary data flows for operations. It is cost-effective and easy to deploy, making it ideal for older systems that cannot be patched.
• Edge devices for protocol translation and network isolation. These devices are highly effective for environments needing real-time data exchange between incompatible systems.

Figure 2: Pharmaceutical network architecture implemented with laboratory equipment protection measures.

While these solutions help secure industrial environments, they also introduce new challenges such as patch management and equipment ownership — critical factors in maintaining long-term security. Ultimately, these are responses to an initially unsecured situation, and therefore not perfect: for instance, using workstations as gateways is a good practice, but it requires patching, lifecycle management, and can come with added costs and increased footprint in server rooms (increased infrastructure requirements).

The choice of solution to mitigating cybersecurity risks must align with organization’s technical constraints and operational context. A few common practices help illustrate the diversity of strategies:

• Laboratory equipment isolation in a dedicated VLAN remains an effective first step. However, even segmented systems must rely on secure communication protocols to ensure data integrity and prevent unauthorized access.
• Edge devices offer another layer of protection. But they come with their own set of challenges, particularly around organizational ownership, management and maintenance responsibilities.
• Workstation equipped with cybersecurity tools often act as gateways by default, converting data into formats that can be read and processed downstream — whether by LIMS, cloud platforms, or internal databases. This setup is common and secured as long as the workstation is properly managed and hardened to avoid becoming single points of failure or introducing additional attack surfaces. Implementing this intermediary layer is ideal but this requires developing or integrating reliable translation mechanisms, sometimes not handled by the vendor.

Conclusion: Strengthening Cybersecurity in Laboratory Environments

In given industries, ensuring the integrity of data, quality of final product and the safety of consumers remains one of the priorities. However, as laboratories become increasingly digitalized and interconnected, new use cases are emerging that challenge traditional architectures and operational models. This evolution demands a more comprehensive, end-to-end approach to cybersecurity—one that integrates technical safeguards, process maturity, and clear governance throughout the laboratory ecosystem.

Implementing a cybersecurity-by-design approach throughout the entire project lifecycle is essential—not only to anticipate risks early but also to support business teams in integrating security seamlessly into their operations.

The Cyber Resilience Act (CRA) will reinforce the cybersecurity of digital assets within the European Union for manufacturers as well as importers and distributors of such assets.

To go further: Cyber Resilience Act: A revolution redefining product security and transforming the ecosystem – RiskInsight

Cet article Protecting Connected Instruments: A Growing Challenge for Laboratories est apparu en premier sur RiskInsight.

In a previous article: Cybersecurity monitoring for OT, Current situation & perspectives we have seen that OT, while overall less impacted than IT, is not exempt from cyberthreats & not immune to cyberattacks. But, due to the difficulty in updating legacy Industrial Control Systems (ICS), cybersecurity measures are often added after deployment. Continuous monitoring is seen as a practical substitute for built-in, cyber-by-design protection. 

When it comes to monitoring tooling, we observed that 100% of our clients have detection tools deployed on the IT side of industrial sites. But only one-third extend monitoring down to the lower layers of the industrial environment:

There is a large variety of detection sources allowing monitoring across different levels of the Purdue model:

• Firewalls (including industrial firewalls)
• Endpoint protection (AV, application whitelisting, EPP, EDR etc.)
• Authentication and access logs (e.g., Active Directory, local authentication)
• Remote access logs (e.g., VPN, jump servers, bastion)
• Deceptive technologies (e.g., honeypots or decoys)
• Network detection and monitoring probes (listening industrial networks)
• Logs from media sanitization or data transfer stations (e.g., USB kiosks)
• Industrial logs (from SCADA, HMI, PLC … when available)

Traditionally, these logs are collected and analyzed by SIEM and/or SOAR solutions, with or without specific OT detection patterns, and should enable the SOC team to detect, investigate, and respond to security events.

Building a consistent detection strategy for OT environments does not require collecting data from every possible source. In fact, a few well-chosen, properly configured, and actively monitored sources can provide strong visibility and early detection capabilities. The key is to focus on data sources that are both relevant to the specific OT architecture and feasible to monitor without disrupting operations. Prioritizing quality and operational relevance over quantity ensures a more effective and sustainable cybersecurity posture.

How to get the most of detection sources?

Start with logs you already have

A pragmatic and cost-effective way to approach OT detection is to start by leveraging the logs and detection patterns already available within the industrial environment, particularly those already exploited for your IT environments. For example, firewall logs, especially those monitoring IT/OT boundaries, can provide valuable insights into network traffic patterns, segmentation breaches, or suspicious remote access attempts. Similarly, Active Directory (AD) logs can reveal abnormal user behavior, failed authentication attempts, or privilege escalations — all of which are critical signals in both IT and OT contexts. Leveraging these existing sources allows organizations to build initial detection capabilities without heavy investment, while laying a solid foundation for more advanced monitoring in the future.

Rather than starting with deploying complex OT-specific detection tools, organizations should build initial detection capabilities using what is already deployed, configured, and understood. This not only reduces costs but accelerates implementation across industrial sites. The goal is to ensure a consistent baseline of visibility across critical applications, systems, and infrastructure before diving deeper.

By starting with what you already have, and focusing on coverage, not complexity, organizations can address OT detection with speed, relevance, and operational realism, while setting the stage for more advanced capabilities down the line.

We will now focus on the two detection tools most widely adopted and discussed in industrial environments today: EDR solutions and OT network detection probes.
In the following sections, we will examine how to leverage these solutions effectively and outline our recommendations.

EDR

Endpoint Detection & Response solutions provide continuous monitoring and analysis of endpoint activities to detect, investigate, and respond to cyber threats in real time. EDR collects detailed data such as process execution, file changes, network connections, and user behavior. By leveraging behavioral analytics and threat intelligence, EDR tools can identify suspicious activities like malware infections, lateral movement, or privilege escalation.

This detection tool, widely used and popularized in IT environments, is now being adopted by most of our clients for deployment within their industrial environments, driven by the evolution of deployment models, the broader coverage of operating systems, and the improved performance of detection models in increasingly complex environments.

However, this does not mean that 100% of OT devices are compatible with EDR solutions. In fact, EDR compatibility varies significantly across different industrial systems due to their diversity and operational constraints. EDR deployment is generally straightforward on higher levels of the Purdue model, such as Layer 3 and Layer 3.5, where systems resemble traditional IT environments like servers and workstations. At Layer 2, implementation requires careful evaluation with vendors support and testing, as devices and protocols become more specialized and resource constrained. Finally, at the lowest levels, controllers, PLCs, and field devices, EDR is generally not viable due to limited processing capacity, proprietary operating systems, and real-time performance requirements.

For environments that support it, extending EDR coverage allows to:

• Address low maturity: Start with tools that are easier to implement and require less maturity.
• Broad coverage: Focus on quickly covering a wide range of systems, sites, and critical applications.
• Leverage IT tools: Use IT-based solutions like EDR for effective detection without heavy infrastructure requirements.

To conclude, deploying EDR Agents on OT Servers and Workstations is becoming increasingly relevant, and a quick win for OT detection, according to our clients’ feedback.

OT Probes

A detection probe is a piece of equipment, virtual or physical, connected to the information system in order to map and monitor it. It consists of sensors distributed across the network to collect data. And typically, a central console to aggregate, correlate and analyze this data.

Probes for industrial environments, which we will refer to simply as OT probes here, are characterized by their passive, non-invasive listening on the network, and their understanding of industrial protocols and behavior. All their probe solutions work on the same principle: network traffic is collected using flow duplication (SPAN, ERSPAN …) or physical duplicator like taps, etc. Packets are inspected in real time to provide several types of data: flow inventory and mapping, asset and vulnerability management, and finally anomaly and incident detection. OT probes promises wide detection capabilities and variety of possible cases of these data. The features and types of users involved (operational and business team, cybersecurity team, etc.) is what makes OT probes so popular. 

However, our clients often face significant challenges when it comes to deploying these probes and effectively leveraging them for detection at scale.

Here are a few common pain points when deploying OT probes:

• Industrial site network capabilities and resources: Deploying OT probes often presents significant challenges due to the limitations of industrial network infrastructure. Network taps and SPAN ports on switches, commonly used for traffic monitoring, are not always manageable or available in OT environments, which limits options for passive traffic capture. Additionally, the costs associated with installing dedicated network taps can be prohibitive, especially across distributed and remote industrial sites. Moreover, deploying and maintaining probes requires skilled resources on-site.
• OT probes collect and correlate information through network traffic capture. To be effective, their deployment requires carefully selecting listening points based on the intended targets. Listening points need to be tailored to each site architecture, often limited by local team knowledge and lack of documentation. Moreover, because industrial environments vary between different sites within the same organization, it is very difficult to establish a one-size-fits-all blueprint. In some architectures, achieving comprehensive asset coverage may require deploying dozens of collection points. As a result, selecting and configuring listening points is a repetitive, iterative process that must be adapted for each location to ensure optimal visibility and detection capabilities.

More than deploying, operating these probes also comes with challenges and requires a significant workload. They tend to generate a high number of false positives, which means teams must create tailored detection rules and playbooks to filter and respond effectively. On average, we estimate that one full-time SOC analyst is required to manage the alerts generated by 50 probes.

In the end, OT probes may be popular, but deployment and tuning costs and resources limit their full utilization. Our recommendation is to prioritize deploying OT probes for critical sites or within key network segments that demand advanced industrial and network monitoring capabilities. Deployment should also be aligned with the organization’s capacity to manage the associated tuning and operational workload. This approach helps maximize return on investment while ensuring effective detection where it matters most for our clients.

Consider other solutions?

Regarding detection for industrial perimeter, while this article focuses on key detection sources like EDR and OT network probes, it is important to acknowledge that other solutions such as deceptive technologies (e.g., honeypots or decoys) can also play a valuable role and be relevant in specific scenarios or environment according to your industrial sites architecture or feared compromission scenarios.

Conclusion

To conclude, here are the key recommendations to build an effective detection tooling strategy to monitor industrial environments       :

1. Leverage existing tools for immediate impact:

Begin by maximizing the value of detection sources already available in your industrial environment: firewall logs, active directory, remote access logs… and EDR, that can be quickly implemented on OT servers and workstations, offering high visibility with minimal effort. Adapting proven IT detection logic to OT use cases enables organizations to rapidly establish a baseline level of visibility without the need for heavy investments or complex integrations. This pragmatic approach ensures faster deployment and broader coverage of your OT assets.

2. Deploy advanced solutions where you can manage the workload

When extending your detection capabilities, prioritize the deployment of advanced tools like OT network probes where they provide the most value. For network probes, focus on critical sites or segments, and carefully select listening points to balance visibility, cost, and operational overhead. This targeted deployment approach ensures resources are used efficiently and strategically.

3. Prioritize quality and relevance over quantity

Building an effective OT detection strategy does not require monitoring every possible data source. Instead, focus on sources that are both relevant to your environment and technically feasible to collect without disrupting operations. This approach allows reducing log storage and management costs and enable the creation of more relevant, high quality detection rules.

Do not hesitate to reach out to discuss how you can build and improve your detection strategy to monitor your industrial assets!

In our next article, we will look at how to evaluate detection in industrial environments using purple team exercises, a practical way to assess and improve your detection capabilities.

Cet article Cybersecurity tooling strategy for an effective industrial detection est apparu en premier sur RiskInsight.

In 2024, the number of connected IoT devices worldwide was estimated at around 18 billion, more than double the world’s population. From connected alarms to smart elevators, industrial sensors, and medical devices, these technologies now shape our daily lives. 

Recent advances in the field of IoT have transformed the way we interact with connected objects. Designed to be intuitive, they are accessible without specific expertise. The connections between them, often wireless, go almost unnoticed by users. However, behind this apparent simplicity lie sophisticated communication protocols, including MQTT.  

Due to its popularity and growing presence in sensitive operations, MQTT has been the subject of research for several years regarding the risks associated with its use. Here, we will focus on how it works, its potential vulnerabilities, and best practices for ensuring secure communications. 

MQTT and the reasons behind its popularity 

This protocol’s strengths 

Developed in 1999 by Andy Stanford-Clark (IBM) and Arlen Nipper (Arcom), MQTT was designed to provide a lightweight, efficient solution with low energy and bandwidth consumption for monitoring isolated oil pipelines in the desert via satellite link. 

It is precisely because of these fundamental properties that MQTT has now established itself as the standard for IoT data transmission. This protocol is also frequently used to upload data from sensors or connected objects to cloud platforms. 

Figure 1 – MQTT key features 

How it operates 

Definitions of key terms 

MQTT Client: A device that exchanges information. 

MQTT Broker: An intermediary entity that allows MQTT clients to communicate and through which all MQTT messages pass. Specifically, the broker receives published messages and distributes them to the relevant recipients (subscribers to the corresponding topic).  

Topic: A string of characters used to filter and organize messages according to a hierarchical structure. When a client posts a message, they associate it with a topic.  

Publish/Subscribe: A model derived from the classic client/server model, in which requests are not initiated by a client requesting resources from a server, but by a server regularly sending updates to clients without active solicitation.

MQTT is a “Machine to Machine” or M2M communication protocol that operates according to a Publish/Subscribe model, allowing for great flexibility in its implementation. 

MQTT clients can take on the role of publisher, subscriber, or both.  

To receive the information they need, subscribers subscribe to topics (1), which are generally organized hierarchically within the broker (e.g., Home/Room/etc.). When a publisher sends a message intended for subscribers to that topic (2), they are notified by the broker (3).

As a result, MQTT clients are not required to share the same network or be active at the same time, and do not need to be synchronized with each other.  

Figure 2 – Illustration of a simplified MQTT architecture 

Moreover, MQTT offers a “Quality of Service” mechanism for its messages, allowing communications to be tailored to the requirements of the application. For example, it can guarantee message delivery in the event of an unstable connection. MQTT clients can select one of three QoS levels for the distribution of their messages: 

• QoS 0 « At most once » – The message will be delivered once or not at all, without acknowledgment. 
• QoS 1 « At least once » – The message will be delivered periodically until the sender receives an acknowledgment.  
• QoS 2 « Once » – The message is guaranteed to be delivered once and only once. 

The chosen QoS level also affects how long the message is stored locally by the sender and recipient.  

This architecture enables decentralized and scalable communications. These features are particularly advantageous in the IoT field, where flexibility is essential to accommodate a wide range of use cases. They also explain why MQTT extends far beyond the IoT and finds applications in many other environments, such as telemetry and industrial monitoring. 

Is MQTT vulnerable? 

Like many other communication protocols, MQTT is not secure by default. Although most implementations now incorporate robust security solutions, certain weaknesses and configuration errors persist, leaving systems vulnerable. 

To illustrate these concepts, we will look at a standard example of how this protocol is used in an industrial environment. 

Figure 3 – Illustration of an example of industrial use of MQTT 

In this scenario, all systems represented contain an MQTT client that allows users to subscribe to topics and communicate with the on-premise broker. MQTT communications are unencrypted and there is no authentication of the broker or clients, leaving it possible for an attacker to access production data exchanged in clear text or to send commands to equipment by impersonating the broker or one of its clients. 

How can you protect yourself? 

To effectively mitigate these risks, the broker and MQTT clients must be carefully deployed and configured. Here we propose various security measures to ensure confidentiality, integrity, authenticity, and availability of end-to-end communications. 

Securing the MQTT broker 

Enabling default encryption for communications 

When port 8883 is the only MQTT port defined, unencrypted communication attempts on the broker are rejected. Furthermore, it is essential that the broker has access to a valid certificate and private key and that the cryptographic suite used is secure (e.g., TLS 1.2 or 1.3).  

Figure 4 – Enabling encryption on a Mosquitto MQTT broker via a configuration file 

Many IoT devices have low computing power and limited resources, so adding mechanisms such as TLS can represent a significant overhead. 

Implementation of customer authentication and control of their access rights 

MQTT allows the authentication of clients connecting to a broker using common methods such as a username and password (with an associated password file) and verification of the client’s certificate, validated by a certification authority (the broker must have the certificate from this authority). Some brokers also allow the use of external authentication solutions. 

To restrict subscriptions or publications on certain topics by clients, an Access Control List or ACL logic can be added.

Figure 5 – Addition of a certificate and password authentication with access control on a Mosquitto MQTT broker 

Strict management of topics is essential to prevent data leaks and limit the risk of compromising the broker. The use of wildcards # and + must be carefully monitored, as an overly permissive configuration would allow an attacker to access all ongoing exchanges. 

Deployment of broker protection measures    

A quick search on the Shodan search engine reveals thousands of MQTT brokers exposed on the Internet, often left in their default configuration, whose users are unaware of their existence or implications. It is therefore essential to protect the broker from both internal and external threats by applying good security practices, such as regularly updating the system or restricting the number of simultaneous requests and connections, to prevent denial-of-service attacks and ensure its availability. 

Securing MQTT clients 

Enabling communication encryption 

To connect to the broker, clients must use port 8883 and have a valid certificate and private key, otherwise the connection will be rejected.

Figure 6 – Encrypted connection on an MQTT Paho client 

The use of self-signed certificates to connect to the broker is strongly discouraged because they can be easily substituted.  

Implementation of broker authentication (mutual authentication) 

In addition to client authentication, MQTT supports broker authentication by verifying the certificate authority that signed its certificate, thus ensuring mutual authentication (mTLS) and secure communications.

Figure 7 – Broker authentication on an MQTT Paho client 

Implementation of customer protection measures 

If an MQTT client is compromised, an attacker could access a significant amount of information depending on the configuration of the targeted broker. This is why clients, and their secrets, must also be protected by applying good security practices on the client’s host machine and on the content of exchanges (e.g., adding anti-replay mechanisms to requests).  

What does the future hold for MQTT? 

Despite its maturity, MQTT remains an evolving protocol and is gradually incorporating innovative features to meet the growing demands of connected environments. In a context where demand for reliable, secure, and low-power communications continues to increase, it is likely that MQTT use cases will continue to multiply in the coming years.

Cet article The security of the MQTT protocol est apparu en premier sur RiskInsight.

Operational Technology, while overall less impacted than IT, is not exempt from cyberthreats & not immune to cyberattacks. Let’s take a closer look at a simplified view of the threat landscape for industrial environments:

• Hacktivism: Increased geopolitical tensions in 2025 have led to low-level attacks by groups like CyberArmyofRussia_Reborn and CyberAv3ngers.
• Cyber Crime / Ransomware: There has been an 87% increase in ransomware attacks on industrial groups in 2025 according to Dragos in its annual report.
• Nation-State: Notable campaigns include Voltzite OT information theft and the IOControl campaign.

This threat landscape was notably depicted by Chris Sistrunk, ICS/OT Technical Leader at Mandiant, Google Cloud Security, at Black Hat 2025:

Given this increasing threat landscape targeting OT, continuous monitoring is essential. So, we know why industrial information systems need to be closely monitored, and we also know that our clients are actively working toward that goal. But one key question remains: how do we measure the effectiveness of detection? And how can we improve it?

How to assess the effectiveness and improve detection on industrial perimeter?

To answer that question, we developed a methodology aimed at evaluating detection capabilities within industrial SOCs.

The evaluation was built around the core activities of a SOC, structured into four pillars:

Using this framework, we assessed ~15 industrial clients to better understand their level of maturity. In this article, we’ll share the key trends and insights that emerged, focusing specifically on detection-related questions. Two follow-up articles will be published: one delving into the effectiveness of various detection strategies and solutions, and another explaining how to test detection capabilities in industrial environments with purple teaming and the custom modules developed for that purpose.

Governance & Strategy

The first question we focused on was whether industrial sites monitoring is handled by a dedicated team using specialized tools — or if, on the contrary, it’s integrated into a broader, centralized SOC approach.

Responses are unanimous:

These figures can be explained by several factors. One key reason is financial rationalization. Maintaining two separate teams with similar skill sets: managing alerts, configuring tools, duplicating capabilities… is costly. However, a unified SOC implies an extended scope to cover OT, but not the presence of OT-specific tools or expertise and in the end, OT detection capabilities.

Even if this approach does not guarantee effective detection and response across the OT scope, a unified SOC can manage OT incidents efficiently, under the right conditions:

End-to-end monitoring

If we look closely at the simplified threat landscape, cyberattacks might not be IT or OT-specific. Cybercrime such as ransomware, the dominant threat today, is not limited to IT or OT alone. It often spreads across both, making it essential for alerts to be followed from end-to-end.

In the end, unifying the detection teams & tools make sense as attacks are not necessarily exclusively IT or OT.

Link with industrial sites

Response time & information sharing is crucial in cyber incidents. As most security teams are centralized in a unique location, there is a need for a link between central security teams and local industrial sites in cyber incident response process:

• This relay is familiar with industrial sites, their specific characteristics, operational context, and modes of functioning
• They also maintain contact on-site to quickly gather the information required for triage, doubt resolution or investigation
• In addition, in global organizations, having resources in the right time zones and ability to communicate in the local language is key, especially in the industrial world

Referred to as Cyber-OT Referents, these relays play an active role in the incident resolution process, particularly during investigation and remediation:

In conclusion, even though unified SOC covering IT and OT are often driven by cost optimization, the model makes sense considering that many threats span both domains. Still, this must not be treated as a simple extension of the perimeter to cover, dedicated OT relays and expertise are essential to properly handle industrial-specific contexts.

Tooling

When it comes to tooling, we observed that 100% of our clients have detection tools deployed on the IT side. However, only one-third extend monitoring down to the lower layers of the industrial environment.

Detection sources covering different levels of the Purdue model

We will focus on popular solutions to address detection in industrial environments: EDR and OT probes.

2.2.1 EDR

Few figures regarding EDR:

Most of our clients have started deploying EDR in their industrial environments.

However, this does not mean that 100% of EDR-compatible OT machines are covered.

For environments that support it, extending EDR coverage allows to:

• Address low maturity: Start with tools that are easier to implement and require less maturity.
• Broad coverage: Focus on quickly covering a wide range of systems, sites, and critical applications.
• Leverage IT tools: Use IT-based solutions like EDR for effective detection without heavy infrastructure requirements.

To do so, most organizations opt to use the same EDR solution for both IT and OT environments. It enables faster rollout thanks to a known and already-integrated tool. Depending on needs and available resources, a different solution may be selected to improve resilience and OT-compatibility.

To conclude, with IT/OT convergence, deploying EDR Agents on OT Servers and Workstations is becoming increasingly relevant, and a quick win for OT detection, according to our clients’ feedback.

OT Probes

Few figures regarding probes:

When it comes to probes, the gap between these two figures highlights the challenge of deploying probes at scale and effectively using them for detection in industrial networks.

Indeed, probes collect and correlate information through network traffic capture. To be effective, their deployment requires carefully selecting listening points based on the intended targets. Listening points need to be tailored to each site architecture, often limited by local team’s knowledge and lack of documentation.

Operating these probes also comes with challenges and requires a significant workload. They tend to generate a high number of false positives, which means teams must create tailored detection rules and playbooks to filter and respond effectively.

In the end, OT Probes may be popular, but deployment and tuning costs and resources limit their full utilization.

Start basic with OT detection tools

In the end, for OT detection, we believe in starting basic by leveraging “IT” tools to ensure a first level of coverage across all sites, critical apps, and infrastructure:

• Prioritize critical assets: Focus on key systems (MES, safety tools, network) essential for production, ensuring they are closely monitored before extending deployment to the lower levels of the Purdue model.
• Implement basic detection: Establish foundational detection across sites and infrastructure for early issue identification, before advancing to complex OT solutions.

Training & Testing

Detection does not rely on deploying tools alone; we will focus here on team’s ability to use them effectively.

A need for more OT-specific knowledge

Benchmark figures revealed a limited understanding and adaptation of both teams and processes to industrial environments:

To bridge the gap, teams need training tailored to industrial contexts, basic for all SOC analysts, and in-depth for OT specialists.

In the same way, investigation and response processes must also be adapted to address the specific needs of industrial environments, where priorities such as availability differ from those in the IT world.

Test your detection!

Finally, improving detection starts with evaluating it but today …

Only a small minority test their real detection capabilities, but we believe that there is room for purple team exercise in OT. These collaborative exercises with the OT SOC, tailored to its maturity and goals, can test and enhance both detection tools and OT SOC processes.

It can start simple: by selecting appropriate production environments and performing a few basic tests like inserting a USB key with a standard malware sample or attempting a couple of privilege escalation actions… we can evaluate whether the EDR deployed on a workstation connected to your SOC will trigger an investigation.

This exercise helps identify the blind spots and adjust tooling, process and playbooks accordingly.

Conclusion: How to enhance the overall low maturity in detection for industrial systems?

The benchmark’s first conclusion is clear: maturity levels are low, and this is a consistent answer across all collected responses. How to enhance this overall low maturity in detection for industrial systems?

Here are the key outcomes regarding the three topics covered in this article:

Do not hesitate to reach out to discuss how you can strengthen your detection capabilities and measure your maturity against the market!

Cet article Cybersecurity monitoring for OT – Current situation & perspectives est apparu en premier sur RiskInsight.

Beyond the simple interruption of operations and financial loss, the consequences on the physical integrity of people and the environment are major HSE (Health, Safety and Environment) impacts that imply critical risks to be considered for the industrial sector. 

Faced with these growing threats and impacts, manufacturers have, until now, invested in protecting their industrial information systems. Resilience is now being taken into account, and resilience projects are being incorporated into cyber IoT roadmaps. Depending on the sector and industrial entity, investing in effective recovery may be more worthwhile than excessive protection. By combining resilience and protection, businesses can safely resume most of their industrial activities as quickly as possible, reducing damage and financial losses

In this context, cyber-resilience is an absolute necessity. 

What are the keys to building this resilience and meeting the challenges of tomorrow? Let’s find out together.

Cyber-resilience challenges for organizations

Cyber resilience is now a strategic priority for industry. The stakes go far beyond the simple security of systems: 

• Ensuring the safety of people and the environment: In some sectors (hospitals, energy, nuclear, water treatment, etc.), the priority is to secure installations, even at the detriment of production. The human and environmental impact of a cyber-attack can be far more serious than simply stopping production. 
• Protecting critical installations: The security of critical production installations must be assessed. An impact on these systems will have major repercussions on the company’s activity and turnover. 
• Preserving sensitive data: Some industrial information is crucial for competitiveness and security. Any leak or alteration can seriously harm the company and, in some cases, national security. 
• Resuming operations quickly and safely: Cyber resilience aims to restart operations quickly, while guaranteeing the safety of installations and people. 

The challenges also extend beyond the organization’s internal security, with increasing geopolitical and regulatory impacts: 

• Geopolitical risks: Cyber-attacks on critical infrastructures, such as those in the energy or water sectors, have significant political and societal consequences. 
• Regulatory pressure: Legislation such as the NIS Directive, the LPM and the Cyber Resilience Act impose strict requirements, forcing businesses to continuously strengthen their cybersecurity.

What are the main resilience activities? 

The main activities of cyber resilience are based on three main areas, each of which is essential for guaranteeing the continuity of operations in the face of incidents. 

1. Maintain critical activities in downgraded mode: 
   • Identify critical activities to be restored as a priority 
   • Industrialising operations in degraded mode to enable partial business continuity pending full recovery 
   • Contain the spread of incidents to limit their impact 
2. Test its crisis management:
   • this includes setting up regular exercises to identify areas for improvement and strengthen the organization’s resilience against cyber-attacks. 
3. Industrializing reconstruction: rebuilding and restoring a healthy IS 
   • This is not simply about restoring services, but about checking and reinforcing each component of the system to ensure its long-term security. This phase helps regain stakeholders’ confidence and ensure a robust infrastructure, ready to prevent future threats. 

Setting up an Industrial IT Disaster Recovery Plan: the cornerstone of IT recovery 

The IIRP (Industrial IT Disaster Recovery Plan) is the key element of the cyber-resilience strategy for industry. This document brings together all the technical, organisational and security procedures needed to rebuild and restart an IoT information system after a disaster or major incident. The IIRP is activated during or after a disaster or crisis. Its role is to ensure the rapid and reliable resumption of industrial activities. 

The IIRP generally contains the following elements: 

• Clear responsibility matrix 
• Schedule for efficient reconstruction 
• Detailed procedures for restoring information systems and IoT IS assets 
• Information on appropriate means of communication 
• Recommendations on the frequency of tests to validate the resumption of activities 

The main objective of the IIRP is to minimize recovery time while ensuring a high level of confidence in its IIS. It also protects sensitive data and helps limit the financial losses associated with business interruptions. By guaranteeing a high level of security, the IIRP minimizes physical, environmental and legislative impacts, while preserving the company’s image and facilitating the work of operational teams. 

The recovery documentation architecture must be adapted to the size and structure of the company. It is essential to correctly choose the reconstruction granularity and the appropriate format for each information system (IS) and industrial entity. 

Example

• IIRP Group (Group Industrial IT Recovery Plan): Main document defining the principles, responsibilities and processes for business resumption at the group level. It refers to the specific IIRP for each site. Review: Every 5 years or in the event of a major change. 
• IIRP Site (Site Industrial IT Recovery Plan): Document detailing the recovery principles and responsibilities for a specific site. It also defines the recovery order of systems in the event of an incident affecting multiple IS and refers to the IIS reconstruction sheets. Review: every 5 years or in the event of a major change. 
• Plant/IIS rebuild sheets: Operational documents detailing the scheduling and actions required for the recovery of each IIS, including architecture diagrams and asset inventories. Review: annually or when there are changes to the IIS. 

The keys to a successful takeover: the importance of properly framing your takeover project 

Focus | Defining the use of files upstream for optimum recovery

Before going on to write and implement the IIS reconstruction sheets, it is important to take several aspects into account in order to facilitate their drafting and ensure that they reflect the reality and requirements of the business. 

The essential prerequisites for writing an industrial IT recovery plan: why well-structured IIS documentation is crucial 

It is necessary to formalise the essential documentary prerequisites for guaranteeing the effective recovery of the industrial IT system (IIS), focusing on the following key elements: 

• Mastery of IIS: In-depth knowledge of IIS is essential. This includes a clear view of the systems, a detailed inventory of assets, as well as mapping and architecture diagrams (logical and physical). It is also crucial to identify the IIS referents who hold the key knowledge of these systems and to ensure that their information is regularly updated. 
• Backup plan: A comprehensive backup plan, including data critical to the plant’s smooth operation, is essential to ensure a rapid and complete resumption of activity. This includes elements such as the backup of PLC programs and configurations, administrative PCs, SCADA systems and historians. 
• Business knowledge: The presence of a Business Continuity Plan (BCP) or business correspondent is a major asset in defining effective scheduling. It ensures that the recovery plan is not only applicable, but also operational and in line with the specific needs of the business. 

These three fundamental elements are essential if we are to initiate an effective IT recovery process that is aligned with the real needs of the business. The project cannot get off the ground without them, and without adequate funding for the site. 

Further information | Recovery: A major stage in IIS compliance 

The business recovery project provides an in-depth inventory of the IIS, which serves as the basis for drawing up a pragmatic action plan to bring it into compliance. This process includes identifying obsolescence in the industrial estate, missing backups and other points of weakness. Thanks to the recovery tests, numerous recommendations and improvements can be put in place to strengthen the security of the IIS and make it more resilient in the face of crises. 

The resulting action plan highlights several key points (not exhaustive): 

• Obsolescence management: The obsolescence of IT infrastructures must be taken into account in the disaster recovery strategy. Aging equipment can seriously compromise the effectiveness of recovery plans. 
• Unmaintained software on obsolete PCs: The use of monitoring software not maintained by the publisher, installed on obsolete PCs (hardware and operating system), and difficult to replace, presents a major risk. In the event of a crisis, this could prevent the plant from operating properly due to a lack of supervision. 
• Lack of back-up for critical data: The absence of back-up for a key server, essential for the resumption of activity at several sites, jeopardises the continuity of the entity’s operations. 
• Lack of documentation and failure to comply with contracts: The lack of documentation on certain equipment (configurations, installation procedures) and the absence of architecture diagrams for certain IS show a failure to comply with contractual requirements. These shortcomings will complicate the reconstruction of the IS in the event of a crisis. 

In conclusion, the success of an industrial disaster recovery project depends on rigorous preparation, including defining the sizing and requirements of the plants, drawing up a roadmap prioritising critical activities, and setting up a project team with the necessary dedicated resources. These steps ensure a smooth recovery, on time and on budget, while strengthening resilience in the face of cyber risks. 

Cet article Cybersecurity Resilience: A Key Pillar to Protect Our Industrial Systems est apparu en premier sur RiskInsight.

As cyber threats become more targeted, sophisticated and persistent—particularly against industrial systems and critical infrastructure—the ANSSI (French Cybersecurity Agency) has strengthened its cybersecurity framework by publishing a revamped version of its guide for the classification of industrial systems, originally released in 2012. 

This guide is intended for all stakeholders involved in industrial system security: operators, operators of vital importance (OIV), essential service operators (OES), integrators, and service providers responsible for aligning technical requirements with business imperatives. 

Its aim is to provide a methodology for determining the criticality of industrial systems, classifying them into one of four cybersecurity levels—minor, moderate, major or catastrophic—based on the maximum severity of potential impacts on: the population, the economy, and the environment. This classification helps identify the appropriate level of security needed and guides the implementation of cybersecurity measures. 

Figure 1: The 4 cybersecurity classes of the guide 

Why revisit the existing framework? 

The first edition of the classification guide, published in 2012, laid the foundation for a tiered security approach by introducing a three-class segmentation model based on risk (impact × likelihood). 

Figure 2: Key differences between the first and second versions of the guide 

While this initial version played a key role in fostering a culture of industrial cybersecurity in France—at a time when sector-specific references were still scarce—it encountered several limitations over time. 

Firstly, the integration of likelihood into the classification process led to a so-called “looping effect“, as described in the new guide. As security measures were implemented, the likelihood of an attack was considered to decrease, which in turn could lower the system’s classification level. This phenomenon compromised the stability of classification over time, making it difficult to maintain consistency between classification and actual protective measures. 

Moreover, the initial guide proposed only three classes, which resulted in systems being assigned to the highest one too often. There was also a lack of granularity in perimeter definition and limited alignment with international standards such as IEC 62443. 

The new version addresses these challenges by basing classification exclusively on impact, ensuring more stable classifications, consistent comparisons between zones, and better integration with structured risk analysis frameworks like EBIOS RM. This evolution also makes the approach more adaptable to the diversity and complexity of modern industrial systems. 

A methodology compatible with existing frameworks 

Figure 3: Classification methodology diagram from the new guide 

The new methodology is structured around three key activities: 

1. Definition of the technical perimeter 
2. Segmentation into coherent zones 
3. Classification of each zone based on the potential severity of impacts in case of compromise 

This approach enables organizations to assign each zone to one of the four cybersecurity classes according to the severity of potential impacts. It provides a rational and scalable understanding of security needs, with a focus on two key criteria: availability and integrity, which align with the core concerns of industrial environments. 

The guide does not replace risk analysis frameworks but is designed to integrate seamlessly with them. It was specifically built to feed into EBIOS RM workshops, providing a classification baseline that supports the identification of feared events and associated security measures. This structure eliminates the need to adapt or distort EBIOS RM to accommodate industrial contexts. 

The guide also draws on concepts from IEC 62443, such as zones, conduits, and security levels, helping align with international industrial cybersecurity best practices. 

This alignment is part of a broader push toward a structured deployment of cybersecurity. The guide provides a practical framework organized around key thematic areas, as illustrated below, to help effectively integrate cybersecurity into industrial environments. 

Figure 4: Key themes for deploying cybersecurity (Chapter 3.1 of the guide) 

What comes next: a detailed measures guide — bridging the gap between strategy and action 

Expected in the coming months, the detailed measures guide is the logical continuation of the classification methodology. It aims to equip industrial stakeholders with practical tools to move from theory to implementation, translating the cybersecurity classes into concrete operational requirements. 

Inspired by the 2012 guide, which already proposed a set of baseline measures for each class, this new version promises a more refined, up-to-date approach that reflects current threat landscapes and security practices. It will offer decision-makers and system owners a clear and actionable toolbox, detailing technical, organizational, and human measures adapted to the criticality level of each zone. 

Scheduled for publication in 2025, the guide will ensure continuity with risk analysis and compliance efforts already underway, while clarifying expectations regarding the concrete implementation of protective measures.  

Securing the present, anticipating the future 

Beyond its publication, the real challenge now lies in adopting the methodology and integrating it into the cybersecurity strategies for both existing and upcoming industrial systems. 

For existing systems, the new guide naturally fits into the security lifecycle recommended by ANSSI in its EBIOS RM guide. Impacts should be assessed on a case-by-case basis to determine whether modifying current architectures is worthwhile, weighing the cost of change, evolving business needs, and expected security benefits. Integration can occur:  

• During the strategic cycle, typically conducted periodically or following a major change, which offers an opportunity to revise perimeter definitions, update functional zones, and reassess system classifications using the new methodology; 
• Or during the operational cycle, focused on reviewing feared events, checking whether existing measures align with the defined cybersecurity classes, and adjusting protection strategies as needed. 

For new industrial projects, the new guide officially replaces the 2012 version and should be incorporated from the earliest design phases. It provides a framework for building a secure architecture aligned with business priorities, while also easing compliance with current and upcoming regulatory frameworks (NIS2, LPM, etc.) or contractual obligations. 

At Wavestone, we are integrating this guide into our industrial cybersecurity maturity evaluation framework and Cyber Benchmark methodology, alongside international standards such as IEC 62443 and NIST SP 800-82. All that remains is to wait for the operational measures guide to complete the picture!

Cet article Enhancing Industrial Cybersecurity: Changes Introduced by the New ANSSI Guide for Industrial Systems Classification est apparu en premier sur RiskInsight.

This innovation is due to increasing numbers of cybersecurity standards, regulations, and directives- such as NIS2 (Network and Information Systems Security Directive), the Cyber Resilience Act (CRA), and sector-specific regulations. This expanding regulatory framework reflects the need to secure critical infrastructures and technological products in the face of growing threats.  

This article explores the PART-IS regulation, its implication, scope, stakeholders involved, essential requirements, and steps involved in complying with it.  

What is PART-IS? Why is it essential?  

PART-IS was introduced to enhance aviation security by protecting critical information systems in aviation. Its main objective is to ensure that these systems, which include technologies such as avionics communications and air traffic management, are resilient in the face of cyber threats to guarantee the continuity and safety of aviation operations in a sector where any failure can have serious consequences. With the growing integration of digital technologies into aviation operations, from navigation systems to ground infrastructure, the sector’s vulnerability to cyber-attacks has increased considerably.  

By requiring aviation industry players to identify and assess the vulnerabilities of their systems, PART-IS is a proactive response to today’s challenges.  

Which systems are concerned?  

PART-IS applies to all digital systems used in civil aviation. This includes, for example: 

• On-board systems, such as Flight Management Systems (FMS)  
• Air Traffic Management (ATM) infrastructures  
• Predictive maintenance systems  

Due to the increasing interconnectivity between these systems, a vulnerability in one component can cause a chain reaction across the entire aviation ecosystem; jeopardising the safety of operations.  

Who are the stakeholders?  

The implementation of the PART-IS is based on collaboration between several stakeholders. The main players involved include: 

• Airline operators, who are responsible for the safety of on-board systems  
• Manufacturers, who must incorporate cybersecurity measures into the design of aircraft and equipment  
• Air navigation service providers, responsible for protecting traffic management systems  
• National authorities, whose role is to supervise and verify regulatory compliance  
• Ground service providers   

Part-IS will be mandatory from October 2025 for organisations approved by EASA under Delegated Regulation (EU) 2022/1645, i.e. production and design organisations. Maintenance organisations under Delegated Regulation (EU) 2023/203 will have to comply by February 2026.  

What are the PART-IS requirements?  

The PART-IS regulation imposes fundamental principles for guaranteeing the security of critical systems. The organisations concerned must adopt a rigorous approach to meet these requirements and ensure their compliance.  

Risk management (ISMS)  

This regulation is part of a proactive approach aimed at identifying, analysing, and mitigating the risks that could compromise the confidentiality, integrity, and availability of sensitive information. Based on a structured framework such as ISO/IEC 27001, the ISMS becomes a central tool for establishing robust security policies, deploying appropriate technical and organisational measures, and raising stakeholders’ awareness of cybersecurity issues.  

Risk management, a fundamental pillar of this approach, enables efforts to be prioritised on the basis of identified vulnerabilities, while ensuring continuous improvement through the PDCA (Plan-Do-Check-Act) cycle. Regulations require civil aviation operators and entities to have robust information security governance in line with best practice.   

Risk assessment  

Organisations must establish a structured methodology for identifying, analysing, and mitigating the cyber risks associated with their information systems. This includes carrying out vulnerability analyses, assessing the impact in the event of a compromise, and implementing appropriate controls.  

Continuous monitoring 

Real-time monitoring of systems is essential for detecting and responding rapidly to security incidents. This requires the use of advanced tools and the implementation of incident response protocols. All incidents must be reported quickly and accompanied by a clear response plan to limit their impact.  

Training and awareness  

Staff must be trained in cyber security best practice to reduce the risk of human error. Regular awareness programmes are essential to maintain a high level of vigilance.  

Audits and documentation  

Compliance with PART-IS is verified through regular audits conducted by EASA or national authorities. Organisations must also maintain full documentation covering safety policies, procedures implemented, and incidents encountered.  

What are the key stages in achieving compliance?   

Compliance with PART-IS offers a strategic opportunity for companies to strengthen the security of their critical systems and modernise their practices.  

With the compliance deadline set for October 2025 for at least part of the perimeter, is an appropriate time to start the compliance process.  

To achieve this, we are currently supporting our customers in 3 main areas:   

• Firstly, it is essential to precisely define the scope concerned, based on the scope of the approvals issued by the EASA, in order to effectively frame the efforts.   
• Next, drawing up an Information Security Management System (ISMS) will help structure the policies and processes required for proactive risk management.   
• Finally, carrying out the first risk analyses to identify vulnerabilities and draw up appropriate action plans.   

These steps lay the foundations for a solid, long-term information security strategy, which will then have to be nurtured and developed in the spirit of the continuous improvement process advocated by PART-IS. 

Cet article PART-IS: A pillar of cybersecurity in European aviation est apparu en premier sur RiskInsight.

However, unlike traditional gas stations, these are highly computerized and connected systems. Indeed, digitalization allows for a smart ecosystem and direct operational gains. This includes features such as smart charging, which allows for financial and energy savings by optimizing electricity consumption depending on grid strain. The driver’s experience is also improved, as they can use their smartphone to easily locate connected chargers and interact with them. 

All these functionalities present specific cybersecurity challenges that we will analyze in this article. We will outline strategies that Charging Point Operators (CPOs) can implement, focusing on public charging stations. Indeed, public chargers are more exposed and thus, are the most complex case study from both operational and cybersecurity perspectives. 

What are the cyber risks in the charging ecosystem? 

Why are cyber risks significant, and what is their nature? To understand this, we need to examine the charging ecosystem. 

The central player in this ecosystem is the CPO, who is on the front line of cyber risks. CPOs are responsible for the direct operation of charging stations, both on-site and remotely. Typically, they use a cloud-hosted software solution called a CSMS (Charging Station Management System). 

The role of the CSMS has been highly standardized thanks to efforts by the Open Charge Alliance (OCA), a consortium that developed the OCPP (Open Charge Point Protocol). OCPP handles more than just maintenance and monitoring; it allows the CSMS to communicate with the charger in real-time to manage the charging process (reserving the station, driver authentication and authorization, billing, etc.). This introduces a cybersecurity risk: compromising the CSMS could lead to a widespread compromise of the CPO’s entire charging network. 

However, to fully map out the possible risks, we must also consider other industry players who share cyber risks with the CPO. 

First, charging stations manufacturers play a key role. Responsible for charger design and production, they also handle software updates and provide patches for vulnerabilities. In some charger models, manufacturers maintain permanent remote access for maintenance purposes via a secondary OCPP connection. If not properly secured, this connection can pose a risk to the CPO. 

To ensure the remote connection of charger networks to the CSMS, Wide Area Network (WAN) solutions are frequently used. This can involve a 3G/4G link, or integration into a preexisting on-site network. In both cases, the link is not under the CPO’s control, making them dependent on the cybersecurity maturity of the telecom provider they choose. 

Additionally, the CPO must integrate their information system with the site owner. Indeed, chargers can be in a variety of environments: highway rest areas, corporate parking lots, shopping malls, public roads etc. Depending on the use case, the stations may be interfaced with building systems (such as occupancy sensors or smart meters) or with user authentication and payment systems. Typically, the CPO has no authority over these systems and their security. 

This multiplicity of actors tends to increase the attack surface on the CPO’s information systems. A breach could result in the leakage of customer data or serve as a foothold for a broader cyberattack targeting the CPO and/or its partners, with significant financial and reputational impacts. 

On a local scale, potential attacks are also severe, including cyber-physical risks (e.g.: a malicious modification of charging parameters, which could lead to battery overheating and potentially a fire) or grid destabilization risks (e.g.: the malicious activation or deactivation of multiple chargers at once, potentially overloading the power grid). 

These scenarios are likely to become more plausible with the growing popularity of extreme fast chargers (especially for heavy-duty vehicles) and bidirectional charging implementations, which allow parked vehicles to feed stored energy back into the grid. 

Implementing new standards: is it enough to address the risks? 

As the charging market rapidly grows, it is becoming more structured, and new standards are emerging. This presents an opportunity to provide a unified cyber response to the risks we have discussed. 

Take ISO 15118-20, for example. Published in 2022, it specifies robust communication mechanisms between vehicles and chargers. In addition to the already mentioned smart charging and bidirectional charging use cases, ISO15118 introduces Plug & Charge: this feature allows the charger to automatically authenticate a vehicle and process payment, eliminating the need for payment cards or RFID tags. 

The primary goals of ISO 15118 are thus to streamline usage, improve energy efficiency, and ensure interoperability. However, its adoption could also bring security benefits, notably through the implementation of a global Public Key Infrastructure (PKI) for charging stakeholders: vehicle manufacturers, mobility operators, and CPOs. 

Meanwhile, the development of OCPP is also expected to accelerate, following the official approval of OCPP 2.0.1 as an international standard (IEC 63584) by the International Electrotechnical Commission. 

However, it will take time before these standards become widely adopted. Several major players, such as Tesla, have developed proprietary protocols with similar features. Moreover, most existing chargers and vehicles are not compatible with ISO 15118 or OCPP 2.0.1 and need to be replaced. 

Thus, we cannot rely solely on standards to address cybersecurity risks: it is imperative to find ways to secure current infrastructures. 

Note : to know more about Plug & Charge and smart charging, feel free to check out the articles by EnergyStream, Wavestone’s energy blog (only available in French): 

• Le Plug & Charge : une nouvelle solution d’authentification et de facturation sécurisée 
• Les défis du déploiement du Plug & Charge 
• Panorama des usages du smart charging 

So, how can CPOs secure their architecture? 

Standards are only one part of the puzzle: it is primarily up to CPOs to implement a comprehensive cybersecurity policy. But how can they tackle the complex risks we have discussed? 

The first step is to understand and document their architecture and solutions. This may seem basic, but there is currently no reference architecture model for charging infrastructure. In this article, we will be model the architecture using four zones, as presented below: 

Figure 1. Base architecture model for public chargers in commercial contexts. 

To secure this architecture end-to-end, we will look at key measures to secure each zone. 

We can, however, disregard the vehicle interface for now. Until ISO 15118 becomes widely adopted, current charging connectors are not integrated into the information system and therefore are not a risk vector. 

For the charging network, cyber hygiene measures and network segmentation are crucial. Chargers are often vulnerable systems, due to the use of default accounts, weak passwords, open network ports, and unencrypted storage systems. The CPO must implement best practices for hardening and firmware updating, for each manufacturer and model they use. 

Network segmentation usually involves the use of firewalls and VLANs, depending on the local network topology and external systems that need to be integrated. Using a local controller can help isolate chargers more easily from untrusted networks. This controller can aggregate all charging stations on a site and serve as a proxy with the CSMS. 

As the WAN network is often outsourced, it is essential for the CPO to encrypt the flows between the chargers and the CSMS. The main existing solution today is the use of TLS with server-side and client-side certificates, as provided in the latest versions of OCPP. 

Finally, how to secure the CSMS? It can generally be assimilated to a cloud-based IoT platform and approached similarly. Priority should be given to code security best practices and proper identity and access management (following the RBAC model). In the future, we can imagine that the CSMS will also play an active role in detecting cyber threats: analyzing logs and OCPP communications could be facilitated by the implementation of AI-based solutions. 

Conclusion: what should be the reference architecture for CPOs? 

Although new standards promise to streamline architectures, the charging ecosystem remains complex due to the diversity in business contexts. This is why we encourage CPOs to adapt the best practices from this article to their use case. The architecture diagram below should be seen as a starting point, rather than a definitive target. 

 Figure 2. Secure architecture model for public chargers in commercial contexts. 

Cet article Electric Mobility – How can charging point operators secure their charging infrastructure?  est apparu en premier sur RiskInsight.

However, this evolution highlights specific cybersecurity challenges associated with these systems, prompting industrial companies to consider how to secure these applications. 

What opportunities does Artificial Intelligence bring? And what are the potential cybersecurity risks that come with it?  

AI & Industry 

To better understand the range of possibilities offered by these technologies, Wavestone has created the 2024 Generative AI Use Case Radar for Operations. This radar lists the usage trends observed among its industrial clients, as well as other potential use cases that may develop in the coming years:  

Figure 1 – Generative AI use cases Radar for Operations 

Wavestone has identified four types of use cases (decision support, tool and process improvement, document generation, and task assistance) that impact various industrial functions (production, quality, maintenance, inventory management, supply chain, etc.). 

Figure 2 – Main uses of generative AI in industrial operations 

Here are some concrete examples illustrating how these technologies integrate into the operations of various sectors, what they bring, and the potential impacts of cyberattacks on these systems: 

Figure 3 – Real AI use cases in industrial sector 

These systems provide significant technological and strategic advantages, as well as considerable financial or time savings. 

However, integrating these technologies can also introduce new risks that companies must consider. 

AI Cyber Risks 

How can an attacker compromise these systems? 

There are several categories of AI-specific attacks, all exploiting vulnerabilities present in different phases of these models’ lifecycle, providing a broad attack surface:  

Figure 4 – AI lifecycle: possible attacks  

Most of these attacks aim to divert AI from its intended use. The objectives can include extracting confidential information or making the AI perform unauthorized actions, thereby compromising the security and integrity of the systems. 

To understand these attacks in detail, Wavestone’s experts have illustrated evasion and oracle methods in this dedicated article. 

What is the situation regarding these risks for industrial companies? 

As it stands, the risks associated with AI in the industry vary greatly depending on the sector and its application. 

To carry out oracle, manipulation, and prompt injection attacks against an AI system, being able to interact with it by providing input data is crucial. This is feasible with some generative AIs, like ChatGPT, which require a user input to start operating. Conversely, other systems, such as those used for predictive maintenance (AI based solutions that anticipate and prevent equipment failures), do not rely on human instructions to function, making interactions more complex. Moreover, the types of input data for these systems are often very specific, hard to obtain, and manipulate. 

Data poisoning attacks could be an alternative, as this method does not require interacting with the AI system. However, this would first require infiltrating the information system to gain access to the AI, deeply understanding its architecture, and then attempting to alter its behavior- with no guarantee of success. Moreover, companies with a good level of cybersecurity already have countermeasures and protection methods in place which significantly reduces the chances of such an attack succeeding. 

Comparatively, other methods that do not specifically target the AI system can be easier to implement and may provide an attacker with a greater opportunity to cause harm to a company. 

However, some AI applications, like generative AI assistants, are vulnerable to input-based attacks mentioned above. 

Here is an example of an attack scenario on the vaccine production assistant shown in Figure 3. 

Context of the use-case 

Employees write their request to the assistant, attaching the specifications of the vaccine to be produced. The assistant runs the analysis and, using a RAG module (which provides the AI with additional data without retraining), cross-references this information with the company’s database. Finally, the assistant returns a machine instruction file to employees, which they can use directly to launch production.  

Attack scenario 

 Figure 5 – Attack scenario killchain on vaccine production assistant 

The consequences of a theft of trade secrets such as this could include the resale of this information to competitors or its public disclosure, which could have significant financial and reputational implications. However, conventional access management security measures can help to reduce the risk of this type of attack. 

Finally, although some AI applications are vulnerable to new attacks, specific security measures tailored to the weaknesses of each system ensure effective protection. 

So, what are the points to remember? 

After all, the risks associated with AI technologies for industrial companies are not fundamentally new. 

Although some AI systems are vulnerable to new attacks, the cybersecurity principles for protecting against them and limiting their impact remain unchanged. 

It therefore remains essential to adopt a risk-based approach and integrate cybersecurity by design for any AI application.  

Cet article Artificial Intelligence, Industrials, and Cyber Risks: What’s the Current State? est apparu en premier sur RiskInsight.

OT Probes: A tool for monitoring industrial networks 

Figure 1: Listening to the network to assess and detect 

A detection probe is a piece of equipment, virtual or physical, connected to the information system (IS) in order to map and monitor it. It consists of sensors distributed across the network to collect data. And typically, a central console to aggregate, correlate and analyse this data. Probes for industrial environments – which we will refer to simply as OT probes here – are characterized by their passive, non-invasive listening on the network, and their understanding of industrial protocols and behaviour. Many players are present on the market, you can find our market overview here: https://www.riskinsight-wavestone.com/2021/03/les-sondes-de-detection-en-milieu-industriel-notre-vision-du-marche/  

All their probe solutions work on the same principle: network traffic is collected using flow duplication (SPAN, ERSPAN …) or physical duplicator like taps, etc. Packets are inspected in real time to provide several types of data: flow inventory and mapping, asset and vulnerability management, and finally anomaly and incident detection. 

This variety of possible use cases of these data and the types of users involved (operational and business team, cybersecurity team, etc.) is what makes OT probes so popular.  

However, procuring and deploying these solutions are costly. The organisation must have a clear understanding of their needs, a view of potential users and the exact added value required before embarking on such a project. 

Let’s take two very different examples 

Imagine two companies are considering deploying OT probes on their industrial sites.  

1st Company: WavePetro 

WavePetro is a company with a large sensitive site, which has a good level of cybersecurity maturity, as well as a segmented architecture. The company wants to deploy OT probes to be compliant with regulations and to improve its detection capabilities. 

Considering its architecture and detection requirements, numerous listening points will be needed on the site. WavePetro can rely on its local teams for expertise and site knowledge to support this complexity. 

2nd Company: RenewStone 

RenewStone has numerous scattered and unmanned small sites with different cybersecurity maturity levels. The sites are connected to central Group infrastructure. 
The company wants to deploy OT probes to gain visibility on its sites using inventory and vulnerability management features.  

With this configuration, RenewStone needs to standardize a turnkey OT probe roll-out and run service with as little local complexity as possible.  

Figure 2: 2 companies, 2 reasons to deploy OT probes, 2 implementation plans 

What is required for a successful roll-out? 

Although these two companies have different drivers and maturities, they will go through the same 5 key stages, albeit with different approaches.  

1.Perform a Proof of Concept 

Let’s start with the first step: the proof of concept. The objective for both companies is to test the feasibility and challenge the value this tool brings to the organisation. 

While WavePetro have to validate feasibility on a reduced perimeter in the factory, RenewStone has to validate OT probe added value validation on few different sites. 

The PoC is key in identifying what can be valuable for both companies. To get the most of it, it is important to: 

• Adapt vendors selection to your needs: The market is quite diversified between pure players, those specializing in industry or extending their IT solutions …  
  Do I want strong detection capabilities? Do I want a managed service? Do I want a unified solution for IT and OT?  
• Select the PoC scope: Identify a representative scope with resources to test on so that results can be reproduced at scale.  
• Draft a target architecture before the PoC: This allows to test an architecture that will be representative of what would be deployed at scale, in order to validate the tests carried out. 

PoC is an essential step to ensure that the tool provides value to your company, but also to be able to convince businesses to deploy especially when not constrained by regulations. 

2.Build the associated operating model  

Even from the early stages, before rollouts, it is important to remember that the end goal of the probes deployment will be to get value from its operation. To be able to do so, it is essential to: 

• Define an operating model for handling alerts, managing the inventory and managing the probes themselves. While WavePetro can have an operating model heavily relying on local knowledge and expertise, RenewStone must build a central operation model to include group teams such as SOC, OT security, network, infrastructure and so on. 
• Decide whether to call on a third party or manage your probes in-house: Few vendors also propose managed service, so you would need to create your own model, which could also rely – wholly or partly – on externalization. 
• Create a RACI: Considering the different use cases and the number of players involved in using or maintaining probes, a RACI is key to ensuring that all stakeholders are involved. 

This stage must be addressed upstream to facilitate the next steps. 

3.Prepare the roll-out  

Once the first step has demonstrated the added value of a probe and their operating model has been defined, let’s prepare for the roll-out. You need to define the final target: 

• Where you will deploy: Especially if you have many diverse sites, like RenewStone, you need to be precise on, and prioritize, the scope: It will not be possible to deploy all sites at the same time. 
• When you will deploy: Work on budget estimates, even if not accurate, as soon as possible so that sites are able to plan a roll-out on the following year. Probes are an expensive solution, not only in terms of hardware and licensing, but also in terms of the resources required to deploy and operate them. 
• How you will deploy: In any case, you need to work on a standard architecture blueprint. But especially if you have many sites to deploy or very limited local resources, you should work on building a packaged service offer to deploy.  

This preparation part is key to avoid wasting time with deployments and guarantee their success. 

4.Deploy ! 

Let’s start deploying… The motto is the same for both companies: Start small and grow.  
The difference lies in the scale:  

• Gradually roll out across the site for WavePetro: It will take some time to be able to listen everywhere effectively. Focus on the expected data to prioritize where to place the probe at first and where to listen to the network. 
• Learn and improve from one roll-out to the next for RenewStone: Rollouts are centralized and more standardized, so teams will learn and improve from one roll-out to the next. There should be a first ring of roll-out that is comprised of representative sites to test and improve the deployment model on.  
• Include change management: in all cases, the deployment of a new tool must absolutely include awareness-raising and training if probes are to find their users. 

Deploying OT probes can be a long and tedious process, but do not get discouraged, because there is still one big step left! 

5.Fine-tune OT probe console 

A probe roll-out is not a “1-and-done” kind of project. This is a tool for continuous improvement and needs to learn to deliver value. You should therefore dedicate time to: 

• Fine-tune OT Probes dashboard: Take time to improve the detection model (whitelist some behaviors, prioritize sensitive assets …), the automatic asset inventory and mapping (enrich inventory, import data, tag VLANs …), and so on. This fine-tuning needs to be done by someone with site-specific knowledge.  
• Integrate with other technologies: You can integrate OT probes consoles with your other solutions and tools such as the SIEM, firewalls or CMDBs to make the most of the data collected by the probes. 
• Try adding features: once you have gained some maturity over the solution, you can go even further with the features available like performing active queries to enrich the inventory and go even further with the features available. 

Fine-tuning enables the solution to reduce the amount of data it retrieves, so that it can focus on security data and alerts that will bring value to your company and its security level. 

Figure 3: Takeaways from 5 key steps towards an OT probes service 

Conclusion 

These 2 examples have taught us a lot about OT probes, and the many challenges involved in deploying and using them. If tomorrow, I were facing a customer wondering what to do with this OT Probe project on his roadmap, I would pick out 3 main elements: 

Figure 4: The 3 keys to a successful probe project 

Before deploying: Is it worth it ? 

Without clearly identified use cases and defined objectives, you may end up with probes providing unused or no real added value information. OT probes are expensive, both financially and in terms of time. You need to make sure they are worth it, and then gives you the means to fully exploit them. 

To do this, take the time to evaluate the quality and value of the information provided by the OT probes with your different teams (cybersecurity, operations, business…). 

Start small and grow 

Don’t be afraid to start small and grow progressively, whether that is in the number of monitored sites, assets or use cases. 

The long-term operation of OT probes is complex and builds over deployments. Take the time to take care of the solution adoption: if you want teams to use the solution, train them and demonstrate OT probes value! 

Rely on continuous improvement 

As for any robust cybersecurity process, continuous improvement should be at its core. Cyber threats are constantly evolving, from attacker techniques to OT exposure due to process digitalization. 

In parallel OT Probes can provide a wide of capabilities from incident detection to cartography, vulnerability management and even more yet to be released by editors. 

Focus first on capabilities that reduce your OT risks, progressively improving the services as it gains maturity! 

Cet article Detection probes for OT : The keys to a successful deployment est apparu en premier sur RiskInsight.

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.

Cybersecurity Regulations in Switzerland 

Two new binding national texts came into effect on July 1st, 2024, to establish a minimum cybersecurity threshold for the electricity supply and railway transport sectors. This article will focus particularly on the revision of the Electricity Supply Ordinance (OApEl).

Global Trend towards Cybersecurity Standardization

The cybersecurity landscape is shaped by various national and international frameworks and legislations:

• The NIST Cybersecurity Framework (CSF) of 2017 in the United States has become a standard for federal agencies to manage and reduce cybersecurity risks, following a presidential executive order indirectly mandating its use.
• In Europe, the 2016 Network and Information Systems (NIS) Directives, complemented by NIS 2 in 2023, aim to enhance the resilience of essential service operators (OSE) and strengthen the security of network and information systems.
• In France, the 2018 Military Programming Law (LPM) for the years 2019-2025 imposes obligations on operators of vital importance (OIV) to secure critical infrastructures against cyber threats.

These initiatives demonstrate a concerted global effort to bolster cybersecurity in response to increasingly sophisticated threats.

Changes for the Swiss Electricity Sector 

In this context, Switzerland’s minimal National ICT standard is now mandatory for the electricity supply sector. 

• The National ICT Standard in Switzerland, implemented by the Federal Office for National Economic Supply (OFAE), aims to protect infrastructures against cyber risks. It covers identification, protection, detection, response, and recovery, drawing inspiration from NIST standards to assess cybersecurity maturity and provide guidance. Unlike the European NIS directives and the French LPM, this standard is not inherently binding.
• The Swiss Electricity Supply Ordinance (OApEl) specifies the Electricity Supply Act (LApEl) and regulates the electricity market to ensure supply security, with a cybersecurity component in its article 8b on data protection. Unlike the ICT standard, it is binding. Its new version, which makes the Minimum ICT Standard mandatory for electricity sector players, took effect on July 1, 2024.

Mandatory Compliance for Swiss Electricity Actors 

Actors that must comply with the National ICT Standard under OApEl within 24 months of its effective date :  

The revised OApEl’s minimum requirements are binding upon their enactment, with no transitional period. The Federal Electricity Commission (ElCom) is now responsible for defining and monitoring compliance. The concerned entities must self-assess over two years and demonstrate compliance to the ElCom. If measures are not promptly implemented, the ElCom engages with companies. In justified cases, an extension may be exceptionally granted.

Surveillance Role of the ElCom 

Under Article 22, paragraph 1 of the LApEl, the ElCom monitors compliance with OApEl provisions and related ordinances. Thus, the ElCom now has a specific mission in the cybersecurity framework for Swiss electricity actors:

• Monitoring: The ElCom monitors compliance with cyber protection measures using the NIST cybersecurity framework and minimum legislative requirements.
• Investigation: In its monitoring process, The ElCom uses self-assessment surveys to document companies’ cybersecurity practices.
• Awareness Interviews: The ElCom conducts awareness interviews with companies deemed crucial for network security and stability.
• Audits: The ElCom can conduct targeted audits in response to anomalies identified during surveys or interviews or based on external indications.

 Legal Compliance Timeline 

Expected Maturity Levels 

The revised OApEl defines three protection levels (A, B, C) to ensure cybersecurity measures are proportional to the potential impact on the Swiss ecosystem. Each level has specific measures and sets expectations for NIST maturity scores (/4).

Membership to each level is proportionate to the volume of electricity produced and/or distributed by network managers and their providers, as well as by producers (excluding nuclear), storage operators, and their providers:

• Level A: More than 450 GWh/year (operators) or more than 800 MW (producers)
• Level B: Between 450 and 112 GWh/year (operators) or between 800 and 100 MW (producers)
• Level C: Less than 112 GWh/year (operators) or less than 100 MW (producers)

Each level has expected maturity scores for NIST control points. For example, for NIST ID-AM 2 (Develop a process for inventorying and continuously maintaining a comprehensive list of your ICT equipment), a NIST maturity level of 4/4 is expected for level A, 3/4 for level B, and 2/4 for level C.

Analysis 

A detailed analysis of OApEl expectations reveals five particularly critical areas, and four others that may appear surprisingly low given the sector and associated risks.

Major compliance points (highest expected scores)

• Governance
• Access Management
• Awareness and Training
• Protection and Security Solutions
• Risk Analysis

Minor Compliance Points (Lowest Expected Scores)

• Communication during and after an incident
• Detection and Investigation
• Mitigation and Isolation
• Business Environment

It is recommended for affected organizations not to neglect preparation for incident communication, response, and isolation capabilities. These elements are crucial for the sector’s criticality to the Swiss economy and the need for operational cooperation for effective crisis management.

Conclusion

With the revision of OApEl, Switzerland’s legal framework gains a new binding sectoral text that will push market actors in the electricity sector to meet expected maturity levels as set by this new regulation.

In perspective with the CySec Rail directive and Finma circulars, Swiss cybersecurity is becoming standardized at the national level, although the texts remain disparate. Indeed, OApEl mainly relies on NIST via the Minimum ICT Standard, while the CySec Rail Directive (for railways) combines elements from ISO 2700X and NIST, and Finma circulars (for the financial sector) formalize sector-specific requirements.

Consequently, it is not unimaginable that other sectors will be impacted soon.

Cet article Switzerland Strengthens Cyber Regulations: Essential Sectors Targeted est apparu en premier sur RiskInsight.

Increasing security requirements for both industrial environments and connected objects have led to a profusion of cryptographic keys in companies that are sometimes difficult to manage. These are used to encrypt and decrypt documents and exchanges as well as to verify the authenticity of messages and files, for example, when updating a component’s software, to ensure its integrity. 

One solution, to the problem of the complexity of managing numerous cryptographic keys within a company, is to implement a KMS (Key Management System). This tool helps protect data, product, and process security in the form of a centralized cryptographic key management tool. 

Beyond standardizing processes, the KMS can help solve problems such as the generation of large numbers of different keys, key storage and access, and key depreciation. 

Why use a KMS? 

KMS (Key Management Systems) are cryptographic key management systems that allow companies to manage their encryption keys centrally and securely. KMSs are designed for organizations managing a large number of cryptographic keys and improve the security of their environments by standardizing processes and providing APIs for crypto functions (signature, encryption, decryption). Organizations with large IT networks and those in the industry with connected objects such as sensors, actuators, embedded systems, or selling connected products are also particularly concerned. 

The importance of good key management is crucial to cybersecurity. Encryption, signature, or verification processes are essential for many organizations, even if they sometimes appear transparent to operational staff. It is important that encryption keys are optimally managed, to avoid, for example, insecure key storage or the use of the same key for multiple devices. 

This article will take a closer look at what a KMS is, how it works, and why it may become essential. Several types of KMS will be presented, as well as the advantages of using them and the difficulties of integrating them. Finally, this article looks at some of the keys to targeting companies that can benefit from this type of tool. 

To get more information on the KMS architecture, you can watch Paul Chopineau conference at the Miami S4x24 https://youtu.be/J5aeAYxcc24?feature=shared. 

Figure 1 : Typical KMS architecture 

The different ways to deploy a KMS 

There are several ways to implement a KMS depending on the options offered by the manufacturer. Some Key Management Systems are offered in SaaS mode while others can be installed on the company’s servers (on premise) or in a hybrid mode- where the keys are stored on premise, but the application is in the cloud. 

Implementing KMSs through cloud solutions enable encryption keys to be managed from a computer or server. These products are more scalable and agile, and easier to deploy and update. Key security, however, will depend on that of the cloud service, even if it is possible to introduce over-encryption. 

On-premise KMS are software and hardware solutions that enable cryptographic keys to be managed using an organization’s internal servers and HSMs. They are generally more customizable and sometimes better adapted to specific needs than KMS deployed in SaaS mode. On premise KMSs, however, take longer to integrate and cost more to purchase (initial CAPEX). They also have the advantage of enabling a company to ensure sovereignty over its cryptographic keys. On premise KMSs are therefore best suited to companies with very stringent security requirements and a greater capacity for initial investment. 

Finally, hybrid KMSs could represent the right balance between optimum security and ease of deployment. The aim is to retain control over the keys, which in this case are stored on site, but to benefit from greater ease of deployment and scalability thanks to a cloud-hosted application. Deployment of the application is made easier, but the hardware resources for key management (HSMs) still need to be installed. A hybrid KMS includes key security approaches of an on-premise solution with software that makes it dependent on the cloud service. Care must be taken, however, to protect against fraudulent exploitation of keys from cloud infrastructures, which could be more difficult to detect than with an on-premise KMS. 

Figure 2 : The three possible implementations for a KMS 

It is also possible to classify products on the market according to provider type. 

Firstly, there are the products of the major cloud players: 

• Amazon with AWS Key Management Service (AWS KMS), 

• Microsoft which offers Azure Key Vault, 

• Google with the Cloud KMS (Key Management Service), 

• IBM which offers a KMS (Key Management Service) integrated into IBM Cloud Private. 

Their products integrate perfectly with the services provided by these major providers, including their secure key storage tools, such as Google’s KMS, which enables keys to be created in the cloud and stored in HSM. 

Specialized companies are also positioning themselves in the market: 

• Cryptomathic with its CKMS (Crypto Key Management System), 

• Entrust, whose product is called KeyControl, 

• HashiCorp, with its product  Vault, 

• Utimaco, whose KMS is called KeyBridge, 

• Thales, for example with its Trusted Key Manager (TKM). 

In particular, these companies offer to run their tools on software resources, such as KMS from Microsoft, Amazon, and Google for HashiCorp; or VMware for Entrust. But also, hardware resources, such as HSM, which provide a superior level of security against physical attacks. 

Finally, the market has also been joined by integrators, such as Atos with its Trustway DataProtect KMS suite, designed for on premises installation on company hardware. 

Finally, Thalès, which positions itself as a hardware provider, publisher, and integrator, offers several key management products for companies. These work in tandem with those offered by more specialized players, as well as with their customers’ preferred cloud services. 

Figure 3: Three main types of KMS providers 

The advantages of using a KMS 

KMS (Key Management Systems) are tools whose full potential has still to be explored, of which can prove particularly useful for managing a company’s encryption keys centrally and securely. Here are just a few of the advantages of using KMSs. 

Firstly, keys will be easier to deploy. KMS enables new cryptographic-encryption keys to be generated quickly and automatically, which is particularly useful when many different keys need to be generated for transmission to products, connected objects or industrial systems. 

In a context where connected object keys are often not renewed and are managed in a non-standardized way, KMS will enable companies to introduce the level of security that will enable them to comply with future regulations on IoT systems. The same applies to the encryption of sensitive data in a database, which is the use case that gave rise to KMS products in the first place. 

To improve key storage and access, KMS offer centralized APIs and interfaces, integrating permissions management with identity and access management (IAM), which can be particularly useful for companies with many types of keys and users of encryption keys. The challenge will be to convince providers and partners outside the company to enter keys via the KMS. This will be an element to be negotiated in future framework contracts. 

KMS also enables one to manage the depreciation of encryption keys, automatically replacing them with new ones when they expire, are compromised or simply become obsolete, for example following a change in the security policy. This ensures that data remains secure at all times. 

In short, KMS are invaluable tools for efficiently and securely managing a company’s encryption keys. They improve compliance with regulations and security standards by ensuring that key management procedures and the keys used comply with established standards. 

Traps to avoid when implementing a KMS 

Setting up a KMS (Key Management System) is a major undertaking, which can be hampered or even halted by the following factors:  

• Deployment costs: KMS can be very costly to deploy. These include license fees, as well as hardware resources such as HSM for key storage, which need to be sized according to usage (frequency of access, volume). 

• Complexity of implementation: setting up a KMS can be complex, especially for companies with a large number of encrypted devices or systems, for whom it will be of high added value. Setting up a KMS can be complex, particularly for companies with a large number of encrypted devices or systems, for whom it will add considerable value. Numerous integrations may need to be set up to communicate with the KMS API, depending on the different use cases. 

• Specific change management procedures: it will sometimes be difficult to convince all the company’s users of the importance of implementing a KMS, and to encourage them to use this tool effectively. To solve this problem, a communication and training strategy is needed to make users aware of the importance of encryption key security and the usefulness of the system.  

• Skills that are rare on the market: IT architects, cryptography specialists, or project managers capable of managing large-scale cybersecurity projects. These are all profiles that are hard to source, and which will be all the more numerous to recruit the more cryptographic keys are used within the organization. Calling on external expertise will therefore be highly profitable and difficult to avoid.  

KMS, an essential solution for secure encryption key management 

In conclusion, KMSs are an essential solution for securely managing a company’s encryption keys. Whether a large enterprise with a large number of encrypted devices or systems, or a small business with similar issues, a KMS can greatly help to centralize and secure crypto key management. 

As an example, take the case of a freight company. It must manage numerous components in its vehicles, such as sensors to ensure compliance with the cold chain, or simply devices for tracking products. These objects connect to public or corporate networks, transmit encrypted data, and are regularly updated. Firmware must therefore be signed when an update is deployed, and encryption keys for data transmitted by sensors must be securely stored to ensure their integrity and confidentiality, as well as being available to operators in the event of a sensor modification. The KMS is particularly useful for all these processes, both to automate them and to facilitate the work of operators, and to ensure that each person involved only has access to the keys he or she uses. The tool will take care of key generation, or key recovery, if the keys have been generated externally, and then all the other stages in the key life cycle. 

It should be noted, however, that assessing the suitability of this technology needs to be taken seriously. Upstream studies and a tendering procedure will be necessary to ensure that the right tool is put in place. By carrying out these procedures with a precise vision of business uses, the company can be sure of not having to change its system later on. 

Cet article KMS: The Key to Secure Management of Cryptographic Objects  est apparu en premier sur RiskInsight.

In fact, many of the systems, equipment, and communications channels in such a network are: 

• Limited in terms of memory and computing power. 
• Located at remote sites with little or no staff or internet access (as opposed to an industrial system within a factory, for instance). 
• Incompatible with wireless technologies, due to the electrical environment of substations and the higher reliability required by certain applications. 
• Deployed for a long period of operation, which creates constraints in terms of maintaining security and interoperability with other systems. 

In an intelligent electrical system, two network infrastructures coexist: an electrical network and an IT network. 

The electrical network connects the equipment used to generate, transmit and distribute electricity. This includes power stations, transformers, power lines, substations, and electricity meters.  

The computer network is used to monitor, control, and optimize power system operations. The aim of IEC 62351 is to secure this IT network. 

Electricity and IT networks coexist in parallel in a Smart Grid context. 

Today, the proliferation of industry standards means that one must wonder what this standard offers in relation to others, or whether it is appropriate for a customer to seek compliance with certain sections of the standard. 

A standard to be used as a guide to good practice 

To date, no organisation offering certification to IEC 62351 has been identified, although some certification authorities do offer conformity assessments (technical tests and associated recommendations).  

Organizations offering conformity assessments IEC 62351 

However, the main purpose of the standard is to provide cyber teams with the tools they need to integrate cyber security into the technical specifications of industrial systems, for use by operators and suppliers. Conformity tests can be based on sections 100 of IEC 62351.  

Overview of the standard 

The introductory section of the standard was published in 2007 in an industrial context that has changed considerably since then. The last section was published in January 2023 and a new section is currently being drafted. The 11 main documents that now make up the IEC 62351 standard, and their regular publication schedule, demonstrate a willingness to adapt to changes in the industrial context. 

The IEC divides the standard into 4 main sections. 

IEC 62351 complements existing cyber standards 

To address Smart Grid cybersecurity issues in a coherent fashion, a combination of ISO/IEC 27001, IEC 62443, and IEC 62351 standards is required. 

The ISO/IEC 27001 family of standards applies to any organization with an information system: it is still applicable to the companies considered here. The standards will provide an overall applicable organization as well as general security measures.  

The ISA/IEC 62443 standard, which applies to industry, provides measures for industrial systems and components. It will ensure that the specific features of industrial systems are considered, at the boundary between IT and OT. 

IEC 62351 is dedicated to IoT, with a very specific field of application: communication in an electrical environment. 

These standards cover increasingly technical and sector-specific subjects.  

In particular, the standard details security measures for communication protocols specific to the sector 

The communication protocols, defined in other standards, are useful for gathering information from equipment in the field and, in turn, for sending commands. Despite their key function, these protocols are not secured by design. The IEC 62351 standard allows security mechanisms to be implemented, using mechanisms already present to limit interoperability impacts. The concerned protocols are: 

  A chapter of IEC 62351 may deal with one aspect of the safety of several protocols. For example, aspects relating to the TCP/IP model are covered jointly in section 3 of the standard. 

IEC 62351 was drafted by the same technical committee (TC57) that developed these communication protocols. The idea is to integrate security mechanisms into protocols that are completely lacking them. By considering their strong presence in the industry and their inherent constraints, the standard’s specifications promote interoperability. There’s no need to change hardware. The standard provides the right tools to secure protocols when required. 

To illustrate the cybersecurity specifications to be found in IEC 62351, the example of section 5, dealing with the IEC 60870-5 protocol, shall be considered: 

Concluding remarks 

The IEC 62351 standard outlines best practices for securing electrical networks, with concrete measures for their implementation.  

This standard can be used by CISOs to define concrete measures to be implemented on their most critical systems, and as a basis for drafting requirements towards their suppliers, to be integrated into specifications.  

Glossary 

Cet article IEC 62351 Standard: What cybersecurity measures are suitable for electrical networks?  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.

The Current Perception of Cybersecurity in OT

In industrial environments, cybersecurity does not always have a positive image and is seen as a potential obstacle to business development. Cybersecurity teams are often criticised for defining rules but delegating their implementation without providing a solution or any help for the implementation of requested changes. For example, it is difficult to regularly change the passwords of dozens of generic industrial accounts, even though this rule is standard on a traditional IT perimeter. As a result, OT teams are often left alone to meet the criteria for security policy requirements.

Left alone, industrial operational teams develop “homemade” solutions designed with their very local point of view, at the scale of their site. These solutions are beyond the group’s control and are very specific (dependence on a local supplier, in-house solution designed for the site’s specific network architecture, etc.), and scalability capabilities are not evaluated. All these solutions are developed by expert and passionate teams who can question security practices and standards, but who rarely have in mind any strategic vision, even at the local scale, making the integration of their solutions at the scale of a group of industrial sites nearly impossible.

Short-term solutions… or even dangerous

In the long run, these local solutions have many disadvantages:

• They are not up to production standards and remain in the POC phase.
• They are poorly documented, which makes maintenance difficult.
• Scaling up to a group of industrial sites is nearly impossible in the long term.

As shown below, some of the “homemade” solutions encountered have even proven to be dangerous:

Real-life examples taken from the 2020-2023 industrial sites audits

Standardise cybersecurity integration in operations

Industrial companies stand out by their strong needs of availability and the substantial real-world implications of the operations. Consequently, investments in this sector must align with the magnitude of these challenges which require cybersecurity solutions of very large scale and complexity. IT, cybersecurity, and OT departments must cooperate throughout the development process to ensure that solutions are suitable for operations while meeting the group’s security standards. The goal is to industrialise the development of cybersecurity solutions for the OT perimeter, providing ready-to-use solutions ready to be deployed at scale.

The solution is the development of a catalogue of cybersecurity services in which services are selected and developed at the group level, in collaboration with all the players (Cyber, operations, IT) and integrating the management of the entire life cycle of the solution (maintenance, documentation, decommissioning, etc.). Thus, the cybersecurity department and the IT department can create, with the industrial department, a product management roadmap, with an industrialized process for the creation of solutions.

Designing an OT Cybersecurity Solution

The process of creating a solution must address several issues:

• Collect the needs of all stakeholders.
• Transcribing needs
• Ensuring Large-Scale Adoption by all industrial sites.

To ensure the efficiency of the process and the solutions, the development of the different solutions is necessarily long and can extend over a period of 2 to 3 years. Wanting to go faster means exposing oneself to poor coverage of operational needs, which could lead to the development of uncontrolled local solutions or poorly controlled and incomplete deployment.

Providing security solutions: a 6-step process

 Solution Factory Process

1.     Research & Development

The goal of the R&D phase is to find the best solution to meet all cybersecurity needs. Thus, in the event of an audit of the central office, compliance with security policies is guaranteed if the tool is used. During R&D, a few points are crucial:

• Assemble a project team with representatives from IT, cybersecurity as well as the operations, to guarantee the usefulness and usability of the solution.
• Define operational constraints at the right level (availability, resistance in a harsh environment, support, etc.) in order to control costs without compromising the usability of the product.
• Plan maintenance, update and release processes as early as R&D to avoid getting stuck with an imperfect or obsolete product.
• Plan the budget and business model of the product. In particular, who has to pay and what are the operating and investment costs. This helps prevent the project from getting stuck at the deployment step due to budget issues.

During the R&D phase, it is also interesting to start from what already exists. This makes it possible to identify talents or solutions that could be adapted at scale and across an OT perimeter. There are two possible approaches to finding solutions:

• Find solutions that OT teams use locally and scale them up.
• Search for cybersecurity solutions from the IT for IT catalogue and adapt them to the industrial world.

Two methods to take into account the existing situation

2.     Prototype

It is essential to think about the user experience and to take care of the image of the product from the prototype. The prototype is first and foremost a showcase that should facilitate the adoption of the product, but which can also damage its image if it is not practical and functional. When presenting the prototype, it is important to frame the use cases covered, and to have a functional and simple product. The first image of the prototype is the one that the operational staff will remember.

3.     Minimum Viable Product

The MVP phase has two main challenges: to test the product, and to bring together promoters. Communication around the MVP must be neat, and everything must be done to avoid failures. When testing, you should not only test the solution itself, but also all the support functions and the integration with the rest of the production environment.

Because the MVP can be a Single Point of Failure for production, it is also necessary to take into account the needs of high availability and set up bypass mechanisms in case of problems to reassure operational team and facilitate the integration. A MVP can severely damage a product’s reputation in the long run if it fails.

4.     Packaging

The packaging stage allows you to define all the prerequisites for the deployment of the product. It is necessary to define:

• Processes throughout the life cycle such as the management of deployment requests, defining the obligation or not to deploy, maintenance processes, update processes considering operational needs, etc.
• Define responsibilities, but considering that industrial sites must maintain a stronger independence than what is usually done on IT perimeters. There needs to be a clear definition of what is delegated to on-site managers in nominal mode and in the event of an emergency.
• The cost model, including long-term cost, must be clearly defined and compared to external solutions.
• Support should be considered as Support as a Service and all processes and tools should be set up and communicated.

5.     Preparing for maintenance

The last step before the actual deployment is the preparation for operational maintenance. For each product, a Solution Owner must be identified to manage the relationships between users, suppliers and – during the integration – the integrator. This person should be identified internally prior to deployment to ensure that maintenance is operational throughout the lifecycle without having to rely on an external.

Prior to deployment, there are three things that need to be taken care of to prepare for the product lifecycle and promote its widespread adoption:

6.     Deployment

During the deployment of the product, early adopters must be supported as much as possible to maximize the chances of adoption of the project by other sites. Financial incentives, such as discounts for early adopters, can also be put in place. Different scenarios of speed of adoption must be anticipated in order to be able to deploy quickly enough in case of great success, but without cost issues in case of adoption difficulties.

Conclusion

In an industrial environment, cybersecurity is still seen as too restrictive, an obstacle to productivity, and too prescriptive. IT departments set up security policies but do not provide solutions to comply with them, which leads to the development of poorly controlled local solutions. To control these risks, one solution is the development of an IT solution catalogue for OT. The development of these solutions is a lengthy process that can take several years, especially when several projects are launched in parallel. To maximize the chances of success, the operational needs must be considered from the R&D phase up until deployment. Integration with operational processes, support processes, and all budget issues must be considered. Finally, the final key to the success of the solution development process is communication. The image of the product must be carefully maintained and controlled to maximize adoption by industrial sites after the start of deployment.

Cet article IT for OT: What process to develop cybersecurity solutions adapted to industrial businesses? est apparu en premier sur RiskInsight.

A SCADA (Supervisory Control And Data Acquisition) system enables the remote management and control of industrial installations. This includes machines such as supervision stations, data centralization servers, maintenance laptops…).

SCADA stations include three main functions:

• Acquisition: Sensors are present on the programmable logic controllers (PLCs) acting on the industrial process. These sensors are connected to the SCADA system so that the various process data can be retrieved.
• Supervision: Operators access the retrieved data and supervise the industrial process in real time.
• Control: when the industrial process allows it, operators can send control commands to PLCs in order to adapt the process.

The nature of these workstations makes them an important element in the production chain, which is why it is necessary to secure their software, which often runs under Windows.

However, there are several limitations compared with a workstation in a conventional office environment:

• The workstations run continuously, with a very low update frequency (once every 1 to 2 years);
• What’s more, these workstations have a long lifespan, often more than 10 years. A SCADA workstation will therefore partly run on an obsolete operating system, which will no longer receive security patches during its lifetime.
• Finally, industrial systems are sometimes totally isolated, preventing the use of security solutions such as Endpoint Detection and Response (EDR), which need to be able to communicate with a central console to send alerts and retrieve actions to be taken.

Conventional security solutions are therefore not applicable in an ecosystem subject to these limitations.

A possible solution: application control

One solution to these problems is application control: this involves managing which applications are allowed to run on a machine, and which are not, by whitelisting authorized applications.

Application control solutions manage both ‘.exe’ files and other program types such as DLLs, drivers, and scripts (e.g. PowerShell, CMD or VBS).

A significant proportion of threats come from malware. This kind of solution allows one to only authorize needed applications, while blocking any undesirable or dangerous ones. Application control also maintains a good level of security in an obsolete system prone to vulnerabilities, since during the compromise stages, an attacker is often led to run malware on a system.

Furthermore, application control is easily integrated into the industrial environment: supervisory workstations are subject to far fewer changes than an office workstation, so there is no need to constantly review the whitelist to add applications to be authorized.

Application control solutions for Windows

Two application control solutions are available natively on Windows: Windows Defender Application Control (WDAC) and AppLocker. WDAC appeared with Windows 10; it is the successor to AppLocker, which has been present since Windows 7. The two solutions have remarkably similar functionalities, however WDAC is actively maintained by Microsoft with regular additions of new features, whereas AppLocker only receives security updates.

When an application is not authorized by the whitelist, its execution will be blocked and the error message below will be displayed to the user. An event containing the blocking information will also be recorded in the Windows logs for review by the Security Operations Center (SOC), or information system administrators.

Application control can operate in blocking or audit mode. In audit mode, the list used is tested: unauthorized applications are still executed, but a blocking event is registered to indicate that they would not work in blocking mode.

For effective application control, it is necessary to create a whitelist that is as restrictive as possible, while still allowing business applications. For both solutions, the whitelist can be set up with three different rules:

• Path-based rules: authorize the application according to the path from which it is executed. These are the easiest rules to use, but they can lead to security issues. It is not uncommon to find authorized folders in the whitelist that are writable by users. Users will then be able to drop any application into the folder to run it, thus bypassing application control.
• Editor rules: authorize the application according to the elements of its digital signature. These rules are just as easy to use as path rules but maintain a high level of security by only authorizing applications from legitimate publishers. The main advantage of this type of rule is that they remain valid after an application update, as the publisher does not change. However, this would require the applications awaiting authorization to be signed, which is not always the case in industrial environments.
• Hash rules: authorize applications according to their hash. These rules impose the highest possible restriction. As each application’s hash is unique, only code explicitly authorized by the policy can be executed. However, this type of rule generates a significant organizational cost: any modification to an application changes its hash; the rule must then be updated to correctly authorize the application.

When it comes to choosing the type of rule to use, there are two possible scenarios:

• On equipment receiving updates, editor rules should be preferred to be able to maintain the validity of the whitelist even after application files have been modified. Path rules can be used secondarily for unsigned applications, while paying particular attention to the access rules for the directories in question.
• On equipment whose configuration will not change, editor rules can be used to easily authorize Windows core code. Business applications can then be authorized using hash rules, as they are unlikely to be modified.

Implementation steps

Now that we know which rules to use, we need to create a whitelist for the machine to be secured. Two approaches are adopted, depending on the type of machine to be managed:

Temporal approach: Deployment by continuous improvement

This method consists in deploying application control starting with a basic policy authorizing Windows components, which is then improved little by little thanks to events generated by the execution of business applications.

This approach is particularly well suited to existing production workstations, where administrators do not have much information on the system. Each event generated must then be reviewed to assess whether the application being executed is legitimate or not. This provides an exhaustive whitelist without authorizing illegitimate applications.

Model-based approach: Deployment on a “golden image”, then replicated on the rest of the machines.

In this approach, WDAC will be deployed on a “golden image“, i.e. a clean image containing all the applications required for the machine’s business use. Once the policy has been correctly configured, the golden image can be cloned on all other machines with the same role. Typically, the golden image could be produced following acceptance testing (FAT/SAT) when a new plant is set up.

This approach is recommended for commissioning new stations into production. By starting with a blank machine where all the software required for the job is installed, we can ensure that no illegitimate applications are present on the machine. It is then possible to use the tools provided by Microsoft to scan the machine and automatically generate a whitelist, authorizing all applications present on the machine.

Limits of application control

It is important to bear in mind the limitations of these solutions, which are not fallible. By their very nature, the actions of an application authorized to be executed are no longer monitored, and the application itself can execute code or launch other programs. Consequently, if an attacker were to discover a vulnerability in a whitelisted application, application control would not prevent its exploitation, which would allow the attacker to influence the industrial process, but it would not allow malicious files such as ransomware to be executed.

There are several ways of bypassing application control, using programs that come as standard with Windows. This is particularly true of ‘mshta.exe’, which can be used to run stand-alone HTML applications (.hta) that can execute code on a machine. For this reason, Microsoft constantly maintains a list of applications present in Windows or signed by Microsoft to be blocked, in order to tighten application control.

The same principle applies to business programs. It is up to manufacturers to have their applications audited to ensure that no vulnerabilities are present that could allow the workstation to be compromised.

Application control on Windows: WDAC or AppLocker?

Overall, both solutions are remarkably similar and compatible with the two deployment modes presented above, so the remaining question is how to choose between the two.

  Whenever possible, it is best to choose WDAC: its strength lies in its global control capability and its various functionalities. AppLocker can only control programs ran by the user, whereas WDAC can also control programs ran by Windows, such as drivers.

What is more, WDAC integrates additional features such as protection against elevation of privileges, and automatic verification of user access on path rules. Microsoft also continues to support the solution and enhance it with new features, while AppLocker only receives security updates.

AppLocker is generally simpler to use than WDAC and allows differentiation regarding the application of rules according to the machine’s users, whereas WDAC’s rules apply to the whole machine without distinction.

However, WDAC is only available on Windows 10 and above. On machines running Windows 7, which are still very common on industrial networks, AppLocker is the only native solution available and should therefore be used. On Windows 10 and above, WDAC is the better application control solution, and should be preferred.

In addition, AppLocker can be used alongside WDAC if you need to differentiate rules for different users. WDAC should then be implemented at the most restrictive level possible, then AppLocker can be used to fine-tune the restrictions.

Cet article Application control: what strategy you should adopt for your industrial supervision system? est apparu en premier sur RiskInsight.

According to the latest Digital Trust Insights study carried out by PwC in September 2019, 53% of the Engineering and Construction (AEC) companies surveyed (sample of 270 global companies) said that they had suffered from cyber incidents which had caused an interruption to their operations between 2017 and 2019.

Even French construction companies are not spared from targeted attacks to compromise data linked to sensitive projects. As an instance, Bouygues Construction has been targeted twice since 2019, and the latest attack in January 2020 caused a paralysis that affected more than 3,000 head office employees. The Rabot Dulliteul group was also attacked in July 2020, causing a slowdown in business. The attackers requested a ransom of 973 bitcoins (~€8 million) and threatened the group to disclose hacked information.

All these examples teach us that it is time to question engineering processes, from design to operation and maintenance, by identifying the cyber risks threatening these processes. Prevention  methods need to be put in place to reduce their probability.

In this article, we will focus on one of the collaborative methods used within the construction industry, which could be a gateway to cyber attacks if the collaborative processes are not properly controlled and secured. This is known as the BIM method.

What do really hide behind the BIM term?

 The BIM (Building Information Modeling) method is a digital collaboration process based on the creation and exploitation of a digital building asset. According to NF – EN ISO 19650, it is defined as the use of a shared digital representation of a built asset (buildings, bridges, roads, factories, etc.) to facilitate the design, construction and operation processes and form a reliable basis for decision-making. As a result, this digital asset represents the most valuable and sensitive asset in a construction project.

How does the BIM collaboration work and what assets does it rely on?

BIM collaboration process level 2 in compliance with NF ISO 19650

The BIM collaboration is essentially based on the exchange of data via models. The starting point is the modelling of business models (MEP, Architecture, Structure) based on the requirements of the BIM convention. These models are then uploaded to the CDE by the BIM coordinator for each discipline. The BIM Manager checks the mock-ups (semantic and geometric checks) and the synthesis unit compiles all the mock-ups into a single synthesis mock-up from which geometric conflicts are detected.

All these conflicts are passed on to the project team via reports in BCF format and are discussed and reviewed at the BIM project meeting. If all goes well, the summary model will be used to prepare the project deliverables, which are then published in the CDE in DWG, IFC and/or PDF format.

Example of an information system based on a collaborative MEP model

To understand the technical foundation on which BIM collaboration is based, we first need to focus on the information system hosting the models. To do this, we have taken the example of an MEP designer who is going to create a model within a design office.

In general, an MEP designer can work on the model either within the company by connecting to the local network or at home using his professional PC and a VPN enabling him to create a tunnel to his company’s local network.

In both cases, the data modified in the model is stored in a database hosted by the company. Access to the model is often uncontrolled within a design office and no authentication system is put in place to access resources as long as you are connected to the company’s local network.

The collaborative platform is then accessed via the Internet to publish the models and documents and share them with all relevant stakeholders.

What are the critical business processes associated with a BIM collaboration?

Digital mock-up management

The mock-up is an ideal target for attackers who want to access the data and exploit it for malicious purposes (blackmail, ransomware, physical attack on the building, etc.). They may aim to destroy all  data, making it unavailable and inaccessible. To achieve this, it is essential to secure the model, and this cannot be done without ensuring the security of the data attached.

The security requirements of such an asset in terms of availability, integrity, confidentiality and traceability are very high.

On the one hand, a model that is unavailable due to the loss of a non-redundant server, for example, has a major financial impact. Penalties can start to be applied as soon as project milestones are no longer met. This unavailability can also affect the company’s image and tarnish the trust placed in it by partners.

On the other hand, the data and information contained in the objects of the model also contain a value. They must not be altered under any circumstances and must remain consistent with the data entered by the business specialists. In addition to the financial and image impact, this could lead to legal proceedings for failure to comply with contractual documents, and could also jeopardise the safety of people and property if the alterations are not detected.

Furthermore, the protection of data at rest and in transit is an essential element in case of data leaks. This data can affect sensitive areas such as networks, access control and fire alarms. Failure to comply with this requirement can have a major impact on the company’s financial situation and image, and can damage the safety of people and property, leading to prosecution.

In general, in the process of modelling a digital mock-up, several players can intervene in the modelling and make their own modifications. These actions must be traced and attributed to their author so that the person responsible can be identified in case of a problem. A lack of due diligence in traceability could easily have an impact on the project’s lead time, in which case the only solution is to revert to an older version instead of correcting the error made by the concerned person.

Creating and sharing of deliverables

Tampering with deliverables is a critical issue, because altering a calculation note or a working drawing can lead to the structural damage of a building, therefore endangering people’s lives. If we apply this logic to that of a nuclear power plant or a military building, the long term effects of this could be catastrophic.

Whether the deliverables are unavailable or leaked, these compromised scenarios have a major impact on data security and can have disastrous consequences for the design office in financial, operational and/or image terms, not to mention the impact on people.

What are the main risk scenarios associated with BIM collaboration?

Scenario 1: Loss of availability of a BIM model

One of the most common risks in BIM collaboration is the unavailability of a model following the failure of a server. In today’s construction industry, some companies are not yet fully aware of the challenges of cybersecurity and do not value the importance of server redundancy. They often use a single server or, in rare occasions, two servers located in the same geographical area, which will not cover all the risks that the building housing these servers could incur (fire, flood, power cut, etc.).

Scenario 2: Unauthorized access to the company’s IS and compromise of sensitive data linked to the model.

A company that only uses a simple authentication system based on login IDs and passwords remains vulnerable to external attacks. A malicious attacker can easily identify a vulnerability in the company’s information system and manage to compromise the credentials of an authorised user and gain access to the models hosted on the company’s servers.

The attacker will then be able to access all the sensitive data entered on the mock-up, in particular data related to high/low voltage, fire safety, video surveillance, air conditioning and ventilation. This data is likely to give him a detailed understanding of how the building works, and will enable him to steal the building plan or sell the data to external parties.

Scenario 3: Unauthorized access to the CDE and exploitation of access rights to deliverables

Similarly to scenario 2, a Common Data Environment without a strong authentication system cannot escape a potential attack, particularly if someone manages to recover a user’s login details using techniques such as phishing or social engineering.

Once the attacker has gained access to the CDE, they can exploit the access rights associated with that user to gain access to sensitive deliverables: plans, diagrams, specifications and any strategic and competitive data. These can then be destroyed or exploited to plan further attacks, or simply sold to third parties to give them a competitive advantage in the marketplace.

Scenario 4: use of external scripts or plugins and alteration or theft of sensitive data

Developing plugins in-house using the functions, methods and properties of the BIM design software API can sometimes seem complex and time-consuming. Some developers reuse scripts provided from sources online. Using these uncontrolled scripts can easily push a malicious element into the IS, subsequently causing access to be compromised. The attacker can then gain access to the model data and steal it for later use or alter it so that it will be unusable.

What are the recommendations to deal with these risks?

Taking into consideration the various security risks compromising the business values associated with a BIM process, it is vital to think about ways of securing the system so as to avoid any potential cyber threats that could jeopardize its IS foundation.

Strengthening the resilience of model servers

A digital mock-up can either be hosted locally on a company server or hosted in the cloud on a CDE. This does not prevent it from being unavailable due to the unavailability of the company’s IS or that of the CDE supplier’s IS.

Among the best practices for avoiding loss of access to a model :

• Redundancy of internal servers on the one hand to balance the load in case of excessive use and therefore ensure optimum performance and fluid access to the model, and on the other hand to ensure business continuity in the case of losing one of these servers. It is strongly recommended that servers are redundant in two different geographical zones to take account of all risks (fire, flood, blackout, etc.).
• Setting up regular back-ups and replicating data in several locations, so that data can be recovered in case of loss. It’s a good idea for these procedures to be tested regularly to check data integrity and to ensure that teams are able to carry out the restoration process smoothly.
  
  

Implementing multifactor authentication

As previously demonstrated, simple authentication to access the model from the company’s internal server or from a Common Data Environment is not enough to be protected from cyber attacks. It is now essential to introduce a strong factorial authentication mechanism (e.g. two-factor authentication) enabling the person to be identified accurately :

• TOTP (Time Based OTP): It is a one-time password based on time. The idea is to encourage users to enter two factors: their user name and password, and a unique six-digit code generated every 30 seconds.
• FIDO2key : It allows users to authenticate themselves in complete security using biometric data or a security key instead of a password.
• Smart Cards: This is a method of securing access to a resource. Users must have a physical or virtual card to access an internal company server or to connect to their CDE account.

It is important to emphasize that these mechanisms are given as an illustration and that the implementation of multifactor authentication is highly dependent on several parameters. On the one hand, it depends on the capacity of the server and infrastructure hosting the CDE and on its interoperability with other systems (ability to integrate with other third parties via API). On the other, we need to ensure that the authentication to be put in place is compatible with the users’ devices: types of device (desktop, tablet, phone, etc.), level of ownership (BYOD, COPE, COBO, etc.), operating systems (Windows, Linux, MacOs, Android, etc.).

Managing access and identity lifecycle

Managing identities and access to a CDE, which represents a goldmine for attackers, should not be taken lightly. Mastering the identity and access lifecycle is a prerequisite.

Identity management

If a new person joins the BIM team :

• Account creation : When a new person joins the organization, a user account must be created in the company’s IS or in the CDE following standardized procedures.
• Roles assignment : Depending on the individual’s role and responsibilities, appropriate roles and privileges must be assigned to access just the necessary resources.

In case of a change of position or mobility within the BIM team :

• Reassessment of privileges : This person’s access rights must be updated accordingly, revoking old privileges and granting new ones. It is therefore important to regularly reassess access privileges to ensure that they still correspond to the person’s actual needs.

If a member leaves the BIM team :

• Account deactivation : This person’s user account must be deactivated immediately to prevent any further unauthorized access.
• Cancellation of rights : All the individual’s access rights must be revoked, including access to systems, applications and data.

Access management

When assigning rights, access rights should be granted according to the principle of least privilege, i.e. users should only have access to the resources they need to carry out their professional tasks.

In addition, it is desirable that access rights should be requested by users, usually via an access request system, so that all requests can be traced and approved.

Regarding the approval of these rights, an approval process must be clearly defined, involving the appropriate managers, to ensure that requests are examined by the right people before being granted.

What is also important is to regularly review and reassess these access rights to ensure that they are still appropriate. If access rights are unused or unnecessary, they should be revoked to reduce the attack surface of the system.

Avoiding installation of plugins or using of unauthorized scripts

Now more than ever before, modelers, coordinators and BIM managers use Visual Programming scripts (Dynamo for Autodesk Revit, Grasshopper for Rhinoceros, etc.) or specific developments via C# or Python on the software’s IDE (Integrated Development Environment) using the API. These manipulations are not controlled and can be a cause of IS access compromise if something has been downloaded from the Internet.

In this case, it is advised to take safety measures such as :

• User privilege check: Access to installing plugins should only be given to users who need them for their work. To do this, simply limit administrative rights on workstations to prevent standard users from installing plugins.
• Centralized installation management : if the company has a centralized network, it is possible to manage plugin installations from an administrative server. This allows you to control which plugins are authorized to be installed on users’ workstations.
• Corporate network security : It’s a good idea to set up firewalls and network security devices to block access to unauthorized or suspicious websites, where users could download potentially malicious plugins.
• Controlling API calls: it is possible to use GPO group policies (on Windows environments with Active Directory) to disable these calls on the workstations of unauthorized users.
• Scripts check: It is recommended that a process for checking and approving scripts is put in place before they are used. It is also advisable to examine scripts in a test environment before using them in a production environment.

Conclusion

It’s clear that the use of Building Information Modeling (BIM) has revolutionized the way we design and manage built assets. However, this transformation has also opened new doors to cyber threats. In this article, we have explored the many cybersecurity issues in the context of digital design with BIM, highlighting the key risk scenarios and best practices for responding to them. It is important to note that the entire approach presented in the article is a cyber standard method adopted by many mature companies (banks, insurance companies, retail actors, etc.). It can be applied to any business sector, whether or not it is accustomed to cyber security.

It remains essential to see cyber security as a challenge that can be met with a proactive approach and concentrated efforts. As we continue to reap the benefits of BIM for the construction and management of modern infrastructure, the protection of our data and systems must remain at the heart of our concerns.

Cybersecurity remains not only an issue for BIM, but a challenge that affects many aspects of our modern lives. Rapidly evolving technologies and increasingly sophisticated cyber attacks demand constant vigilance. As a company, we must continue to invest in the research and development of new cybersecurity solutions and promote awareness of this critical issue.

Cet article Cybersecurity, a new challenge for the digital design of built assets using BIM est apparu en premier sur RiskInsight.

Intro

The emergence of the Industry 4.0 is characterized by the digitization of industry and greater interconnection between the various machines that make up an industrial IS (Information System). However, this growth in communications within industrial Control Systems also leads to an increase in their attack surface. Moreover, the protocols used historically (such as Modbus), offer little or no security mechanism. Some of these protocols were also proprietary, which could cause interoperability problems between the different machines of the IS.

The OPC UA standard was created in 2008 by the OPC Foundation to address these issues, by proposing a standardization of communications between ICS machines, and by integrating many mechanisms to ensure the security of these communications.

The OPC UA standard

The OPC UA standard is an open-source and multiplatform communication standard. It can be implemented on any type of device, regardless of their operating system.

Possible communications offered by OPC UA (Source: OPC Foundation website)

Two types of architecture can be set up:

• Client-server architecture: this is the most widely used architecture. It is composed of hardware and/or software elements that contain data, OPC UA servers that provide this data or services, and OPC UA clients that can interact with the servers to use their services or access their data.
• PubSub architecture: it can be used to exchange a higher data volume. It is composed of Publishers who send messages, and Subscribers who receive these messages through a Message Oriented Middleware (MOM).

Client-server architecture security

As the client-server architecture is by far the most widely used, we will now look in more detail at the security mechanisms offered by the OPC UA standard in this type of architecture.

First of all, three levels of security are available regarding the encryption of communications between a client and an OPC UA server:

• None: messages are sent in clear text, without any protection
• Sign: messages are signed. This protects the integrity of the transmitted data, but not their confidentiality
• SignAndEncrypt: messages are signed and encrypted. In this case, the confidentiality of the messages is also protected

To set up an encrypted channel, the client and server each have an X.509 certificate and an associated private key, which they use to exchange a session key in a secure channel. Then, they can use this session key to encrypt the rest of the exchanges, using symmetric encryption algorithms.

Several levels of security for user authentication are also available. To authenticate, clients send tokens to the servers called UserIdentityTokens, which contain the information necessary for the authentication process. There are several types of UserIdentityToken, and the server chooses which types it accepts:

• AnonymousIdentityToken: this token does not contain any specific information. If the server accepts it, and authenticates the user as an anonymous user
• UserNameIdentityToken: this token contains a username and a password. If these are valid, the user is authenticated and then obtains the profile and rights associated with his username
• X509IdentityToken: this token contains an X.509 certificate. If the server has registered this certificate, the user is authenticated and then obtains a profile and the rights associated with the certificate
• IssuedIdentityToken: this token encapsulates an access token provided by a third-party access management service, like an OAuth2 server for example

Finally, once authenticated, the user has access to the server’s nodes. Below is an example of nodes that could be encountered on an OPC UA server:

OPC UA nodes

Access control can be set up to restrict access to some nodes to high-privileged users (administrators, etc.), or to require that the communication channel be encrypted to access some sensitive nodes. The figure below summarizes how access management to a node works:

Role overview extracted from chapter 2 of the OPC UA specifications

OPC UA audit tooling

Only few public tools are available to audit OPC UA applications. One of the most well-known is the Metasploit module called « msf-opcua ».

This module is composed of three scripts:

• opcua_hello: sends a “Hello Message” to a list of IP addresses, for a given port, to detect the presence of OPC UA servers among this list
• opcua_server_config: this script requires an authenticated access to an OPC UA server to be used. It allows to retrieve information on the configuration of the server endpoints (encryption, authentication…)
• opcua_login: performs a dictionary attack on a server using username and password authentication

Although it provides some useful functionalities, this tool has some limitations. For example, it is not possible to scan several ports at once with the opcua_hello script. Another example is that the opcua_server_config script requires authentication to retrieve configuration information, which is available without authentication.

Therefore, Wavestone decided to improve this tool. It was decided to stop using the Metasploit framework, which imposed too many constraints, therefore the tool is now an independent Python script, renamed « opcua_scan ». It is based on the opcua-asyncio library, unlike the msf-opcua module which uses the python-opcua library declared deprecated by its authors.

The tool is accessible with this link, and provides two commands: “hello” and “server_config”, which reimplement and improve the functionality of the opcua_hello and opcua_server_config scripts of the msf-opcua module. The opcua_login script is not included, as no improvement were performed, and it can be used directly.

The hello command

This command is used to detect OPC UA applications in a network. It sends “Hello Message” to a list of IP addresses, on a given list of ports, and deduces the presence or absence of OPC UA servers on the targets. Then, the FindServers service, which is supposed to be implemented by any OPC UA server, is used to retrieve the ApplicationDescription of the server (and other OPC UA applications known by the server). This object contains useful information, such as the productUri, which gives information about the software or library used to run the detected server, or the discoveryUrls, which indicates the URLs to the server’s DiscoveryEndpoints. These endpoints can be used by the server_config command to retrieve more information about the server configuration.

Several options have been added to the command, such as the configuration of the timeout or the possibility to retrieve the list of detected servers in a JSON output file.

This is how the hello command could be used in practice:

$ python opcua_scan.py hello -i <IPs> -p <ports> -o hello_output.json

Example of results generated by the hello command

And the screenshot below shows an extract of the generated JSON file:

Extract of an output file generated by the hello command

The complete documentation of the hello command and all its options is available here.

The server_config command

Thanks to the DiscoveryEndpoints retrieved with the hello command, we now have access to the entire Discovery Service Set of the server. No authentication or encryption mechanisms are required to use these services. Among these services, the one called GetEndpoints can be used to retrieve the endpoints to connect to the server, as well as information about the configuration of these endpoints. This information is given through EndpointDescriptions objects, which contain, among others:

• The security level of the encryption accepted on the endpoint (None, Sign ou SignAndEncrypt)
• The signature or encryption algorithm used
• The types of UserIdentityToken accepted by the endpoint (AnonymousIdentityToken, UserNameIdentityToken, X509IdentityToken or IssuedIdentityToken)

The server_config command allows to retrieve the EndpointDescriptions of all the servers detected via the hello command, and to identify among these servers those that accept anonymous authentication or the None security level. All this information is accessible for a non-authenticated user.

In addition, if an authenticated access to a server is possible, the command also allows to browse the nodes of the server and identify the rights that the current user has on these nodes. For example, it is possible to obtain a list of nodes of type Variable that can be written to, or a list of methods that can be executed by the user.

Finally, other useful options have been added to the server_config command:

• -o (or –output) allows to set up a JSON output file to store the results of the command and browse them more easily than on a terminal. Additional information is stored there, such as the value of the UserWriteMask attribute of the nodes, which indicates which attributes of the nodes can be modified by the user.
• -r (or –root_node) allows to browse only a subset of the server’s nodes from a starting node specified in the argument. Indeed, browsing all the nodes can be long and this option can be used to target the nodes of interest.

The complete documentation of the server_config command and all its options is available here.

In practice, this is how the server_config command could be used:

The output file of the hello command is given as an argument (via the -t option) and will be used to retrieve information about the endpoints of the detected servers::

$ python opcua_scan.py server_config -t hello_output.json

Example of results generated by the server_config command

Here, the server allows unencrypted and anonymous connections or authenticated with a username and password. If the server did not allow anonymous connections, the opcua_login script of msf-opcua could be used to try to find valid credentials, but this is not necessary in this example

It is therefore possible to anonymously access the server, browse its nodes and search for interesting nodes (the beginning of the command result has been deliberately cut off, and the « TemperatureControl » directory has been targeted with the -r option to reduce the number of nodes browsed):

$ python opcua_scan.py server_config -t hello_output.json -o config_output.json -nw -r ‘ns=3;s=85/0:Simulation’

Example of results obtained during a search for writeable nodes

Writeable nodes can then be further analysed in the output file that was configured in the previous command:

Extract of an output file generated by the server_config command

Here, it seems possible for an anonymous user to remotely turn on or off an air conditioners via the detected OPC UA server

Conclusion

Despite the security mechanisms provided by the OPC UA standard, misconfigurations can easily occur and can impact the availability of industrial assets. The tool developed by Wavestone and presented in this article facilitates the audit of these configurations to better assess the security of Industrial Control Systems.

Finally, the OPC UA specifications defines more security mechanisms, such as the management of certificates by a Global Discovery Server or the encryption of PubSub messages thanks to the implementation of a Security Key Server. The OPC UA standard could therefore enable further progress in terms of security, but few implementations of these mechanisms exist to this date.

The tool is available on Wavestone’s Github account: https://github.com/wavestone-cdt/opcua-scan

This tool was also used during a Arsenal lab session at BlackHat Asia 2023 in Singapore: https://github.com/wavestone-cdt/bhasia23-opcuhack

Cet article A look at OPC-UA, an emerging modern ICS protocol est apparu en premier sur RiskInsight.

However, in Industrial Control Systems, we never talk about the security of the code that controls the process, why? This is the gap the TOP 20 project is trying to close.

Project genesis

The project started with Jake Browdsky’s presentation at the S4 conference in 2019:

In this talk, the concept of securing the industrial process by applying secure coding practices in the PLC code is discussed and several examples are mentioned.

This idea was then transformed into a collaborative project by Sarah Fluchs and Vivek Ponnada, on which more than 900 people contributed with their ideas!

Programmable Logic Controllers

Programmable Logic Controllers (PLCs) are located at the core of automation, at the level 1 of the Purdue model.

ISA representation of the Purdue model
Is The Purdue Model Dead? – Dale Peterson: ICS Security Catalyst (dale-peterson.com)

PLC are embedded, real-time computers that interact directly with the sensors and the actuators to monitor and control a part of the industrial process.

They run an infinite loop, composed of 4 steps :

The “logic”, or code of the PLC, can be written in different languages, as defined in the IEC 61131-3 standard:

• Ladder diagram (LD)
• Function block diagram (FBD)
• Structured text (ST)
• Instruction list (IL) [now deprecated]
• Sequential function chart (SFC)

The TOP20 document

The TOP20 document is the result of the online discussions to identify the 20 most important coding practices and can be downloaded from the project website.

Like the OWASP TOP10, it doesn’t aim at describing each and every possible secure coding practice, at least for now.

Each of the TOP20 practice is detailed with the same information:

The 20 practices can be organized in three main categories:

A few examples

Let’s have a look at one example from each category. For this we’ll use an entry-level PLC from our lab, a traffic light as well as a SCADA supervision.

Unfortunately, each PLC vendor -even each PLC family- uses its own specific programming software; examples showcased here cannot be copy-pasted in another PLC brand code and will require a different implementation.

The PLC code as well as the SCADA project used for the demonstration can be downloaded from our github page.

Rule #13: Disable unneeded / unused communication ports and protocols

This practice consists of hardening the PLC. Most PLCs today offer support for several ICS protocols, as well as a variety of additional services like FTP, a web server and many more.

Disabling the services not used and reinforcing the security of the ones enabled (changing default credentials, etc) is a necessary step to reduce the attack surface, and consequently limit the number of security patches to apply in the future (the less features enabled, the more vulnerabilities will be applicable and will have to be patched).

Let’s take a look at the video:

Rules #6 and #8 : Checking inputs at the PLC level

These two rules can be demonstrated in the same example as they follow the same principle : do not blindly trust external input! For someone like me who has done his fair share of web application pentesting, I couldn’t agree more!

Valid ranges for input values are oftentimes implemented at the SCADA level, leaving room for an attacker to directly write an out-of-range value to the right PLC register.

This is especially true for counters and timers, which should be checked to ensure they’re superior or equal to zero, and that the value is inferior to a high limit that makes sense for the process.

Let’s take a look at the video:

Monitoring the PLC rules #2 and #5

We can leverage operational data from the PLC to try to detect abnormal situations that could be cybersecurity incidents.

PLC state

Making sure the PLC is in “RUN” mode is critical for the safety and security of operations. A stopped PLC could prevent the SCADA HMI from displaying the right information to the operator, leading to bad decisions.

Likewise, features like input and output “forcing” could result in the SCADA HMI not displaying the real state of the process, and should be detected and clearly displayed to the operator.

Let’s take a look at the video:

This technique can also be used to detect PLCs in “PROGRAM” mode, which allows the PLC to be remotely programed.

PLC firmware and code version

Wouldn’t it be great to be able to query the firmware version of your PLC directly from a Modbus register? Well, you can!

In addition, on our PLC, we can also get a checksum of the PLC code, meaning we can detect if somebody has tampered with the PLC code, raise an alarm, and investigate if we cannot match that to an entry in the change management register.

Let’s take a look at the video:

So what can you do?

The top 20 document is readily available, but how can you use it?

If you want to learn more about PLC code security, you can also check the content we showcased during our workshops at DEFCON and BruCON on our Github page.

Cet article Top 20 Secure PLC Coding Practices est apparu en premier sur RiskInsight.

What is S4?

A 3 day conference, dedicated to ICS cybersecurity, held in Miami South Beach and organized by Dale Peterson.

• 3 stages: the Main Stage at the Fillmore theater, stage 2 and stage 3 mainly for technical deep dives at the ELV
• the Cabana Sessions around the Surfcomber pool to network, discuss with vendors such as Dragos, Nozomi Networks, Phoenix Contact, Keysight and many others but also get a copy of the book “Countering Cyber Sabotage: Introducing Consequence-Driven, Cyber-Informed Engineering (CCE)” signed by Andy Bochman and Sarah Freeman
• the Welcome Party at the Botanical Garden

This year, around 800 people attended the conference to create the future and Wavestone was there through my participation as both an attendee but also a speaker.

S4 actually started on April 18th with two specific events:

• The first ICS4ICS exercice (I will talk about that a bit later in this article)
• Women in ICS Security social event: more than 160 women attended the conference this year and it was great having the opportunity to meet incredible talents at a women only event; it was the first time such an event was organized at S4 and I hope not the last!

The talks started on April 19th and Dale kicked off the event with a keynote introducing this  year’s theme: No Limits!

In this article, I am going to present some of my favorite talks.

If you are interested, all videos will be released in the next weeks on S4Events YouTube channel: https://www.youtube.com/c/S4Events/videos Here is the full S4x22 video release schedule: https://s4xevents.com/wp-content/uploads/2022/04/S4x22-Video-Release-Schedule.pdf Stay tuned!

A Tale of Two (very different) Secure ICS Architectures

Speaker: Alexandrine TORRENTS, Wavestone

Well, I can’t say this is my favorite talk but I have to start with this presentation as this year was a bit special for me: first time speaker at S4.

I had the opportunity to talk on the Main Stage, right after the keynotes and talk about ICS secure architectures.

No Limits! It gave me the idea of thinking about the future of ICS network architectures.

In this presentation, I compare and contrast the requirements and corresponding secure ICS network architecture of two very different businesses within the same company: power plants and solar/wind farms.

I won’t detail the whole presentation today as I will write a more detailed article in a few weeks just in time for the release of the video on June 13th.

Interview: CISA Director Jen Easterly

Dale Peterson interviewed CISA Director Jen Easterly on the Main Stage.

The video of the interview is already available on S4Events YouTube channel: https://www.youtube.com/watch?v=xOdIUA4lWnI

I found this interview very interesting, and also very inspiring.

Jen presented CISA’s goal: understand, manage and reduce risks, as well as specific objectives for 2022-2023.

One is oriented on processes:

• Baseline goals have been defined to drive common baselines across all sectors.
• Sector specific documents will be added in the next two years.

Another one is oriented on people:

• CISA wishes to expand its ICS team and is recruiting, especially senior ICS experts.
• CISA will create an ICS JCDC workgroup (Joint Cyber Defense Collaborative) to unify defensive actions and drive down risk in advance of cyber incidents related to ICS. The workgroup will include both public and private sectors.

Jen also talked about Shields UP (https://www.cisa.gov/shields-up) . Since Russia’s invasion of Ukraine, intelligence indicates that the Russian Government is exploring options for potential cyberattacks and CISA is asking every organization to be prepared to respond to disruptive cyber incidents. They published several recommendations on their website.

This interview made me think about what could be done within the French cybersecurity agency (ANSSI) regarding ICS cybersecurity. From my understanding, the ICS expertise is spread across different business units. But what if there was a dedicated ICS cybersecurity task force driving all efforts?

Security Truth or Consequences

Speaker: Dale Peterson

Dale presented a Hard Security Truth: Cybersecurity controls at best reduce the likelihood of attack, but they do not eliminate the possibility of compromise.

Indeed, even with the best security controls implemented and the best OT security program,organizations can be defeated by human errors, configuration errors, or 0day vulnerabilities. It is not a game asset owners can win, they can only reduce the chances of losing.

But what if companies could shift to a consequence reduction mindset and maybe win the cyber risk management game?

Let’s take the example of a glass manufacturer. One of the most sensitive PLCs controls the heat of the oven. if this PLC is compromised, it could be very dangerous for the process. Of course, you can reduce the likelihood of this compromise by implementing security controls, such as network filtering for example. But what if the PLC gets compromised anyway? How could you reduce the impact and get back the control of the process as quickly as possible?

Well, do not only think about cybersecurity and focus on the business and its resiliency. Adding a manual control on the production line could do the trick and make sure the consequence of an attack would not be that important.

Well, it is not always that simple but I find it interesting to focus on consequences and find business oriented solutions to reduce cyber risks.

Dale concluded his talk by presenting his 3-step approach for consequence reduction:

• Identify high consequence event within your organization
• Determine if a cyber attack can cause that event
• If yes, find a way that it won’t

This approach looks like a safety approach, but applied to additional consequences not covered by safety, like loss of revenue.

PIPEDREAM & ICS Cyber Threat In 2022

Speaker: Rob Lee, Dragos

Rob Lee was supposed to present his ICS Cyber Treat review but with the recent news, he made a focus on Pipedream, the ICS attack toolkit/malware analyzed by Dragos: https://www.youtube.com/watch?v=H82sbIwFxt4

This toolkit has been developed by the threat group Chernovite and its capability has not been employed yet. Pipedream seems to be the most flexible ICS attack framework to date. It uses ICS-specific protocols for reconnaissance and manipulation of PLCs.

The primary targets of the toolkit include PLCs from Omron and Schneider Electric. However, pipedream capabilities could impact much more PLC vendors.

Rob presented some of these capabilities, as well as potential attack scenarios following the ICS cyber kill chain:

• EVILSCHOLAR – A capability designed to discover, access, manipulate, and disable Schneider Elctric PLCs.
• BADOMEN – A remote shell capability designed to interact with Omron software and PLCs.
• MOUSEHOLE – A scanning tool designed to use OPC UA and FINS protocols to enumerate PLCs and OT networks.
• DUSTYTUNNEL – Custom remote operational implant capability to perform host reconnaissance and command and control.
• LAZYCARGO – Drops and exploits a vulnerable ASRock driver to load an unsigned driver. Works on all Windows systems not just those with ASRock

Dragos published a full report on pipedream: https://www.dragos.com/blog/industry-news/chernovite-pipedream-malware-targeting-industrial-control-systems/

What I find the most interesting in this toolkit is that it does not use a lot of CVEs, but mainly legitimate functionalities of PLCs and industrial protocols to target industrial control systems.

This toolkit was also analyzed by Mandiant, who called it Incontroller. They also made a presentation at S4 and published a detailed report of their analysis: https://www.mandiant.com/resources/incontroller-state-sponsored-ics-tool

Unpwning A Building

Speaker: Peter Panholzer, Limes Security

This presentation was pretty original as cybersecurity experts had to exploit a cybersecurity vulnerability to resolve a cybersecurity incident.

The incident: a building had a complete loss of their building automation system, using KNX devices.

The initial situation: Devices of the building were no longer operational and the vendor recommended replacing the devices (cost > 100k€).

Idea to resolve the incident: the BCU key is a security parameter used to protect the device from being modified; the BCU key was probably set on the device by the attacker. The idea was to retrieve the BCU key and reprogram the devices.

How: the cybersecurity experts asked for some samples of devices, and tried to read the key from the devices. They managed to dump the firmware of one of the devices and access the memory that was not protected. They used a sliding window and with some brute force, they managed to retrieve the key that was written in clear text in the memory.

Resolution: Fortunately (in this case), the key was the same for all devices and it could be used to reset the devices and restart the building automation system

Unprecedented Attack, Unprecedented Response – SUNBURST From The Inside

Speaker: Tim Brown, SolarWinds

You’ve all heard about the SUNBURST cyberattack on SolarWinds in December 2020.  In this presentation, Tim Brown, CISO of SolarWinds took us inside and explained how he managed this major incident in the first hours, days, weeks, and months that followed.

Besides the presentation in itself that was very good, the most interesting point for me is about the final thoughts and the fact that this incident has increased the level of transparency expected of vendors.

This event caused many changes and has brought supply chain security even more to the front of cybersecurity discussions. 

Using NTIA’s VEX to Tame the Vulnerability Tsunami

Speaker: Eric Byres, aDolus Technology

SBOM (Software Bill of Materials) was kind of trendy this year at S4. Vendors and asset owners should have a SBOM to list all components and libraries used in their products and use it in their vulnerability management process to identify patches to install.

With this, you could end up with thousands of vulnerabilities to patch. But is the vulnerability exploitable in your context?

Indeed, just because a vulnerability database references a particular software component doesn’t mean the vulnerability will actually be exploitable in every software product that includes that component. As a result, organizations can waste valuable time fruitlessly searching for and patching vulnerabilities, even though those vulnerabilities aren’t actually exploitable.

This introduces VEX (Vulnerability Exploitability eXchange), which is a security advisory profile that will be used in combination with SBOM. This profile allows software suppliers to issue a standardized, machine-readable document that states whether or not their products are “affected” by one or more known component vulnerabilities.

You can use VEX for multiple use cases:

• Multiple products to one vulnerability: what products are affected by Log4j?
• Multiple vulnerabilities to a specific product: which vulnerabilities affect the product I use?

The status of a vulnerability includes affected, not affected, fixed, or under investigation.

VEX provides a method for asset owners to focus on exploitable vulnerabilities that present the most risk.

Once you get a comprehensive list of vulnerabilities that could be exploited in your product, as an asset owner, you can use the SSVC methodology to decide what to do in your context with the vulnerability: patch now, patch during the next scheduled maintenance, defer.

Another talk was related to this subject during S4: CSAF, not SBOM, is the Solution, presented by Jens Wiesner from BSI. CSAF (Common Security Advisory Framework) is an open standard about security advisories.

Top 20 PLC Secure Coding Practices

Speakers: Vivek Ponnada, Nozomi Networks and Josh Ruff, Deloitte

The Top 20 PLC Secure Coding Practices is the result of a community effort to provide guidelines to engineers that are creating software (ladder logic, function charts etc.) to help improve the security posture of Industrial Control Systems: https://plc-security.com/

The idea came from a talk at S4x20 where Jake Brodsky asked why engineers and technicians aren’t trained to code and configure PLC’s in a secure manner, and then gave examples of what should be taught and done.

The aim of this session was to present some of the practices in detail and with concrete examples.

Below are two of the practices that were presented:

• Practice #3: Leave operational logic in PLC

While HMI visualization software provides some level of coding capabilities, this functionality should not be used for control or safety coding

The idea with this practice is to make sure that controls are performed by the PLC itself and not by the HMI. This way, if you bypass the HMI and send a request directly to the PLC, the PLC won’t automatically accept your request but will perform controls to make sure the logic makes sense.

It is similar to the OWASP recommendation in IT to implement controls on the server side and not on the client side for web applications.

• Practice #7: Validate paired inputs/outputs

When mutually exclusive paired inputs or outputs that physically cannot happen at the same time (e.g., motor start/stop, valve open/close) are asserted simultaneously, this may indicate a sensor failure or malicious activity.

The idea with this practice is to implement controls based on inputs/outputs that are linked together. For example, a compressor cannot be started and stopped at the same time. An attacker could turn on both the start and stop outputs simultaneously. To avoid that, a single output could be used to run the compressor with interlocks and delay timers.

If you already know the Top 20 PLC secure coding practices, you won’t learn anything with this presentation but I think it is a great introduction to understand the mindset behind these practices.

Something interesting as well, several talks this year were linked to PLC secure coding practices:

• PLC EDR: Model Checking of Logic
• PLC Library to Detect Abnormalities

You can find out more about these presentations, as well as others in Arnaud SOULLIE’s video on S4: https://www.youtube.com/watch?v=9XCNjmKJiTk

ICS4ICS: Results of the First Major Exercise

Speaker: Megan Samford, Schneider Electric

Like I mentioned earlier, S4 was the stage of the first ICS4ICS exercise on April 18th. ICS4ICS stands for Incident Command System for Industrial Control Systems.

Megan Samford talked at S4x20 about the fact that cyber was the only designated federal disaster type not currently using Incident Command System for its response framework.

Since 2020, a team of more than 1000 volunteers has been put together to create a global framework of cyber responders.

The Incident Command Process is based on a planning P cycle that provides a proven structured process to manage any incident with a standardized approach to organizing and executing work.

The objective of the exercise was to present this methodology as well as the structure of documents and templates that can be used to follow a cyber incident:

• Cover Sheet
• ICS-202 Incident Objectives
• IICS-203 Organization Assignment List
• ICS-204 Assignment List
• ICS-205A Communications List
• ICS-207 Incident Organization Chart
• ICS-208 Safety Message/Plan
• ICS-214 Activity Log

The goal for ICS4ICS after S4x22 is to expand its capabilities by:

• Conducting ICS4ICS exercices globally
• Offering ICS4ICS credentials and training globally
• Supporting more complex incidents

Of course, ICS4ICS is more of an organizational framework and does not give guidance about the cyber incident itself. I would be interested in the next few years to have insights on how companies actually used this framework and how it helped their ICS cyber incident response.

Finally, if you still have time, I recommend the following presentations as well:

• Cyber Conflict and International Relations
• Assessing the Balance Between Visibility and Confidentiality in ICS Network Traffic
• Inside Industroyer2 and Sandworm’s Latest Cyberattacks Against Ukraine
• The Great Debate: Cyber Insurance Will Play A Major Role In OT Risk Management
• When C-SHTF: Lessons Learned from the Front Lines in OT Incident Response

S4x22 was great! So many good talks but also (and foremostly) the opportunity to see again so many familiar faces of the ICS community and meet new people.

I already look forward to S4x23 that will take place from February 13th to February 16th, 2023. Next year, the conference will still be in Miami South Beach, but at the Loews as the Fillmore will be in renovation.

Cet article S4x22 – Write up of the ICS cybersecurity conference est apparu en premier sur RiskInsight.

The energy sector is made up of vital infrastructures and provides essential services for a country. The sector, shaped by increasing digitalization, is undoubtedly a prime target for cyber attackers with consequences that are liable to create shockwaves throughout the service industry as well as all major infrastructure. Taking electricity as an example, an outage spanning a few days would have grave consequences on transport, health and communication almost guaranteeing they cannot perform their core functions.

A sector undergoing transformation

The energy sector began its transition with the arrival of renewable energy. The shift in the sector is also due to innovative techniques and systems that have been integrated into the power grid to help manage the complex task of balancing energy levels, because it is vital that the energy pumped in and out of the grid at any one time always remain equal. This level of transformation leads to an increased need for flexibility to ensure security of both the power supply and the significant investments in the power grid. These are the objectives that have and will continue to drive concepts such as smart grids, to enable the control of energy consumption and optimization.

In response to these business evolutions (market shifts), the energy sector is undergoing a digital transformation that is disrupting the way energy is produced, processed, stored, transported, and consumed. Overall, information and communication technologies have helped optimize the supply chain. An example being the widespread deployment of industrial internet of things (IIOT) devices. The switch to these devices has led to an explosion in the volume of data in day to day activities. While energy companies must now use this data to be more agile in their decision making by effectively leveraging it, the large volumes of data expose the industry as a whole to a host of data based malicious actions, making cyber security a priority for the energy sector.

Here is a concrete example: remotely piloted, wind turbines and solar panels are by nature connected objects. They must be accessible remotely and therefore secure. However, these new projects do not systematically consider all cybersecurity constraints and related technical solutions (secure protocols, appropriate access technologies, etc.) from the design phase.

An increasingly targeted sector

Let’s look at the “history” of cybersecurity in relation to this sector: the discovery of Stuxnet in 2010 created a shock wave within the energy industry. This attack highlighted unknown vulnerabilities at the time.

In December 2016, some inhabitants of Kiev and its periphery were deprived of electricity for about 1 hour due to the disconnection of the substation of the Pivnichna electricity transmission power grid. The attack began as part of a massive phishing campaign in July of the same year, which exploited a vulnerability in Windows XP. The failure was caused by the remote switching of the circuit breakers to cut power.

Since then, cyber events have become recurring occurrences. Another example: renewable energies are new targets for cyber attackers. In 2019, in Utah in the United States, a wind and solar power system suffered connection losses with the company’s control center for 12 hours, causing power outages in surrounding homes. Cyber attackers had exploited a known vulnerability on unpatched firewalls causing a denial of service of equipment.

In 2021, the executives of Colonial Pipeline, which connects refineries across the United States, decided to block all their distribution operations following the spread of ransomware. The company said they paid $4.4 million in ransom for hackers to provide a computer tool to restore their business ^[1].

The energy sector is one of the most targeted sectors. According to the X-Force Threat Intelligence Index 2022 ^[2], the energy sector ranked as the fourth most affected sector in 2021, with 8.2% of all observed attacks, behind the manufacturing industry, the financial sector, and the professional services sector.

In 2021, ransomware was the most common type of attack against energy organizations with 25% of attacks. Oil and gas companies are particularly affected by this phenomenon. Remote Access Trojan (RAT), DDoS and Business Email Compromise (BEC) follow with 17% of attacks each.

While cyber-attacks are most often targeted for profit and espionage, the energy industry also deals with sabotage intentions, sometimes for geopolitical reasons. Some hacktivists can also pose a threat by attacking critical infrastructure. The recent ongoing major geopolitical destabilization events reinforce these risks.

The energy sector has critical infrastructure. In an increasingly interdependent world, any disruption, even initially limited to an entity or geographic area, can produce broader cascading effects as outlined below:

Impact Chain-Wavestone

To fight effectively against these new threats, the States and the European Union have adopted binding regulations to ensure a higher level of cybersecurity on the most critical facilities.

What role for regulation?

In France, the competent authority for cybersecurity is the Agence nationale de la sécurité des systèmes d’information (ANSSI). To respond to the increase in threats, the concept for the defence strategy has been based on the Military Programming Law (LPM) since 2013 in order to secure the Operators of Vital Importance (OIV). ANSSI mainly insists on procedures for the approval, control, and maintenance in security conditions of Vital Information Systems (SIIV).

At European level, the objective is also to protect sensitive organizations such as operators of essential services (OES) in the energy sector. The reference point for cybersecurity is currently the Network and Information System Security (NIS) directive. Its primary objectives are to increase cooperation between EU Member States, by facilitating the exchange of strategic and operational information, and to improve the cyber resilience of public and private entities in key sectors such as energy. When it comes to energy, ENISA wants to protect from large-scale threats with increasingly cross-border and interdependent power grid.

The complexity lies in the operational application of specific measures in industrial environments where equipment and means of production are expected to last several decades. Thus, modifying operational processes and/or equipment to incorporate additional cybersecurity is a concrete challenge. The impacts of this transition are significant both in financial and operational terms. This makes cooperation and sharing even more important for energy stakeholders to find pragmatic and adapted solutions: adapted network architecture, technical solutions compatible with the industrial world, vulnerability management processes and updates built with operational teams for example.

Conclusion

Considering the critical nature of the energy sector infrastructure, it is essential that business and cybersecurity actors in the energy sector communicate on good cybersecurity practices, learn from previous attacks, and contribute to changing the overall level of protection. It is in this context that the first forum dedicated to energy stakeholders «Cyber4Energy» will be held in Marseille on 30-31 March 2022. This event will be an opportunity for professionals to discuss cybersecurity challenges and dedicated solutions available to the sector.

Références :

[1] Etats-Unis : les oléoducs Colonial Pipeline ont versé une rançon de 4,4 millions de dollars à des hackeurs (lemonde.fr)

[2] X-Force Threat Intelligence Index 2022, IBM Security X-Force Threat Intelligence Index 2022 (ibm.com)

Cet article Energy sector: A cybersecurity obligation in the face of attacks to ensure the provision of essential services est apparu en premier sur RiskInsight.

In this article, we expose our vision of the market and the maturity of cybersecurity for industrial information systems (IS), as well as our convictions and analysis on the subject.

What is the state of the threat to industrial information systems?

In 2011, the cybersecurity of industrial information systems, suddenly came to the forefront with the Stuxnet attack and the discovery of a state level threat against Operational Technologies (OT). For a decade, Advanced Persistent Threats (APTs) were considered the biggest threat to industrial system security, through impressive and complex attacks, such as the series of “Black Energy” attacks against the Ukrainian power grid between 2007 and 2014, or the “Triton” attack against the safety systems of a chemical plant in Saudi Arabia in 2017.

However, the Snake/EKANS case in 2020 allows us to point out a trend that has been continuously increasing for the past few years: the appearance of ransomware in ICS. These ransomwares are the result of opportunistic attacks on vulnerable systems or are side effects of attacks targeting the corporate IS, as in the case of Colonial Pipeline in May 2021.

With the ransomware business model becoming sustainable on one hand, and the emergence of increasingly connected industrial IS on the other hand, it is realistic to expect a large increase in opportunistic attacks and ransomware side effects on industrial information systems.

Faced with an increasing threat, companies must implement cybersecurity measures on industrial systems and define coherent strategic goals, but this requires a real investment. Therefore, we have worked on listing ICS cybersecurity domains and the solutions to secure them. This radar is not exhaustive, but it aims to clarify the topic by giving a high-level vision.

Methodology

For five months, this radar was built with five experts in cybersecurity of Industrial IS, in addition to the hundred consultants of Wavestone’s industrial cybersecurity offer.

This radar has two parts (we will call them dials): one is presenting cybersecurity products specialized in industrial IS and the other is presenting the different domains of industrial IS cybersecurity, sorted by maturity level.

Industrial cybersecurity products are identified as such according to the following criteria:

•         They meet a need in the process of securing industrial information systems
•         They are adapted to an industrial environment in terms of hardware and software:

·       The hardware is rugged to withstand harsh conditions and/or has a long service life

·       Network security products consider industrial protocols

·       Terminal security products are compatible with obsolete systems.

The cybersecurity domains are also selected and evaluated based on the observations of our consultants in the field, with various customers in varied industrial domains, but in the French context.

The rest of this article highlights some of the important ICS domains, from the most mature to the most emerging. This analysis echoes and updates our 2019 publication presenting feedbacks on ICS protection and security. Indeed, if the main topics remains the same (e.g. IT/OT separation), the players and their maturity evolve quickly, bringing new issues and transforming the old ones.

Which basis should be used to secure an industrial network?

People, procedures, and resilience

The strengths and weaknesses of industrial IS and management IS are different. To implement effective cybersecurity measures in an industrial IS, one must first understand the levers already present in Industrial IS that can be useful for cyber security.

First, the operators in industrial production networks are very familiar with the processes and the usual functioning of the production system. In addition, procedures in the event of an incident are much more developed than in corporate IS. Together, these elements give a capacity to detect malfunction and to respond efficiently. A clever way to improve this resilience capacity is to add cyber incident detection procedures based on the teams’ current knowledge.

Network knowledge

Knowing your network makes it easier to secure the IS and maintain it in secure conditions by allowing risk analysis, network segmentation, vulnerability and patch management, regulatory compliance, etc.

It is possible to carry out this exhaustive inventory by hand on a regular basis, especially by using industrial maintenance tools. To go further, it is possible to automate the task with free mapping tools (Dragos CyberLens, GrassMarlin). Finally, probes (Nozomi, Claroty, Dragos, etc.) can go much further by automating the detection of anomalies on the network or even by helping with incident response.

Backup and recovery

The best resilience weapon against ransomware is the systematic and, if possible, offline backup of critical data for the production system. This practice is more and more implemented in OT systems.

However, additional conditions are necessary for backups to be truly useful. First, all the data needed for the system to function must be identified. This data can be either technical data (machine configuration for example) or business data. A risk analysis allows you to identify it efficiently. Finally, you must ensure that you are able to restore a functional system from the backups made, especially for certified systems.

What are the opportunities in 2021?

Our study has enabled us to highlight effective measures to greatly increase the security level of an industrial IS.

Segmenting your network

Network segmentation has been around for several years. However, it is still an important step in securing your industrial network. Having a segmented network allows to efficiently prevent the propagation of an attack and therefore its impact.

In addition to the use of appropriate firewalls, a network segmentation project requires competent architecture and integration teams with sufficient time and resources. Network segmentation is a balance between security and business needs. The use of new “Software Defined” network technologies allows to perform segmentation in a more agile way.

Separate the management network from the industrial network

The connection of industrial IS to corporate IS is necessary today, but it is also a vector of risk.

The solutions to be implemented depend on the criticality of the industrial network and the necessary flows between the two networks. However, a single interface between the two networks must always be favored to maintain control over this particularly critical interface.

A complete range of products exists, from firewalls to data diodes. A good practice is to assemble several of these solutions within a DMZ, to control the services that can communicate between the two networks.

Nevertheless, IT/OT separation goes far beyond the network issue discussed above. In terms of identity, the separation of the Active Directory (AD) between the management network and the industrial network must also be addressed. From a security perspective, it is best, if the resources are available, to separate these two ADs to avoid the spread of attacks. However, the ADs can also be linked by closely controlling authorized flows and/or providing remediation if one of the two ADs is compromised.

Identify network users

A particularity of identity management in ICS is the strong presence of shared workstations. In this situation, an adapted solution must allow several users to work on the same machine in an authenticated way, thus allowing to identify the actions of each one.

In this case, the model where each user has his own Windows session is not adapted. A possible solution is to set up a generic Windows session on which the user authenticates himself in a simple and fast way thanks to a badge and a Fast Switching software.

What are the next major cybersecurity projects for industrial IS?

SOC

Several Managed Security Services Providers (MSSP) are starting to propose ICS specialized Security Operation Centers (SOC). However, these SOCs should not be considered as miracle solutions: it is above all by knowing your business and all its particularities that the SOC can be effective.

A key aspect when setting up an industrial SOC is to clearly define a scope that is correlated with the cyber maturity of the IS. In an industrial cyber SOC, only cyber incidents should be dealt with, without considering purely operational events, which are already handled by the supervision system.

Third party security

Supply chain management, both in IT and OT, is becoming one of the most important cyber topics. REvil’s attack on Kayesa and its customers in July 2021 gives an idea of the possibilities of a supply chain attack: the attacks reach a new scale and can affect hundreds or even thousands of organizations at once. Obviously, industrial IS also involves third parties and are therefore not immune. For example, the compromise of a PLC vendor could impact numerous customers.

Third party attacks can take different forms, including the following examples:

•          Access to the IS by using a software update with a trojan inside
•          Theft of data stored by a third party
•          Access to the IS via a remote access, for example used by the third party to perform maintenance

Protecting oneself from supply chain attacks is particularly complex. However, tools exist. First, it is essential to know your supply chain and the risk related to each third party. Third parties at risk can then be subject to measures to reduce the chances of compromise such as a Security Assurance Plan (SAP) or regular audits.

Remote access to the IS can be controlled by using Bastions or privileged access management (PAM) solutions, which monitor all actions made by the third party and finely manage their rights. However, this solution can become a constraint for the user, therefore it is advised to focus on the user’s needs to propose the most relevant solutio.

Cloud

Still mainly confined to secondary functions such as inventory and supply management, the cloud is gradually making its way into industrial IS with the development of Industry 4.0. By doing so, it allows, for example, global IoT terminals management in production sites or optimizing server sizing.

But this change also raises security issues. Some of these issues have already been addressed with the democratization of the cloud in management information systems, but others have yet to be resolved. How to manage the security of IoT devices? How can cloud systems be integrated into critical environments, which are highly regulated? Who stores the data and what regulations apply?

Cet article What are the trends and challenges in industrial cybersecurity in 2021? est apparu en premier sur RiskInsight.

Over 40 assessments of industrial sites

If you want to know more, you can find the detailed study.

Cet article Industrial sites cybersecurity : benchmark on 40 assessments est apparu en premier sur RiskInsight.

Reminder of the state of the threat

ANSSI states in ÉTAT DE LA MENACE RANÇONGICIEL – À L’ENCONTRE DES ENTREPRISES ET INSTITUTIONS[1] published on 05/02/2020: «  Since 2018, ANSSI and its partners have observed that more and more cybercriminal groups with significant financial resources and technical skills favour the targeting of particular companies and institutions in their ransomware attacks. ».

Faced with this observation, it is more necessary than ever to secure information systems. This involves applying the fundamentals of security: applying patches, managing accounts and passwords, managing network segmentation etc. As a reminder, the application of these initial measures permits a significant reduction in the probability that an information system will be subject to a ransomware but can in no way guarantee that this will not happen.

Specificity of the industrial sector

However, even though new defensive solutions are continually being developed, the cost and complexity of deploying some of them ultimately make them little used. This is truer in an industrial environment, where their integration can be complex, as some systems are fixed in a functional configuration. Moreover, the budgets allocated to IT security in an industrial environment, although increasing in recent years, are still not sufficient for many sites.

Furthermore, an industrial information system shares a common base with a conventional information system and is therefore subject to the same attacks. Of course, attacks such as Stuxnet, Triton, or BlackEnergy (on a smaller scale) require additional skills. However, it is always worth remembering that the targets of interest for groups possessing this type of means are generally already subject to regulatory obligations (LPM in France, NIS directive etc.), which if respected, greatly limit the risks of a successful attack against them. However, these systems are not invulnerable, and must therefore also be prepared to respond to an attack.

Inevitable attack on industrial systems: how to minimise the impact and restart operations quickly?

It therefore appears that:

• Protecting oneself from the threat is often limited to the application of basic security measures if there is no regulatory obligation applicable to the target information system;
• Identifying the sources of threat and detecting an attack before it reaches its objective requires in most cases resources that are too important in relation to the budgets of current industrial information systems.

If the probability of an information system undergoing a successful cyber-attack, and more specifically a ransomware, is almost certain, the following question arises: “How can we prepare for a major cyber-attack, maintain critical activities in a degraded mode, while rapidly regaining confidence in the industrial information system? ».

The answer to this question is covered by the last two pillars of computer security according to the NIST framework: respond and recover. An attempt to answer this question is presented in this article.

Note: the first part of this article “How to respond to an attack before it is too late?” is not necessary to implement the recommendations detailed in the second part “How to recover after an attack if it could not be contained? ». Although the implementation of network filtering measures is highly recommended, it may be interesting for sites where the implementation of such filtering measures takes too long to implement, to start with the preparation part of the remediation of a cyber-attack, which is easier to implement.

How to respond to an attack before it is too late?

Involving industrial teams

Before talking about the measures that can be put in place to respond to a digital security incident, it may be interesting to remember that industrial staff are used to crisis management.

Indeed, many industries regularly organise crisis management exercises (fire, chemical risk, natural disasters, etc.). On many sensitive sites, procedures are therefore already available to respond to this type of incident, under the direction of a dedicated manager. In addition, autonomous physical protection is generally available: pressure relief valve, non-return valve, sprinkler etc., although these are sometimes replaced by connected instrumented safety systems.

The context is therefore appropriate for adding a new procedure in order to respond to a computer attack. This will generally consist of isolating the industrial information system from the outside via a procedure known as the “red button”. In order to draw up the associated procedure, the involvement of site personnel will be essential, particularly to ensure that the application is not more harmful than the attack itself.

A prerequisite for the implementation of the isolation posture: the control of its flows and the implementation of network partitioning/filtering.

It is necessary to measure the impacts generated using the “red button”. To do this, it is necessary to list the interconnections of the industrial site with other systems.

List the interconnections with other information systems.

It may be interesting to start by listing the flows between the industrial information system and the outside. First of all, it is necessary to define what this system contains. In a basic case, it includes the PLCs, the supervision, as well as the equipment necessary for the interconnection of the first two.

Other equipment can then be added: an Historian server, client stations for supervision, a NAS, etc. This network, later called an industrial network, is generally connected with other networks in order to share information with the equipment of the latter.

It is possible to mention:

• Exchanges with the company’s ERP (whether an MES – Manufacturing Execution System is present or not), generally located on the office network;
• Exchanges with partners: regulation of electricity, water and gas networks, etc.;
• Exchanges with service providers: weather, cloud solutions for energy optimisation, predictive maintenance, etc.

These flows, although useful to simplify operations, can generally be temporarily cut off or replaced by alternative means (telephone call to indicate production levels for example).

Moreover, each industrial site is different, and therefore manages these interconnections differently. It is common to see MPLS networks dedicated to industrial sites when the company owns several of them. In other cases, the office network will be used to federate them. It is also true for the connection needs between these industrial networks and the Internet, which sometimes pass first through the office network, or benefit from a direct output.

List its internal flows

After listing the interconnections between the industrial network and the outside, the internal flows remain to be listed. Most of these flows should be strictly necessary for the proper functioning of the industrial process, such as those between supervision and PLCs. Cutting off these connections would therefore require stopping the industrial process, or at least making it safe.

It may then be interesting to separate the equipment and associated flows into several zones:

• Supervision;
• Field network;
• Others (supervision client stations, historian server, etc.).

Setting up these zones allows the exposure of these components to be drastically reduced. Indeed, only the supervision should have access to the field networks, while the “Others” category should only have access to the supervision.

Other zones may be necessary to implement such as:

• An administration zone: which could also be used to program the PLCs according to the distribution of roles and responsibilities on site;
• A DMZ: which can accommodate a relay server so that equipment outside the industrial site does not connect directly to the supervision system to retrieve production data, etc.

Depending on the services offered (WSUS server, antivirus server, Terminal Server for remote access etc.) other zones can of course be added.

Evaluate the real need for these flows

After listing all these flows, it is interesting to identify the real need for each of them. For example, is it necessary to be able to access e-mails from a supervision server?

In order to limit the exposure of the industrial network to the outside, it could also be necessary to take some equipment out of it. For example, if a database accessed from the office network is fed by the supervision, but not useful to it, hosting it directly on the office network may prove simpler than trying to limit access.

Once the necessary flows have been clearly identified, the associated filtering rules must be configured in detail (source IP address, destination IP address, destination port). This work generally requires a significant human investment, mainly from the teams in charge of the industrial site, as well as a significant material cost to acquire security equipment. However, it is a prerequisite for setting up the fallback postures described below. In an ideal case, application filtering (level 7 of the OSI model) could also be implemented.

This work, although essential to the implementation of isolation postures, is also one of the fundamental actions to be carried out within the framework of securing an information system (industrial or not). Indeed, each flow cut off is a flow that does not need to be monitored, as well as one that is less exploitable by an attacker.

Preparing fallback postures

Complete isolation of all the equipment in an industrial information system is not always desirable, even in the event of an attack. After having listed these flows, it may be interesting not to set up a single isolation posture, but several fallback postures, allowing in some cases to continue working almost normally.

Preventive fallback posture: isolate the plant in the event of an attack on an external network

After identifying the flows between the industrial network and the outside, it is possible to create an associated fallback posture in order to deactivate them if necessary. The objective of this posture is to cut all interconnections of the industrial network with the outside in order to prevent any propagation of an attack. A proven solution is to group these flows on a few dedicated Ethernet ports. Thus, it is sufficient to indicate in the associated procedures to disconnect the associated cables to activate the fallback posture. This also avoids having to intervene on the configuration of firewalls in the event of a cyber security incident.

In addition, it is also necessary to define the cases in which this posture should be activated. If it can be activated without posing any problem to production, or adding too much work to the site staff, the question may arise as to whether these flows are necessary.

If this posture does have an impact on the site’s industrial activities, a good balance must be found between triggering it too early (as soon as the antivirus software on an office workstation raises an alert), or too late (after the first industrial workstations have been encrypted). This will also depend on the context of the company and its resources (dedicated or non-dedicated security monitoring team, etc.).

Specificity (distributed sites, non-autonomous sites, etc.)

If all flows with the outside do not have the same destination, it may also be interesting to define several specific fallback positions. Indeed, if the service provider in charge of managing the site’s cameras warns that he is undergoing a ransomware attack, it seems more optimal to disconnect only the flows between this service provider and the factory network, rather than all the flows, including those to the ERP.

In the case where the industrial process is distributed over several sites (production and distribution plant in particular), the activation of the preventive fallback posture should not cut off the flows between these different sites. Indeed, specific links should be dedicated to this. If this is not the case, use of the office network to ensure these connections, for example, a project to overhaul the industrial network is probably to be expected (deployment of a dedicated VRF, or a SDWAN network for example).

Finally, it is always good to remember that each factory is different, so a local study will have to be carried out on each one to understand its specificities.

Last resort fallback position: switch off the information system in the event of a proven attack on the plant

Finally, it may be interesting to prepare a last resort fallback posture. This should consist of isolating each VLAN (if defined, preferably with a local HMI per VLAN to ensure a degraded mode) or each piece of equipment (turn off the switches) in order to prevent the attacker from continuing his actions, which in the most advanced cases of attack, could directly target the site’s industrial process.

The objective is then to secure the site or ensure its essential services. The activation of this posture implies working without an information system and should only be applied in the event of proven compromise of at least one piece of equipment on the site, since it leads to the same immediate result as a ransomware, if not worse.

An upstream work with the operators will be necessary in order to list all the actions to be carried out when this posture is activated and to define degraded modes. Indeed, this will generally require the activation of on-call duty in order to manually perform certain tasks: checking the correct operation of equipment, especially on remote sites, use of local HMIs, etc. Moreover, some industrial processes are no longer manually controllable today, and will therefore have to be stopped since no degraded mode is available.

In order to estimate the impacts of activating such a posture, it may be interesting to look at the impacts listed in the event of fire or a general power failure. Moreover, only a real test of this posture can ensure its operational impacts.

How to recover after an attack if it has not been contained?

In some cases, the activation of fallback postures may not be sufficient to protect the entire industrial information system, especially if they are activated too late. It is then essential to be able to proceed with the reconstruction of all or part of the said system in a sufficiently short time to limit the associated impacts.

The main prerequisites for restoring an industrial information system are listed below.

What must be backed up to be able to restore its PLCs?

In order to be able to restart the factory, it is necessary in most cases to start restoring PLCs, which requires two main elements.

Having an up-to-date copy of your PLC programs

PLCs are spared in most current attacks, probably because targeting Windows workstations is enough for attackers to achieve their intended objectives. However, attacks are likely to be increasingly targeted, and most PLCs currently in use are not secure (unencrypted and unauthenticated communications, default passwords, administration functionality that cannot be deactivated, etc.).

It is therefore necessary to save these programs, which is already generally the case, particularly on the programming station (sometimes belonging to a service provider) used when the device is commissioned. It should be noted that these backups should be stored on at least one off-line medium, so that they are not encrypted in the same way as the workstation hosting them.

These observations remain valid even for the new generations of PLCs, which, although benefiting from a level of security that is far superior to that of their predecessors, are not invulnerable.

Save a means of downloading these programs to the PLCs

Many PLCs require dedicated software to be programmed. This is even the case if you just want to download an already written program. It is therefore advisable to have a copy of these programs.

In some cases, a programming station disconnected from the network and reserved for this purpose can be a solution. It should be noted, however, that maintaining such a station in a safe condition can quickly become complex. If this solution is selected, this station could also host the copy of the PLC programs. Keeping a second backup set off-line (external hard disk for example) would however be an additional security measure.

Furthermore, if new generations of PLCs are used, with the latest security features enabled, other elements should be backed up such as: PLC program passwords, certificates used for certain communications (or a means of regenerating them) etc.

These prerequisites are also valid for network equipment (firewalls, switches etc.).

What needs to be backed up to be able to restore essential computer hardware?

Identifying what is really needed

Restoring SCADA system, and associated client workstations, is generally equivalent to restoring a Windows system and associated programs. Several questions must be asked to identify the items to be backed up:

• What equipment is needed? An engineering workstation, a SCADA server, a few operator workstations?
• Is it possible to reinstall the SCADA system from scratch (new installations of Windows and the supervision software) and then deposit a backup of the SCADA configuration? Is this feasible in a sufficiently short time?
• Would not a complete copy of the SCADA server disk be simpler? It would indeed be sufficient to insert the saved disk to reboot.
• Are changes regularly made to the supervision software? If yes, is it necessary to back them all up? In this case, it seems complex to make a complete copy of the disk each time.

Backing up intelligently

In many cases, backups of Windows workstations are made in the same way as those of PLC programs, by copy/paste. It could then be interesting to look at automatic backup mechanisms. However, these are probably to be avoided for factories starting from scratch and not having enough budget to install them serenely. Indeed, implementing this type of solution in a secure manner is generally more complex than making a simple bit-by-bit copy of a hard disk.

Do not neglect documentation and training

However, it is not enough to have complete backups available. It is also necessary to draw up detailed operating procedures for restoring these backups. Indeed, if a crisis were to occur, the stress of the teams and the potential unavailability of some of the knowledge could lead to handling errors in the absence of documentation.

These procedures are not intended to enable a complete restoration of all systems, but at least to enable the essential elements previously identified to be restarted:

• An engineering workstation with the associated PLC programming software;
• A SCADA server;
• Two to three operator workstations;
• The plant’s essential PLCs.

In addition, it is generally recommended to have at least two sets of backups, one to be stored near the equipment concerned, the other to be stored on another physical site, with access limited to a limited number of people. It may be tempting to store an additional set of backups online, but it should be noted that in the event of a cyber-attack, and activation of fallback procedures, it is complex to download these backups and deposit them on the systems to be restored.

Finally, it is essential to test all these procedures to ensure that they are exhaustive. A test could, for example, be the opportunity to realise that the backup of the SCADA configuration does not include the licence key, or that the passwords configured when the complete disk was copied have since been modified without keeping the history.

Conclusion

Crisis management is an important component of the business for many industrial system operators. These same people are also the most experienced in their perimeter. However, they are generally not IT experts. Pragmatic measures, adapted to their context, will therefore be far more useful than a generic 200-page guide containing all the good practices to be applied to an information system.

As in development with the KISS principle (Keep it simple, stupid), fallback postures, as well as restoration procedures, should be kept simple to understand, and stupid to apply.

Furthermore, although the application of a strict network filtering policy can only be advised, it is not strictly necessary for the implementation of backup and recovery actions. Thus, even if the probability of a successful attack is increased, it will still be possible to restore critical systems.

Finally, it should be noted that more and more industrial processes are nowadays operating in a just-in-time mode. In this type of context, the preservation of the industrial system from an attack, or the ability to restore it quickly, would not be sufficient to maintain the level of production if the management of orders or distribution, for example, are unavailable. Cyber resilience must therefore be considered at the company level, and not only at the level of the industrial site.

Key elements

To respond to an attack before it is late, it is necessary:

• To involve the industrial teams (without which it is highly likely that the computer will survive the attack, but without the factory continuing to fulfil its primary mission);
• To control its flows and implement network partitioning/filtering in order to be able to set up fallback postures:
  • Preventive, in order to isolate the factory in the event of an attack on an external network without having too significant an impact on the industrial process;
  • As a last resort, in order to shut down the information system in the event of a proven attack on the factory before the attacker modifies the industrial process.
• To test these fallback postures, in order to ensure that their activation is not worse than the attack.

And in the case where the attack could not be contained, the following elements are generally necessary in order to recover from the said attack:

• Possess an up-to-date copy of your PLC programs;
• Save a means of downloading these programs to the PLCs;
• Have at least one copy of all critical backups on an off-line medium (external hard disk for example);
• Identify its essential computer equipment (in particular so as not to restore the history server before the supervision server, etc.);
• Backing up intelligently, sometimes a bit-by-bit copy of the hard disk is more efficient than an automatic copy on a dedicated server, generally encrypted at the same time as the system whose backups it hosts;
• Don’t neglect documentation and training (otherwise a forgotten license key, or someone on holiday could quickly sign the end of the restore…).

[1] www.cert.ssi.gouv.fr/uploads/CERTFR-2020-CTI-001.pdf

A new version of the threat assessment was published at the beginning of the year: https://www.cert.ssi.gouv.fr/uploads/CERTFR-2021-CTI-001.pdf

Cet article Cyber resilience in an industrial environment est apparu en premier sur RiskInsight.

Our product vision: a solution with multiple functionalities

Description

An OT probe is a piece of equipment, virtual or physical, connected to the information system (IS) in order to map and monitor it. It consists of sensors distributed in the network to collect data and central equipment to correlate this data.

A probe is characterised by:

• Its operating mode,
• The positioning of its components,
• Its attack detection methods,
• Its bundle of features.

The illustration below provides more details on each of these items:

Figure 1: Main characteristics of an OT probe

Main functionalities

The functionalities of these OT probes are essential for their users. The illustration below presents a summary of the main functionalities identified:

Figure 2: Main functionalities of an OT probe

More advanced functionalities also appear on some products, such as centralised management of several sites, provision of investigation guides, vulnerability research, etc. According to our observations, the solutions on the market tend towards the same objectives in structural and functional terms. The differences appear rather at the level of the global integration of the probe with the offers of the suppliers.

Our vision of the market: a market in the process of consolidation

Numerous and varied players

Our studies have enabled us to highlight a little over twenty players with diverse profiles on the OT probe market. Over the last five years, some players have appeared, others have disappeared, partnerships have been built and solutions have continued to evolve. All these elements indicate a market that is still in the process of consolidation.

Figure 3: Our market knowledge

Actors with different approaches

As might be expected in such a diverse market, different approaches to the sales model emerge. Some players put more emphasis on their product as such, while others emphasise its integration in their catalogues of services (threat intelligence, SOC, CSIRT…) or complementary products. These approaches naturally influence the contact between the players and their customers: the more the offer emphasises a service, the more the player will seek to have direct contact with his customer.

Our vision of the field: a need for maturity

Our feedback

At least initially, we recommend focusing on critical sites and processes for reasons of time, cost and skill savings. Moreover, in order to offer relevant behavioural detection, the probes require a significant learning time depending on the site on which they are deployed (identification of false positives, false negatives, accumulation of data for learning…). In addition to this time, significant human resources are required during this learning phase, but also later during the daily use of the product (mainly alert management). It will also be important to link the probe management teams and the incident response teams in order to deal with incidents detected by the probe and then confirmed.

Prior to deployment, the positioning of the probes should be studied. Indeed, it will be the key to both a complete mapping and an optimal detection surface. These initial considerations must address important points such as hardware compatibility (switches, for example) with the probes and the architecture of the site (on which the number of probes may depend). In addition to providing a real-time inventory, mapping can help implement or review network segmentation, an essential step in a security project. The qualification phase should also make it possible to check that the chosen probe will understand all the industrial protocols used and to discuss the processing of encrypted flows, if any.

Finally, of course, this type of project cannot be carried out without the integration, from the outset, of the OT teams.

A number of our clients stop at the test phase, but others have started to deploy probes on their critical sites or even on their entire industrial information system. The reasons given for not deploying probes are mainly related to costs, charges and required skills. The sovereignty of a detection probe can also be an important issue in certain environments.

Identified limits

In addition to the above points, technical limitations may also arise. Issues of bandwidth and network overload, induced by the collection of logs, can be anticipated. Moreover, an OT probe is by nature limited to network exchanges, its results (detected threats, security level evaluation…) are therefore to be put into perspective in relation to the resources at its disposal.

Finally, the probes ensure detection. On the other hand, the reaction must be carried out by other means, human or technological. More generally, with their many interesting functionalities, the probes are complementary to good security practices such as: the installation of antivirus and firewall, the implementation of a well of logs and adequate collection configurations, the construction of network documentation, the establishment of dedicated SOC and CSIRT teams… All these practices remain in force and will allow the full exploitation of the probes’ capacities.

Figure 4: Our main feedback on the deployment of an OT probe

Conclusion

The probes offer a range of functionalities that meet real needs. Our meetings indicate that the market players continue to take into consideration the needs that have been brought to their attention in order to improve their product. Despite a consolidating market, the players seem to be technically converging towards extremely similar end products. Differences will be played out on ergonomic details, on the approaches adopted by each and on costs.

Our initial feedback shows the importance of the load and the skills required to use a probe. While they may be useful in an immature context, in order to help with system knowledge and the implementation of good network hygiene, they only really reveal their potential once they are fully integrated into the arsenal of detection and incident response teams, which corresponds to a highly mature context. Thus, it would seem to be a higher priority to follow the good practices outlined above in order to gain in maturity and then to consider deploying a probe in a second phase.

1: See https://en.wikipedia.org/wiki/Purdue_Enterprise_Reference_Architecture

2: See https://en.wikipedia.org/wiki/Port_mirroring

3: See https://en.wikipedia.org/wiki/Network_tap

Cet article Detection probes in industrial environments, our vision of the market est apparu en premier sur RiskInsight.

Let us make a detour through a page of history, before plunging into the heart of our subject :

• In the 18th century, James Watt’s steam engine and coal mining changed the way of working. The use of hydraulic machines made the artisan workshops evolve into much more efficient factories: the 1st industrial revolution was in full swing.
• Then, the 2nd industrial revolution known for Taylorism and mass production is based on the use of electricity and oil. The long assembly lines, dear to Charlie Chaplin, replace the hydraulic and steam engines that are now obsolete.
• The development of new information technologies, from 1970 onwards, supporting operators in the most difficult tasks characterizes the 3rd industrial revolution. In particular, it allowed for increased robotization and production of larger batches.

This 4th industrial revolution marks the arrival of new technologies that are increasingly connected, leading to a high level of dependence on information technology.

Industry 4.0 brings together a set of technological advances and technical tools for optimising industrial processes.

Let’s take a concrete example of a use case:

A company needs to accelerate its production rate and to robotise part of its actions to save time. For example, screwing actions. It chooses to use a collaborative robot, also called a « cobot »^[1], capable of carrying out actions simultaneously or on the same workspace as an operator. The operator will be responsible for presenting the parts to be screwed to the cobot.

In addition to reducing turnaround time, the implementation of this binomial makes it possible to increase the quality of the finished product.

Industry 4.0 use cases increase the cyber risk to business processes. There are two reasons for this: the need for new interconnections of industrial systems with the outside world and the increased potential impact in the event of compromise..

What are the impacts for cybersecurity in this whole story? If we continue with this cobot, the screwing, initially done manually by an operator, is now made easier by the use of the cobot. The cobot has to be connected to receive orders and be updated.

• The manual operation is replaced by a computerised operation that is now exposed to a cyber attack

On a conventional robot, a “safety cage” is present to prevent intrusion by an operator during the operation of the machine tool. On a cobot, as there is collaboration with the operator, this protection does not exist. An impact in case of contact between the cobot’s screwdriver and the operator’s hand would be particularly serious for the operator !

• The introduction of new technologies can increase the severity of a cyber attack

This is not the only consequence of unsafe use of such technology :

• Changing a value in the cobot regarding the screwing torque can lead to a quality defect in case of incorrect tightening ;
• Greater importance of assisted operations means that in the event of a failure, the impact on production will be greater… which will quickly lead to a financial impact.

Let’s sum up a little simplistically :

The question now is how to deal with these risks, without blocking the legitimate demands of operational staff. Spoiler: no, refusing the project is not the solution!

The teams responsible for cybersecurity can anticipate the needs for the implementation of 4.0 technologies by drawing up adapted reflex sheets

From a technical point of view, we can group the advances linked to Industry 4.0 around a few major themes: augmented reality, connected objects, additive manufacturing, etc. Upstream of projects and with a few well-informed industry players around the table, it is possible to anticipate potential demands.

The objective for the cyber security team will then be to draw up a profile of typical use cases, deduce the potential risks and begin to identify appropriate security measures to respond to them. It is also an opportunity to propose “Industry 4.0” checklists to raise awareness upstream of projects.

Concretely, here is an example of a typical reflex card applied to our cobot seen previously :

By preparing upstream, cybersecurity teams are more relevant and effective when a new project is about to start.

Ready to embark on a “4.0” project? This is the ideal opportunity to support the industry in the transformation of its factory by offering adapted cyber security services.

The advantage of “Industry 4.0” projects lies in their ability to make in-depth changes to the foundations, sometimes a little dusty, of systems and networks already installed in the factory.

Does a conveyor project need to exchange information with the outside world? This is an opportunity to propose a secure file exchange server in your industrial DMZ (if you don’t have one, this is also a good time to think about it). Does an augmented reality system need a more stable wireless connection? This is the time to start thinking about strengthening the control of the devices that can be connected to it…

At the risk of repeating the obvious here, the ideal is to arrive upstream of the projects, through a constructive approach, rather than through a 100-page ISSP and guides to standards and technical rules that are not adapted to the cases of use presented.

For the risk analysis of an “Industry 4.0” project, the EBIOS RM risk analysis method facilitates exchanges by sharing strategic scenarios that can be understood by the business

Once discussions have begun on a concrete project, it is useful to carry out a risk analysis to support the discussions. Its depth and method will depend on the size and risks of the project.

This analysis will make it possible to refine the objectives we wish to protect, take a step back from the existing ecosystem and define the most convincing attack scenarios.

Here are some examples of frequently found scenarios :

• Logical sabotage for financial purposes (long version of the Ransomware scenario): A targeted or non-targeted attack, making equipment unavailable for financial gain.
• Stopping/Slowing down production: Targeted sabotage to gain a competitive advantage, revenge by ideology or just by defiance can be carried out by a malicious competitor, an avenger, a terrorist, an activist or even a thrill-seeking amateur. Also be careful not to forget the errors of manipulation !
• The alteration of the quality of the part produced: rather sophisticated and targeted sabotage impacting the quality of the products to discredit the company or simply create damage.

The conclusion of the risk analysis will make it possible to precisely define the cybersecurity measures to be put in place and the associated residual risks.

To move away from the “fortified castle” model, i.e. to focus on the isolation of its industrial IS and perimeter security, and to propose adapted security measures: finer detection, encryption, MCS … in a way, it’s time to move on to “4.0” measures

Our feedback shows that the definition of an action plan is a balancing act in these “4.0” projects. Indeed, by applying an overly restrictive safety model, based on IEC 62443-3-3 type zones and ducts, we run the risk of misunderstanding between the stakeholders. In fact, not all business solutions are compatible or mature, and many have not yet integrated the standards we would like to see applied.

So what to do? One way might be to propose appropriate security measures, “4.0” measures (for the industrial environment in any case) that have already proved their worth in other environments:

• To prevent a threat from spreading, one shall strengthen detection resources, especially the flows from and to industrial IS. This is the time to take advantage of this opportunity to dock with the Group SOC if it has not already done so.

• To ensure the integrity and traceability of transmitted/received data, encryption and authentication can be implemented. Do you already have a Group PKI? Why not think about extending it to industrial perimeters.

• It is also the right time to strengthen its OCM / SCM process. Is the solution connected with the outside? No more excuses for not installing an antivirus, updating it, installing security patches for your favourite OS, etc. This point should be anticipated prior to purchasing the solution, rather than once the product has already been installed!

• Finally the solution is critical for the business? A cyber-resilience component must be anticipated so that the solution can be quickly rebuilt and restarted in the event of an attack.

As we have just seen, there is no shortage of solutions, but they require adapted support from the cybersecurity teams and going beyond theoretical models. So, let’s take advantage of these “4.0” projects to make our industrial cyber security models evolve without a priori!

[1] https://commons.wikimedia.org/wiki/File:Cobot.jpg license CC : https://creativecommons.org/licenses/by-sa/4.0/deed.en

Cet article Industrial Cybersecurity in the Age of Industry 4.0 : how can we secure these new use cases and support business projects? est apparu en premier sur RiskInsight.

Managing risks in the long term

Equipment hardening

In addition to secure architecture and administration tools, security levels for each item of equipment should be increased according to the strict necessity principle. A generic hardening guide can be created and then adapted to each of the technologies identified by the industrial IS mapping. This allows some of the vulnerabilities to be remedied at configuration and system levels.

Additional security can be provided by adding complementary solutions, such as:

• Antivirus software, which will cover industrial workstations against the most common viruses, whether connected to the network or not (although the latter will require manual updates);
• Implementing strict rules on local machine firewalls, which can be used to prevent communications, and therefore intrusions, on unused ports, and to filter the origin of flows according to the protocols used – which means attempted attacks can be more easily detected;
• Local administrator account-management solutions (for example, LAPS for Windows) finally make it possible to manage native administrator accounts on workstations in a central and individualized way.

However, sometimes it may no longer be possible to harden equipment due to obsolescence. In such cases, there is a need to work with the relevant business functions on obsolescence management of the equipment – its potential replacement and, as a last resort, options to isolate it from the rest of the IS. On obsolete workstations, configuration blockers can be used to ensure the installation and use of components is limited only to those that are strictly necessary.

It’s important to remember that, while industrial ISs have vulnerabilities, they are, above all, part of the company’s means of production. Dialog with the relevant teams is therefore essential in understanding how equipment is used – in order to resolve the vulnerabilities while limiting effects on the business as far as possible.

Security maintenance

Once equipment has been brought up to the right level of security, a plan will be needed to maintain this over time. A choice of options for managing security patches can be developed to meet the needs of the business (in terms of availability, integrity, etc.) and synchronized with the maintenance of the industrial equipment through:

1. Integration into standard operating processes; for example, an installation’s qualification/quality processes may require that equipment be up to date. The updating and administering of equipment can therefore take advantage of plant shutdowns, especially where recertification is needed.

2. Planning a “hot swap” update process in the event of a critical security breach and a procedure for the preventive isolation of production lines – until it’s possible to interrupt the production process;
3. The identification of redundant or peripheral equipment where interventions can be carried out on the basis of straightforward interaction with production managers.

To put in place these patching processes, the mapping carried out previously must have generated a precise equipment inventory, including:

• The identification of the equipment: type, location, and number of units;
• The industrial processes that each item of equipment is used for, and the associated criticality;
• The version of the operating system and/or firmware, and the tools and configurations deployed;
• The cybersecurity needs of supported processes;
• The availability of redundancy, data buffering, and cold spares;
• The required patching frequency and patching history.

But maintaining security levels isn’t simply about applying patches to equipment, it should also:

• Define the process for updating the security solutions installed on equipment isolated from the network;
• Install removable media cleaning solutions, given that these types of tool remain in widespread use on industrial sites. Here, the use of portable solutions allows such media to be analyzed while moving around the site;
• Ensure the safeguarding of equipment configurations and their integration into the DRP in order to guarantee that equipment can be restarted following an incident while still meeting availability needs;
• Set up monitoring of the industrial IAM[1] to ensure robust physical and logical access control. This can also be used to automate a number of time-consuming activities that are still sometimes done manually.

Detecting cybersecurity incidents

The measures set out above help reduce the likelihood of risks occurring and increase the availability of equipment, which benefits the business. Nevertheless, there will still be a need to prepare for the worst and to have in place the tools needed to detect an incident – to be able to remedy such events as quickly as possible and minimize interruption times.

Putting in place detection

The first step is to activate the IDPS[2] functions on networked equipment to ensure that a first stage of detection, and potentially automatic blocking, is in place.

The next step is to collect information by deploying a concentrator on site. The network equipment and server logs can then be sent to existing or dedicated SIEMs[3] where correlation and detection can take place. SOC[4] and CERT[5] teams can then carry out analysis and detection, and respond, if needed, to an incident, by working through standard scenarios.

Anticipating specific risks

However, detection based on standard scenarios may offer only limited value to the business functions. Considering the entirety of sources (PC, Linux, UNIX, etc.) and setting up dedicated industrial IS probes, capable of interfacing with the SCADA systems, can enhance the detection system. Such solutions, however, can be costly.

The key factor is to ensure a progressive and rapid increase in the maturity and value added by the SOC. Agile methods are a good fit here and involve the iterative application of the cycle described in the text box below.

Planning for remedial activities

Lastly, detecting an incident will only result in effective remediation if the business-function teams are involved. As with equipment updates, emergency stop procedures should be reviewed jointly with industrial IS users. A formal Incident Response Plan enables the actions for an industrial cyber-incident to be planned.

Dedicated industrial IS crisis-management exercises should also be carried out to ensure that teams are optimally prepared and to highlight any shortcomings.

Taking a progressive and participative approach guarantees an initiative’s success

The security maintenance of an industrial IS is a complicated undertaking that can only be successful if it is carried out in partnership with the business functions. A progressive and participative approach should be taken to work with them in each of the following areas:

• Understanding the industrial IS, by mapping and prioritizing the most critical elements;
• Mitigating the risks on the industrial IS, by implementing state-of-the-art secure network architecture and defining the administration processes – due to their criticality, safety ISs must be given particular attention;
• Ensuring an adequate level of safety, by hardening and ongoing security maintenance – in particular, this will involve discussions with equipment suppliers and manufacturers;
• Putting in place the tools needed to detect security incidents – these can have a bearing on production and define the response processes.

The actions above can’t always be carried out in parallel. Defining a clear roadmap will enable such actions to be prioritized. This will aid cost control and maximize the value added for the business functions.

Given that such significant undertakings are often driven centrally, the challenge is to engage the individual industrial sites (which may be spread across the world) to ensure security levels can be maintained in the long term. In general, we observe that companies take a two-stage approach:

1. A multiyear cybersecurity program (typically carried out over three years), with a budget of €10m-15m, aimed at:
   • Creating the industrial IS inventory
   • Raising the security levels of existing assets by putting in place protective measures, often involving separation and filtering, and remedying the most critical vulnerabilities – here, defining procedures is essential;
   • Putting in place an initial network of local cybersecurity coordinators;
2. Create an industrial cybersecurity team and its associated management structures that bring together:
   • A framework of key activities that local players will need to manage;
   • The participative construction of the tools that will help this network of local managers carry out their cybersecurity activities;
   • The development of approaches to manage the increase in security maturity levels and change (such as maturity matrices, site-level budget-modeling tools, the definition of steering indicators, central services that the sites can draw on, etc.).

Implementing the management processes can start immediately after the program and therefore benefit from the initial network of site-level cybersecurity coordinators put in place.

Once constructed, it becomes a question of energizing the initiative and steering progress on the sites and industrial ISs, in terms of both security and maturity levels.

Doing this typically involves:

• A network of local cybersecurity coordinators, of size 0.5 to 2 FTEs[6] per site, who are responsible for carrying out projects, implementing ongoing cybersecurity activities, continuous security improvements, and reporting;
• A central team of 3 to 10 FTEs, to provide overall steering and support local managers – especially in terms of expertise.

[1] IAM i.e. Identity and Access Management.

[2] IDPS i.e. Introduction Detection and Prevention Systems.

[3] SIEM i.e. Security Incident and Event Management.

[4] SOC i.e. Security Operation Center.

[5] CERT i.e. Computer Emergency Response Team.

[6] These figures can vary significantly depending on the size and number of local sites; they are the typical arrangements we observe in the large international organizations that Wavestone supports

Cet article Saga (3/3) – Feedback from the field and good practices for the protection and the security maintenance of industrial ISs est apparu en premier sur RiskInsight.

Administration – the nerve center of network architecture

Good administration of an IS is essential to guaranteeing its availability and security. When carrying out an IS security program, you must be clear about the objectives you want to achieve. The good practices we observe in the field include:

• Creating an administration network isolated from the production network with both central and local scope whose aim is to protect administration flows and avoid integrity losses on flows used to manage sensitive operations;
• Protecting the administrative equipment to prevent an attacker from controlling these critical elements directly;
• Standardizing, as far as possible, practices and equipment to facilitate the deployment of secure, or even centralized, administration architecture, and to maintain security levels over time. This can be achieved by pooling resources within a central, dedicated team.

To note: here, we are discussing only the administration of industrial IS infrastructure. Production PLCs, for example, are administered by the business functions in terms of configuration and will pass through the dedicated configuration and maintenance team, when updates are required.

The first step is to create the structure of the isolated and overarching administration network. This objective can be achieved by putting in place the following measures:

• To optimize and pool resources, and especially to assure the DRP[1], the administration network must be constructed around one or more datacenters.
• In order to reduce the risk of an attack propagating by using an infected site as a springboard, the WAN[2] network placed between the datacenter and the industrial installations can be configured as a hub and spoke[3] network, which ensures the separation of each installation.
• To guarantee the integrity and confidentiality of administrative flows, these must be isolated within a specific VRF[4] or VPN[5] administration network between the datacenter and each site.  Putting in place such a dedicated administration network requires, in particular, the use of telecoms and security equipment, as well as dedicated interfaces on the servers.
• For the most important sites, the risk of intrusion via the user LAN[6] can be reduced by setting up an administration LAN which is only accessible from the datacenter’s administration LAN. However, such architecture must provide a resilient solution in the event that the WAN is cut to allow sites to access it directly and also for equipment that simply cannot be maintained remotely.
• Companies with multiple sites can also use a standardized housing that embeds all the security functions required for the site to be interconnected. This facilitates configuration and security maintenance.

Diagram showing the interconnection of a site with or without a SCADA

The second step consists of connecting the administration tools and equipment to be administered to this network, while protecting it from compromise.

Diagram showing the interconnection of a standalone site

There may also be a variety of reasons to keep part of the IS fully disconnected. A disconnected IS removes the ISS risks, leaving only business risks. Disconnection also lowers the level of exposure and therefore the risk of intrusion. A risk analysis should be carried out to determine how to proceed. The associated infrastructure will need to be modified: moving from simple local administration to dedicated administration – which can be costly. These various network bricks, then, enable administrators to access the industrial equipment. However, they must also be given access to the necessary tools.

Administrator tools: how to meet needs while guaranteeing security

Because corporate and industrial ISs are generally managed separately, they each use their own tools – although these may be based on identical products.  This type of configuration meets several objectives. It:

• Assures access control on the administration interfaces, reducing the likelihood of appropriating a means of attack and the fraudulent use of the tools;
• Tracks administrator activity to reduce the potential impact of an attack, by providing a means of detection and response, and facilitating investigation following an event.

This requires the implementation of an administration chain.

Diagram showing the main functions involved in a chain of administration

To centralize access and maintain close control of authorizations, an administration bastion must be set up. Generic accounts are handled by the bastion and protected in its digital safe. This also ensures the traceability of activity and reduces the risk of theft from generic, privileged accounts. The bastion can also secure administration flows by performing protocol translation (for example, from Telnet[8] to SSH[9]).

Equipment, especially telecom equipment, whose security levels are sufficiently mature (including detailed management of rights, traceability, individual accounts, etc.) can be directly administered without passing through a bastion.

The establishment of a dedicated administration workstation, where the tools needed for corporate management will be housed, requires a process to be put in place for their installation. This will ensure the workstation can remain secure and that the list of tools being deployed on the IS can be documented.

Planning for external maintainers

Lastly, it’s essential that access by third-party maintainers is secure in order to limit the risks that arise from improper or unmanaged access, such as infection of the IS after the installation of an unauthorized tool, data loss triggered by a malicious third party, the unavailability of equipment, etc.

An external access point with strong authentication will be needed to confirm the identity of users. Such an access point allows maintainers to access a rebound server which is controlled and hardened by the customer, while also ensuring the traceability of activity. Here, more sophisticated customers deploy solutions that allow the third-party access to the IS for the duration of the intervention only – and then only once access has been approved internally.

The configuration and maintenance servers that are dedicated to the site and PLCs must be rigorously monitored to keep them up to date and secure, especially in terms of the tools deployed on them.

For more detailed information, note that there is an ANSSI[11]  working group dedicated to the cybersecurity of industrial systems. Its PIMSEC framework[12]  recommends a range of security requirements that can be incorporated into contracts with industrial IS service providers.

We now have knowledge of our equipment and the solutions to secure and manage it. However, cybersecurity issues evolve over time, so it is essential to guarantee a level of security over time and to deploy adequate means of detection. How can this be done? This will be the topic of our next article!

[1] Disaster Recovery Plan.

[2] WAN i.e. Wide Area Network.

[3] Hub and Spoke i.e. A network around the datacenter.

[4] Virtual Routing and Forwarding

[5] VPN i.e. Virtual Private Network.

[6] LAN i.e. Local Area Network.

[7] VLAN i.e. Virtual Local Area Network

[8] Telnet i.e. Terminal Network, Telecommunication Network, or Teletype Network.

[9] SSH i.e. Secure Shell

[10] RDP i.e. Remote Desktop Protocol

[11] ANSSI i.e. The French National Cybersecurity Agency.

[12] PIMSEC i.e. ANSSI’s framework for security requirements for industrial systems integrators and maintenance providers.

Cet article Saga (2/3) – Feedback from the field and good practices for the protection and the security maintenance of industrial ISs est apparu en premier sur RiskInsight.

Opening things up to corporate ISS is now a necessity… but it also carries risks

Historically, industrial ISs were not connected to corporate ISs, either because there was no need or as a way of limiting the risk of exposure. The majority of interventions were local, with work taking place directly on equipment, or remotely, using specific methods. The management of this work and the operations themselves were mostly local too.

Business functions’ changing needs and the optimization of production processes have brought with them new and less localized requirements (such as remote supervision, remote maintenance, the emergence of the IoT1, the standardization and rationalization of technologies and skills, cyber threats, etc.), which are designed to improve performance and facilitate operations. These challenges have led to a need to digitalize and interconnect industrial and corporate ISs.

Although this is now essential for a company’s business functions to operate effectively, our discussions with operational staff highlight the fact that such changes have also led to risks of intrusion and the propagation of threats between these interconnected ISs. These affect:

• Operations and quality – with potential shutdowns and modifications to production lines resulting in financial, reputational, and even people impacts;
• The security of facilities, where production equipment being seriously compromised can have impacts on both people and the environment.

Mitigating these intrusion and propagation risks and their consequences means implementing security measures in several different stages:

• Industrial IS mapping;
• Putting in place secure network architecture;
• The hardening and security maintenance of the various systems over time;
• And, lastly, putting in place the measures to detect incidents and respond to them.

Regulatory authorities have also been considering these risks. For the most sensitive installations, they are now mandating these types of measures and others too.

Interventions (such as patch management, account audits, integrity control, etc.), sometimes done remotely and often frequently, may now need to be carried out by teams more distant from site operations. These quickly come up against a traditional operating model designed to prioritize the continuity and integrity of operations, quality, hygiene and safety – while minimizing disruptions to production.

How can these measures be implemented without losing sight of the industrial IS’s core purpose – to operate a physical process in the way designed?

Mapping, a prerequisite for dealing with cybersecurity risks on industrial ISS

To assess the risks and control the potential impacts of implementing any new measures, the first step is the IS mapping of your industrial installations, which enables you to:

• Know the systems that need to be administered and kept up to date;
• Identify the users (operators, maintainers, etc.), and therefore those who need to be involved when a change takes place, to manage the operational impacts;
• Evaluate the potential impacts of new vulnerabilities and security breaches in terms of safety, operations, and quality.

Once the mapping process is underway, you will also need to develop formal procedures for updating the map. This means defining the update frequency, according to the level of criticality, and then actively managing the risks.

This is a substantial piece of work requiring dialog and close collaboration with automation and other engineers involved with the installation.

Mitigating risks on an industrial IS by putting in place security architecture

Security isn’t a new concept and it makes sense to follow the established principles for corporate IS architecture and security – adapting them to the particularities of industrial ISs:

• Reducing the risks of propagation and intrusion by clearly partitioning the industrial IS and restricting access to it;
• Securing the administration of the IS by putting in place dedicated administration architecture;
• Equipping administrators with appropriate tools that enable them to make interventions across the entirety of the industrial assets;
• Integrating from the start (as far as possible) interventions made by external maintainers.

These four principles form the cornerstones of securing industrial IS architecture.

Partitioning, the first step in reducing exposure

Corporate and industrial ISs have essentially different goals: one is designed to facilitate the operation of a business (by providing messaging, management systems, collaborative tools, etc.), while the other is used to operate physical processes. In theory, these should be separated, and only certain types of information should be allowed to flow between them. However, feedback from the field tells us that this is rarely the case.

As in any work on IS security, the strict necessity principle should be adopted to limit exposure to cyber threats. Any interconnection between an industrial and corporate IS should serve a specific purpose; for example:

• Sending production orders to SCADA[1];
• Transferring CAM[2] files to digitally controlled machines;
• Collecting production data to enable the control of operations.

An industrial IS must also be internally partitioned to reduce the risk of threat propagation. To do this, you can use the principle of zones and conduits described in the IEC 62443 standard.

In practice, this partitioning has to be carried out in several steps:

• The listing of relevant business activities according to their different levels of sensitivity;
• Grouping activities requiring the same security level into zones (with, potentially, a ”legacy” zone and associated sub-zones);
• Putting in place security rules for each zone according to their needs, as described in standard IEC 62443;
• Checking that the interconnections (conduits) between the different zones comply with security rules;
• Migrating the applications. Ensuring applications are compliant can be a long and difficult task, and it’s best to use a risk analysis to prioritize and manage the work, as well as documenting the nonconformities and associated remediation plans. In addition, the migration process itself may be complex, if you are to avoid an impact on operations.

The particularity of safety ISS

Safety ISs are industrial ISs that enable industrial production systems to be put into a safe state. Before the advent of today’s digital systems, such systems had long been used in mechanical, pneumatic, and electrical forms. The particular importance of ensuring their integrity is therefore well understood. A final partitioning step can be considered to achieve this. However, field observations often tell us that existing arrangements act as a brake that complicates the work. When done rigorously, such separation reduces the risks of propagation and enables distinct levels of security to be implemented for the production IS and safety IS according to their risk levels. However, a disadvantage is that doing this requires a dedicated SCADA system, which is both expensive and not operationally friendly.

Diagram of Industrial IS / Safety IS partitioning scheme

After having launched this process of identifying and partitioning industrial IS, it is time to deal with their administration. How to reconcile security, operational gain and availability of the production tool? We will tell you about it very soon.

[1] SCADA i.e. Supervisory Control And Data Acquisition system

[2] CAM i.e. Computer Aided Manufacturing

[3] DMZ i.e. Demilitarized Zone.

Cet article Saga (1/3) – Feedback from the field and good practices for the protection and the security maintenance of industrial ISs est apparu en premier sur RiskInsight.

La couverture des risques dans la durée

Le durcissement des équipements

En complément d’une architecture et d’un outillage d’administration sécurisés, il convient d’élever le niveau de sécurité de chaque équipement en appliquant un principe de strict nécessaire. Un guide de durcissement générique peut être créé et adapté à chaque technologie identifiée lors de la cartographie du SI Industriel. Celui-ci permet de remédier à une partie des vulnérabilités présentes au niveau des configurations et des systèmes.

L’utilisation de solutions complémentaires peut également apporter un surplus de sécurité :

• Les antivirus connectés au réseau ou non (impliquant une mise à jour manuelle) vont couvrir les postes industriels contre les virus les plus communs ;
• La mise en place de règles strictes sur les pare feux locaux des machines va empêcher les communications, et donc intrusions, sur les ports inutilisés, et filtrer l’origine des flux en fonction des protocoles utilisés, permettant de mieux détecter des tentatives d’attaques ;
• Des solutions de gestion des comptes administrateurs locaux (par exemple LAPS pour Windows) peuvent enfin permettre de gérer les comptes administrateur natifs des postes de manière centralisée et individualisée.

Il arrive cependant qu’il ne soit plus possible de durcir un équipement du fait de sa vétusté, il faut alors travailler avec le Métier sur la gestion de l’obsolescence des équipements, sur leur éventuel remplacement et en dernier recours sur les capacités à les isoler du reste du SI. Des bloqueurs de configuration pourront également permettre, sur des postes vétustes, de restreindre l’installation et l’utilisation de composants à ceux uniquement nécessaire.

Il est important de rappeler que le SI Industriel souffre de certaines vulnérabilités, mais est avant tout l’outil de production du Métier. Le dialogue avec ces équipes est donc primordial à la compréhension de l’utilisation qu’ils en font afin de résoudre ces vulnérabilités en limitant les conséquences au maximum pour le métier.

Le maintien en conditions de sécurité

Lorsque les équipements atteignent le bon niveau de sécurité, il faut prévoir son maintien dans le temps. Différents scénarios de gestion des correctifs de sécurité ou « patchs » peuvent être définis pour répondre également aux besoins du Métier (disponibilité, intégrité) et synchronisés avec la maintenance industrielle :

1. Intégration dans les processus nominaux d’exploitation (par exemple : les processus de qualification / qualité d’une installation peuvent imposer que les équipements soient à jour). La mise à jour et l’administration des équipements tireront ainsi profit des arrêts industriels d’autant plus si une re-certification est nécessaire.

2. Préparation d’un processus de mise à jour « à chaud » en cas de faille de sécurité critique et d’un processus d’isolation préventive d’une ligne de production le temps que le procédé puisse être interrompu ;
3. Identification des équipements redondants ou périphériques sur lesquels une intervention avec simple information des responsables de sites est possible.

Afin de mettre en place ces process de patch, la cartographie réalisée précédemment doit faire apparaître un inventaire précis des équipements devant inclure :

• L’identification des équipements, leur type, localisation et nombre ;
• Les procédés industriels pour lesquels ils sont utilisés et la criticité associée ;
• Le système d’exploitation/lefirmware, les outils et la configuration ainsi que la mention des versions déployées ;
• Les besoins en termes de cybersécurité au regard des procédés supports ;
• La disponibilité de redondance, de mise en tampon des données et de cold spare ;
• La fréquence de patch requise et l’historique de patch.

Le maintien du niveau de sécurité ne se base pas uniquement sur l’application de correctifs de sécurité sur les équipements. Il convient également de :

• Définir le processus de mise à jour des solutions de sécurité installées sur les équipements coupés du réseau ;
• Installer des solutions de nettoyage de média amovibles qui restent très présents sur les sites industriels – certains produits ont l’avantage d’être portables et donc d’analyser le média pendant le déplacement à l’intérieur du site industriel ;
• Assurer la sauvegarde des configurations des équipements et leurs intégrations au DRP afin de garantir une remise en route post-incident qui réponde aux besoins de disponibilité ;
• Mettre en place un suivi de l’IAM[1] Industriel afin d’avoir un contrôle d’accès physique et logique robuste. Cette action permettra aussi d’automatiser de nombreuses actions fastidieuses de revue de comptes parfois encore faites à la main.

La détection des incidents de cyber sécurité

Les mesures citées précédemment permettent de réduire la probabilité d’occurrence des risques et donc d’augmenter la disponibilité des équipements pour le Métier. Il faut néanmoins se préparer au pire et avoir les outils nécessaires à la détection d’un incident pour le remédier au plus vite et garantir un temps d’interruption réduit au maximum.

La mise en place de la détection

La première étape à réaliser est l’activation des fonctions IDPS[2] sur les équipements réseaux afin d’assurer un premier stade de détection et potentiellement de blocage automatique.

Il s’agit ensuite d’assurer la collecte d’informations en déployant un concentrateur sur site. Les logs des équipement réseaux et serveurs pourront ainsi être envoyés aux SIEM[3] existants ou dédiés dans lesquels se feront corrélation et détection. Les SOC[4] et CERT[5] peuvent alors réaliser les opérations d’analyse, de détection et éventuellement de réaction sur incident en se basant sur des scénarios classiques.

L’anticipation de risques spécifiques

Cependant, la détection basée sur des scénarios classiques n’apportera que peu de valeur aux métiers. La prise en compte de l’ensemble des sources (PC, Linux, UNIX…) et la mise en place de sondes dédiées aux SI Industriels capables de s’interfacer avec des systèmes SCADA peut permettre d’améliorer le système de détection. Toutefois, ces solutions peuvent s’avérer coûteuses.

L’élément clé consistera ici à assurer une montée en maturité et en valeur incrémentale et rapide du SOC.

Se préparer à la remédiation

Pour finir, la détection d’un incident ne pourra aboutir à une remédiation efficace que si le Métier est inclus. Tout comme pour les mises à jour d’équipements, il convient donc de revoir les procédures d’arrêt d’urgence avec les utilisateurs du SI Industriel. La formalisation d’un Plan de Réponse à Incident permet de planifier les actions à mener en cas d’incident cyber-industriel.

Des exercices de gestion de crise dédiés au SI Industriel doivent également être menés pour assurer une préparation optimale des équipes et mettre en lumière les éventuels manques.

Une approche progressive et participative garantira le succès de la démarche

La mise en conditions de sécurité d’un SI Industriel est un chantier complexe qui ne peut être faite qu’avec le Métier. Il convient donc de travailler avec lui de manière progressive et participative sur chacun des chantiers suivants :

• Prendre connaissance de son SI Industriel en réalisant une cartographie en priorisant les éléments les plus critiques ;
• Mitiger les risques sur le SI Industriel en mettant en place l’état de l’art de l’architecture réseau sécurisée et définir les processus d’administration – les SI de Sûreté, par leur criticité, devront faire l’objet d’une attention particulière ;
• Atteindre un niveau de sécurité adéquat par le durcissement et le maintien en conditions de sécurité des équipements dans le temps – des discussions pourront notamment avoir lieu avec les fournisseurs et constructeurs d’équipements ;
• Mettre en place les outils nécessaires à la détection d’incident de sécurité, qui peuvent avoir une influence sur la production, et définir les processus de réaction.

Toutes ces actions ne peuvent pas toujours être menées en parallèle. La définition d’une feuille de route claire va permettre la priorisation des différentes actions pour pouvoir maitriser les coûts et maximiser l’apport pour le Métier.

Si ce vaste chantier est souvent initialisé en central, l’enjeu reste de pouvoir embarquer les sites, parfois répartis dans le monde entier, pour assurer une sécurité pérenne dans le temps. Nous observons, en général, une démarche en deux temps :

1. Un programme cybersécurité pluriannuel (souvent 3 ans) pour un budget de 10 à 15 millions d’euros visant à :

• Réaliser l’inventaire des SI Industriels ;
• Élever le niveau de sécurité du parc existant par la mise en place de protections souvent périmétriques et de filtrage ainsi que la remédiation des vulnérabilités les plus critiques – la définition de procédures est ici nécessaire ;
• Faire émerger un premier réseau de coordinateurs cybersécurité locaux ;

2. La création d’une filière cybersécurité industrielle et de la gouvernance associée réunissant :

• Le cadrage des activités clés à piloter par les acteurs locaux ;
• La construction participative d’outils pour aider ce réseau de responsable locaux à opérer les activités de cybersécurité sur le contenu ;
• La construction des moyens de pilotage de la montée en maturité et de gestion du changement (matrices de maturité, outils de modélisation budgétaire par site, définition d’indicateurs de pilotage, services centraux consommables par les sites…).

La mise en place de la gouvernance peut démarrer après le programme et tirer ainsi profit du premier réseau de correspondants sensibilisés à la cybersécurité bâti par le programme.

Une fois construite, il s’agit ensuite de l’animer et de piloter la progression des sites et des systèmes industriels à la fois en termes de niveau de sécurité et de niveau de maturité.

Cette animation réunit en général :

• Un réseau responsables cybersécurité locaux de 0,5 à 2 ETP[6] par site en charge de réaliser les projets, d’implémenter les activités récurrentes de cybersécurité, d’améliorer continuellement la sécurité et de reporter ;
• Une équipe centrale de 3 à 10 ETP pilotant globalement et appuyant les responsables locaux notamment en termes d’expertise.

[1] IAM i.e. Identity and Access Management.

[2] IDPS i.e. Introduction Detection and Prevention Systems.

[3] SIEM i.e. Security Incident and Event Management.

[4] SOC i.e. Security Operation Center.

[5] CERT i.e. Computer Emergency Response Team.

[6] Ces chiffres peuvent varier significativement en fonction de la taille de l’entreprise et du nombre de sites locaux, il s’agit d’une moyenne observée dans de grandes organisations internationales que Wavestone accompagne.

Cet article Saga (3/3) – Retours d’expérience et bonnes pratiques pour protéger et maintenir en condition de sécurité des SI Industriels est apparu en premier sur RiskInsight.

Industrial networks also called ‘OT’ (Operating Technology) or ‘Production Networks’ include: production networks in factories, test benches, research laboratories or embedded networks in technological products: trains, cars, planes, etc.

USB flash drives, the real swiss army knives of industrial it, are proving to be formidable vectors for cyber attacks

Particularly vulnerable industrial networks

Industrial systems have long service lifecycles lasting for several decades. These service lifecycles are much longer than those in traditional IT and often lead to problems of hardware or software degradation. These legacy systems are then no longer maintained by their suppliers as they stop publishing security updates for them. Maintaining their security is therefore complex or even impossible.

Even when updates are published, there are issues. For example, they require a maintenance window which can have an operational impact. In some cases, it may also be necessary to requalify the system or perform technical and functional testing before restarting.

In addition, system standardisation has become the norm. Windows or Linux operating systems are commonly found with fewer security patches and therefore may be more easily exploited by computer viruses.

The degradation of industrial systems, the difficulty of maintaining them in a secure state and their standardisation make them increasingly vulnerable to cyber threats. However, it is still necessary to access the industrial network to exploit these vulnerabilities, as they are historically less exposed….

These vulnerabilities are regularly exploited using removable media as a vector

Removable media is often used as a bridge between the internal office network or an external network and the industrial network. For example:

• USB storage devices can be used to deploy configurations or patches on disconnected systems. These configuration files or patches come from workstations that have an internet connection via the company network. These workstations are exposed to cyber threats, and as a result so are the USB storage devices, and through them, the disconnected systems.
• Many service providers operating on the industrial network use USB sticks to deliver configuration files, debugging tools and other software. The multitude of subcontractors means there are many data exchanges from uncontrolled networks to industrial networks, each potentially representing a threat vector that can be exploited.

These exchanges expose the industrial network to several types of threats:

• There are many viruses designed to exploit Windows vulnerabilities by spreading through removable media. One of the best-known ones is the Conficker virus, which exploits the automatic task launch mechanism of removable media and thus manages to automatically launch a virus or viral payload when the media is connected. Once a computer is infected, it can spread to other hosts through the network.
• The original intended use of storage devices can also be maliciously changed; this type of attack is called a “Bad USB”. Rubber Ducky is an example: it makes a USB key look like an input device such as a keyboard, and then launches commands when connected to a computer.
• When connected to a computer, USB killers, which look like ordinary USB sticks, store energy until they reach a high voltage, they then release this energy into the host computer to destroy its physical components.

However, the use of these removable media devices is difficult to circumvent

Removable media has several common uses such as data storage, backup, transfer or information sharing.

These different use cases have gradually emerged, often at the ingenuity of users without any real supervision from the IT department or the business. When we study these different scenarios, we can classify them into two categories:

• Those that can be easily removed by offering either a more secure alternative or an improved way of working. For example, with two industrial networks connected to each other, the implementation of a file sharing space on the network can replace a direct exchange by removable media.
• Those that could be eliminated with major investment or be very difficult to remove immediately. For example, using an isolated network to install a new computer whereby the deployment of a master image by USB can be difficult to replace.

It is difficult to do without removable media entirely, but their use remains problematic. Faced with these threats, solutions are beginning to emerge.

Multiple technical solutions exist but provide only a partial solution

A myriad of increasingly available technical solutions

There are different technical solutions for controlling the content or use of removable media. They can be categorised into several families of solutions:

• Decontamination terminals or boxes, using one or more antivirus databases, allow us to analyse the USB key content, and if necessary, (re)format or quarantine files if they are considered malicious. Several manufacturers offer this type of solution, including KUB, HOGO, Orange and SOTERIA.
• More complex ones can issue a certificate to the key after it has gone through the decontamination terminal. This certificate validates (to the host) that the key has been scanned. This requires that an agent is deployed on all workstations to enable certificate authentication. OPSWAT and FACTORY Systems are among the manufacturers. Previously mentioned KUB, also offers this more complex option on these boxes.
• Lastly, there is a solution to group the devices that are used as filters, effectively acting as security airlocks between the host and the removable media. This is a small piece of equipment, connected directly to the USB port of the host on one side, and to the USB key on the other side. Its operation is based on white-list filtering and/or blocking writing from the workstation to the removable media. SECLAB is an example of a manufacturer for this solution.

Since all solution offers have different characteristics, it is necessary to identify the one that best meets the security requirements and constraints of the user.

These technical solutions create additional steps and require time, which may hinder their adoption

Depending on the technical solution, the cleansing of removable media is a step that can be time-consuming.  For example, if the key contains lots of small files that must all be checked, the processing time will increase. This task is also highly dependent on the performance of the media being tested.

Additionally, a problem of sizing the terminal arises if the removable media is used to push several large updates (Microsoft for example) or even a complete WSUS database (Windows Server Update Services) between 2 networks (this can reach a 100GB of data). If this time is not controlled and limited, removable media users will stay clear of this technology.

Difficult access also discourages users. In the industrial sector, there are many constraints depending on where users are located. A change of area may require a change of protective equipment, clothing or special controls. Insufficient equipment could lead to the same accessibility problem.

It is necessary to place the right equipment where decontamination is taking place or is unavoidable (reception, security office), and to find the right compromise between the different implementation of solutions: e.g. a solution applied centrally (terminal) vs. distributed (box or filter).

These technical solutions often require maintenance in operational condition (MOC) and maintenance in safety condition (MSC) which must not be neglected

To properly function, the technical solutions must be maintained by updating them, updating their viral databases for when the solution integrates an anti-virus, updating the filtering rules, as well the certificate database for more complex systems. It is also useful to be able to issue reports and alerts when the tool permits.

For this purpose, the decontamination terminals require several types of access:

• antivirus updates on servers;
• internal operating system updates on servers;
• the supervision network for issuing reports and alerts;
• Sometimes to a dedicated server that will manage the certificate database and centralise administration.

These terminals can therefore be integrated into a more, or less complex architecture as required.

Decontamination terminals are equipped with an operating system and often standard applications, hence the importance of hardening their configurations so they themselves are not the victim of an attack.

It is necessary to conduct a study on the possible technical solutions by putting into perspective the reliability, utility, efficiency and cost of each option. Similarly, it is essential to review the governance of these facilities, which are at the crossroads between the management information system and the industrial information system. This should avoid problems of underestimating the implementation of these solutions and stop users turning away from the chosen solution.

The protection of industrial systems against USB-related threats requires a careful choice of technical solution and availability for users. Without this and without awareness of the cybersecurity issues, systems are exposed, and the impacts of an attack can be significant.

These tools must be the subject of a full project: from the consideration of use cases and change management

The use cases must be known to decide between the different solutions or even eliminate the use of the removable media

Before proposing a technical solution, the first question to ask yourself is why do we need to use the removable media? To answer this question, you must list all the different use cases.

In each case, it must be determined whether their use is appropriate and whether there is no more effective and/or safe alternative. Here are some examples of commonly encountered situations for which alternative solutions exist:

• If a USB key is used as storage for config. files, then a centralised solution or at least storage on suitable equipment can be used.
• In the case of media being used between two devices that are connected to a network, the implementation of an exchange server, for example using a secure protocol such as SFTP, can be considered.
• For maintenance teams working on connected systems that use removable media to update configuration files, an MFT (Managed File Transfer) exchange gateway with antivirus control can be used. This application ensures the safety of a file from an external source before making it available internally. A third-party solution would be able to make secure removable media available to staff or maintenance teams by only allowing editing of media from workstations.

In the remaining cases, an appropriate solution should be considered. The solution should be presented to users and its interest explained. For better adoption, it should have as little influence as possible on the pre-existing business process, and as a minimum, it should not lead to an excessive workload or time commitment.

In addition to being integrated with the business use case, the technical solution must meet the intended security objectives

2 selection criteria must be taken into account when deploying a removable media security solution: the business use case and the security objectives targeted.

The security objectives are often the same: check that a storage device is genuinely a storage device (i.e. not a “Bad USB”) and check that it does not contain a virus or viral payload. These 2 objectives are covered by most solutions on the market.

It is therefore the business use case that will influence the ergonomics of the chosen solution:

• A fixed monobloc terminal integrates well into the entrance of an area reserved for operations such as a laboratory or workshop. On the other hand, a tablet will be much more mobile and can be used in several situations.
• A certificate solution requiring an equipment agent on standard workstations without specific qualifications will not be difficult but can be problematic in qualified or already obsolete environments.
• Mobiles always need a way to control; a filter solution can be considered for this.

Once the type of solution has been chosen, the possibilities of integrating the solution into the existing ecosystem with proposed security measures will make it easier to select the most appropriate one.

The chosen solution must integrate administration and incident reporting functions while guaranteeing an appropriate level of security

The chosen tool must be easily manageable and have a centralised administration function if there is a significant number of facilities being planned. It is also necessary that the following elements of the solution can be updated: the operating system, the embedded applications, antivirus applications, and the signature databases.

These features mean that the solution will need a connection to the administration network and an external connection to retrieve these updates. These connections must be secure, and the update server systematically identified.

In addition, it is necessary to take precautions to ensure that the solution has been hardened and that only the useful functions are available, especially at the operating system level. It would be pointless if the key decontamination tool itself was the vector of key contamination!

Finally, it is preferable that the generated reports and event logs can be sent in a standard Syslog format, centralised and also analysed by an existing SIEM to detect and track any suspicious activities.

In conclusion, the implementation must be approved by the people who will actually use the terminal every day

There are many technical solutions that, by analysing and decontaminating these devices, can reduce exposure by removable media in industrial networks. There are 2 success factors for good implementation:

• A solution designed for business use cases with end users in mind; and
• A solution where administrative factors, the update process and security aspects have been considered upstream.

In addition to these, there is a 3^rd success factor: change management, which must ensure that the new tool is properly integrated into existing processes with appropriate communication to end users.

It is necessary to formalise a procedure in case there is a virus or any other abnormality. Detecting is ultimately only the first step towards an appropriate response.

Cet article Removable media decontamination tools – success factors for effective security gain and successful deployment est apparu en premier sur RiskInsight.

Le développement rapide du véhicule autonome et connectée indique qu’il est urgent de mettre en œuvre des mesures pour réduire le risque cyber.

Dans un premier temps, ces mesures consistent à adapter des concepts de cybersécurité connus et maitrisés tout en s’adaptant à un environnement nouveau, dans un contexte marché ultra-concurrentiel et confronté à des usagers de plus en plus exigeants.

Dans un second temps, il s’agit de mettre sous contrôle des systèmes critiques intelligents, interactifs, et ce en temps réel afin de se prémunir d’attaques évolutives, de plus en plus sophistiquées et difficiles à anticiper.

Des concepts de cybersécurité connus… mais qui doivent tenir compte des contraintes propres aux systèmes embarqués

La course à l’innovation autour du véhicule connecté conduit à la mise en œuvre de plus en plus de services, ce qui augmente le niveau d’exposition du véhicule à de nombreuses menaces – adeptes du car tuning, hacktivistes, organisations criminelles, gouvernements etc.

La mise sur le marché de nouveaux modèles de véhicules pourrait être conditionnée par sa capacité à se protéger des cybermenaces. En effet cette protection pourra s’appuyer sur des incontournables de la cybersécurité tels que : la gestion des identités et des accès (authentification forte, infrastructure PKI…), la segmentation des réseaux et le regroupement par actifs critiques (Firewall, Gateway…), le chiffrement des données et des communications (via un réseau Ethernet, des environnements d’exécution protégés), la détection et la supervision des composants critiques (SIEM embarqué, sonde de sécurité IPS/IDS…).

Contrairement à un système d’information d’entreprise, un véhicule connecté est un produit contenant un système pouvant s’apparenter à un système d’information à espace fini, à prix fixe et en mouvement. Autant de contraintes différentes de celles d’un SI classique qui complexifient sa sécurisation. Celle-ci doivent être prises en compte au plus tôt, dès la phase de conception du véhicule :

• Le coût du véhicule – Des solutions cybersécurité connues certes, mais qui doivent néanmoins s’intégrer dans un système initialement mécanique/électronique où le coût de chaque pièce doit être justifié afin de ne pas trop augmenter le Prix de Revient à la Fabrication (PRF). L’important étant de maintenir un équilibre coût/risques acceptable pour garantir la sécurité de l’usager.

• La dimension et le poids du véhicule – L’encombrement et le poids sont les deux principaux ennemis des solutions de transport. L’intégration de composants embarqués et de modules de cybersécurité supplémentaires peut amener à une modification des architectures physiques des véhicules. Mais l’évolution d’un véhicule n’est pas aussi aisée que celle d’un système d’information classique ; au vu du contexte une approche modulaire permettant l’ajout de capacité hardware dès la phase de conception pourrait être envisagée.

• La capacité de calcul en temps réel – Selon la criticité des composants du véhicule, il pourra être décidé d’y sécuriser certaines communications (via chiffrement, signature). Une analyse fine et une priorisation des échanges à protéger sont préconisées, les mécanismes de cryptographie étant très consommateurs en ressources et puissance de calculs.

• L’expérience utilisateur – Les constructeurs automobiles ont toujours cherché à développer le concept de confort et de plaisir de la conduite. L’intégration de la cybersécurité dans le véhicule ne doit pas aller à l’encontre de ce principe et nombre d’utilisateurs ne sont probablement pas prêts à accepter la cybersécurité au détriment de leur expérience de conduite. Ainsi, il paraît difficilement envisageable de demander à un conducteur d’entrer un mot de passe à chaque démarrage du véhicule, encore moins de configurer un nouvel utilisateur pendant plusieurs minutes à chaque fois qu’il prête son véhicule. Les problématiques de cybersécurité permettent d’identifier de nouveaux usages et de se positionner au service de l’expérience utilisateur. Cela peut conduire au développement de solutions innovantes comme l’authentification de l’usager via smartphone ou la délégation de droits d’accès au véhicule via une application.

• La mobilité et la connectivité – La détection d’incidents et la supervision des composants critiques du véhicule nécessitent une disponibilité et une remontée des logs en continue.  Sachant qu’un véhicule en mouvement peut être amené à se retrouver dans une zone à couverture réseau limitée (voir nulle), ces problématiques de connectivité amènent à concevoir des systèmes de supervision et détection directement intégrés au véhicule. De manière générale, face à la perte de connectivité, la résilience doit être généralisée à l’ensemble des fonctions (cyber ou non) du véhicule.

• Le cycle de vie – La durée de vie peut varier d’un véhicule à l’autre, historiquement basée sur l’usure mécanique que subissent les voitures. Désormais le véhicule c’est aussi un ensemble de composants électroniques et de services qui doivent s’adapter à un cycle de vie long. Chaque système et solution informatique incorporés au véhicule doivent être conçus pour fonctionner et être supportés dans la durée. Le défi que devront relever les constructeurs est de contrôler l’obsolescence et maintenir en condition opérationnelle leur parc automobile. Le développement des systèmes de mise à jour Over-The-Air (OTA) deviendra une nécessité pour le déploiement des patchs et correctifs de sécurité.

Les principaux enjeux de cybersécurité

La (cyber)sécurité des véhicules n’est pas qu’une affaire de solutions techniques

Convergence de l’ingénierie automobile et du digital

Le croisement des univers de l’ingénierie et du service devient un sujet prioritaire chez les constructeurs automobiles, provoquant certains changements dans leur cœur de métier. La gouvernance doit évoluer en prenant en compte un certain nombre d’actions indispensables à la sécurisation de leurs véhicules et plateformes de services.

Il est important de s’assurer que la cybersécurité soit pensée et intégrée dans l’ensemble des étapes du projet tout en disposant des ressources et compétences nécessaires.

La mise en circulation d’un véhicule impose aussi de gérer lors de cette phase des problématiques de maintien en condition opérationnelle et de sécurité des systèmes développés, qu’ils soient embarqués ou débarqués (plateforme de services connectés). Ainsi les constructeurs opèrent dans un environnement qui les positionne, à la fois, en fournisseur de produit mais aussi de services automobiles.

On constate que le temps moyen de développement et d’intégration d’un véhicule est d’environ 3 à 5 ans, là où il faut quelques mois pour développer et mettre en production un nouveau service (connecté).

De fait, pour faire face à un marché toujours plus concurrentiel ; les architectures développées du véhicule doivent être en capacité de supporter l’approvisionnement régulier de nouveaux services tout au long du cycle de vie. Il sera nécessaire de garantir un maintien du niveau de sécurité, de sureté et de qualité du véhicule.

Ainsi, on peut logiquement s’attendre à une transformation des scénarios de développement et d’intégration, avec un véhicule qui voit sa plateforme devenir plus modulaire, plus évolutive pour réduire ce fameux « time-to-market ». Les services quant-à-eux se verront soumis à un développement Agile avec un temps de mise en production plus flexible afin que les mondes de l’ingénierie et du service soient de nouveau « synchronisés » et puissent travailler en synergie.

Le ruissellement de la cybersécurité des constructeurs aux fournisseurs

La question de la responsabilité en cas d’accident lié à une cyber attaque ou à un incident système devient également un sujet urgent à adresser. En effet, par défaut la responsabilité de l’accident serait attribuée au système assurant le déplacement sécurisé de la voiture. Le constructeur automobile, créateur du système, devrait en assumer la défectuosité (conformément à la partie responsabilité du fait des produits défectueux issu de la loi n°98-389 du 19 mai 1998). C’est pourquoi les constructeurs (ou OEMs – Original Equipment Manufacturer) auront la responsabilité de s’assurer que les fournisseurs de rang 1 (Tiers-1) et plus, s’engagent eux aussi dans une démarche d’intégration de la cybersécurité dans les produits fournis. La sécurité de bout-en-bout du véhicule ne pourra être assurée que par la déclinaison d’exigences de sécurité sur l’ensemble de la chaine fournisseur., intégrées dans les cahiers des charges, renforcées au sein des contrats et vérifiées à la livraison.

La problématique de la cybersécurité dans l’écosystème automobile est prise très au sérieux par les instances internationales et plus particulièrement par la Commission Economique pour l’Europe des Nations Unies qui entend faire de la nouvelle norme, l’ISO/SAE 21434, une base commune de référence que l’ensemble des acteurs de cet écosystème devront respecter. Cette norme encore en cours d’élaboration fera l’objet d’un prochain article.

Cet article Saga 3/3 : La sécurité des véhicules connectés, les réponses pour une transformation nécessaire ! est apparu en premier sur RiskInsight.

In this series, we’ll first present connected vehicles and their associated cybersecurity challenges; the main sources of threat and the risks will be addressed in a second installment. Lastly, a third article will present our views on the issue and the main lines of the response required to address it.

The connected car: a vehicle supporting a raft of interactions

Entertainment, an extension of your smartphone, shared mobility, management of the car’s life cycle… users are demanding new experiences, and the services and applications they generate are resulting in a range of interactions. We can imagine a smart car being able to find a free parking space, automatically schedule an appointment for maintenance, or turn a traffic light green as it approaches. Since April 1, 2018, all new vehicle models must also have an emergency call system, as well as geolocalization to enable the authorities to be contacted in the case of an accident. In this respect, they are already “connected”.

Manufacturers and other players are already capitalizing on the opportunity to maintain a close relationship with customers throughout the vehicle life cycle. By doing this, they become “providers of services and mobility solutions,” drawing on, among other things, collected data. In particular, because such connectivity represents a step toward autonomy, the vehicle needs to be able to communicate with other vehicles and the surrounding environment. These changes are underway, and their pace will progressively increase.

However, the challenge of cybersecurity is scarcely taken into account, or ignored: yet it has to be a key plank of any connected solution—from the design phase to the end of the life cycle. Such thinking is essential to safeguarding the vehicle’s integrity, protecting passenger lives, and complying with current and future regulation.

The first prerequisite is to properly understand the connected vehicle’s technologies and ecosystem.

How connected vehicles interact with their environment

A specific feature of a connected vehicle is that it interacts with its ecosystem, via mobile data streams, over both the short and long-ranges.

• Short-range connections: Here, the vehicle interacts directly with an object (such as a smartphone, infrastructure, etc.), without any intermediary. It uses technologies with a limited range for local exchanges (WAVE, on-board Wi-Fi, Bluetooth, etc.).
• Long-range connections: Here, the vehicle uses remote access to interact with external components via a cloud platform. 4G, and soon 5G, connections are the technologies of choice for connecting vehicles to the internet.

This connected-vehicle concept also covers exchanges with the vehicle’s direct environment under the umbrella term “Vehicle-to-Everything” (or V2X). Lastly, the standard, ISO 20077, covers “Extended Vehicles” (or ExVe) as a whole: which comprise the physical vehicle as well as all the platforms and infrastructures that the car manufacturer is responsible for.

A range of ecosystems and players that need to work together

The car was once a very closed system; with the exception of diagnostic connections for garages and some connectivity to be able to broadcast multimedia content; any connectivity risks were largely contained. Today, the proliferation of forms of connectivity and access to the internet have opened up new opportunities for manufacturers and service providers, but also for attackers.

The first ecosystem to consider is the . Electronic and communication systems must be able to communicate with each other without the transmitted data or stored secrets being altered or stolen. Among these systems are the ECUs, the mini “on-board computers” that control the vehicle’s key functions, such as the braking system, air conditioning, lighting, etc.

Beyond on-board security, there are the user and owner (the latter not necessarily an individual) who have the right to give orders to the vehicle according to pre-defined rules. In the future, their authentication will be essential when it comes to questions of responsibility, as well as for verifying the legitimacy of the orders they issue.

Another vitally important aspect concerns connected services that use centralized platforms, or even cloud-based ones, which have been developed by the manufacturers or their partners. These platforms represent a significant threat because they can trigger orders for entire fleets of vehicles, and therefore the impact of any problem is multiplied. Manufacturers will need to put in place sufficiently secure solutions to allow such services; they’ll need to combine their own platforms with those of partners and the APIs on the vehicle, as well as ensuring the required level of confidence in the environment.

Lastly, in the medium-term, external objects and the surrounding environment (other vehicles, garages, parking lots, road infrastructure, etc.) will need to communicate and share information. The challenges of ensuring security in real time (in terms of availability, integrity, etc.) will be complex ones.

Cybersecurity issues: from the virtual to the real world

People’s safety, inside and outside vehicles, is a top priority for the automotive industry. We might imagine, then, that the cybersecurity issues raised by connected vehicles will be treated with the same degree of rigor—such that they can guarantee the car’s safety and integrity.

The first issue represents an organizational challenge for all stakeholders, especially manufacturers, because the emergence of this new model brings together two opposing worlds: services and engineering. The first is characterized by agility and speed, and large numbers of short-term projects. The second, with a much longer development cycle, must meet the safety and quality requirements associated with vehicle approval. This dichotomy has impacts on cybersecurity and, in particular, its integration into development projects, as well as the coverage of end-to-end risk. For example, as a result of its position, the backend becomes a nerve center that must be fully protected to avoid any risk of a systemic attack that could have repercussions for the entire fleet. Unfortunately, the true value of this need for security is not currently appreciated, mainly as a result of requirements for very short times to market.

Considering the other issues, it’s clear that the cybersecurity challenges for connected vehicles don’t differ greatly from those in the IS world: identity and access management, detection and response, the security of infrastructures, cryptography, third-party management, patch management, etc. A connected vehicle is a mobile IS, and numerous security standards (ISO2700x, NIST 800, etc.) have already been developed. These set out good practice in various guides and reference documents (SAE J3061, AUTOISAC, NHST, etc.) and the topic will shortly be covered to the ISO/SAE 21434 standard.
However, a number of factors inherent to vehicles and their embedded systems mean that the topic needs to be considered from new and specific angles.

The vehicle’s mobility and connectivity make security more complex: security must be guaranteed where there is a limited connection, or no connection, and in the context of a changing environment. Regulatory aspects must not be ignored either, given that the vehicle may have to move between countries.

The world of on-board systems also places constraints on hardware—in terms of cost, computing power, and size.

Questions about updating components and services arise too, given that a system must be able to function at all times but may also be shut down for long periods.

Lastly, vehicles are designed for a long life cycle, which implies thinking about security from the start, especially when it comes to managing identities and accesses. This long life cycle also means considering evolving standards over time, as well as developing a model for updates that guarantees vehicle security in a way that is sustainable and manageable for constructors.

The road ahead is long, and cybersecurity is approaching a crossroads that was not in view a decade ago. It’s vital that all players involved grasp the importance of what’s required and start to put in the effort now, before it’s too late.

Cet article Saga 1/3: connected car: between cybersecurity and safety est apparu en premier sur RiskInsight.

Here is a little background on the study released during the Vivatech event dedicated to startup and technological innovation, called “How are startups shaping the future of road mobility?” in which a chapter was dedicated to cybersecurity.

The automotive industry must now consider cybersecurity as an integral part of how cars are built, just as physical safety became a critical part of how cars were built in the late 20th century.

Many people in this field caught on leading to the creation of many startups on the topic. Today, no less than 20 startups try to provide solutions to face automotive cyber risks.

Cybersecurity, yes, but with a different approach

Those startups show that the challenges to be handled are almost the same as those usually encountered in other sectors but need to be addressed differently.

Due to the current specificities and constraints related to the automotive industry and connected car in particular, startups are having to adapt existing cybersecurity concepts and solutions while innovating including:

• Manufacturing costs;
• Proprietary and specific technologies for embedded materials, with little security originally integrated (e.g. CAN – Controller Area Network);
• Systems with long lifetime and complicated upgrade capacity;
• Limited processing capacity;
• Architecture complexity.

4 main cybersecurity objectives are addressed by startups in the field, through the products and services they propose:

• protect hardware, firmware and software, as well as related processed-data which is a true challenge especially when having to implement cryptography mechanisms requiring significant computational
• ensuring only legitimate communications are allowed to ensuring no-one is able to take unauthorized control of  a car, while protecting data in transit which is essential for privacy;
• detecting abnormal events and reacting accordingly in order to prevent any intrusion or cyber attacks on a car as well as a whole fleet;
• managing systems lifecycle, particularly related-vulnerabilities is  becoming a major concern all the more so when a car has a 15 to 20 year life;

It appears clearly that intrusion detection and threats prevention are two of the most covered topics as 70% of the automotive cybersecurity startups are offering related solutions. One can say that the market and car manufacturer kept in mind what happened to the Jeep Cherokee. However this figure may originates from the fact that is probably easier to provide security at the car boundary rather to integrate cybersecurity in the current constraint in-vehicle architecture and components.

One another key point is that vehicles have a lot in commons and share, for some aspects, the same characteristics with the Internet Of Things. That’s why it is not surprising to see startups like Prove&Run or IoT.BZH coming from this world and offering embedded software and hardware oriented security services and solutions to the automotive market.

Cybersecurity startups anticipate future connected car architectures

Even if startups mainly offer solutions and services to secure existing systems and architectures within modern vehicles, there is a trend today showing some of them are anticipating and building cybersecurity solutions for the forthcoming systems and architectures.

The startup Argus Cyber Security* is a good example. One of its first products was the “CAN firewall”, to protect the historical CAN network which is still the reference protocol in  current vehicles. The startup has since developed new solutions like the “In-Vehicle Network Protection Suite” to support a wide array of network protocols – CAN and CAN-FD, FlexRay, Ethernet (with SOME/IP, DoIP etc.), etc. – and thus defend current and future vehicle architectures.

Another example is Arilou Technologies*, which recently designed a new cybersecurity tool called the “Ethernet Security Hub” especially for protecting future connected and autonomous vehicles equipped with Ethernet networks rather than CAN networks.

Major actors invest in startups at an unprecedented pace

The ongoing creation of cybersecurity startups in the automotive industry over the past years highlights the fact that cybersecurity has become a top concern in the sector.

Established automotive companies, like car and equipment manufacturers, know this well.

Some focus on hiring new talents and/or developing technologies in-house but most of them are very aggressive in investing or buying startups at an unprecedented pace. Are they afraid of the potential competition? Are they unable to provide these innovations with their own R&D teams? Do they want to
accelerate with the integration of new ways of working and new teams? The answer is certainly a combination of these 3 factors as the connected and autonomous car represents a major shift in their organization and strategy.

This fast movement is clearly visible when looking at the list of the latest startups acquisitions below:

• Founded in 2013, ADVANCED TELEMATIC SYSTEMS was acquired by HERE in 2018;
• Founded in 2013, ARGUS CYBER SECURITY was acquired by Continental in 2017;
• Founded in 2012, TRUSTPOINT INNOVATION TECHNOLOGIES was acquired by ETAS (Bosch) in 2017, which had already acquired the cybersecurity company Escrypt in 2012;
• Founded in 2012, TOWERSEC was acquired by Harman in 2016, which was in turn acquired by Samsung in 2017;
• Founded in 2010, ARILOU TECHNOLOGIES was acquired by NNG in 2016;
• Etc.

In addition to these acquisitions, many actors also invest in startups and build partnerships with them, like Denso for example, which recently invested over $2 Million in Dellfer, a startup that was founded in 2016.
Besides, startups are not the only ones to be concerned. Some established companies in the field are also concerned, highlighting the market dynamism on the topic. For instance, Thales and Vector recently formed a joint-venture to work on addressing cybersecurity challenges related to the connected and autonomous car.

A new area of risks is rising

The arrival of autonomous cars is a new challenge for cybersecurity. Many new risk scenarios will have to be taken into account, mainly in the field of attacks on artificial intelligence, advanced sensors security and even automated response to cyber events.

To face this new challenge, solutions are only at a development phase and not particularly dedicated to the automotive sector. Many researchers like Nicolas Papernot or Ian Goodfellow are currently working on how to prevent Adversarial Attacks which aim at deceiving AI and which could lead, if applied to an autonomous car, to safety issues.

Breakthrough solutions are probably being developed by startups from the Zeroth. AI accelerator, an Artificial Intelligence and Machine Learning focused startup accelerator.

Although they will undoubtedly provide bleeding edge solutions to these complex problems, no one has declared working on the automotive field yet.

Certainly, cybersecurity and safety will have to be addressed jointly to make autonomous vehicles a reality.

Cet article Connected cars: When cybersecurity comes into play est apparu en premier sur RiskInsight.

Therefore, vehicles attack surface is becoming ever wider. They are then exposed to more and more risks which can jeopardize passengers’ safety but also the safety of people around vehicles under attack. Indeed, several researchers have already managed to perform different attacks on recent vehicles, and sometimes shown how to take full control of them. ​

What kinds of cyberattacks have been performed so far? What are the possible attack vectors? What could be the motives behind such cyberattacks?

A wide range of cyberattacks already performed on connected and autonomous cars…

Over the last few years, several vulnerabilities have been discovered by researchers on connected vehicles. In particular two events gave rise to an important media response in 2015, bringing the topic to the forefront.

The first one was performed by American researchers Charlie Miller and Chris Valasek, who managed to remotely hack a Fiat Chrysler car and take control of many functionalities, from radio volume tuning to brakes activation. Their entry point was the Internet-connected feature Uconnect that was used in the car to control the vehicle’s entertainment and navigation system, enable phone calls and offer a Wi-Fi hot spot. By attacking this feature, they managed to reach an adjacent chip in the hardware used for the car’s entertainment system, and silently rewrite the chip’s firmware to plant their code. With this rewritten firmware, they were then able to send commands through the car’s internal network, known as CAN bus, to its physical components like the engine and wheels. Once this attack was presented by the researchers, Fiat Chrysler had to patch 1.4 million vehicles by sending USB sticks to all concerned customers so that they can manually fix the vulnerability in their vehicles.

© ANDY GREENBERG/WIRED

Apart from cyberattacks that were made possible thanks to initial physical access or remote connection, others were also performed on sensors used in some cars to detect their surroundings. For instance, in 2016, Chinese researchers showed how to attack the Tesla Model S through its different sensors: Millimeter Wave Radars (MMW Radars), LiDAR, cameras, ultrasonic sensors, etc. They presented different kinds of attacks such as:

• Jamming attack on MMW Radars: use of a transmitter tuned to the same frequency as the car’s receiving equipment, and with the same type of modulation, to override any signal at the car’s receiver. Thus, no signal is received by the car, meaning that if the sensor is used to detect obstacles for example, these ones can no longer be detected during the attack (“obstacle evaporation”).
• Spoofing attack on ultrasonic sensors: use of a transmitter to create at a specific timing ultrasonic pulses with similar pattern as the ones of the car’s ultrasonic sensors to change the time of propagation. Thus, the distance between the car and the objects around it that is calculated by the sensors is no longer the real one during the attack.
• Blinding attack on cameras: use of an LED spot or lasers to blind, or even cause permanent damage on cameras (permanent dead pixels).

To sum up, researchers all around the world already managed to perform various cyberattacks on modern vehicles from different manufacturers, some of which are listed on the timeline below:

6 main vectors to attack connected and autonomous vehicles…

Today’s vehicles can connect to 3G/4G networks and can provide Wi-Fi and Bluetooth access. These technologies are standard and present vulnerabilities: many different types of attacks on these networks are well known. One can easily imagine an opponent penetrating remotely the local network of the vehicle using these canals or performing a “Man-In-The-Middle” attack, in order to steal personal data, to alter some services or even to take control of the commands as shown previously.

In addition, it is possible to directly connect to the vehicle. All cars have ODB port for diagnostic purposes and most of the modern infotainment systems offer a USB port. It represents an open door for attackers to conduct malicious actions with serious consequences: blocking part or all the systems due to a ransomware, malicious frames sent to the CAN bus, alteration of ECUs due to malwares, etc.

With the advent of extended and autonomous vehicles, new types of attacks must also be considered. The automated drive relies on many kinds of sensors that are continuously interacting with the environment to collect information about roads, traffic, etc. Attacks affecting these sensors may have dramatic impacts and malicious people can deflect the primary functions of either the sensors or the road infrastructures to cause an accident. In the past, a fatal accident has occurred, showing that sensors are vulnerable and be a source of misinterpretationOne can say with certainty that the implementation of artificial intelligence within vehicles will result in more and more targeting this vulnerable part.

Finally, the vehicle is becoming a central point of connection with the internet of things. Services will be delivered from smartphones and external devices that will become new vectors to conduct an attack. For instance, authentication may fail or be compromised on the smartphone and can give an unlimited access to services on vehicles, allowing doors unlocking for instance.

According to the attack vector, attacks may be categorized and:

• Could affect a single vehicle or a whole fleet, which will increase the level of impact
• Must be conducted close to the vehicle or can be realized remotely, which will change opponents’ capabilities and will contribute to increase the complexity of the attack because of the physical presence required or not.

Sensors, IoT, public or private network, the extended vehicle is a concentrate of technologies. It represents a large playground for attacker ready to act! But why a person would attack a vehicle?

 

What would be the motives behind such cyberattacks?

Motivations for the attackers could be diverse and varied. We have spotted 5 major categories:

• The first one is ideology: In the automotive context, several organization might intend to attack the vehicle. It could be an environmental group that wants to disclose a specific message (about air pollution for example), to cause a service outage, etc.

• It could be simply financial: Some attacks could be very basic: to hack the infotainment system to gain access free of charge to musical streaming services for example.

• Then, a third motivation could be destabilization: A state may want to destabilize another state by attacking a fleet of vehicle; a competitor may try to spoil the brand image of a car manufacturer, etc.
• It could be also killing: The possibilities to take full control of the vehicle and to cause accidents with likely human fatalities could attract criminals or terrorists. It will have a dramatic impact on populations. In a near future, a fleet of vehicles could become a massive state weapon.
• Then, the last one is attack capabilities procurement: Vehicles will become sophisticated systems with a great potential of computation. If a person finds a vulnerability, cars could become a way to spy citizens. Their performances could be also used for brute force attacks. They could be also turned into botnets to realize DDOS attacks.

Current vehicles already offer many ways to connect with external systems which could present vulnerabilities: Bluetooth, Wi-Fi, USB, etc. With the development of autonomous cars, services platforms and connected road infrastructures, the attack surface is going to increase more and more, and impacts will become very serious. Therefore, car hacking will also appeal to many opponents.

It becomes urgent to adopt a granularity approach to secure vehicle vital functions and to guarantee the safety of passengers. Measures and organization are inspired from IT world, but they need to be adapted to the automotive context. For this purpose, start-ups can bring some answers to technical challenges and norms, such as the ISO21434 currently in development, intend to provide a worldwide framework to increase the resilience of connected vehicles. But what are concretely the solutions and how to protect vehicles from cyberattacks? Don’t put the car(t) before the horse, stay tuned, we will soon have a look on it!

Cet article Saga 2/3: Connected cars… a path full of pitfalls (…and security holes) est apparu en premier sur RiskInsight.

Last year, the National Health Service England (NHS) faced its most important cybersecurity crisis due to the Wannacry ransomware attack. In October 2017, the National Audit Office (NAO) published a report showing that at least 34% of trusts in England were disrupted, and around 19,494 patient appointments canceled including canceled patient operations. This was mainly due to the fact that the information system managing the appointments, the patients’ records or test results were infected by the ransomware.

However, the report points out that medical devices such as MRI scanners (that have Windows XP embedded within them) were also locked by the ransomware. Only 1,220 devices were infected representing 1% of the overall amount, because several equipments were disconnected to avoid the ransomware propagation. So why the healthcare sector suffered from such an attack and how come the ransomware spread that easily?

Healthcare cybersecurity: Low maturity level

The NAO report highlighted the challenges that the NHS had to face to tackle the attack. These challenges seem similar to the ones that several industries and manufacturers have been facing showing that an analogy of the healthcare information systems and the industrial control systems (ICS) have the same weaknesses.

Indeed, both ICS and Health Information Systems (HIS)face the same cybersecurity challenges, among them:

• The wide use of legacy devices and operating systems (such as Windows XP);
• The length of the window of exposure of these systems (the window of exposure is the time between the vulnerability disclosure and the patching of the system): the vendors support or the quality guidelines and regulations may represent obstacles for a fast patching (a recent survey conducted on 3000 security professionals working for healthcare and pharmaceutical organizations, show that 57% of the respondents had experienced at least a data breach which was conducted after the exploitation of a vulnerability for which a patch had been previously released);
• Critical and unsecure devices directly connected to the Internet exposing the medical network. For example, McAfee published a report explaining how they exploited an unsecure and connected Picture Archiving and Communication System (PACS – device that stores and shares images coming from imaging devices such as scanners) to use personal medical data;
• Lack of security by design: several organizations and researchers have been alerting on several flows affecting medical devices such as pacemakers (Cyber-flaw affects 745,000 pacemakers – BBC), insulin pumps (J&J warns diabetic patients: Insulin pump vulnerable to hacking – Reuters) or infusion pumps (Black hat conference [PDF])

A growing threat on the healthcare sector

The low cybersecurity maturity level of the healthcare sector combined with the continuous interest of some actors on personal data or life threatening made the threat skyrocket these past few years. Indeed, several cybersecurity companies have been alerting on a growing number of cyber threat actors who are targeting healthcare sector, for example:

• In the last newsletter was reported that a US hospital was hit by Samsam ransomware in January 2018. Samsam is only one of the numerous ransomware that targeted hospitals among them Locky;
• In March 2018, Kaspersky researchers discovered that a Chinese-speaking group used PlugX malware (remote access tool which has been used previously by several groups since 2012) in pharmaceutical organizations for stealing information;
• In April 2018, Symantec identified a new attack group named Orangeworm. This group has been targeting healthcare sector companies (equipments manufactures, pharmaceutical, health organizations) for several years. Orangeworm has been using a backdoor called Kwampirs which collects data in the infected systems. This malware propagates easily in Windows XP devices.

Protecting against

In order to curb the number of security incidents in the healthcare sector, several measures can be, and in some cases have already been, implemented among them:

• Design of a global cybersecurity governance by implementing a cybersecurity policy;
• Conduction of awareness campaigns towards the hospital staff on the cybersecurity threats;
• Implementation of patch management procedure in order to reduce the window of exposure of the system (a combined work with the vendors and the regulation organizations may be required so the patching covers the largest amount of device as possible);
• Network segregation into several levels of protection matching the level of criticality (medical devices should be highly protected).

Several governmental agencies and institutions have been publishing reports and guidelines in order to help healthcare organizations and the medical devices suppliers in securing their network or providing more secure medical devices. You will find here after some of the documents:

• Cyber security and resilience for Smart Hospitals – ENISA
• Security and Resilience in eHealth Infrastructures and Services – ENISA
• Guide Pratique : Règles pour les dispositifs connectés d’un Système d’Information de Santé – Agence des systèmes d’information partagés de santé [PDF]
• Information for Healthcare Organizations about FDA’s “Guidance for Industry: Cybersecurity for Networked Medical Devices Containing Off-The-Shelf (OTS) Software” – FDA
• The U.S Food & Drug Administration released its Medical Device Safety Action Plan in April 2018

>>Latest news

	Aerial tramway with security holes Golem.de, April 19th Two white hackers found the control system of a new aerial tramway in the internet without any security measures. According to them, the commands were sent unencrypted, the authentication wasn’t provided and the web application was vulnerable to cross-site scritping and HTTP header injection attacks. Link to the article
	Patch Plugs More Than a Dozen Vulnerabilities Affecting Industrial Secure Router Series Tripwire, April 16th Cisco Talos published a report revealing several vulnerabilities affecting the Moxa EDR-810 industrial secure router with firewall/NAT/VPN and manager layer 2 switch functions. This router sets perimetric security for critical assets such as pumping/treatment systems in water stations, Distributed Control Systems (DCS) in oil and gas stations … Many of the flaws received a CVSS score of 8.8. Moxa released an updated version of the firmware. Link to the article
	Advisory: Hostile state actors compromising UK organisations with focus on engineering and industrial control companies NCSC, April 5th The National Cyber Security Centre (NCSC) published an advisory revealing that several ongoing attacks have been targeting mainly engineering and industrial control companies since March 2017. The attacks are involving the harvesting of credentials using strategic web compromises and spear-phishing. The advisory also refers to the Department of Homeland Security (DHS) and FBI joint Technical Alert (see below for more information). Link to the advisory
	Sentryo Provides Anomaly Detection Technology to Siemens to Address the Cybersecurity Challenges of industrial infrastructures Sentryo, April Siemens and Sentryo signed an agreement in which Siemens AG will provide Sentryo ICS CyberVision solution to its clients among Siemens products and services. Sentryo’s solution is an asset management and anomaly detection tool designed for Industrial Control Systems. Link to the press release [FR][PDF]
	ISA announces newly published ISA/IEC 62443-4-1-2018 security standard Automation.com, March 28th The international Society of Automation released the Part 4-1 of the ISA/IEC 62443 standard. This part tackles the Product Security Development Life-Cycle Requirements. “It defines a secure development life-cycle for developing and maintaining secure products.” This includes several concepts such as security by design, patch management and product end-of-life. Link to the article
	Schneider Electric Launches Cybersecurity Virtual Academy ISS Source, March 27th Schneider Electric launched the Cybersecurity Virtual Academy which is a website that provides several materials to raise the awareness of the cybersecurity risks in the industrial control systems. Link to the article
	Threat landscape for industrial automation systems in H2 2017 Kaspersky lab, March 26th Kaspersky has published a report on the threat landscape over the industrial control systems during the second semester of 2017. In the report, Kaspersky analyses the vulnerabilities discovered by the ICS-CERT and the ones identified by Kaspersky Lab ICS Cert. Here are some figures given in the report: 322 vulnerabilities were identified by ICS-CERT and more than 50% of them are impacting the energy sector; 3,3% of industrial automation system computers were attacked by cryptocurrency mining programs during the period from February 2017 to January 2018; 10,8% of all ICS systems were attacked by botnet agents during 2017. The mains sources of botnet agent attacks on ICS systems in 2017 were internet, removable media and email messages; The Kaspersky figures show also a certain decrease on the number of attacks on ICS systems between 2016 and 2017. This can be explained by the fact that more and more companies are training their employees and began implementing simple cybersecurity measures. Link to the report
	Draft NIST Special Publication 800-160 Volume 2, Systems Security Engineering: Cyber Resiliency Considerations for the Engineering of Trustworthy Secure Systems NIST, March 21st The National Institute of Standards and Technology (NIST) released a public draft of the NIST SP 800-160 Volume 2, Systems Security Engineering: Cyber Resiliency Considerations for the engineering of Trustworthy Secure Systems. This document aims to provide guidelines to organizations on how to apply cyber resiliency concepts during the engineering of systems. These guidelines may be applied on new systems, modification of systems, Critical infrastructure systems … Link to the release | Link to the document [PDF]
	Russian Government Cyber Activity Targeting Energy and Other Critical Infrastructure Sectors US-CERT, March 15th The Department of Homeland Security (DHS) and the Federal Bureau of Investigation (FBI) published a joint Technical Alert in which give details on how the Russian government targeted several American organizations operating in the energy, nuclear, water, commercial facilities aviation and critical manufacturing sectors (DHS and FBI have already warned about this threat in another alert published in October). The alert analyzed the attacks using the Lockheed Cyber Kill Chain (stage1:reconnaissance, stage 2: weaponization, stage 3: delivery, stage 4: exploitation, stage 5: installation, stage 6: command & control, stage 7: actions and objectives). The threat actors after gaining access to their victims information system, they conducted reconnaissance operations within the network. They mainly focused on identifying and browsing file servers. They viewed information and files regarding Industrial Control Systems (ICS) or Supervisory Control And Data Acquisition (SCADA) systems. Link to the alert
	‘Cyber event’ disrupts power in Mich. – but don’t blame hackers E&E News, March 8th An employee of a public utility that provides electricity in Michigan (Consumers Energy) inadvertently cut the electricity to about 15000 consumers. During an “internal testing” the employee overstepped his authority in a control center leading to the outage. The utility the event as a “cyber event” and reported it to the department of Energy even tought the outage had nothing to do with a malware or cyber attack. Since the event, the company adjusted the access controls. Link to the news
	A Qualitative View of 2017 Across vulnerabilities, threats, and lessons learned in hunting and incident response Dragos, March Dragos published 3 reports in which they reveal their findings and analysis regarding the industrial control systems vulnerabilities during 2017, the industrial threat landscape incident response and hunting lessons. Some of the results of these reports are the following:  “64% of 2017 ICS-related vulnerability patches don’t fully eliminate the risk because the components were insecure by design”; 5 activity groups are working on developing tools and malwares (as Crashoverride that attacked the Ukrainian electric grid in 2016); The main infection vectors are: unprotected interconnectivity with IT systems, removable media, unprotected interfacility connection and phishing. Link to the Vulnerabilities report [PDF] Link to the threat activity groups report [PDF] Link to the hunting and responding report [PDF]
	Siemens report: Mideast’s oil and gas sector needs readiness boost as cyber risk grows Siemens, March A recent report published by Siemens shows that the Middle East facing more and more attacks targeting Operational Technology (OT) (according to the report 30% of the attacks are targeting OT). The report gives the results of a survey on 176 individuals working in the Middle East who are responsible for overseeing the cybersecurity of their organisations. Here are some figures: “75% of organizations have suffered at least one security compromise that resulted in the loss of confidential information or disruption to operations in the OT environment over the past 12 months”; “68% of respondents say the top cyber security threat is the negligent of careless insider”; “31% of respondents say their organization’s industrial control systems” protection and security are adequate”. Link to the press release
	NERC Full Notice of Penalty regarding Unidentified Registered Entity NERC, February 28th The North American Electric Reliability Corporation (NERC) files a Notice of Penalty of two million seven hundred thousand dollars ($ 2,700,000), in accordance with the Federal Energy Regulatory Commission (FERC), regarding noncompliance by an Unidentified Registered Entity (URE). Indeed, a third-party URE contractor failed to comply with the information protection program and copied very sensitive data, including records associated with Critical Computer Assets (CCA), from the URE environment on its own unsecured environment. While the data was on the contractor’s network, a subset of data was available online without the need to enter a username or password for a total of 70 days. This exposed information increases the risk of a malicious attacker gaining both physical and remote access to URE’s systems and access to internal CCAs. Link to the article

>>Main ICS vulnerabilities

>>Upcoming ICS events

Jun. 30-1	Nuit du Hack Paris, France
Jun. 18	IEEE Workshop on Smart Industries (IEEE SIW) Taormina, Italy
Jun. 15	European Maritime Cyber Risk Management Summit London, UK
May. 22-23	Annual Nuclear Industrial Control Cybersecurity and Resilience Conference (ICCS) Warrington, UK
May. 3-4	Global Cyber Security in Healthcare & Pharma Summit London, UK

Cet article Industrial Control Systems Cybersecurity News #2 – Radiology of the cybersecurity level of the healthcare sector est apparu en premier sur RiskInsight.

Industrial Control Systems (ICS) are complex systems that aim to control industrial processes. ICS can be found in several sectors: energy, nuclear, transport, chemistry… In brief these systems control many of the critical productive assets of companies or states making their compromise by adversaries a high risk on the environment or people’s lives.

Thus, the cybersecurity of these systems is crucial. Moreover, securing these systems may be challenging due to their complexity (mainly because ICS are a mix of technologies and their lifetime is longer than usual information systems’).

In order to meet our clients’ needs and answer to their future concerns, Wavestone has been conducting an ICS cybersecurity watch where every recent study, attack or incident and report regarding the security of Industrial Control Systems are studied. In 2017, more than 80 news were reported from which we can retrieve a lot of teachings.

So, what did we notice this year?

First of all, ICS had its share of attacks. However, this year’s attacks, more than the other years’, had an unusual worldwide impact. Indeed, while ICS attacks were usually localized on a device (for instance on health devices), factory (for example a cryptomining malware found in a water utility – for more information see below) or a region (Dallas emergency sirens ignition in April 2017), 2017’s attacks started locally and spread quickly impacting several production lines in the world (WannaCry and NotPetya).

During 2017, many attacks have been reported in the news. Moreover, we noticed that several national agencies, governments or political figures alerted on ongoing attacks or attempts on critical infrastructure. The sector that was the most targeted seems to be the Energy sector. Indeed, several news were reported from Turkey (in January), USA (in March, July), Baltic States (in May), UK (in July) and Ireland (in July) showing that this sector was a privileged target by hackers (state sponsored or not).

The energy sector wasn’t the only hot topic of the year, as a matter of fact, autonomous cars cybersecurity hit many times the headlines (even if that topic may or may not be considered as related to industrial control systems). This is mainly due to the fact that cars’ cybersecurity is a new market. Therefore, cybersecurity experts and researchers try to find vulnerabilities and exploits (for example vulnerability found in airbag control units), while car manufacturers launch partnerships and initiatives showing that cybersecurity is now one of their main concerns (for example GM invited ethical hackers to try and hack its cars).

Finally, the ICS cybersecurity market tends to grow as demonstrated by the several fundraisings and partnerships signed during this year. In a broader perspective, we can notice three kinds of actors in the ICS cybersecurity market:

• ICS cybersecurity companies: usually small-sized companies or start-ups. They are pure-players that develop and put in the market ICS-dedicated solutions (Sentryo, CyberX, Nozomi …);
• ICS vendors: we noticed last year, some vendors that conceive ICS launched partnerships with ICS cybersecurity companies to improve their systems’ security (for example Siemens-PAS partnership in September, Schneider-Claroty partnership in August);
• IT security companies: these companies (well known in the IT world) tailor their solutions for industrial context. They show a growing interest for ICS by publishing reports and attack analysis (for example Kaspersky, McAfee).*

So, what is coming next?

It may be easy to say that the ICS cybersecurity will still (unfortunately) hit the headlines. Especially with alerts of attacks targeting life threatening system such as the safety instrumented systems controllers. But, we may see more and more news on specific sectors such as maritime, transport, health… that weren’t somehow as exposed in the media as the energy or nuclear sector. The ICS cybersecurity market may continue to grow especially with partnerships and acquisitions. Industrial Control Systems will continue to face new threats, challenges and changes.

>>Latest news:

	CyberX raises $18 million in series B funding to combat rising threats to IIoT and critical infrastructure, bringing total funding to $30 million (CyberX, February 27th) CyberX announced that the company raised $18 million dollars to develop threat detection in the Industrial Internet of Things (IIoT) and critical infrastructures. The company develops a threat monitoring and risk mitigation platform that includes ICS-specific threat intelligence. Link to the press release
	Fun with Modbus 0x5A (Security Insider, February 9th) During the last edition of Defcon in Las Vegas, Wavestone presented its latest study regarding the ModBus protocol cybersecurity and specifically the function 90. An attacker may thanks to this function start, stop a controller or force it to send a determined output value,  Link to the article
	ICS detection challenge results (Dale Peterson, February 7th) At the S4x18 in January, took place the ICS Detection Challenge. The 4 companies that completed the challenge are: Claroty, Gravwell, Nozomi Networks and Security Matters. The first part of the challenge consists on evaluating the ICS Detection class of 3 products which are: Claroty, Nozomi Networks and Security Matters. It was won by Claroty over Nozomi Networks and Security Matters. The competitors’ products had to detect cyber-attacks and incidents occurring on an oil&gas company. Link to the results The second part which consists in the asset detection phase was also won by Claroty even though Nozomi provided the most details in their asset inventory. Link to the results
	Water utility in Europe hit by cryptocurrency malware mining attack (eWeek, February 7th) The security firm Radiflow discovered a cryptocurrency mining malware in the network of a water service provider in Europe. The malware was downloaded from a malicious advertising site infecting the Human Machine Interface and then spread to the SCADA network that was still running Microsoft Windows XP OS. The malware degraded the system performance. Tough the degradation wasn’t noticed by the operators. Link to the article
	Ukraine power distributor plans cyber defense system for $20 million (Reuters, February 6th) Ukraine’s state-run power distributor Ukrenergo, which was a target for cyber-attacks in the past two years (December 2016 and December 2017), will invest up to $20 million in a new cyber defense system. The acting head of Ukrainian state power distributor Ukrenergo, told that the company and international consultants had identified about 20 threats that would be eliminated with the new system. The main goal of this system is to make “physically impossible for external threats to affect the Ukrainian energy system”. Link to the article
	Increasing number of industrial systems accessible from web (study Security Week, February 2nd) According to a new report published by Positive Technologies, the number of industrial control systems (ICS) accessible from the Internet has increased significantly during the past year. Most of vulnerabilities of these systems could be exploited remotely without needing to obtain any privileges in advance. The most common types of vulnerabilities were remote code execution (24%), information disclosure (17%), and buffer overflows (12%).Most of these systems are accessible via HTTP, followed by the Fox building automation protocol associated with Honeywell’s Niagara framework, Ethernet/IP, BACnet, and the Lantronix discovery protocol. Link to the article | Link to the report [PDF]
	Flaws in gas station software let hackers change prices, steal fuel, erase evidence (Motherboard, January 31st) Security researchers were able to connect to a web interface that manages gas station thanks to Shodan (search engine of connected devices). After using the default admin login and password, and then a hardcoded username and password, the researchers were able to shut down fuel pumps, hijack credit card payments, and steal card numbers. Link to the article
	Government warns critical industry firms to prepare for cyberattacks (Sky news, January 29th) All companies which are involved in critical industry and essential services, such as energy, transport, water, health and digital infrastructure, have been warned by the British government that they face sanctions if they do not include cybersecurity rules in their systems.The fines come as the government implements the Network and Information Systems (NIS) Directive, which would cover events such as the WannaCry attack. Link to the article
	Gemalto licensing tool exposes ICS, corporate systems to attacks (Security week, January 22nd) Kaspersky Lab researchers found 14 vulnerabilities in Gemalto Sentinel LDK (software) and the associated USB Dongle (SafeNet). The USB dongle is used to activate the software. When connected, drivers are installed and the port 1947 is added to the list of exceptions in the Windows firewall. This port can be exploited to identify remotely accessible devices. Link to the article
	SamSam ransomware hits hospitals, city councils, ICS firms (Bleeping Computer, January 19th) Samsam ransomware hit several hospitals, city councils and an ICS firm. Hancock Health admitted paying the ransom ($55.000) even though they had backups. The Samsam ransomware spread by brute forcing RDP connections. Link to the article
	Industrial systems scrambling to catch up with Meltdown, Spectre (The Register, January 18th) Meltdown and Spectre vulnerabilities also had an impact on industrial control systems. Some vendors decided to publicly communicate about their vulnerable products (OSISoft for example), other vendors like Emerson and General electric keep the information only for their customers and finally some vendors are still investigating if their products are vulnerable to Meltdown and Spectre. Link to the article For more information on Meltdown and Spectre vulnerabilities, you can read this post by Wavestone on Security Insider [French]
	Researchers find 147 vulnerabilities in 34 SCADA mobile applications (SC Magazine, January 11th) IoActive and Embedi researchers found 147 vulnerabilities in 34 mobile applications used in tandem with Supervisory Control and Data Acquisition (SCADA) systems. The top vulnerabilities were: code tampering flaws, insecure authorization, insecure data storage… This security weaknesses could allow an attacker to compromise industrial network infrastructure by exploiting the vulnerable applications. Link to the article
	Industrial Cybersecurity Firm Nozomi Networks Raises $15 Million (Security Week, January 10th) Nozomi is an industrial cybersecurity firm that has recently raised $23.8 million. Nozomi’s offering which is “SCADAguardian”, consists on using machine learning and behavioral analysis to detect zero-day attacks in real-time. This technology allows rapid response to alerts by ICS incident alerting and notification systems. The company said the additional funding will be used to support worldwide expansion of marketing, sales, support and product innovation. Link to the article