Or, ce sont des systèmes hautement informatisés et connectés, bien plus que les stations-essence traditionnelles. En effet, la digitalisation permet un écosystème intelligent et des gains opérationnels directs. Par exemple, le smart charging permet des économies financières et énergétiques en optimisant les usages d’électricité en fonction des pics de demande sur le réseau électrique. L’expérience du conducteur est également fluidifiée, grâce à la possibilité de localiser et d’interagir avec les bornes depuis son smartphone. 

Ces fonctionnalités intelligentes posent des défis particuliers de cybersécurité que nous décrypterons dans cet article. Nous décrirons les stratégies que peuvent mettre en place les Charging Point Operators (CPO – opérateurs de recharge en français), en nous focalisant sur le cas des bornes de recharge en lieu public. En effet, ces dernières sont plus exposées et présentent le cas d’étude le plus complexe, tant d’un point de vue opérationnel que cyber. 

Risques cyber sur l’écosystème de la recharge : de quoi parle-t-on ? 

Tout d’abord, pourquoi le risque cyber est-il important, et quelle en est la nature ? Pour le comprendre, il nous faut d’abord étudier l’écosystème de la recharge. 

L’acteur central de cet écosystème est le CPO, en première ligne des risques cyber. C’est lui qui assure l’opération directe des bornes de recharge, sur le terrain mais surtout à distance. En général, il utilise une solution logicielle de supervision appelée CSMS (Charging Station Management System), hébergée dans le Cloud.  

Le rôle du CSMS a été fortement standardisé grâce aux efforts de l’Open Charge Alliance (OCA), un consortium d’acteurs du secteur qui est à l’origine du protocole OCPP (Open Charge Point Protocol). Au travers d’OCPP, le CSMS n’a pas qu’un rôle de configuration et supervision ; il assure toutes les communications nécessaires au déroulé d’une recharge (réservation de la borne, authentification et autorisation du conducteur, facturation…). Ceci présente un premier risque : la compromission du CSMS peut entraîner une compromission générale des réseaux de bornes du CPO. 

Cependant, pour avoir une vue globale des risques, nous devons considérer également les autres acteurs métier qui partagent le risque cyber avec le CPO. 

En premier lieu, les fabricants de bornes jouent un rôle important. Responsables de la conception et de la fabrication des bornes, ils assurent le suivi logiciel et fournissent les correctifs en cas de vulnérabilités. Dans certains modèles de bornes, les fabricants conservent un accès de maintenance à distance permanent, utilisant une seconde connexion OCPP : cette dernière peut être vue comme un risque pour le CPO si elle n’est pas maîtrisée. 

Ensuite, pour assurer la connexion à distance des réseaux de bornes au CSMS, l’utilisation de solutions WAN (Wide Area Network) est fréquente. Il peut s’agir d’un lien 3G/4G ou d’une intégration à un réseau préexistant sur site. Dans les deux cas, ce lien n’est pas maîtrisé par le CPO, qui est dépendant de la maturité cyber du prestataire télécom qu’il sélectionne. 

Enfin, le CPO doit intégrer son SI avec le gestionnaire du site qui héberge ses bornes. Celles-ci peuvent être placées dans des endroits variés : aires de repos d’autoroute, parkings d’entreprise, centres commerciaux, voies publiques… Selon les cas, les bornes peuvent être interfacées à des systèmes du bâtiment (capteurs de présence, compteurs connectés…), ou encore à des systèmes d’authentification et paiement des usagers. Le CPO n’a généralement pas d’autorité sur ces systèmes et sur leur niveau de sécurité. 

Cette multiplicité d’acteurs tend à faire croître la surface d’attaque sur le SI du CPO. Or, une intrusion peut entraîner une fuite de données client ou servir de pré-positionnement pour une attaque cyber plus large ciblant le CPO et/ou ses partenaires, avec des impacts financiers et réputationnels. 

A l’échelle locale, les attaques possibles sont également sévères, incluant des risques cyberphysiques (modification malveillante des paramètres de charge, entraînant une surchauffe de la batterie et potentiellement un incendie), ou des risques de déstabilisation du réseau électrique (par l’activation/désactivation malveillante de recharges sur de nombreuses bornes en simultané). 

Ces scénarios devraient devenir plus plausibles, en raison de la popularisation des bornes de recharge ultra-rapides (notamment utilisées par les véhicules lourds), et des technologies de recharge bidirectionnelle, offrant la possibilité pour un véhicule stationné d’injecter l’énergie stockée dans sa batterie sur le réseau. 

Mettre en œuvre les nouveaux standards, est-ce suffisant pour répondre aux risques ?  

Du fait de sa forte croissance, le marché de la recharge se structure, et de nouveaux standards se développent : ceci présente une opportunité d’apporter une réponse cyber unifiée aux risques que nous avons évoqués. 

Prenons le standard ISO 15118-20. Publié en 2022, il spécifie des mécanismes de communication robuste entre véhicules et bornes. En plus des usages de smart charging et de recharge bidirectionnelle évoqués précédemment, la norme introduit le Plug & Charge : cette fonctionnalité permet d’autoriser les recharges en identifiant directement le véhicule, sans nécessité pour l’usager de présenter un badge ou une carte de paiement. 

Les buts premiers d’ISO 15118 sont donc la fluidification des usages, l’efficacité énergétique, et l’interopérabilité. Mais son adoption pourrait aussi révolutionner le modèle de sécurité, notamment via la mise en place d’une PKI (Public Key Infrastructure) globale aux acteurs de la recharge : fabricants de véhicules, opérateurs de mobilité, et CPO. 

Parallèlement, le développement et la démocratisation de l’OCPP devraient s’accélérer, suite à l’approbation officielle d’OCPP 2.0.1 en tant que norme internationale (IEC 63584) par la Commission électrotechnique internationale. 

Cependant, des freins forts subsistent concernant l’adoption de ces standards. Plusieurs acteurs majeurs, tels que Tesla, ont développé des protocoles propriétaires avec des fonctionnalités similaires. Et surtout, la plupart des bornes et véhicules existants ne sont pas compatibles avec ISO 15118 ou OCPP 2.0.1., et doivent être remplacés. 

Ainsi, nous ne pouvons pas nous contenter des standards comme seule réponse aux risques cyber : paradoxalement, bien que leur adoption soit cruciale pour que le secteur monte en maturité, il est impératif de trouver des moyens de sécuriser les infrastructures déjà existantes. 

Note : pour en savoir plus le Plug & Charge et le smart charging, n’hésitez pas à consulter les articles d’EnergyStream, le blog énergie de Wavestone : 

• 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 

Mais alors, comment les CPO peuvent-ils protéger leur architecture ? 

Les standards n’ont pas réponse à tout : c’est donc d’abord au CPO qu’il incombe d’appliquer une politique de cybersécurité exhaustive. Mais comment s’armer face à la complexité des risques évoqués ? 

La première étape, c’est de comprendre et documenter son architecture et ses solutions. Cela peut sembler basique, mais il n’existe pas aujourd’hui d’architecture de référence pour les infrastructures de recharge. Dans cet article, nous modéliserons l’architecture en quatre zones, comme présenté ci-dessous : 

Figure1. Modèle d’architecture standard pour les infrastructures de recharge

Pour sécuriser de bout en bout cette architecture, nous allons regarder les mesures-clés pour sécuriser chaque zone. 

Nous pouvons cependant ignorer l’interface véhicule dans notre analyse. En effet, en attendant la démocratisation d’ISO 15118, les connecteurs de charge actuels ne sont pas intégrés au SI et ne constituent donc pas un vecteur de risque cyber. 

Sur le réseau de bornes, les mesures d’hygiène cyber et de segmentation réseau sont primordiales. Les bornes de recharge sont souvent des systèmes vulnérables : présence de comptes par défaut, mots de passe faibles, ports réseaux ouverts, systèmes de stockage non chiffrés… Des bonnes pratiques de durcissement et de mise à jour des micrologiciels doivent être pensées par le CPO pour chaque fabricant et modèle qu’il sélectionne.  

La segmentation réseau implique généralement l’utilisation de firewalls et de VLANs, selon la topologie réseau locale et les systèmes externes devant être intégrés. La mise en place d’un contrôleur local peut permettre d’isoler plus facilement les bornes des réseaux externes. Ce contrôleur peut agréger toutes les bornes d’un site et servir de proxy avec le CSMS. 

Passons au réseau WAN. Celui-ci étant souvent un réseau externalisé, il est fondamental pour le CPO de pouvoir chiffrer les flux entre les bornes et le CSMS. La principale solution existante aujourd’hui est l’utilisation de TLS avec certificats serveur et client, prévue dans les versions les plus récentes d’OCPP. 

Enfin, comment sécuriser le CSMS ? Celui-ci peut généralement être assimilé à une plateforme IoT dans le Cloud, et être abordé de manière similaire. Citons en priorité les pratiques de sécurité du code et la bonne gestion des identités et des accès (suivant le modèle RBAC). A l’avenir, nous pouvons imaginer que le CSMS jouera aussi un rôle actif de détection des menaces cyber : l’analyse des logs et des communications OCPP pourrait être facilitée par la mise en œuvre de solutions basées sur l’intelligence artificielle. 

Conclusion : quelle architecture de référence pour les CPO ? 

Bien que les nouveaux standards offrent des espoirs d’homogénéisation des architectures, l’écosystème de la recharge reste complexe en raison de la variété des cas métier. C’est pourquoi nous encourageons les CPO à adapter les bonnes pratiques de cet article à leur cas d’usage ; le schéma d’architecture ci-dessous doit ainsi servir de base de réflexion, plutôt que de cible définitive. 

Figure 2. Modèle d’architecture sécurisée pour les infrastructures de recharge

Cet article Mobilité électrique – Comment les opérateurs peuvent-ils sécuriser leur infrastructure de recharge ?  est apparu en premier sur RiskInsight.

En quelques mots, si vous fabriquez, importez ou revendez un produit avec des éléments numériques, vous serez sûrement affecté par le CRA et devrez veiller à sa conformité. Cet article vise à éclairer sur : Que prévoit cette réglementation ? Qui est concerné ? Comment assurer la conformité ? 

Qu’est-ce que le CRA et qu’implique-t-il ?   

Pour comprendre la nécessité du CRA, il est crucial de considérer le contexte plus large de la cybersécurité en Europe. Le CRA est une réglementation ambitieuse conçue pour assurer la sécurité des citoyens de l’UE en s’attaquant aux faibles niveaux observés aujourd’hui de cybersécurité des produits avec des éléments numériques, par le biais d’une intervention politique de l’Union européenne. Pour ce faire, des études approfondies axées sur la cybersécurité des produits numériques ont été menées, aboutissant à la proposition d’une législation définissant les obligations pour l’ensemble des acteurs de la chaîne d’approvisionnement des produits, des fabricants aux distributeurs. 

L’implication de Wavestone dans ce processus souligne son engagement à améliorer les normes de cybersécurité. Nous avons participé à une étude exploratoire approfondie commandée par l’UE, en engageant un large éventail de parties prenantes, y compris des autorités nationales, des organes de l’UE, des fabricants de matériel et de logiciels, des associations professionnelles, des organisations de consommateurs, des chercheurs, des universitaires et des professionnels de la cybersécurité. 

Grâce à la position de Wavestone en tant que leader mondial, et particulièrement européen, dans le domaine de la cybersécurité, plusieurs interviews, groupes de discussion et ateliers ont été organisés. Des informations précieuses ont été recueillies auprès d’interlocuteurs variés, offrant une vision complète qui prend en compte les perspectives de toutes les parties prenantes et permettant de poser les bases du développement du CRA. 

Définition et périmètre 

Le CRA est une proposition législative qui définit les obligations des fabricants, importateurs et distributeurs de produits contenant des éléments numériques commercialisés dans l’UE, tous devant porter le marquage CE dans tous les secteurs. Tel que défini dans la réglementation, cela inclut « tout produit logiciel ou matériel ainsi que ses solutions de traitement de données à distance, comprenant des composants pouvant être commercialisés séparément ». L’objectif de cette réglementation est non seulement de sécuriser les produits autonomes, mais aussi d’assurer la sécurité des chaînes de transmission de données et des infrastructures centrales grâce à l’application de cette norme. 

À cette notion de produit s’ajoute une notion de criticité, le CRA distingue donc deux types de produits : les produits avec des éléments numériques et les produits critiques avec des éléments numériques. Comme détaillé ci-dessous dans la partie « Checklist de conformité au CRA », cela influencera la manière dont la conformité pourra être atteinte. 

Quelques exemples de produits avec des éléments numériques incluent les produits de consommation, les smart cities et les logiciels non essentiels. Les produits critiques avec des éléments numériques comprennent, par exemple, les systèmes de contrôle industriel et les pare-feu. La liste détaillée des produits concernés se trouve dans les annexes de la réglementation. 

 Cependant, comme détaillé ci-dessous dans « Un écosystème complexe », le CRA ne s’applique pas universellement, et les produits de certains secteurs spécifiques ne sont pas tenus de se conformer aux exigences. 

Parties prenantes et responsabilités 

Le CRA impacte tout le cycle de vie des produits numériques, depuis le développement par les fabricants, importateurs et distributeurs jusqu’au consommateur final, mais aussi la gestion des vulnérabilités depuis la conception jusqu’à la fin de vie du produit, au travers d’une responsabilité partagée. 

Exigences essentielles  

Comme mentionné précédemment, l’objectif du CRA est de garantir un niveau suffisant de cybersécurité dans les produits contenant des éléments numériques. Pour ce faire, il introduit des exigences essentielles reposant sur trois piliers  

• Sécurité des produits : Assurer que les produits sont conçus, développés et fabriqués pour atteindre des niveaux de cybersécurité appropriés et qu’ils sont exempts de vulnérabilités exploitables connues. 
• Documentation utilisateur : Fournir une documentation pour garantir une utilisation sécurisée, depuis la mise en service jusqu’à la fin de vie du produit. 
• Gestion des vulnérabilités : Identifier et documenter les vulnérabilités, réaliser des tests de sécurité réguliers, et mettre en place une politique de divulgation des vulnérabilités. 

En cas de non-conformité aux exigences essentielles, des sanctions peuvent être appliquées à l’une des trois parties prenantes. Comme pour le RGPD, chaque État membre doit déterminer les sanctions applicables en cas de violation de cette réglementation. Les pénalités sont basées sur le chiffre d’affaires annuel de l’entreprise et la gravité de l’infraction, avec des amendes pouvant atteindre 15 millions d’euros ou 2,5 % du chiffre d’affaires annuel mondial total pour les violations graves. 

Comment se conformer au CRA ? 

Chronologie du CRA  

Le CRA a été un projet à long terme, avec presque 10 ans entre l’identification du besoin et la mise en application, reflétant la complexité de l’établissement de réglementations de cybersécurité complètes: 

Les entreprises ont jusqu’en 2026 pour se conformer, avec des obligations intermédiaires. Des exigences similaires peuvent être trouvées dans d’autres réglementations, telles que la NIS2, mais contrairement à d’autres réglementations, le CRA ne nécessite pas de transposition nationale. Le CRA a été adopté par le Parlement européen en mars 2024, et il attend un vote du Conseil européen pour devenir une loi. 

Un écosystème complexe 

L’une des principales préoccupations soulevées lors de la préparation était de savoir comment naviguer dans la multitude de réglementations existantes et parvenir à une harmonie réglementaire, en particulier dans les secteurs où les normes de sécurité, de protection de la vie privée et de cybersécurité s’entrecroisent.  

Le CRA vise à favoriser l’interopérabilité en s’alignant sur le cadre général de la sécurité des produits, sur les exigences de la loi sur la cybersécurité pour les produits, processus et services TIC, et sur les normes de marquage CE pour la conformité européenne. 

Pour simplifier la mise en conformité, le CRA inclut des présomptions de conformité avec les réglementations existantes telles que la directive RED, la loi sur l’IA et certaines règles sectorielles.  

Toutefois, le CRA ne s’applique pas de manière universelle ; certains secteurs, tels que le secteur médical, l’aviation et l’automobile, sont déjà régis par des réglementations établies et sont donc exemptés des dispositions de la réglementation. 

 Checklist de conformité au CRA 

La mise en conformité au CRA implique une compréhension approfondie du texte principal du règlement et de ses deux annexes, qui détaillent la liste des produits concernés, les exigences essentielles, les obligations des fabricants, des importateurs et des distributeurs, ainsi que les autorités nationales compétentes et les sanctions.  

Le processus de certification varie en fonction de la criticité du produit : 

• Pour les produits non critiques : une auto-évaluation est nécessaire. 
• Pour les produits critiques : une évaluation par un tiers est nécessaire, ce qui signifie que la conformité du produit au CRA sera évaluée par une entité certifiée. Au moment de la rédaction de cet article, les schémas de certification exacts n’ont pas encore été spécifiés, mais en France, la certification CESTI est en discussion. 

Cinq points de contrôle principaux doivent être pris en compte pour assurer la conformité :   

1. Analyse d’écarts législatifs : Identifier les écarts entre les pratiques actuelles et les exigences du CRA en examinant les politiques, les processus et les contrôles existants en matière de cybersécurité afin d’identifier les zones nécessitant une amélioration. 
2. Évaluation de la sécurité des produits : Effectuer des évaluations approfondies pour garantir l’identification et la sécurité des produits.  
3. Mise à jour des instructions destinées aux utilisateurs : Fournir une documentation claire et complète à l’intention des utilisateurs en veillant à ce que tous les produits soient accompagnés d’une documentation conforme aux normes de la réglementation. 
4. Gestion des vulnérabilités : Mettre en place un processus d’identification et de partage des vulnérabilités. 
5. Revue de l’organisation interne : Mettre en œuvre une procédure permanente pour assurer la conformité, couvrant les points clés mentionnés ci-dessus et surveiller les changements de produits ou de législation qui pourraient impliquer de nouveaux écarts à remédier. 

En conclusion, le Cyber Resilience Act représente un cadre complet pour renforcer la cybersécurité des produits numériques au sein de l’UE. La conformité avec cette réglementation nécessite une préparation approfondie. Pour les entreprises, se conformer au CRA n’est pas seulement une obligation légale, mais aussi une opportunité d’améliorer leur position sur un marché de plus en plus conscient des enjeux de cybersécurité. 

Cet article Cyber Resilience Act : Une révolution qui redéfinit la sécurité des produits et transforme l’écosystème est apparu en premier sur RiskInsight.

L’accroissement des exigences de sécurité concernant tant les environnements industriels que les objets connectés ont provoqué une profusion des clés cryptographiques, parfois difficile à gérer, dans les entreprises. Celles-ci servent à la fois à chiffrer et déchiffrer des documents ou échanges, mais aussi à la vérification de l’authenticité de messages ou fichiers, par exemple lors de la mise à jour du logiciel d’un composant, pour s’assurer de son intégrité. 

Une solution au problème de la complexité de gérer de nombreuses clés cryptographiques dans une entreprise est de mettre en place un KMS, pour Key Management System. Cet outil aide à protéger les données, la sécurité des produits et des processus sous la forme d’un outil centralisé de gestion des clés cryptographiques.  

Au-delà d’une simple standardisation des processus, ils peuvent aider à régler des problèmes tels que la génération de clés différentes en grand nombre, le stockage et accès aux clés ou encore la dépréciation des clés. 

Pourquoi utiliser un KMS ? 

Les KMS (Key Management Systems) sont des systèmes de gestion de clés cryptographiques qui permettent aux entreprises de gérer de manière centralisée et sécurisée leurs clés de chiffrement. Ils s’adressent aux organisations gérant de nombreuses clés cryptographiques, et améliorent ainsi la sécurité de leurs environnements, en standardisant les processus et en apportant des API pour la réalisation des fonctions crypto (signature, chiffrement, déchiffrement). Les organisations ayant de grands réseaux informatiques, mais aussi ceux industriels comprenant des objets connectés tels que des capteurs, des actionneurs ou des systèmes embarqués, ou vendant des produits connectés sont particulièrement concernées. 

L’importance d’une bonne gestion des clés est cruciale pour la cybersécurité. Les processus de chiffrement, de signature ou de vérification sont essentiels pour beaucoup d’organisations, même s’ils paraissent parfois comme transparents aux opérationnels. Il est important que les clés de chiffrement soient gérées de manière optimale, afin d’éviter par exemple un stockage non sécurisé des clés ou l’utilisation de la même clé pour plusieurs appareils. 

Nous allons examiner de plus près ce qu’est un KMS, comment il fonctionne et pourquoi il peut devenir essentiel. Plusieurs types de KMS seront présentés, ainsi que les avantages liés à leur utilisation et les difficultés à leur intégration. Enfin, quelques clés seront données pour cibler plus précisément les entreprises qui peuvent bénéficier de ce type d’outil. 

Pour plus d’informations sur l’architecture KMS, vous pouvez également regarder la conférence de Paul Chopineau à l’occasion de la Miami S4x24 : https://youtu.be/J5aeAYxcc24?feature=shared. 

Figure 1 : Architecture type d’un KMS 

Les différentes manières de déployer un KMS 

Il existe plusieurs manières d’implémenter un KMS, selon les options proposées par leur constructeur. Certains sont proposés en mode SaaS. D’autres peuvent être installés sur les serveurs de l’entreprise (on premise), et il existe aussi des KMS hybrides pour lesquels les clés sont stockées on premise mais l’applicatif est dans le cloud. 

Les premiers sont des solutions cloud qui permettent de gérer les clés de chiffrement depuis un ordinateur ou un serveur. Ce sont des produits plus scalables et agiles, aussi plus faciles à déployer et à mettre à jour. En revanche, la sécurité des clés sera dépendante de celle du service cloud, même s’il est possible d’introduire des surchiffrements. 

Les KMS on premise sont des solutions logicielles et matérielles qui permettent de gérer les clés cryptographiques en utilisant des serveurs et HSM internes à l’organisation. Ils sont généralement plus personnalisables et parfois plus adaptés à des besoins spécifiques que les KMS déployés en mode SaaS. En revanche, leur intégration sera plus longue et leur coût d’achat (CAPEX initial) sera plus élevé. Leur avantage est aussi qu’ils peuvent permettre à une entreprise de s’assurer de sa souveraineté sur ses clés cryptographiques. Ils conviennent donc mieux aux entreprises ayant des exigences très fortes de sécurité et une capacité plus importante d’investissement initial 

Enfin, les KMS hybrides pourraient représenter un juste milieu entre sécurité optimale et facilité de déploiement. L’objectif est de garder le contrôle sur les clés, celle-ci étant dans ce cas sauvegardées sur site, mais de bénéficier d’une plus grande facilité de déploiement et de montée en charge grâce à un applicatif hébergé dans le cloud. Le déploiement de l’applicatif est ainsi facilité, mais il reste à installer les ressources matérielles de gestion des clés (HSMs). La sécurité des clés s’approche de celle d’une solution on premise, mais le logiciel rend celle-ci dépendante du service cloud. Attention néanmoins à se protéger d’une exploitation frauduleuse des clés depuis les infrastructures cloud qui pourrait être plus difficile à détecter que pour un KMS on premise. 

Figure 2 : Les trois implémentations possibles pour un KMS 

Il est aussi possible de classer les produits sur le marché selon le type de fournisseur. 

On retrouve ainsi premièrement les produits des grands acteurs du cloud : 

• Amazon avec AWS Key Management Service (AWS KMS), 
• Microsoft qui propose Azure Key Vault, 
• Google avec le Cloud KMS (Key Management Service), 
• IBM qui propose un KMS (Key Management Service) intégré à IBM Cloud Private. 

Leurs produits s’intègrent parfaitement aux services fournis par ces grands fournisseurs, y compris leurs outils de stockage sécurisé des clés, comme le KMS de Google, qui permet de créer des clés dans le cloud et les stocker dans des HSM. 

Des entreprises spécialisées se positionnent également sur le marché : 

• Cryptomathic avec son CKMS (Crypto Key Management System), 
• Entrust, dont le produit se nomme KeyControl, 
• HashiCorp, avec son produit Vault, 
• Utimaco, dont le KMS se nomme KeyBridge, 
• Thales, avec par exemple son Trusted Key Manager (TKM). 

Ces entreprises proposent notamment de faire fonctionner leurs outils avec des ressources logicielles, telles que les KMS de Microsoft, Amazon et Google pour HashiCorp ou encore VMware pour Entrust. Mais aussi des ressources matérielles, tels que des HSM qui apportent un niveau supérieur de sécurité contre les attaques physiques. 

Enfin, le marché a aussi été rejoint par des intégrateurs, comme Atos avec sa suite Trustway DataProtect KMS qui se destine à une installation on premises, sur le matériel de l’entreprise. 

Thalès enfin, qui se positionne à la fois comme fournisseur hardware, comme éditeur et comme intégrateur, propose plusieurs produits de gestion des clés pour les entreprises. Ceux-ci fonctionnent de mise avec ceux proposés tant par les acteurs plus spécialisés qu’avec les services cloud préférés de leurs clients. 

Figure 3 : Trois grands types de fournisseurs de KMS 

Les avantages à utiliser un KMS 

Les KMS (Key Management Systems) sont des outils dont le potentiel complet est encore à explorer, mais qui peuvent se révéler particulièrement utiles pour gérer de manière centralisée et sécurisée les clés de chiffrement d’une entreprise. Voici quelques avantages que l’on peut tirer de leur usage. 

Tout d’abord, les clés seront plus faciles à déployer. Les KMS permettent de générer rapidement et de manière automatisée de nouvelles clés cryptographiques, ce qui est particulièrement utile lorsqu’il est nécessaire de générer de nombreuses clés différentes pour transmettre à des produits, objets connectés ou systèmes industriels. 

Dans un contexte où les clés des objets connectés ne sont souvent pas renouvelées et sont gérées de manière non standardisée, les KMS permettront aux entreprises d’introduire le niveau de sécurité qui leur permettra de respecter les futures régulations des systèmes IoT. Même chose pour le chiffrement de données sensibles dans une base de données, qui est le cas d’usage à l’origine de la naissance des produits KMS. 

Pour améliorer le stockage et l’accès aux clés, les KMS offrent des APIs et interfaces centralisées, intégrant une gestion des permissions en lien avec la gestion des accès et identités (IAM), ce qui peut être particulièrement utile pour les entreprises disposant de nombreux types de clés et utilisateurs des clés de chiffrement. La difficulté sera de convaincre les fournisseurs et partenaires extérieurs à l’entreprise de rentrer les clés par le biais du KMS. Ce sera un élément à négocier dans les contrats cadres futurs. 

Les KMS permettent également de gérer la dépréciation des clés de chiffrement, en les remplaçant automatiquement par de nouvelles clés lorsqu’elles expirent, qu’elles sont compromises ou tout simplement obsolètes, par exemple à l’issue d’un changement dans la PSSI. Cela permet de maintenir la sécurité de vos données à tout moment. 

En résumé, les KMS sont des outils précieux pour gérer efficacement et de manière sécurisée les clés de chiffrement d’une entreprise. Ils permettent ainsi d’améliorer sa conformité aux réglementations et aux normes de sécurité en s’assurant que les procédures de gestion de clés et les clés utilisées sont conformes aux standards établis. 

Les pièges à éviter lors de l’implémentation d’un KMS 

Mettre en place un KMS (Key Management System) est une démarche lourde, qui peut être freinée ou même stoppée par les aspects suivants : 

• Coût du déploiement : les KMS peuvent être très coûteux à déployer. Il s’agit des frais de licence, mais aussi des ressources matérielles comme les HSM à mettre en place pour le stockage des clés et à dimensionner en fonction de l’usage qui en sera fait (fréquence d’accès, volumétrie). 

• Complexité de la mise en place : la mise en place d’un KMS peut être complexe, en particulier pour les entreprises disposant de nombreux appareils ou systèmes chiffrés ; pour lesquelles il aura justement une forte valeur ajoutée. Il peut être nécessaire de mettre en place de nombreuses intégrations pour communiquer avec les APIs du KMS en fonctions des différents cas d’usages. 

• Procédures de change management spécifiques : il sera parfois difficile de convaincre tous les utilisateurs de l’entreprise de l’importance de la mise en place d’un KMS, et de les inciter à utiliser cet outil de manière efficace. Pour résoudre ce problème, il faudra s’appuyer sur une stratégie de communication et de formation pour sensibiliser les utilisateurs à l’importance de la sécurité des clés de chiffrement et à l’utilité du système. 

• Compétences rares sur le marché : des architectes informatiques, des spécialistes en cryptographie, ou encore des gestionnaires de projets capables de piloter des projets structurants en cybersécurité. Tout autant de profils durs à sourcer et qui seront d’autant plus nombreux à recruter qu’il existe de cas d’usages de clés cryptographiques au sein de l’organisation. L’appel à des expertises externes sera alors très profitable et difficile à éviter. 

Les KMS, une solution essentielle pour la gestion sécurisée des clés de chiffrement 

En conclusion, les KMS sont une solution essentielle pour gérer de manière sécurisée les clés de chiffrement de votre entreprise. Tant pour les grandes entreprises disposant de nombreux appareils ou systèmes chiffrés, ou une petite entreprise rencontrant le même type de problématiques, un KMS peut grandement aider à centraliser et à sécuriser la gestion des clés crypto. 

A titre d’exemple, prenons le cas d’une entreprise de fret. Celle-ci doit gérer de nombreux composants dans les véhicules comme des capteurs pour s’assurer du respect de la chaîne du froid ou simplement des appareils pour le suivi les produits. Ces objets se connectent à des réseaux publics ou d’entreprise, transmettent des données chiffrées, mais sont aussi mis à jour régulièrement. Il faut donc signer les firmware lors du déploiement d’une mise à jour, et s’assurer que les clés de chiffrement des données que transmettent les capteurs, pour s’assurer de leur intégrité et de leur confidentialité, sont bien stockées de manière sécurisées, mais aussi sont à disposition des opérateurs en cas de modification d’un capteur. Pour tous ces processus, à la fois pour les automatiser mais aussi pour faciliter le travail des opérateurs et s’assurer que chaque intervenant ne dispose d’un accès qu’aux clés qu’il utilise, le KMS sera particulièrement utile. L’outil se chargera de la génération des clés, ou de leur récupération si elles ont été générées de manière externe, puis de tout le reste des étapes du cycle de vie de la clé. 

Il reste à noter que l’évaluation de la pertinence de cette technologie est à prendre au sérieux. Des études en amont ainsi qu’une procédure d’appel d’offre seront nécessaires pour s’assurer de la mise en place du bon outil. En réalisant ces procédures avec une vision précise sur les usages métiers, l’entreprise s’assurera de ne pas avoir à en changer par la suite. 

Cet article Les KMS : la clé de la gestion sécurisée des objets cryptographiques  est apparu en premier sur RiskInsight.

RSSI, DSI et équipes DevSecOps s’interrogent tous sur la manière de le mettre en pratique et de l’exploiter.

Qu’est-ce que le SBOM et dans quel contexte intervient-il ?

Le SBOM (Software Bill of Materials) est un inventaire formel, généralement au format Xlsx, JSON, XML ou texte brut, qui est conçu pour être lu par des machines. Il contient des informations détaillées sur les composants logiciels d’un système, y compris leurs dépendances, leurs attributs et leurs relations hiérarchiques. L’objectif principal d’un SBOM est de fournir une vue complète et à jour de tous les éléments logiciels qui composent une application ou un système. (source : NTIA-Software-Bill-Of-Materials)

À l’instar d’un produit physique, un logiciel est un ensemble complexe composé de divers éléments. Il comprend du code développé en interne, des composants tiers (qu’il s’agisse de bibliothèques open source ou de modules soumis à différentes licences) ainsi que l’ensemble des outils nécessaires à l’assemblage du produit final.

Or, à chaque nouvelle vulnérabilité découverte par des chercheurs ou exploitée par des hackers, les fournisseurs et acheteurs, se retrouvent confrontés à une question cruciale : où se situent les éventuelles vulnérabilités critiques au sein de leur produit ?

Aujourd’hui, l’analyse de Wavestone atteste de manière formelle que le SBOM est indéniablement un élément essentiel pour résoudre cette problématique.

Méthodes de génération du SBOM

Une analyse technique approfondie des outils disponibles sur le marché a révélé les méthodes de génération des SBOMs (Software Bill of Materials).

Trois sources principales émergent pour créer un SBOM à partir d’un logiciel :

• Code Binaire (compilé)
• Code source du projet
• Conteneur d’image, généré par des plates-formes telles que Docker.

Ces trois sources ont la capacité de produire un fichier conforme aux standards établis, notamment SPDX et CycloneDX. Cependant, il est essentiel de noter que tous les outils ne prennent pas en charge ces trois entrées de manière uniforme.

Le défi technique réside, par exemple, dans la décompilation du code binaire, qui peut parfois entraver son intégration. Dans de tels cas, la recherche d’indicateurs spécifiques préalablement définis au sein du code s’avère être une méthode efficace pour identifier la majeure partie des interdépendances hiérarchiques dans un format approprié.

Types d’entrées pour la génération d’un SBOM

Malgré ces techniques d’extraction et d’analyse de code, l’exhaustivité des données n’est pas pour autant garantie et une vérification additionnelle doit être considérée.

Une génération facilitée mais une exploitation qui reste à déterminer et pose encore de nombreuses questions

La création d’un SBOM, s’est considérablement simplifiée grâce à la présence d’acteurs majeurs spécialisés sur le marché, tels que Dependency Track, Adolus ou encore Fossa, pour n’en nommer que quelques-uns. De plus, les outils d’Analyse de Composition Logicielle SCA, bien établis au sein des équipes de développement de nos clients offrent désormais la possibilité de générer et de lire un SBOM.

Sa génération n’est aujourd’hui plus un défi majeur, en raison de la mise en œuvre des standards énumérés plus haut. Ils facilitent la génération automatisée du SBOM en fournissant des directives claires sur la manière dont les informations sur les composants doivent être structurées et présentées.

Cependant, les systèmes conçus pour l’analyser ne sont pas encore pleinement matures. Par exemple. Les entreprises qui reçoivent ces inventaires se trouvent souvent confrontés à des questions sur la manière de les utiliser et de les partager avec d’autres parties. Par ailleurs, à cette problématique technique s’additionne des problématiques organisationnelles car le cadre d’utilisation entre organisations n’est pas encore clairement défini.

Néanmoins, des acteurs travaillent activement à mettre en place une architecture d’intégration sécurisée de ces SBOM au sein de leurs pipelines CI/CD. Actuellement, la récupération fiable du SBOM d’un tiers reste un défi. Les préoccupations sur l’échange et le partage émergent dès que l’on aborde ce sujet. La diversité des contrats avec les fournisseurs, qui souhaitent protéger leur propriété intellectuelle, et la difficulté de centralisation posent des défis au contenu de ce type d’inventaire. Chaque inventaire est élaboré de manière hétérogène, sans suivi ni cadre réglementaire uniforme imposé. D’un point de vue technique, chaque entité a la liberté de remonter les informations de son choix.

A date, nous constatons que les pionniers dans le domaine, optent pour la génération interne de leurs SBOM, y compris sur les logiciels tiers. Cette approche offre davantage de contrôle sur la qualité et la spécificité des données, soulignant la nécessité d’une réglementation plus détaillée et de normes plus strictes pour assurer la fiabilité des échanges d’inventaires logiciels.  

Le SBOM intégré au cœur de vos processus logiciels

Toutes ces lacunes ont incité à concevoir un processus optimal à l’état théorique pour le moment, afin d’intégrer un SBOM au sein d’un pipeline CI/CD, processus pouvant être décomposé en quelques étapes.

1. Création d’un espace de génération et de collecte du SBOM, en Automatisant la collecte de ces données pour garantir leur précision et leur exhaustivité ;
2. Stockage des SBOM dans un Répertoire, en Configurant un référentiel centralisé pour stocker tous les SBOM générés. Il peut s’agir d’un référentiel de gestion de versions ou d’un système de stockage de données adapté ;
3. Distribution d’un Paquet SBOM sur Demande d’un Client, en s’assurant que les SBOM sont facilement accessibles et que les clients peuvent les récupérer de manière sécurisée.

Projection sur l’intégration d’un SBOM au sein d’une chaîne d’approvisionnement logiciel

Cette prospective théorique ouvre la voie à une automatisation du processus de génération, stockage et diffusion des inventaires et rapports de vulnérabilité.

Cela offrira aux parties prenantes la capacité de :

• Recevoir en temps réel des SBOM et des rapports de vulnérabilité ;
• Authentifier la légitimité des artefacts reçus (conteneurs d’images, documents, etc..) ;
• Etablir une confiance et une validation par le bais de la transparence au cœur du processus de production logicielle.

Un futur radieux pour le SBOM ?

 Les instances politiques prennent conscience du niveau d’impréparation de leurs infrastructures face à la montée en puissance des cyberattaques. Dans ce contexte, le SBOM est de plus en plus considéré comme un moyen efficace d’accroître la réactivité en matière de vulnérabilités susceptibles d’affecter un grand nombre d’entreprises de manière concomitante.

Même si le marché n’est pas encore tout à fait prêt pour une transition vers une utilisation généralisée de cette solution, il est courant que la réglementation, même si elle peut sembler arbitraire, influence profondément la trajectoire dans une nouvelle direction.

Il est probable que l’Europe finira par converger vers la réglementation établie aux États-Unis, même si celle-ci semble encore être à un stade préliminaire et incomplet, en particulier en ce qui concerne les mécanismes de partage et d’échange de ces inventaires.

Dans le contexte actuel, les acteurs concernés se voient contraints de réévaluer leurs critères de priorité. Il sera important de disposer des données sur la composition des logiciels, l’origine de ses composants, leur provenance, les vulnérabilités connues, et d’avoir confiance dans le processus de production et de contrôle de qualité.

Cependant, il est nécessaire de remettre à l’ordre du jour la série de défis auxquels ils se confrontent plus généralement :

• Données lacunaires ou incomplètes, l’absence de données exhaustives sur la composition des logiciels peut rendre difficile l’évaluation des risques.
• Approches ad hoc pour le partage de données, les méthodes non standardisées et les approches improvisées pour le partage d’informations peuvent rendre la communication inefficace et peu fiable.
• Coûts additionnels pour la collecte et la maintenance des données, la collecte, la vérification et la mise à jour des informations sur la composition des logiciels peuvent engendrer des surcoûts ;
• Absence de standardisation, le manque de normes dans la collecte et le partage des données rend difficile la comparaison et l’analyse des informations entre les différentes parties prenantes ;
• Gouvernance et confidentialité des données, La gestion des données sensibles sur la composition des logiciels soulève des préoccupations quant à leur confidentialité, intégrité et disponibilité

Cet article Pourquoi le SBOM est considéré comme un allié indispensable de la sécurité de vos produits ? est apparu en premier sur RiskInsight.

Azure, ces dernières années, s’impose de plus en plus dans ce secteur, comme a pu le souligner le Gartner, qui les classe dans les leaders visionnaires des plateformes IIoT [1] en raison de ses capacités, et de sa couverture quasiment complète de tous les cas d’utilisation et secteurs d’activité.

L’IoT, par nature souvent largement exposé, voire sur Internet, peut-être la cible d’attaques.

Avant de passer à des recommandations spécifiques pour protéger vos dispositifs IoT et vos données, examinons comment les différents services d’Azure IoT peuvent être utilisés ensemble pour créer des solutions IoT sécurisées.

Présentation de l’offre Azure IoT

Microsoft Azure IoT est une plateforme de bout en bout pour la connectivité, l’analyse et la visualisation de données provenant d’appareils IoT. Elle offre également une interconnexion avec les autres services standards d’Azure comme Azure Machine Learning ou encore Azure SQL Database.

Azure IoT propose deux écosystèmes de solutions à ses clients :

• Azure IoT Central est une aPaaS, application Platform as a Service, entièrement managée qui simplifie la création de solutions IoT. Ce service est responsable de connecter, gérer et exploiter des flottes d’appareils, et fournit à une interface utilisateur de gestion. Azure IoT Central est en réalité un agrégat de différents services Azure IoT comme Azure IoT Hub ou encore Azure IoT Hub Device Provisioning Service (DPS).

Azure IoT Central propose des modèles d’application selon plusieurs domaines d’activité : Retail, Santé, Energie, Industrie, etc., et vise une mise en œuvre « clés en main ».  

• Un écosystème personnalisé grâce aux différents services PaaS, Platform as a Service, d’Azure. Dans cet écosytème, deux services ; Azure IoT Hub et Azure Digital Twins sont les fondations d’une solution IoT. Nous les avons également combinés à Azure Device Provisionning et Azure Device Update pour une couverture des besoins cybersécurité optimale.

Ces deux écosystèmes permettent à Azure de répondre à tous types de besoins IoT et IIoT :

• Azure IoT Central est un très bon service si vous souhaitez développer rapidement une application peu complexe grâce à son catalogue de modèle d’application.
• Si vous souhaitez une solution personnalisée, ou avec des fonctionnalités non supportées par Azure IoT Central : optez pour un écosystème fondé sur Azure IoT Hub.

Maintenant que nous avons une bonne compréhension des écosystèmes d’Azure IoT, il est important de se concentrer sur la sécurisation de ces écosystèmes. Comment protéger efficacement des dispositifs IoT et des données lors de l’utilisation des services Azure IoT ? C’est ce que nous allons étudier dans les prochaines parties.

Préambule : l’outil Azure CLI

Afin de gérer des ressources Azure, Microsoft met à disposition plusieurs outils, la plupart étant utilisables en CLI (Command Line Interface, ou en lignes de commandes). L’outil proposant le plus de fonctionnalités pour la gestion étant Azure CLI.

Cet outil, disponible pour les systèmes d’exploitation de type Windows et UNIX, permet notamment à un utilisateur membre d’un environnement Azure de gérer et d’obtenir des informations concernant des ressources Azure. Il est à noter que l’éventail des possibilités de cet outil varie en fonction des droits que possède l’utilisateur sur les ressources en question.

Pour l’installer, Microsoft met à disposition une page dédiée expliquant les étapes pour tout type d’environnement.

Afin de l’utiliser, il suffit de se connecter à un compte utilisateur Azure via l’interface de commande choisie (Powershell ou Bash), puis d’entrer les commandes voulues. Lorsque l’utilisation de cet outil est terminée, une déconnexion du compte est recommandée.

Une utilisation classique de cet outil est présentée ci-dessous :

La documentation de cet outil, présentant et expliquant l’ensemble des commandes possibles, est disponible à cette adresse.

Cet outil sera utilisé par la suite lors d’exemple de manipulations techniques.

1^er vecteur de sécurisation : authentification des objets

L’authentification des appareils est cruciale pour une infrastructure Azure car elle permet de garantir que seuls les dispositifs autorisés puissent accéder aux ressources Cloud. Les services Azure IoT supporte deux principaux moyens d’authentification pour les dispositifs IoT :

• Un Jeton SAS (Shared Access Signature, ou SAS Token en anglais) est une chaine de caractères permettant d’authentifier des appareils, ainsi que des services. Un jeton SAP à la structure suivante :

Ce type d’authentification a une durée de validité définie et des permissions, qui lui sont attribué à partir d’une stratégie d’accès, sur un périmètre donné. La signature, quant à elle, est un élément crucial car elle est responsable de garantir la sécurité des communications entre l’objet et les services Azure, mais également de prouver l’identité du dispositif. Cette signature est générée à partir d’un secret qui doit être propre à chaque appareil.

• Un certificat X.509 [2] est un certificat numérique permettant une authentification forte de l’objet. Il contient des informations sur l’entité émettrice du certificat, la durée de validité du certificat mais également l’identité du sujet (par exemple : l’objet). L’une des forces des certificats est la capacité à pouvoir créer des chaines de certificats, et ainsi créer des relations de confiance:

En termes de sécurité, les certificats X.509 offrent un niveau de sécurité plus élevé, en supposant un algorithme cryptographique à l’état de l’art, car ils permettent de représenter des relations de confiance. Cependant, la gestion et l’utilisation des certificats peut impliquer une complexité supplémentaire pour un projet IoT.

Afin de forcer l’utilisation des certificats X.509 pour authentifier des objets connectés, il est possible d’interdire les jetons SAS pour un IoT Hub. En effet, les IoT Hubs d’Azure possèdent trois propriétés liées à l’utilisation ou non des jetons SAS :  disableLocalAuth, disableDeviceSAS et disableModuleSAS. Par conséquent, la bonne pratique associée à l’interdiction des jetons SAS passe par l’attribution de ces trois paramètres à True. Cette manipulation peut être réalisée à l’aide de l’outil Azure CLI :

La vérification des valeurs de ces mêmes paramètres peut également être réalisée à l’aide d’Azure CLI :

Dans l’exemple de réponse ci-dessous, la propriété disableDeviceSAS a été correctement paramétrée, ce qui n’est pas le cas des deux autres.

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

Le choix du moyen d’authentification pour Azure IoT dépendra des exigences de sécurité de votre solution. Si vous avez besoin d’une sécurité élevée et que vous avez une infrastructure pour gérer les certificats, alors l’authentification par certificat X.509 est une bonne option. Cependant, si vous recherchez une solution simple à gérer et à utiliser, le jeton SAS pourrait être plus adapté à vos besoins.

2^ème vecteur de sécurisation : RBAC et alertes

L’assignement des rôles sur votre infrastructure Azure IoT doit être réfléchi et défini selon les besoins des utilisateurs. Une définition de rôles et de permissions précise permet de limiter l’accès aux ressources et aux divers fonctionnalités disponibles sur la plateforme. Les différents services Azure IoT fournissent une multitude de rôles préconfigurés qui peuvent être adaptés à vos besoins et à votre organisation. Ensuite, appliquer le principe du moindre privilège, et limiter le nombre de comptes disposant de privilèges importants, permet d’améliorer le niveau de sécurité de votre infrastructure Azure IoT.

Azure CLI permet notamment de lister les utilisateurs possédant des droits sur la ressource Azure IoT souhaitée, ainsi que leurs rôles associés. La commande suivante permet de réaliser cette action :

Il est possible d’utiliser des sélecteurs de chaînes de caractères (Select-String pour Powershell, grep pour Bash) afin de ne récupérer que les informations souhaitées.

Dans l’exemple ci-dessous, les noms, types et rôles ont été les seuls éléments récupérés à l’aide de Select-String :

La fonction des rôles intégrés Azure est disponible à cette page.

De plus, la configuration d’alertes basées sur les métriques de vos services Azure IoT est un autre outil à prendre en compte. Des alertes peuvent être configurées pour détecter des comportements suspects ou des anomalies, et ainsi permettre une investigation rapide sur votre infrastructure. Azure met à la disposition de ses clients une large collection de signaux permettant de définir des conditions d’alertes. Il est également possible de définir des signaux d’alertes customisés via le langage de requête utilisé par Azure Log Analytics.

Le Portail Azure est le moyen le plus facile pour mettre en place des alertes basées sur les données collectées par le IoT Hub. Par exemple, pour définir une règle d’alerte de journal, il faut :

1. Aller sur la page de management du IoT Hub souhaité ;
2. Aller dans la sous-catégorie Logs de la catégorie Monitoring;
3. Choisir une règle en utilisant le langage de Azure Log Analytics ;
4. Ajouter une règle d’alerte liée à cette requête ;
5. Choisir l’opérateur, l’unité, la valeur seuil, la récurrence de vérification et la période concernée par la règle.

Ces actions sont résumées par les captures d’écran ci-dessous :

Il suffira ensuite de choisir un groupe d’action lié à un type d’action (envoi de mail, de SMS, etc.).

L’exemple donné entrainera une action si le nombre de connexions échouées d’objets connectés à l’IoT Hub concerné dépasse les 10 échecs en 10 minutes ou moins.

En complément, un guide détaillé prenant la forme d’un tutoriel est disponible sur la documentation Azure. Il est à noter que ce service est payant en supplément.

3^ème vecteur de sécurisation : le service en lui même

Enfin, la mise en place d’une configuration adéquate des services Azure IoT est un autre élément clé pour améliorer le niveau de maturité cyber de la plateforme. Cela inclut des options telles que par exemple les règles de routage ou encore paramétrer la version minimum de TLS utilisé par les appareils pour se connecter sur Azure IoT Hub.

Les règles de routage sont utilisées pour rediriger les messages des appareils IoT vers un point de terminaison (stockage, services, base de données, etc.) et sont paramétrables par des requêtes de routage. Il est recommandé de filtrer les messages entrants, via les requêtes de routage, afin d’augmenter la sécurité de votre solution IoT.

La vérification de la version minimale de TLS acceptée peut être faite à l’aide d’Azure CLI : en effet, un IoT Hub possède l’attribut minTlsVersion permettant de contrôler cette propriété. Cette vérification est réalisée à l’aide de la commande suivante :

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 :

En synthèse

La sécurité est un enjeu majeur pour les projets IoT : Microsoft, avec son produit Azure IoT, fournit une plateforme IoT répondant à une majorité des besoins IoT, et ce de manière sécurisée, sous couvert d’en faire la bonne configuration. Au cours de cette article, nous avons abordé des recommandations permettant d’améliorer le niveau de sécurité de votre infrastructure Azure IoT.

Il est important de garder en tête que d’autres vecteurs d’attaques existent, tels que les vulnérabilités matérielles et logicielles ainsi que les réseaux utilisés par les dispositifs IoT.  En somme, la sécurité d’une infrastructure IoT est un défi complexe qui nécessite une approche de bout en bout.

Avec la participation de 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 Améliorer la sécurité de son infrastructure IoT : conseils de configuration et bonnes pratiques sur Azure IoT est apparu en premier sur RiskInsight.