Pentest SCADA/ICS : Sécurité des Systèmes Industriels

Les systèmes SCADA (Supervisory Control and Data Acquisition) et ICS (Industrial Control Systems) constituent l'épine dorsale des infrastructures critiques mondiales : centrales électriques, réseaux de distribution d'eau, pipelines de gaz naturel, usines chimiques et lignes de production manufacturière. Pendant des décennies, ces systèmes ont fonctionné en vase clos, isolés des réseaux d'entreprise et d'Internet, ce qui a conduit leurs concepteurs à négliger la sécurité informatique au profit de la disponibilité et de la sûreté fonctionnelle. L'avènement de l'Industrie 4.0, la convergence IT/OT et la numérisation accélérée des environnements industriels ont radicalement changé la donne : aujourd'hui, les automates programmables industriels (PLC) communiquent via des protocoles standardisés, les IHM (Interfaces Homme-Machine) tournent sous Windows, et les données de production remontent en temps réel vers des systèmes ERP connectés à Internet. Cette évolution expose des systèmes conçus sans modèle de menace informatique à des adversaires de plus en plus sophistiqués, comme l'ont démontré Stuxnet en 2010, l'attaque sur le réseau électrique ukrainien en 2015-2016, TRITON/TRISIS ciblant les systèmes de sécurité instrumentée Schneider en 2017, et plus récemment les ransomwares frappant Colonial Pipeline en 2021. Ce guide technique détaille la méthodologie complète d'un pentest SCADA/ICS professionnel, des protocoles industriels aux outils d'évaluation, en passant par le cadre réglementaire IEC 62443 et les bonnes pratiques de remédiation.

1. Comprendre l'architecture des systèmes industriels

Avant d'aborder les techniques d'évaluation, il est impératif de maîtriser l'architecture typique d'un système ICS. Cette compréhension permet d'identifier les vecteurs d'attaque pertinents et d'éviter toute interruption non souhaitée.

2. Le modèle Purdue : hiérarchie des niveaux ICS

Le modèle de référence Purdue (Purdue Reference Model), également connu sous le nom de modèle ISA-95 ou PERA (Purdue Enterprise Reference Architecture), définit une hiérarchie en cinq niveaux pour les environnements industriels :

• Niveau 0 — Processus physique : capteurs, actionneurs, vannes, moteurs. C'est l'interface avec le monde physique.
• Niveau 1 — Contrôle de base : PLC (Programmable Logic Controllers), RTU (Remote Terminal Units), DCS (Distributed Control Systems). Ces équipements exécutent la logique de contrôle en temps réel.
• Niveau 2 — Supervision : HMI (Human-Machine Interfaces), SCADA servers, ingénierie stations. Les opérateurs supervisent et commandent depuis ce niveau.
• Niveau 3 — Opérations de site : historiens de données (OSIsoft PI, AspenTech), serveurs MES (Manufacturing Execution Systems), gestion des alarmes.
• Niveau 4 — Logistique d'entreprise : ERP (SAP, Oracle), systèmes de planification, accès Internet.

Entre les niveaux 3 et 4 se trouve la DMZ industrielle (IDMZ), zone tampon critique qui doit filtrer tous les flux entre l'OT et l'IT. Son absence ou sa mauvaise configuration est l'une des failles les plus fréquemment observées lors des audits.

3. Protocoles industriels : Modbus/TCP en détail

Modbus est le protocole industriel le plus répandu au monde, développé par Modicon en 1979. Sa simplicité et son universalité en font encore aujourd'hui la lingua franca des communications PLC. Modbus/TCP encapsule les trames Modbus RTU dans des paquets TCP/IP sur le port 502.

Structure d'une requête Modbus/TCP :

Transaction ID (2 bytes) | Protocol ID (2 bytes, toujours 0x0000)
Length (2 bytes)         | Unit ID (1 byte)
Function Code (1 byte)   | Data (variable)

Exemple de lecture de registres holding (FC=0x03) :
00 01 00 00 00 06 01 03 00 00 00 0A

Décodage :
- Transaction ID: 0x0001
- Protocol ID: 0x0000 (Modbus)
- Length: 0x0006 (6 bytes suivants)
- Unit ID: 0x01 (esclave 1)
- Function Code: 0x03 (Read Holding Registers)
- Start Address: 0x0000 (registre 0)
- Quantity: 0x000A (10 registres)

Absence totale d'authentification : n'importe quel équipement sur le réseau peut envoyer une commande Modbus à un PLC. Les function codes critiques à surveiller lors d'un pentest :

FC 01 - Read Coils (lecture sorties digitales)
FC 02 - Read Discrete Inputs (lecture entrées digitales)
FC 03 - Read Holding Registers (lecture registres de configuration)
FC 04 - Read Input Registers (lecture valeurs de mesure)
FC 05 - Write Single Coil (écriture sortie digitale — CRITIQUE)
FC 06 - Write Single Register (écriture registre — CRITIQUE)
FC 15 - Write Multiple Coils (écriture multiple — TRÈS CRITIQUE)
FC 16 - Write Multiple Registers (écriture multiple — TRÈS CRITIQUE)
FC 43 - Read Device Identification (fingerprinting)

Outil d'exploration Modbus avec Python (pymodbus) :

from pymodbus.client import ModbusTcpClient
from pymodbus.exceptions import ModbusException
import struct

def modbus_recon(host, port=502, unit_id=1):
    """Reconnaissance passive Modbus — lecture seule."""
    client = ModbusTcpClient(host, port=port, timeout=3)

    if not client.connect():
        print(f"[-] Connexion échouée vers {host}:{port}")
        return

    print(f"[+] Connecté à {host}:{port}")

    # Lecture device identification (FC 43/14)
    try:
        response = client.read_device_information(read_code=0x01, unit=unit_id)
        if not response.isError():
            print(f"[+] Vendor: {response.information.get(0, b'').decode('utf-8', errors='ignore')}")
            print(f"[+] Product: {response.information.get(1, b'').decode('utf-8', errors='ignore')}")
            print(f"[+] Version: {response.information.get(2, b'').decode('utf-8', errors='ignore')}")
    except Exception as e:
        print(f"[!] FC43 non supporté: {e}")

    # Lecture holding registers (FC 03) — plage 0-99
    try:
        result = client.read_holding_registers(address=0, count=100, unit=unit_id)
        if not result.isError():
            print(f"[+] Holding Registers [0-99]: {result.registers}")
            # Analyser les valeurs pour identifier des setpoints
            for i, val in enumerate(result.registers):
                if val != 0:
                    print(f"    Register {i}: {val} (0x{val:04X})")
    except ModbusException as e:
        print(f"[-] Erreur lecture registers: {e}")

    # Enumération des Unit IDs (1-255)
    print("\n[*] Enumération des Unit IDs...")
    for uid in range(1, 256):
        try:
            r = client.read_coils(address=0, count=1, unit=uid)
            if not r.isError():
                print(f"[+] Unit ID {uid} répond")
        except:
            pass

    client.close()

if __name__ == "__main__":
    modbus_recon("192.168.1.100")

4. Protocole DNP3 : analyse et vulnérabilités

DNP3 (Distributed Network Protocol 3) est le protocole dominant dans les secteurs électrique et hydraulique nord-américains. Standardisé par l'IEEE 1815, il est plus sophistiqué que Modbus avec des fonctionnalités de time-stamping, de reporting par exception et d'authentification optionnelle (SA — Secure Authentication v5).

Vulnérabilités connues de DNP3 :

• Replay attacks : sans SA activé, les commandes peuvent être rejouées.
• Spoofing d'adresses : les adresses source ne sont pas vérifiées.
• Fuzzing : les implémentations ont historiquement de nombreux bugs parseur (ICS-CERT ICSA-14-098-03).
• DNP3 SA v2 downgrade : certains équipements acceptent un retour au mode non authentifié.

# Analyse DNP3 avec Wireshark (filtre)
dnp3

# Capture ciblée port 20000 (DNP3 standard)
tcpdump -i eth0 -w dnp3_capture.pcap tcp port 20000 or udp port 20000

# Avec Scapy pour analyse DNP3
pip install scapy
python3 -c "
from scapy.all import *
from scapy.contrib.dnp3 import *

# Lecture d'une capture
pkts = rdpcap('dnp3_capture.pcap')
for pkt in pkts:
    if pkt.haslayer(DNP3):
        print(pkt[DNP3].summary())
        pkt[DNP3].show()
"

5. OPC-UA : le protocole moderne et ses risques

OPC-UA (Open Platform Communications Unified Architecture) est le successeur d'OPC Classic, conçu pour pallier les lacunes de sécurité de son prédécesseur basé sur DCOM/RPC. OPC-UA intègre nativement le chiffrement (TLS), l'authentification par certificats et des mécanismes d'autorisation. Cependant, sa complexité engendre ses propres vulnérabilités.

Points d'attaque OPC-UA :

# Enumération OPC-UA avec opcua-client-gui ou python-opcua
pip3 install opcua

python3 << 'EOF'
from opcua import Client
from opcua.ua import uaerrors
import logging

# Désactiver les logs verbeux
logging.basicConfig(level=logging.ERROR)

def opcua_enum(endpoint):
    """Enumération des noeuds OPC-UA sans authentification."""
    client = Client(endpoint)

    # Test connexion anonyme (fréquemment mal configuré)
    try:
        client.connect()
        print(f"[CRITIQUE] Connexion anonyme acceptée sur {endpoint}")

        # Parcourir l'arbre de noeuds
        root = client.get_root_node()
        objects = client.get_objects_node()

        print("\n[*] Noeuds Objects:")
        for child in objects.get_children():
            print(f"  - {child.get_browse_name()}: {child.get_node_id()}")
            try:
                for subchild in child.get_children():
                    print(f"    - {subchild.get_browse_name()}: {subchild.get_value()}")
            except:
                pass

        client.disconnect()
    except Exception as e:
        print(f"[-] Connexion anonyme refusée: {e}")

    # Test security modes
    for security_mode in ["None", "Sign", "SignAndEncrypt"]:
        print(f"[*] Test security mode: {security_mode}")

# Endpoints courants OPC-UA
endpoints = [
    "opc.tcp://192.168.1.100:4840",
    "opc.tcp://192.168.1.100:4843",
    "opc.tcp://192.168.1.101:49320",  # Kepware
]

for ep in endpoints:
    opcua_enum(ep)
EOF

Vulnérabilités OPC-UA documentées par l'ICS-CERT :

• CVE-2023-27321 : Stack overflow dans l'implémentation OPC Foundation .NET (CVSS 7.5)
• CVE-2022-29862 : Infinite loop DoS dans OPC UA .NET Standard
• CVE-2021-40142 : Use-after-free dans certaines implémentations C++
• Validation insuffisante des certificats (self-signed acceptés silencieusement)
• Trust lists mal configurées permettant l'acceptation de certificats non autorisés

6. Méthodologie de pentest ICS : approche passive d'abord

La règle d'or du pentest industriel est de commencer par une phase de reconnaissance strictement passive. Contrairement aux environnements IT, un seul paquet malformé peut déclencher un arrêt d'urgence (E-Stop), bloquer une ligne de production ou, dans le pire des cas, créer une situation dangereuse pour les opérateurs et l'environnement.

7. Reconnaissance passive avec Wireshark pour ICS

Wireshark dispose de dissecteurs natifs pour la plupart des protocoles industriels. Configuration optimale pour un environnement ICS :

# Installation des dissecteurs ICS supplémentaires
# Wireshark 4.x inclut nativement: Modbus, DNP3, EtherNet/IP, PROFINET, IEC 104

# Filtres Wireshark essentiels pour ICS
# Modbus/TCP
modbus
tcp.port == 502

# DNP3
dnp3
tcp.port == 20000

# EtherNet/IP (Rockwell/Allen-Bradley)
enip
tcp.port == 44818 or udp.port == 2222

# PROFINET (Siemens)
pn_dcp or pn_rt
eth.type == 0x8892

# IEC 60870-5-104 (SCADA électrique)
iec104
tcp.port == 2404

# OPC-UA
opcua
tcp.port == 4840

# Afficher uniquement les commandes d'écriture Modbus
modbus.func_code == 5 or modbus.func_code == 6 or modbus.func_code == 15 or modbus.func_code == 16

Script d'analyse automatique des captures ICS :

#!/usr/bin/env python3
"""
ICS Traffic Analyzer — Analyse passive de captures réseau industrielles
Usage: python3 ics_analyzer.py -f capture.pcap
"""

import argparse
from scapy.all import rdpcap, TCP, UDP, Raw
from collections import defaultdict
import struct

class ICSAnalyzer:
    def __init__(self, pcap_file):
        self.packets = rdpcap(pcap_file)
        self.modbus_hosts = defaultdict(set)
        self.write_commands = []
        self.device_fingerprints = {}

    def analyze_modbus(self):
        """Analyse du trafic Modbus/TCP (port 502)."""
        for pkt in self.packets:
            if TCP in pkt and (pkt[TCP].dport == 502 or pkt[TCP].sport == 502):
                if Raw in pkt:
                    data = bytes(pkt[Raw])
                    if len(data) >= 8:
                        func_code = data[7]
                        src_ip = pkt.src if hasattr(pkt, 'src') else "?"
                        dst_ip = pkt.dst if hasattr(pkt, 'dst') else "?"

                        self.modbus_hosts[dst_ip].add(src_ip)

                        # Détecter les commandes d'écriture
                        WRITE_CODES = {5: "Write Coil", 6: "Write Register",
                                      15: "Write Multiple Coils", 16: "Write Multiple Registers",
                                      22: "Mask Write Register", 23: "Read/Write Multiple"}

                        if func_code in WRITE_CODES:
                            self.write_commands.append({
                                'src': src_ip,
                                'dst': dst_ip,
                                'func': WRITE_CODES[func_code],
                                'data': data[8:].hex()
                            })
                            print(f"[!] ÉCRITURE DÉTECTÉE: {src_ip} -> {dst_ip} | {WRITE_CODES[func_code]} | {data[8:].hex()}")

    def report(self):
        """Génère un rapport de la session."""
        print("\n" + "="*60)
        print("RAPPORT D'ANALYSE ICS")
        print("="*60)
        print(f"\nHôtes Modbus détectés: {len(self.modbus_hosts)}")
        for host, clients in self.modbus_hosts.items():
            print(f"  PLC/RTU: {host} — Clients: {', '.join(clients)}")

        print(f"\nCommandes d'écriture interceptées: {len(self.write_commands)}")
        for cmd in self.write_commands:
            print(f"  {cmd['src']} -> {cmd['dst']}: {cmd['func']} ({cmd['data']})")

if __name__ == "__main__":
    parser = argparse.ArgumentParser()
    parser.add_argument('-f', '--file', required=True)
    args = parser.parse_args()

    analyzer = ICSAnalyzer(args.file)
    analyzer.analyze_modbus()
    analyzer.report()

8. Outils de scanning ICS : Nmap et Shodan

Le scanning actif doit être effectué avec la plus grande prudence. Plusieurs PLCs et RTUs sont connus pour crasher ou entrer en état d'erreur lors d'un scan de ports agressif.

# Nmap — scripts NSE pour ICS (toujours tester hors prod d'abord)
# Scanner doux avec timing T2 (paranoïaque)
nmap -sS -sV -T2 --open -p 102,502,4840,20000,44818,2404,47808 \
  --script=modbus-discover, s7-info, enip-info, dnp3-info \
  192.168.100.0/24

# Script NSE modbus-discover : énumération Unit IDs
nmap -p 502 --script modbus-discover --script-args='modbus-discover.aggressive=true' \
  192.168.100.50

# Script s7-info pour automates Siemens S7 (port 102 — S7comm)
nmap -p 102 --script s7-info 192.168.100.50

# Résultat typique s7-info :
# PORT    STATE SERVICE
# 102/tcp open  iso-tsap
# | s7-info:
# |   Module: 6ES7 315-2EH14-0AB0
# |   Basic Hardware: 6ES7 315-2EH14-0AB0
# |   Version: 3.3.9
# |   System Name: SIMATIC 300(1)
# |_  Serial Number: S C-J7Y70482

Recherche Shodan pour équipements ICS exposés :

# CLI Shodan pour recherche d'équipements ICS
pip3 install shodan
shodan init YOUR_API_KEY

# Recherche d'automates Siemens S7 exposés
shodan search "Siemens S7" --fields ip_str, port, org, country_code

# Modbus exposés sur Internet
shodan search "port:502 modbus" --fields ip_str, port, org

# OPC-UA exposés
shodan search "port:4840 opcua" --fields ip_str, port, org, product

# Rockwell/Allen-Bradley EtherNet/IP
shodan search "port:44818 product:\"EtherNet/IP\"" --fields ip_str, port, product, org

# Recherche par géographie (France)
shodan search "port:502 country:FR" --fields ip_str, city, org

9. Exploitation des PLC : techniques et risques

L'exploitation des automates programmables industriels (PLC — Programmable Logic Controller) représente le risque le plus grave dans un environnement ICS. Un PLC compromis peut entraîner des dommages physiques réels. Cette section est présentée à des fins éducatives et de défense uniquement.

10. Attaques sur automates Siemens S7

Le protocole S7comm (port 102) est propriétaire mais a été entièrement rétro-ingénié. Stuxnet l'exploitait pour manipuler les centrifugeuses d'enrichissement d'uranium iraniennes.

#!/usr/bin/env python3
"""
S7 PLC Reconnaissance avec python-snap7
Lecture seule — à des fins d'audit uniquement
"""
import snap7
from snap7.util import *
from snap7.types import *

def s7_audit(ip, rack=0, slot=2):
    """
    Audit passif d'un automate Siemens S7.
    rack=0, slot=2 pour S7-300/400
    rack=0, slot=1 pour S7-1200/1500
    """
    client = snap7.client.Client()

    try:
        client.connect(ip, rack, slot)
        print(f"[+] Connecté à {ip} (Rack:{rack}, Slot:{slot})")

        # Informations CPU
        cpu_info = client.get_cpu_info()
        print(f"[+] Module type: {cpu_info.ModuleTypeName.decode()}")
        print(f"[+] Serial: {cpu_info.SerialNumber.decode()}")
        print(f"[+] Order code: {cpu_info.OrderCode.decode()}")

        # État CPU
        cpu_state = client.get_cpu_state()
        states = {0x00: "UNKNOWN", 0x04: "STOP", 0x08: "RUN"}
        print(f"[+] État CPU: {states.get(cpu_state, 'AUTRE')}")

        # Liste des blocs de données disponibles
        print("\n[*] Blocs de données (DB):")
        blocks = client.list_blocks()
        print(f"    OBs: {blocks.OBCount}, FCs: {blocks.FCCount}, FBs: {blocks.FBCount}, DBs: {blocks.DBCount}")

        # Lecture DB1 (souvent le bloc de données principal)
        try:
            db1_size = 100  # Lire les 100 premiers bytes
            db1_data = client.db_read(1, 0, db1_size)
            print(f"\n[+] DB1[0:100] hex: {db1_data.hex()}")
        except Exception as e:
            print(f"[-] Impossible de lire DB1: {e}")

        # Lecture inputs (I) — état physique des capteurs
        try:
            inputs = client.read_area(Areas.PE, 0, 0, 4)  # 4 bytes = 32 entrées
            print(f"[+] Entrées digitales I0.0-I3.7: {inputs.hex()}")
        except Exception as e:
            print(f"[-] Impossible de lire les entrées: {e}")

    except Exception as e:
        print(f"[-] Erreur connexion S7: {e}")
    finally:
        client.disconnect()

s7_audit("192.168.1.100")

11. Attaques sur HMI (Interface Homme-Machine)

Les IHM modernes tournent fréquemment sous Windows 10 IoT Enterprise ou Windows Server, avec des logiciels SCADA commerciaux (Wonderware InTouch, Ignition, FactoryTalk View, WinCC). Ces postes présentent souvent une surface d'attaque IT classique, enrichie de permissions OT.

# Enumération des services courants sur une HMI Windows
nmap -sV -p 80,443,445,1433,4840,4843,9001,9998,57412 192.168.100.10

# Services typiques sur une HMI :
# 80/443  — Interface web SCADA (Ignition, FactoryTalk)
# 445     — SMB (partages de configuration)
# 1433    — SQL Server (historien de données)
# 4840    — OPC-UA
# 9001    — Ignition Gateway
# 57412   — Siemens WinCC OA

# Test d'authentification faible sur Ignition Gateway
curl -s http://192.168.100.10:8088/system/gwinfo | python3 -m json.tool
# Révèle version, modules installés, connexions configurées

# Ignition utilise souvent des credentials par défaut
# admin/admin ou admin/password
curl -s -X POST http://192.168.100.10:8088/system/gateway \
  -d 'j_username=admin&j_password=admin'

Vecteurs d'attaque spécifiques aux HMI :

• Script injection dans les graphiques SCADA : certaines versions de WinCC permettent l'injection de VBScript via les propriétés d'objets graphiques
• Fichiers de projet non chiffrés : les projets Wonderware (.aapkg), FactoryTalk (.fta) peuvent contenir des credentials en clair
• Kiosque mode bypass : les HMI en mode kiosque sont souvent contournables via des combinaisons clavier (Sticky Keys, etc.)
• USB autorun : nombreuses HMI avec politiques USB permissives (vecteur de Stuxnet)

12. Environnement de laboratoire GRFICSv2

GRFICSv2 (Graphical Realism Framework for Industrial Control Simulations) est un environnement de simulation ICS open-source permettant de pratiquer les techniques de pentest sans risque. Il simule une usine chimique de production de chlore avec des PLCs virtuels, un SCADA HMI et des processus physiques réalistes.

# Installation de GRFICSv2 avec Docker
git clone https://github.com/Fortiphyd/GRFICSv2.git
cd GRFICSv2

# Architecture des containers
# - chemical_plant : simulation Python du processus physique
# - plc1, plc2, plc3 : OpenPLC (Modbus/TCP)
# - hmi : ScadaBR (interface SCADA web)
# - historian : OSIsoft PI simulé

docker-compose up -d

# Vérification des services
docker-compose ps
docker exec -it plc1 bash

# Accès HMI ScadaBR
# http://localhost:8080/ScadaBR
# Credentials par défaut: admin/admin

# Test Modbus sur PLC1 (192.168.95.2 dans le réseau Docker)
python3 -c "
from pymodbus.client import ModbusTcpClient
c = ModbusTcpClient('127.0.0.1', port=502)
c.connect()
r = c.read_holding_registers(0, 10, unit=1)
print('Registres:', r.registers)
c.close()
"

# Simulation d'attaque : modification du setpoint de pression
python3 -c "
from pymodbus.client import ModbusTcpClient
c = ModbusTcpClient('127.0.0.1', port=502)
c.connect()
# ATTENTION: simulation uniquement — NE JAMAIS faire en production
# Écriture du setpoint de pression (registre 1) à une valeur dangereuse
# c.write_register(1, 9999, unit=1)
print('[SIMULATION] Modification setpoint — NE PAS exécuter en prod')
c.close()
"

13. Schneider Electric : vulnérabilités et outils d'audit

Schneider Electric est l'un des leaders mondiaux des systèmes d'automatisation industrielle. Ses gammes Unity Pro (M340, M580, Premium), EcoStruxure et Modicon sont déployées dans des milliers d'installations critiques mondiales. TRITON/TRISIS (2017) ciblait spécifiquement les Safety Instrumented Systems (SIS) Triconex de Schneider.

# Nmap scripts pour Schneider Modicon
nmap -p 502 --script modbus-discover 192.168.1.100
# Identifier Modicon par le vendor ID dans FC43

# Port 80/443 — Interface web Modicon M580
curl -sk https://192.168.1.100/index.htm | grep -i "schneider\|modicon\|firmware"

# Outil officiel de diagnostic : Unity Pro (propriétaire)
# Alternative open-source : ModRSsim2 pour test

# CVE notables Schneider ICS :
# CVE-2022-22723 — Buffer overflow Modicon M340 (CVSS 9.8)
# CVE-2021-22763 — Credentials hardcodés Easergy T300
# CVE-2020-7537 — Déni de service Modicon M340 via requête HTTP malformée
# CVE-2018-7789 — Modicon M221 — lecture configuration sans auth

# Test CVE-2018-7789 (lecture de config Modicon M221)
# UNIQUEMENT sur systèmes autorisés
curl -s http://192.168.1.100/prog.bin --max-time 5 | xxd | head -20

14. Rockwell Automation / Allen-Bradley : EtherNet/IP

EtherNet/IP (Ethernet Industrial Protocol) est le protocole de prédilection de Rockwell Automation pour ses gammes ControlLogix, CompactLogix et MicroLogix. Il encapsule le protocole CIP (Common Industrial Protocol) sur TCP/44818 et UDP/2222.

# Nmap EtherNet/IP enumeration
nmap -p 44818 --script enip-info 192.168.1.100

# Résultat typique :
# PORT      STATE SERVICE
# 44818/tcp open  EtherNet/IP
# | enip-info:
# |   Vendor ID: Rockwell Automation/Allen-Bradley (1)
# |   Device Type: Programmable Logic Controller (14)
# |   Product Code: 54
# |   Revision: 20.11
# |   Status: 0x0060
# |   Serial Number: 0xC0A86464
# |_  Product Name: 1756-L71 LOGIX5571

# Outil : EtherScan (open-source)
git clone https://github.com/piyushsingh1/etherscan
pip install pycomm3

python3 -c "
from pycomm3 import LogixDriver

# Connexion à un ControlLogix (lecture seule)
with LogixDriver('192.168.1.100/1,0') as plc:
    # Lire toutes les tags disponibles
    tags = plc.get_tag_list()
    print(f'Tags disponibles: {len(tags)}')
    for tag in tags[:20]:  # Afficher les 20 premières
        print(f'  {tag[\"tag_name\"]}: {tag[\"data_type\"]}')

    # Lire une tag spécifique
    result = plc.read('Program:MainProgram.Motor_Speed')
    print(f'Motor Speed: {result}')
"

15. ICS-CERT et avis de sécurité : gestion des vulnérabilités

L'ICS-CERT (Industrial Control Systems Cyber Emergency Response Team), désormais intégré à CISA (Cybersecurity and Infrastructure Security Agency), publie des avis de sécurité (advisories) pour les vulnérabilités affectant les systèmes industriels. La consultation régulière de ces avis est fondamentale pour tout programme de gestion des vulnérabilités OT.

Avis ICS-CERT critiques récents (2024-2026) :

# Récupérer automatiquement les derniers avis ICS-CERT
curl -s "https://www.cisa.gov/sites/default/files/feeds/known_exploited_vulnerabilities.json" | \
  python3 -c "
import json, sys
data = json.load(sys.stdin)
ics_vulns = [v for v in data['vulnerabilities'] if 'scada' in v.get('shortDescription','').lower()
             or 'ics' in v.get('shortDescription','').lower()
             or 'plc' in v.get('shortDescription','').lower()]
for v in ics_vulns[:10]:
    print(f\"{v['cveID']}: {v['shortDescription'][:80]}\")
"

16. Segmentation réseau : implémentation de la DMZ industrielle

La segmentation réseau est la mesure de protection la plus efficace dans un environnement ICS. Son implémentation correcte selon le modèle Purdue réduit drastiquement la surface d'attaque.

Architecture réseau recommandée (IEC 62443 / NIST SP 800-82) :

INTERNET
    |
[Pare-feu Périmètre]
    |
RÉSEAU IT (Niveau 4)
  192.168.10.0/24
  - Postes utilisateurs
  - Serveurs ERP, mail
    |
[Pare-feu + IDS/IPS — Zone de démarcation IT/OT]
    |
IDMZ — Industrial DMZ (Niveau 3.5)
  192.168.50.0/24
  - Serveur de rebond (Jump Server) — unique point d'accès OT
  - Antivirus management
  - WSUS (patches Windows isolé)
  - Historien de données (lecture seule depuis OT)
  - Serveur de temps (NTP)
    |
[Pare-feu OT — règles strictes, whitelist applicative]
    |
RÉSEAU OT SUPERVISION (Niveau 3)
  10.0.3.0/24
  - Serveur SCADA
  - Serveur historien OT
  - Station ingénierie
    |
[Switch managé avec VLAN + ACL]
    |
RÉSEAU CONTRÔLE (Niveau 2)
  10.0.2.0/24
  - HMI (Human-Machine Interfaces)
  - Serveur OPC-UA
    |
[Switch managé VLAN dédié]
    |
RÉSEAU TERRAIN (Niveau 1)
  10.0.1.0/24
  - PLC / RTU / DCS
  - Protocoles: Modbus, EtherNet/IP, PROFINET
    |
TERRAIN PHYSIQUE (Niveau 0)
  - Capteurs, actionneurs

Règles pare-feu entre niveaux Purdue :

# Règles iptables pour pare-feu OT (exemple simplifié)
# Niveaux 3 -> 2 : SCADA vers HMI

# Autoriser uniquement OPC-UA depuis serveur SCADA
iptables -A FORWARD -s 10.0.3.10 -d 10.0.2.0/24 -p tcp --dport 4840 -j ACCEPT

# Autoriser la télémétrie Modbus depuis HMI vers PLC (lecture seule — FC1-4)
# Note: filtrage au niveau protocole nécessite un pare-feu applicatif ICS
iptables -A FORWARD -s 10.0.2.0/24 -d 10.0.1.0/24 -p tcp --dport 502 -j ACCEPT

# Bloquer tout le reste entre niveaux
iptables -A FORWARD -s 10.0.3.0/24 -d 10.0.1.0/24 -j DROP

# Journaliser les tentatives de connexion directe IT->OT
iptables -A FORWARD -s 192.168.10.0/24 -d 10.0.0.0/8 -j LOG --log-prefix "IT->OT BLOQUÉ: "
iptables -A FORWARD -s 192.168.10.0/24 -d 10.0.0.0/8 -j DROP

17. Conformité IEC 62443 : cadre réglementaire

La norme IEC 62443 (anciennement ISA-99) est le cadre de référence international pour la cybersécurité des systèmes de contrôle industriels. Elle se structure en quatre séries :

Les Security Levels (SL) définissent le niveau de résistance requis :

• SL 1 : Protection contre les attaques involontaires (erreurs humaines)
• SL 2 : Protection contre les attaquants intentionnels avec peu de ressources
• SL 3 : Protection contre des attaquants sophistiqués avec ressources ICS spécifiques
• SL 4 : Protection contre des États-nations ou groupes très financés

# Checklist d'audit IEC 62443 (extraits Section 3-3)

# SR 1.1 — Identification et authentification humaine
# Test: Y a-t-il une authentification sur tous les équipements OT ?
nmap -p 502 --script modbus-discover 10.0.1.0/24  # Modbus sans auth
nmap -p 102 --script s7-info 10.0.1.0/24           # S7 sans auth

# SR 1.2 — Authentification logicielle et des processus
# Test: Les communications inter-systèmes sont-elles authentifiées ?
# OPC-UA doit utiliser des certificats, pas le mode "None"

# SR 2.1 — Séparation des rôles d'autorisation
# Test: Les comptes opérateurs peuvent-ils modifier la configuration PLC ?

# SR 3.1 — Intégrité des communications
# Test: Les protocoles supportent-ils l'intégrité (HMAC, signatures) ?

# SR 5.1 — Segmentation réseau
# Test: Les zones et conduits sont-ils correctement implémentés ?
traceroute -T -p 502 10.0.1.100  # Combien de hops depuis le réseau IT ?

# Rapport de conformité automatisé
cat > iec62443_audit.sh << 'SCRIPT'
#!/bin/bash
echo "=== AUDIT IEC 62443 ==="
echo ""
echo "[SR 1.1] Test authentification Modbus..."
nmap -p 502 --script modbus-discover --open 10.0.1.0/24 -oN modbus_open.txt 2>/dev/null
MODBUS_COUNT=$(grep -c "502/tcp open" modbus_open.txt 2>/dev/null || echo 0)
echo "  PLCs Modbus sans auth détectés: $MODBUS_COUNT"

echo "[SR 5.1] Test segmentation réseau..."
ping -c1 -W1 10.0.1.1 &>/dev/null && echo "  [FAIL] Réseau niveau 1 accessible directement" || echo "  [OK] Réseau niveau 1 non accessible"
SCRIPT

18. Rapport de pentest ICS : structure et contenu

Le rapport d'un pentest ICS doit impérativement distinguer les risques de sécurité des risques de sûreté (safety), et prioriser les remédiations en fonction de l'impact opérationnel.

Structure type d'un rapport de pentest ICS :

1. RÉSUMÉ EXÉCUTIF
   - Périmètre évalué (zones Purdue)
   - Fenêtre d'évaluation et contraintes
   - Score de risque global (CVSS + impact opérationnel)
   - 3-5 recommandations prioritaires

2. MÉTHODOLOGIE
   - Approche passive vs active
   - Outils utilisés et paramètres de prudence
   - Personnel sur site pendant les tests actifs
   - Protocole d'arrêt d'urgence

3. DÉCOUVERTES TECHNIQUES
   Pour chaque finding :
   - Description technique
   - Impact cybersécurité (CVSS v3.1)
   - Impact opérationnel (disponibilité, safety)
   - Preuve (screenshots, captures réseau — anonymisées)
   - Remédiation recommandée
   - Effort de remédiation (court/moyen/long terme)

4. ANALYSE DE RISQUE OT
   - Matrice de risque combinant probabilité et impact opérationnel
   - Cartographie des scénarios d'attaque (ATT&CK for ICS)
   - Points d'accès critiques identifiés

5. PLAN DE REMÉDIATION
   - Priorité 1 (< 30 jours) : vulnérabilités critiques sans impact prod
   - Priorité 2 (< 90 jours) : remédiation lors de maintenance planifiée
   - Priorité 3 (< 12 mois) : architecture et processus

19. MITRE ATT&CK for ICS : cartographie des tactiques

ATT&CK for ICS est la matrice de tactiques et techniques d'attaque spécifiques aux environnements industriels, maintenue par MITRE. Elle comprend 12 tactiques et plus de 80 techniques documentées.

20. Détection et réponse aux incidents ICS

La détection d'intrusion dans les environnements OT nécessite des outils adaptés, capables d'analyser les protocoles industriels et de détecter les anomalies de comportement sans perturber les opérations.

# Déploiement de Dragos Platform Community Edition (ou alternative open-source)
# Alternative open-source : SecurityOnion avec dissecteurs ICS

# Zeek (anciennement Bro) avec plugin ICS
# Installation du plugin modbus pour Zeek
zeek -i eth0 -C modbus_analyzer

# Règles de détection Suricata pour Modbus
cat >> /etc/suricata/rules/ics.rules << 'RULES'
# Détecter les écritures Modbus depuis des IPs non autorisées
alert tcp !10.0.2.0/24 any -> 10.0.1.0/24 502 (msg:"Modbus WRITE depuis hôte non autorisé";
  content:"|00 00|"; offset:2; depth:2;
  byte_test:1,&,0x80,7, relative;
  sid:9000001; rev:1;)

# Détecter les tentatives d'énumération Modbus (FC 43)
alert tcp any any -> any 502 (msg:"Modbus Device Identification (FC43)";
  content:"|00 2B|"; offset:6; depth:2;
  sid:9000002; rev:1;)

# Détecter le scan de Unit IDs
alert tcp any any -> any 502 (msg:"Possible Modbus Unit ID scan";
  threshold:type both, track by_src, count 50, seconds 10;
  sid:9000003; rev:1;)
RULES

# Redémarrer Suricata
systemctl restart suricata

21. Cas pratique : audit complet d'un sous-réseau ICS

#!/bin/bash
# Script d'audit ICS complet — USAGE AUTORISÉ UNIQUEMENT
# Paramètres : réseau cible, interface d'écoute

TARGET_NET="${1:-10.0.1.0/24}"
IFACE="${2:-eth0}"
OUTDIR="/tmp/ics_audit_$(date +%Y%m%d_%H%M%S)"
mkdir -p "$OUTDIR"

echo "=== AUDIT ICS ==="
echo "Cible: $TARGET_NET | Interface: $IFACE"
echo "Résultats: $OUTDIR"

# Phase 1 : Découverte passive (écoute 5 minutes)
echo "[Phase 1] Écoute passive 5 minutes..."
timeout 300 tcpdump -i "$IFACE" -w "$OUTDIR/passive_capture.pcap" \
  "tcp port 502 or tcp port 102 or tcp port 4840 or tcp port 44818 or tcp port 20000" &
TCPDUMP_PID=$!
sleep 300
kill $TCPDUMP_PID 2>/dev/null

# Phase 2 : Scan doux (T2, pas de scripts agressifs)
echo "[Phase 2] Scan de découverte (T2)..."
nmap -sn -T2 "$TARGET_NET" -oN "$OUTDIR/hosts_alive.txt"
ALIVE_HOSTS=$(grep "Nmap scan report" "$OUTDIR/hosts_alive.txt" | awk '{print $5}')

# Phase 3 : Fingerprinting des équipements ICS
echo "[Phase 3] Fingerprinting ICS..."
for host in $ALIVE_HOSTS; do
    echo "  Scan: $host"
    nmap -sV -T2 -p 80,102,443,502,4840,20000,44818 \
      --script "s7-info, modbus-discover, enip-info" \
      -oN "$OUTDIR/host_${host}.txt" "$host" 2>/dev/null
done

# Phase 4 : Analyse de la capture passive
echo "[Phase 4] Analyse de la capture passive..."
if command -v tshark &>/dev/null; then
    # Extraire les hosts Modbus
    tshark -r "$OUTDIR/passive_capture.pcap" -Y "modbus" \
      -T fields -e ip.src -e ip.dst -e modbus.func_code 2>/dev/null | \
      sort -u > "$OUTDIR/modbus_communications.txt"

    # Détecter les écritures
    tshark -r "$OUTDIR/passive_capture.pcap" \
      -Y "modbus.func_code == 5 or modbus.func_code == 6 or modbus.func_code == 15 or modbus.func_code == 16" \
      -T fields -e frame.time -e ip.src -e ip.dst -e modbus.func_code 2>/dev/null > "$OUTDIR/modbus_writes.txt"
fi

echo "[Terminé] Résultats dans $OUTDIR"
ls -la "$OUTDIR/"

FAQ — Questions fréquentes sur le pentest SCADA/ICS

Quelle est la différence entre un pentest IT classique et un pentest ICS ?

La différence fondamentale réside dans les priorités : un pentest IT accepte un impact limité sur la confidentialité pour démontrer une vulnérabilité, alors qu'un pentest ICS doit préserver en toutes circonstances la disponibilité et la sûreté du processus industriel. Les équipements OT sont souvent fragiles face aux scans intensifs, et leur indisponibilité peut avoir des conséquences physiques graves. La méthodologie ICS est donc essentiellement passive, progressive et toujours coordonnée avec les équipes opérationnelles.

Modbus peut-il être sécurisé sans remplacement complet du protocole ?

Oui, partiellement. En l'absence d'authentification native dans Modbus, les compensations de sécurité incluent : la segmentation réseau stricte (whitelisting des IPs autorisées à envoyer des commandes Modbus), des pare-feux applicatifs ICS capables d'inspecter les Function Codes et de bloquer les écritures non autorisées (produits : Tofino Security, Claroty, Dragos), et des systèmes de détection d'anomalies (Nozomi Networks, Darktrace for ICS) qui détectent les comportements inhabituels. La migration vers OPC-UA avec sécurité activée est la solution pérenne.

Comment tester la sécurité OPC-UA sans interrompre la production ?

En mode passif : capturer le trafic TCP 4840/4843 et analyser avec Wireshark (dissecteur OPC-UA intégré) pour vérifier si TLS est utilisé. En mode actif léger : utiliser le client OPC-UA officiel de l'OPC Foundation en lecture seule pour tester la connexion anonyme. Ne jamais tenter d'écriture sur des nœuds de configuration ou de contrôle en production.

Quels sont les indicateurs de compromission (IoC) spécifiques aux environnements ICS ?

Les IoC ICS spécifiques incluent : des requêtes Modbus d'écriture depuis des adresses IP inhabituelles, des connexions S7comm vers des PLCs depuis des postes qui n'ont pas de logiciel d'ingénierie installé, des transferts de programme PLC en dehors des fenêtres de maintenance, des changements de configuration IHM non planifiés, des alertes de sécurité instrumentée (SIS) inhabituelles, et des communications vers des destinations Internet depuis le réseau OT (qui devrait être totalement isolé).

IEC 62443 est-il obligatoire en France pour les opérateurs d'importance vitale ?

En France, les OIV (Opérateurs d'Importance Vitale) sont soumis à la directive NIS2 (transposée en droit français en 2024) et aux arrêtés sectoriels de l'ANSSI. L'IEC 62443 est la norme technique de référence recommandée par l'ANSSI dans ses guides sectoriels, mais elle n'est pas juridiquement imposée mot pour mot — c'est le niveau de sécurité attendu qui est règlementaire, et IEC 62443 fournit le cadre pour l'atteindre. Les secteurs eau, énergie et transport sont soumis aux exigences les plus strictes.

Comment détecter si un PLC a été compromis ?

La détection de compromission PLC est complexe car ces équipements sont souvent des boîtes noires. Les indicateurs incluent : des changements inattendus dans le code ladder/FBD du programme PLC (nécessite une comparaison avec le baseline), des modifications non autorisées des blocs de données, des comportements d'E/S incohérents avec les setpoints configurés, des connexions réseau inhabituelles dans les journaux du switch managé, et des alarmes d'intégrité si le PLC supporte la vérification de code (Siemens S7-1500 avec Protection Level 3 offre cette fonctionnalité).

Quels outils open-source recommandez-vous pour un premier audit ICS ?

Pour débuter : Wireshark avec ses dissecteurs ICS natifs pour la capture passive, Nmap avec les scripts NSE ICS (modbus-discover, s7-info, enip-info) pour la découverte, pymodbus pour les tests fonctionnels Modbus, python-snap7 pour les automates Siemens, et GRFICSv2 pour la pratique en environnement sûr. Pour la détection : Zeek avec les plugins ICS, Suricata avec les règles ICS-SNORT. Côté commercial, Claroty, Dragos et Nozomi Networks proposent des versions d'évaluation.

Quelle certification viser pour devenir expert en sécurité ICS ?

Les certifications reconnues dans le secteur OT/ICS incluent : GICSP (GIAC Global Industrial Cyber Security Professional) — la référence du secteur, CSSA (Certified SCADA Security Architect) par ISA, ICS/SCADA Security Essentials par SANS (ICS410), et Certified ICS/SCADA Professional par InfoSec Institute. Pour les environnements Siemens spécifiquement, la certification SINEMA/SINEC de Siemens complète le tableau technique. L'ANSSI propose également des formations spécialisées ICS via son programme de certification.

Pour approfondir les techniques de post-exploitation en environnement Active Directory souvent interconnecté avec les réseaux OT, consultez notre article sur le lateral movement en Active Directory. La sécurité des réseaux industriels bénéficie également d'une solide compréhension des techniques de segmentation réseau avancées. Pour les aspects cryptographiques des communications industrielles, voir notre analyse des protocoles de chiffrement TLS et leurs configurations. La gestion des vulnérabilités OT s'intègre dans une démarche plus large présentée dans notre guide sur les programmes de gestion des vulnérabilités. Enfin, pour les aspects réglementaires, notre article sur la conformité NIS2 en France complète ce panorama.

Références externes : CISA ICS Security Resources et ISA/IEC 62443 Standards Series.

22. Protocoles spécialisés : IEC 60870-5-104 et IEC 61850

IEC 60870-5-104 est le protocole TCP/IP du standard IEC 60870-5-101, largement déployé dans les réseaux de distribution électrique et les centres de conduite SCADA. Il fonctionne sur le port TCP 2404 et gère la supervision des télécommandes, télémesures et téléinformations dans les environnements SCADA électriques.

#!/usr/bin/env python3
"""
Analyse du protocole IEC 60870-5-104 avec pyiec104
Usage : audit passif et reconnaissance des unités distantes (RTU/IED)
"""
import iec104
import socket
import struct
import time

class IEC104Auditor:
    """Auditeur passif pour le protocole IEC 60870-5-104."""

    # Types de données IEC 104 courants
    TYPE_IDS = {
        1:  "M_SP_NA_1 (Single Point)",      # État ON/OFF d'un équipement
        3:  "M_DP_NA_1 (Double Point)",       # État 4 positions
        5:  "M_ST_NA_1 (Step Position)",      # Position de transformateur
        9:  "M_ME_NA_1 (Normalized Value)",   # Valeur normalisée
        11: "M_ME_NB_1 (Scaled Value)",       # Valeur mise à l'échelle
        13: "M_ME_NC_1 (Short Float)",        # Flottant 32 bits
        30: "M_SP_TB_1 (SP with time)",       # Single Point avec timestamp
        36: "M_ME_TF_1 (Float with time)",    # Flottant avec timestamp
        45: "C_SC_NA_1 (Single Command)",     # Commande — CRITIQUE
        46: "C_DC_NA_1 (Double Command)",     # Double commande — CRITIQUE
        50: "C_SE_NA_1 (Set Normalized)",     # Setpoint normalisé — CRITIQUE
        100: "C_IC_NA_1 (Interrogation)",     # Requête de lecture générale
        103: "C_CS_NA_1 (Clock Sync)",        # Synchronisation horloge
    }

    def __init__(self, host: str, port: int = 2404):
        self.host = host
        self.port = port
        self.sock = None

    def connect(self) -> bool:
        """Établit une connexion TCP vers le serveur IEC 104."""
        try:
            self.sock = socket.socket(socket.AF_INET, socket.SOCK_STREAM)
            self.sock.settimeout(10)
            self.sock.connect((self.host, self.port))

            # Envoyer STARTDT_ACT (activation de la session)
            startdt = bytes([0x68, 0x04, 0x07, 0x00, 0x00, 0x00])
            self.sock.send(startdt)

            # Lire la réponse STARTDT_CON
            response = self.sock.recv(6)
            if response[2] == 0x0B:  # STARTDT_CON
                print(f"[+] Connexion IEC 104 établie avec {self.host}:{self.port}")
                return True
        except Exception as e:
            print(f"[-] Connexion échouée : {e}")
        return False

    def send_general_interrogation(self) -> list:
        """
        Envoie une requête d'interrogation générale (C_IC_NA_1).
        Retourne tous les points de données de l'unité distante.
        NOTE: En production, ceci peut déclencher une réponse volumineuse
        """
        # ASDU pour C_IC_NA_1 (Interrogation commande)
        # COA=1, IOA=0, QOI=20 (station interrogation)
        i_frame = self._build_i_frame(
            type_id=100,   # C_IC_NA_1
            coa=1,         # Common Address of ASDU
            ioa=0,         # Information Object Address
            data=b'\x14'   # QOI=20 (global interrogation)
        )
        self.sock.send(i_frame)

        results = []
        self.sock.settimeout(5)
        try:
            while True:
                data = self.sock.recv(4096)
                if not data:
                    break
                parsed = self._parse_asdu(data)
                results.extend(parsed)
        except socket.timeout:
            pass

        return results

    def _build_i_frame(self, type_id: int, coa: int, ioa: int, data: bytes) -> bytes:
        """Construit un I-Frame IEC 104."""
        # Structure APCI + ASDU
        asdu = bytes([
            type_id,    # Type Identifier
            0x01,       # VSQ: 1 objet, SQ=0
            0x06,       # COT: Activation (6)
            0x00,       # COT high byte
            coa & 0xFF, # COA low byte
            (coa >> 8) & 0xFF,  # COA high byte
            ioa & 0xFF, # IOA byte 1
            (ioa >> 8) & 0xFF,  # IOA byte 2
            (ioa >> 16) & 0xFF, # IOA byte 3
        ]) + data

        apci_length = 4 + len(asdu)
        apci = bytes([0x68, len(asdu) + 4, 0x00, 0x00, 0x00, 0x00]) + asdu
        return apci

    def _parse_asdu(self, data: bytes) -> list:
        """Parse les ASDU reçus et retourne les points de données."""
        results = []
        if len(data) < 6:
            return results

        # Sauter l'en-tête APCI (6 bytes)
        asdu_start = 6
        if len(data) <= asdu_start:
            return results

        type_id = data[asdu_start]
        type_name = self.TYPE_IDS.get(type_id, f"Unknown({type_id})")

        # Détecter les commandes (type_id 45-64 = commandes)
        if 45 <= type_id <= 64:
            print(f"[!] COMMANDE DÉTECTÉE : {type_name} (TypeID={type_id})")
            results.append({'type': 'COMMAND', 'type_id': type_id, 'name': type_name})

        return results

    def close(self):
        if self.sock:
            # Envoyer STOPDT_ACT avant fermeture propre
            stopdt = bytes([0x68, 0x04, 0x13, 0x00, 0x00, 0x00])
            self.sock.send(stopdt)
            time.sleep(0.1)
            self.sock.close()

# Utilisation
auditor = IEC104Auditor("192.168.1.100")
if auditor.connect():
    points = auditor.send_general_interrogation()
    print(f"\n[+] Points de données reçus : {len(points)}")
    auditor.close()

IEC 61850 est le standard de communication pour les postes électriques modernes. Contrairement à IEC 60870-5-104 qui transporte des valeurs brutes, IEC 61850 utilise un modèle d'objets orienté sémantique avec des Logical Nodes et des Datasets. Sa surface d'attaque est différente :

# Outils d'audit IEC 61850
# liIEC61850 — bibliothèque open-source C pour IEC 61850
git clone https://github.com/mz-automation/libiec61850
cd libiec61850 && mkdir build && cd build && cmake .. && make

# Test de connexion MMS (Manufacturing Message Specification — port 102)
./examples/mms_client_example 192.168.1.100

# Découverte des équipements IEC 61850 sur le réseau
# GOOSE (Generic Object Oriented Substation Events) sur multicast :
tcpdump -i eth0 -n "ether proto 0x88b8"  # GOOSE Ethernet type

# Analyse des messages GOOSE (pas d'authentification dans GOOSE v1)
tshark -i eth0 -Y "goose" -T fields \
  -e goose.gocbRef \
  -e goose.sqNum \
  -e goose.timeAllowedToLive \
  -e goose.stNum

# Vulnérabilité : injection GOOSE
# Les messages GOOSE ne sont pas authentifiés dans la norme de base
# Un attaquant sur le réseau peut injecter des trames GOOSE avec des états falsifiés
# Mitigation : IEC 62351-6 (GOOSE security) — chiffrement et signature des messages

23. Sécurisation des accès distants aux environnements ICS

Les accès à distance aux environnements ICS représentent l'un des vecteurs d'intrusion les plus fréquents, comme l'a démontré l'incident de la station de traitement des eaux d'Oldsmar, Floride (2021), où un attaquant a accédé via TeamViewer pour tenter de modifier les niveaux de soude caustique.

# Bonnes pratiques pour les accès distants ICS

# 1. Jump Server (Bastion) dédié dans la IDMZ
# Le seul point d'entrée dans le réseau OT depuis l'IT ou Internet
# Configuration SSH hardened sur le bastion

cat > /etc/ssh/sshd_config.d/ics-bastion.conf << 'EOF'
# Bastion ICS — Configuration SSH ultra-restrictive
Protocol 2
Port 22022          # Port non standard

# Authentification par clé uniquement, jamais par mot de passe
PasswordAuthentication no
PubkeyAuthentication yes
AuthorizedKeysFile /etc/ssh/authorized_keys/%u

# Restriction des utilisateurs autorisés
AllowUsers ot-admin ot-engineer

# Timeout de session
ClientAliveInterval 60
ClientAliveCountMax 5
LoginGraceTime 30

# Journalisation maximale
LogLevel VERBOSE
SyslogFacility AUTHPRIV

# Désactiver les fonctionnalités inutiles
X11Forwarding no
AllowTcpForwarding no  # Sauf si nécessaire pour le tunneling spécifique
AllowStreamLocalForwarding no
GatewayPorts no
PermitTunnel no
EOF

# 2. VPN dédié OT avec MFA (Cisco AnyConnect, Palo Alto GlobalProtect)
# Séparation du VPN IT et du VPN OT — profiles distincts
# MFA obligatoire pour tout accès distant OT (TOTP, push notification)

# 3. PAM (Privileged Access Management) pour les sessions OT
# CyberArk, BeyondTrust, Teleport — enregistrement vidéo des sessions
# Tous les accès distants OT doivent être enregistrés et auditables

# 4. Inventaire et désactivation des accès distants non autorisés
# Scanner les logiciels d'accès à distance présents sur les HMIs
nmap -p 5900,5938,3389,4899,5631 10.0.2.0/24
# Port 5900 : VNC
# Port 5938 : TeamViewer
# Port 3389 : RDP
# Port 4899 : Radmin
# Port 5631 : PCAnywhee

# Tous les logiciels d'accès à distance non approuvés doivent être désinstallés
# des HMIs et PLCs qui en supportent la gestion logicielle

24. Threat Intelligence spécifique aux systèmes ICS

Les groupes APT ciblant spécifiquement les systèmes ICS sont documentés et traqués par les principaux organismes de cybersécurité. La connaissance de ces acteurs et de leurs techniques est essentielle pour une défense efficace.

# Flux STIX/TAXII pour la threat intelligence ICS
# CISA ICS Advisories en format STIX 2.1
curl -s "https://www.cisa.gov/sites/default/files/feeds/known_exploited_vulnerabilities.json" \
  | python3 -c "
import json, sys
data = json.load(sys.stdin)
ics = [v for v in data['vulnerabilities']
       if any(k in v.get('shortDescription','').lower()
              for k in ['scada','ics','plc','hmi','industrial'])]
for v in ics[:15]:
    print(f\"{v['cveID']}: {v['vendorProject']} — {v['shortDescription'][:60]}\")
"

# Abonnement aux alertes ICS-CERT (CISA)
# https://www.cisa.gov/ics (RSS Feed, email alerts, STIX)

# Dragos WorldView — Threat Intelligence ICS commerciale
# Alternative gratuite : ICS-ISAC (Information Sharing and Analysis Center)

# MITRE ATT&CK for ICS — détection des techniques
# Télécharger la matrice en JSON
curl -s "https://raw.githubusercontent.com/mitre-attack/attack-stix-data/master/ics-attack/ics-attack.json" \
  | python3 -c "
import json, sys
data = json.load(sys.stdin)
techniques = [o for o in data['objects'] if o.get('type') == 'attack-pattern']
print(f'Techniques ICS ATT&CK : {len(techniques)}')
for t in techniques[:10]:
    print(f'  {t.get(\"external_references\",[\"\"])[0].get(\"external_id\",\"\")} : {t[\"name\"]}')
"

25. Exercices de simulation d'attaque ICS (Tabletop)

Les exercices de simulation (tabletop exercises) sont une méthode éprouvée pour tester la résilience des équipes face à des incidents ICS sans risque pour la production. L'ANSSI et le NIST recommandent leur pratique annuelle pour les OIV.

Scénario d'exercice tabletop ICS — Exemple complet

TITRE : "Operation ColdPress" — Attaque sur une station de traitement d'eau

CONTEXTE INITIAL :
Heure H+0 : Le SCADA de la station de traitement d'eau de la ville affiche
une alarme de niveau de chlore anormalement élevé dans le bassin de traitement.
L'opérateur de quart constate que le setpoint a été modifié à distance.

INJECT 1 (H+0h05) :
L'investigation révèle une connexion VPN inhabituelle depuis une IP
géolocalisée aux Pays-Bas, il y a 45 minutes. L'utilisateur VPN est
"maintenance_ext" — un compte prestataire créé il y a 2 ans et supposément désactivé.

Questions pour l'équipe :
- Qui peut désactiver ce compte VPN immédiatement ?
- Comment isoler le SCADA du réseau tout en maintenant la surveillance ?
- Quelle est la procédure de notification des autorités (ANSSI, préfecture) ?
- L'opérateur doit-il passer en mode manuel ? Qui prend cette décision ?

INJECT 2 (H+0h30) :
L'analyse des logs révèle que l'attaquant a accédé au SCADA via une HMI
Windows 2012 non patchée depuis 18 mois. Il a ensuite utilisé des
credentials d'un opérateur pour se connecter au DCS.

Questions pour l'équipe :
- Quels systèmes ont potentiellement été compromis ?
- Comment effectuer une analyse forensique sans interrompre le traitement ?
- Faut-il alerter le public sur la qualité de l'eau ?
- Qui contacter chez le fournisseur du SCADA pour assistance ?

INJECT 3 (H+2h00) :
L'équipe CSIRT découvre que l'attaquant a installé un RAT
(Remote Access Trojan) sur 3 HMIs. Des traces de reconnaissance vers
d'autres systèmes OT sont visibles dans les logs réseau.

Questions pour l'équipe :
- Procédure de reconstruction des HMIs compromises
- Tests de validation avant remise en service
- Documentation pour le rapport d'incident réglementaire
- Mesures préventives immédiates pour éviter la récidive

CRITÈRES D'ÉVALUATION :
- Temps de détection initial
- Temps de containment (isolation)
- Qualité de la communication interne et externe
- Connaissance des procédures d'urgence
- Coordination IT/OT/management

26. Hardening des communications Modbus : solutions pratiques

#!/usr/bin/env python3
"""
Proxy Modbus sécurisé — Firewall applicatif pour protocole Modbus/TCP
Filtre les Function Codes non autorisés et les Unit IDs invalides
"""
import asyncio
import struct
import logging
from dataclasses import dataclass
from typing import Set, Dict

logging.basicConfig(level=logging.INFO, format='%(asctime)s %(levelname)s %(message)s')
logger = logging.getLogger("ModbusProxy")

@dataclass
class ModbusProxyPolicy:
    """Politique de filtrage Modbus."""
    allowed_unit_ids: Set[int]        # Unit IDs autorisés
    allowed_read_fcs: Set[int]        # Function Codes de lecture autorisés
    allowed_write_fcs: Set[int]       # Function Codes d'écriture autorisés
    allowed_client_ips: Set[str]      # IPs clientes autorisées
    allowed_write_addresses: Dict[int, tuple]  # {unit_id: (addr_min, addr_max)}

# Politique restrictive pour un PLC de contrôle de pression
PUMP_POLICY = ModbusProxyPolicy(
    allowed_unit_ids={1, 2},           # Seuls les PLCs 1 et 2
    allowed_read_fcs={1, 2, 3, 4},     # Lectures autorisées
    allowed_write_fcs={6},             # Écriture registre unique seulement
    allowed_client_ips={"10.0.2.10", "10.0.2.11"},  # HMIs autorisées seulement
    allowed_write_addresses={
        1: (100, 105),  # Setpoints de pression pour le PLC 1 (registres 100-105)
        2: (100, 105),  # Setpoints pour le PLC 2
    }
)

class ModbusSecureProxy:
    """Proxy Modbus avec filtrage de sécurité."""

    def __init__(self, listen_host: str, listen_port: int,
                 target_host: str, target_port: int,
                 policy: ModbusProxyPolicy):
        self.listen_host = listen_host
        self.listen_port = listen_port
        self.target_host = target_host
        self.target_port = target_port
        self.policy = policy
        self.blocked_count = 0

    async def handle_client(self, reader: asyncio.StreamReader,
                             writer: asyncio.StreamWriter):
        """Gère une connexion client avec filtrage de sécurité."""
        client_ip = writer.get_extra_info('peername')[0]

        # Vérifier l'IP cliente
        if client_ip not in self.policy.allowed_client_ips:
            logger.warning(f"BLOQUÉ — IP non autorisée : {client_ip}")
            writer.close()
            self.blocked_count += 1
            return

        # Connexion vers le PLC réel
        try:
            plc_reader, plc_writer = await asyncio.open_connection(
                self.target_host, self.target_port)
        except ConnectionRefusedError:
            logger.error(f"Impossible de se connecter au PLC {self.target_host}:{self.target_port}")
            writer.close()
            return

        logger.info(f"Connexion proxifiée : {client_ip} -> {self.target_host}:{self.target_port}")

        try:
            while True:
                # Lire l'en-tête Modbus/TCP (6 bytes)
                header = await asyncio.wait_for(reader.readexactly(6), timeout=30)
                length = struct.unpack('>H', header[4:6])[0]
                payload = await asyncio.wait_for(reader.readexactly(length), timeout=30)

                full_request = header + payload

                # Analyser la requête
                unit_id = payload[0]
                func_code = payload[1] if len(payload) > 1 else 0

                # Vérification du Unit ID
                if unit_id not in self.policy.allowed_unit_ids:
                    logger.warning(f"BLOQUÉ — Unit ID non autorisé : {unit_id} depuis {client_ip}")
                    self.blocked_count += 1
                    # Envoyer une exception Modbus (code 0x04 — SLAVE_DEVICE_FAILURE)
                    error_response = header[:4] + b'\x00\x03' + bytes([unit_id, func_code | 0x80, 0x04])
                    writer.write(error_response)
                    continue

                # Vérification des Function Codes d'écriture
                WRITE_FCS = {5, 6, 15, 16, 22, 23}
                if func_code in WRITE_FCS:
                    if func_code not in self.policy.allowed_write_fcs:
                        logger.critical(f"BLOQUÉ — FC d'écriture non autorisé : FC{func_code} "
                                       f"depuis {client_ip} vers Unit {unit_id}")
                        self.blocked_count += 1
                        continue

                    # Vérification de la plage d'adresses pour les écritures
                    if len(payload) >= 4 and unit_id in self.policy.allowed_write_addresses:
                        write_addr = struct.unpack('>H', payload[2:4])[0]
                        addr_min, addr_max = self.policy.allowed_write_addresses[unit_id]
                        if not (addr_min <= write_addr <= addr_max):
                            logger.critical(f"BLOQUÉ — Écriture hors plage autorisée : "
                                          f"registre {write_addr} (autorisé: {addr_min}-{addr_max})")
                            self.blocked_count += 1
                            continue

                    logger.info(f"ÉCRITURE AUTORISÉE : FC{func_code} sur Unit {unit_id} depuis {client_ip}")

                # Transmettre la requête au PLC
                plc_writer.write(full_request)
                response = await asyncio.wait_for(plc_reader.read(1024), timeout=10)
                writer.write(response)

        except (asyncio.TimeoutError, asyncio.IncompleteReadError, ConnectionResetError):
            pass
        finally:
            plc_writer.close()
            writer.close()
            logger.info(f"Connexion fermée : {client_ip}")

    async def start(self):
        """Démarre le proxy."""
        server = await asyncio.start_server(
            self.handle_client, self.listen_host, self.listen_port)
        logger.info(f"Proxy Modbus démarré sur {self.listen_host}:{self.listen_port}")
        logger.info(f"Forwarding vers {self.target_host}:{self.target_port}")
        async with server:
            await server.serve_forever()

if __name__ == "__main__":
    proxy = ModbusSecureProxy(
        listen_host="0.0.0.0",
        listen_port=502,
        target_host="10.0.1.100",  # PLC réel
        target_port=502,
        policy=PUMP_POLICY
    )
    asyncio.run(proxy.start())

27. Certification et formation en sécurité ICS

En France, l'ANSSI propose des formations certifiantes pour les experts OT via son programme SecNumedu et publie des guides techniques gratuits : le Guide de la cybersécurité des systèmes industriels (ANSSI, 2014, mis à jour 2021) reste une référence fondamentale pour les équipes françaises.

28. Analyse de risque OT selon IEC 62443-3-2

La norme IEC 62443-3-2 définit la méthodologie d'analyse de risque pour les systèmes ICS, en particulier le processus de détermination des Security Levels cibles (SL-T) pour chaque zone et conduit. Cette analyse est le fondement de tout programme de sécurité OT structuré et doit précéder toute décision d'investissement en sécurité industrielle.

L'analyse de risque IEC 62443 se déroule en cinq étapes distinctes. La première étape consiste à définir la portée du système sous évaluation (SUE) et à identifier toutes les zones et conduits selon la terminologie IEC 62443. Une zone est un regroupement logique de systèmes avec des exigences de sécurité communes — par exemple, la zone de contrôle des pompes, la zone de supervision SCADA, la zone des serveurs d'ingénierie. Un conduit est le chemin de communication entre deux zones, incluant les protocoles utilisés, les pare-feux et les équipements réseau.

La deuxième étape est l'identification des menaces. Pour chaque zone et conduit, on applique la taxonomie des menaces ICS : menaces d'origine humaine (attaquants internes, prestataires malveillants, hacktivistes, cybercriminels organisés, États-nations), menaces d'origine non humaine (pannes matérielles, erreurs de configuration, catastrophes naturelles) et menaces liées à la chaîne d'approvisionnement (composants matériels ou logiciels compromis à la source).

La troisième étape est l'évaluation de la conséquence pour chaque scénario de menace. IEC 62443 propose quatre catégories de conséquences : sûreté des personnes (blessures, décès), impact environnemental (déversements, émissions), impact financier direct (pertes de production, coûts de rétablissement) et impact sur la réputation. Pour chaque catégorie, une échelle de gravité de 1 (insignifiant) à 4 (catastrophique) est appliquée.

La quatrième étape est l'évaluation de la probabilité d'occurrence pour chaque scénario, en tenant compte des contremesures existantes. La probabilité combine la motivation de l'attaquant, sa capacité technique, l'accessibilité de la cible et les contremesures en place. La cinquième étape est la détermination du niveau de risque résiduel et la décision de traitement : accepter le risque, réduire le risque (implémentation de contrôles), transférer le risque (assurance cyber) ou éviter le risque (suppression de la fonctionnalité vulnérable).

La corrélation entre le niveau de risque déterminé et le Security Level cible (SL-T) s'effectue selon la matrice ci-dessous. Un risque calculé comme élevé pour une zone de contrôle de procédés chimiques dangereux conduit typiquement à un SL-T de 3 (protection contre les attaquants avec ressources ICS spécifiques), voire 4 pour les procédés à très haute conséquence (nucléaire, chimie des agents dangereux).

L'implémentation pratique de cette méthodologie dans les organisations françaises s'appuie généralement sur des outils dédiés. EBIOS RM (Expression des Besoins et Identification des Objectifs de Sécurité, méthode de l'ANSSI) peut être adaptée aux environnements OT en complément d'IEC 62443-3-2. La méthode HAZOP (Hazard and Operability Study), historiquement utilisée pour les analyses de sûreté fonctionnelle, est souvent étendue pour intégrer les scénarios de cybersécurité, créant ainsi des analyses CHAZOP (Cyber HAZOP). Cette convergence des analyses de sûreté et de cybersécurité est particulièrement recommandée pour les procédés chimiques et pétroliers où les conséquences d'une attaque réussie peuvent être catastrophiques.

29. Gestion des patchs OT : contraintes et stratégies

La gestion des correctifs de sécurité dans les environnements industriels est fondamentalement différente de celle des environnements IT, en raison de plusieurs contraintes spécifiques qui la rendent beaucoup plus complexe. Comprendre ces contraintes est essentiel pour concevoir une stratégie réaliste et efficace.

La contrainte de disponibilité est la plus contraignante. Les environnements OT fonctionnent souvent en continu (24/7/365) avec des taux de disponibilité exigés de 99,99% ou plus. Les fenêtres de maintenance permettant l'application de correctifs peuvent être rares — typiquement une ou deux fois par an pour des arrêts planifiés de quelques jours dans les industries chimiques et pétrochimiques, ou plus fréquentes (hebdomadaires) dans certaines industries manufacturières. Pendant ces fenêtres, l'équipe de sécurité doit prioriser et appliquer des mois de correctifs accumulés en quelques heures, tout en maintenant la disponibilité des systèmes critiques.

La contrainte de qualification est la deuxième grande difficulté. Les équipements ICS sont souvent soumis à des certifications réglementaires (FDA 21 CFR Part 11 pour la pharmacie, SIL pour les systèmes de sécurité instrumentée, certifications nucléaires). L'application d'un correctif de sécurité peut invalider une certification existante, nécessitant des tests de validation coûteux et longs avant le retour en production. Certains fabricants d'automates (Siemens, Schneider, Rockwell) exigent que les patchs soient appliqués par leurs propres équipes ou des intégrateurs certifiés, ajoutant des délais supplémentaires.

La contrainte de rétrocompatibilité complique encore la situation. De nombreux systèmes ICS intègrent des composants vieillissants (Windows XP Embedded, Windows Server 2003, des protocoles réseau obsolètes) qui ne peuvent pas être mis à jour vers des versions supportées sans remplacer l'ensemble de l'équipement, un investissement qui se chiffre en millions d'euros pour une grande installation. Pour ces systèmes en fin de vie, la stratégie de défense repose exclusivement sur la compensation par d'autres contrôles : segmentation réseau renforcée, monitoring intensif, liste blanche d'applications, chiffrement des communications sortantes.

Face à ces contraintes, plusieurs stratégies pratiques se dégagent pour les équipes de sécurité OT. La première est la hiérarchisation des correctifs selon un score combinant la sévérité CVSS et l'exploitabilité en contexte OT. Un correctif critique pour une vulnérabilité VPN exposée sur Internet sera traité dans les 48 heures, même en dehors de la fenêtre de maintenance planifiée, tandis qu'un correctif de bibliothèque peu utilisée peut attendre l'arrêt annuel.

La deuxième stratégie est la mise en place d'environnements de test OT fidèles à la production. Ces maquettes permettent de tester les correctifs avant leur déploiement en production, d'identifier les régressions et les incompatibilités, et de former les équipes aux procédures de déploiement. L'investissement dans une maquette, bien que coûteux initialement, est justifié par la réduction des risques d'indisponibilité lors des mises à jour.

La troisième stratégie est l'utilisation de Virtual Patching via les pare-feux applicatifs ICS. Des solutions comme Tofino Security, Claroty xDome ou les fonctionnalités de filtrage protocole des pare-feux industriels permettent de bloquer l'exploitation de vulnérabilités connues au niveau réseau, sans modifier le système vulnérable lui-même. Cette approche permet de maintenir la protection même en l'absence de correctif officiel ou pendant l'attente de la prochaine fenêtre de maintenance.

30. Aspects réglementaires en France : OIV et NIS2

En France, la régulation de la cybersécurité des systèmes industriels s'inscrit dans un cadre légal et réglementaire spécifique qui implique des obligations concrètes pour les opérateurs concernés. La Loi de Programmation Militaire (LPM) de 2013 a introduit en France le concept d'Opérateurs d'Importance Vitale (OIV) et leurs obligations en matière de cybersécurité des Systèmes d'Information d'Importance Vitale (SIIV). Ces obligations sont définies dans des arrêtés sectoriels confidentiels pour chacun des douze secteurs d'activité d'importance vitale : énergie, eau, transports, santé, alimentation, finances, communications électroniques, industrie de défense, activités judiciaires et gouvernementales.

La directive NIS2 (Network and Information Security 2), transposée en droit français fin 2024 sous le nom de loi sur la résilience des entités essentielles, a considérablement élargi le périmètre des obligations en créant deux catégories d'entités : les Entités Essentielles (EE) et les Entités Importantes (EI). Les EE sont soumises aux obligations les plus strictes, incluant des mesures de cybersécurité renforcées pour les systèmes OT dans les secteurs de l'énergie, de l'eau, des transports et de la santé. Les obligations concrètes incluent la mise en place d'une politique de sécurité des systèmes d'information OT documentée, la réalisation d'audits de sécurité périodiques (tous les trois ans pour les EE), la notification des incidents significatifs à l'ANSSI dans les 24 heures suivant leur détection, et la mise en place de plans de continuité et de reprise d'activité couvrant les scénarios cyber.

L'ANSSI publie des guides techniques sectoriels spécifiques aux environnements OT, notamment le Guide de la Cybersécurité des Systèmes Industriels (2014, mis à jour 2021) qui couvre la segmentation réseau, la gestion des accès distants, la gestion des patchs et la détection d'intrusion pour les SCADA. Ces guides, bien que non juridiquement contraignants pour les non-OIV, constituent la référence technique de l'état de l'art en France et sont fréquemment utilisés comme base de référence lors d'audits contractuels ou d'évaluations de la conformité assurantielle.

Pour les organisations souhaitant se faire certifier selon IEC 62443, plusieurs organismes accrédités opèrent en France : Bureau Veritas, SGS, Dekra et TÜV Rheinland proposent des services d'audit et de certification IEC 62443. La certification IEC 62443-2-1 (pour les systèmes de management de la cybersécurité OT) et IEC 62443-3-3 (pour les exigences de sécurité au niveau système) sont les plus demandées par les grandes organisations industrielles françaises, notamment dans les secteurs de l'eau, de l'énergie et du traitement des déchets.

Conclusion et recommandations

La maîtrise de ces techniques et outils est indispensable pour tout professionnel de la cybersécurité en 2026. L'évolution constante des menaces exige une veille permanente et une mise à jour régulière des compétences. Pour aller plus loin, consultez nos articles techniques ou contactez notre équipe pour un accompagnement sur mesure adapté à votre contexte.