Comprendre l'analyse des causes profondes dans le contexte de l'ICS

Les systèmes de contrôle industriel (SCI) constituent l'épine dorsale des infrastructures essentielles – réseaux électriques, stations de traitement de l'eau, raffineries de pétrole et installations de fabrication de produits chimiques.Comme ces environnements englobent la connectivité numérique et les dispositifs d'Internet des objets industriels (IIoT), la surface d'attaque s'étend de façon spectaculaire. Contrairement aux violations informatiques typiques, un compromis dans un SCI peut entraîner des dommages physiques, des catastrophes environnementales ou des pertes de vies humaines.

L'ACS dans le SCI diffère de l'ACS en matière de sécurité des TI parce qu'elle doit tenir compte des contraintes liées à la technologie opérationnelle (OT) : protocoles existants qui manquent de chiffrement, boucles de contrôle en temps réel qui ne tolèrent pas la latence et cycles de vie de sécurité qui peuvent être perturbés par des correctifs de sécurité.

Causes profondes communes des atteintes à la cybersécurité du SIC

Bien que chaque incident soit unique, des modèles apparaissent à travers les infractions à la SCI. Comprendre ces causes profondes communes aide les organisations à concentrer leurs ressources défensives.

Faiblesse des mots de passe et authentification inadéquate

De nombreux systèmes ICS dépendent toujours des identifiants par défaut partagés sur plusieurs appareils ou des mots de passe codés en dur dans des contrôleurs logiques programmables (PLC). L'attaque de ransomwares de Colonial Pipeline 2021, bien qu'elle soit principalement un compromis informatique, a mis en évidence la faiblesse de l'authentification sur les outils d'accès à distance pouvant conduire à un mouvement latéral dans des environnements OT.

Vulnérabilités non affectées des logiciels et des logiciels firmware

Les systèmes industriels fonctionnent souvent sur des systèmes d'exploitation dépassés comme Windows 7 ou XP, et les cycles de patch peuvent durer des mois ou des années en raison de tests de compatibilité avec des applications de contrôle.Cela crée une fenêtre d'exposition pour les vulnérabilités connues.L'attaque Triton/Trisis sur une usine pétrochimique saoudienne en 2017 a exploité les vulnérabilités dans Schneider Electric.Triconex contrôleur de sécurité – un dispositif qui n'a pas été patché parce que les opérateurs craignaient de perturber les fonctions de sécurité.

Absence de segmentation des réseaux entre les TI et les OT

Les réseaux plats sont la principale faiblesse structurelle des environnements ICS. Lorsque les réseaux informatiques et de contrôle d'entreprise ne sont pas correctement segmentés via des pare-feu, des DMZ ou des diodes unidirectionnelles, un courriel de phishing qui compromet un système d'affaires peut permettre aux attaquants de pivoter dans le réseau de contrôle. L'attaque du réseau électrique en Ukraine 2015 a réussi en partie parce que les attaquants ont utilisé le réseau informatique pour atteindre le réseau ICS, résultat direct d'une segmentation insuffisante.

Menaces d'initié : Malicieux et accidentel

Les menaces d'initiés dans ICS peuvent aller d'un ingénieur mécontent qui reprogramme un PLC pour causer un dysfonctionnement, à un entrepreneur qui relie par inadvertance un ordinateur portable infecté par des logiciels malveillants au réseau OT. Une étude de 2019 par l'Institut Ponemon a constaté que les initiés sont responsables de près de 25% des incidents ICS. La cause fondamentale est souvent une combinaison de contrôles d'accès inadéquats, d'absence d'analyse de comportement et d'une culture qui privilégie la commodité par rapport à la sécurité.

Capacités insuffisantes de surveillance et de détection

De nombreux environnements ICS ne disposent pas de systèmes de détection et de réponse (EDR), de surveillance du réseau ou de gestion d'informations et d'événements de sécurité (SIEM) qui sont adaptés aux protocoles OT. Sans visibilité dans le trafic réseau de contrôle, comme Modbus, DNP3 ou PROFINET, un attaquant peut se déplacer latéralement pendant des semaines ou des mois avant la découverte. L'attaque 2017 de NotPetya a touché de nombreuses organisations ICS, mais dans de nombreux cas, le malware était déjà présent sur les réseaux internes avant que le composant essuie-glaces ne soit activé. La cause principale était une lacune de surveillance qui n'a pas permis de détecter le compromis initial.

Méthodes d'analyse des causes profondes dans le SCI

Bien que les cadres d'intervention en cas d'incidents de TI constituent un point de départ, les méthodologies spécifiques au SCI intègrent le contexte opérationnel. Les approches suivantes sont largement utilisées dans les milieux industriels.

Les 5 Pourquoi

La technique 5 Whys est d'abord développée par Toyota et est simple à l'origine : demandez « pourquoi » à plusieurs reprises jusqu'à ce que la cause sous-jacente émerge. Par exemple, pourquoi le système de sécurité a-t-il échoué ? Parce qu'un firmware désuet permettait à un attaquant de la contourner. Pourquoi le firmware était-il dépassé ? Parce que le patch n'avait pas été testé pour la fonction de sécurité spécifique. Pourquoi les tests ont-ils été retardés ? Parce qu'il n'y avait pas de harnais de test automatisé. Pourquoi n'y avait-il pas de harnais de test ? Parce que le budget priorisait les nouveaux outils de validation.

Schéma de l'os de poisson (Ishikawa)

Pour une violation de la SCI, les catégories peuvent comprendre : (formation, sensibilisation, actions d'initiés), [Processus[ (gestion du changement, cycles de patchage, jeux de réaction incidente), Technologie[ (authentification, segmentation, conception de backend) et Facteurs externes (vulnérabilités de vengeurs, lacunes réglementaires). Une équipe cartographie chaque facteur contributif et le retrace à la colonne vertébrale du diagramme. Cette méthode est idéale pour les incidents complexes avec des défaillances multiples entreblocage.

Analyse des arbres de défaillance (ALÉ)

L'ALE est une méthode de déduction descendante souvent utilisée dans le domaine de la sécurité, mais également applicable aux atteintes à la sécurité. À partir de l'événement indésirable (la brèche), les analystes travaillent en arrière en utilisant des portes logiques (AND, OR) pour identifier des combinaisons de défaillances qui pourraient causer l'événement. L'ALE est particulièrement utile dans ICS parce qu'il reflète l'analyse de sécurité que les ingénieurs effectuent déjà. Par exemple, une brèche pourrait survenir si (A) le pare-feu est mal configuré ET (B) l'antivirus est périmé ET (C) le système de détection des anomalies n'est pas surveillé.

Le processus d'ACR en cinq phases

  1. Phase 1: Collecte et préservation des données[ — Imagerie légale des contrôleurs, des historiens, des postes de travail d'ingénierie et des registres de réseau. En OT, cela doit être fait avec soin pour éviter de perturber les processus critiques.
  2. Phase 2: Reconstruction de la chronologie des événements — Logs corrélés provenant de sources IT et OT. Les environnements ICS ont souvent des problèmes de synchronisation du temps (différents appareils utilisant différents serveurs NTP ou aucun du tout), de sorte que la normalisation du temps est critique.
  3. Phase 3: Identification de la vulnérabilité[ — Cartographie de la trajectoire d'attaque vers des faiblesses spécifiques, incluant non seulement les vulnérabilités techniques (VCE), mais aussi les lacunes de procédure, comme l'absence de vérifications des antécédents des entrepreneurs ou l'absence d'un comité d'examen officiel des changements.
  4. Phase 4: Détermination de la cause racine — Appliquer une ou plusieurs méthodologies (5 Pourquoi, os de poisson, FTA) pour converger sur la raison fondamentale. Souvent, la cause racine est une combinaison d'une vulnérabilité technique et d'un échec de processus.Par exemple, la politique de segmentation du réseau existait sur papier mais n'a jamais été vérifiée.
  5. Phase 5 : Développement et vérification des mesures correctives — Mise en oeuvre de mesures visant à remédier à la cause profonde, et non seulement aux symptômes. Les actions courantes comprennent la refonte de l'architecture réseau, les configurations des appareils de durcissement, la mise en oeuvre de boîtes de sable automatisées de gestion des patchs et l'introduction de la détection d'intrusion OT-aware.

Défis uniques de l'ACR dans les environnements ICS

La conduite de l'ACR dans un système de contrôle industriel présente des obstacles rarement rencontrés dans la sécurité des TI.

Technologies et protocoles patrimoniaux

De nombreux appareils ICS fonctionnent depuis 15 à 30 ans, en utilisant des firmwares qui ne peuvent être patchés ou même enregistrés. Les protocoles propriétaires de fournisseurs comme Siemens, Rockwell ou ABB peuvent ne pas avoir de caractéristiques de sécurité natives ou de logarithme normalisé. Les analystes ont souvent besoin de connaissances en ingénierie profonde pour interpréter le comportement des appareils.

Sécurité sur les contraintes de sécurité

Par exemple, exiger un changement de mot de passe tous les 30 jours peut sembler sûr, mais si un ingénieur est enfermé pendant une procédure d'arrêt d'urgence, la vie humaine pourrait être en danger. Le processus d'analyse des causes profondes doit impliquer des ingénieurs de la sécurité et des normes de référence comme ISA-62443 (IEC 62443) qui équilibrent la sécurité avec la sécurité fonctionnelle.

Capacités limitées de la médecine légale

Contrairement aux serveurs informatiques, de nombreux PLC et RTU ne disposent pas de stockage persistant pour les journaux. Les données d'événements peuvent être conservées dans une mémoire volatile qui disparaît sur redémarrage. Les outils médico-légaux conçus pour ICS, comme ceux de Dragos ou Nozomi Networks, peuvent capter des informations d'état, mais elles ne sont pas déployées universellement.

Pressions réglementaires et de conformité

Les industries telles que l'énergie, l'eau et la fabrication de produits chimiques sont soumises à des règlements (NERC CIP, NIST SP 800-82, Directive NIS de l'UE) qui peuvent imposer des procédures spécifiques de l'ARC. L'analyse doit produire un rapport qui satisfait les auditeurs sans exposer les vulnérabilités sensibles qui pourraient être exploitées.

Bâtir un programme efficace d'ACR pour le SCI

L'ARC ne devrait pas être un exercice ponctuel après chaque infraction; il devrait être intégré à la gouvernance de la sécurité de l'organisation.

Préparation préalable à l'incident

Avant qu'une brèche ne se produise, définir l'équipe de l'ARC : un mélange de professionnels de la sécurité des TI, d'ingénieurs en OT, d'opérateurs de systèmes de contrôle et de gestion. Autoriser l'accès en lecture seule aux systèmes clés et établir une chaîne de garde pour les preuves médico-légales. Documenter l'architecture du réseau, l'inventaire des biens et les dépendances connues.

Sélection et intégration des outils

Les appareils de surveillance réseau qui peuvent analyser Modbus, DNP3 et OPC-UA trafic sont essentiels. Les agents d'extrémité conçus pour les systèmes embarqués (comme ceux de Microsoft Defender pour IoT ou Armis) peuvent collecter la télémétrie sans déstabiliser les contrôleurs. L'enregistrement centralisé avec flux de données synchronisés dans le temps permet une corrélation entre les événements IT et OT. Un bon RCA devrait être en mesure de répondre : -Comment l'attaquant a-t-il d'abord accès au réseau OT, quelles commandes ont été envoyées et quels actifs ont été affectés ?

Apprentissage post-incident et amélioration continue

Par exemple, si la cause fondamentale était un manque de segmentation, vérifiez que les nouvelles règles de pare-feu sont appliquées et qu'aucune exception n'a été ajoutée silencieusement. Partagez des leçons anonymisées dans l'industrie par l'entremise de groupes de partage d'information comme CISA=S Automated Indicator Sharing (AIS) pour ICS, ou l'ISA=S Security Compliance Institute. Cet apprentissage collectif aide l'ensemble du secteur à améliorer ses niveaux de sécurité.

Étude de cas illustrative : leçons d'une rupture hypothétique de l'ICS

Note : L'exemple suivant est construit à partir de modèles communs observés par les chercheurs en sécurité. Il ne représente pas un incident spécifique mais synthétise les causes profondes typiques.

Une équipe de RCA a utilisé la méthode fishbone et a identifié des facteurs contributifs : le HMI était en service sous Windows 7 sans mise à jour de sécurité, le VPN d'accès à distance utilisait une authentification à facteur unique partagée entre 12 opérateurs, et les registres de réseau montraient du trafic du segment informatique d'entreprise au réseau de contrôle qui n'avait pas été signalé par le pare-feu informatique (puisque le HMI ne surveillait que le trafic nord-sud, et non est-ouest). La cause profonde était le manque de segmentation associé à une politique d'accès à distance non sécurisée. Les mesures correctives comprenaient le déploiement d'une DMZ avec une diode de données unidirectionnelle, la mise en œuvre de MFA pour toutes les connexions à distance et la création d'une boîte de sable automatique pour les mises à jour HMI.

Cette affaire souligne que la cause fondamentale n'était pas une vulnérabilité unique, mais une combinaison de lacunes technologiques et de défaillances de processus.En abordant les deux, l'utilité non seulement s'est remise de l'incident, mais a construit un environnement de contrôle plus résistant.

Conclusion : Intégrer l'ARC comme un processus continu

Dans les systèmes de contrôle industriel, où le coût de l'échec comprend des dommages physiques et des risques pour la sécurité publique, la capacité de découvrir et d'éliminer systématiquement les causes profondes est indispensable. En adoptant des méthodes structurées, en respectant les contraintes uniques des environnements OT et en construisant un programme dédié, les organisations peuvent passer de la lutte contre les incendies réactifs à la résilience proactive. L'objectif ultime est de faire en sorte que chaque brèche, quoiqu'elle soit douloureuse, serve de tremplin vers une infrastructure industrielle plus sûre et plus fiable.