Dans les environnements industriels, le temps est un luxe que l'on n'a pas toujours. J'ai vu trop d'équipes perdre des heures, voire des jours, à essayer de comprendre ce qui se passe sur une ligne de production après une anomalie réseau. La bonne nouvelle : en déployant rapidement des outils d'edge security, il est tout à fait possible de détecter une cyberattaque industrielle en moins de 48 heures. Voici comment je procède, étape par étape, avec des retours d'expérience concrets et des recommandations pratiques.
Pourquoi viser un déploiement en 48h ?
Quarante-huit heures, ce n'est pas un chiffre magique ; c'est un objectif réaliste qui force à prioriser l'essentiel : visibilité, collecte des indicateurs et règles de détection simples mais efficaces. Dans l'industrie, chaque minute d'arrêt coûte cher. Un déploiement rapide permet d'avoir des alertes exploitables, limiter la surface d'attaque et enclencher des mesures de confinement avant que la situation n'empire.
Préparer le terrain en amont (1 à 4 heures)
Avant tout déploiement, il faut cartographier rapidement :
- les segments réseau critiques (SCADA, DCS, MES, IT),
- les protocoles OT utilisés (Modbus, OPC-UA, Profinet, EtherNet/IP),
- les assets prioritaires (automates, HMI, gateways, serveurs historiques).
Je prépare toujours une fiche d'urgence listant 10 à 20 adresses IP/ports prioritaires et les VLANs ciblés. Cette fiche sera la base du déploiement initial, car on ne peut pas tout surveiller en 48h — il faut choisir les points d'observation les plus critiques.
Choix des outils d'edge security pour un déploiement express
Pour une mise en place rapide j'opte généralement pour une combinaison d'observabilité réseau à la périphérie et d'agents légers sur machines critiques :
- Appliances ou sondes réseau passives (tap/span ou sondes inline) capables d'analyser Modbus, OPC-UA, BACnet, etc. Des acteurs spécialisés comme Nozomi Networks ou Claroty proposent des sondes OT prêtes à l'emploi.
- Agents EDR/EDR-Lite pour les passerelles Windows/Linux (CrowdStrike, SentinelOne, ou des solutions moins intrusives si l'IT/OT doit rester séparé).
- Composants de Network Detection and Response (NDR) en edge pour détecter les comportements anormaux — Darktrace Enterprise Immune System ou des appliances open source pour démarrer (Zeek + Suricata).
- Passerelles edge cloud (ex : appliances Fortinet, Palo Alto ou solutions cloud-managed comme AWS IoT Greengrass) pour centraliser les logs et appliquer politiques.
L'important est de choisir des outils qui s'installent rapidement (image VM/ISO, appliance plug-and-play ou agent massif via GPO/Ansible) et qui offrent des règles de détection OT prêtes à l'emploi.
Déploiement en pratique — plan sur 48h
Voici un planning type que j'utilise :
- Heures 0–4 : Installation des sondes réseau dans les segments critiques. Configuration minimale : sniffing promiscuous, capture des en-têtes, export des logs NetFlow/sFlow et des traces protocolaires vers un collector central.
- Heures 4–12 : Déploiement des agents sur machines prioritaires. Activation d'un profil "monitor only" pour éviter tout impact opérationnel. Connexion des agents au SIEM ou au cloud de gestion.
- Heures 12–24 : Activation des règles basiques OT/ICS (reconnaissance anormale, commande inhabituelle sur automates, firmware download détecté, exécution de commandes non autorisées). Etablissement de dashboards simples : top 10 d'IPs émettrices, top protocoles, alertes critiques.
- Heures 24–48 : Affinage des règles, tri des faux positifs, priorisation des alertes. Validation avec l'équipe opératoire. Mise en place d'une procédure de réponse initiale (isoler segment, couper liaison VPN suspecte, arrêter un poste compromis).
Quels signaux surveiller pour détecter une attaque industrielle ?
En OT, les signaux ne sont pas forcément ceux du monde IT. Voici ce que je surveille en priorité :
- Commandes inhabituelles vers automates : commandes d'écriture soudaines sur registres critiques (Modbus Write), modifications de setpoints non planifiées.
- Scans et reconnaissances : balayages de ports, requêtes massives sur bus de terrain, tentatives de lecture d'addresses inhabituelles.
- Traffic latéral non documenté : machine IT qui communique directement avec un automate sans passerelle autorisée.
- Transferts de firmware : opérations de mise à jour non programmées ou binaires envoyées depuis sources externes.
- Anomalies de timing : latences inhabituelles, bursts de trafic en dehors des fenêtres opérationnelles.
- Alertes d'intégrité : modifications de fichiers système sur HMIs, services stoppés/relancés anormalement.
Cas d'usage concret : comment j'ai détecté une intrusion en 36h
Sur un site de production, nous avons déployé en urgence deux sondes réseau sur le VLAN SCADA et un agent "monitor-only" sur le serveur HMI. En moins de 24 heures, la solution NDR a identifié des requêtes Modbus Write répétées vers un ensemble d'automates en dehors des fenêtres de production. Simultanément, l'EDR a remonté une connexion sortante vers une IP externe inconnue depuis la machine de l'opérateur.
Grâce à ces deux corrélations (commande OT + exfiltration potentielle), nous avons déclenché la procédure de confinement : isolation du VLAN, mise en quarantaine de la machine incriminée et capture des trafics pour enquête post-mortem. L'attaque a été neutralisée avant toute modification durable des racks d'automates.
Outils et configurations rapides recommandés
Pour aller vite, j'ai des préférences testées sur le terrain :
- Zeek + Suricata en VM edge pour une première couche open-source NDR (règles Modbus/OPC-UA via Zeek scripts).
- Nozomi/Claroty si budget et besoin d'une intégration OT-native, leurs sondes sont optimisées pour l'ICS et réduisent les faux positifs.
- SIEM cloud (Azure Sentinel, Splunk Cloud ou Elastic Cloud) pour centraliser rapidement les logs et activer des playbooks automatisés.
- Palo Alto / Fortinet pour des appliances edge qui combinent NGFW et visibilité applicative.
Points de vigilance et pièges à éviter
- Ne pas lancer des agents intrusifs sans validation : en OT, un agent mal testé peut provoquer des arrêts machines.
- Éviter l'« over-alerting » : déployer peu de règles critiques d'abord, puis enrichir. Trop d'alertes nuit à la réactivité.
- Prévoir l'aspect conformité et séparation IT/OT : certaines architectures imposent des contraintes (air-gapped) qui nécessitent des sondes passives plutôt qu'agent.
- Documenter chaque déploiement : qui a installé quoi, où, et pourquoi. En situation de crise, la traçabilité sauve du temps.
La gouvernance et la collaboration qui font la différence
Au-delà des outils, le facteur décisif reste la coordination entre équipes IT, OT et la direction. Sans une chaîne de décision claire et des procédures validées, une alerte critique peut rester sans réponse. J'insiste toujours sur deux choses : des runbooks simples (isoler, collecter, escalader) et des exercices réguliers de simulation pour vérifier que le plan tient la route.
| Objectif | Action rapide | Résultat attendu |
|---|---|---|
| Visibilité | Déployer sondes réseau sur VLANs critiques | Captures protocolaires et dashboards en quelques heures |
| Détection | Activer règles OT prêtes à l'emploi | Alertes pertinentes sur commandes anormales |
| Réponse | Procédure d'isolation et playbooks SIEM | Confinement avant compromission étendue |
En 48 heures, l'objectif n'est pas de tout sécuriser mais d'obtenir un niveau de renseignement opérationnel qui permet d'agir efficacement. Avec les bons outils, une priorité claire et une collaboration fluide entre IT et OT, détecter — et souvent stopper — une attaque industrielle en moins de deux jours n'est pas seulement possible, c'est pragmatique.
