This figure reveals a profound shift: backups, often considered the last resort, have now become prime targets for attackers. When faced with a major cyberattack, traditional continuity plans are no longer sufficient. Indeed, they fall short in industrial environments, particularly given the nature of the stakes involved: physical safety, environmental impact, continuous production, and more.

This is why the most advanced organizations are now building dedicated OT cyber-resilience programs, designed to manage crises in the face of major disruptions or incidents. That aim to ensure the continuity of essential operations and restore compromised assets.

The NIS2 Directive — and particularly ANSSI’s RECYF framework — supports this effort by introducing clear cyber-resilience obligations for essential and important entities.

Where to start, what obstacles to anticipate, and how to build OT resilience that meets NIS2 requirements?

NIS 2 and Industrial Resilience: Requirements and Current State

What NIS 2 Concretely Requires

The growing integration of IT into industrial processes — MES, ERP systems connected to production lines; the gradual shift away from paper-based processes — has profoundly changed the operational reality of manufacturing plants. Dependencies are numerous, often poorly mapped, and an IT failure can bring OT to a halt even when the physical equipment remains fully functional. In this regard, strengthening the cyber resilience of industrial environments has become a priority .

The NIS 2 directive significantly broadens the scope of entities subject to cybersecurity obligations. Two objectives are crucial in terms of resilience:

Industrial State of Play

While industrial organizations have gradually invested in securing their OT environments, maturity around continuity and recovery remains insufficient to meet NIS 2 requirements. Several gaps are observed systematically:

•  Gaps in the knowledge of assets and their criticality
  • Asset mapping that is often not formalised or incomplete
  • BIAs are absent or only partially completed
• Existing business BCPs are designed for physical or traditional IT scenarios, but not for OT cyber challenges
• Continuity and recovery capabilities are not tested: organisations limit themselves to unit tests or isolated VM restorations, never covering a complete production line or end-to-end scenario. Several factors explain this situation:

Without the necessary maturity on these topics, a cyber incident can result in weeks of downtime

Building OT Resilience for NIS 2: A Practical Roadmap

Foundations and Prerequisites     

Before building a recovery, plan or testing anything, the groundwork must be laid. Including knowing what to protect, how to hold up during an incident, and what to back up.

Which stakeholders to involve from the start?

A cyber-resilience program driven solely by Cyber or IT teams risks failing to reflect operational realities and address the true business stakes: without the involvement and buy-in of operators, the initiative will struggle to move forward. This requires an evangelization phase, concretely explaining what an incident costs their operations, and identifying the right stakeholders in each department from the outset.

Which business perimeters to prioritise?

The goal of cyber-resilience is not to produce an exhaustive inventory of the industrial asset base. It is to identify the assets that underpin critical business processes. The starting point is to establish a BCP at the global level, followed by a BIA at the site level, which will define the RTO and RPO for each critical process.

Asset collection relies on a hybrid approach:

• Operational interviews with field teams
• Analysis of architecture documents and configurations to identify additional dependencies

Network probes may seem like an obvious choice, but they only detect assets that are actively generating traffic. Any equipment that is not communicating at a given moment will simply disappear from the mapping. In OT environments, a significant number of devices are configured once and then operate autonomously, which severely limits their network visibility. Furthermore, some systems are entirely standalone and emit no traffic at all — even though they may be critical to operations. Relying solely on probes therefore provides a partial and potentially misleading view of the environment, with a real risk of overlooking essential assets.

What data to backup and how?

Asset mapping makes it possible to catalogue and prioritise the systems that need to be protected based on their criticality, as validated with business teams. For each asset, the minimum backup content and backup frequency are then defined:Several principles then structure the backup security strategy:

• Redundancy, encryption, and immutability of backups
• Air-gapping for the most sensitive environments
• Differentiated retention policies by asset type
• Contractual clauses governing backup obligations for third parties

Backup infrastructure is not merely technical storage systems: they are themselves sensitive targets and must be treated as critical systems, with the appropriate level of protection.

How to ensure continuity during an incident?

The first step of the BCP is to identify the crisis scenarios that need to be addressed, as these determine which stakeholders to involve, which procedures to define, and which operating modes to adopt. This work is carried out jointly with the HSE, business, cybersecurity, and risk management teams.

For each critical process identified, the following must then be defined in collaboration with the production, maintenance, and quality teams:

Validation and Recovery

How to validate that recovery works?

An untested DRP is a theorical DRP.

Tests can be conducted in the following ways to limit the impact on production:

• On a dedicated global test infrastructure, shared across sites,
• On a test line,
• During maintenance windows,
• Using digital twins.

These tests should be validated at least once a year.

Progression is gradual:

Each test is documented: actual RTO and RPO measured, comparison against theoretical targets, gaps identified, and corrective actions planned.

RTO/RPO objectives may not be realistic in the context of a major cyber crisis. They should therefore not act as a blocking factor for conducting tests or for validating cyber-resilience principles under NIS2.

How to rebuild after an incident?

The DRP defines how to restart critical systems following a disaster. It covers several scenarios: hardware failure, ransomware, and OT network loss.

For each scenario, it is necessary to:

• Define the restart sequencing based on dependencies between systems
• Document the escalation and decision-making chain
• Clearly define third-party involvement: intervention conditions, coordination modalities, and prerequisite security requirements (ransomware eradication, controlled environment such as a “clean room”, gradual recovery with network segmentation)

Two recovery logics must be distinguished: loss of availability (switching to backup resources) and loss of integrity (complete reconstruction from backups). The procedures are not the same and must be addressed separately.

From Asset Resilience to Crisis Management

What we have described here constitutes the minimum foundation for initiating a recovery approach in an OT environment. But NIS 2 requires going further as the entire information system is concerned, and the question is no longer purely technical; it calls for a structured program, managed over time, capable of demonstrating compliance and asset resilience.

This means deploying this approach pragmatically, taking into account cyber risks, regulatory constraints, and available resources. It also means not approaching OT resilience as a one-off project: cyber-resilience must be embedded by design, with tracked workstreams, documented evidence, and business teams engaged over the long term.

Finally, the market today offers solutions dedicated to OT resilience. Actively monitoring this space can prove valuable in identifying the right tools.

Moreover, resilience does not stop at technical recovery, it also encompasses crisis management: Enabling a paradigm shift in cyber crisis management preparedness – RiskInsight

Glossary

Cet article Industrial Cyber-Resilience: How to Get Started with NIS 2 Compliance est apparu en premier sur RiskInsight.

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.

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.

This third article focuses on a key question: how do you measure the efficiency of your OT detection? 

From compliance to efficiency: a KPI paradigm shift 

KPI stands for Key Performance Indicator. However, we tend to create KPIs to monitor progress against our plans, not real performance. While useful, monitoring only deployment or coverage (number of sites connected to the SOC, EDR deployment on OT machines, number of probes registered to the management console) tells you very little about the actual ability of your SOC to detect a real attacker. 

So, how confident are you in your detection tools, use cases, and processes? The only way to be sure is simple: test them. And the best way to test them is through Purple Team exercises. 

What is Purple Teaming in OT? 

A Purple Team exercise is a collaborative mission between the Red Team (attackers) and the Blue Team (defenders). Unlike a traditional Red Team assessment, where the defenders are kept in the dark and evaluated afterward, a Purple Team exercise is an iterative, joint effort. 

This collaborative approach allows both teams to: 

• Share assumptions about the OT environment 
• Validate detection logic in real time 
• Understand blind spots 
• Improve playbooks and detection pipelines 
• Align everyone around a realistic threat model 

Performing a Purple Team Exercise 

A Purple Team operation can be summarized in three main phases: 

1. Preparation

The preparation phase is often the most challenging, especially in OT environments, where safety, process continuity, and vendor constraints must be considered. 

Depending on the maturity of the organization, preparation can range from basic to highly sophisticated: 

• Unit Tests 
  Small, isolated tests of specific detection rules (e.g., “Detect Modbus function code 90”). 
• Feared Scenario-based Testing 
  Build scenarios around the organization’s crown jewels and failure modes (e.g., “Unauthorized remote program upload on a PLC controlling a critical process”). 
• CTI-Infused Testing 
  Integrate threat intelligence: test techniques used by real OT-focused attackers (e.g. TTPs from Volt Typhoon, Sandworm, Xenotime, or ransomware groups targeting industrial environments). 

To structure the preparation phase, two elements are essential: 

• A good knowledge of your OT environment 
  Planning an exercise that will be relevant to both the business risks & OT detection without impacting the process requires a deep knowledge of the site and its automation. 
• Mapping to the MITRE ATT&CK for ICS matrix 
  Mapping your tests to the ATT&CK matrix allows you to have a common language with the detection teams. This allows you to select relevant techniques, avoid blind spots, and ensure coverage across multiple layers: OT workstations, PLCs, network interactions, engineering actions… 

2. D-day (Execution)

Execution is performed jointly: 

• The Red Team launches controlled and authorized actions 
• The Blue Team monitors detections in real time 
• Both teams adjust, document, and validate findings as the exercise unfolds 

Depending on the scope and complexity of the tests, the Purple Team operation can last from a few hours to a few days. 

Ensuring Reproducibility with Caldera 

To ensure repeatability and consistency across Purple Team exercises, automation becomes key.  Caldera, an open-source Breach & Attack Simulation (BAS) framework developed by MITRE, is a powerful tool for this. 

As a former pentester, I’ve always disliked the term “automated pentest”—but BAS tools are the closest thing we have to repeatable, safe attack execution. 

Why use Caldera instead of performing tests manually? 

Caldera enables you to: 

• Prepare and validate a controlled list of tests on a controlled list of assets 
• Ensure only authorized actions are executed 
• Guarantee reproducibility across environments 
• Replay the exact same actions to measure improvements after configuration changes 

Some OT-specific plugins already exist in the Caldera-OT module, supporting Modbus, Profinet, DNP3, and others. 

Recently, Wavestone released two additional OT plugins: 

• Siemens S7 protocol support 
• OPC-UA communications actions 

Caldera in a nutshell 

Caldera usage relies on: 

• Abilities: atomic technical actions (e.g., reading coils, writing tags, scanning a PLC) 
• Adversaries: collections of abilities that form a scenario 
• Operations: real-time execution of those adversaries against a target 

Fact sources: parameters provided for an operation; you can launch the same operations against different environments by just changing the fact source. 

The following video (French with English subtitles) will walk you through a demonstration of Caldera on our small ICS demo setup: 

3. Debriefing

The debrief is where most of the value is extracted. The following types of Key Performance Indicators might be used: 

• Detection Coverage – what percentage of executed stimuli were detected? 
• Alert Quality – were alerts actionable, precise, and intelligible? 
• Reaction Time – how long before an alert is raised and acknowledged? 
• Playbook Efficiency – were the right actions taken in the expected time frame? 

These might phase results in: 

• Updated detection rules 
• Improved SIEM/SOC playbooks 
• Better monitoring architecture 
• Training material for analysts and engineers 

Start Testing Now! 

Purple Team testing brings value immediately, no matter what your current maturity level is: 

• It validates your tools in real-world conditions 
• It trains your SOC and OT teams 
• It reveals blind spots early in the program 
• It provides quantitative KPIs to drive detection improvements 

And yes, it is possible, in most production environments, under the following conditions: 

• Strictly controlled scope 
• Vendor-approved actions 
• No disruptive functions executed 
• Involvement of operations and safety teams 
• Continuous monitoring of system behavior during testing 

In short: start small, stay safe, and iterate. 

Do not wait for your OT security program to be “finished” before you start testing its effectiveness! 

Cet article Purple Teaming for OT:  How to switch from a compliance to a performance mindset? 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.

What is SBOM, and in what context does it come into play?

 The SBOM (Software Bill of Materials) is a formal inventory, typically in JSON, XML, or plain text format, designed to be machine-readable. It contains detailed information about the software components of a system, including their dependencies, attributes, and hierarchical relationships. The primary goal of an SBOM is to provide a comprehensive and up-to-date view of all the software elements composing an application or system (source: NTIA-Software-Bill-Of-Materials)

Like a physical product, software is a complex assembly of various elements. It includes internally developed code, third-party components (open-source libraries or modules subject to different licenses), as well as all the tools necessary for assembling the final product.

However, with each new vulnerability discovered by researchers or exploited by hackers, suppliers and buyers are faced with a crucial question: where do potential critical vulnerabilities lie within their product?

Today, Wavestone’s analysis formally attests that the SBOM is undeniably an essential element to address this issue.

Generation methods

A comprehensive technical analysis of tools available on the market has revealed the methods for generating Software Bill of Materials (SBOMs).

Three main sources emerge for creating a SBOM:

• Binary Code (compiled)
• Project Source Code
• Image Container, generated by platforms such as Docker.

These three sources can produce a file compliant with established standards, including SPDX and CycloneDX. However, it is essential to note that not all tools support these three inputs uniformly.

The technical challenge lies in decompiling binary code, which can sometimes impede its integration. In such cases, the search for specific predefined indicators within the code proves to be an effective method for identifying most of hierarchical interdependencies in an appropriate format.

Types of Inputs for Generating an SBOM

Despite these code extraction and analysis techniques, data completeness is not guaranteed, and additional verification must be considered.

Facilitated generation but an exploitation that remains to be determined, posing numerous unanswered questions

 The creation of an SBOM has been significantly simplified due to the presence of major players specialized in the market, such as Dependency Track, Adolus, and Fossa, to name a few. Additionally, well-established Software Composition Analysis (SCA) tools within our clients’ development teams now offer the capability to generate and read an SBOM.

Generating it is no longer a major challenge today, thanks to the implementation of the standards mentioned earlier. They facilitate automated SBOM generation by providing clear guidelines on how information about components should be structured and presented. Moreover, many software development and supply chain management tools now natively integrate SBOM creation.

However, the systems designed to analyze SBOMs are not yet fully mature. Clients receiving these inventories often face questions about how to use and share them with other parties. Furthermore, to this technical issue, organizational challenges are added, as the framework for use between organizations has not yet been clearly defined.

Nevertheless, stakeholders are actively working to establish a secure integration architecture for these SBOMs within their CI/CD pipelines.

Currently, obtaining a reliable SBOM from a third party remains a challenge. Concerns about exchange and sharing arise as soon as this topic is addressed. The diversity of contracts with suppliers, who seek to protect their intellectual property, and the challenge of centralization pose hurdles to the content of such inventories. Each inventory is developed heterogeneously, without follow-up or a uniform regulatory framework imposed. From a technical standpoint, each entity has the freedom to report the information of their choice.

As of now, we observe that pioneers in the field are opting for internal generation of their SBOMs, including for third-party software. This approach offers greater control over the quality and specificity of data, underscoring the need for more detailed regulation and stricter standards to ensure the reliability of software inventory exchanges.

The SBOM Integrated into the Core of Your Software Processes

All these gaps have prompted the design of an optimal, theoretically state-of-the-art process to integrate an SBOM into a CI/CD pipeline, a process that can be broken down into a few steps.

1. Creation of an SBOM Generation and Collection Space, Automating the collection of these data to ensure their accuracy and completeness.
2. Storage of SBOMs in a Repository, Configuring a centralized repository to store all generated SBOMs. This could be a version control repository or a suitable data storage system.
3. Distribution of an SBOM Package upon Client Request, Ensuring that SBOMs are easily accessible, and clients can securely retrieve them on demand.

                                   Projection on the Integration of an SBOM within a Software Supply Chain

This theoretical outlook paves the way for the automation of the process of generating, storing, and disseminating inventories and vulnerability reports.

This will provide stakeholders with the ability to:

• Receive real-time SBOMs and vulnerability reports.
• Authenticate the legitimacy of received artifacts (image containers, documents, etc.).
• Establish trust and validation through transparency at the heart of the software production process.

A Bright Future for SBOM?

 Political entities are becoming aware of the level of unpreparedness of their infrastructures in the face of increasing cyber threats. In this context, SBOM is increasingly seen as an effective means to enhance responsiveness to vulnerabilities that could simultaneously affect many companies.

Even though the market is not quite ready for a widespread transition to the use of this solution, it is common for regulation, even if it may seem arbitrary, to profoundly influence the trajectory in a new direction.

It is likely that Europe will eventually converge towards the regulation established in the United States, even though it still seems to be in a preliminary and incomplete stage, especially concerning the mechanisms for sharing and exchanging these inventories.

In the current context, stakeholders are compelled to reassess their priority criteria. It will be important to have data on software composition, the origin of its components, their source, known vulnerabilities, and to trust the production and quality control process.

However, it is necessary to bring back to the agenda the series of challenges they generally face:

• Incomplete or lacking data, the absence of comprehensive data on software composition can make risk assessment difficult.
• Ad hoc approaches for data sharing, non-standardized methods and improvised approaches for information sharing can make communication inefficient and unreliable.
• Additional costs for data collection and maintenance, Collecting, verifying, and updating information on software composition can incur additional costs.
• Lack of standardization, the lack of standards in collecting and sharing data makes it difficult to compare and analyze information among different stakeholders.
• Governance and data privacy, managing sensitive data on software composition raises concerns about its confidentiality, integrity, and availability.

In conclusion, the SBOM serves as a vital ally for the security of your products, enabling transparency, risk reduction, and informed decision-making throughout the software development lifecycle.

Cet article Why is SBOM considered a vital ally for the security of your products? est apparu en premier sur RiskInsight.

Azure, in recent years, has been gaining a foothold in this sector, as Gartner has pointed out, ranking them among the visionary leaders of Industrial IoT (IIoT) platforms [1] due to its capabilities, and its almost complete coverage of all use cases and industries.

The IoT, by nature often widely exposed, even on the Internet, can be the target of attacks. It is therefore essential to put in place security mechanisms, and to apply best practices to improve the security level of the platform and the objects that connect to it, which we will explore in this article.

Before moving on to specific recommendations for protecting your IoT devices and data, let’s look at how the various Azure IoT services can be used together to create secure IoT solutions.

Presentation of the Azure IoT offer

Microsoft Azure IoT is an end-to-end platform for connectivity, analysis and visualization of data from IoT devices. It also offers interconnection with other standard Azure services such as Azure Machine Learning and Azure SQL Database.

Azure IoT offers two solution ecosystems to its customers:

• Azure IoT Central is a fully managed aPaaS, Platform as a Service application that simplifies the creation of IoT solutions. This service is responsible for connecting, managing and operating fleets of devices, and provides a management user interface. Azure IoT Central is an aggregate of different Azure IoT services such as Azure IoT Hub or Azure IoT Hub Device Provisioning Service (DPS).

Azure IoT Central offers application models according to several business domains: Retail, Health, Energy, Industry, etc., and aims at a “turnkey” implementation.  

• A customised ecosystem thanks to the various Azure PaaS (Platform as a Service) services. In this ecosystem, two services; Azure IoT Hub and Azure Digital Twins are the foundations of an IoT solution. We have also combined them with Azure Device Provisioning and Azure Device Update for optimal coverage of cyber security needs.

These two ecosystems enable Azure to address all types of IoT and IIoT needs:

• Azure IoT Central offers a complete service if you want to quickly develop a low-complexity application thanks to its application template catalogue.
• If you want a custom solution, or with features not supported by Azure IoT Central: opt for an ecosystem based on Azure IoT Hub.

Now that we have a good understanding of the Azure IoT ecosystems, it is important to focus on securing these ecosystems. How can we effectively protect IoT devices and data when using Azure IoT services? This is what we will explore in the following sections.

Preamble: the Azure CLI tool

In order to manage Azure resources, Microsoft provides several tools, most of which can be used in CLI (Command Line Interface). The tool offering the most functionality for management is Azure CLI.

This tool, available for Windows and UNIX operating systems, allows a user who is a member of an Azure environment to manage and obtain information about Azure resources. It should be noted that the range of possibilities of this tool varies according to the rights that the user has over the resources in question.

To install it, Microsoft provides a dedicated page explaining the steps for any type of environment.

In order to use it, all you must do is connect to an Azure user account via the chosen command interface (PowerShell or Bash), then enter the desired commands. Once the use of this tool is finished, a disconnection of the account is recommended.

A typical use of this tool is shown below:

The documentation of this tool, presenting and explaining all the possible commands, is available at this address.

This tool will be used later in the example of technical manipulations.

1st security vector: authentication of objects

Device authentication is crucial for an Azure infrastructure as it ensures that only authorised devices can access cloud resources. Azure IoT services support two main means of authentication for IoT devices:

• A SAS Token (Shared Access Signature) is a string of characters used to authenticate devices and services. An SAP token has the following structure:

This type of authentication has a defined validity period and permissions, which are assigned based on an access policy, on a given perimeter. The signature, on the other hand, is a crucial element because it is responsible for guaranteeing the security of communications between the object and Azure services, but also for proving the identity of the device. This signature is generated from a secret that must be specific to each device.

• An X.509 certificate [2] is a digital certificate allowing strong authentication of the object. It contains information about the entity issuing the certificate, the validity period of the certificate and the identity of the subject (e.g. the object). One of the strengths of certificates is the ability to create chains of certificates, and thus create trust relationships:

X.509 certificates offer a higher level of security, assuming a state-of-the-art cryptographic algorithm, as they allow trust relationships to be represented. However, the management and use of certificates can involve additional complexity for an IoT project.

In order to force the use of X.509 certificates to authenticate connected objects, it is possible to prohibit SAS tokens for an IoT Hub. Indeed, Azure IoT Hubs have three properties related to the use or not of SAS tokens: disableLocalAuth, disableDeviceSAS and disableModuleSAS. Therefore, the best practice associated with disabling SAS tokens is to set these three parameters to True. This can be done using the Azure CLI tool:

Checking the values of these same parameters can also be done using the Azure CLI:

In the example response below, the disableDeviceSAS property has been set correctly, but the other two have not.

The Azure portal also allows you to perform this verification:

The choice of authentication method for Azure IoT will depend on the security requirements of your solution. If you need strong security and have the infrastructure to manage certificates, then X.509 certificate authentication is a good option. However, if you are looking for a solution that is simple to manage and use, the SAS token may be more suitable for your needs.

2nd security vector: RBAC and alerts

The assignment of roles on your Azure IoT infrastructure must be thoughtful and defined according to the needs of the users. A precise definition of roles and permissions makes it possible to limit access to resources and to the various functionalities available on the platform. The various Azure IoT services provide a multitude of pre-configured roles that can be adapted to your needs and your organisation. Secondly, applying the principle of least privilege, and limiting the number of accounts with important privileges, allows you to improve the security level of your Azure IoT infrastructure.

Azure CLI allows you to list the users with rights to the desired Azure IoT resource and their associated roles. The following command allows you to perform this action

It is possible to use string selectors (Select-String for PowerShell, grep for Bash) to retrieve only the desired information.

In the example below, names, types and roles were the only items retrieved using Select-String:

The Azure built-in roles feature is available on this page.

Configuring alerts based on the metrics of your Azure IoT services is another tool to consider. Alerts can be configured to detect suspicious behaviour or anomalies, allowing for rapid investigation of your infrastructure. Azure provides its customers with a large collection of signals to define alert conditions. It is also possible to define custom alert signals via the query language used by Azure Log Analytics.

The Azure Portal is the easiest way to set up alerts based on the data collected by the IoT Hub. For example, to define a log alert rule, you need to:

1. Go to the management page of the desired IoT Hub;
2. Go to the Logs sub-category of the Monitoring category;
3. Choose a rule using the Azure Log Analytics language;
4. Add an alert rule related to this query;
5. Choose the operator, unit, threshold value, check recurrence and time period for the rule

These actions are summarised in the screenshots below:

It will then be sufficient to choose an action group linked to a type of action (sending an email, SMS, etc.).

The example given will lead to an action if the number of failed connections of connected objects to the IoT Hub concerned exceeds 10 failures in 10 minutes or less.

A detailed guide in the form of a tutorial is available on the Azure documentation. Note that this service is available at an additional cost.

3rd vector of security: the service itself

Finally, setting up proper configuration of Azure IoT services is a key element in improving the platform’s cyber maturity level. This includes options such as routing rules or setting the minimum version of TLS used by devices to connect to Azure IoT Hub.

Routing rules are used to redirect messages from IoT devices to an endpoint (storage, services, database, etc.) and are configurable by routing requests. It is recommended to filter incoming messages, via routing requests, to increase the security of your IoT solution.

Checking the minimum TLS version accepted can be done using the Azure CLI: indeed, an IoT Hub has the minTlsVersion attribute to check this property. This check is performed using the following command:

Si cette commande ne retourne rien, ou retourne une valeur inférieure à 1.2, alors la configuration n’est pas satisfaisante.

Le portail d’Azure permet également d’effectuer cette vérification

If this command returns nothing, or returns a value less than 1.2, then the configuration is not satisfactory.

The Azure portal also allows you to perform this check:

En synthèse

Security is a major issue for IoT projects: Microsoft, with its Azure IoT product, provides an IoT platform that meets the majority of IoT needs in a secure manner, provided that it is configured correctly. In this article, we have discussed recommendations for improving the security of your Azure IoT infrastructure.

It is important to keep in mind that other attack vectors exist, such as hardware and software vulnerabilities and the networks used by IoT devices.  Securing an IoT infrastructure is a complex challenge that requires an end-to-end approach.

With the help of Marius ANDRE

[1] “Magic Quadrant for Global Industrial IoT Platforms”

https://www.gartner.com/doc/reprints?id=1-2BQFX3BJ&ct=221116&st=sb

[2] “Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile”

https://www.rfc-editor.org/rfc/rfc5280

Cet article Improving the security of your IoT infrastructure: configuration tips and best practices on Azure IoT est apparu en premier sur RiskInsight.

In this example, we will assume that you are a coffee machine manufacturer. Your current project is to build a connected coffee machine for your corporate customers. You have identified multiple use cases for this IoT machine. For instance, it automatically orders new coffee capsules when the stock falls below a certain threshold. A second option would be that the coffee machine, sends automatic alerts to your servers when maintenance management such as cleaning, repairs, etc. is needed. Finally, it offers your clients functionalities for monitoring consumption.

How can you choose the right network for your needs? What questions should you ask yourself? How do you make a good choice while considering the overall security of your system?

First Step – Define your business requirements and perform a risk analysis

First, you must identify the requirements for your IoT network which are twofold: business and security requirements. We characterize these requirements with levels 0 to 3, 0 being the lowest and 3 being the highest level.

For the business requirements, you must answer questions such as:

1. How far should the object’s signal reach?
2. How much bandwidth do you need?
3. What is the autonomy of your object?

In our example, we assume that your connected coffee machines will be distributed to corporate customers operating over a large geographical area (i.e. over 100 km radius). Therefore, you will need a wide coverage to enable your customers’ widespread machines to communicate with your Information System.

Two business cases are outlined here: If your customer agrees to connect your machine to its existing local network, you will then only need a short-range wireless network between the machine and the internet router. If they refuse to do so, you will then need to set up a long-range network as you will deploy your service and machines over a wide area.

For the bandwidth, a small/short amount will be needed as it solely requires to be able to send small data packages a few times a day at most (capsule orders, alerts, general status, …).

In regard to energy consumption, a coffee machine is traditionally connected to a power supply to perform its tasks; henceforth, power does not constitute an issue in terms of IOT, i.e. the object autonomy is therefore not constraint. There is no energy consumption requirement per se as it is already covered by the coffee machine’s connection to the power grid.

We summarize the levels for business requirements as follows:

• Range (R) = 3 or 1
• Bandwidth (B) = 1
• Energy consumption (E) = 0

Having defined your business requirements, a risk analysis must be conducted to formulate the security requirements of your project for availability, integrity, confidentiality, and traceability purposes.

A loss of availability would occur in the event of a dysfunction on the connected coffee machine that would render it unusable for a customer. A loss of access to the network or unavailability of backend servers should never result in the machine being unavailable: it must remain working off-network. However, if a dysfunction of the machine occurs, we assume that you would want it to be reported back as quickly as possible through the network in order for maintenance actions to be triggered.

How long can this last? The answer would be several hours rather than several days, as we wouldn’t want to deprive employees from their coffee breaks! Therefore, 4 to 24 hours is an acceptable window of unavailability which can be translated into an availability requirement level of 2.

A loss of integrity would result in data corruption. For example, a potential excess order of coffee capsules may occur by altering the messages sent by the coffee machine or by replacing the same order multiple times. In both cases, this would result in a financial loss for your client. Data on the network needs to be communicated rigorously and exactly. Hence, we can conclude this is a requirement level of 3.

A loss of confidentiality would result in data being divulged; orders quantities are rather sensitive data that shouldn’t be shared with external parties. It needs to be ensured that data is communicated securely on the network and is not accessible by externals parties.  Hence, we conclude that confidentiality has a requirement level of 2.

For traceability, and for simplification reasons, we choose to leave this aspect aside assuming that it is already accounted for by the study of the first 3 criteria.

In a nutshell, risk analysis concludes to the following security requirements:

• Availability (A) = 2
• Integrity (I) = 3
• Confidentiality (C) = 2

For more details about risk analysis methodology for smart objects, you can refer to this article.

At the end of this analysis, you obtain for both of your business cases a radar chart of your requirements.

Business case 1: your customer connects your coffee machine to its local network

Business case 2: your customer does not connect your coffee machine to its local network

Though not discussed in this article, financial aspects are also important and depend on various factors such as the network operator pricing model. Same goes for geographic constraints as some networks may not be available on some regions.

Eventually, the ease of configuration of the network may be included in your business requirements, especially if your connected object targets a B2C audience.

Second step – Choose your IoT Network

Building on business and security requirements, we developed a methodology to choose the right network that will be optimal to meet your business and security needs: range, bandwidth, energy consumption, availability, integrity, confidentiality.

The three business requirements are mandatory, the network you choose must fulfil them, otherwise, it will be eliminated.

For security requirements, the assessment requires pre-emptive analysis. Between two networks that cover the same business requirements, you should choose the one that offers the best level of security with the minimum cost.

If a network doesn’t cover one of the security requirements, you will have to implement some additional security feature as a part of your project backlog, consequently raising your costs.

You should also be vigilant that the additional implementation doesn’t impact the system’s performance. For instance, if you implement data encryption at the application layer, increasing processing times would negatively impact your maximum data rate or could be constrained by the hardware capabilities of the device, with a potential financial impact in case of a hardware upgrade. Consequently, one of your business requirements may no longer be met.

In case high availability is required (A=3), you ought to choose a robust network by design that will meet your real-time needs.

In fact, spread spectrum (like Bluetooth or ZigBee) or frequency hopping modulated protocols (like Sigfox or Bluetooth) are more resistant to radio jamming or radio interferences.

These types of networks are particularly recommended when availability is an important requirement, such as on an industrial production line.

Moreover, mesh protocols are known to be more reliable and scalable than point to point protocols. However, for them to achieve efficiency, they need to be used in a context where multiple connected devices are linked together. Mesh protocols like WirelessHART can also guarantee real-time communications. Their usage is especially adapted to an industrial context.

A simple methodology to choose the right network is to confront your business requirements to the network’s business and security offerings.

In the following radar charts, we present different types of IoT networks providing different levels of business and security offerings, and we compare each one of them to our business requirements.

Business case 1: your customer connects your coffee machine to its local network

Business case 2: your customer does not connect your coffee machine to its local network

Let’s apply the previous methodology to your connected coffee machine. First, we use our previous radar charts to see which networks comply with our business requirements.

Business case 1: your customer connects your coffee machine to its local network

For your first business case, Bluetooth and Wi-Fi are two viable short-range options if your customer connects the machine to its local network. On the one hand, Bluetooth meets all the security requirements, but it is less straightforward to implement compared to Wi-Fi. On the other hand, Wi-Fi meets all of them except for availability but that is something we can work out with SLA agreements.

Business case 2: your customer does not connect your coffee machine to its local network

For your second business case, Zigbee, BLE and Wi-Fi are clearly out of the equation because they do not meet the range requirements. However, LoRa, LTE-M and Sigfox are still in the mix.

We use the radar charts again, this time to assess these three candidate’s compliance with the security requirements.

Sigfox does not meet one of your security requirements (confidentiality) whereas LoRa complies with all security requirements. LTE-M is the best offering as it meets all your requirements, but it is also the most expensive. We conclude that LoRa is a relatively good candidate.

In conclusion, we have one good candidate: LoRa which will require the deployment of a new network and an alternative using a pre-existing Wi-Fi network. It should be noted that you may refuse to connect to the Wi-Fi network on company premises for security reasons.

We will undertake a new scenario in a next article: a customer company buys the machine and discusses what payment options to use.

Cet article Connecting your connected coffee machine: yes, but how? est apparu en premier sur RiskInsight.

What is a cyber risk analysis?

Did you ever wonder what would happen if a device your company developed and sells leak the data it collects? Or if that data were corrupted or suddenly made unavailable? What would be the most detrimental? What if your solution was vulnerable to a cyberattack? Could the consequences be a takeover of device(s) which leads to a safety hazard such as a building taking fire or even a human casualty? Or maybe it could “just” be a pivot attack onto your customer’s network that leads to a full incapacity for your and your customer’s businesses to operate.

If you are currently developing an IoT solution and are not having a nervous breakdown when considering such possibilities, you are probably wondering though how your CISO (Chief Information Security Officer) is not having one.

Well it is probably because your CISO has a method: they consider every risk from an unbiased perspective and in a comparable manner. Ensuring each risk is correctly evaluated (i.e. not overestimated or underestimated) and sharing the outcome of this evaluation with all project stakeholders is the first important step. Once all stakeholders agree upon every risk your company has the right basis to decide control measures.

This approach does not mean you should address every risk to the point that your solution is virtually unhackable. Frankly, this is not technically possible, and your budget would vanish far before achieving a so called zero cyber risk solution. Each control measure must be prioritized and proportional to the risk likelihood and severity.

What we described above is known as a risk analysis methodology. Cybersecurity professionals use this methodology as the baseline to their company’s cybersecurity initiatives. The professionals evaluate risk scenarios (often tied to service availability, data integrity, confidentiality and/or traceability of actions) and the impacts on their company’s brand image, legal liabilities, safety consequences and of course financial outcomes. The higher the risk is evaluated, the higher the priority is set to lower the likelihood of the risk occurring (e.g. add barriers to an attack, reduce the attack surface, etc.) or the severity of outcomes if the risk occurs (e.g. apply segmentation to reduce the spread of an attack).

If you want to learn more about the existing risk analysis methodologies you should start with ISO27005 which has a wide scope of adoption and understanding across various industries.

Be reassured that talking about risks will not increase the likelihood of the problem occurring (if you ever feared that), however not talking about them puts the project at great risk.

What makes an IoT Project risk analysis different?

Hopefully we have convinced you that doing a risk analysis of your project is an important task; we will touch upon how you can get started quickly in the next chapter. Before we get there, we will detail what makes the exercise specific for an IoT project: what are the characteristics of such projects and what makes the risk analysis more difficult or simpler?

Let us start with the common characteristics that should be considered for a risk analysis. First of all, an IoT initiative often relies on a very decentralized network of hardware (sensors, gateways, servers, etc.). These devices can be spread over a large geographical area, sometimes all over the world, and are meant to remain in the field for a long time with little to no onsite maintenance. It is common to see B2B IoT devices that aim for a lifetime of more than 10 years (e.g. a water metering project for utility companies). B2C devices can also aim for such lifetimes – think of connected vehicles for instance. It is also noteworthy that IoT devices usually have limited user interfaces such as a screen and keyboard. Despite this, the buttons, LED and mobile applications allow the necessary interactions or customizations to the IoT device for you to collect data from the field. Remember, the data collected from connected devices is where the value resides. Thus, whether that data is critical or not is essential in the risk evaluation. Finally, we need to remind ourselves that an IoT project is still an IT project. If the devices are not typical laptops, the application servers and storage remain central in most cases. This is where a large part of the risk remains, but fortunately, there are many best practices for this portion of the solution as well.

From a cybersecurity perspective such characteristics can make IoT projects riskier. For instance:

• The physical security of a decentralized network is very hard to enforce. Where are the devices located? Are the devices accessible to the public? Can someone easily steal, damage or tamper the devices? For example, a tracker installed on a pallet travels outside trusted premises and can be damaged or removed – intentionally or not. Of course, this risk is amplified by a wider geographical footprint.
• Given the limited user interactions and the longer device lifetime, it can become very costly and time-consuming to maintain the devices, especially if you must physically dispatch technicians. Hands-on intervention can be simply unrealistic, but even firmware upgrades have a failure rate. Because of all this, the controls must be relevant for the long run.
• In any IoT project, the sensitivity of the data is a factor that must be considered. Is it critical for your company? For consumer projects the sensitivity of the data can be perceived as very high because the devices will collect data from the “real” world.
• IoT solutions consist of many different technologies and vendors. This is a challenge for us: what are the security practices followed by each of these vendors and do these practices sufficiently cover my risks?
• Finally, the security controls that can be applied are dependent on the capacities of the devices and softwares. For example, many sensors run on 8-bits MCU and thus cannot run complicated encryption algorithms.

Fortunately, all these characteristics also play a role in reducing the cyber risks for IoT projects.

• With very decentralized deployments, the level of effort required by an attacker to access a large number of devices is burdensome. Compromising a single device is one thing but compromising the entire fleet of devices is an entirely different task. This is especially true if physical tampering or proximity is required.
• The application of the IoT devices are rarely handled directly by a user and there are limited user interactions after installation. Thus, attackers have limited opportunities to trick the user into misusing the application.
• Depending on the context, the value of the data can be very limited for attackers (e.g. room temperature monitoring used to control AC systems). What is more, the value can also decrease sharply with time. Production data can be critical for real-time control of processes, but it becomes a lot less valuable a few minutes after.
• The architecture of IoT solutions is usually segregated from the IT systems including servers or data centers. This segregation enables companies to easily define and protect integration points.
• Finally, the limited capacities of the device play a role in preventing any harmful attempt. Attackers simply cannot access, implant malware or effectively control sensors with 8-bit MCUs.

So now, how can I get started?

Well, take a deep breath and involve your CISO.

The CISO must identify and evaluate applicable regulations, decide what level of risks is acceptable, provide policies to follow and tools to implement security measures. Perhaps you should appoint Product Security Officer to specifically address IoT security in your company or even a given IoT product’s security if the stakes require it.

Getting to an acceptable level of security will require expertise on the various areas of the IoT solution. If you are that expert, then you should probably be ready to get involved. This will drive the whole team to consider the:

• End-to-end security on the technology stack: from hardware to cloud including embedded software, network connectivity, mobile apps, etc.
• End-to-end security from a device lifecycle perspective. When you design your device, think about all phases: from manufacturing to distribution; from initial use to normal usage; resell, refurbish, recycle or trash.
• Partners involvement: make sure not to forget them and assess their maturity. You might need to take measures to support them or upskill them (hint: ask your CISO or PSO for it).
• Audit of your device and the whole technology stack. Do this regularly because your software may not have changed but the threats and known vulnerabilities may have.
• Long-term security updates and maintenance: define for how long you will update and deploy your devices.
• Incident response organization: define how you can be notified of vulnerabilities or breaches and how you can plan to respond (from a technical and a communication point of view).

IoT cybersecurity is not impossible. It actually provides methodologies and tools to help achieve a secure landscape.

Project stakeholders and customers are seeking and pressuring for secure products. Regulation to enforce security are imminent and frameworks to help align every actor regarding its duties will continue to be applied. It is time to get ahead now if you are looking to make cybersecurity an asset for your product on your market!

Cet article Risk analysis and IoT: a marriage of love or reason? est apparu en premier sur RiskInsight.

What does “Jitsuin Archivist” look like?

The start-up Jitsuin has developed a tool called “Jitsuin Archivist” based on Distributed Ledger Technology (DLT). The purpose of this tool is to know “Who did what to a Thing and When”.

As of today, 5 types of users can interact with the tool: Archivist Administrator, System Administrator, Maintenance Operator, Auditor, Custom (currently in beta version).

Figure 1 – The 5 user roles of “Jitsuin Archivist”

On this tool the user has access to the “Security Twins” of the connected devices. Indeed, after logging in, the user accesses a dashboard through which he has a global view of all the connected devices linked to the tool. He can see relevant statistics related to his IoT deployment, such as the number of critical incidents, the activity of connected objects, etc.

The user can also access the “Manage Assets” page where he will find a map with the location of all the connected objects linked to the tool and a list of them (where he can also see in more detail the events linked to a particular connected device).

Figure 2 – The different views of the tool “Jitsuin Archivist”: 1. dashboard with a global view, 2. all the objects and their location, 3. detailed view of an object, 4. all the actions of the object useful during security audits

The PoC: A House with a digital lock

Wavestone used Jitsuin’s tool to first address the issue of identity and access management in buildings in at the dawn of digital transformation and the to illustrate the usefulness of “Security Twins”.

To do this Wavestone used the lego house “SmartHouse” :

Figure 3 – The “SmartHouse”

Equipped with an RFID card reader, a Raspberry Pi microcontroller and a servomotor, the entrance door of the “SmartHouse” only opens to users who have an authorized access card. All actions related to opening, closing, granting of entry rights, etc. are recorded on “Jitsuin Archivist” (see figure 4).

Figure 4 – The functional diagram of the “SmartHouse”

In order to facilitate the interaction with the digital lock of the “SmartHouse”, a platform allowing the simulation of different operations made by different peopled involved in the life cycle of connected devices has been created using the Django web framework and Bootstrap. This platform allows, among other things, to:

• Send security patches to the connected lock (using Azure IoTHub)
• Assign access rights to the “SmartHouse”
• View the history of access rights requests made and those awaiting validation, etc.

This is what the platform looks like:

Figure 5 – SmartHouse’s management platform

The use of “Jitsuin Archivist” in this PoC is very interesting when regards to security audits of connected devices. Indeed, as “Jitsuin Archivist” is based on Distributed Ledger Technology (DLT), this system can be considered as “secure by design” since an auditor has a technical guarantee on the non-compromise of data (provided that the sending of this data is secure).

Here is the “Auditor View” on “Jitsuin Archivist” where it is possible to see all the information regarding the connected devices linked to the platform and to know who has done what to the connected device:

Figure 6 – The “Auditor View” of “Jitsuin Archivist”

The PoC scenario: WaveHouse rents “SmartHouses” in France …

Here is the general architecture of the PoC:

Figure 7 – The general architecture of the PoC

As one can see, the digital lock (represented by the RFID card reader, the Raspberry Pi microcontroller and the servomotor) interacts with Azure IoTHub as well to facilitate the management of its firmware updates.

The main use cases studied by Wavestone and Jitsuin

The main use cases studied by Wavestone and Jitsuin are explained in the video below:

Conclusion

Wavestone and Jitsuin were able to demonstrate – with the different use cases illustrated above in the video – how to improve the security of connected devices:

• First of all, all of the people involved in the life cycle of the digital lock of the “SmartHouse” had access to its “Security Twin”. Indeed, each of them had access to a decentralized and unchangeable register provided by “Jitsuin Archivist” with all the information regarding the security of the digital lock.
• Then, as mentioned above, this architecture is “secure by design” because as “Jitsuin Archivist” is based on Distributed Ledger Technology (DLT), one has a technical guarantee on the non-compromising of data.
• The “Security Twin” of the digital lock ensured physical security since it had the rights management information, allowing all the people involved to know who had access to the “SmartHouse”.
• Finally, since the “Security Twin” also had firmware information, the different people involved could easily know which connected devices had vulnerabilities and quickly plan the distribution of security patches.

The “Security Twins” would therefore ultimately improve the security of the connected devices, since it would be easy to know which objects are secure and which are not.

Cet article “Security Twins”: A new security & trust guarantee for connected devices (2/2) est apparu en premier sur RiskInsight.

Despite their usefulness, introducing connected devices unfortunately brings new risks for companies. Indeed, according to the Palo Alto Networks report² published in March 2020, 57% of the connected devices analyzed were vulnerable to medium or high severity attacks. This is not surprising. Securing connected devices is proving to be an arduous task that explains why Beecham Research³ finds 62% of Industrial IoT transformations fail to scale because of a lack of trust.

Therefore, with this article we will try to ask ourselves about the security and trust issues of connected devices and how companies can deal with them.

What are the security and trust issues of connected devices?

In order to mitigate the security risks on connected devices, NIST recommends in its report⁴ published in 2019 to focus on 6 main areas:

• Inventory: Maintain an accurate inventory of all connected devices and their most relevant characteristics throughout their lifecycle (see the article detailing the lifecycle of connected devices).

Figure 1 – Connected device lifecycle

• Vulnerabilities: Identify and eliminate known vulnerabilities in the software and firmware of connected devices to reduce the likelihood and ease of exploitation and compromise.
• Access: Prevent unauthorized and inappropriate physical and logical access, use and administration of connected devices by people, processes and other computing devices.
• Detect security incidents of connected devices: Monitor and analyze connected device activity for signs of incidents involving the security of the device.
• Detect data security incidents: Monitor and analyze the activity of the connected device for signs of data security incidents.
• Protect data: Prevent access and alteration of data that could expose sensitive information or allow manipulation or disruption of the operation of connected devices.

However, current IoT platforms only partially meet these security requirements (see the article detailing the usefulness of IoT platforms).

Figure 2 – The usefulness of IoT platforms

Indeed, traditional IoT architectures rely on a centralized cloud platform, operated by a third-party company and where most often the rules for data collection and storage are opaque. This is not the best solution to ensure the security of connected devices since:

• The use of a centralized cloud platform introduces the risk of “single point of failure” on the IoT architecture (although today this risk is mitigated with the implementation of a redundant architecture and backups).
• It is entirely possible for an attacker to change the data stored in the cloud database. The decision making of the different stakeholders is therefore impacted.
• Collaboration between the different stakeholders of the IoT deployment (manufacturers, maintenance operators, …) becomes more difficult because access to the platform can be restricted to them.

The use of a decentralized management system for connected devices where all stakeholders would have the possibility to reliably consult or contribute information regarding connected devices (firmware version, maintenance operations, etc.) becomes essential to guarantee the security of those devices and the integrity of data they produce.

How do “Security Twins” help meet the security challenges of connected devices?

In order to support IoT platforms and improve the security of IoT deployments, the notion of  “Security Twin” should be introduced in IoT deployments.

The principle of a “Security Twin” is simple. It is a virtual representation of the connected device that contains all its security information, such as firmware version, vulnerabilities, etc. upon which all stakeholders involved in its upkeep can reach consensus (see figure 3).

Figure 3 – The “Security Twin” mechanism (from: Jitsuin)

A “Security Twin” gains effectiveness when more stakeholders of the deployment can interact with it and reach consensus that the information provided/recorded is correct.

Therefore, solutions based on Distributed Ledger Technology (DLT) represent a logical first step in the creation of Security Twins, as they would allow the security information of the connected device to be gathered in a decentralized and immutable registry that would be accessible by all authorized stakeholders in the IoT deployment. The best well known distributed registry solution is the Blockchain (see the article on Blockchain’s uses and limitations).

Taking up the points raised earlier in the NIST report, one could say that the use of a “Security Twin” would therefore improve:

• Device and access management: all stakeholders of the IoT deployment would have access to a decentralized and immutable register of all the connected devices with the corresponding security and trust information.
• Vulnerability management and the detection of device security incidents: the different stakeholders could share device security information and take the necessary actions (e.g. the manufacturer of a connected device could notify the other stakeholders of the availability of a new firmware update thanks to the “Security Twin”).
• Data protection and the detection of data related security incidents: The very foundation of a “Security Twin” is based on the use of a decentralized and immutable register to record data related to the security of connected devices. This makes it more difficult for attackers to change the data, which reduces the risk of a security incident.

The use of “Security Twins” therefore offers the possibility of strengthening the security, integrity, trust and resilience of connected devices.

The start-up Jitsuin has developed “Jitsuin Archivist” a tool based on Distributed Ledger Technology (DLT) to overcome the lack of collaborative tools to secure connected devices. The purpose of this tool is not to replace IoT platforms but to allow the creation of “Security Twins”.

Together, Wavestone and Jitsuin sought to demonstrate the benefits of using a decentralized architecture with “Security Twins”. The two companies have therefore collaborated on the construction of a PoC (Proof of Concept) to tackle identity and access management of buildings using connected devices, which will be introduced in a future article.

1 Gartner, 29th August 2019 : https://www.gartner.com/en/newsroom/press-releases/2019-08-29-gartner-says-5-8-billion-enterprise-and-automotive-io
2 Palo Alto Networks, 10th March 2020, “Unit 42 IoT threat report”: https://unit42.paloaltonetworks.com/iot-threat-report-2020/
3 Why IoT projects fail https://www.whyiotprojectsfail.com/?cs=br2
4 NIST – “Considerations for Managing Internet of Things (IoT) Cybersecurity and Privacy Risks” : https://csrc.nist.gov/publications/detail/nistir/8228/final

Cet article “Security Twins”: A new security & trust guarantee for connected devices (1/2) est apparu en premier sur RiskInsight.

Quels besoins pour l’IAMoT ?

Il est possible de définir l’IAM comme une discipline permettant de « donner les bons droits, aux bonnes personnes, aux bons moments ». L’IAMoT vient ajouter une composante à cette définition pour permettre de « donner les bons droits, aux bonnes personnes et aux bons objets, aux bons moments ».

Mettre en œuvre des solutions pour permettre une gestion adaptée des identités des objets connectés se traduit donc par le besoin de prendre en compte :

• La gestion des identités des objets et de leur état (voir l’article détaillant le cycle de vie des objets) ;
• La gestion du contrôle d’accès et des habilitations :
  • des objets sur le SI et sur ses données ;
  • des objets sur les autres objets et leurs données ;
  • des employés/partenaires de l’entreprise sur l’objet et ses données ;
  • des clients finaux sur l’objet et ses données ;
• La gouvernance des identités des objets et la pertinence des droits associés dans le temps.

Tout comme pour l’IAM, pour chacun de ces domaines, il va être nécessaire de définir des processus, une organisation associée et des outils adaptés aux contraintes technologiques du projet.

La question est donc maintenant : vers quelles solutions s’orienter pour répondre à mes besoins ?

Des plates-formes IoT orientées connectivité et gestion de flotte

Le premier réflexe est de se tourner vers les services que peuvent fournir les plates-formes de gestion d’objets connectés.

En étudiant ces plates-formes plus en détail, nous avons fait le constat que leur priorité est déjà de couvrir les services essentiels pour la gestion de la flotte des objets connectés :

• gérer la connectivité multi-protocolaire des objets avec le SI de l’entreprise (SigFox, LoRa, 3/4/5G…) ;
• maîtriser l’inventaire des objets déployés et en assurer la configuration ou la mise à jour via un module de « Device Management » (LWM2M, OMA-DM, TR-069/CWMP…) ;
• permettre la remontée et la mise à disposition des données générées par l’objets (DTLS, CoAP, MQTT, AMQP…).

Ces fonctions s’accompagnent de solutions techniques d’authentification de l’objet sur les plates-formes mais celle-ci n’offrent aucune opportunité de couverture des besoins métier.

Dans ce cas, que font les acteurs traditionnels de l’IAM et du CIAM ? Puis-je me tourner vers leurs solutions qui sont aujourd’hui orientées sur la couverture des besoins des utilisateurs ?

Des marchés IAM et CIAM en mutation pour couvrir une infime partie du besoin IoT

Les éditeurs historiques de solutions IAM et CIAM ont compris l’énorme opportunité que représente l’IAMoT et orientent progressivement leurs offres et le discours associé sur ce marché. Néanmoins, nous constatons qu’ils ne couvrent encore que très partiellement les besoins identifiés ci-dessus et que selon leur capacité à innover le délai de mise en œuvre des nouveautés pourra être important.

Forts de leurs savoir-faire technologiques, ils se concentrent aujourd’hui quasi-exclusivement sur le volet contrôle d’accès. Ils offrent ainsi des solutions pertinentes pour permettre l’authentification applicative des objets sur le SI et la délivrance de jetons d’autorisation dont la gestion du contenu relève encore d’un défi propre à chaque projet. Sur les autres volets de l’IAMoT tels que la gestion de l’identité et de l’état des objets, la gestion du modèle de rôles liant objets / utilisateurs / identités internes / identités externes, ou la gouvernance des droits dans le temps, il est urgent que leur offre s’étoffe.

Dès lors, comment peut-on couvrir des besoins IAMoT bien présents malgré les lacunes du marché ?

Une hétérogénéité des usages rendant complexe la normalisation des pratiques et la standardisation des solutions

La diversité des usages et donc des modes de fonctionnement des objets connectés est évidemment à l’origine de la difficulté des éditeurs à proposer une offre générique adaptée à ses clients. Mais les projets IoT sont là et il n’est pas envisageable d’attendre que le marché prenne forme.

Mais si l’harmonisation est actuellement impossible au niveau global du marché, un effort peut être consenti au niveau de l’entreprise afin d’essayer d’harmoniser les réponses pour l’ensemble de ses usages IoT. Ainsi tout en cherchant à tirer parti de ce que propose le marché IAMoT, il est nécessaire d’envisager le développement modulaire des briques manquantes et en priorité celles ayant trait à la gestion des relations « objets / utilisateurs / identités internes / identités externes ». Attention toutefois à ne pas succomber aveuglement à l’utilisation des frameworks bas-niveau propriétaires proposés par les plates-formes IoT. Chacun devra être vigilant à conserver un niveau d’abstraction et d’autonomie suffisant pour ne pas être lié ad vitam æternam à un éditeur unique. Ce point d’attention est d’autant plus important dans un marché peu mature et en explosion où les bonnes idées se font et se défont.

Que faut-il retenir ?

Aucune solution du marché ne couvre l’intégralité des besoins fondamentaux de l’IAM of Things. Les plates-formes IoT se limitent aux fonctions de connectivité des objets, de gestion de flotte et de remontée de données. Les plates-formes IAM et CIAM n’offrent quant à elles que des réponses technologiques aux besoins d’authentification et d’autorisation.

Afin de combler les manques, chaque entreprise devra évaluer le besoin de se lancer dans le développement de ses propres modules applicatifs. Un effort tout particulier devra être entrepris pour atteindre un niveau adapté de généricité des modules pour l’ensemble de leurs usages et d’indépendance vis-à-vis des solutions éditeur.

Cet article IAM of Things, un marché émergeant mais un besoin déjà présent est apparu en premier sur RiskInsight.

What are the risks in the iot world?

The IoT advent has enabled millions of new potential technological advantages for consumers and companies. However, with these new advantages, certain risks are higher in the field of connected devices.

Figure 1 – Most significant risks in the IoT world

These business and technological risks which could cause significant potential impacts for consumers and companies, should be identified from the upstream phases of an IoT project.

Which project methodology to choose in order to ensure security of connected devices?

Even though security issues to address in IoT project are common for all project, we think necessary to structure reflections regarding the life cycle of the connected device.

The diagram below highlights all the stages of their life cycle.

Figure 2- A life cycle enabling to address all the security issues

Let us review  some important issues raised by this approach:

1. Design, manufacturing, and distribution phases

This first phase addresses issues related to the design of the object, regarding business stakes, targeted users (B2B, B2C, B2E), deployment environment (controlled or not) and criticality of the use:

• What are the regulatory constraints related to the use of the object?
• What identity should be labeled and how is this identity created?
• How is the security related to object’s hardware and software secrets and data stored in the object?
• How is the state of a device on the management platform initialized, ensuring it has no right on the IS before the initialization step?

The determined choices during the manufacturing phases are crucial because they determine characteristics and capacities of the device. Some of them will therefore be immutable throughout the life of the device and will impose strong constraints in the following steps.

Furthermore, although the end of the manufacturing phase marks the beginning of the existence of the device on the device management platform, there is still no reason to consider an interaction with the IS.

Any interaction before the device’s association to a user (physical or moral) would mean that it has been diverted in the distribution phase. Any access to the IS before the initialization phase must be strictly limited to the firmware update (version N installed at the factory and version N+1 available when unpacking) or to the pre-customization of the object (operating settings or injection of secrets not related to the user). Beyond IS security, an object that is unused before any pairing phase will reduce the risk of theft of that object in the factory or during distribution.

2. Initialization phase

Initialization phase materializes the association phase (also named pairing) between a device and its owner. Any data generated by the device (or realized action) is then declared as belonging or attributed to its owner..

Therefore, the main challenge is to ensure a reliable level of user / object association corresponding to the following business stakes:

• Low level of association required (low-risk situation): An employee declares the usage of an attendance identification system in the meeting room;
• Strong level of association required (high-risk situation): when purchasing a connected lock, a consumer provides a serial number and a one-time secret code to allow his mobile application to unlock the door of his home.

It is very important to find a balance between the user experience and security.

The robustness of the expected association will vary according to the nature of the services to which the customer has subscribed.

3. Use phase

The definition of the use cases of connected devices is the most anticipated step by companies, however many aspects of security remain neglected.

Besides business use cases, additional questions must be raised:

• How can regular updates of the connected device be implemented?
• What are the different actors of the company roles regarding the maintenance of the device operating system layer: the application layer, and the network module?
• What is the detection and response requirements for a compromised device?
• How to take advantage of the company SIEM (Security Information and Event Management) and SOC (Security Operation Center) for technical security incidents (software compromise of the device) and for business security incidents (misuse or theft of a device)?
• How can backward compatibility of protocols and APIs used by different versions of the same type of device be maintained?
• What are the models of roles and interactions between different populations acting on the object?

Concerning this last question, and as an example, the scheme below illustrates the potential complexity stemming from the interactions and roles model such as a connected vehicle.

Figure 3- Example of a roles and interactions model with a connected vehicle (research carried out with IMT Atlantique)

4. Resale phase

Today, the resale is the most neglected phase during the device design. This event essentially concerns devices for B2C markets and raises very specific issues:

• How to detect and handle the resale of a device between individuals?
• What privacy-by-design principles should be implemented to protect secrets and data from the former owner while resetting a device?
• How can access rights of the former owner of the device be removed?
• What are the ways to reset a device in a stable and clean state before re-pairing?

The major difficulty involves the detection of the resale event which triggers the device/user unpairing processes, reset the state of the object, etc.

Our experience allows us to identify some circumstances that could indicate a change of ownership.

Figure 4 – Examples of events that could indicate the change of ownership

Despite such examples, we witness that resale remains a complex event to identify. Thus, some companies choose not to authorize the device resale via a lease contract. The device must therefore be returned when the service is terminated; otherwise it must be made unusable. This model is comparable to renting an Internet box with an ISP (Internet Service Provider).

5. End-of-life and recycling

Although essential, we currently have little perspective on this step, however there are multiple stakes:

• Revoke access rights on the Information System of an end-of-life device;
• Renew the identity of a recycled device;
• Ensure the replacement of a defective object by re-associating a new one with the same owner and the same data;
• Detect the inactivity of a device to trigger a replacement.

The main risks are the loss of access control over the company IS via identifiers associated with recycled devices, the disclosure of personal data of the former owner or the additional cost of license for data generated by devices considered out of the scope.

A variable capacity of action in response to the risks according to the nature of the project

At this stage of your reading, you probably think that this article is not your concern because you purchase pre-conceived connected modules or devices.

Unfortunately this mindset is wrong –  you are still exposed to the same risks! Even though you only purchase or welcome connected devices in your IS, by addressing all the issues above you will be able to feed the contents of requirement specifications to suppliers.

To conclude, whatever the nature of your IoT project, it is essential to design your object by structuring the reflections around its life cycle: from its manufacturing to its disposal. It is therefore necessary, at each stage, to address all the relevant security themes: Network / application / hardware security, standards, detection and reaction, governance, maintenance in security condition…

Figure 5 – Main security themes for an IoT project

Cet article A life cycle approach for IoT security est apparu en premier sur RiskInsight.

Comment l’idée vous est-elle venue ?

Georges Bote (ICARE Technologies) raconte que l’idée est venue au fondateur, Jérémy Neyrou « il y a 6 ans de cela, en perdant mes clés de voiture sur une plage Corse complètement déconnectée de tout réseau, après avoir parcouru près d’une dizaine de kilomètres en plein soleil d’été à pied », il imagine un « objet à la fois intuitif et autonome qui permettrait d’embarquer [le] trousseau de clés et [les] moyens de paiement ». C’est ainsi qu’est née Aeklys, « cette bague intelligente qui permet d’embarquer jusqu’à 28 fonctionnalités différentes ».

Quel est le plus grand risque de sécurité pour les banques et pour ses clients selon vous ? Comment répondez-vous à la menace qui pèse sur les banques ?

Georges Bote (ICARE Technologies) s’accorde également à dire que « la fraude à la fois bancaire et sur l’identité des personnes reste le grand risque pour les banques et leurs clients ». C’est pourquoi la bague connectée proposée par ICARE Technologies embarque un mécanisme de désactivation en cas de perte ou de vol, protégeant ainsi son propriétaire contre l’usurpation de ses moyens de paiement sans qu’il ne doive faire opposition d’une quelconque manière que ce soit.

L’enjeu pour les RSSI aujourd’hui est de parvenir à concilier la facilité d’implémentation, la simplicité d’utilisation des solutions de sécurité avec une technologie sécurisée. Comment convaincre un RSSI de la pertinence de votre solution et de la sécurité du produit ? Quels sont les différenciateurs qui vous démarquent sur le marché ?

ICARE Technologies explique que la pertinence de la sécurité de sa solution « réside dans notre technique et différentes certifications bancaires. Notre secure element dispose d’un niveau EAL6+ certifié par l’ANSSI, ce qui nous permet de travailler dans le domaine militaire en plus d’avoir un chiffrement en AES 256 bits ».

Quelles sont les synergies entre votre innovation et les solutions de sécurité bancaires existantes à l’heure actuelle ?

La force du produit d’ICARE Technologies réside dans son innovation et en sa sécurité : « de plus, il caractérise une nouvelle forme de liberté et de sécurité qui est fortement attractive pour les clients potentiels. L’intérêt est donc d’en faire devenir un objet « à la mode » de manière à orienter la connotation sociale de la bague comme une tendance ».

Les synergies existent et la technologie est actuellement en phase de test avec des partenaires bancaires et industriels pour travailler notamment sur la sécurisation de valises informatiques. Georges Bote annonce « la préparation d’un 2ème tour de table et de belles surprises pour notre Go To Market qui sera prévu le 1er trimestre 2019 ».

Pour en savoir plus : https://fr.icaretechnologies.com/

Cet article L’INTERVIEW D’ICARE TECHNOLOGIES – LA BAGUE INTELLIGENTE SECURISEE est apparu en premier sur RiskInsight.

 AU COEUR DE LA TRANSFORMATION NUMÉRIQUE

Aucune industrie ne peut aujourd’hui ignorer cette tendance et les entreprises voient un intérêt grandissant à s’emparer de ce qu’elles perçoivent comme une véritable opportunité.

Alors que des start-ups conçoivent chaque jour des dispositifs intelligents, des partenariats se mettent en place entre les vendeurs et les industries traditionnelles – tels les secteurs de l’assurance, automobile, administratif, bancaire – afin d’offrir de nouveaux services aux consommateurs grâce à divers éléments connectés.

UNE SURFACE D’ATTAQUE DE PLUS EN PLUS EN PLUS VASTE POUR LES CYBERCRIMINELS

L’essor de cet Internet des Objets n’est pas sans danger, d’autant plus que les risques, qui étaient surtout virtuels, s’étendent au domaine du physique.

Une étude frappante a été menée par HP Fortify en 2014, mettant en avant un constat sans appel : en testant la sécurité des 10 des objets connectés les plus en vogue du moment, une moyenne de 25 vulnérabilités par objet a été trouvée. La plupart d’entre elles sont liées à des problèmes de sécurité basiques, tels que la mauvaise gestion de la confidentialité des données et des droits d’accès, l’absence de chiffrement des flux, une interface d’adminis­tration Web non sécurisée, ou encore une protection générale inadaptée. La suite de cette étude en 2015 a également montré que les 10 smartwatchs et les 10 systèmes de sécurité pour les particuliers les plus vendus présentaient tous des vulnérabilités majeures concernant la confidentialité des données de l’utilisateur.

Ce manque de durcissement augmente le risque de vulnérabilités pouvant affecter toute sorte d’objets : des réfrigérateurs aux toilettes connectées, en passant par les voi­tures et les serrures. L’actualité des derniers mois en est la preuve avec par exemple l’attaque DDoS sur le DNS Dyn avec le botnet Mirai en octobre 2016 ou la prise de contrôle à distance d’une Tesla par une équipe de hackers chinois en septembre 2016.

DANS QUELLE CATÉGORIE DE RISQUES VOUS SITUEZ-VOUS ?

En ce qui concernent les entreprises, les risques dépendent de la posture adoptée. Dans le cas des objets connectés, quatre cas sont possibles. Les différentes postures ont été réunies sous l’acronyme « CARA » (pour Concevoir, Acquérir, Recommander, Accueillir) comme le montre le tableau ci-dessous. Une fois la posture identifiée, il convient de spécifier les risques génériques et les recommandations associées.

Afin d’évaluer le risque, le cabinet Wavestone a développé un outil spécifique, la matrice « heat map ». Elle prend en compte deux dimensions : le niveau de risque et la posture.

UN OUTIL D’ÉVALUATION EFFICACE : LA MATRICE « HEAT MAP »

Le schéma ci-dessous présente l’exemple concret de l’utilisation d’objets connectés pour le secteur bancaire et ses divers ser­vices. Ce contexte présente des contraintes particulières. D’un côté la réalisation d’une transaction financière est plus risquée que la consultation du solde bancaire. Mais d’un autre côté, la personnalisation des fonctions de sécurité sur un appareil appartenant à un employé ou à un client est bien plus compliqué que le durcissement d’un produit choisi par l’entreprise et qui a été acquis à un fournisseur, ou même développé en interne.

Cette matrice permet de réaliser une cartographie des risques qui requièrent la plus grande attention.

DES DISPOSITIFS DE SÉCURITÉ HABITUELS : DE NOUVEAUX MODES D’IMPLÉMENTATION

Une fois la cartographie des risques établie, il faut s’intéresser aux réponses que l’on peut y apporter. Une référence intéressante à ce propos est celle de l’initiative « IoT Project » de l’OWASP (Open Web Application Security Project – organisation à but non lucratif) qui propose notamment une liste de recommandations de sécurité intéressantes et compréhensibles.

La première chose à noter à propos de ce guide est qu’il est divisé en 3 catégories selon les cibles d’audience visées : fabri­cants, développeurs, consommateurs. Cette structure a du sens dans la mesure où la sécurité est partagée entre ceux qui conçoivent les composants (matériel ou logiciel), et ceux qui les utilisent.

Par ailleurs, les dispositifs de sécurité doivent être complets – renforçant non pas les seuls objets connectés, mais aussi toute la sur­face d’une attaque (physique, matériel, logiciel, base de données, local ou à distance, etc.). À cet égard, les mesures de sécurité proposées sont surtout construites sur les bonnes pratiques de l’industrie de la sécurité.

L’Internet des Objets apporte un réel changement dans la mise en œuvre des dispositifs de sécurité.

En effet, plusieurs contraintes liées aux objets connectés sont à prendre en compte :

• Ergonomie : la taille et le design influenceront les mesures de sécurité acceptables par les utilisateurs – par exemple, la taille de l’écran pour taper un mot de passe.
• Puissance : les petits objets embarqués actuels ont une puissance de calcul limitée. Plusieurs opérations ne peuvent être réalisées en même temps dans un laps de temps raisonnable. Par exemple, Apple a conseillé aux développeurs de ne pas implémenter des fonctionnalités nécessitant de long temps d’exécution sur l’Apple Watch.
• Connectivité : l’Internet des Objets utilise généralement du Bluetooth ou des protocoles NFC, deux technologies ayant une portée et un débit limité, ce qui ne permet pas toujours d’embarquer un niveau de sécurité suffisant.
• Durée de vie de la batterie : les algo­rithmes cryptographiques (comme du chiffrement / déchiffrement asymé­trique en temps réel) peuvent affecter durement la consommation énergé­tique, même s’ils permettent de pro­curer un meilleur niveau de protection.
• Gestion des mises à jour : il est indis­pensable de mettre à jour le système, sans interférer avec l’utilisation de l’objet. Cela est particulièrement frap­pant dans le cas des voitures connec­tées que l’on ne peut pas conduire lorsque le logiciel est en train de se mettre à jour. Cela peut prendre plus de 45 minutes.

Au-delà de la sécurité, la confidentialité est également indispensable pour les consommateurs ainsi qu’une exigence pour les autorités. L’implémentation pourrait être complexe, mais plusieurs initiatives pour la confidentialité des objets connectés ont émergé ces dernières années.

Parmi ces initiatives, le projet PRESERVE est un exemple intéressant. Il offre à l’industrie automobile un nouveau moyen d’utiliser les PKI et les certificats numériques pour les voitures et les routes connectées. Le projet utilise des « pseudonymes » modifiés régulièrement afin de garantir que le conducteur reste anonyme tout en assurant que les communications entre les véhicules et l’infrastructure routière sont authentiques et sécurisées.

Nous sommes entrés dans une ère où sécurité et confidentialité des données sont devenues des critères essentiels dans le choix des consommateurs. Cette évolution ne peut plus être ignorée par les acteurs concernés, qu’ils conçoivent, acquièrent, recommandent ou accueillent des objets connectés.

Cet article Objets connectés : les 4 dimensions de la sécurité est apparu en premier sur RiskInsight.

Et puis sont venus les partenaires externes et leurs employés. Dans le cas d’usage classique, un constructeur d’avion doit pouvoir collaborer avec l’ensemble de ses sous-traitants : il faut leur permettre l’accès aux applications, gérer ou faire gérer leurs comptes et leurs droits. La fédération des identités ainsi que ses standards et protocoles ont permis de répondre à cette problématique. La gestion des identités si elle devait prévoir de nouveaux processus n’a été que faiblement impactée (la volumétrie restait d’un ordre de grandeur comparable, les utilisateurs restaient des humains maîtrisés, etc.)

Aujourd’hui, un premier palier doit être franchi pour gérer une volumétrie beaucoup plus forte et des utilisateurs d’un nouveau type : les clients. Des centaines de milliers voire des millions d’identités. Il faut maintenant gérer l’identité d’un client et pouvoir l’authentifier et l’autoriser sur les applications mises à sa disposition. Il faut savoir l‘authentifier simplement de son point de vue (e.g. via un réseau social) et faire le lien avec son compte traditionnel dans le CRM pour gérer la relation. Les opérateurs télécoms et les banques et leurs bases clients sont devenues le nouveau cas d’usage classique : les accès aux applications via Internet et terminaux mobiles sont dans l’air du temps.

Au-delà de ce changement d’échelle, les caractéristiques de ces identités de clients sont différentes des traditionnelles identités de l’entreprise : le nombre d’applications accédées et de rôles est plus faible. Par ailleurs, plus question de devoir gérer des cas particuliers, tous les clients sont logés à la même enseigne et ce pour le plus grand bénéfice des projets IAM qui vont enfin voir se réduire fortement leur complexité fonctionnelle.

Enfin, un deuxième palier s’annonce déjà : la gestion des identités des objets connectés. Le CES 2014 qui s’achève ces jours-ci nous en offre de multiples illustrations : brosses à dent, cocottes minutes, lits, ampoules, etc. Tous les objets du quotidien sont désormais connectés. Par ailleurs, la complexité et les facultés de ces objets nous environnant sont telles aujourd’hui que de nouvelles approches sont nécessaires.

Les premiers objets connectés étaient de simples capteurs : température, pression, cellules infrarouge, compteurs, etc. Généralement non connectés directement à Internet, ils émettaient de l’information dans un protocole spécifique à destination d’une passerelle qui elle avait pour rôle de centraliser les données et de les transmettre via Internet à un serveur de traitement.

Nouveaux usages et nouveaux besoins

L’identification de ces objets est alors très sommaire, allant de la simple déclaration d’adresse MAC jusqu’à l’utilisation d’une clé de chiffrement des échanges pour les installations les plus sophistiquées.

Les objets connectés sont maintenant non seulement émetteurs de données de plus en plus complexes mais également destinataires de commandes et d’action à réaliser, de correctifs et patches de sécurité, etc.

Dernier cas d’usage classique à la mode : la voiture connectée informe directement le constructeur ou le concessionnaire qu’un sous-composant est en mauvaise santé ou qu’une révision est nécessaire.

Ces objets doivent pouvoir être joints depuis n’importe où (et ne plus être masqués par une passerelle) et par ailleurs, les capacités d’attaques cybercriminelles ayant fortement augmentés ces dernières années, la sécurité des échanges et l’authentification préalable des objets est devenu un prérequis. Et nous voilà donc avec des milliers d’objets disposant d’une identité !

Cet article Des objets et des hommes est apparu en premier sur RiskInsight.