P.I.L.O.T.E

5 min de lecture

04.2_Detail_SL_1a4

La norme IEC 62443 définit les Security Levels (SL) pour mesurer et démontrer la robustesse d’une architecture OT face aux menaces. Contrairement à une simple classification, les SL doivent être appliqués selon trois dimensions complémentaires :

  • SL‑T (Target Security Level) : le niveau de sécurité cible défini pour une zone ou un conduit, en fonction des scénarios de menace auxquels ils doivent résister.
  • SL‑C (Capability Security Level) : le niveau de sécurité que les composants (ex. PLC, firewall, HMI) sont capables de fournir.
  • SL‑A (Achieved Security Level) : le niveau réellement atteint après intégration et audit des systèmes.

Cette distinction est cruciale : il est possible de viser un SL‑T=3 pour un SCADA, mais si les composants ne dépassent pas un SL‑C=2, alors le SL‑A final sera limité. L’objectif du RSSI est donc de réduire l’écart entre SL‑T et SL‑A en choisissant des composants adaptés et en renforçant les mesures organisationnelles.

Dérivation des SL‑T à partir des menaces

La définition des SL‑T doit partir d’une analyse de risques et de scénarios de menace réalistes. La 62443 recommande une approche progressive :

MenaceExemple de scénarioSL‑T recommandé
Erreur humaine non intentionnelleOpérateur qui modifie un paramètre par inadvertanceSL‑T = 1
Malware opportunisteInfection par un ver type WannaCrySL‑T = 2
Malveillance interne cibléeEmployé qui modifie le SCADA pour saboter la productionSL‑T = 3
Attaque externe organisée (APT)Groupe menaçant ciblant un réseau électrique nationalSL‑T = 4

Ce tableau illustre que la malveillance interne impose un SL‑T ≥ 3, tandis qu’une attaque de type APT exige un SL‑T de 4 sur les zones critiques (ex. SCADA énergie).

Les Foundational Requirements (FR) – IEC 62443‑3‑3

La norme 62443‑3‑3 décline les SL en exigences fondamentales (FR) applicables à tout système :

  • IAC – Identification and Authentication Control : gestion des identités, authentification forte, MFA.
  • UC – Use Control : gestion des droits et autorisations, séparation des tâches.
  • SI – System Integrity : durcissement des systèmes, intégrité logicielle et matérielle.
  • DC – Data Confidentiality : chiffrement des données en transit et au repos.
  • RDF – Restricted Data Flow : segmentation, filtrage des flux, pare‑feux industriels.
  • TRE – Timely Response to Events : journalisation, détection d’incidents, SOC/IDS/IPS.
  • RA – Resource Availability : disponibilité, redondance, PRA/PCA OT.

Chaque FR est décliné en System Requirements (SR) par niveau de SL (1 à 4).

Retours d’expérience et cas concrets

  • Stuxnet (2010) : a révélé la nécessité d’un SL‑T≥3 sur les automates, incluant des contrôles IAC (authentification forte) et SI (intégrité logicielle).
  • Ukraine – Industroyer (2016) : a démontré que des zones énergie critiques nécessitent un SL‑T=4, avec RDF (segmentation stricte) et TRE (détection en temps réel).
  • Colonial Pipeline (2021) : a mis en lumière que le SL‑T défini pour la zone IT n’avait pas été aligné avec l’OT, rendant l’arrêt global possible.

Preuves d’audit attendues

  • Documentation des SL‑T justifiant les choix par scénario de menace.
  • Inventaire des composants avec leur SL‑C déclaré par les fournisseurs.
  • Rapports d’audit comparant SL‑T, SL‑C et SL‑A, avec analyse des écarts.
  • Procédures FAT/SAT incluant des tests de conformité aux SR de la 62443‑3‑3.
  • Journaux d’événements démontrant l’activation des contrôles (MFA, segmentation, IDS/IPS).

Impacts organisationnels et gouvernance

  • Le COMEX doit valider les SL‑T pour chaque zone critique, car cela engage le niveau de risque acceptable pour l’organisation.
  • Le RSSI OT doit s’assurer que les SL‑T sont réalistes au regard des menaces sectorielles et des capacités techniques disponibles.
  • Les intégrateurs doivent démontrer comment l’architecture proposée atteint les SL‑T visés.
  • Les fournisseurs doivent fournir des fiches produits mentionnant clairement le SL‑C de leurs composants.
  • Les auditeurs doivent mesurer l’écart entre SL‑T et SL‑A et recommander des plans correctifs.

Comparaisons utiles

  • ISO 27001 : ne propose pas d’équivalent aux SL, mais l’Annexe A introduit des mesures similaires.
  • NIST 800‑82 : recommande une approche par criticité comparable aux SL, mais sans formalisme tripartite (SL‑T, SL‑C, SL‑A).
  • NIS2 : impose que les mesures de sécurité soient proportionnées aux risques et aux menaces, ce qui se traduit en pratique par l’adoption de SL‑T adaptés.

Conséquences opérationnelles pour le RSSI

Le RSSI doit :

  • Conduire une analyse de risques OT pour définir les SL‑T.
  • Vérifier que les composants déployés atteignent un SL‑C suffisant pour couvrir les SL‑T.
  • Réaliser un audit de conformité afin de mesurer le SL‑A réellement atteint.
  • Définir un plan de remédiation si un écart existe entre SL‑T et SL‑A.
  • Documenter et présenter au COMEX les justifications des niveaux retenus.

Objectifs pédagogiques

À l’issue de ce chapitre, l’apprenant devra être capable de :

  • Expliquer la distinction entre SL‑T, SL‑C et SL‑A.
  • Dériver les SL‑T à partir de scénarios de menace.
  • Relier les Foundational Requirements (IAC, UC, SI, DC, RDF, TRE, RA) aux niveaux de SL.
  • Identifier les preuves d’audit permettant de démontrer la conformité.
  • Conseiller la direction sur les implications organisationnelles des choix de SL.

Checklist RSSI

  • Définir les SL‑T de chaque zone OT à partir de scénarios de menace.
  • Recueillir les SL‑C auprès des fournisseurs et vérifier leur conformité.
  • Réaliser un audit pour calculer le SL‑A et comparer avec le SL‑T.
  • Préparer les preuves FAT/SAT et journaux de sécurité associés aux FR.
  • Présenter les écarts et plans correctifs à la direction et au COMEX.

Vue Graphique