Chaque exigence technique de la norme IEC 62443 se rattache à l’une de sept exigences fondamentales (Foundational Requirements — FR). Ce ne sont pas des recommandations générales. Ce sont des catégories structurées qui contiennent des exigences système (SR) précises, chacune accompagnée de renforcements optionnels (RE) qui augmentent le niveau de sécurité.
Ce guide détaille les 7 exigences fondamentales, liste les 51 exigences système associées telles qu’elles apparaissent dans l’IEC 62443-3-3, et explique comment les appliquer concrètement dans un environnement industriel.
Sommaire
Comment les Exigences Fondamentales S’organisent
L’IEC 62443-1-1 définit les 7 exigences fondamentales. L’IEC 62443-3-3 les décline en exigences système (SR) avec des renforcements (RE) organisés par niveau de sécurité (SL 1 à SL 4).
La logique est simple :
- Chaque FR est un objectif de sécurité (ex : « contrôler qui accède au système »)
- Chaque SR est une exigence concrète qui contribue à cet objectif (ex : « authentifier les utilisateurs humains »)
- Chaque RE est un renforcement qui augmente le niveau de protection (ex : « ajouter l’authentification multi-facteurs »)
- Le niveau de sécurité (SL 1 à 4) détermine quelles SR et quels RE sont exigés
À SL 1, seules les SR de base sont requises. À SL 4, presque toutes les SR et leurs RE sont exigés. Le niveau cible (SL-T) de chaque zone détermine les exigences applicables.
FR 1 — Contrôle de l’Identification et de l’Authentification (IAC)
Objectif : Vérifier l’identité de chaque utilisateur, processus logiciel et dispositif avant d’accorder l’accès au système.
C’est la première ligne de défense. Si un attaquant peut accéder au système sans s’identifier, toutes les autres mesures de sécurité deviennent inutiles. FR 1 est aussi la plus détaillée des 7 exigences fondamentales — elle contient 13 exigences système.
Exigences système de FR 1
| SR | Intitulé | Ce que ça couvre |
|---|---|---|
| SR 1.1 | Identification et authentification des utilisateurs humains | Chaque personne qui accède au système doit être identifiée et authentifiée. RE 1 exige une identification unique. RE 2 exige l’authentification multi-facteurs pour les accès via des réseaux non fiables. RE 3 l’exige pour tous les réseaux. |
| SR 1.2 | Identification et authentification des processus logiciels et dispositifs | Les logiciels et les dispositifs (pas seulement les humains) doivent prouver leur identité avant de communiquer. |
| SR 1.3 | Gestion des comptes | Créer, gérer, activer, désactiver et supprimer les comptes. Inclut l’audit des comptes existants. |
| SR 1.4 | Gestion des identifiants | S’assurer que chaque identifiant est unique et ne peut pas être réutilisé par une autre entité. |
| SR 1.5 | Gestion des moyens d’authentification | Protéger les mots de passe, certificats et autres moyens d’authentification contre le vol et la modification. |
| SR 1.6 | Gestion de l’accès sans fil | Contrôler et surveiller tous les accès sans fil au réseau IACS. Identifier et authentifier chaque dispositif sans fil. |
| SR 1.7 | Force de l’authentification par mot de passe | Imposer des règles de complexité et de longueur minimale pour les mots de passe. |
| SR 1.8 | Certificats PKI (Infrastructure à clé publique) | Gérer les certificats numériques utilisés pour l’authentification. Valider les certificats avant de les accepter. |
| SR 1.9 | Force de l’authentification par clé publique | Imposer des longueurs de clé et des algorithmes suffisamment robustes. |
| SR 1.10 | Retour d’information de l’authentificateur | Le système ne doit pas révéler d’informations utiles à un attaquant pendant le processus d’authentification (pas de message « mot de passe incorrect » qui confirme que l’identifiant existe). |
| SR 1.11 | Tentatives de connexion échouées | Limiter les tentatives de connexion pour empêcher les attaques par force brute. Attention : en environnement industriel, un verrouillage trop strict peut empêcher un opérateur d’accéder à des commandes critiques en situation d’urgence. |
| SR 1.12 | Notification d’utilisation du système | Afficher un avertissement d’utilisation autorisée avant la connexion. |
| SR 1.13 | Accès via des réseaux non fiables | Contrôler spécifiquement les accès qui proviennent de réseaux extérieurs au périmètre de confiance. |
Ce que ça signifie en pratique
Sur un site industriel, FR 1 implique : changer tous les mots de passe par défaut des automates et des IHM, mettre en place une authentification individuelle (pas un compte partagé « operateur »), exiger l’authentification multi-facteurs pour tout accès distant, et surveiller les accès sans fil.
FR 2 — Contrôle d’Utilisation (UC)
Objectif : Après avoir authentifié un utilisateur ou un processus, imposer ce qu’il est autorisé à faire.
L’identification dit qui vous êtes. Le contrôle d’utilisation dit ce que vous pouvez faire. FR 2 applique le principe du moindre privilège : chaque utilisateur n’a accès qu’aux fonctions strictement nécessaires à son rôle.
Exigences système de FR 2
| SR | Intitulé | Ce que ça couvre |
|---|---|---|
| SR 2.1 | Application des autorisations | Le système doit appliquer les privilèges assignés à chaque utilisateur et processus. |
| SR 2.2 | Contrôle d’utilisation sans fil | Restreindre les actions autorisées via des connexions sans fil. |
| SR 2.3 | Contrôle des dispositifs portables et mobiles | Gérer l’utilisation des ordinateurs portables, tablettes et clés USB dans l’environnement IACS. |
| SR 2.4 | Code mobile | Contrôler l’exécution de code mobile (scripts, applets) sur les systèmes de l’IACS. |
| SR 2.5 | Verrouillage de session | Verrouiller automatiquement les sessions inactives après un délai défini. |
| SR 2.6 | Terminaison de session distante | Pouvoir mettre fin à une session distante de manière forcée. |
| SR 2.7 | Contrôle de sessions simultanées | Limiter le nombre de sessions simultanées par utilisateur. |
| SR 2.8 | Événements auditables | Définir quels événements doivent être enregistrés dans les journaux d’audit. |
| SR 2.9 | Capacité de stockage d’audit | S’assurer que l’espace de stockage des journaux est suffisant. |
| SR 2.10 | Réponse aux échecs de traitement d’audit | Définir le comportement du système quand le mécanisme d’audit échoue. |
| SR 2.11 | Horodatage | Utiliser des horodatages fiables et synchronisés pour les enregistrements d’audit. |
| SR 2.12 | Non-répudiation | Empêcher un utilisateur de nier avoir effectué une action. |
Ce que ça signifie en pratique
Un opérateur de conduite peut voir les données de process et acquitter les alarmes, mais ne peut pas modifier la logique de l’automate. Un ingénieur d’automatisme peut programmer les automates, mais ne peut pas modifier les règles du pare-feu. Un prestataire externe a accès uniquement aux équipements qu’il maintient, pendant une fenêtre de temps définie.
FR 3 — Intégrité du Système (SI)
Objectif : Protéger le système contre les modifications non autorisées et détecter les violations d’intégrité.
FR 3 garantit que le logiciel, la configuration et les communications n’ont pas été altérés par un attaquant. C’est la détection de falsification appliquée à l’ensemble du système.
Exigences système de FR 3
| SR | Intitulé | Ce que ça couvre |
|---|---|---|
| SR 3.1 | Intégrité des communications | Protéger l’intégrité des données échangées entre les composants du système. |
| SR 3.2 | Protection contre le code malveillant | Détecter, prévenir et récupérer d’infections par des logiciels malveillants. |
| SR 3.3 | Vérification des fonctionnalités de sécurité | Permettre la vérification du bon fonctionnement des mécanismes de sécurité. |
| SR 3.4 | Intégrité du logiciel et de l’information | Détecter les modifications non autorisées du logiciel et des données. RE 1 exige une notification automatique des violations d’intégrité. |
| SR 3.5 | Validation des entrées | Valider toutes les données reçues par le système avant de les traiter. |
| SR 3.6 | Sortie déterministe | S’assurer que le système produit des sorties prévisibles et correctes dans des conditions définies. |
| SR 3.7 | Traitement des erreurs | Gérer les erreurs sans révéler d’informations utiles à un attaquant. |
| SR 3.8 | Intégrité de session | Protéger les sessions contre le détournement et la modification. |
| SR 3.9 | Protection des informations d’audit | Empêcher la modification ou la suppression des journaux d’audit. |
Ce que ça signifie en pratique
Un automate dont le programme a été modifié sans autorisation doit être détecté. Une trame Modbus altérée en transit doit être identifiée. Un historique dont les enregistrements ont été supprimés doit déclencher une alerte. En environnement industriel, la liste blanche d’applications (application whitelisting) est souvent le moyen le plus efficace d’implémenter SR 3.2 — car les antivirus traditionnels ne fonctionnent pas sur les systèmes de contrôle.
FR 4 — Confidentialité des Données (DC)
Objectif : Empêcher les utilisateurs, processus ou dispositifs non autorisés de lire des informations sensibles.
FR 4 est la plus courte des 7 exigences fondamentales — elle ne contient que 3 exigences système. En environnement industriel, la confidentialité est la priorité la plus basse (après la disponibilité et l’intégrité). Mais elle reste importante : les recettes de fabrication, les paramètres de process et les identifiants d’accès doivent être protégés.
Exigences système de FR 4
| SR | Intitulé | Ce que ça couvre |
|---|---|---|
| SR 4.1 | Confidentialité de l’information | Protéger les informations sensibles contre la lecture non autorisée, en transit et au repos. |
| SR 4.2 | Persistance de l’information | S’assurer que les données sensibles sont correctement effacées quand elles ne sont plus nécessaires (mémoire, supports de stockage). |
| SR 4.3 | Utilisation de la cryptographie | Utiliser des algorithmes et des protocoles cryptographiques conformes aux bonnes pratiques reconnues. |
Ce que ça signifie en pratique
Les identifiants stockés dans les IHM et les postes d’ingénierie doivent être chiffrés, pas stockés en clair. Les communications qui transportent des recettes de fabrication ou des paramètres sensibles doivent être chiffrées quand le protocole le permet. Quand le protocole ne le permet pas (Modbus, DNP3 sans Secure Authentication), des tunnels chiffrés ou des VPN doivent être utilisés comme mesures compensatoires.
FR 5 — Flux de Données Restreint (RDF)
Objectif : Segmenter le réseau pour que les données ne circulent que là où c’est nécessaire. Bloquer tout le reste.
FR 5 est l’exigence qui donne vie au modèle zones et conduits de l’IEC 62443. C’est la traduction technique de la segmentation réseau en exigences vérifiables.
Exigences système de FR 5
| SR | Intitulé | Ce que ça couvre |
|---|---|---|
| SR 5.1 | Segmentation du réseau | Diviser le réseau en zones logiques en fonction des exigences de sécurité. |
| SR 5.2 | Protection des frontières de zone | Surveiller et contrôler les communications aux frontières entre les zones. |
| SR 5.3 | Restrictions des communications point à point | Restreindre les communications directes entre utilisateurs qui ne passent pas par les systèmes de contrôle. |
| SR 5.4 | Partitionnement applicatif | Séparer les applications critiques des applications non critiques, même sur le même hôte. |
Ce que ça signifie en pratique
Un pare-feu entre la zone entreprise et la zone OT, configuré pour n’autoriser que les protocoles strictement nécessaires. Des VLAN séparés pour les différents niveaux du modèle de référence. Une DMZ entre l’IT et l’OT. Aucune communication directe entre un poste de messagerie et un automate. Le trafic de navigation web ne doit jamais atteindre le réseau de contrôle.
FR 6 — Réponse Rapide aux Événements (TRE)
Objectif : Surveiller les événements de sécurité, les enregistrer et alerter rapidement les bonnes personnes.
FR 6 est la capacité de détection. Sans elle, un attaquant peut opérer dans le réseau pendant des semaines ou des mois sans être repéré — comme dans l’attaque du réseau électrique ukrainien où les attaquants étaient présents depuis plusieurs mois avant d’agir.
Exigences système de FR 6
| SR | Intitulé | Ce que ça couvre |
|---|---|---|
| SR 6.1 | Accessibilité des journaux d’audit | Les journaux d’audit doivent être accessibles en lecture seule aux personnels autorisés. |
| SR 6.2 | Surveillance continue | Le système doit surveiller en continu les événements de sécurité et alerter en cas d’anomalie. |
Ce que ça signifie en pratique
Déployer un système de détection d’intrusion (IDS) adapté aux protocoles industriels (Modbus, DNP3, OPC). Établir des comportements de référence (baselines) du trafic réseau. Alerter sur les nouveaux dispositifs, les schémas de communication inhabituels et les séquences de commandes anormales. Centraliser les journaux et les protéger contre la suppression.
FR 7 — Disponibilité des Ressources (RA)
Objectif : Protéger contre les attaques par déni de service et maintenir le système opérationnel sous contrainte.
FR 7 est l’exigence la plus spécifique aux environnements industriels. En IT, un serveur web indisponible pendant une heure est un désagrément. En OT, un automate indisponible pendant une seconde peut provoquer un arrêt d’urgence, une surpression ou un dégagement de produits dangereux.
Exigences système de FR 7
| SR | Intitulé | Ce que ça couvre |
|---|---|---|
| SR 7.1 | Protection contre le déni de service | Le système doit résister aux attaques DoS et maintenir ses fonctions essentielles. |
| SR 7.2 | Gestion des ressources | Gérer les ressources système (CPU, mémoire, bande passante) pour empêcher leur épuisement. |
| SR 7.3 | Sauvegarde du système de contrôle | Effectuer des sauvegardes régulières de la logique automate, des configurations IHM et des données de l’historique. |
| SR 7.4 | Récupération et reconstitution du système de contrôle | Pouvoir restaurer le système à partir des sauvegardes dans un délai défini. |
| SR 7.5 | Alimentation de secours | Maintenir l’alimentation électrique des composants critiques du système de contrôle en cas de coupure. |
| SR 7.6 | Paramètres de configuration réseau et sécurité | Documenter et protéger les configurations réseau et sécurité. |
| SR 7.7 | Fonctionnalité minimale | Désactiver les services, protocoles et fonctionnalités non nécessaires pour réduire la surface d’attaque. |
| SR 7.8 | Inventaire des composants du système de contrôle | Maintenir un inventaire à jour de tous les composants du système de contrôle. |
Ce que ça signifie en pratique
Sauvegarder les programmes automate et les tester régulièrement en restauration. Maintenir un inventaire complet de chaque dispositif, avec les versions de firmware et les configurations. Supprimer tous les services inutiles des postes IHM et des serveurs SCADA. Documenter les configurations réseau et pare-feu. Prévoir une alimentation sans interruption (UPS) pour les systèmes de contrôle critiques.
Synthèse : Les 51 Exigences Système en un Coup d’Œil
| FR | Nom | Nombre de SR |
|---|---|---|
| FR 1 | Identification et authentification | 13 SR |
| FR 2 | Contrôle d’utilisation | 12 SR |
| FR 3 | Intégrité du système | 9 SR |
| FR 4 | Confidentialité des données | 3 SR |
| FR 5 | Flux de données restreint | 4 SR |
| FR 6 | Réponse rapide aux événements | 2 SR |
| FR 7 | Disponibilité des ressources | 8 SR |
| Total | 51 SR |
Les FR ne sont pas toutes de même taille. FR 1 (authentification) est de loin la plus détaillée avec 13 SR. FR 6 (détection) est la plus concise avec seulement 2 SR. Mais la taille ne reflète pas l’importance : FR 7 (disponibilité) est souvent la plus critique en environnement industriel, car c’est elle qui garantit que le système de contrôle reste opérationnel.
Comment les Niveaux de Sécurité S’appliquent aux FR
Chaque SR a un tableau dans l’IEC 62443-3-3 qui indique si elle est exigée à chaque niveau de sécurité :
| SL 1 | SL 2 | SL 3 | SL 4 | |
|---|---|---|---|---|
| SR de base | La plupart | Toutes | Toutes | Toutes |
| RE (renforcements) | Aucun | Certains | La plupart | Tous |
À SL 1, le système doit respecter les SR de base — le minimum pour se protéger contre les violations accidentelles. À SL 4, le système doit respecter toutes les SR avec presque tous les renforcements — le maximum pour résister à une attaque étatique avec des ressources étendues.
L’écart entre deux niveaux n’est pas linéaire. Le passage de SL 2 à SL 3 représente un saut significatif en termes de coût et de complexité, car il exige des mécanismes d’authentification forte, du chiffrement de bout en bout et une surveillance continue.
Questions Fréquentes
Quelle est la différence entre une FR et une SR ?
Une FR (Foundational Requirement) est un objectif de sécurité de haut niveau — par exemple, « contrôler l’accès au système ». Une SR (System Requirement) est une exigence concrète et vérifiable qui contribue à cet objectif — par exemple, « authentifier les utilisateurs humains ». Les FR sont définies dans l’IEC 62443-1-1. Les SR sont détaillées dans l’IEC 62443-3-3.
Faut-il respecter toutes les 51 SR ?
Non. Le nombre de SR applicables dépend du niveau de sécurité cible (SL-T) de chaque zone. À SL 1, seules les SR de base sont exigées. À SL 4, toutes les SR et presque tous les renforcements (RE) sont exigés. Votre analyse de risque (IEC 62443-3-2) détermine le SL-T de chaque zone.
Quelle FR est la plus importante pour un site industriel ?
Cela dépend du profil de menace. Pour la majorité des sites, FR 1 (authentification), FR 5 (segmentation) et FR 7 (disponibilité) sont les trois exigences les plus critiques. FR 1 empêche l’accès non autorisé. FR 5 limite la propagation. FR 7 maintient le système en service.
Les FR s’appliquent-elles aux composants individuels ?
Oui. L’IEC 62443-4-2 traduit les mêmes 7 FR en exigences techniques pour les composants individuels (automates, IHM, équipements réseau). Les FR s’appliquent à trois niveaux : le système (62443-3-3), les composants (62443-4-2) et l’organisation (62443-2-1).
Où trouver les RE (Requirement Enhancements) ?
Les RE sont détaillés dans l’IEC 62443-3-3, directement sous chaque SR. Chaque SR a une section « Requirement enhancements » qui liste les renforcements disponibles et un tableau « Security levels » qui indique à quel SL chaque RE est exigé.