Dans les environnements de production industrielle, les machines automatisées et les systèmes de contrôle-commande jouent un rôle central dans la performance opérationnelle et la productivité. L’intégration croissante des technologies numériques, IoT, des réseaux industriels et SCADA expose ces équipements à de nouvelles vulnérabilités pouvant affecter la disponibilité des installations, la qualité de production et la sécurité des opérateurs.
Cette étude de cas présente une approche de cybersécurité machine appliquée aux entreprises manufacturières et aux systèmes automatisés utilisés, en s’appuyant sur les contre-mesures de base et les bonnes pratiques du domaine. Elle met en évidence les principales vulnérabilités observées dans les architectures industrielles ainsi que les mesures techniques et organisationnelles permettant de renforcer la sécurité des systèmes.
L’objectif est d’illustrer comment une démarche structurée d’analyse des risques et exigences règlementaires permet de protéger les systèmes automatisés tout en garantissant la continuité de production et la fiabilité des équipements industriels.
Étude de cas – Cybersécurité - Site manufacturier - Machine
Site de fabrication de machines-outils et équipements industriels, 300 employés, production en série/petites séries avec forte personnalisation.
Présentation de l'étude de cas
- Usine de production manufacturière - Discontinu
- ⚠️ Règlement Machine
-
CRA - NIS 2 - CSA
-
ISO 13849 - IEC 62061 - EN 50 742
Cette étude de cas présente une illustration pédagogique de la manière dont les exigences de cybersécurité industrielle peuvent être analysées et structurées dans un contexte de production manufacturière de produit intégrant des éléments numérique (PEN). Elle décrit les systèmes concernés, les contraintes réglementaires spécifiques, ainsi que les enjeux de sécurité et cybersécurité fonctionnelle. L’objectif est d’illustrer, à travers un exemple concret, l’articulation entre les règlements Machine, CRA, NIS, … et IEC 62443, les niveaux de Security Level, ainsi que les catégories d’exigences techniques, organisationnelles et documentaires généralement rencontrées dans ce type d’environnement industriel.
Les éléments présentés ont une vocation strictement informative et pédagogique. Elle reste un exemple réaliste et ne constituent pas une recommandation mais un approche.
Contexte Industriel
Site de production de 200 employés basé en France (UE), fabrication de machines pour d’autres industriels
SYSTEMES :
🔴 Lignes d’assemblage pilotées par automates : Schneider M340/M580, Siemens S7-1200/1500, Rockwell CompactLogix/ControlLogix, Beckhoff CX/EL séries
🔴 SCADA atelier : Intouch, WinCC, FactoryTalk View, Wonderware System Platform, Ignition (Inductive Automation)
🔴 MES (Manufacturing Execution System) : Siemens Opcenter (ex-SIMATIC IT), Dassault DELMIA, Rockwell FactoryTalk ProductionCentre
🔴 PLM : Siemens Teamcenter, Dassault ENOVIA, PTC Windchill
🔴 CAO méca : SolidWorks, CATIA V5/V6, Inventor,
🔴 CAO élec : EPLAN Electric P8, AutoCAD Electrical, SEE Electrical
🔴 Atelier logiciel de génie Atomatique (ALGA) : TIA Portal, Studio 5000, Control Expert, TwinCAT
🔴 ERP : SAP S/4HANA, Oracle EBS, Microsoft Dynamics 365
🔴 Bancs de test : stations validation fonctionnelle machines avant livraison client
🔴 Robots collaboratifs (cobots) : Universal Robots, ABB YuMi, KUKA iiwa, Fanuc CR
ENJEUX :
🔴 Protection propriété intellectuelle : plans machines, savoir-faire, algorithmes contrôle = cœur business
🔴 Continuité production : retards livraison = pénalités contractuelles clients (-10% CA par semaine retard)
🔴 Qualité produits : conformité machines livrées (marquage CE, certifications clients sectoriels automobile, défense, …)
🔴 Cybersécurité supply chain : risque compromission machines vendues → responsabilité fabricant (rappels coûteux)
🔴 Conformité CRA : double casquette utilisateur (site production) + fabricant (machines vendues)
EXIGENCES CRA (Cyber Resilience Act)
🟠 ATTENTION : Le constructeur est DOUBLEMENT concerné par le CRA
1. En tant qu’UTILISATEUR (son propre site de production) :
🟠 Vérifier conformité CRA des équipements achetés auprès fournisseurs (Siemens, Rockwell, Schneider, ABB, Universal Robots…)
🟠 Exiger documentation cybersécurité : SBOM, notice sécurité, coordonnées PSIRT constructeur
🟠 Support et mises à jour sécurité : contrats maintenance incluant patches 5 ans minimum
🟠 Traçabilité fournisseurs : s’assurer conformité CRA dans contrats d’achat (clause contractuelle)
🟠 Notification vulnérabilités : surveiller CVE équipements installés (CISA ICS-CERT, CERT-FR, bulletins constructeurs)
Auprès des fournisseurs IACS :
🟠 Exiger déclaration conformité CRA, SBOM fourni (Siemens, Schneider, …)
🟠 vérifier support cybersécurité 5 ans (firmware updates)
🟠 Contrat SAP : clause mise à jour sécurité MES/ERP incluse
🟠 S’assurer que les fournisseurs IACS respectent CRA pour produits mis sur marché UE
2. En tant que FABRICANT de machines (responsabilité CRA majeure) :
Les machines vendues sont des « produits avec éléments numériques » → CRA APPLICABLE !
1️⃣ Conformité obligatoire machines vendues UE (après déc. 2027) :
Marquage CE étendu : déclaration conformité CRA en plus directives Machines 2006/42/CE (future 2023/1230)
Interdiction vente UE si non-conforme CRA (sanctions : amendes jusqu’à 15M€ ou 2,5% CA mondial)
2️⃣ Sécurité by design & by default (développement machines) :
Conception sécurisée : intégrer cybersécurité dès phase conception (threat modeling, STRIDE, PASTA)
Pas de vulnérabilités connues : machines livrées sans CVE exploitables (scan avant livraison)
Configuration sécurisée par défaut :
Pas de mots de passe par défaut (admin/admin interdit)
Services inutiles désactivés (Telnet, FTP non-sécurisé)
Comptes utilisateurs uniques avec politique mot de passe
Secure boot : automate machine démarre avec firmware signé (si supporté)
Mises à jour sécurisées : mécanisme update firmware avec signature cryptographique
3️⃣ Documentation cybersécurité obligatoire (livrée avec machine) :
Notice cybersécurité :
Bonnes pratiques exploitation machine (isolation réseau, mots de passe, sauvegarde)
Recommandations architecture réseau client (VLAN, firewall, pas d’internet direct)
Procédure mise à jour firmware sécurisée
SBOM (Software Bill of Materials) :
Liste composants logiciels machine avec versions (automate firmware, IHM, bibliothèques)
Format standard : CycloneDX, SPDX
Mise à jour SBOM à chaque modification logicielle
Coordonnées PSIRT : Product Security Incident Response Team (email, téléphone, délai réponse garanti)
Vulnérabilités connues à date livraison : déclaration CVE applicables (si présentes, avec plan correction)
4️⃣ Support cybersécurité 5 ans minimum (après livraison) :
Garantie mises à jour sécurité : fournir patches vulnérabilités découvertes pendant 5 ans
Notification clients sous 24h : si vulnérabilité critique découverte (exploitation active), alerter clients via email/portail
Fourniture correctifs : Délai maximal 14 jours pour patch ou mesures atténuation (workarounds)
Gratuit pour vulnérabilités sécurité (pas de facturation support)
Base de connaissances : portail en ligne accessible clients (CVE, patches, FAQ, procédures)
5️⃣ Gestion vulnérabilités parc installé (machines déjà vendues) :
Inventaire parc machines : base de données clients avec versions firmware installées
Contact clients maintenu : emails/téléphones à jour pour notifications urgentes
Patch rétroactif : fournir correctifs machines anciennes (dans limite 5 ans support)
Procédure rappel : si vulnérabilité critique non patchable (cas extrême, coûteux)
6️⃣ Notification CERT-FR (ANSSI) obligatoire :
24h si exploitation active : vulnérabilité exploitée dans la nature → notification immédiate CERT-FR
72h rapport détaillé : nature vulnérabilité, machines affectées, versions, correctif prévu
Circuit France : CERT-FR transmet à ENISA (coordination européenne CRA)
7️⃣ Supply chain sécurisée (composants machines) :
Exigence fournisseurs : automates, IHM, PC embarqués achetés conformes CRA
Clauses contractuelles : fournisseurs doivent garantir conformité CRA composants
Traçabilité composants : origine, versions, certifications (SBOM en cascade)
Exigences NIS 2
Classification : Actuellement classé Entité Importante (EI) car plus de 50 employés et CA >10 M€
A noter qu’un seul critère aurait suffit. De plus si l’effectif devient > 250 ou le CA > 50M€, l’entreprise sera classée « Entité Essentielle » (EE).
Avec un effectif de 200 personnes et L’entreprise est soumise à NIS2 car elle réalise un CA> 55M€.
🟩 Obligations NIS2 pour EI (constructeur manufacturier) :
➡️ Gouvernance allégée vs EE (Entités Essentielles) :
Direction responsable cybersécurité (pas nécessairement COMEX, RSSI suffit)
Pas de supervision ANSSI continue (vs EE type énergie, nucléaire)
Formation direction recommandée (pas obligatoire strict)
➡️ Incident reporting :
24h alerte précoce CERT-FR si incident significatif (ransomware, vol IP, arrêt production >24h)
72h rapport détaillé : impact, causes, mesures prises
Seuil significatif : >10% production impactée OU données sensibles volées OU tentative intrusion réussie
➡️ Gestion risques cyber :
Analyse de risque formelle : ISO 27005, EBIOS RM, ou IEC 62443-3-2 (adaptée OT)
Plan de traitement risques : roadmap pluriannuelle, budget alloué
PRA/PCA cyber : procédures restauration production + PLM/CAO (actifs critiques)
Tests annuels PCA (exercices, mesure RTO/RPO réels)
➡️ Protection propriété intellectuelle (IP) :
Données CAO/PLM = actif critique à protéger (espionnage industriel, concurrence)
Chiffrement serveurs PLM, contrôle accès strict (DLP, IRM)
Sauvegarde offline immuable (protection ransomware)
➡️ Sécurisation supply chain :
Évaluation cyber fournisseurs critiques (automates, composants machines, cloud)
Clauses contractuelles cybersécurité (NDA, audits, conformité CRA)
Diversification fournisseurs (réduire dépendance mono-source)
➡️ Audits ANSSI possibles :
Même si EI (pas EE), ANSSI peut auditer (contrôle aléatoire ou post-incident)
Pas de supervision permanente (vs EE), mais conformité vérifiable sur demande
Analyse des cyber risques machine
Dans le cadre de cette étude de cas, une analyse approfondie des risques machines a été réalisée afin d’identifier les vulnérabilités potentielles des lignes de productions et des machines construites et automates programmables associés. L’évaluation a pris en compte plusieurs dimensions :
Disponibilité des lignes de production
Les attaques générant des dysfonctionnements des automatismes peuvent entraîner des pertes de production, des arrêts non planifiés et des conséquences sur la sécurité des machines et produits .Intégrité des données et des commandes
La manipulation non autorisée des données ou des commandes peut provoquer des dysfonctionnements critiques. Cette dimension inclut l’analyse des risques liés aux communications OT, aux bus de terrain et aux automates programmables.Confidentialité et protection des informations sensibles
Certaines informations industrielles, telles que les plans des machines, les configurations de systèmes et les savoir faire doivent être protégées contre tout accès non autorisé.Menaces externes et internes
L’évaluation a considéré les risques provenant de menaces externes (attaques cyber, intrusion réseau) et internes (erreurs humaines, accès non contrôlés).Conformité et bonnes pratiques industrielles
Les risques ont été évalués en référence aux normes et standards applicables, notamment la IEC 62443 eet EN 50742, garantissant une approche structurée et conforme aux meilleures pratiques du secteur.
Ransomware ciblé sur plans/CAO :
Chiffrement serveurs PLM → paralysie Bureau d’Études
Menace diffusion plans concurrence (double extorsion)
Coût : perte CA (retards livraison) + rançon potentielle + atteinte réputation
Espionnage industriel :
Vol savoir-faire (algorithmes contrôle, process fabrication)
Concurrence (copie machines), États (transfert technologie)
Cas réels : APT10 (Chine), Turla (Russie) ciblant secteur manufacturier
Sabotage machines livrées :
Code malveillant dans automates machines vendues (supply chain attack)
Activation différée chez client (bombe logique)
Responsabilité fabricant : recalls, dommages clients, poursuites judiciaires
Arrêt production :
Ransomware bloquant MES/ERP → arrêt lignes assemblage
Perte CA : 50-500k€/jour selon taille usine
Pénalités contractuelles clients (retards livraison)
Architecture IEC 62443-3-2
Particularité manufacturier : Convergence IT/OT forte (ERP ↔ MES ↔ Automates), flux bidirectionnels nécessaires (ordres fabrication, remontées production)
Zone 1 (SL2) : PLM/CAO – Propriété Intellectuelle
Justification SL2 :
Actif critique : propriété intellectuelle = cœur business, vol = perte avantage concurrentiel
Impact business : espionnage industriel, copie machines, perte CA
Menace : APT (Advanced Persistent Threat), concurrence, États
Architecture réseau :
Réseau physiquement séparé (câbles dédiés, switch dédié) ou VLAN strict avec firewall en coupure
Accès restreint : Bureau d’Études uniquement (whitelist IP, authentification MFA)
Pas de connexion internet directe depuis postes CAO (proxy filtrant si nécessaire, sites whitelistés)
Transfert fichiers vers production via serveur relais validé (zone tampon DMZ interne)
Zone 2 (SL1-2) : Ligne de production – Assemblage & Robots
Justification SL1-2 :
SL1 zones non-critiques (convoyage simple, stockage)
SL2 îlots critiques (assemblage machines haute valeur, robots collaboratifs sécurité)
Impact : Dos – arrêt production = perte CA, pas de risque humain direct (vs Seveso)
Architecture réseau :
LAN par ligne de production si faisable (Ligne 1, Ligne 2, Robots, Logistique)
Firewall industriel entre production et IT : inspection protocoles OT (Modbus TCP, Profinet, EtherNet/IP)
Segmentation îlots : switch managé par zone, ACL strictes (whitelist IP autorisées)
Engineering stations : réseau dédié ou VLAN strict, accès via Jump Host/Server recommandé
Conduits critiques :
MES → Automates : téléchargement ordres fabrication (OF), recettes produits (lecture/écriture contrôlée)
Automates → MES : remontée données production (quantités, temps cycle, alarmes) – préférer unidirectionnel si possible
Engineering → Automates : téléchargement programmes (conduit temporaire, activé sur demande, loggé)
Mesures brownfield réalistes :
Ne pas sur-segmenter : VLAN par ligne acceptable, micro-segmentation par machine = trop complexe brownfield
Firewall IT/OT : déploiement prioritaire (quick win, 3-6 mois)
Migration progressive VLAN : commencer par nouvelles lignes, migrer anciennes lors arrêts maintenance
Zone 3 (SL1-2) : Bancs de test – Validation machines clients
RISQUE SPÉCIFIQUE : Contamination malware machines clients testées
Justification SL2 (élevée pour zone test) :
Machines clients potentiellement compromises (provenance inconnue, malware dormant)
Risque propagation : malware machine client → réseau bancs test → production interne
Cas réels : USB infectée client, backdoor automate client, ransomware latent
Architecture réseau (isolation critique) :
VLAN dédié bancs test : aucune connexion directe production/IT (air-gap logique)
Quarantaine obligatoire : machine client testée isolée jusqu’à validation saine
Scan antivirus/malware machine client avant connexion réseau (offline si possible)
Automates jetables/réinitialisables pour tests : réinitialisation complète après chaque machine client
Serveur relais : transfert données test via serveur scanné (pas de connexion directe banc → IT)
Procédure test machine client (sécurisée) :
Réception machine client : inspection visuelle/signature, pas de connexion réseau immédiate
Connexion banc test isolé (VLAN quarantaine, pas d’accès autres zones)
Scan antivirus automate client (Kaspersky, Trend Micro Industrial) si accessible
Tests fonctionnels : validation conformité, mesures, traçabilité
Récupération données test : export via clé USB scannée OU serveur relais
Réinitialisation banc test : reset automate, effacement logs, validation intégrité
Autorisation libération machine client (si conforme)
Mesures compensatoires si isolation impossible (brownfield contraint) :
IDS passif surveillance permanente VLAN bancs test (alerte si activité suspecte)
Logs exhaustifs connexions machines clients (IP, MAC, timestamps)
Interdiction clés USB machines clients vers réseau interne (contrôle strict)
Audit mensuel bancs test : vérification absence malware, comparaison baseline
Zone 4 (SL1) : IT Bureautique & ERP
Architecture réseau :
Séparation stricte IT/OT : aucun routage direct vers production/PLM
DMZ pour échanges nécessaires : serveurs relais (données production → ERP, plans validés PLM → IT)
Firewall double : IT ↔ DMZ ↔ OT (inspection applicative, pas de bypass)
Mesures standard IT (pas spécifique OT) :
Antivirus/EDR : Microsoft Defender, CrowdStrike, SentinelOne
Patch automatique : Windows Update, WSUS (déploiement progressif)
Filtrage web : proxy Squid, Forcepoint, Zscaler (blocage sites malveillants)
Anti-phishing emails : sandboxing (Proofpoint, Mimecast), formation utilisateurs
MFA : Office 365, ERP (Azure MFA, Duo, Google Authenticator)
Sauvegarde ERP : quotidienne, rétention 90j, tests restauration trimestriels
Zone 5 (SL1) : DMZ Clients – Accès SAV sécurisé
Périmètre :
Serveurs portail extranet : documentation machines (manuels, pièces détachées, SBOM)
Serveurs patches/firmwares : téléchargement mises à jour machines vendues (espace client sécurisé)
VPN clients : accès SAV pour support à distance machines installées chez clients (si proposé)
Architecture double firewall (sécurité maximale) :
Internet → Firewall 1 → DMZ Clients → Firewall 2 → Interne (JAMAIS de connexion directe)
Mesures sécurité DMZ :
VPN clients avec MFA : accès portail uniquement (pas d’accès réseau interne)
Serveur relais SAV : si support à distance machine client nécessaire, via bastion enregistré
Honeypot : serveur leurre dans DMZ (détection tentatives intrusion, threat intelligence)
WAF (Web Application Firewall) : protection portail web (injection SQL, XSS, CSRF)
Monitoring renforcé : logs exhaustifs DMZ analysés SIEM, alertes temps réel
Limitation accès SAV machines clients :
Jamais d’accès direct fabricant → machine client via internet (risque supply chain attack inverse)
Si support nécessaire : VPN initié par client, session temporaire, enregistrée, validée contrat
Privilégier support par documentation/vidéos (réduire connexions à distance)
Outils et solutions
Défense périphérique brownfield réaliste
◉ Architecture réseau (segmentation zones) – Priorité investissement
Firewall industriel IT/OT (investissement prioritaire – Quick Win) :
◆ Fortinet FortiGate 60F/80F/100F (adapté PME)
◇ Inspection DPI protocoles OT (Modbus, S7comm, CIP, Profinet)
◇ Antivirus intégré, IPS signatures industrielles
◆ Stormshield SN160/SN210 : français, certifié ANSSI (CSPN), recommandé si sensible
◆ Cisco Firepower 1010 : intégration écosystème Cisco
Switch managés VLAN (segmentation production) :
◆ Hirschmann MACH104 : très répandu industrie, fiable
◆ Moxa EDS-G516E : bon rapport qualité/prix, management simple
◆ Siemens Scalance XC/XM : intégration TIA Portal (justifié si siemens)
◆ Cisco Industrial Ethernet (IE) 2000 (si budget et compétences réseau Cisco)
Réseau PLM/CAO physiquement séparé (si budget) :
◆ Switch dédié + câblage séparé : si budget ou client défense
◆ Alternative pragmatique : VLAN strict + firewall
◉ Détection et supervision (visibilité menaces)
IDS/IPS OT passif (détection anomalies) :
◆ Nozomi Guardian : détection passive, reconnaissance automates, ML anomalies (si budget cyber > 100K€)
◆ Alternative PME : Zeek (Bro) open-source + scripts ICS (gratuit)
◆ Claroty xDome / Dragos Platform / Darktrace industrial (trop cher)
◉ Asset inventory (inventaire équipements)
Approche pragmatique PME – Inventaire hybride réaliste (pas d’outil miracle) :
Niveau 1 (automates Ethernet) :
◆ Nmap + NSE scripts ICS : scan passif gratuit (0€, expertise nécessaire)
OU Nozomi si souscription IDS (inventaire inclus)
Niveau 2 (serveurs, PC) :
◆ Lansweeper : inventaire IT simple
OU GLPI open-source (gratuit, interface basique)
Niveau 0 (capteurs/E/S) :
◆ Documentation manuelle : schémas EPLAN, Excel, audit annuel (5-10 jours/homme)
GMAO : SAP PM, CARL Source (si existant, sinon Excel suffit)
◉ SIEM industriel (corrélation événements)
Solutions adaptées PME :
◆ Graylog open-source : meilleur choix PME
Gratuit, interface web, recherche logs puissante
◆ Wazuh : alternative open-source (HIDS + SIEM)
Gratuit, agent-based, intégration Elastic Stack
Solutions acceptables (si budget confortable) :
◆ Microsoft Sentinel : si écosystème Microsoft/Azure
Justifié si Office 365 E5 + Azure déjà présent
◉ Protection Propriété Intellectuelle (spécifique manufacturier)
DLP (Data Loss Prevention) – Surveillance exfiltration plans
Solutions adaptées PME :
◆ Microsoft Purview DLP : si Office 365 E3/E5
Recommandé : si Microsoft 365, activation obligatoire
◆ GPO Windows + monitoring manuel : alternative gratuite
Blocage clés USB (Device Installation policies)
Blocage OneDrive perso, Google Drive (AppLocker)
Suffisant PME si BE <20 personnes
◉ Chiffrement données au repos (serveurs PLM, NAS)
Solutions gratuites adaptées PME :
◆ BitLocker : inclus Windows Server/Pro
activer systématiquement (obligation RGPD)
◆ VeraCrypt : open-source, multiplateforme
Gratuit, robuste – Bon pour disques externes backup offline
◆ Chiffrement NAS natif : Synology/QNAP
Inclus (gratuit), transparent utilisateurs – Activer obligatoirement
◉ Device Control (blocage clés USB)
Solutions gratuites adaptées PME :
◆ GPO Windows : gratuit, efficace
Blocage USB masse (sauf whitelist devices)
Configuration Active Directory (2-5 jours/homme)
◉ Gestion identités & accès (IAM)
Solutions adaptées PME :
MFA (Multi-Factor Authentication)
◆ Microsoft Azure MFA : si Office 365
Intégration native Azure AD, push notifications
◆ Google Authenticator : gratuit
TOTP, app smartphone gratuite
Bon si budget serré (user gère token)
◆ Yubikey : tokens matériels
Recommandé postes critiques (admin, BE senior)
◉ Jump Server / Bastion
Solutions adaptées PME :
◆ Apache Guacamole : open-source, excellent PME
Clientless (navigateur), RDP/SSH/VNC
◆ Wallix Bastion : français, certifié ANSSI- Solutions acceptables (si budget confortable clients défense OU exigence ANSSI)
Sessions vidéo enregistrées, MFA intégré
Solutions moins adaptées PME :
CyberArk PAM, BeyondTrust (orienté grands comptes, complexité excessive pour PME)
◉ Gestion mots de passe (coffre-fort)
Solutions économiques PME :
◆ Bitwarden : open-source, excellent
Cloud ou self-hosted
◆ KeePass : open-source, local
Gratuit, fichier local, Bon si <10 users, synchronisation manuelle acceptable
Solutions moins adaptées PME :
CyberArk, 1Password Business, …
◉ Gestion vulnérabilités & patch management
Scanner vulnérabilités
Solutions adaptées PME :
◆ Nmap + NSE scripts ICS : gratuit, efficace, scan ports + services + versions
◆ OpenVAS (Greenbone) : open-source
Scanner gratuit, signatures régulières, bon compromis PME
◆ Tenable Nessus Professional : référence marché, justifié si budget et audits clients (ISO 27001, certifications)
Solutions plus adaptées grande entreprise :
Tenable OT security, Qualys VMDR (cher, fonctions avancées, orienté multi-sites)
◉ Veille CVE (surveillance vulnérabilités)
Solutions gratuites adaptées PME :
◆ CISA KEV catalogue (Known Exploited Vulnerabilities), exploit actif
◆ The ICS Advisory Project (OT/ICS)
◆ Bulletins constructeurs : Siemens, Rockwell, Schneider
◆ NVD : flux RSS/JSON gratuit, automatisable (scripts Python parsing)
◆ CERT-FR
◉ Sauvegarde & résilience
Backup offline PLM/CAO
Solutions adaptées PME :
◆ Veeam Backup & Replication : recommandé si VMware/Hyper-V
◆ NAS Synology/QNAP : Snapshots immuables, réplication, recommandé excellent rapport qualité/prix
◆ Bandes LTO-9 : archivage long terme – Offline total (protection ransomware maximale), recommandé plans critiques (archivage 7+ ans)
Solutions moins adaptées PME :
Acronis Cyber Backup, Solutions enterprise multi-sites (coût et dimensionnement excessif).
◉ Sauvegarde configs automates
◆ Scripts automatisés :
TIA Portal Openness (PowerShell)
pycomm3 (Python Rockwell) : open-source
Control Expert API (VBA/Python) : inclus logiciel
◆ Planification : Windows Scheduler via stockage NAS
◉ Sécurisation machines vendues (conformité CRA)
Tests sécurité pré-livraison
Solutions adaptées PME :
◆ Scan Nmap + NSE scripts ICS : gratuit
Suffit validation basique (ports, services, versions)
◆ Checklist manuelle : procédure validée
PW défaut, services inutiles, logs, procédure organisationnelle recommandé (pragmatique, efficace)
Pentest externe ponctuel (si budget/exigence clients) : prestataire spécialisé, justifié machines critiques (défense, médical, >100k€)
◆ SLA (Service Level Agreement) – Analyse et réponse aux alertes
◉ PSIRT (support après-vente)
Organisation équipe
◆ Responsable PSIRT + support technique
◆ CRM clients : si existant (Salesforce, Dynamics), sinon Excel structuré (gratuit)
◆ Veille CVE : gratuite (CISA, NVD, bulletins)
◆ Portail web : SharePoint si Office 365 ou page web.
Exigences détaillées Zone ICS
✅ Périmètre : Automates ligne assemblage, robots/cobots, convoyeurs, AGV/AMR, capteurs/actionneurs, réseaux Profinet, EtherNet/IP, Modbus TCP, Ethercat
IAC – Authentification : contrôle d’accès physique renforcé…
UC – Contrôle d’usage : procédure LOTO stricte …
SI – Intégrité : baseline configuration …
DC – Confidentialité : chiffrement …
RDF – Isolation réseau : LAN séparé, diode unidirectionnelle …
TRE – Réponse événements : IDS passif…
RA – Disponibilité : ne rien toucher au SIS existant…
Mesure compensatoire clé : surveillance périmétrique passive …
✅ Accès automates (programmation, diagnostic) :
◆ Comptes nominatifs logiciels engineering : TIA Portal, Studio 5000, Control Expert, TwinCAT
– Pas de compte partagé « maintenance » (traçabilité individuelle obligatoire)
– Intégration Active Directory si possible (SSO, gestion centralisée)
– Logs connexions : qui a connecté quel automate, quand (audit trail)
◆ Mot de passe automate activé :
– Siemens S7-1500 : protection accès CPU (read/write/full), Know-how protection blocs
– Rockwell ControlLogix : Source Key protection (empêche lecture programme sans clé)
– Schneider M340/M580 : Security Editor (4 profils : Operator, Maintenance, Engineer, Administrator)
– Beckhoff TwinCAT : User management avec droits granulaires
◆ Pas de MFA native automate legacy :
– Automates anciens (S7-300, vieux CompactLogix) : pas d’auth individuelle → mesures compensatoires :
– MFA au niveau Jump Server (bastion pour accès automates)
– MFA stations engineering (Windows Hello, Duo, Azure MFA)
– Contrôle accès réseau (firewall whitelist IP sources autorisées)
✅ Accès physique contrôlé :
◆ Armoires automates verrouillées : clés tracées (registre manuscrit ou électronique)
◆ Logs accès physiques : badge RFID entrées ateliers, caméras zones automates (si sensible)
◆ Stations engineering sécurisées :
– Stockage salle dédiée (pas en atelier production, risque vol/sabotage)
– Verrouillage automatique session (timeout 15 min inactivité)
– Chiffrement disque dur (BitLocker, VeraCrypt)
✅ Authentification réseaux terrain (protocoles industriels) :
◆ Profinet avec DCP Security (Siemens TIA Portal V17+) : authentification équipements, pas par défaut legacy
◆ EtherNet/IP avec CIP Security (Rockwell ControlLogix 5580+) : chiffrement TLS, authentification certificats
◆ Modbus TCP non sécurisé : acceptable en brownfield si réseau isolé firewall (pas de chiffrement natif)
◆ Segmentation réseau = sécurité principale : VLAN, firewall (protection périmétrique prioritaire vs protocole)
✅ Limitation réaliste brownfield :
Automates anciens (S7-300/400, Premium, Quantum, vieux CompactLogix) : aucune authentification individuelle
◆ Mesures compensatoires obligatoires :
– Contrôle accès réseau strict (firewall, ACL switch, whitelist IP)
– Logging stations engineering (toute connexion tracée)
– Surveillance IDS passif (alerte téléchargement programme)
– Procédure organisationnelle : validation responsable production avant modif
✅ Gestion des rôles (RBAC – Role-Based Access Control) :
◆ Opérateur :
– Supervision IHM uniquement (lecture états production, acquittement alarmes)
– Pas de modification paramètres process, recettes, programmes
– Accès limité boutons/écrans IHM (configuration TIA Portal, FactoryTalk View)
◆ Technicien maintenance :
– Accès diagnostic automates (TIA Portal mode online, Studio 5000 monitoring)
– Pas de téléchargement programme (lecture seule, ou upload seulement)
– Modification paramètres process autorisée (setpoints, timers) avec validation
◆ Ingénieur méthodes :
– Modification programmes automates (téléchargement, debug)
– Validation responsable production obligatoire avant téléchargement
– Fenêtre maintenance planifiée (pas de modif production running sauf urgence)
◆ Administrateur :
– Gestion utilisateurs, backup/restore, configuration réseau
– Double validation pour actions critiques (reset factory, firmware update)
✅ Traçabilité actions (audit trail) :
◆ TIA Portal :
– Activation audit trail (menu Options → Settings → Audit)
– Logs : qui a téléchargé programme, bloc modifié, timestamp
– Export logs CSV/XML (archivage SIEM ou serveur fichiers)
◆ Studio 5000 :
– Logs changements dans projet (Compare tool, versioning)
– FactoryTalk View / Historian : logs actions opérateur HMI
– Logix Echo (module add-on) : enregistrement checksums programmes, détection modifications
◆ Control Expert (Schneider) :
– Versioning projets avec commentaires obligatoires (décrire modification)
– Cybersecurity Admin Expert (CAE) : audit centralisé actions (qui a connecté, modifié, téléchargé)
◆ Logs centralisés syslog :
– Automates modernes (S7-1500, ControlLogix 5580, M580) : envoi syslog serveur central
– SIEM corrélation (Graylog, Splunk) : détection actions suspectes (hors horaires, séquences anormales)
✅ Validation modifications critiques :
◆ Changement programme automate → validation responsable production écrite (email, signature papier)
◆ Test en simulation si automate le permet :
– PLCSIM (Siemens) : simulation S7-1500 sur PC avant téléchargement réel
– Studio 5000 Emulate (Rockwell) : émulation ControlLogix virtuel
– Control Expert Simulator (Schneider) : test logique hors production
◆ Fenêtre de maintenance planifiée :
– Modifications programmes uniquement arrêts production (nuit, weekend, maintenance programmée)
– Exception urgence : validation direction + documentation a posteriori
– Pas de modif en production running sauf mode « online change » validé (automates récents uniquement)
✅ Limitation accès réseau (principe moindre privilège) :
◆ Téléchargement programmes uniquement depuis stations engineering autorisées :
– Whitelist IP sources sur firewall/ACL switch
◆ Pas d’accès direct automate depuis réseau IT :
– Obligatoire passer par Jump Server OU DMZ relais
– Logs sessions Jump Server (traçabilité, rejouabilité)
◆ Blocage protocoles dangereux :
– Telnet désactivé (SSH v2 si remote nécessaire)
– FTP désactivé (SFTP ou SCP si transfert fichiers)
– HTTP désactivé (HTTPS obligatoire serveurs web automates)
Protection programmes (baseline + surveillance) :
◆ Configuration de base sauvegardée :
– Archive projets TIA Portal (.zap15), Studio 5000 (.ACD), Control Expert (.stu, .xef)
– Versioning Git OU serveur fichiers versionné (historique modifications)
– Stockage sécurisé : NAS chiffré, réplication offsite, backup offline
– Rétention 6-12 mois minimum (historique versions, rollback si besoin)
◆ Comparaison périodique (détection modifications non autorisées) :
– Upload mensuel manuel/scripté : récupération programme automate, comparaison vs baseline
– Scripts automatisés :
* TIA Portal Openness (PowerShell) : upload S7-1500, compare projet (gratuit, développement interne)
* pycomm3 (Python) : upload ControlLogix L5K, hash MD5 comparaison (open-source)
* Control Expert API : upload Schneider, compare (inclus logiciel, scripting VBA/Python)
– Schneider M580 avec CAE : scan automatisé conformité baseline (si licence CAE disponible)
– Rapport écarts : alerte si différence détectée (investigation : légitime ou malveillant ?)
Détection temps réel modifications (monitoring) :
◆ IDS passif OT (Claroty, Nozomi, Dragos) :
– Analyse trafic réseau (span port switch production)
– Détection téléchargement programme (protocoles S7comm Write, CIP Download, Modbus Write)
– Alerte immédiate si téléchargement hors fenêtre maintenance autorisée
– Corrélation : téléchargement + source IP → identification station engineering
◆ Syslog automates récents :
– S7-1500, ControlLogix 5580, M580 : événement « Program – Download » vers SIEM
– Corrélation SIEM : téléchargement hors horaires bureau → alerte équipe cyber
◆ Code applicatif automate (monitoring intégrité embarqué – avancé) :
– FB_IntegrityMonitor : bloc fonctionnel dans programme automate
– Lecture variables système (checksum programme, version blocs, timestamp dernière modif)
– Comparaison vs baseline stockée (DB automate ou serveur externe)
– Alerte si CRC différent : envoi vers SCADA/SIEM (OPC-UA, Modbus TCP, MQTT)
– Limitation : charge CPU (exécution tâche basse priorité 1s-10s, pas cyclique rapide)
Baseline intégrité (CRC vs SHA-256) :
◆ Niveau 1 – CRC32 automate (détection rapide) :
– Checksum natif automate (léger CPU)
– Comparaison locale vs baseline CRC
– But : détection modification accidentelle ou tentative basique
– Heartbeat (message de vie) horaire : envoi CRC vers SCADA/serveur (OPC-UA, syslog)
◆ Niveau 2 – SHA-256 serveur (validation cryptographique) :
– Upload programme complet vers serveur sécurisé (hebdomadaire ou mensuel)
– Calcul SHA-256 côté serveur (Python, Node.js avec bibliothèques crypto)
– Comparaison avec baseline SHA-256 stocké chiffré (serveur externe, pas automate modifiable)
– But : détection modification malveillante sophistiquée (attaquant ne peut pas recalculer SHA-256 sans accès serveur)
– Pourquoi SHA-256 plutôt que CRC :
* CRC = détection corruption accidentelle, pas cryptographiquement sûr (attaquant peut recalculer)
* SHA-256 = hash cryptographique, impossible créer collision intentionnelle
* HMAC-SHA256 (optimal si implémentable) : hash avec clé secrète, protection maximale
Protection écriture automate :
◆ Mode RUN protégé :
– Siemens : passage STOP → RUN nécessite mot de passe (configuration TIA Portal)
– Rockwell : Keyswitch position RUN (protection physique) ou password (ControlLogix)
– Schneider : Security Editor (profil Engineer minimum pour passage STOP/RUN)
◆ Protection blocs fonctionnels :
– Know-how protection (Siemens) : blocs FC/FB protégés, lecture code impossible sans password
– Source Key (Rockwell) : protection lecture programme (upload nécessite clé)
– Code encryption (Schneider Control Expert) : chiffrement projet
Firmware automates (approche ultra-prudente brownfield) :
◆ Ne pas mettre à jour firmware sans raison critique :
– Risque régression fonctionnelle, instabilité process
– Compatibilité matérielle (modules I/O, réseaux terrain)
– Requalification applicative potentiellement nécessaire
◆ Si update obligatoire (CVE critique exploitée, support constructeur obsolescence) :
– Test automate spare identique : validation fonctionnelle complète (1-4 semaines)
– Validation constructeur : bulletin technique, procédure officielle
– Fenêtre maintenance : arrêt production planifié (nuit, weekend)
– Plan retour arrière : procédure rollback firmware ancien testée (backup firmware précédent)
◆ Inventaire versions firmware :
– Documentation papier + fichier Excel/base données
– Asset discovery OT (Claroty, Nozomi) si compatible automates récents
– Audit physique annuel : relevé versions réelles (étiquettes CPU, lecture online)
Mesure compensatoire legacy (automates anciens sans fonctions intégrité) :
◆ Protection périmétrique maximale :
– Firewall strict entre production et IT (whitelist IP/ports, inspection protocoles)
– IDS passif surveillance permanente (Claroty, Nozomi)
– Isolation réseau : VLAN dédié, pas de routage vers IT
◆ Surveillance accès :
– Logs stations engineering centralisés (GPO Windows Event Forwarding, syslog)
– Caméras salles automates (si sensible, enregistrement 30-90j)
– Alertes IDS si connexion automate hors fenêtre maintenance
◆ Durcissement stations engineering :
– Antivirus OT-compatible (Trend Micro, Kaspersky Industrial)
– Whitelist applications (AppLocker, Device Guard)
– Pas de navigation internet (proxy filtrant strict, sites whitelistés)
– MFA accès session Windows (Hello, Duo, Azure MFA)
✅ Chiffrement flux (sélectif, pragmatique) :
◆ TLS 1.2+ pour IHM web :
– Serveurs web automates (WinCC Web Navigator, FactoryTalk View SE, Ignition) : HTTPS obligatoire
– Certificats valides (pas auto-signés) : Let’s Encrypt (gratuit) ou CA interne
◆ VPN IPsec pour accès distant :
– Support constructeur (Siemens Remote Service, Rockwell FactoryTalk TeamONE)
– Tunnel chiffré AES-256, authentification certificats + MFA
– Session temporaire (durée limitée intervention), logs exhaustifs
◆ OPC-UA avec Security :
– Intégration MES/SCADA récente : OPC-UA mode Sign&Encrypt (chiffrement + auth certificats)
– Configuration : TIA Portal OPC-UA Server Security Policy (Basic256Sha256 minimum)
– PKI interne : certificats équipements (autorité certification locale ou constructeur)
◆ Pas de chiffrement natif Profinet/Modbus legacy :
– Acceptable brownfield si réseau isolé firewall
– Profinet avec DCP Security (automates avec TIA V17+) : optionnel si budget/compatibilité
– Chiffrement end-to-end impossible sans remplacement complet → chiffrement au niveau périmètre
✅ Chiffrement données sensibles (recettes, programmes) :
◆ Recettes production :
– Stockage serveur MES chiffré (AES-256, base données SQL Server TDE ou Oracle TDE)
– Transmission automate ↔ MES : OPC-UA chiffré (si supporté) OU réseau isolé acceptable
◆ Programmes automates avec protection :
– Know-how protection Siemens (obfuscation, pas chiffrement strict mais acceptable)
– Source Key Rockwell (empêche lecture, équivalent protection IP)
– Schneider Code Encryption (chiffrement projet Control Expert)
◆ Plans machines (si stockés production) :
– Serveurs fichiers chiffrés (BitLocker, VeraCrypt, NAS encryption)
– Transfert PLM → Production : via serveur relais sécurisé (pas de partage réseau direct)
◆ Réalisme brownfield (pas de sur-engineering) :
– Pas de chiffrement end-to-end automate ↔ SCADA sur legacy :
* Impossible sans remplacement complet équipements
* Compensation : segmentation réseau stricte, firewall, IDS
– Chiffrement au niveau périmètre prioritaire :
* VPN accès distant
* TLS IHM web, OPC-UA moderne
* Accepter Modbus/Profinet en clair si zone isolée
✅ Segmentation réseau (zones isolées) :
◆ VLAN par ligne de production (si faisable brownfield) :
– Ligne 1 : VLAN 100 (automates assemblage, robots, convoyeurs)
– Ligne 2 : VLAN 200 (automates tests, stations qualité)
– Robots/Cobots : VLAN 300 (îlot robotique centralisé)
– AGV/AMR : VLAN 400 (véhicules guidés)
– MES/SCADA : VLAN 500 (supervision centrale)
◆ Firewall industriel en coupure IT/OT (investissement prioritaire) :
– Inspection protocoles industriels (DPI Modbus, S7comm, CIP, Profinet)
– ACL strictes : whitelist IP/ports autorisées (deny all par défaut)
– Logs exhaustifs : toute traversée firewall loggée SIEM
– Exemples : Fortinet FortiGate 60F/100F, Palo Alto PA-220, Stormshield SN160
◆ Micro-segmentation progressive :
– Ne pas sur-segmenter : VLAN par ligne acceptable, par machine = trop complexe brownfield
– Priorité : séparation IT/OT (firewall global), puis VLAN lignes critiques
– Migration progressive : commencer nouvelles lignes, migrer anciennes lors arrêts maintenance
✅ Conduits contrôlés (flux autorisés explicitement) :
◆ Automates ↔ SCADA/MES :
– Préférer flux unidirectionnel : automates → MES (remontée données process, pas de commande retour)
– Si bidirectionnel nécessaire : inspection firewall, ACL strictes (whitelist registres Modbus, tags OPC)
– Protocoles : OPC-UA (préféré moderne), Modbus TCP, S7comm, EtherNet/IP
◆ Stations engineering ↔ Automates :
– Conduit dédié VLAN engineering ou firewall ACL
– Filtrage IP source : seules stations BE autorisées (192.168.10.50-60)
– Protocoles : S7comm (Siemens), CIP (Rockwell), Modbus TCP (Schneider)
– Logs connexions : timestamp, IP source, automate cible (audit trail)
◆ MES ↔ ERP :
– Pas de connexion directe : via DMZ relais (double firewall)
– Serveur relais : middleware (API REST, message broker RabbitMQ/Kafka)
– Protocoles : HTTPS (API), SQL sécurisé (connexion chiffrée, compte read-only)
✅ Isolation réseaux terrain (protocoles industriels) :
◆ Profinet :
– VLAN dédié réseau Profinet (pas de routage vers IT, même pas vers MES si possible)
– Multicast flooding : limitation switches (IGMP snooping activé)
– Séparation physique câblage si critique (chemins câbles dédiés)
◆ EtherNet/IP :
– Réseau industriel isolé (VLAN ou switch dédié)
– Passerelle contrôlée vers supervision (firewall ou gateway Rockwell Stratix)
◆ Modbus RTU/RS485 :
– Air-gap naturel (série, pas d’IP)
– Conversion Modbus RTU → TCP : passerelle isolée (Moxa MGate, Anybus)
✅ Pas d’accès internet automates (sécurité maximale) :
◆ Updates firmware :
– Téléchargement manuel PC IT (site constructeur)
– Transfert vers serveur relais OT (scan antivirus, validation)
– Déploiement depuis serveur relais vers automates (contrôlé, loggé)
◆ Support constructeur :
– VPN temporaire via Jump Server (pas d’accès direct automate depuis internet)
– Session enregistrée (Wallix Bastion, CyberArk), rejouable pour audit
– Durée limitée (2-8h intervention), désactivation après
✅ Micro-segmentation progressive (roadmap réaliste) :
◆ Phase 1 (0-6 mois) : Firewall IT/OT global (quick win, protection immédiate)
◆ Phase 2 (6-18 mois) : VLAN lignes critiques (assemblage machines haute valeur, robots)
◆ Phase 3 (18-36 mois) : VLAN toutes lignes + ACL inter-VLAN (défense en profondeur)
◆ Phase 4 (36+ mois) : Micro-segmentation avancée (si ROI justifié, pas systématique)
✅ Collecte logs (visibilité événements) :
◆ Automates modernes (S7-1500, ControlLogix 5580, M580) :
– Syslog vers serveur central (Graylog, Splunk, rsyslog)
– Événements : connexions engineering, téléchargements programmes, erreurs CPU, basculements redondance
– Configuration : TIA Portal (Diagnostic → Syslog), Studio 5000 (Controller Properties → Syslog)
◆ Automates legacy (S7-300, vieux CompactLogix) :
– Pas de syslog natif → logs stations engineering (connexions TIA Portal, Studio 5000 tracées Windows Event Log)
– Centralisation : GPO Windows Event Forwarding vers serveur WEF (gratuit, complexe) ou agent SIEM
◆ SCADA/MES :
– Logs événements process + cyber : WinCC Audit (Siemens), FactoryTalk Historian (Rockwell)
– Alarmes process corrélées : déviations paramètres = possible cyber-attack (analyse conjointe)
◆ Firewall, switches, IDS :
– Syslog exhaustif : connexions, blocages ACL, alertes IDS
– Stockage centralisé SIEM (rétention 90j minimum, 1 an recommandé)
✅ Détection anomalies (corrélation événements) :
◆ IDS passif OT (Claroty, Nozomi, Dragos) :
– Alertes scan réseau (Nmap, Shodan), connexions inhabituelles (IP inconnues), téléchargements programmes
– Détection protocoles anormaux (HTTP sur port Modbus, S7comm depuis IT)
– Threat intelligence OT : signatures malwares ICS (Industroyer, Triton, Havex)
◆ SIEM industriel (Splunk, Graylog, Wazuh) :
– Corrélation événements multi-sources (firewall + IDS + automates + stations engineering)
– Règles détection :
* Téléchargement programme hors horaires (21h-6h) → alerte niveau 2
* Connexion automate depuis IP inconnue → alerte niveau 1 (investigation immédiate)
* Scan réseau production (multiples connexions TCP SYN) → alerte niveau 1
* Succession actions suspectes (scan + connexion + téléchargement) → alerte niveau 3 (incident confirmé)
◆ Monitoring process (corrélation cyber-process) :
– Déviations paramètres process (température, pression, débit, vitesse) = possible cyber-attack
– Exemple : température four augmente sans ordre opérateur → investigation (cyber ou panne ?)
– Équipe production + cyber : analyse conjointe (compétences complémentaires)
✅ Alerting (notification équipes) :
◆ Niveaux alertes :
* Niveau 1 (info) : événement suspect, investigation non urgente (scan réseau, tentative connexion échouée)
* Niveau 2 (warning) : anomalie significative, investigation 4h (téléchargement hors horaires, accès non autorisé réussi)
* Niveau 3 (critical) : incident confirmé, réponse immédiate (ransomware détecté, arrêt ligne inexpliqué, modification programme malveillante)
◆ Canaux notification :
– Email (SIEM → équipe cyber, responsable production)
– SMS/appel (niveau 3 uniquement, astreinte 24/7 si production continue)
– Dashboard SIEM (supervision temps réel SOC interne ou MSSP)
◆ Escalade :
– Niveau 1 → admin réseau (investigation 24h)
– Niveau 2 → RSSI + responsable production (investigation 4h, décision arrêt ligne si nécessaire)
– Niveau 3 → Direction + cellule crise (réponse immédiate, coordination interne/externe)
✅ Procédure incident (graduated response) :
1 ◆ Détection :
– IDS alerte, monitoring détecte anomalie, opérateur signalement
– Horodatage précis (UTC), capture contexte (logs, screenshots)
2 ◆ Analyse initiale (15-60 min) :
– Équipe cyber : vérification alerte (faux positif ? incident réel ?)
– Évaluation criticité : impact production, vol données, propagation possible ?
– Identification source : interne (erreur, malveillance), externe (internet, USB), indéterminé
3 ◆ Confinement (si incident confirmé) :
– Isolation segment réseau : débrancher switch physiquement OU blocage firewall (commande CLI)
– Pas d’arrêt automate sauf validation responsable production (impact CA)
– Préservation preuves : copie logs, capture mémoire (si forensic nécessaire), photos écrans
4 ◆ Éradication :
– Nettoyage malware : antivirus, reinstallation OS si nécessaire
– Restauration backups : programmes automates, serveurs MES/SCADA
– Validation intégrité : scan complet, comparaison baseline (SHA-256)
5 ◆ Récupération :
– Remise en service progressive : tests fonctionnels, validation qualité
– Surveillance renforcée 72h : monitoring continu, détection récidive
– Autorisation reprise production : responsable production + RSSI
6 ◆ Leçons apprises (post-incident, 1-2 semaines) :
– REX (Retour d’Expérience) : causes racines (méthode 5 Pourquoi, diagramme Ishikawa)
– Actions correctives : failles comblées (technique + organisationnel)
– Mise à jour procédures : correction process, formation équipes
– Capitalisation : documentation incident, partage REX (interne, secteur si approprié)
✅ Limitations réalistes (pas de sur-automatisation) :
◆ Pas de réponse automatisée bloquant production : validation humaine obligatoire (faux positifs possibles)
◆ Pas d’EDR sur automates : n’existe pas car dangereux pour process, protection périmétrique + monitoring externe uniquement
◆ Temps réponse acceptable : 15 min détection, 1h analyse, 4h confinement (SL2 brownfield réaliste)
✅ Redondance automates (ne pas modifier si existante) :
◆ Architecture native :
– S7-1500R/H (Siemens) : redondance contrôleur hot-standby, basculement <100ms
– ControlLogix Redundancy (Rockwell) : deux contrôleurs synchronisés, bumpless transfer
– M580 Hot Standby (Schneider) : HSBY redondance, basculement <50ms
◆ Ne jamais modifier redondance native :
– Configuration validée constructeur, modification = risque instabilité
– Tests périodiques redondance (simulation panne, validation basculement) : procédure constructeur
◆ Stock spare (si pas de redondance) :
– CPU + modules I/O critiques (1 spare minimum, 2 si lead time long >6 mois)
– Stockage conditions contrôlées (température, humidité, ESD)
– Pas de redondance forcée si ligne non-critique : coût vs bénéfice (accepter risque panne)
✅ Sauvegarde configurations (protection données) :
◆ Backup avant toute intervention (procédure obligatoire non négociable) :
– Upload programme automate (TIA Portal, Studio 5000, Control Expert)
– Sauvegarde manuelle : fichier daté (nom format : PLC01_2026-11-27_beforeModif.zap15)
– Validation : test restauration backup sur automate spare (si disponible)
◆ Backup hebdomadaire automatisé :
– Scripts TIA Portal Openness (PowerShell), pycomm3 (Python), Control Expert API
– Planification : tâche Windows Scheduler, cron Linux (dimanche 2h du matin)
– Stockage : NAS chiffré, rétention 6 mois (26 versions hebdomadaires)
◆ Backup serveurs SCADA/MES :
– Snapshot quotidien si virtualisé (VMware, Hyper-V) : rétention 7j
– Backup complet hebdomadaire : Veeam, Acronis, rétention 3 mois
– Test restauration trimestriel : validation procédure, mesure temps (RTO réel)
✅ Plan de reprise (RTO/RPO réalistes brownfield) :
◆ RTO (Recovery Time Objective) ligne production :
– Ligne critique (machines haute valeur, goulet) : <4h (restauration automate + tests)
– Ligne secondaire : <8h (acceptable impact CA limité)
– Ligne non-critique : <24h (stock produits finis absorbe)
◆ RPO (Recovery Point Objective) :
– Automates : <7j (backup hebdomadaire acceptable, modifications rares)
– MES/SCADA : <24h (données production perdues acceptables si <1 jour)
– PLM/CAO : <4h (données critiques, backup fréquent obligatoire)
◆ Procédure documentée :
– Step-by-step restauration (screenshots, commandes CLI, temps estimé)
– Contacts constructeurs support (hotline, numéros contrat)
– Validation tests : responsable production signe autorisation reprise
✅ Mode dégradé (continuité partielle) :
◆ Pilotage manuel si IHM down :
– Pupitre local, sélecteurs (mode manuel/auto)
– Procédure papier conduite manuelle (affichée atelier, plastifiée)
– Formation opérateurs : exercices mode dégradé trimestriels
◆ Production ralentie si MES down :
– OF (Ordres Fabrication) papier, traçabilité manuelle
– Saisie données a posteriori (réconciliation après restauration MES)
◆ Accepter arrêt temporaire :
– Mieux arrêter proprement que forcer production (risque qualité, sécurité)
– Communication clients : transparence retards, plan rattrapage
✅ Stock stratégique pièces (gestion obsolescence) :
◆ Modules automates critiques :
– CPU obsolètes (S7-300, Quantum, vieux CompactLogix) : stock 1-2 unités
– Modules I/O spécifiques (analogiques, communication) : 1 spare minimum
Prix 500-5000€/module selon rareté
◆ Pas besoin stock exhaustif :
– Modules standards (TOR, Ethernet) : disponibles constructeur (<1 semaine lead time)
– Focus équipements longs délais (>1 mois) ou obsolètes (EoL End of Life)
✅ Continuité sans sur-engineering (réalisme brownfield) :
◆ Ne pas virtualiser automates : n’a pas de sens (matériel dédié temps réel)
◆ Ne pas cluster serveurs SCADA si ligne non-critique : coût excessif (15-50k€) vs bénéfice
◆ Accepter cold standby + restauration rapide : SL2 standard acceptable (4-8h RTO)
◆ Haute disponibilité (HA) uniquement si justifiée :
– CA >100k€/h perdu
– Pénalités contractuelles clients (>50k€/jour retard)
– Réputation critique (livraison machines stratégiques défense, médical)
Livrables Attendues - Constructeur Manufacturier
🟩 Livrables conformité NIS2 (site production) :
1. ➡️ Architecture réseau zones/conduits :
◆ Schémas Visio/Lucidchart détaillés (niveaux 0-4, Purdue Model adapté manufacturing)
◆ Focus protection PLM/CAO (zone critique IP)
◆ Inventaire équipements : automates, serveurs, switchs, firewall (marque, modèle, version, IP)
◆ Matrice flux réseau : source, destination, protocole, port, justification business
◆ Points mesure SL (frontières zones, évaluation SL-T vs SL-A)
2. ➡️ Analyse de risque cyber (IEC 62443-3-2 ou ISO 27005) :
◆ Identification actifs critiques : PLM/CAO (IP), production (CA), bancs test (contamination)
◆ Analyse menaces : espionnage industriel (APT10, Turla), ransomware (REvil, LockBit), sabotage interne
◆ Évaluation vulnérabilités : CVE équipements, architecture, legacy, facteur humain
◆ Définition SL cible : PLM SL2, Production SL1-2, Bancs test SL2
◆ Gap analysis : SL actuel vs cible, mesures compensatoires brownfield
◆ Plan traitement risques : roadmap 3-5 ans, budget (firewall IT/OT priorité, puis VLAN, IDS, formation)
3. ➡️ Politique de sécurité OT simplifiée :
◆ Périmètre : site production + machines vendues (double casquette CRA)
◆ Règles :
– Accès automates : comptes nominatifs, MFA stations engineering, validation modifs
– Segmentation réseau : VLAN production, firewall IT/OT, isolation bancs test
– Protection IP : chiffrement PLM, DLP, contrôle clés USB, sauvegarde offline
– Machines vendues : secure by design, tests sécu, SBOM, support 5 ans
◆ Responsabilités : RSSI (stratégie), admin réseau (opérations), BE (développement sécurisé), production (procédures)
4. ➡️ Procédures gestion incidents :
◆ Ransomware : détection (EDR, IDS), confinement (isolation réseau), éradication (restauration backups)
◆ Vol IP : détection (DLP, logs accès PLM), investigation (forensic), notification (direction, clients si machines compromises)
◆ Sabotage production : détection (IDS, monitoring process), analyse (cyber ou process), récupération (restauration, tests)
◆ Incident machines vendues : notification CERT-FR (<24h si critique), développement patch, notification clients
5. ➡️ Plan de continuité activité (PCA production + PLM) :
◆ Fonctions essentielles : production machines critiques (CA >50%), ◆ Bureau d’Études (développement nouveaux produits)
◆ RTO/RPO : Production SL2 <4h/7j, PLM <8h/4h
◆ Procédures reprise : restauration automates (scripts), serveurs (Veeam), PLM (backup triple)
◆ Moyens secours : spare parts automates, sites backup (cloud PLM si acceptable), modes dégradés (manuel)
◆ Tests PCA annuels : exercices restauration, mesure RTO/RPO réels, REX améliorations
6. ➡️ Tableaux de bord conformité :
◆ KPI cybersécurité : incidents (nombre, criticité, temps résolution), vulnérabilités (CVE ouverts, délai patch), formations (% équipes formées)
◆ Indicateurs production : disponibilité lignes (uptime %), arrêts cyber (heures perdues/an), impact CA
◆ Suivi actions : audits (dates, constats, actions correctives), projets cyber (firewall, IDS, roadmap)
◆ Reporting direction mensuel : synthèse 1 page (faits marquants, décisions nécessaires, budget)
7. ➡️ Checklist conformité NIS2 Entité Importante :
◆ Gouvernance : RSSI nommé ✓, politique sécurité validée ✓, budget alloué ✓
◆ Gestion risques : analyse formelle ✓, plan traitement ✓, revue annuelle ✓
◆ Incident reporting : procédure CERT-FR ✓, tests notification ✓
◆ Supply chain : évaluation fournisseurs ✓, clauses cyber contrats ✓
◆ Formation : sensibilisation générale ✓, formation BE cybersécurité ✓
◆ PCA : procédures documentées ✓, tests annuels ✓
◆ Audits : auto-évaluation annuelle ✓, audit externe si budget (recommandé)
🟩 Livrables conformité CRA (machines vendues) :
1. ➡️ Secure Development Lifecycle (SDL) documenté :
◆ Processus formalisé développement machines sécurisées
◆ Phases : Conception (threat modeling) → Développement (secure coding) → Tests (pentest) → Livraison (doc cyber) → Support (PSIRT)
◆ Templates réutilisables : checklist threat modeling, guidelines secure coding, procédure tests sécu
◆ Formation équipes : programme 5-10 jours/ingénieur BE, recyclage annuel
2. ➡️ Threat model type (modèle menaces réutilisable) :
◆ STRIDE appliqué machine standard :
Spoofing : usurpation opérateur (MFA HMI recommandée)
Tampering : modification recettes (validation changements, logs)
Repudiation : non-traçabilité actions (logging événements obligatoire)
Information Disclosure : fuite recettes propriétaires (chiffrement, contrôle accès)
Denial of Service : crash automate (validation entrées, watchdog)
Elevation of Privilege : opérateur accède admin (RBAC strict)
◆ Mitigation par défaut : mesures sécurité intégrées baseline machines
◆ Adaptation : threat model spécifique machines complexes/critiques (secteur défense, médical)
3. ➡️ Baseline sécurité (checklist durcissement automates machines) :
◆ Configuration sécurisée :
Mots de passe uniques (pas admin/admin), politique complexité
Services inutiles désactivés (Telnet, FTP, HTTP)
Secure boot activé (si supporté)
Logging événements activé (accès, modifications)
◆ Tests pré-livraison :
Scan vulnérabilités (Nmap + NSE scripts ICS)
Pentest léger (tests manuels passwords, services, injections)
Validation conformité CRA (checklist 20-30 points)
◆ Procédure : vérification systématique avant expédition (responsable qualité + cyber)
4. ➡️ Templates documentation (notice cyber, SBOM, déclaration conformité) :
◆ Notice cybersécurité machine (PDF 5-15 pages) :
Section 1 : Présentation machine (modèle, composants cyber : automate, IHM, réseau)
Section 2 : Bonnes pratiques exploitation (isolation réseau, mots de passe, sauvegarde programmes)
Section 3 : Architecture réseau recommandée (VLAN, firewall, pas d’internet direct)
Section 4 : Procédure mise à jour firmware (téléchargement portail, vérification SHA-256, installation)
Section 5 : Contact PSIRT (email, téléphone, horaires, SLA)
Section 6 : Vulnérabilités connues à date livraison (tableau CVE si applicables, sinon « Aucune »)
◆ SBOM (Software Bill of Materials, JSON/XML CycloneDX ou SPDX) :
Automate : marque, modèle, version firmware (ex : Siemens S7-1515-2 PN, firmware V2.9.3)
IHM : PC industriel, OS (Windows 10 IoT LTSC 2021), logiciels (WinCC Runtime Advanced V18)
Bibliothèques : si applicables (OpenSSL 1.1.1, Modbus library 3.1.7)
Mise à jour : SBOM révisé si modification logicielle machine
◆ Déclaration conformité CRA (PDF 1-2 pages) :
Fabricant : nom, adresse, SIRET
Machine : modèle, numéro série, date fabrication
Conformité : « Cette machine est conforme au règlement CRA (UE) 2024/XXX »
Signature : responsable qualité + date
Annexe : SBOM, notice cybersécurité
5. ➡️ Procédure PSIRT (gestion vulnérabilités produits vendus) :
◆ Organisation : équipe 2-5 ETP (responsable, ingénieurs sécu, support)
◆ Processus :
1 – Veille CVE quotidienne (CISA, NVD, constructeurs)
2 – Matching CVE ↔ composants machines (SBOM)
3 – Analyse criticité (CVSS, exploitation active ?)
4 – Décision : patch urgent / workaround / risque acceptable
5 – Notification clients (<24h si critique, <7j sinon)
6 – Développement patch (1-14j selon criticité)
7 – Distribution portail client (HTTPS, signature SHA-256)
8 – Support installation (hotline, documentation)
◆ SLA : réponse <24h, patch <14j (CRA), support 5 ans minimum
Outils : CRM (base clients), VulnDB (agrégation CVE), portail web (distribution patches)
6. ➡️ Contrats fournisseurs (clauses cybersécurité CRA) :
◆ Fournisseurs automates (Siemens, Rockwell, Schneider) :
Conformité CRA composants (obligatoire post-déc. 2027)
Support 5 ans (patches sécurité gratuits)
Notification vulnérabilités <24h
SBOM fourni avec automate
Clause pénalités si non-conformité (retard livraison, non-conformité découverte)
◆ Fournisseurs composants (PC industriels, IHM, capteurs) :
Absence malware certifiée (scan antivirus constructeur)
Support firmware 5 ans
Traçabilité origine (pas de contrefaçon chinoise non certifiée)
◆ Prestataires sous-traitance (développement programmes automates) :
NDA (confidentialité code)
Respect secure coding guidelines (formation préalable)
Revue code obligatoire avant intégration
Garantie absence backdoors (clause contractuelle + audit possible)
7. ➡️ Plan de formation cyber BE :
◆ Programme :
Sensibilisation générale (2h e-learning) : phishing, mots de passe, ingénierie sociale
Secure by Design (2 jours) : threat modeling STRIDE, architecture sécurisée
IEC 62443-4-1 (3 jours certifiant) : développement sécurisé automates
Secure coding (2 jours pratique) : TIA Portal, Studio 5000, Control Expert
CRA conformité (1 jour) : obligations, documentation SBOM, tests
◆ Public : ingénieurs BE (10-15 personnes), techniciens programmation (5-10)
◆ Fréquence : initiale (onboarding nouveaux), recyclage annuel (1 jour actualisation)
8. ➡️ Registre conformité (traçabilité machines vendues CRA) :
◆ Base de données machines (Excel structuré ou CRM) :
Numéro série, modèle, client, date livraison
Version firmware/logiciel automate
SBOM lié (fichier JSON/XML)
Vulnérabilités connues (CVE applicables)
Patches appliqués (historique mises à jour)
Fin support (date livraison + 5 ans)
◆ Mise à jour : livraison (création fiche), retour client upgrade (mise à jour version), fin support (archivage)
◆ Audit : vérification annuelle cohérence (échantillon machines, validation conformité)
Cybersécurité - Législation Européenne
La cybersécurité regroupe l’ensemble des mesures destinées à protéger les systèmes informatiques, les réseaux et les données contre les vols, les dommages, les divulgations d’informations et les perturbations de services.
Dans l’Union européenne, la cybersécurité est une priorité stratégique, avec d’importants investissements en recherche, innovation, infrastructures et cyberdéfense. Depuis 2004, l’Agence de l’Union européenne pour la cybersécurité (ENISA), renforcée par la loi européenne sur la cybersécurité de 2019, soutient les États membres en fournissant conseils, solutions et coordination face aux cyberincidents majeurs.
La nouvelle stratégie européenne depuis 2020 vise à renforcer la résilience collective face aux cybermenaces et à garantir des services numériques sûrs pour tous. Elle s’articule autour de trois axes principaux :
Renforcer la résilience et la souveraineté technologique : révision des règles de sécurité des réseaux et adoption d’une nouvelle directive pour assurer un niveau élevé et commun de cybersécurité, notamment pour les infrastructures critiques publiques et privées.
Améliorer les capacités de prévention, de dissuasion et de réaction : création d’une unité conjointe de cybersécurité et renforcement des outils diplomatiques pour lutter contre les cyberattaques.
Promouvoir un cyberespace ouvert et mondial : coopération internationale accrue pour défendre un ordre numérique fondé sur des règles, protéger les droits fondamentaux en ligne et renforcer les capacités cyber des pays partenaires.
En résumé, l’UE cherche à renforcer sa sécurité numérique, sa capacité de réaction et son rôle international dans le domaine de la cybersécurité.