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

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

What are the cyber risks in the charging ecosystem? 

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

So, how can CPOs secure their architecture? 

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

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

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

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

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

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

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

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

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

Conclusion: what should be the reference architecture for CPOs? 

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

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

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

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

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

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

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

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

Definition and Scope 

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

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

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

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

Stakeholders and Responsibilities 

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

Essential Requirements 

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

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

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

How to achieve compliance with the CRA? 

Timeline of the CRA 

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

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

A complex ecosystem 

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

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

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

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

Checklist for CRA compliance 

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

The certification process varies based on product criticality: 

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

Five main checkpoints are to be considered to achieve compliance:  

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

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

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

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

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

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

Why use a KMS? 

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

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

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

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

Figure 1 : Typical KMS architecture 

The different ways to deploy a KMS 

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

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

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

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

Figure 2 : The three possible implementations for a KMS 

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

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

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

• Microsoft which offers Azure Key Vault, 

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

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

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

Specialized companies are also positioning themselves in the market: 

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

• Entrust, whose product is called KeyControl, 

• HashiCorp, with its product  Vault, 

• Utimaco, whose KMS is called KeyBridge, 

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

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

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

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

Figure 3: Three main types of KMS providers 

The advantages of using a KMS 

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

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

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

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

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

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

Traps to avoid when implementing a KMS 

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

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

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

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

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

KMS, an essential solution for secure encryption key management 

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

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

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

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

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.