Points clés
- IEC 62443-3-3 : les 51 exigences système (SR) par exigence fondamentale, le mécanisme des renforcements RE, et comment les appliquer selon votre SL cible.
- Protocole principal : IEC 62443-3-3 — consulter les articles associés sur la page thématique.
- Temps de lecture : 13 min read · 2 346 mots · publié .
Vous avez fixé un niveau de sécurité cible pour votre zone. SL 2, disons. Et maintenant ?
C'est là que la plupart des démarches IEC 62443 s'arrêtent. On sait découper le réseau en zones, on sait qu'il faut viser SL 2, mais personne ne sait quoi écrire dans le cahier des charges.
L'IEC 62443-3-3 est le document qui répond à cette question. Elle traduit les sept exigences fondamentales en 51 exigences système concrètes, et indique lesquelles s'appliquent à chaque niveau de sécurité.
C'est la partie la plus opérationnelle de toute la série.
- Ce que cette partie fait, et ce qu'elle ne fait pas
- Le mécanisme : exigence de base et renforcements
- Les 51 exigences système
- Répartition par exigence fondamentale
- Comment s'en servir concrètement
- Ce que la norme ne vous donnera pas
- Questions fréquentes
Ce que cette partie fait, et ce qu'elle ne fait pas
Elle traite du système, c'est-à-dire de l'ensemble constitué des automates, du SCADA, du réseau et des postes d'ingénierie, pris comme un tout dans une zone donnée.
Elle ne traite pas des composants pris individuellement. Si vous voulez savoir ce qu'un automate doit savoir faire tout seul, c'est l'IEC 62443-4-2 qu'il faut ouvrir. Les deux documents partagent les mêmes sept exigences fondamentales et les mêmes quatre niveaux, mais l'un s'adresse à l'intégrateur, l'autre au constructeur.
C'est une distinction qui a des conséquences pratiques. Un système peut atteindre SL 2 avec des composants qui, seuls, n'atteignent que SL 1 — à condition que l'architecture compense. Un pare-feu de zone peut fournir la protection qu'un automate ancien est incapable d'assurer.
Le mécanisme : exigence de base et renforcements
C'est le point que la plupart des articles ratent, et sans lui la norme est illisible.
Chaque SR comporte :
- une exigence de base, qui définit le minimum
- un ou plusieurs renforcements (Requirement Enhancements, RE), numérotés RE(1), RE(2), RE(3)
Le niveau de sécurité ne change pas la liste des SR. Il change le nombre de renforcements à appliquer.
Prenons SR 1.1, l'identification et l'authentification des utilisateurs humains :
| Niveau | Ce qui est exigé |
|---|---|
| SL 1 | Exigence de base : identifier et authentifier les utilisateurs |
| SL 2 | + RE(1) : identification unique, donc pas de compte partagé |
| SL 3 | + RE(2) : authentification multifacteur depuis les réseaux non fiables |
| SL 4 | + RE(3) : authentification multifacteur depuis tous les réseaux |
Vous voyez la logique. Passer de SL 2 à SL 3 ne vous demande pas de nouvelles catégories de mesures. Cela vous demande de durcir celles que vous avez déjà.
Certaines SR ne sont pas exigées du tout au SL 1 et n'apparaissent qu'à partir du SL 2. La surveillance continue, SR 6.2, en fait partie.
Un exemple vérifié : la SR 3.4
L'intégrité du logiciel et de l'information, SR 3.4, illustre bien le mécanisme — et elle a fait l'objet d'une correction officielle.
| Exigence | SL 1 | SL 2 | SL 3 | SL 4 |
|---|---|---|---|---|
| SR 3.4 — Intégrité du logiciel et de l'information | — | ✓ | ✓ | ✓ |
| SR 3.4 RE(1) — Notification automatique des violations d'intégrité | — | — | ✓ | ✓ |
Deux enseignements. D'abord, la SR 3.4 n'est pas exigée au SL 1 : elle n'apparaît qu'à partir du SL 2. Ensuite, la détection d'une violation d'intégrité est une chose, sa notification automatique en est une autre — et celle-ci n'arrive qu'au SL 3.
Autrement dit, à SL 2 vous devez pouvoir constater qu'un fichier de configuration d'automate a été modifié. À SL 3, votre système doit vous le signaler tout seul.
Attention à l'édition que vous utilisez
Ces deux lignes ont été corrigées après la première publication de la norme. Dans le texte d'origine, la SR 3.4 était rattachée au SL 1 ; le correctif l'en retire.
Si vous travaillez à partir d'un exemplaire non corrigé, votre mapping est faux sur cette ligne. Vérifiez que votre copie intègre bien les correctifs publiés avant de bâtir une spécification dessus.
Les 51 exigences système
FR 1 — Identification et authentification (13 SR)
| SR | Objet |
|---|---|
| 1.1 | Identification et authentification des utilisateurs humains |
| 1.2 | Identification et authentification des processus logiciels et dispositifs |
| 1.3 | Gestion des comptes |
| 1.4 | Gestion des identifiants |
| 1.5 | Gestion des moyens d'authentification |
| 1.6 | Gestion de l'accès sans fil |
| 1.7 | Robustesse des mots de passe |
| 1.8 | Certificats à clé publique |
| 1.9 | Authentification par clé publique |
| 1.10 | Retour d'information de l'authentificateur |
| 1.11 | Tentatives de connexion échouées |
| 1.12 | Notification d'utilisation du système |
| 1.13 | Accès via des réseaux non fiables |
Le SR 1.2 mérite l'attention. Il ne concerne pas les humains mais les processus et les dispositifs : votre SCADA doit s'authentifier auprès de l'automate, pas seulement l'opérateur auprès du SCADA. Avec Modbus ou DNP3 sans sécurité, c'est structurellement impossible — le protocole n'a aucun mécanisme d'authentification. C'est là que la mesure compensatoire au niveau de la zone devient obligatoire.
FR 2 — Contrôle d'utilisation (12 SR)
| SR | Objet |
|---|---|
| 2.1 | Application des autorisations |
| 2.2 | Contrôle de l'utilisation sans fil |
| 2.3 | Contrôle des dispositifs portables et mobiles |
| 2.4 | Code mobile |
| 2.5 | Verrouillage de session |
| 2.6 | Terminaison de session distante |
| 2.7 | Contrôle des sessions concurrentes |
| 2.8 | Événements auditables |
| 2.9 | Capacité de stockage des journaux d'audit |
| 2.10 | Réponse aux défaillances de traitement des audits |
| 2.11 | Horodatage |
| 2.12 | Non-répudiation |
Le SR 2.5, verrouillage de session, est celui qui déclenche le plus de discussions en salle de conduite. Un poste opérateur qui se verrouille au bout de quinze minutes est un problème d'exploitation réel. La norme prévoit ce cas : le verrouillage ne doit pas empêcher l'action en situation d'urgence. À traiter en conception, pas en exploitation.
FR 3 — Intégrité du système (9 SR)
| SR | Objet |
|---|---|
| 3.1 | Intégrité des communications |
| 3.2 | Protection contre le code malveillant |
| 3.3 | Vérification des fonctions de sécurité |
| 3.4 | Intégrité du logiciel et de l'information |
| 3.5 | Validation des entrées |
| 3.6 | Sortie déterministe |
| 3.7 | Traitement des erreurs |
| 3.8 | Intégrité de session |
| 3.9 | Protection des informations d'audit |
Le SR 3.6, sortie déterministe, n'a pas d'équivalent en IT. Il exige que le système place ses sorties dans un état prédéfini et sûr quand il ne peut plus fonctionner normalement. C'est une exigence de sûreté autant que de sécurité, et elle illustre bien pourquoi l'IEC 62443 n'est pas une ISO 27001 adaptée.
FR 4 — Confidentialité des données (3 SR)
| SR | Objet |
|---|---|
| 4.1 | Confidentialité de l'information |
| 4.2 | Persistance de l'information |
| 4.3 | Utilisation de la cryptographie |
Trois SR seulement, contre treize pour FR 1. Ce déséquilibre n'est pas un oubli : il traduit l'inversion des priorités en OT. La confidentialité arrive en dernier.
Le SR 4.2 est souvent négligé. Il traite de l'effacement effectif des données sensibles — sur un automate mis au rebut, sur une carte mémoire d'IHM, sur un poste d'ingénierie renvoyé en réparation.
FR 5 — Flux de données restreint (4 SR)
| SR | Objet |
|---|---|
| 5.1 | Segmentation du réseau |
| 5.2 | Protection des frontières de zone |
| 5.3 | Restrictions des communications point à point à usage général |
| 5.4 | Partitionnement applicatif |
Quatre SR, mais c'est le FR qui produit le plus de travail concret. Les renforcements de SR 5.1 vont de la segmentation logique à SL 1 jusqu'à l'isolement physique des réseaux critiques à SL 4.
Le SR 5.2 porte les renforcements les plus structurants : refus par défaut avec autorisation par exception, capacité de fonctionnement en mode îlot, et comportement en cas de panne du dispositif de frontière.
FR 6 — Réponse rapide aux événements (2 SR)
| SR | Objet |
|---|---|
| 6.1 | Accessibilité des journaux d'audit |
| 6.2 | Surveillance continue |
Le FR le plus court, et le plus souvent absent des installations réelles. Le SR 6.2 n'est pas exigé au SL 1 mais devient obligatoire dès le SL 2 — c'est l'une des marches les plus coûteuses de tout le référentiel, parce qu'elle suppose une supervision de sécurité qui n'existe généralement pas côté OT.
FR 7 — Disponibilité des ressources (8 SR)
| SR | Objet |
|---|---|
| 7.1 | Protection contre le déni de service |
| 7.2 | Gestion des ressources |
| 7.3 | Sauvegarde du système de contrôle |
| 7.4 | Restauration et reconstitution |
| 7.5 | Alimentation de secours |
| 7.6 | Paramètres de configuration réseau et de sécurité |
| 7.7 | Fonctionnalité minimale |
| 7.8 | Inventaire des composants du système de contrôle |
Le SR 7.8 est le point de départ réel de toute démarche. Vous ne pouvez pas protéger ce que vous n'avez pas inventorié. C'est aussi la SR sur laquelle la quasi-totalité des installations existantes échoue au premier audit.
Le SR 7.7, fonctionnalité minimale, est celui qui rapporte le plus pour le moins d'effort : désactiver les services inutilisés sur les automates et les switches ne coûte rien et réduit la surface d'attaque immédiatement.
Répartition par exigence fondamentale
| FR | Domaine | Nombre de SR |
|---|---|---|
| FR 1 | Identification et authentification | 13 |
| FR 2 | Contrôle d'utilisation | 12 |
| FR 3 | Intégrité du système | 9 |
| FR 4 | Confidentialité des données | 3 |
| FR 5 | Flux de données restreint | 4 |
| FR 6 | Réponse rapide aux événements | 2 |
| FR 7 | Disponibilité des ressources | 8 |
| Total | 51 |
La répartition raconte quelque chose. Vingt-cinq SR sur cinquante et une portent sur qui accède au système et ce qu'il a le droit d'y faire. Trois seulement portent sur la confidentialité.
Comment s'en servir concrètement
En rédaction de cahier des charges
C'est l'usage le plus rentable. Au lieu d'écrire « le système devra être sécurisé », vous annexez la liste des SR applicables à votre SL cible et vous demandez à l'intégrateur de se positionner sur chacune.
Trois colonnes suffisent : la SR, la réponse du fournisseur — conforme, partiellement conforme, non conforme — et la justification technique.
Vous obtenez un document contractuel, comparable d'une offre à l'autre, et qui rend visibles les écarts avant la commande plutôt qu'après la mise en service.
En évaluation d'un système existant
Même liste, autre usage. Vous parcourez les 51 SR sur une installation en exploitation et vous notez ce qui est en place.
L'écart entre votre SL cible et ce que vous constatez, c'est votre SL atteint. La différence est votre risque résiduel, et elle doit être documentée et acceptée formellement — pas laissée implicite.
Le piège à éviter
Ne confondez pas ce qu'un composant sait faire et ce que le système fait réellement.
Un fournisseur qui annonce un automate « SL 2 capable » vous parle de SL-C, la capacité. Cela ne dit rien de la configuration livrée. Un automate capable d'authentification dont l'authentification est désactivée reste un automate sans authentification.
Le SL atteint se mesure sur l'installation, pas sur la fiche produit.
Ce que la norme ne vous donnera pas
Elle ne vous dit pas quel SL viser. C'est le rôle de l'IEC 62443-3-2, qui définit la méthode d'évaluation de risque par zone. Sans elle, votre SL cible est une intuition.
Elle ne vous donne pas de solutions. Elle énonce des exigences, pas des produits ni des architectures. Deux installations conformes au même SL peuvent être conçues très différemment.
Elle ne traite pas les composants. Pour ce qu'un automate ou un switch doit fournir en propre, il faut l'IEC 62443-4-2.
Elle ne couvre pas l'organisation. Les processus, la formation, la gestion des correctifs relèvent de la catégorie 2.
Questions fréquentes
Combien d'exigences système contient l'IEC 62443-3-3 ?
Cinquante et une, réparties sur les sept exigences fondamentales, chacune assortie de renforcements qui s'ajoutent selon le niveau de sécurité visé.
Faut-il appliquer les 51 SR ?
Oui, dans le sens où elles sont toutes évaluées. Mais ce qui est exigé varie : certaines se limitent à leur exigence de base au SL 1, d'autres ne s'appliquent qu'à partir du SL 2, et les renforcements s'ajoutent progressivement jusqu'au SL 4.
Quelle différence entre l'IEC 62443-3-3 et l'IEC 62443-4-2 ?
La partie 3-3 fixe les exigences au niveau du système, pour l'intégrateur. La partie 4-2 fixe les exigences au niveau du composant, pour le constructeur. Mêmes exigences fondamentales, mêmes niveaux de sécurité, périmètres différents.
Un système peut-il atteindre un SL supérieur à celui de ses composants ?
Oui. L'architecture peut compenser. Un pare-feu de zone, une passerelle unidirectionnelle ou une DMZ peuvent apporter une protection qu'un composant ancien est incapable de fournir seul. C'est même le cas le plus fréquent sur les installations existantes.
Comment savoir quel niveau de sécurité viser ?
Par une évaluation de risque menée zone par zone, selon la méthode de l'IEC 62443-3-2. Le SL cible découle du risque, pas d'une préférence ou d'un budget.
Où trouver la correspondance exacte entre SR et niveau de sécurité ?
Dans le tableau de correspondance des SR et des RE aux quatre niveaux de sécurité, en annexe de la norme. C'est le tableau à consulter avant toute rédaction de spécification.
La norme a-t-elle été corrigée depuis sa publication ?
Oui, sur la SR 3.4. Un exemplaire non corrigé contient un mapping erroné sur cette ligne. Travaillez toujours à partir d'une version intégrant les correctifs publiés.