La sécurité des Systèmes d'Information Industriels (SII / OT)

La sécurité des Systèmes d’Information Industriels (SII) représente aujourd’hui un enjeu majeur. Les audits et les tests d’intrusion qui en découlent ont pour objectif d’identifier les risques et de démontrer les vulnérabilités exploitables par un attaquant ayant un accès direct ou indirect au SII (aussi qualifié de réseau Industrial Control System / ICS network / réseau OT).

En effet, l’exercice consiste à mettre en avant des problématiques de sécurité qui impactent un SII ou les réseaux interconnectés. L’objectif de cet article est de partager notre expérience et d’expliquer la démarche propre à ces contextes.

Avant toute chose, nous souhaitons apporter quelques précisions aux lecteurs :

• Cet article se veut généraliste et n’a pas pour but de détailler la méthodologie technique XMCO (ni même de lister tous les outils ou encore de se concentrer sur un cas spécifique) ;
• Nous n’apporterons ici aucun détail quant aux vulnérabilités identifiées durant nos missions d’audits (référence de matériels, de constructeurs, 0-day, etc.) ;
• Nous éviterons de rentrer dans les spécificités de chaque terme ou de débattre autour de la sémantique 🙂 . De surcroit, nous essaierons simplement d’éclairer le lecteur sur les audits / tests d’intrusion industriels et l’importance de la prise en compte de leur sécurité.

1. Quelques notions à connaître

Dans un souci de compréhension de l’article, nous tenons à rappeler quelques définitions et distinctions entre les termes couramment rencontrés.

1.1 Distinction entre l’IT et l’OT

IT (Information Technology / Technologie de l’Information)

OT (Operational Technology / Technologie Opérationnelle)

Se rapporte à l’ensemble des « actifs » d’une entreprise liés à la technologie de l’information (matériels, logiciels et personnes). De façon très schématisée, le terme peut s’apparenter au « réseau bureautique » de l’entreprise avec en son centre « les données », les machines et les collaborateurs qui les utilisent. Il s’agit là d’interconnecter des applications métiers et des données qui peuvent ensuite être exploitées par les personnes.

Se rapporte aux Systèmes d’Information Industriels (SII) / Industrial Control System (ICS) et regroupe l’ensemble des compétences, technologies, outils de production, matériels/machines, logiciels, personnes, etc. avec en son centre « les interfaces interconnectées avec le monde réel ». Le SI Industriel (SII) / « réseau industriel » va donc interconnecter des interfaces logiques avec le monde physique (ex. via du pilotage ou de la supervision avec des interfaces HMI, SCADA) ou plus directement avec des Automates Programmables Industriels (API également nommés Programmable Logic Controller, PLC) ou tout autre équipement des rouages de la chaîne de production.

Nous utiliserons dans la suite de cet article le terme de réseau IT/OT (ou ICS). D’autres pourraient être évoqués à l’instar des systèmes Supervisory Control and Data Acquisition (SCADA) et des Distributed Control Systems (DCS), mais différentes ressources s’attèlent de façon très complète à présenter les distinctions et similitudes.

1.2 Distinction entre sécurité et sureté

Nous définissons ici ces 2 notions dans un contexte de cybersécurité industrielle.

Sécurité (Security)	Sureté (Safety)
Capacité à avoir connaissance des risques (prévention) pouvant impacter un Système d’Information Industriel et permettant de définir puis de déployer des mesures techniques et organisationnelles pour assurer un niveau de service acceptable et viable des systèmes.	Capacité d’un système ou d’un ensemble de systèmes à disposer de mesures permettant d’éviter des incidents qui pourraient mettre en danger l’environnement, la santé des personnes, des biens, etc. On parle également de « sécurité fonctionnelle ».

2. Pourquoi réaliser des audits de sécurité ou des tests d’intrusion sur un SII

Toute technologie ou donnée est aujourd’hui susceptible d’être attaquée pour différents motifs. Ainsi, l’industrie n’y échappe pas d’autant que l’exposition des SII est de plus en plus importante :

• Concurrence avec volonté de nuire, de ralentir, de détruire une activité (de façon directe ou indirecte) ;
• Malveillance externe ou interne ;
• Chantage / récupération d’une contrepartie (argent, données, technologie, etc.) ;
• Challenge technique ;
• Motifs étatiques ;
• Recherche de visibilité / reconnaissance ;
• Script kiddies.

La différence vient aujourd’hui essentiellement de la perception du grand public sur les menaces. En effet, la médiatisation autour de la sécurité informatique se concentre surtout sur les données personnelles. Les tests d’intrusion et les audits de réseaux ICS permettent donc de sensibiliser les différents acteurs œuvrant dans des contextes industriels face aux risques Cyber qui les concernent.

2.1 Des impacts sur le monde réel

Une attaque sur un SII peut engendrer différents impacts d’ordre :

• Matériel (destruction) / humain (blessure voire mort) ;
• Financier (perte de disponibilité ou ralentissement avec un impact sur la production) ;
• Environnemental (incendie, pollution, etc.) ;
• Politique ;
• Métier (vol de secrets ou de savoir-faire, etc.) ;
• Éthique / image / renommée.

2.2 La perception de l’auditeur

Les objectifs du côté de l’auditeur vont donc être avant tout :

• D’identifier des vulnérabilités pour révéler des scénarios d’attaques réalistes et les risques inhérents à une exploitation réussie. Cela passe par la vérification :
  • de l’efficacité des mécanismes de sécurité implémentés ;
  • des mesures et solutions déployées pour la protection des systèmes sensibles ;
  • des procédures et moyens organisationnels en place ;
  • du niveau de sensibilisation des collaborateurs (profils techniques ou non).

• D’échanger avec les sachants pour qualifier au mieux les risques ;
• De démontrer l’exploitabilité et de mettre en avant les conséquences concrètes en adaptant ses retours aux différents interlocuteurs ;
• De fournir des recommandations applicables dans le contexte de l’environnement. Il convient de prioriser au mieux les actions pour supprimer ou à minima mitiger le niveau de menace.

2.3 La perception de l’audité

A l’inverse, l’objectif pour l’audité va donc être :

• De challenger sa sécurité (configurations, solutions, procédures), d’éventuels prestataires (ex. Security Operation Center / SOC externe) mais également ses équipes dans le cadre d’un exercice concret ;
• D’avoir un état des lieux de son niveau de sécurité et des risques encourus ;
• D’obtenir / de consolider un plan d’action à mettre en place dans le cadre du renforcement de son SII ;
• De disposer d’un appui externe dans le cadre de migrations, de changements d’équipements / de solutions, ou de définition d’un budget ;

2.4 Les différentes méthodologies

À l’instar d’autres catégories de tests d’intrusion, l’approche peut distinguer 3 phases complémentaires :

1. Boîte noire : cette phase consiste à réaliser les tests sans aucun compte utilisateur ou information. Le point d’entrée se fait depuis Internet, un accès réseau filaire (salle de réunion, bureau libre, etc.), un accès sans-fil (Wi-Fi) ou via une connexion VPN (selon l’exposition des actifs et les contraintes techniques).
2. Boîte grise : un ou plusieurs compte(s) utilisateur(s) standard(s) sur le(s) domaine(s) (dans la mesure de l’existence d’un Active Directory / AD) sont demandés. L’objectif est de couvrir davantage de scénarios sur les réseaux interconnectés avec le SI Industriel. Cette demande peut être complétée par différents identifiants pertinents dans le contexte de l’audit.
3. Boîte blanche : les tests sont étendus avec l’assistance de responsables ou des opérateurs sur site facilitant l’identification de scénarios pragmatiques. À ce titre, la moindre documentation facilitant la compréhension de l’environnement est la bienvenue (inventaire, schémas, documentation de constructeurs, accès au code source, accès aux systèmes, etc.).

3. Quelles vulnérabilités sur un SII ?

Nous identifions généralement des vulnérabilités ou des non-conformités inhérentes à :

• La segmentation réseau permissive (au sein même du réseau OT ou entre l’IT et l’OT) avec des règles incomplètes voire un réseau à plat ;
• L’absence de patchs de sécurité, de mises à jour ou l’utilisation de composants qui ne sont plus maintenus. Ces derniers s’avèrent ainsi vulnérables à de multiples exploits. Rappelons que dans un SII la priorité est la disponibilité et non pas que tout soit à jour. En somme, il est primordial de comprendre le contexte de l’obsolescence identifiée et du pourquoi. Il peut s’agir d’une question de budget, licence, redémarrage complexe, oubli, absence de sachant, interconnexions limitées, etc. ;
• L’utilisation d’identifiants par défaut ou triviaux qui engendre un risque important sur la sécurité (solutions, équipements, services, etc.). A cela s’ajoutent les problématiques de comptes génériques, de réutilisation d’identifiants, de sessions ouvertes « permanentes », etc. ;
• Des applications vieillissantes qui n’ont pas été développées sous l’angle de la sécurité et qui sont toujours utilisées ;
• Des problématiques de gouvernance (rôles, responsabilités, délégations, etc.) et de supervision ;
• Des configurations par défaut ou triviales (Wi-Fi, postes de travail, filtrages réseau permissifs, partages non maitrisés, etc.) ;
• L’absence de sensibilisation des collaborateurs face aux risques Cyber (phishing, gestion des mots de passe, sessions, etc.) ;
• L’absence de surveillance / monitoring / suivi des évènements de sécurité ;
• La gestion des tiers / prestataires externes (quid des attaques ciblant la chaîne logistique / supply chain) ;
• Les problématiques de composants inconnus qui font parfois tout, trop ou rien. Il s’agit là des « boites magiques » installées par des tiers dont personne en interne n’a malheureusement la maitrise ;
• L’absence malheureusement récurrente de documentation à jour voire l’absence totale (inventaire, schémas, guides, responsabilités, etc.). En conséquence, la connaissance du périmètre ou d’une technologie peut ainsi totalement se perdre.

Note : Quitte à faire doublon avec le second point de cette liste, rappelons que la priorité des équipements industriels a toujours été de fonctionner (focus sur la disponibilité) et non pas de fonctionner "avec de la sécurité". Aujourd'hui les éditeurs / constructeurs prennent davantage en considération cette problématique même si cela demeure un réel casse-tête pour les équipes.

4. La modernisation de l’industrie (Cloud et IoT)

Le terme industrie laisser souvent penser à de vieilles technologies qui n’évoluent pas ou peu. La longévité de certains matériels / systèmes à qui l’on demande avant tout d’être fiables joue dans cette perception. Pour autant, de plus en plus de solutions « modernes » viennent s’interfacer dans ces architectures pour faciliter le travail des équipes. Cela se fait au regard de multiples facteurs (position géographique, milieu à risque, besoin de pilotage à distance, nécessité d’analyse des données en temps réel, étude de la productivité, etc.).

L’objectif est donc avant tout d’optimiser et de faciliter :

• La centralisation des informations (données / data au sens large) ;
• Le partage de ressources ;
• L’exploitabilité et le pilotage des outils / machines ;
• La maintenance ;
• Les possibilités d’assistance technique à distance avant de dépêcher des interventions sur site ;
• L’interopérabilité entre les équipements de différents usages et d’années de conception parfois éloignées.

C’est ici qu’interviennent le Cloud et l’Internet des objets (IoT) également appelé Internet industriel des objets (IIoT) dans le contexte industriel. Cette convergence permet aujourd’hui de « faciliter » la gestion de ces problématiques, mais accroit également le périmètre à sécuriser / surveiller. Ajouter un équipement IoT accroit ainsi les risques à différents niveaux : hardware, firmware, protocolaire, système, applicatif, etc. Tout comme chaque nouveau matériel ou applicatif, il convient d’avoir un durcissement, un suivi, une sensibilisation, une documentation, etc.

Le Cloud n’échappe pas à la règle et intègre de plus en plus de données industrielles chez les grands fournisseurs de services (Amazon AWS, Google GCP, Microsoft Azure, etc.). Cette composante accroit donc les risques. Les données qui se retrouvaient initialement restreintes localement sont dorénavant plus facilement exposées.

5. Les étapes d’un audit industriel (prisme sécurité)

L’objectif est de mettre en évidence les risques de malveillance interne ou externe qui pourraient permettre d’accéder au SII.

5.1 Démarche « classique »

Prenons le cas d’une démarche qualifiée de « classique » :

① Préparation : découverte du contexte, présentation du périmètre, des risques, des enjeux et de l’environnement

Cette phase consiste à échanger avec les responsables et les équipes en lien avec la mission. L’intérêt étant de comprendre le contexte, les raisons et les enjeux. Il en résulte la mise en avant des principaux risques qu’une attaque pourrait engendrer, la description des équipements, les rôles des collaborateurs, la présentation du périmètre à couvrir ou à exclure, etc. Outre une meilleure compréhension, cela permet de définir des prérequis essentiels à la réalisation de la mission (documents à transmettre, dates de réalisation, livrables attendus, contacts, etc.).

② Découverte : cartographie du réseau / comparaison avec l’attendu

Cette phase s’attarde sur l’identification des points d’entrée puis la réalisation des scans de découverte afin de constituer une cartographie du SI Industriel et des potentiels réseaux interconnectés (selon le périmètre défini). En fonction des documents transmis cela permet également de corréler les informations fournies avec la réalité du terrain. Dans un contexte industriel, cette étape doit préférablement être appuyée par la fourniture de l’inventaire du périmètre (automates, postes de travail, stations des opérateurs, routeurs, équipements divers, etc.). L’objectif est d’écarter les risques inhérents à certains équipements « sensibles ».

La cartographie et l’inventaire pourront mettre en avant les problématiques d’exposition sur Internet notamment celles liées aux services entrant dans le concept d’industrie 4.0 (ex. Industrial Internet of Things / IIoT évoqué au préalable).

Des recherches d’informations passives / OSINT (comptes, code source, fichiers de configuration, etc.) doivent également être conduites. Cette étape est enrichie tout le long de l’audit avec les nouvelles informations acquises. Cela permet ainsi d’affiner des recherches et d’en réaliser de nouvelles.

③ Analyse

Cette phase s’attèle à identifier, croiser et qualifier l’ensemble des informations réunies. Il en résulte la préparation des premiers scénarios d’exploitation via les technologies utilisées, systèmes, versions, applications, interfaces, etc.

Selon les informations obtenues, des recherches sont également réalisées sur les sites des éditeurs, les bases de connaissances, les services d’hébergement de code, etc.

Un focus sur les protocoles industriels devra être réalisé : Modbus, OPC-UA, S7, etc. (notamment sur les implémentations « maison »).

④ Exploitation : de failles système, réseau, applicative, AD, etc.

Une fois les scans réalisés et les informations qualifiées, il est temps de rechercher des vulnérabilités et des non-conformités. L’exploitation de ces dernières aura notamment pour objectif l’obtention d’accès privilégiés aux systèmes ou aux applications. Selon le point d’entrée, le but peut être de rebondir depuis le réseau bureautique, sur le réseau de supervision (ex. MES, SCADA, DCS) puis Industriel (ex. PLC, capteurs, actionneur) ou alors d’évaluer directement le niveau de sécurité d’un de ces derniers.

Viennent ensuite la corrélation des informations récoltées individuellement, la combinaison de vulnérabilités et la mise en avant de scénarios permettant de démontrer la possibilité d’impacter la disponibilité ou l’intégrité de la chaine, d’exfiltrer les informations d’un site industriel ou encore de modifier la traçabilité des données.

(Au cas par cas) Un compte utilisateur standard du domaine peut être requis. Suite à quoi, il est pertinent de chercher des vulnérabilités telles qu’elles pourraient être identifiées par un utilisateur malveillant (stagiaire, prestataire, collaborateur sans droit spécifique, etc.). En outre, Il est possible qu’aucun domaine ne soit utilisé auquel cas des comptes locaux sur des machines ou des applications pertinentes peuvent être communiqués.

⑤ Livrables

Une importance particulière doit être apportée aux livrables afin de restituer au mieux l’information en 2 niveaux (managérial et technique). L’objectif est ainsi de pouvoir donner rapidement un constat clair et concis des résultats aux équipes de direction tout en offrant également aux équipes techniques l’ensemble des détails inhérents aux tests conduits (concluant ou non) avec les différentes synthèses, descriptions et recommandations à appliquer afin de corriger les non-conformités ou les vulnérabilités identifiées.

Les livrables sont également l’occasion de souligner les points positifs relevés durant l’audit ainsi que d’illustrer des scénarios d’exploitation (combinaison de vulnérabilités) mettant en exergue les « kill chain ».

En fonction des résultats, les scripts développés ainsi que des vidéos d’exploitation permettant d’illustrer les attaques peuvent être communiqués. Ces éléments peuvent faciliter le « rejeu » et la compréhension des équipes internes.

---

5.2 Compléments techniques

Audit WiFi

L’objectif est d’identifier les vulnérabilités exploitables via ou sur l’infrastructure Wi-Fi en vue de s’introduire sur le réseau OT du site industriel ou aux réseaux interconnectés.

Cloisonnement / Segmentation des réseaux

En parallèle des tests techniques présentés ci-dessus, des tests de cloisonnement / segmentation peuvent être conduits. Cette étape a pour but d’assurer l’isolation partielle ou totale de l’environnement vis-à-vis des autres réseaux (ex. IT ou supervision ou une DMZ spécifique) mais aussi de confronter les informations obtenues avec les configurations des équipements en charge du filtrage ou encore avec les documents transmis.

Approche « Assume Breach »

Simulation d’une attaque depuis une machine « compromise » (ex. en cas de vol, d’un d’accès illégitime, d’un prestataire malveillant) avec un poste éteint puis sur une session ouverte (dynamique).

Approche « Red Team »

La complexité des environnements industriels rend la réalisation de campagnes de Red Team délicate. Avant d’envisager ce type d’approche, il convient au client de disposer d’un solide niveau de sécurité et d’être confiant quant à la maturité des procédures, des outils et des équipes qui seront éprouvés. Bien que le Red Team apparaisse parfois comme une carte blanche totale, l’approche en milieu industriel requiert des garde-fous accrus que nous rappelons un peu plus bas dans cet article.

Focus sur un matériel industriel ou un pan du SII

Le but est ici de se concentrer sur un actif précis du SII pour donner un avis sécurité (étude de firmware, d’un client lourd, d’un équipement, etc.).

Audit de configuration d’un équipement / poste (travail, maintenance, opérateur)

L’idée est de procéder à un audit de configuration d’une ou plusieurs machines (mode échantillonnage) afin d’identifier les axes de sécurisation / durcissement.

---

5.3 Compléments non techniques

Outre la partie purement technique, il est souvent pertinent de réaliser en amont des tests (ou en complément) les étapes ci-dessous afin de couvrir les aspects organisationnels et physiques de l’audit, par exemple :

Revue documentaire

La mise à disposition d’une documentation complète et à jour du SI Industriel est très souvent complexe. Toutefois, le moindre document peut nous permettre d’éclairer notre compréhension du périmètre (ex. un schéma sera plus parlant qu’une simple liste d’adresses IP). Les documents peuvent également nous permettre d’identifier des problématiques qu’il n’aurait pas été possible de trouver “facilement” dans le temps imparti aux tests.

Entretiens organisationnels

Les entretiens permettent d’avoir un lien direct avec les équipes (automaticiens, informaticiens, responsables de la partie métier du site) et d’en apprendre davantage sur le fonctionnement du site comme sur le quotidien des personnes en charge du bon fonctionnement. Cela facilite la compréhension de certains concepts métiers et permet aux équipes de poser directement leurs questions aux auditeurs. Cela permet également de limiter les risques lors de la phase technique en contextualisant les scénarios d’exploitation.

Visite du site (sécurité physique)

La visite du site industriel permet d’avoir une compréhension accrue du contexte et des enjeux métiers. Il s’agit d’autre part de rassurer les équipes sur place (ex. automaticiens, responsables) afin d’initier un travail collaboratif et d’enrichir les connaissances de chacun sur les problématiques de sécurité. La visite du site peut également être l’occasion d’identifier d’autres axes de sécurisation inhérents au monde physique (entrées, caméras, registres, détecteurs de mouvements, badgeuses, etc.).

Sensibilisation des collaborateurs

Tout comme les métiers de l’IT, il est pertinent de sensibiliser les équipes OT face aux risques liés au phishing et plus généralement à l’ingénierie sociale (ex. que faire en cas de récupération d’éléments amovibles sur un site industriel – USB, carte SD, etc.). Des campagnes fictives peuvent ainsi être conduites ou encore des ateliers de sensibilisation (menaces actuelles, risques divers, etc.).

6. Notes concernant les audits et tests d’intrusion industriels

Les éléments présentés ci-dessous pourront sembler évidents pour beaucoup, mais il est important de les rappeler. Ceux-ci permettent également de se poser les bonnes questions en amont d’un audit et sont à la fois valables en tant qu’auditeur, mais également en tant que client avant d’engager un prestataire dans le cadre de la réalisation d’un audit ou d’un test d’intrusion visant un SI Industriel.

Note : Environnement industriel ou non, un audit reste une évaluation à un instant 't' sur un périmètre défini durant un temps restreint.

6.1 Le facteur « temps »

Le temps dédié à l’audit est un facteur clé (quel que soit l’environnement). Différentes raisons peuvent obliger à restreindre sa durée (obligation métier, coût, contrainte technique, jalon à respecter, etc.). Nous rappelons qu’un audit ne peut être considéré comme exhaustif. Selon les contextes, nos efforts se concentreront sur la mise en évidence de vulnérabilités élevées/critiques et de non-conformités majeures. L’exhaustivité est un terme à utiliser avec beaucoup de précautions, car elle n’existe tout simplement pas en audit. Nous pouvons suivre un référentiel, une checklist, une méthodologie, etc. Pour autant, il y aura toujours un pan qui n’aura pas pu être couvert complètement (attention aux propositions prétendant le contraire). Il convient donc avant tout d’avoir un plan d’audit et une méthodologie pragmatique avec pour objectif de réaliser un maximum de contrôles pertinents durant le temps dédié.

6.2 L’environnement industriel

La réalisation d’un audit dans un environnement industriel induit de facto des risques inhérents au contexte de réalisation (équipements, systèmes, applications, etc.). Nous tenons à mettre en avant qu’à l’instar de tout audit de sécurité il est primordial de prendre le maximum de précautions afin d’écarter ou de limiter le moindre impact, MAIS que le risque 0 n’existe pas.

Nous insistons dans ces contextes (et dans la mesure de leur existence) sur la mise à disposition d’environnements de « test » / préproduction, de sites « inactifs » ou de « labs » dédiés (maquettes) avec « les configurations cibles ». De même, la réalisation des audits durant des périodes de maintenance / d’activité ralentie est également une possibilité. Nous sommes cependant tout à fait conscients que la duplication de tels environnements s’avère extrêmement onéreuse.

En cas d’impossibilité, il est nécessaire d’identifier des périodes de maintenance, d’activité ralentie, ou le ciblage de « maillons spécifiques ». Le second choix requiert cependant une disponibilité des équipes sur site accrue. Plus précisément, sur un environnement de « production », nous ne procéderons qu’à des « tests limités ». Aucune action d’écriture ne pourra ainsi être réalisée sur les composants du SII (PLC, RTU, Data Historians etc.). À titre d’exemple, certains équipements industriels ne s’avèrent pas en mesure de gérer une simple requête malformée d’où l’importance de donner à l’auditeur le maximum d’informations sur le périmètre ;

6.3 Support, Inventaire & Documentation

Nous demandons le support durant la durée de l’audit de collaborateurs « sachants » en mesure de répondre à nos interrogations et aptes à débloquer des situations techniques. Cette disponibilité est primordiale en cas de question ;

Nous demandons en amont de l’audit la mise à disposition de toute documentation (inventaire des actifs, inventaire des VLAN, schémas réseau, guides de sécurisation appliqués, etc.). Cette dernière nous permet d’avoir une meilleure compréhension du périmètre OT (y compris dans le cadre d’audits réalisés sans phase dite de « boîte blanche ») ;

Quitte à faire doublon avec le précédent point, les inventaires sont essentiels (à la fois aux équipes du site ou aux gestionnaires, mais également aux équipes d’audit). Faire tomber un site vitrine par méconnaissance du périmètre est préjudiciable, perturber une chaine de production est d’un tout autre acabit ;

Sans porter un quelconque jugement de valeur, il est nécessaire côté auditeur de positionner des consultants disposant d’une certaine expérience et aptes à appréhender la variété des architectures et technologies rencontrées (Web, réseau, système, AD, etc.).

Note : En raison de l’impact potentiel sur l’humain, la santé, l’environnement et bien évidemment sur la chaîne de production, nous prenons un ensemble de précautions visant à endiguer d’éventuelles conséquences non souhaitées durant nos tests.

7. Recommandations pour l’amélioration de la sécurité des Systèmes d’Information Industriels

Même sans audit, différentes mesures peuvent être mises en œuvre afin de renforcer la sécurité du SII :

• Mettre en place et maintenir à jour un inventaire des actifs du périmètre OT ;
• Limiter au maximum l’exposition de composants OT directement sur Internet ou l’externalisation ;
• Limiter le nombre de services exposés sur les équipements et les sécuriser ;
• Mettre en place une segmentation / filtrage entre l’IT et l’OT (ex. modèle Purdue ou approche hybride avec l’IoT) ;
• Mettre en place une segmentation / filtrage au sein de l’OT ;
• Mettre en place des solutions de détection et un suivi des évènements de sécurité ;
• Identifier clairement les responsables (rôles et périmètres) et communiquer ;
• Maintenir un suivi des versions et appliquer les patchs de sécurité (à minima sur les actifs les plus critiques) ;
• Mettre en place un plan de réponse aux incidents (technique et organisationnel incluant les processus de gestion des sauvegardes) ;
• Procéder à des tests / simulations de façon régulière ;
• Durcir ou demander le durcissement des configurations des équipements, applications, appliances, etc. dès leur intégration dans le SII ou SI ;
• Définir une politique de mots de passe forte et la respecter même sur les actifs industriels ;
• Sensibiliser et former les équipes aux différentes menaces et aux bonnes pratiques de sécurité ;
• Prendre en considération la gestion des tiers.

8. Quelques outils

Pour les plus curieux(ses), voici quelques outils utiles durant les audits et tests d’intrusion industriels :

• Wireshark : pour l’analyse des paquets ;
• Nmap : pour l’identification de services ;
• Scapy : boite à outils de manipulation de paquets réseau (Python) ;
• Binwalk : pour l’analyse des firmwares ;
• x32|64dbg : debugger ;
• Sysinternals Suite : suite d’outils fournis par Microsoft ;
• IDA / Cutter (Rizin) / Ghidra : pour le reverse de firmwares ou de binaires ;
• s7scan / Snap7 / plcscan : pour des étapes de scans sur des services industriels.

9. Exemples d’audits techniques menés par XMCO en lien avec la sécurité des Systèmes d’Information Industriels

Nous présentons ci-dessous quelques exemples d’audits réalisés par XMCO dans des contextes de SI Industriels.

• Analyse / Reverse du firmware d’un RTU + recherches de vulnérabilités 0-day ;
• Audit de configuration d’un Poste de Travail (PdT) Windows utilisé par des automaticiens / responsables de la maintenance industrielle (objectif de durcissement) ;
• Audit d’équipements industriels (capteurs de pression) (contexte IIoT) ;
• Tests de segmentation IT/OT ;
• Audit d’une architecture d’entrepôt robotisé (applications, serveurs, clients lourds, segmentation, etc.) ;
• Audits 360 étendu IT/OT (externe, interne, maturité, Wi-Fi, etc.) ;
• Tests d’intrusion depuis le réseau OT (scénario de compromission ex. prestataire malveillant ou poste compromis) ;
• Recherches de vulnérabilités sur des équipements ;
• Couverture Internet d’actifs IT/OT exposés.

10. Ressources complémentaires

• ANSSI – La cybersécurité des systèmes industriels
• Clusif – Conférence OT – Clusif (2021) – 20210303-Guide-cybersécurité-des-systemes-industriels.pdf
• NIST – SP 800-82 Rev. 2 – Guide to Industrial Control Systems (ICS) Security
• Norme IEC 62443 – Réseaux – Produits Industriels
• ICS cybersecurity academy (par Arnaud Soullié)
• Sans omettre plus largement les différents contributeurs de la communauté sécu ! 🙂