4.2 Crise OT, signalement ANSSI & exercices

Un plan de réponse à incident OT structure les actions à mener dès la détection. Il doit être écrit, connu, testé et maintenu à jour. Référentiel international : NIST SP 800-61 Rev. 2 + ISO/IEC 27035.

Les 4 phases NIST :

1. Préparation : équipe, outils, procédures, formation, exercices.
2. Détection & analyse : caractérisation, qualification, priorisation.
3. Containment, eradication & recovery : confinement, éradication, rétablissement.
4. Post-incident : analyse de cause, leçons apprises, amélioration.

Spécificités OT à prévoir dans le plan :

• Décision d'arrêt de production : qui peut/doit prendre la décision d'arrêter une ligne ou un site en cas d'incident OT ? Procédure documentée, escalade rapide.
• Coordination IT/OT : pas de containment OT sans validation de l'équipe production (risque de causer un accident).
• Communication avec les opérateurs terrain : que dire, que ne pas dire, comment garder la confiance.
• Bascule en mode dégradé : remplacement temporaire d'un automate, fonctionnement manuel, papier-crayon (cas Norsk Hydro).
• Forensique OT : préservation des preuves sur SCADA / PLC sans interrompre le process. Outil clé : capture réseau passive + sauvegarde des configurations.
• Recovery : restauration depuis sauvegardes saines (testées au préalable), revalidation du process.

Équipe d'intervention type :

• Commandant de crise (RSSI ou directeur industriel selon contexte).
• Cellule technique cyber : équipe interne et, presque toujours, un prestataire de réponse à incident — à sélectionner et contractualiser avant la crise, idéalement parmi les prestataires qualifiés par l'ANSSI (PRIS).
• Cellule technique OT (ingénieurs procédés, automaticiens, constructeurs).
• Cellule juridique & communication (DPO, juridique, com'corp, RP).
• Cellule métier (responsables production, achats, clients).
• Liaison avec les autorités : ANSSI/CERT-FR, dépôt de plainte, assureur, et selon le secteur l'ARS ou la DREAL — pour un site classé Seveso, un incident cyber affectant la maîtrise du procédé relève aussi de l'information de l'inspection des installations classées.

Le signalement sera une obligation au titre de l'article 23 de NIS2, à adresser au CSIRT ou à l'autorité compétente — en France, l'ANSSI et son CERT-FR. Le canal, le formulaire et les seuils précis seront fixés par la loi de transposition et ses décrets : à ce jour, un signalement se fait par les voies habituelles du CERT-FR, sur une base volontaire, et c'est déjà la bonne pratique — la plupart des entreprises qui ont sollicité le CERT-FR tôt dans un incident en retirent un bénéfice opérationnel immédiat.

Qu'est-ce qu'un incident « significatif » qui déclenche l'obligation ? Article 23 NIS2 : un incident est significatif s'il :

• A causé ou est susceptible de causer une perturbation opérationnelle grave du service ou des pertes financières.
• A affecté ou est susceptible d'affecter d'autres personnes physiques ou morales en causant des préjudices matériels ou non matériels considérables.

Contenu de l'alerte précoce (≤ 24 h) :

• Nature de l'incident (catégorie : ransomware, intrusion, DDoS, etc.).
• Périmètre concerné (sites, systèmes).
• Impact estimé sur les opérations.
• Mesures conservatoires en cours.
• Caractère transfrontalier éventuel (autres pays UE concernés).

Contenu de la notification (≤ 72 h) :

• Description détaillée du mode opératoire.
• Indicateurs de compromission (IoC) identifiés.
• Conséquences sur la disponibilité, l'intégrité, la confidentialité.
• Premier impact financier et opérationnel estimé.
• Mesures de remédiation engagées.
• Communication aux parties prenantes (clients, salariés, partenaires) — coordonnée avec l'ANSSI.

Rapport final (≤ 1 mois) :

• Analyse complète de la cause racine.
• Chronologie détaillée de l'incident.
• Bilan complet des impacts (financier, opérationnel, réputationnel, juridique).
• Mesures correctives mises en œuvre.
• Améliorations apportées au programme cyber.
• Leçons apprises et axes de progrès.

La continuité d'activité (PCA) et la reprise après sinistre (PRA) font partie des 10 mesures NIS2 (article 21). Pour le contenu détaillé, voir notre formation dédiée PCA / PRA & Continuité d'activité. Pour l'OT, quelques spécificités à retenir :

• Sauvegardes des configurations PLC, SCADA, HMI : c'est l'urgence n°1. Beaucoup d'entreprises n'ont pas de sauvegarde récente du programme de leurs automates. En cas d'effacement par un attaquant, la reprise prend des semaines.
• Règle 3-2-1-1-0 appliquée aux configurations OT : 3 copies, sur 2 supports différents, dont 1 hors site (off-site), dont 1 hors ligne (offline) ou immutable, avec 0 erreur vérifiée lors d'un test régulier.
• Sauvegardes déconnectées : indispensables face à un rançongiciel, qui cherche systématiquement à détruire les sauvegardes accessibles. Deux options : un support physiquement débranché (bande, disque sorti du coffre) ou un stockage immuable, sur lequel une donnée écrite ne peut plus être ni modifiée ni supprimée avant l'expiration d'un délai.
• Tests de restauration réguliers : une sauvegarde non testée n'est pas une sauvegarde. Cycle annuel minimum, idéalement semestriel.
• Bascule en mode dégradé : prévoir comment continuer la production sans certains équipements (papier, mode manuel local, sous-traitance temporaire). Le cas Norsk Hydro est un cas d'école : retour au papier-crayon pendant 3 semaines, mais la production a continué.
• Pièces détachées critiques : stock de PLC/HMI/switches de remplacement pour reprise rapide.
• RTO / RPO différenciés par criticité : un SIS nécessite un RTO < 1 h ; un Historian peut tolérer 24 h.

Cas Norsk Hydro (2019) : environ 22 000 postes chiffrés, et pourtant la production n'a pas totalement cessé. Le groupe disposait encore de procédures papier et d'opérateurs capables de conduire les installations en manuel ; les sites ont basculé dans ce mode, à cadence réduite, pendant que l'informatique était reconstruite. L'entreprise a refusé de payer et communiqué publiquement chaque jour. Impact évalué à 650-750 millions de couronnes norvégiennes, dont l'assurance cyber n'a couvert qu'une part minoritaire.

Les exercices de crise sont l'investissement le plus rentable d'un programme cyber. Pourtant, ils sont souvent reportés faute de temps. NIS2 (article 21) les recommande explicitement dans les pratiques d'hygiène.

Trois niveaux d'exercices à organiser :

• Tabletop (sur table) — exercice papier de 2-4 h. Un scénario écrit, les participants discutent les actions qu'ils prendraient. Coût faible, valeur élevée. À organiser 1 fois par an minimum au niveau COMEX.
• Exercice fonctionnel — simulation plus poussée avec déclenchement de procédures réelles (sans toucher à la production). Test des outils, des canaux de communication, des temps de réaction. 1 à 2 fois par an.
• Test d'intrusion piloté par la menace (TLPT) — une équipe offensive tente de pénétrer le système réel dans un cadre contractuel strict. Coûteux, très formateur. Pour le secteur financier, DORA rend ces tests obligatoires au moins tous les trois ans (article 26) pour les entités désignées. En OT, un test offensif ne se conduit jamais sur un système de production en marche : il se fait sur un banc, une maquette ou pendant un arrêt planifié.

Scénarios OT recommandés pour les exercices :

• Ransomware paralysant l'IT et impactant l'OT par effet de bord (scénario type NotPetya / Saint-Gobain).
• Compromission d'un compte fournisseur via VPN.
• Découverte d'un malware sur un poste HMI.
• Comportement anormal d'un SIS (scénario Triton).
• Demande de rançon avec exfiltration de données et menace de divulgation.
• Incident sur un fournisseur cloud d'Historian.

Points clés du retour d'expérience post-exercice :

• Temps de détection effectif.
• Délai de mobilisation de l'équipe d'intervention.
• Clarté des procédures (qui appelle qui).
• Qualité de la communication interne et externe.
• Capacité à respecter le délai NIS2 de 24h de signalement.
• Coordination IT / OT / production effective.
• Lacunes identifiées et plan d'action.