Comment nous construisons vos règles et playbooks

Les alertes génériques ne connaissent pas votre site. Nous écrivons donc ce qui est normal chez vous, construisons chaque règle sur cette base, lui donnons un playbook qui dit qui fait quoi, et la testons avant sa mise en service.

Visite et inventaire passif
Nous parcourons le site avec les personnes qui le font tourner. Puis nous recensons chaque équipement, chaque connexion et chaque compte à partir de ce que vos outils voient déjà. En lecture seule et passif : rien ne touche au contrôle en marche.
Exemple : Werk Niederrhein, notre usine de démonstration
équipements sur le plan
16
zones
4
flux autorisés
6
valeurs de procédé
12
postes IT
8
comptes
7
Lu depuis : supervision OT, pare-feu, VPN, annuaire, EDR
2
Zones et conduits
Nous regroupons les équipements en zones par niveau Purdue et décrivons les conduits entre elles (IEC 62443). Chaque connexion est vérifiée par rapport à ce modèle.
Exemple : Werk Niederrhein, notre usine de démonstration
- L4 · EntrepriseOffice laptopVPN gatewayWarehouse system
- L3 · ExploitationEngineering WSSCADA serverHistorianOT firewall
- L2 · ContrôleHMI MixingHMI Packaging
- L1 · TerrainPLC Mixer 1PLC Mixer 2PLC FillingPLC PackerPLC PalletiserPLC BoilerPLC Water treatment
Conduits : 6 flux autorisés, via le pare-feu OT
Ce qui est normal sur votre site
Avec vos ingénieurs, nous convenons de ce qui est normal : qui peut écrire sur quel automate, quand a lieu la fenêtre de maintenance, comment les fournisseurs se connectent, la plage normale des valeurs de procédé clés.
Exemple : Werk Niederrhein, notre usine de démonstration
Écritures sur les automates
Uniquement depuis le poste d’ingénierie, uniquement dans la fenêtre de maintenance
Fenêtre de maintenance
Samedi 06:00–14:00
Accès fournisseurs
Par VPN, uniquement dans la fenêtre de maintenance
Consigne de remplissage
995–1005 ml
Une règle fondée sur ce modèle
Chaque règle cherche une chose qui ne doit pas arriver sur votre site. En voici une telle que l’application la montre : en langage clair, pourquoi elle compte et ce qu’elle signifie pour NIS2.
ÉlevéeRègle R-003MITRE ATT&CK for ICS: T0836 · Modify Parameter
Écriture OT depuis un poste qui n’est pas un poste d’ingénierie
Impair Process Control
Se déclenche quand
un automate reçoit une écriture (consigne, configuration ou programme) d’un poste que le modèle du site ne connaît pas comme poste d’ingénierie.
Pourquoi
Seuls les postes d’ingénierie devraient modifier les automates ; tout le reste est une erreur de configuration ou une attaque.
NIS2
Probablement important : un procédé manipulé peut toucher la sécurité et le service. Préparez l’alerte précoce (24 h).Confiance de cette règle seule : 25 sur 30
Dans la démoÉcriture OT vers plc-03 depuis laptop-office-01
Montrée en langage clair, comme dans l’application. Le code de la règle est notre travail et reste chez nous.
5
Son playbook : qui fait quoi
Chaque règle a son playbook. Chaque étape nomme qui agit et qui est seulement informé. Dans le dossier, Lagebild sollicite ces personnes et consigne leurs réponses.
Playbook · R-003
1. Confirmer (10 min): La ligne tourne-t-elle normalement, et quelqu’un vient-il de modifier des consignes ou des programmes ?
  Chef d’équipe(agit et répond)
2. Vérifier l’automate (30 min): Comparer avec la dernière version saine connue et la restaurer en cas d’écart. La sécurité d’abord.
  Ingénieur OT(agit et répond)
3. Contenir (30 min): Bloquer le poste qui écrit au pare-feu ou au port du switch, sans arrêter la production.
  Ingénieur OT(agit et répond)
4. Préserver: Conserver la capture réseau et les journaux ; ne rien redémarrer pour l’instant.
5. Informer le directeur d’usine: Ce qui a changé sur la ligne, et si la production ou la qualité sont touchées.
  Directeur d’usine(informé)
6. Informer le RSSI: Probablement significatif au titre de NIS2 : l’alerte précoce de 24 h court dès maintenant.
  Responsable de la sécurité de l’information (RSSI)(informé)
Les rôles deviennent des personnes : votre liste d’équipe dit qui a quel rôle et comment le joindre.
6
Testée avant la mise en service
Nous rejouons des scénarios d’attaque dans la vraie chaîne de traitement : le simulateur joue le site, les règles tournent, des dossiers s’ouvrent. Chaque scénario doit donner exactement un dossier avec les bonnes règles. Une journée de travail normale entière ne doit en donner aucun.
Rejeu avant la mise en service
- Un portable de bureau écrit sur l’automate de remplissageR-003 · R-005 · R-008 · R-009Attendu:1 dossier
- Un fournisseur se connecte hors fenêtre de maintenanceR-006 · R-009Attendu:1 dossier
- Un appareil inconnu parle à l’automate de la chaudièreR-007Attendu:1 dossier
- Clic de phishing, VPN, puis le poste d’ingénierieR-001 · R-002 · R-005 · R-008Attendu:1 dossier
- Une journée de travail normaleAttendu:0 dossier
Après la mise en service, le score NIS2 apprend des dossiers que votre équipe clôt comme fausses alertes.
7
Qui décide pour NIS2, et l’horloge
Chaque dossier reçoit un score NIS2 de 0 à 100. Qui décide est défini par client, en général votre RSSI ou le SOC. Lagebild prépare chaque déclaration ; votre équipe la vérifie et la soumet.
Score NIS2
≥ 90Le dossier NIS2 s’ouvre
60–89Une personne décide
< 60Bruit : conservé, jamais déclaré
Un portable de bureau écrit sur l’automate de remplissage : R-003 avec trois autres règles, score 99. Le dossier NIS2 s’ouvre.
L’horloge
24 hAlerte précoce
72 hNotification
1 moisRapport final
8
Revue chaque trimestre
Les sites évoluent : nouvelles machines, nouveaux fournisseurs, nouvelles fenêtres. Avec Managed OT Security, nous revoyons avec vous les règles, les playbooks et le modèle du site chaque trimestre.
- Quels dossiers étaient de fausses alertes, et pourquoi
- Nouveaux équipements, flux, fournisseurs et fenêtres dans le modèle du site
- Règles et playbooks : ajustés, ajoutés ou retirés
- Qui figure sur la liste d’équipe, et qui décide pour NIS2

Le jeu de règles en un coup d’œil

Les règles dont nous partons, chacune ajustée à votre modèle de site pendant le Check. Chacune a un playbook comme celui ci-dessus.

Jeu de règles Klaar : ce que surveille chaque règle, pourquoi c’est important, sa gravité et qui agit en premier
Règle	Ce qu’elle surveille	Pourquoi c’est important en OT et pour NIS2	Gravité	Qui agit en premier
R-001Phishing, puis VPN	Une connexion VPN d’un compte qui a cliqué sur un lien de phishing dans les 6 dernières heures	Les identifiants volés sont une voie d’entrée courante. Possiblement important si cela mène à l’OT.	Élevée	Analyste SOC
R-002Bureau vers poste d’ingénierie	Une session à distance (RDP ou SMB) d’un poste de bureau ou IT vers un poste d’ingénierie	Ce poste peut modifier les programmes d’automate : une étape classique vers l’OT.	Élevée	Chef d’équipe
R-003Écriture depuis le mauvais poste	Un automate écrit depuis un poste qui n’est pas un poste d’ingénierie	Erreur de configuration ou attaque. Probablement important au sens de NIS2.	Élevée	Chef d’équipe
R-004VPN la nuit	Une connexion VPN entre 22:00 et 05:00, heure du site	Rare la nuit et début fréquent d’une attaque. Pas à déclarer à elle seule.	Moyenne	Analyste SOC
R-005Écriture hors maintenance	Un automate modifié en dehors de la fenêtre de maintenance convenue	Les changements en production sont planifiés ; celui-ci demande une explication.	Moyenne	Chef d’équipe
R-006Fournisseur hors maintenance	Le compte de télémaintenance d’un fournisseur se connecte sans maintenance convenue	L’accès fournisseur est une voie d’entrée fréquente. Vérifier tout de suite avec le fournisseur.	Élevée	Fournisseur
R-007Appareil inconnu	Une adresse absente de l’inventaire parle à un automate ou un appareil de terrain	Un nouvel appareil ne doit jamais apparaître sans prévenir. Possiblement important.	Élevée	Chef d’équipe
R-008Valeur de procédé hors plage	Une valeur de procédé sort de sa plage normale de fonctionnement	Avec une écriture : un effet physique sur le procédé. S’il s’agit d’une attaque, important.	Critique	Chef d’équipe
R-009Connexion hors modèle	Deux postes connus échangent un protocole industriel que le modèle du site n’autorise pas	Un nouveau chemin vers le système de contrôle. Pas à déclarer à elle seule.	Moyenne	Ingénieur OT

Visite du site notre Gemba walk ciblé

Tout commence sur place. Nous allons là où le travail se fait, avec les personnes qui font tourner la ligne, et regardons uniquement ce que NIS2 demande : accès à distance et des fournisseurs, qui peut modifier les automates, sauvegardes, zones réseau et traitement d’un incident.

Qui participe: Chef d’équipe, ingénieur OT, maintenance et votre RSSI
Combien de temps: Une demi-journée sur place, dans le cadre du Check
Ce qui en sort: L’inventaire, le modèle de zones et la liste de ce qui est normal : la base de vos premières règles et playbooks

Des règles qui connaissent votre site ?

30 minutes, gratuit. Vous repartez avec vos trois plus grands écarts.

Réserver un appel gratuit

Visite et inventaire passif

Zones et conduits

Ce qui est normal sur votre site

Une règle fondée sur ce modèle

Écriture OT depuis un poste qui n’est pas un poste d’ingénierie

Son playbook : qui fait quoi

Playbook · R-003

Testée avant la mise en service

Rejeu avant la mise en service

Qui décide pour NIS2, et l’horloge

Score NIS2

L’horloge

Revue chaque trimestre

Le jeu de règles en un coup d’œil

Visite du site notre Gemba walk ciblé

Des règles qui connaissent votre site ?