(Rte-Cyber) NT-DI-CNER-DCCL-PIM-19-00210-Ind.2 RSPACE Specs Cybersécurité Des Lots SAMU-SCU-BCU

Date d’approbation : 23/09/2019
- Date d’applicabilité :
Date de fin de validité :
- NT DI CNER-DCCL-PIM 19 00210
Indice : 2
Projet R#SPACE - Spécifications de cyber sécurité des

équipements des lots SAMU, SCU et BCU.
63 Pages 0 annexes
Documents annulés : [Documents annulés]

Documents de référence : [Doc. de réf.]
Référence fonctionnelle : [Réf. fonctionnelle]
Résumé : [Résumé]
Accessibilité : Filières : Domaine GED :
RTE Métier DI Privé
Domaine professionnel RD
Processus local DEVIN
Centre National Expertise Réseaux

Immeuble WINDOW
7C Place du Dôme
92073 Paris La Défense cedex www.rte-france.com 05-09-00-COUR
NT-DI-CNER-DCCL-PIM-19-00210 Date d’approbation : 23/09/2019
Indice : 2 - Page : 2/63
Projet R#SPACE - Spécifications de cyber sécurité des équipements des lots SAMU, SCU et BCU.
Rédacteurs Vérificateurs Approbateurs

Nom Visa Nom Visa Nom Date/Visa
V. DIEMUNSCH VD V. LEITLOFF VL T. MICHEL TM
B. ROHÉE BR G. DUVERBECQ GD E. DE SÈZE EDS
M. SALL MS [Vérificateur3] [Approbateur3]
Lieu de conservation (ou...) : [Lieu de conservation]

*Le rédacteur s’assure de la validité du contenu du document et de sa conformité aux règles documentaires.
*Le vérificateur dispose des compétences techniques adaptées pour une vérification du contenu du document.
*L’approbateur est une personne autorisée à la publication du document, engageant l’entité. Il s’assure de la faisabilité des instructions décrites
ainsi que de la mise en œuvre des moyens nécessaires et valide la date de mise en application.
DIFFUSION
Pour action Pour information
Direction des Achats : CNER/DCCL :
Mayeul GRAVIER, Vincent BOUSQUET.
Tévy VAY. Jean-Marie BOISSET,
Frédéric FOUSSERET,
Gilles GUILLET,
Tarik MACHKOUR,
Yann LELOUP.
DSIT/DESPA :
Frédéric LENOIR,
Paul RAZANAJATOVO.
HISTORIQUE
Projet ou
Indice Date Rédacteur(s) Modifications
Pour approbation
V. DIEMUNSCH
0 06/05/19 Projet B. ROHÉE
M. SALL
0.1 16/05/19 Pour signature Idem Remarques de Geoffroy et Volker
1 23/05/19 Pour signature Idem Remarques de Timothée et Volker
Mise à jour suite aux retours des
1.2 29/07/19 Projet Idem constructeurs lors du dialogue
compétitif.
2 9/09/2019 Pour signature V. DIEMUNSCH
Copyright RTE. Ce document est la propriété de RTE. Toute communication, reproduction, publication même partielle est
interdite sauf autorisation écrite du Gestionnaire du Réseau de Transport d'Electricité (RTE)
SOMMAIRE
1. Planification ................................................................................................................... 4
1.1 Sans l’Infrastructure de Gestion de Clés de Rte ................................................... 4
1.2 Sécurisation de l’accès au réseau local ............................................................... 5
1.3 Contrôle d’accès aux automates basé sur les rôles .............................................. 5
1.4 Signatures et révocations .................................................................................. 6
1.5 Sécurisation des messages rapides .................................................................... 6
2. ADMS : Administration sécurisée................................................................................... 7
2.1 Description ...................................................................................................... 7
2.2 Exigences fonctionnelles ................................................................................... 7
3. EXPS : Exploitation sécurisée ......................................................................................14
3.1 Description .................................................................................................... 14
3.2 Exigences fonctionnelles ................................................................................. 14
4. GDOI : Service de distribution de clés de session dans un groupe. ..............................18
4.1 Description .................................................................................................... 18
5. NAC : Contrôle d'Accès au Réseau Local du Poste Electrique (802.1X-2010)..............21
5.1 Description .................................................................................................... 21
6. RBAC : Contrôle d'accès basé sur des certificats (62351-8 PUSH model)....................25
6.1 Description .................................................................................................... 25
7. SYSLOG : Collecte des journaux de sécurité ...............................................................33
7.1 Description .................................................................................................... 33
8. TLS : Sécurisation des flux TCP par TLS......................................................................57
8.1 Description .................................................................................................... 57
9. Contraintes ...................................................................................................................61
1. Planification
Dans la suite du présent document, les exigences sont présentées en suivant une logique de
regroupement par fonctions, afin de faciliter la compréhension de la vision globale. Toutefois,
les contraintes industrielles amènent à planifier différentes phases de réalisation de la sécurité
sur site, qui se traduisent par les 5 paquets d’exigences détaillés ci-dessous.
1.1 Sans l’Infrastructure de Gestion de Clés de Rte

Tant que l’infrastructure de gestion de clés de Rte n’est pas en place, la sécurité sera
essentiellement périmétrique c’est-à-dire assurée par les machines de supervision, directement
enrôlée dans l’AD de Rte en non par les automates. Pour les automates, on se contentera de
renforcer les machines, chiffrer les flux d’administration et de remonter les traces de sécurité
(Syslog).
Les exigences du paquet n°1 sont :

RS-5831 ADMS-01 : Chiffrement du flux d'administration
RS-5829 ADMS-02 : Confidentialité et intégrité des flux SNMP de gestion des équipements
RS-6216 ADMS-06 : Port dédié au réseau local d'Administration
RS-6409 ADMS-07 : Déconnexion automatique des sessions administratives des IED
RS-4357 EXPS-04 : Déconnexion automatique des utilisateurs
RS-6303 EXPS-06 : Durcissement des IED contre les cyber-attaques
RS-5907 RBAC-01 : Définition des rôles à Rte
RS-6158 RBAC-02 : Définition des profils. Séparation des rôles et des responsabilités
RS-6160 RBAC-03 : Profils envisagés, rôles incompatibles.
RS-5946 SYSLOG-01 : Système de journalisation de sécurité
RS-5992 SYSLOG-02 : Horodatage des événements
RS-5994 SYSLOG-03 : Source des événements
RS-6163 SYSLOG-04 : Format des messages
RS-6164 SYSLOG-04-01 : Entête d'un message
RS-6165 SYSLOG-04-02 : Corps d'un message
RS-6194 SYSLOG-04-03 : Utilisation éventuelle du champ MSG
RS-6193 SYSLOG-04-04 : Identifiant des événements
RS-6147 SYSLOG-04-05 : Sévérité des événements
RS-6024 SYSLOG-10 : Centralisation des journaux
RS-6027 SYSLOG-11 : Pas de traitement local des journaux
RS-6025 SYSLOG-13 : Modes de transfert et adresses de collecte
RS-6029 SYSLOG-14 : Dimensionnement du stockage local de la journalisation
RS-6028 SYSLOG-15 : Supervision de l’espace de stockage attribué à la journalisation
RS-6315 SYSLOG-22 : informations sur les GOOSE et les Sampled Values
RS-6537 SYSLOG-25 : informations génériques
RS-6538 SYSLOG-26 : Informations relatives à la sécurité des documents XML
1.2 Sécurisation de l’accès au réseau local

Après la mise en place d’une Infrastructure de Gestion de Clés à Rte, le plus important est la
sécurisation de l’accès au réseau local (aux deux réseaux d’administration et d’exploitation).
Pour cela on utilise 802.1x-2010 avec MACsec, qui permet de sécuriser tous les protocoles
Ethernet et IP. Notez bien que sans MACsec cette sécurité est inopérante car des attaques
faciles en intermédiaire (« Man-In-The-Middle ») sont possibles, toutefois si l’authentification
par 802.1x est validée sur les sites pilotes, un simple changement de matériels (commutateurs
et cartes réseau) permettra de mettre en œuvre MACsec.

RS-6224 ADMS-05 : Enrôlement des équipements dans l'IGC
RS-6211 ADMS-05-01 : support en priorité du protocole d'enrôlement EST
RS-6212 ADMS-05-02 : Support du protocole d'enrôlement SCEP
RS-6129 NAC-01 : Version de 802.1X
RS-6130 NAC-02 : Authentification par EAP/TLS
RS-6134 NAC-03 : Mécanisme de confidentialité et d'intégrité des trames Ethernet (MACsec,
IEEE 802.1AE)
RS-6137 NAC-04 : Nécessité des VLAN (IEEE 802.1Q)
RS-6132 NAC-05 : VLAN dédié à l'enrôlement.
RS-6437 NAC-06 : Support de la redondance du réseau en PRP ou HSR
RS-6317 SYSLOG-20 : informations sur la mise en œuvre des certificats
1.3 Contrôle d’accès aux automates basé sur les rôles
L’étape suivante est de mettre en place de contrôle d’accès basé sur les rôles (RBAC) sur les
automates eux-mêmes. Ce mécanisme est considéré par la CEI 62351 comme l’ultime barrière
dans la défense en profondeur du poste électrique contre les cyber-attaques. Il est basé sur
TLS et sa mise en place inclus donc les autres usages de TLS (sécurisation de l’administration,
des traces de sécurité, etc.).

RS-6221 EXPS-01 : Sécurisation des flux MMS
RS-6222 EXPS-03 : Utilisation de certificats pour l'authentification
RS-6157 RBAC-04 : RBAC de base (Core RBAC Model)
RS-6162 RBAC-05 : Approche par sessions TLS
RS-6161 RBAC-06 : Profile A de la norme IEC 62351-8.
RS-6016 SYSLOG-12 : Sécurisation du transport des journaux
RS-6314 SYSLOG-21 : Informations sur le Contrôle d'Accès (RBAC)
RS-6540 SYSLOG-23 : Informations relatives à TLS
RS-6152 TLS-01 : Versions du protocole TLS
RS-6169 TLS-02-01 : Suites cryptographiques d'intégrité seule, pour TLS 1.2
RS-6150 TLS-02-02 : Suites cryptographiques de chiffrement pour TLS 1.2
RS-6155 TLS-02-03 : Extensions nécessaires pour TLS 1.2
RS-6173 TLS-03-02 : Suites cryptographiques de chiffrement pour TLS 1.3
RS-6156 TLS-03-03 : Détails pour TLS 1.3
1.4 Signatures et révocations

Afin d’éviter l’installation de logiciels (firmware) non qualifiés par Rte, ou de configurations non
validées par Rte, des signatures cryptographiques seront exigées en préalable à un installation.
D’autre part, le certificat d’une machine désinstallée ou volée pourra être révoqué.

RS-6198 ADMS-03 : Vérification des signatures des logiciels
RS-6207 ADMS-04 : Vérification de la signature des fichiers de configuration (FCPE)
RS-6440 ADMS-09 : Configuration du répondeur OCSP de validité des certificats
RS-6442 ADMS-10 : Configuration du point de distribution de la liste de révocation des
certificats (CRL)
RS-6167 TLS-04-01 : Support du protocole OCSP par les clients TLS
RS-6168 TLS-04-02 : Support du protocole OCSP par les serveurs TLS
1.5 Sécurisation des messages rapides

Les messages rapides de bas niveau, directement sous forme de trames Ethernet (les GOOSE
et SV de la CEI 61850), peuvent être sécurisés par l’application de mécanismes ad-hoc définis
par la CEI 62351-6. Toutefois, ces mécanismes demandent des évolutions matérielles compte-
tenu des performances demandées et il n’y a pas encore d’implémentations de référence chez
les constructeurs. C’est pourquoi, nous avons choisi de mettre ces exigences en dernier dans
l’ordre de réalisation.

RS-6205 EXPS-02 : Sécurisation des Sampled Values et GOOSE
RS-6175 GDOI-01 : Protocole IKE v1, authentification des clients.
RS-6177 GDOI-02 : IKE v1, Modes
RS-6179 GDOI-03 : IKE v1, Groupes de Galois
RS-6180 GDOI-04 : IKE v1, algorithme de chiffrement
RS-6181 GDOI-05 : IKE v1, condensat utilisé pour l'intégrité
RS-6182 GDOI-06 : IKE v1, fonctions pseudo-aléatoires
RS-6174 GDOI-07 : Support de l'acquittement du changement de clé de groupe
RS-6188 GDOI-08 : Utilisation d'OCSP par le serveur et les clients
RS-6190 GDOI-09 : Configuration des clients GDOI
RS-6151 TLS-03-01 : Suites cryptographiques d'intégrité seule, pour TLS 1.3
2. ADMS : Administration sécurisée

2.1 Description
Priorité Phase 1 - Pilotes Fonction modifiée le 2019-07-25

Key RS-6196
Répond aux besoins RS-5826 - Confidentialité et intégrité des systèmes d'administration
RS-6594 - Configuration de sécurité
RS-5906 - Contrôle d'accès basé sur les rôles (RBAC)
RS-5797 - Maintien en Conditions Opérationnelles de Sécurité (MCO et
MCS)
Est impacté par les RS-5959 - ANSSI-01 : Non-réplication des mots de passe nationaux
contraintes RS-6171 - ANSSI-02 : Choix et dimensionnement des mécanismes
cryptographiques
RS-5936 - ANSSI-03 : Recommandations sur TLS
RS-6329 - ANSSI-04 : Recommandations sur SSH
RS-6340 - ANSSI-05 : Recommandations pour le cloisonnement du
système
RS-5799 - LPM-10 : Règle relative à la gestion de crises
RS-5803 - LPM-14 : Règle relative aux comptes d’administration
RS-5804 - LPM-15 : Règle relative aux systèmes d’information
d’administration
RS-5805 - LPM-16 : Règle relative au cloisonnement
RS-5806 - LPM-17 : Règle relative au filtrage
RS-5808 - LPM-19 : Règle relative à l’installation de services et
d’équipements
RS-5809 - LPM-20 : Règle relative aux indicateurs
Est lié aux fonctions RS-6206 - ADMIN-Fonctions du Poste Administration R#SPACE
Les protocoles d'administration doivent assurer :

 l'intégrité des communications,
 une authentification sûre des utilisateurs,
 le respect des limitations d'accès liées aux rôles des utilisateurs (RBAC, Role Based
Access Control),
 la confidentialité des communications,
 la légitimité des logiciels (firmware) et des configurations déployées (fichiers FCPE).
2.2 Exigences fonctionnelles
ADMS-01 : Chiffrement du flux d'administration RS-5831

Dernière modification : 2019-07-25
Un même équipement peut avoir plusieurs flux d'administration sécurisés séparément. Chaque
flux d'administration sera sécurisé par chiffrement, au moyen d'une des deux options
suivantes :
 préférentiellement par TLS 1.3. Toutefois TLS 1.2 est toléré sous réserve de suivre les
prescriptions de l'ANSSI en matière de suite de chiffrement (cf. RS-5936 - ANSSI-03 :
Recommandations sur TLS), reprises dans RS-6149 - TLS : Sécurisation des flux TCP
par TLS. Les rôles des utilisateurs seront portés par un attribut du certificat utilisé pour
authentifier la connexion (cf. RS-5825 - RBAC : Contrôle d'accès basé sur des certificats
(62351-8 PUSH model)).
 sinon par SSH en utilisant l'authentification par clé publique, conformément aux
prescriptions de l'ANSSI (cf. RS-6329 - ANSSI-04 : Recommandations sur SSH). Les
rôles des utilisateurs devront être disponibles pour les équipements au moyen du
protocole LDAP (cf. RS-6210 - ADMS-08 : Clés publiques pour l'authentification sur les
équipements de réseau).
Remarque :
Sur les premiers sites pilotes, pour utiliser TLS en l'absence d'IGC, il faudra installer le certificat
auto-signé du Poste d'Administration lors de la configuration de l'IED pour s'assurer que lui
seul puisse administrer l'IED. Le logiciel propre au constructeur installé sur le poste
d'administration devra ignorer les contrôles d'identification de l'IED, car en l'absence
d'enrôlement de l'IED, son certificat sera générique.
ADMS-02 : Confidentialité et intégrité des flux SNMP de gestion des RS-5829

équipements
En cas d'utilisation de SNMP pour superviser et administrer des équipements (commutateurs

du réseau, voire IED…) les mesures de sécurités suivantes devront être respectées. Il faut
noter qu'il y a deux options (Security Model en jargon SNMP) possibles pour assurer la
sécurité : "Transport Security Model" et "User Security Model". Le constructeur d'équipement
(IED) est libre d'en choisir une des deux, à condition qu'elle soit configurée de façon
satisfaisante du point de vue de la sécurité, en suivant les recommandations ci-dessous. Les
machines de l'infrastructure de supervision de Rte, clientes de SNMP, devront supporter les
deux options. Rte a une préférence pour TSM qui est plus moderne.
Utilisation du "Transport Security Model" (TSM)

Le "Transport Security Model" est défini dans le RFC 5591, et se propose de gérer la sécurité
au niveau de la couche transport et non au niveau du protocole SNMP, s'appuyant sur des
couches de transport sécurisées existantes et matures. Les deux options existantes sont le
transport du protocole SNMP sur SSH (RFC 5592) et le transport de SNMP sur TLS/DTLS (RFC
6353).
Est imposée :
 l'utilisation de TLS en suivant les exigences exprimée dans RS-6149 - TLS :
Sécurisation des flux TCP par TLS.
Est interdite :
 l'utilisation de SSH, pour sécuriser SNMP, car cela imposerait des contraintes trop
fortes, soit organisationnelles (distribution des empreintes de clés publiques de tous
les équipements devant s'y connecter), ou le déploiement de DNS avec DNSSEC
(pour l'intégrité des champs SSHFP). De plus, comme de toute façon une IGC devrait
être utilisée étant donné les autres mesures de sécurité mises en place, le transport
sur SSH ne faciliterait en aucune façon le déploiement.
Utilisation du "User Security Model" (USM)

Le "User Security Model" sécurise le protocole en intégrant directement de la cryptologie au
protocole SNMP lui-même.
Sont imposées :
 l'utilisation d'authentification basée sur HMAC-SHA-2 (standardisée par le RFC 7630),
 la confidentialité basée sur AES (RFC 3826).
Sont interdites :
 l'utilisation de mécanismes d’authentification basés sur MD5 et SHA-1,
 l'utilisation de mécanismes de confidentialité basés sur Triple-DES.
ADMS-03 : Vérification des signatures des logiciels RS-6198

En introduction, nous présentons les principes du mécanisme de signature des logiciels :

 La signature numérique du développeur des logiciels (le constructeur de l'équipement),
est vérifiée par les IED (ou leur logiciel d'administration), en préalable à l'installation.
Ceci vise à se protéger de l'installation d'un logiciel (firmware) modifié par un attaquant
sur un IED.
 La contre-signature par Rte des logiciels, effectuée par le responsable de la qualification
à l'issue des tests fonctionnels et de sécurité, signifie qu'un logiciel est autorisé en
production. Le certificat de signature utilisé par Rte devra être configuré soit dans l'IED,
soit dans son logiciel d'administration, de façon à ce que la contre-signature soit vérifiée
avant même la vérification de la signature du constructeur.
 Le retour à une version logicielle dont la contre-signature par Rte est antérieure à la
date de contre-signature de la version installée est interdit, afin de se prémunir contre
les attaques basées sur le retour à une version antérieure vulnérable. Si un besoin
légitime de retour en arrière est avéré, il faudra à nouveau contresigner ladite version,
afin de le permettre (une procédure d'urgence devra exister pour répondre aux
contraintes opérationnelles).
Le bénéfice majeur de cette mesure est un contrôle technique par l'IED qui garantit une double
validation effective par Rte : d'une part la validation de la personne appliquant le changement
(exploitant), et d'autre part la validation de la personne ayant validé le logiciel (qualification).
Les équipements (IED) devront, lors d'une mise à jour logicielle (firmware),
respecter les exigences suivantes :
 vérifier que le fichier est (contre-)signé par Rte, par une clé préalablement autorisée,
afin de s'assurer qu'il a été qualifié pour un déploiement en production.
 vérifier que la date de contre-signature par Rte est postérieure à la date de signature
de la précédente installation.
 Les deux formats de signature utilisés par Rte sont CMS (RFC 5652) et COSE (RFC
8152). L'IED doit supporter la vérification d'au moins un des deux formats de signature,
afin que l'infrastructure de Rte puisse générer une signature qui convienne à l'IED.
 La clé de signature de Rte aura l'attribut PKIX Extended Key Usage "Code signing" (OID
1.3.6.1.5.5.7.3.3).
 Les IED devront refuser le positionnement d'une clé ne possédant pas cet attribut.
 Finalement, vérifier que le fichier est signé par le constructeur, donc produit par celui-
ci, potentiellement avec un format de signature qui lui est propre.
ADMS-04 : Vérification de la signature des fichiers de configuration RS-6207

(FCPE)
Les équipements (IED) ou leur logiciel d'administration, devront, lors d'une mise à jour de leur
configuration :
 vérifier que le fichier de configuration (FCPE) est signé par Rte, par une clé
préalablement autorisée, afin de s'assurer qu'il a été qualifié pour un déploiement en
production.
 Les deux formats de signature utilisés par RTE sont CMS (RFC 5652) et COSE (RFC
8152). l'IED doit supporter la vérification d'au moins un des deux formats de signature,
afin que l'infrastructure de Rte puisse générer une signature qui convienne à l'IED.
Le bénéfice majeur de cette mesure est un contrôle technique par l'IED garantissant une
double validation effective à Rte : non seulement de la personne appliquant le changement
(exploitant ou maintenance), mais aussi de la personne en charge de la qualification de la
configuration.
ADMS-05 : Enrôlement des équipements dans l'IGC RS-6224

Tous les mécanismes de sécurité de la norme IEC 62351 retenus reposent sur un certificat et
une clé privée associée sur chaque IED, afin qu'il puisse s'authentifier auprès de ses pairs. La
norme propose quatre mécanismes d'enrôlement des IED dans l'IGC, mais après une étude
des fonctionnalités offertes par ceux-ci, une revue de ceux qui bénéficiaient effectivement d'un
support logiciel, et le dialogue compétitif, Rte a choisi de n'en retenir que deux.
Les protocoles retenus sont EST et SCEP :

 Les IED doivent supporter prioritairement le protocole EST. À défaut, le seul protocole
toléré sera SCEP.
 Les autorités d'enregistrement de Rte supporteront les deux.
 Le support de l'enrôlement de certificats ECDSA (basé sur une cryptographie par
courbes elliptiques ECC) est impératif pour les deux protocoles car il n'est pas prévu
de support des clés RSA.
Authentification de la machine :
 soit au moyen d'un certificat du constructeur pré-installé (la machine ayant été enrôlée
préalablement dans l'IGC du constructeur). Le serveur d'enrôlement de Rte fera
confiance à l'IGC du constructeur et se basera sur les informations du certificat pour
authentifier la machine.
 soit au moyen d'un secret partagé (un mot de passe d'enrôlement propre à la machine)
qui aura été pré-installé par le constructeur. Au préalable, le constructeur aura transmis
à l'IGC de Rte, par un canal sécurisé défini conjointement, les machines livrées avec
les couples (numéro de série, mot de passe unique).
Autant que possible, l'enrôlement sera automatique : à la connexion au réseau, la machine

non enrôlée cherchant à se connecter à une adresse IP d'enrôlement prédéfinie par Rte.
ADMS-05-01 : support en priorité du protocole d'enrôlement EST RS-6211

EST est un des protocoles d'enrôlement dans une IGC recommandés par l'IEC 62351. Il
commence à être largement implémenté, même si le support de SCEP est probablement encore
plus élevé.
EST le protocole le plus consensuel au sein de l'IETF, et son importance ne fera qu'augmenter,
son support est donc important pour l'interopérabilité à long terme. Par ailleurs, EST étant
relativement récent, les implémentations ne souffrent généralement pas de limitations vis à
vis du support des clés ECDSA.
R#SPACE pourra utiliser des fonctionnalités présentes dans EST mais pas dans SCEP, telle que
la demande de révocation à l'initiative d'un équipement enrôlé, utile par exemple en cas de
dépose (decommissioning) d'un équipement. Toutefois, il n'y a pas d'exigence de Rte de
support impératif de la révocation par EST.
Le support d'EST est donc demandé en priorité par rapport au support de SCEP.
ADMS-05-02 : Support du protocole d'enrôlement SCEP RS-6212

SCEP est un des protocoles d'enrôlement dans une IGC recommandé par une IEC 62351, et
est de loin le protocole d'enrôlement le plus répandu. Il souffre néanmoins d'une absence de
standardisation (un RFC documentant les pratiques existantes tardant à sortir). Ceci peut
entrainer des problèmes d’interopérabilité entre une implémentation ancienne et une
implémentation moderne configurée pour rejeter les pratiques obsolètes.
Des implémentations anciennes souffrent de limitations, vis à vis de l'emploi de pratiques
cryptographiques modernes, que ce soit au niveau du protocole lui-même ou dans le support
de clés autres que RSA, spécifiquement ECDSA.
Pour le protocole d'enrôlement SCEP il est donc demandé :

 le support de clés ECDSA et non seulement RSA,
 le support d'AES dans la partie CMS protégeant les échanges.
Rappelons que le support de SCEP est toléré, mais il est demandé en priorité le support du
protocole EST (cf. RS-6211 - ADMS-05-01 : support en priorité du protocole d'enrôlement
EST).
ADMS-06 : Port dédié au réseau local d'Administration RS-6216

Le système R#SPACE vise la ségrégation des flux d’administration issus du Poste

d'Administration, sur un réseau local (LAN) dédié à l'administration. Le but est qu'un outil
d'administration ne puisse pas envoyer des commandes sur le réseau d'exploitation. Pour cela,
il est impératif que les IEDs mettent à disposition une interface réseau à part (voir détails dans
l'exigence RS-5019 - LAN-03 Interface des équipements terminaux permanent). Les flux
d'administration attendus seront :
 ceux entre les IEDs et leur logiciel d'ingénierie, propre à leur constructeur,
 les traces des journaux de sécurité (Syslog),
 les éventuels flux de supervision SNMP,
 les messages du protocole d'enrôlement et de renouvellement des certificats.
Pour des raisons de sécurité, il est interdit que l'interface d'administration intègre un serveur
IEC 61850 (MMS, GOOSE et SV) ou qu'elle mettre à disposition les données et commandes du
procédé par n'importe quel autre moyen (par exemple un autre protocole de SCADA).
ADMS-07 : Sessions administratives des IED, RBAC et temporisation RS-6409

Pour l'établissement d'une connexion d'administration sur l'équipement, conformément au

contrôle d'accès basé sur les rôles (RS-5825), seul un certificat porteur d'un rôle
d'administrateur (et sans rôles d'exploitation, cf. RS-6160 - RBAC-03 : Profils envisagés, rôles
incompatibles) sera autorisé comme authentifiant de connexion.
Si un serveur sert d'intermédiaire entre l'utilisateur et l'IED pour la session d'administration
(cas d'un logiciel d'administration exposant une API REST), alors c'est au serveur intermédiaire
de vérifier le rôle administrateur de l'utilisateur et de journaliser les opérations d'administration
avec le nom de l'utilisateur. Le serveur se connectera à l'IED en présentant un certificat de
machine possédant le rôle administrateur (voir RS-6532 - IGC-05-09 : Gabarit de certificat de
machine).
Sans activité de l'utilisateur, la session d'administration interactive d'un IED (web ou autre, par
exemple une session SSH) doit se déconnecter automatiquement au bout d’un temps
configurable dit « temporisation de déconnexion locale automatique de l'administration » et
clore la session.
Valeurs Valeur par

Libellé - Donnée de configuration Paramètre
admissibles défaut
Temporisation de déconnexion 0 à 2h, pas de 5
15 min Oui
automatique min
Note : la valeur 0 pour la temporisation signifie que le mécanisme de déconnexion

automatique est hors service, ou qu’il a une temporisation infinie.
ADMS-09 : Configuration du répondeur OCSP de validité des certificats RS-6440

Le répondeur OCSP (cf. RS-6123 - IGC 11 : Répondeur OCSP de validité des certificats) utilisé
par les mécanismes TLS, GDOI ou autre, devra être configurable sur les IED. En effet, même
si un répondeur OCSP peut être spécifié dans le certificat lui-même, celui-ci ne sera pas
forcément disponible localement. Dans le cas où et un répondeur OCSP est spécifié et dans la
configuration de l'IED et dans le certificat, le répondeur à contacter en premier est celui spécifié
par la configuration (sur le serveur local), et en cas d'indisponibilité de celui-ci, celui spécifié
par le certificat (sur le serveur national distant).
ADMS-10 : Configuration du point de distribution de la liste de RS-6442

révocation (CRL)
Le point de distribution de la liste de révocation des certificats, (CRL pour Certificate Revocation
List, cf. RS-6116 : IGC-10 Révocation du certificat d'un utilisateur ou d'une machine), utilisée
pour valider les certificats en cas d'indisponibilité du répondeur OCSP (cf. RS-6440) devra être
configurable sur les IED, que ce soit dans un contexte d'utilisation de TLS, GDOI ou de tout
autre mécanisme utilisant des certificats.
En effet, même si un point de distribution de liste de révocation (CRL) peut être spécifié dans
le certificat lui-même, celui-ci ne sera pas forcément disponible et local au poste électrique.
Dans le cas où et un point de distribution est spécifié et dans la configuration de l'IED et dans
le certificat, le point à utiliser en premier est celui spécifié par la configuration (sur le serveur
local), et en cas d'indisponibilité de celui-ci, celui spécifié par le certificat (sur un serveur
national distant).
3. EXPS : Exploitation sécurisée

3.1 Description
Priorité Phase 1 - Hors Fonction modifiée le 2019-07-25
Pilotes
Key RS-6202
Répond aux besoins RS-5879 - Authentification efficace et robuste des utilisateurs
RS-5830 - Cloisonnement du poste électrique et filtrage des flux
RS-5821 - Confidentialité des mesures physiques classées ICS
RS-5877 - Intégrité de la synchronisation temporelle des équipements
RS-5751 - Intégrité des flux d'informations du poste électrique
Est impacté par les RS-5959 - ANSSI-01 : Non-réplication des mots de passe nationaux
contraintes RS-5800 - LPM-11 : Règle relative à l’identification
RS-5801 - LPM-12 : Règle relative à l’authentification
RS-5802 - LPM-13 : Règle relative aux droits d’accès
RS-5807 - LPM-18 : Règle relative aux accès à distance
RS-5820 - CRE-01 : Confidentialité des Informations Commercialement
Sensibles
Est lié aux fonctions
Cette fonction vise à regrouper les exigences de sécurité concernant les messages et les
systèmes nécessaires aux :
 fonctions de protection,
 fonctions d'exploitation,
 commandes provenant de la conduite ou de la téléconduite,
 informations remontant aux systèmes de conduite et de maintenance.
EXPS-01 : Sécurisation des flux MMS RS-6221

Les flux MMS sont utilisés dans la norme IEC 61850-8-1 pour le transfert des commandes et
des informations entre les calculateurs (IED) et le système de supervision (passerelle de
téléconduite, poste opérateur, poste d'administration, passerelle de supervision...).
Exigences :
1. Afin de garantir l'intégrité de ces flux, les connexions TCP nécessaires à MMS sont
sécurisées par TLS 1.2, en authentification seule, en suivant la norme IEC 62351, cf.
RS-6149 - TLS : Sécurisation des flux TCP par TLS.
2. Un contrôle d'accès basé sur les rôles (RBAC) est implémenté sur l'IED serveur, en
utilisant les rôles transmis par le certificat du client (passerelle, poste opérateur...), cf.
RS-5825 - RBAC : Contrôle d'accès basé sur des certificats (62351-8 PUSH model).
3. L'IED doit supporter 10 connexions MMS simultanées (a minima). En cas d'atteinte de
la limite du nombre de connexions simultanées, une stratégie d'évitement du déni de
service doit être implémentée, cf. RS-4357 - EXPS-04 : Déconnexion automatique des
utilisateurs.
EXPS-02 : Sécurisation des Sampled Values et GOOSE RS-6205

Le mécanisme qui doit être mis en œuvre pour garantir l'intégrité des SV et des GOOSE est
celui décrit dans l'IEC 62351-6. Il repose sur un code d'authentification (MAC, Message
Authentication Code), ici HMAC-SHA-256 ou AES-CMAC. Le choix entre les deux algorithmes
cryptographiques sera réalisé à la configuration de l'IED, et sera le même pour tous les IED
du site, de façon à ce que, si le traitement des SV et GOOSE est réalisé par une couche
matérielle, celle-ci n'ait pas à supporter les deux algorithmes simultanément.
La clé de session est obtenue et renouvelée par le mécanisme d'échange de clés de groupe,
cf. RS-5754 - GDOI : service de distribution de clés de session dans un groupe. En particulier,
le mécanisme d'anti-rejeu prévu par l'IEC 62351-6 devra impérativement être implémenté.
Remarques :
Le mécanisme initial de signature directe par la clé privée, décrit dans des versions antérieures
du standard l'IEC 62351-6, n'est pas retenu, car il est trop coûteux en calcul.
Notons que les Sampled Values peuvent servir à reconstituer les courbes de charges de clients,
lesquelles sont des Informations Commercialement Sensibles (ICS). Il conviendrait donc de les
chiffrer, cf. RS-5820 - CRE-01 : Confidentialité des Informations Commercialement Sensibles.
Toutefois, il n'y a pas pour l'instant, à notre connaissance, de mécanisme de chiffrement des
SV disponible dans la norme. D'autre part, les contraintes en matière de puissance de calcul
sont jugées aujourd'hui trop importantes pour les matériels actuels. Mais ce point pourra
évoluer au cours du projet R#SPACE.
EXPS-03 : Utilisation de certificats pour l'authentification RS-6222

Afin de répondre aux exigences de disponibilité de l'authentification sur les machines du fond
de poste (poste opérateur et poste d'administration) en situation de crise grave (perte des
réseaux de télécommunication, perte des centres de données nationaux, perte fonctionnelle
de l'Active Directory industriel...), il est nécessaire que les utilisateurs de ces machines puissent
s'authentifier au moyen d'un badge porteur de leur identité de de leurs rôles.
L'IGC centralisée de Rte créera un certificat X.509 avec l'identité et les rôles de la personne,
tirés de l'AD, au moment de l'attribution ou du renouvellement du badge. Puis le certificat sera
stocké dans le badge, avec la clé privée associée, dans la carte à puce du badge, pour
permettre une authentification par réponse à un défi (cf. RS-5770 - IGC-08-01 :
Authentification par badge avec carte à puce).
La session ouverte sur le PO ou le PA utilisera le certificat de deux manières :

1. les rôles permettront de donner des droits d'activer des vues et des commandes sur la
machine elle-même.
2. le certificat sera transmis en tant que certificat de client à l'établissement de la
connexion avec un IED.
Le serveur de sécurité du site maintiendra une liste des badges révoqués émise par l'IGC. Pour
limiter la taille de cette liste on jouera sur la durée de validité du certificat du badge
(typiquement 1 à 2 ans), cf. RS-6123 - SRV-01 et RS-6535 - SRV-02.
Les badges seront des cartes à puce compatibles avec le système de contrôle d'accès des
grands sites, CARTESE (technologie MIFARE DESFire EV1) et avec le SmartCardLogon. Un
second facteur d'authentification par code PIN sera ajouté pour la fonction Smart Card,
idéalement il sera le même que le code PIN de CARTESE.
Exigences :
 Les IED devront mettre en œuvre l'authentification par certificat et le RBAC décrit dans
la fonction RS-5825 - RBAC : Contrôle d'accès basé sur les certificats (IEC 62351-8
PUSH model).
 L'utilisation de mots de passe locaux doit être désactivée, car elle n'est pas gérable
industriellement sur les sites.
EXPS-04 : Déconnexion automatique des utilisateurs RS-4357

Pour les IHM :

Sans activité de l'utilisateur, la session locale doit se déconnecter automatiquement au bout
d’un temps configurable dit « temporisation de déconnexion automatique » et clore la session.
L’identifiant de l’utilisateur précédent n’est plus visible. Aussi, pour toute nouvelle tentative de
connexion :
 on demande l’identification et l’authentification d’un utilisateur, et non seulement
l’authentification de l’utilisateur déconnecté,
 la vue présentée est la vue par défaut et non la vue affichée avant la déconnexion.
Pour les connexions MMS :

 une connexion inactive pendant la durée de la « temporisation de déconnexion
automatique », doit être fermée.
 lorsque le nombre maximum de connexions simultanées est atteint, la demande validée
d'ouverture d'une nouvelle connexion entraîne la coupure d'une connexion existante,
pour éviter un déni de service. Par exemple la connexion dont la dernière utilisation
est la plus ancienne, ou alors une au hasard.
Libellé - Donnée de Valeurs Valeur par
Paramètre
configuration admissibles défaut
Temporisation de déconnexion 0 à 2h, pas de 5
15 min Oui
automatique min
Note : la valeur 0 pour la temporisation signifie que le mécanisme de déconnexion
automatique est hors service, ou qu’il a une temporisation infinie.
EXPS-06 : Durcissement des IED contre les cyber-attaques RS-6303

Les IED devront être durcis contre les cyber-attaques, en appliquant notamment la démarche
suivante :
 Réduction de la surface d'attaque : toutes les interfaces exposées devront être

justifiées par des exigences fonctionnelles de Rte, et les interfaces non nécessaires
devront être désactivées (exemple, interface SSH si le mode d'administration d'un
équipement est par un serveur Web).
 Application du principe de privilège minimal : les différents composants devront avoir
les droits minimaux leur permettant d'effectuer leur tâche.
 Tous les secrets d'authentification présents sur les IED devront être indiqués à Rte,
effaçables et changeables par Rte.
 S'il devait y avoir des stockages de mot de passe sur les IED, à destination
d'authentification d'utilisateurs, leur stockage devra être basé sur un mécanisme
d'empreinte robuste.
 Le démarrage devra garantir l'intégrité du logiciel (firmware) chargé, et son
authenticité.
 La mémoire de masse devra être chiffrée et son intégrité garantie avec un secret
accessible au seul IED, pour éviter que des données sensibles puissent être extraites
d'un IED éteint ou déposé ("décommissionné").
Dans le cas où une instance de Linux tourne sur un IED :

 Chiffrement intégral des supports permanents du système de fichier de façon à garantir
intégrité et confidentialité, en utilisant par exemple LUKS ou équivalent, avec une clé
stockée localement sur une puce TPM.
 Application du principe de privilège minimal pour les applications, qui devront tourner
sous des utilisateurs dédiées, et renoncer à leurs privilèges dès que possible.
L'utilisation de "capacités" (capabilities en anglais) est recommandée pour éviter
qu'une application ait besoin des droits de super-utilisateur.
EXPS-07 : Durcissement des machines Linux contre les cyberattaques RS-6306

Les machines Linux (en particulier celles de fond de poste) doivent être durcies contre les
cyberattaques, en appliquant a minima les mesures suivantes :
 Désactivation de toute interface externe de l'Intel Management Engine (ME) ou de
l'AMD Platform Security Processor (PSP) ou autre solution équivalente.
 Positionnement d'un mot de passe fort et diversifié au niveau UEFI pour empêcher le
changement des paramètres de démarrage.
 Interdiction de démarrage (boot) sur un média autre que la mémoire de masse interne
au niveau UEFI.
 Activation du démarrage (boot) sécurisé UEFI (implique l'ajout de clé Rte au niveau
UEFI et la signature du bootloader par Rte).
 Chiffrement intégral des supports permanents du système de fichier de façon à garantir
intégrité et confidentialité, en utilisant LUKS ou équivalent, avec une clé stockée
localement sur une puce TPM.
 Application du principe de privilège minimal pour les applications, qui devront tourner
sous des utilisateurs dédiés, et renoncer à leurs privilèges dès que possible. L'utilisation
de "capacités" (capabilities en anglais) est recommandée pour éviter qu'une application
ait besoin des droits de super-utilisateur.
4. GDOI : Service de distribution de clés de session dans

un groupe.
4.1 Description

Pilotes
Key RS-5754
Répond aux besoins RS-5751 - Intégrité des flux d'informations du poste électrique
Est impacté par les RS-6171 - ANSSI-02 : Choix et dimensionnement des mécanismes
contraintes cryptographiques
Est lié aux fonctions RS-6536 - SRV : Serveur local de fonctions de sécurité
Pour répondre aux exigences de sécurisation des messages Ethernet portant les grandeurs
physiques échantillonnées et les ordres de déclenchement (cf. RS-6205 - EXPS-02 :
Sécurisation des Sampled Values et GOOSE), la CEI 62351-6 propose un mécanisme
garantissant :
 soit uniquement l’intégrité des messages,
 soit à la fois l'intégrité et la confidentialité des messages.
Le mécanisme de vérification de l'intégrité est basé sur la protection des trames GOOSE/SV
par un code d’authentification (Message Authentication Code, MAC), calculé par une fonction
de hachage avec une clé symétrique de session partagée entre l’émetteur et les abonnés. La
clé de session est distribuée par le KDC (Key Distribution Center) aux machines du groupe par
le protocole GDOI (Group Domain of Interpretation), dédié au partage de clés symétriques,
qui est standardisé par le RFC 6407. L'utilisation de GDOI en environnement CEI 61850 est
standardisée par la CEI 62351-8.
GDOI permet de partager facilement une clé de session dans un groupe de machines
possédant chacune une clé privée et un certificat de clé publique associée, et offre un
mécanisme de renouvellement rapide permettant d’exclure rapidement un équipement
compromis (en ne l’informant pas de la nouvelle clé). Des valeurs spécifiques aux GOOSE/SV
ont été standardisées par le RFC 8052. GDOI est basé sur IKE (Internet Key Exchange), un
protocole d’établissement de liens sécurisés (SA) utilisé dans la suite IPsec, et plus précisément
sur sa version 1. Notons que dans le contexte d'IPsec, la version 1 est en fait obsolète et
remplacée par IKE v2.
GDOI-01 : Protocole IKE v1, authentification des clients. RS-6175

IKEv1 assure l'authentification des parties prenantes et la négociation de clés dans GDOI.
Authentification des clients :
 Les équipements et le KDC GDOI doivent supporter de l'authentification par certificats
X509v3.
 Les équipements et le KDC GDOI doivent supporter à la fois des clés ECDSA et des
clés RSA.
 Les équipements et le KDC GDOI doivent supporter a minima les tailles de clés RSA
2048, 3072 et 4096 bits.
 Le rejet des clés RSA de moins de 2048 bits doit être configurable (même si en pratique
l'IGC ne devrait pas en émettre).
 Le rejet des clés dont le certificat utilise le MD5 ou SHA1 doit pouvoir être configuré
(même si en pratique l'IGC ne devrait pas en émettre).
GDOI-02 : IKE v1, Modes RS-6177

IKEv1 est un protocole en deux phases (appelée ici 1 et 2). La phase 1 peut être effectuée de
deux façons, appelées "Main Mode" et "Aggressive Mode".
 Les équipements et le KDC GDOI doivent supporter le "Main Mode" lors de la phase
1 de la partie IKEv1 de GDOI.
 Les équipements et le KDC GDOI peuvent optionnellement supporter le "Aggressive
Mode" lors de la phase 1 de la partie IKEv1 de GDOI.
GDOI-03 : IKE v1, Groupes de Galois RS-6179

L'établissement de la clé de session se fait par l'algorithme de Diffie-Hellman sur un groupe de

Galois. L'annexe B du RGS de l'ANSSI, dans sa règle "RecomLogp-1", demande l'utilisation
d'un groupe d'entiers d'une taille supérieure ou égale à 3072 bits pour les agréments de clés.
Ceci impose donc :

 Le support obligatoire du groupe MODP (identifiant 15), avec des entiers sur 3072
bits tel que décrit dans le RFC 3526.
 Le support optionnel des groupes de tailles supérieures (id 16, 17 et 18).
 La possibilité de désactiver le support des groupe de taille inférieure (2048 et moins,
id 14).
GDOI-04 : IKE v1, algorithme de chiffrement RS-6180

Des vulnérabilités touchent la plupart des algorithmes supportés par IKEv1, ne laissant que
très peu de choix encore acceptables. Ceci nécessite :
 le support obligatoire d'AES-CBC, tel que défini par le RFC 3602.
GDOI-05 : IKE v1, condensat utilisé pour l'intégrité RS-6181

Les vulnérabilités avérées de MD5 et SHA1 imposent l'utilisation des condensats de la famille
SHA-2 pour assurer l'intégrité des échanges. Ceci impose donc :
 le support obligatoire de HMAC-SHA-256-128 tel que défini dans le RFC 4868,
 le support souhaitable de HMAC-SHA-384-192 et HMAC-SHA-512-256 tels que définis
dans le RFC 4868.
GDOI-06 : IKE v1, fonctions pseudo-aléatoires RS-6182

Concernant les fonctions pseudo-aléatoires (PRF : Pseudo Random Function), il est demandé :
 Le support obligatoire de PRF-HMAC-SHA-256.
 Le support souhaitable de PRF-HMAC-SHA-384.
 Le support souhaitable de PRF-HMAC-SHA-512.
GDOI-07 : Support de l'acquittement du changement de clé de groupe RS-6174

Le RFC 8263 ajoute à GDOI une fonction d'acquittement du changement de clé de groupe
(GROUPKEY-PUSH Acknowledgement Message). Il est souhaitable que le serveur GDOI, et les
IED communiquant avec lui, supportent cette extension.
GDOI-08 : Utilisation d'OCSP par le serveur et les clients RS-6188

Le protocole OCSP, défini dans le RFC 6960 permet de vérifier si un certificat présenté est
toujours valide.
 Le serveur GDOI devra vérifier par une requête OCSP la validité du certificat présenté
par le client.
 Les clients GDOI (IED) devront vérifier par une requête OCSP la validité du certificat
présenté par le serveur.
GDOI-09 : Configuration des clients GDOI RS-6190

Les clients GDOI (IED) devront disposer, pour pouvoir rejoindre le groupe :
 de l'adresse du serveur GDOI,
 d'un certificat pour s'authentifier auprès de celui-ci,
 de l'ID numérique du groupe GDOI à rejoindre,
 des caractéristiques du trafic à protéger (par exemple : source et destination, même
s’il s'agit d'un "broadcast Ethernet" dans le cas des GOOSE et SV).
5. NAC : Contrôle d'Accès au Réseau Local du Poste

Electrique (802.1X-2010)
5.1 Description

Pilotes
Key RS-6128
Répond aux besoins RS-6026 - Assurer l'intégrité de la signalisation IP (ICMP)
RS-5821 - Confidentialité des mesures physiques classées ICS
RS-5877 - Intégrité de la synchronisation temporelle des équipements
RS-5771 - Sécurisation de l'accès au réseau local (LAN du poste
électrique)
RS-5820 - CRE-01 : Confidentialité des informations commercialement
sensibles
RS-5808 - LPM-19 : Règle relative à l’installation de services et
d’équipements
Le déploiement du mécanisme IEEE 802.1X répond au besoin de contrôler l'accès à un port

Ethernet et d'empêcher les attaques de l'homme du milieu sur le câble entre l'équipement et
le commutateur).
Bénéfices
Au-delà de la sécurité des communications, le fait que le commutateur puisse identifier
l'identité d'un équipement et potentiellement sa classe, pourrait ouvrir la possibilité d'assigner
le bon VLAN aux équipements basé sur leur identité, avec une configuration génériques (par
exemple, une machine dont le nom (Distinguished Name) contiendrait par exemple
"mergingunit.tranche1" irait dans le VLAN adapté, sans configuration plus spécifique. Ceci
pourrait faciliter les remplacements d'équipements sans reconfiguration des commutateurs.
(La décision est prise par le RADIUS, voir par exemple chez Cisco
https://www.cisco.com/c/en/us/td/docs/ios-xml/ios/sec_usr_8021x/configuration/xe-
3se/3850/sec-user-8021x-xe-3se-3850-book/sec-ieee-8021x-vlan-assign.html).
802.1X étant appliqué "port à port" et non "end to end", l'adoption partielle est possible. Des
équipements compatible peuvent communiquer avec des équipements non compatibles, le
commutateur assurant l'envoie de trames Ethernet compatible avec l'équipement connecté sur
le port.
Cas des équipements ne supportant pas 802.1X-2010 mais supportant 802.1X-

2001 :
Ces équipements ne supportant pas MACsec, une fois le port ouvert il faut accepter le risque
d'usurpation au niveau Ethernet. Tous les protocoles non sécurisés par ailleurs issus ou à
destination des équipements concernés seront vulnérables.
NAC-01 : Version de 802.1X RS-6129

La version du protocole 802.1X devra être 802.1X-2010 ou ultérieure pour garantir une sécurité
acceptable. La version 802.1X-2001 pourra être tolérée pour les premiers sites afin de mettre
au point les procédures d'installation et de maintenance mais sera interdite à partir d'une date
fixée contractuellement.
Remarque :
Ni 802.1X-2001 ni 802.1X-2004 ne permettent la négociation de clés pour 802.1AE (cf. RS-
6134 - NAC-03 : Mécanisme de confidentialité et d'intégrité des trames Ethernet (MACsec,
IEEE 802.1AE)) or en l'absence de ce mécanisme, ils sont vulnérables à des attaques, en
particulier l'insertion d'une machine pirate - un implant configuré en pont ("bridge") - entre
l'équipement et le commutateur.
Pour des références, se reporter à :
 https://www.researchgate.net/publication/327402715
 https://www.digitalsilence.com/wp-content/uploads/2018/08/DEF-CON-26-Gabriel-
Ryan-Whitepaper-Bypassing-Port-Security-In-2018-Defeating-MacSEC-and-802.1x-
2010.pdf
NAC-02 : Authentification par EAP/TLS RS-6130

L'authentification devra s'effectuer au moyen du protocole EAP/TLS, les autres modes

d'authentifications sur EAP sont interdits en raison de problèmes de sécurité intrinsèques ou
de problèmes organisationnels pour la création et la distribution de secrets.
Conformément à RS-6149 - TLS : Sécurisation des flux TCP par TLS, la version de TLS doit
être 1.2 ou 1.3 :
 Toutes les suites cryptographiques de TLS 1.3 sont acceptables.
 Seules les suites conformes aux recommandations de l'ANSSI sur le déploiement de
TLS (cf. RS-5936 - ANSSI-02 : Recommandations sur TLS) sont acceptables en TLS1.2.
Remarque :
EAP/TLS permet l'authentification mutuelle de l'équipement qui cherche à se raccorder et du
réseau auquel on le raccorde. La difficulté principale de déploiement est la nécessité d'un
certificat, obtenu par enrôlement de l'équipement dans l'IGC.
NAC-03 : Mécanisme de confidentialité et d'intégrité des trames RS-6134

Ethernet (MACsec, IEEE 802.1AE)
L'utilisation de MACsec (802.1AE) telle que spécifié par 802.1x-2010 (802.1AE-2006) est
impérative, afin d'éviter une connexion en intermédiaire d'un attaquant, entre un équipement
autorisé et le commutateur (attaque de type Man-in-the-middle). Seul le support de la suite
de chiffrement GCM-AES-128 est obligatoire (en mode AEAD : Authenticated Encryption with
Associated Data). Le support des suites GCM-AES-256, GCM-AES-XPN-128 et GCM-AES-XPN-

256 est optionnel.
Remarque :
MACsec répond en partie au besoin d'intégrité et de confidentialité au niveau des trames
Ethernet. MACsec n'implémente pas de sécurité de machine à machine telle que TLS ou IPsec
peuvent l'assurer, mais une sécurité de port à port (sur le câble), le chiffrement étant effectué
directement au niveau des composants Ethernet des équipements et des commutateurs, les
commutateurs déchiffrant une trame en entrée et la chiffrant avec la clé du destinataire en
sortie. Cela signifie que les informations restent exposées à une interception, et surtout que
les commandes restent exposées à une usurpation, par les commutateurs du réseau eux-
mêmes, qui dans ce contexte, jouent un rôle clé dans la sécurité.
Pour l'établissement des clés de MACsec, même si une dépose manuelle des clés est
techniquement possible, l'utilisation des mécanismes d'établissement de clés de 802.1X-2010
est nécessaire sur un site industriel, étant donné le nombre d'équipements impactés.
NAC-04 : Nécessité des VLAN (IEEE 802.1Q) RS-6137

Le support à la fois de 802.1AE et de 802.1Q (VLAN de niveau 2) est exigé des IED.
Remarque :
La nécessité du support des VLAN (de niveau 2), normalisés par l'IEEE 802.1Q, est imposée
par la nécessité d'assurer une qualité de service (QoS) suffisante pour le respect des
contraintes de temps-réel des GOOSE et des SV. Il apparaît que certains équipements
supportent les deux standards 802.1AE et 802.1Q mais pas en même temps. Toutefois, dans
le cadre R#SPACE, la cible est que tout le trafic soit protégé par MACsec, tout en gardant les
différents VLANs offerts par 802.1Q pour la qualité de service.
NAC-05 : VLAN dédié à l'enrôlement. RS-6132

Pour un équipement nouveau - dans le cas de la mise en place d'un nouveau poste ou du
remplacement d'un équipement - en l'absence d'authentification réussie par 802.1X,
l'équipement devra être assigné par le commutateur à un VLAN non chiffrée permettant
seulement l'enrôlement, c'est-à-dire seulement l'accès à l'interface d'enrôlement d'une Autorité
d'Enregistrement de l'IGC et complètement séparé du reste du réseau d'administration (ou le
cas échéant du réseau d'exploitation).
NAC-06 : Support de la redondance du réseau en PRP ou HSR RS-6437

Le réseau local d'exploitation est redondé pour des raisons de fiabilité. Les deux protocoles
utilisés avec la CEI 61850 sont PRP, pour deux réseaux parallèles en étoile, et HSR pour un
réseau en anneau. Cela conduit à avoir deux liaisons Ethernet physiques, avec les mêmes
adresses MAC et IP, ce qui est acceptable car les deux réseaux redondants sont séparés.
Comme deux commutateurs redondants ne communiquent pas entre eux, la clé de session
MACsec (802.1X) est différente pour chaque liaison, même entre deux liaisons redondantes.
Un équipement a donc nécessité de s'authentifier deux fois pour une liaison redondante, une
fois sur chaque commutateur.
Exigence :
Il est nécessaire que le logiciel support de 802.1X soit compatible avec PRP ou HSR. La
renégociation sur un des deux ports physiques ne doit aucunement impacter l'autre port.
NAC-07 : Serveur RADIUS pour l'authentification des équipements RS-6195

802.1x
Un serveur RADIUS est nécessaire en support à 802.1X.

Exigences génériques :
 Support de RADIUS sur TLS (RFC 6614 - Transport Layer Security (TLS) Encryption for
RADIUS), et non pas sur UDP.
 Support de l'utilisation d'une CRL ou de l'appel à un répondeur OCSP pour la vérification
de la validité des certificats.
 L'impossibilité de récupérer la CRL ou de contacter le répondeur OCSP donnera lieu à
l'émission d'alertes de sécurité.
 Contrairement à ce que dit RFC 6614 §3.3, la suite
TLS_RSA_WITH_3DES_EDE_CBC_SHA doit pouvoir être désactivée et ne doit en aucun
cas être utilisée (car elle n'est pas conforme au RGS, en raison de sa sécurité
contestable).
 Respect général de l'exigence RS-5936 - ANSSI-03 : Recommandations sur TLS.
 Authentification du commutateur par le serveur RADIUS, pour se protéger de
l'attaquant qui remplace le commutateur (authentification RADIUS effectuée par secret
partagé, qui devra être diversifié et de forte entropie).
 Serveur RADIUS redondé pour ne pas introduire de mode commun (Single Point of
Failure).
Besoin spécifique au support de 802.1X :

 Support d’EAP/TLS (RFC 5216) pour pouvoir authentifier les équipements.
Besoin de support des VLANs pour la qualité de service :

 pour pouvoir assigner les VLANs nécessaires à la priorisation des flux temps-réels, aux
équipements en fonction de leur identité, il y a nécessité de supporter les attributs
définis par le RFC 3580 (IEEE 802.1X Remote Authentication Dial In User Service
(RADIUS) Usage Guidelines).
6. RBAC : Contrôle d'accès basé sur des certificats

(62351-8 PUSH model)
6.1 Description
Pilotes
Key RS-5825
Répond aux besoins RS-5879 - Authentification efficace et robuste des utilisateurs
RS-6594 - Configuration de sécurité
RS-6541 - Sécurisation des modes d'exploitation
Est impacté par les RS-6340 - ANSSI-05 : Recommandations pour le cloisonnement du
contraintes système
RS-5787 - LPM-01 : Règle relative à la politique de sécurité des systèmes
d’information
RS-5800 - LPM-11 : Règle relative à l’identification
RS-5801 - LPM-12 : Règle relative à l’authentification
RS-5802 - LPM-13 : Règle relative aux droits d’accès
RS-5803 - LPM-14 : Règle relative aux comptes d’administration
RS-5805 - LPM-16 : Règle relative au cloisonnement
Est lié aux fonctions
Cette fonction définit la manière dont le contrôle d'accès basé sur les rôles (RBAC) est réalisé
en profondeur dans le système de CCN, sur la base de certificats portés par des machines et
des utilisateurs.
Le modèle PUSH de la CEI 62351-8 repose sur les principes suivants :
 chaque utilisateur ou machine possède un certificat, établi par l'IGC de Rte qui définit
son identité et ses rôles dans le système.
 les machines du système distribué entrent en relation de type client-serveur par la
création de connexions sécurisées au moyen de TLS. Le client présente son certificat
au serveur, qui ouvre une session avec des droits correspondants aux rôles mentionnés
dans le certificat.
RBAC-01 : Définition des rôles à Rte RS-5907

Remarques préliminaires :
Les rôles définis ci-dessous sont sensiblement différents de ceux de Smart Electre et des rôles
prédéfinis de la norme IEC 62351. Les spécifications de R#SPACE décriront, pour chaque
fonction, les droits associés à ces rôles. Notons que ces rôles peuvent aussi être attribués à
des processus informatiques. L'Active Directory industriel de Rte (cf. RS-5861 - AD : Contrôle
d'accès basé sur les rôles de l'Active Directory de Rte), permet de connaître et de gérer les
rôles attribués à chaque intervenant. Les rôles seront inscrits dans les certificats générés par
l'IGC.
Rôle Local Distant Droits Smart Electre

Passage de commandes et
consignes si tranche en local (y
compris, mise en / hors service
des fonctions, et commande du
mode de ré-enclenchement de
l'ARS).
Gestion des modes
OUI NON
Exploitation locale d'exploitation : passage d’une Exploitation
tranche en local puis en
télécommande, en
maintenance, commande des
modes de test. Surveillance du
site électrique : lecture de télé-
informations, gestion
d'alarmes…
Surveillance du site électrique :
Assistance à lecture de télé-informations,
l'exploitation gestion d’alarmes…Pas de
passage de commandes.
Lecture des télé-informations.
Passage de
télécommandes. Consignation
Téléconduite Télé-exploitant
d’une tranche pour travaux.
Rôle réservé à la passerelle de
téléconduite.
Ce rôle cible l’analyse
d’incidents électrotechniques
simples et la collecte Analyse
Analyse d'incident
d’informations. d’incident
Lecture et export de
perturbographies, ECDE, LAD…
Visualisation et export du
Journal de Bord, des alarmes,
de l'identité des IED, de la main
courante. Vue système
(réseaux LAN et état de santé
des IED). Gestion des modes
Maintenance N1/ d'exploitation. Redémarrage Maintenance
N2 Curative logiciel (temporisé). N1/N2
Redémarrage matériel
(temporisé) par manœuvre des
MCB d'alimentation des IED.
Désactiver et retirer un
équipement. Intégrer et activer
un équipement.
Mise ES/HS d'une fonction

(ADD par exemple). Vue
système (réseaux LAN et état
de santé des IED). Gestion des
modes d'exploitation. Passage
Maintenance de commandes autorisé
N1/N2 Préventive seulement si mode
d'exploitation de la tranche =
"en maintenance". Surveillance
en local des installations (prises
en compte des TI, gestion des
alarmes…) et rapport au CEX.
Désactiver et retirer un
équipement. Enrôler, intégrer et
activer un équipement. Charger
une configuration ou un
MaintN3Loc
Maintenance N3 paramétrage et l'activer.
MaintN3Dist
Installer une mise à jour
logicielle (paquet). Essais et
modes de test. Gestion des
modes d'exploitation.
Gestion des modes
d'exploitation. Passage de
commandes en tant que
Maintenance N3 Personnel de Manœuvre.
MaintN3Loc
PDM Surveillance en local des
installations (prise en compte
des TI, gestion des alarmes…)
et rapport au CEX.
Installation et configuration du
système et de l’application.
Qualification d’une version
logicielle. Création d’un paquet
d’installation d’une mise à jour.
Redémarrage matériel et
Administration logiciel non temporisé. Configuration
Installation des correctifs de
sécurité. Rôle réservé au poste
d'administration et à un
administrateur sur site, et
temporairement à un
installateur sur un site donné.
Consultation des Syslogs et des
Supervision de informations de sécurité. Gestion des
sécurité Configuration des droits utilisateurs
associés aux rôles.
Création d'un paquet

Intégrateur
d'installation d'une mise à jour.
Exigence :
Pour chaque fonction, les droits de réaliser les actions élémentaires - et en particulier les
passages de commandes - seront accordés à un ou plusieurs rôles, en suivant les orientations
données ci-dessus, dans les spécifications détaillées ou la modélisation des interfaces. La
configuration détaillera pour chaque commande les droits (lecture, écriture, exécution) de
chaque rôle.
RBAC-02 : Définition des profils. Séparation des rôles et des RS-6158

responsabilités
Seuls les rôles sont associés à des droits dans la spécification fonctionnelle. Toutefois, les rôles
sont regroupés dans des profils d'utilisateurs pour faciliter la gestion. Un profil correspond
simplement à un ensemble (non nul) de rôles. Un utilisateur possède un ou plusieurs profils.
Lorsqu'une session est ouverte, elle doit l'être pour la totalité des rôles de l'utilisateur,
indépendamment de ses profils. Ainsi les droits d'un utilisateur, dans une session ouverte sur
le système, seront la somme des droits associés à chacun de ses rôles.
Illustration des concepts de « Rôle » et « Profil » d'un « Utilisateur » :
L’utilisateur « François T » qui a un identifiant peut se connecter au système grâce à son

authentifiant (par exemple un mot de passe). Il disposera alors des droits associés aux rôles
« exploitant », « analyse d’incidents » et « maintenance N1/N2 », découlant du profil « GDP ».
Exigence :
À l'ouverture d'une session sur un IED avec un profil donné, les droits attribués à la session
seront le regroupement des ensembles de droits, chaque rôle du profil ayant un ensemble de
droits.
RBAC-03 : Profils envisagés, rôles incompatibles. RS-6160

La notion de séparation des responsabilités (separation of duties) doit être ajoutée au modèle
de base : certains rôles sont séparés, pour des raisons de sécurité, car les tâches qu'ils réalisent
sont incompatibles entre elles. Cela signifie que ces rôles ne peuvent pas être utilisés
simultanément par un utilisateur dans une même session. Ces rôles doivent bien sûr appartenir
à des profils différents.
Exigences :
Sont déclarés incompatibles entre eux les rôles suivants :

1. administration et (conduite locale ou téléconduite).
2. maintenance (N1/N2 ou N3) et téléconduite,
3. conduite locale et téléconduite,
Un serveur doit refuser d'ouvrir une session avec des rôles incompatibles entre eux. L'exigence
de séparation de l'administration et de la conduite est très forte. La non- séparation de la
conduite locale et de la téléconduite peut être tolérée au niveau d'un automate (IED).
Remarques :
Les différents profils prévus actuellement sont les suivants. Notez bien que Rte se réserve
le droit de modifier les profils lors de réorganisations internes.
Les automates (IED) et les Postes Opérateurs (IHM) de R#SPACE doivent être en mesure de
créer des sessions correspondant à ces profils, c'est-à-dire qu'une session aura les droits
conférés par l'ensemble des rôles du profil.
EMASI
Gestionnai
Rôles \ GD PEAS / CASTE PDC Intégrate Systémi
re de
Profils P I PMSAS R D ur / CNER er
sécurité
I
Exploitatio
n locale
Assistance
à
l'exploitati
on
Analyse
d'incident
Maintenan
ce N1/N2
Curative
Maintenan
ce N1/N2
Préventive
Maintenan
ce N3
Maintenan
ce N3 PDM
Supervisio
n de
sécurité
Intégrateu
r
GDP : Groupement De Poste, dit « l’exploitant ».
PEASI : Pôle Étude d’Automatisme et Système Industriel.
EMASI : Équipe de Maintenance Automatisme et Système Industriel.
PMSASI : Pôle Maintenance Spécialisée Automatisme et Système Industriel.
CASTER : Centre d’Administration Supervision Télémaintenance régional.
PDCD : Pôle Dispatching Configuration de Données.
RBAC-04 : Principes du RBAC (Core RBAC Model) RS-6157

Le standard ANSI INCITS 359-2004 sur lequel s'appuie en partie le standard IEC 62351-8 rend
obligatoire l'implémentation du Core RBAC model afin d'assurer l'interopérabilité sur l'ensemble
d'un système.
Ce modèle inclut : les utilisateurs (USERS), les rôles (ROLES), les objets ou ressources (OBS),
les opérations sur ces objets (OPS) et les permissions d'accès à ces objets (PRMS). A cela
s'ajoutent les sessions (SESSIONS) qui associent un sous-ensemble de rôles à un utilisateur.

Les éléments OBS et OPS sont prédéfinis.
Exigences :
Pour les IED et machines de site, les opérations qui doivent être supportées sont :
 ajout et suppression d'utilisateurs (AddUser et DeleteUser). L'ajout est réalisé
simplement par lecture du certificat de l'utilisateur, qui mentionne son identifiant et la
suppression est automatique à la fermeture de la session.
 ajout et suppression de rôles (AddRole et DeleteRole) : cela est réalisé par
configuration de l'IED ou de la machine.
Les principales opérations sur les relations sont :

 association d'un ou plusieurs rôles à un utilisateur. Le standard IEC parle alors de
"subject assignment" ou de "subject-to-role mapping". Cela est réalisé dans le certificat
du client, qui contient les rôles qui lui sont attribués par Rte.
 association de permissions à un rôle. Le standard IEC parle de "role assignment" ou de
"role-to-permission mapping". Cela est réalisé par la configuration de sécurité de la
machine (qui est différente de la configuration normale).
 association des opérations (ou actions autorisées) à un objet. Le standard IEC parle de
"Permission assignment" ou de "mapping of actions to objects". Cette association est
en partie déterminée par la modélisation des objets faite par l'IEC 61850.
RBAC-05 : Approche par sessions TLS RS-6162

Le standard IEC-26351-8 propose 2 approches pour la mise en œuvre de RBAC :

 l'approche par messages, appelée parfois "End-to-End security". Chaque message émis
est signé avec la clé publique de l'émetteur du message. A la réception, la signature
du message doit être vérifiée de même que la signature du certificat de l'émetteur pour
vérifier que ce dernier est valide. Ces opérations peuvent coûter en temps de calcul. Il
est toutefois possible de faire l'économie de la seconde vérification.
 l'approche par sessions. Les certificats sont utilisés pendant la phase d'établissement
pour l'authentification mutuelle et la création d'une clé de session qui servira à protéger
les échanges. Pour des raisons de sécurité, le standard IEC62351-4 demande que les
clés de sessions soient régulièrement renégociées.
Exigence :
L'approche par sessions est choisie et sera mise en œuvre grâce à TLS (cf. RS-6149 - TLS :
Sécurisation des flux TCP par TLS).
RBAC-06 : Profil A de la norme IEC 62351-8 RS-6161

Le standard IEC-62351-8 définit 4 profiles pour la mise en place du RBAC :

 le profil A qui utilise des certificats X.509 à clé publique, mentionnant l'identité et les
rôles.
 le profil B qui utilise un certificat principal X.509 pour l'identité, puis un certificat X509
attribut pour les rôles.
 le profil C qui met en œuvre des jetons JSON (JWT).
 le profil D qui utilise le protocole RADIUS pour authentifier les utilisateurs et récupérer
leurs rôles.
Les certificats fournis par l'IGC de Rte suivront le profil A. Le profil B, avec des certificats
attributs pour les rôles, ne sera pas utilisé, ni les profils C et D.
Remarques :
 le profil C, basé sur une technologie Web JWT ne nous semble pas approprié à un
contrôle-commande numérique.
 le profil D, est envisageable en solution de repli, mais pose soit un problème de sécurité
si la base de mots de passe est répliquée en local, soit un problème de disponibilité en
cas de perte du lien avec le centre de données.
7. SYSLOG : Collecte des journaux de sécurité

7.1 Description

Key RS-5856
Répond aux besoins RS-6522 - Garantir la chronologie des Logs en cas de resynchronisation.
RS-5853 - Journalisation des événements de sécurité
Est impacté par les RS-5791 - LPM-05 : Règle relative à la journalisation
contraintes RS-5794 - LPM-06 : Règle relative à la corrélation et l’analyse de
journaux
Tous les équipements informatiques présents sur le poste électriques doivent remonter des
traces vers les journaux centralisés de sécurité, afin que le centre opérationnel de sécurité
(SOC) puisse superviser les installations. Le format des traces de sécurité doit suivre la RFC
5424 (Syslog) et les recommandations de la norme CEI 62351-14, qui - au moment où nous
écrivons - est encore en cours de rédaction (Committee Draft).
SYSLOG-01 : Système de journalisation de sécurité RS-5946

Un système de journalisation d’événements de sécurité doit être mis en place pour :

 l’ensemble des machines physiques du poste,
 l’ensemble des services applicatifs du poste,
 les postes d’administration et de maintenance du poste.
Le système de journalisation enregistre les évènements associés :

 à l’authentification (abouties ou échouées),
 à la gestion des comptes et des droits,
 à l’accès aux ressources,
 aux modifications des règles et stratégies de sécurité,
 ainsi qu’à l’activité du système et des processus sous-jacents.
SYSLOG-02 : Horodatage des événements RS-5992

Les événements enregistrés doivent être systématiquement situés dans le temps afin de
pouvoir reconstituer les faits de manière précise, lors d’investigation d’incidents ou
d’anomalies, ils mentionneront donc la date et heure avec une précision absolue minimale de
50 ms et une résolution minimale de 1 ms.
Chaque application ou système déclenchant des événements à journaliser doit donc avoir
accès à l'horodatage, grâce à la synchronisation des horloges des différents équipements sur
une source de temps fiable (référentiel unique de temps) :
 le protocole Network Time Protocol (NTP) est souvent utilisé pour cela (précis à 10 ms
sur les postes),
 le protocole Precision Time Protocol (PTP) est bien sûr possible (relié à l'horloge locale
du poste, qui elle-même peut être synchronisée globalement, par satellite ou un autre
moyen).
Les ajustements d'horloge doivent être réalisés progressivement, de manière à garantir un

temps local croissant, sans retour en arrière. Dans le cas où un saut dans le temps serait
inévitable, un évènement spécifique doit être journalisé.
SYSLOG-03 : Source des événements RS-5994

Pour chaque événement à journaliser, il faut nécessairement identifier la source :

 le nom de l'équipement ayant généré la trace (hostname) : pour les IED du poste la
règle de nommage est basée sur RS-5011 - MOD-21 Règles de nommage des IED,
 une information sur le processus ayant déclenché cette émission.
SYSLOG-04 : Format des messages RS-6163

La RFC 5424 décrit la structure générale des messages Syslog comme suit :
HEADER SP STRUCTURED-DATA [SP MSG], avec :
 SP = caractère espace (i.e. blanc)
 [] indique une partie optionnelle
HEADER est décrit par RS-6164 - SYSLOG-04-01 : Entête d'un message,

STRUCTURED-DATA est décrit par RS-6165 - SYSLOG-04-02 : Corps d'un message,
MSG est décrit par RS-6194 - SYSLOG-04-03 : Utilisation éventuelle du champ MSG.
Note : les blancs dans la description de la première ligne ne sont là que pour faciliter la lecture.
Lorsqu'un caractère blanc doit être présent, il est indiqué par les 2 lettres SP. Par exemple,
HEADER et STRUCTURED_DATA sont séparés par un blanc.
SYSLOG-04-01 : Entête d'un message RS-6164

La partie entête (HEADER) d'un message syslog est décrit par la RFC 5424 de la manière
suivante :
 HEADER = PRI VERSION SP TIMESTAMP SP HOSTNAME SP APP-NAME SP PROCID
SP MSGID
Le standard IEC 62351-14 spécifie les valeurs que doivent prendre les différents champs :
PRI = 1*3DIGIT : indique la priorité du message syslog. Il est de la forme <PRIVAL>, où
PRIVAL est un entier valant 8 * FACILITY + sévérité. L'IEC 62351-14 donne la valeur 13 à
FACILITY. Les valeurs de sévérité sont spécifiées par le standard et rappelées dans
l'exigence RS-6147 - SYSLOG-04 : Sévérité des événements.
VERSION = NONZERO-DIGIT 0*2DIGIT : indique la version du message syslog. L'IEC
62351-14 lui donne la valeur 1.
TIMESTAMP = NILVALUE / FULL-DATE "T" FULL-TIME : indique la date et l'heure de
création du message syslog. Si l'équipement n'est pas capable de dater l'événement, la
valeur NIL doit être utilisée.Dans le cas contraire, ce champ a la forme FULL-DATE "T" FULL-
TIME avec :
 FULL-DATE = FULLYEAR - MONTH - MDAY
 FULL-TIME = PARTIAL-TIME TIME-OFFSET
 PARTIAL-TIME = HOUR ":" MINUTE ":" SECOND [SECFRAC]
 TIME-OFFSET = "Z" / TIME-NUMOFFSET
 avec
 FULLYEAR = 4DIGIT (4 chiffres= pour l'année
 MONTH = 2DIGIT (2 chiffres) pour le mois de 01 à 12
 MDAY = 2DIGIT (2 chiffres) pour le jour de 01 à 31 dépendant du mois dans l'année
 HOUR = 2DIGIT (2 chiffres) pour l'heure de 00 à 23
 MINUTE = 2DIGIT (2 chiffres) pour les minutes de 00 à 59
 SECOND = 2DIGIT (2 chiffres) pour les secondes de 00 à 59
 SECFRAC = "." 1*6DIGIT (1 point suivi de 1 à 6 chiffres) indique des fractions de
secondes (optionnel)
 TIME-NUMOFFSET = ("+" / "-") HOUR ":" MINUTE
HOSTNAME = NILVALUE / 1*255PRINTUSASCII : indique l'hôte sur lequel a été généré le
message Syslog. Ce peut être son nom ou son adresse IP sous la forme d'une chaine de 1 à
255 caractères ASCII imprimables autres que le blanc. Si l'équipement ne peut pas
déterminer ce champ, la valeur NIL doit être utilisée.
APP-NAME = NILVALUE / 1*48PRINTUSASCII : indique le nom du composant qui a généré
l'événement de sécurité. Ce peut être un device ou une application. C'est une chaine de 1 à
48 caractères ASCII imprimables autres que le blanc. Si le composant n'a pas de nom, la
valeur NIL doit être utilisée.
PROCID = NILVALUE / 1*128PRINTUSASCII : indique le processus associé au message
Syslog. L'IEC 62351-14 demande que ce champ ne soit pas utilisé. La valeur NIL lui sera
donc attribuée.
MSGID = NILVALUE / 1*32PRINTUSASCII : ce champ est une chaine de 1 à 32 caractères
ASCII imprimables autres que le blanc. Dans le contexte de l'IEC 62351-14, il correspond au
champ LogType du standard et doit avoir la valeur IEC62351-14
Note : PRINTUSASCII = %d33-126
La forme générale de l'entête est donc la suivante pour un événement de type "notice" :
 Priorité de l'événement (champ PRI de la RFC5424) avec Sévérité = "notice" (champ
Sev de l'IEC62351-14), cela donne la valeur 108
 La version du message syslog (champ VERSION de la RFC5424). elle prend la valeur
1
 Heure et date de l'événement (champ TIMESTAMP de la RFC5424)
 L'hôte qui a émis le message syslog (champ HOSTNAME de la RFC 5424)
 Le nom de l'entité qui a généré le message syslog (Champ ProdName de
l'IEC62351-14 et champ APP-NAME de la RFC5424) = "nom du produit ayant
transmis l’événement"
 L'identifiant du process qui a généré le message syslog (champ PROCID de la

RFC5424). D'après l'IEC 62351-14 ce champ ne doit pas être utilisé. Il aura donc la
valeur NIL représentée par le charactère -
 Le type du message (champ LogType de l'IEC62351-14 et champ MSGID de la
RFC5424). Il prend la valeur IEC 62351-14
SYSLOG-04-02 : Corps d'un message RS-6165

Le corps (STRUCTURED-DATA) d'un message syslog est décrit par la RFC 5424 de la manière
suivante (voir également la RFC 5234) :
 STRUCTURED-DATA = NIL / 1*SD-ELEMENT
 SD-ELEMENT = "[" SD-ID *(SP SD-PARAM) "]"
 SD-PARAM = PARAM-NAME "=" %d34 PARAM-VALUE %d34
 SD-ID = SD-NAME
 PARAM-NAME = SD-NAME
 PARAM-VALUE = UTF-8-STRING ; characters '"', '\' and ']' MUST be escaped.
 SD-NAME = 1*32PRINTUSASCII ; except '=', SP, ']', %d34 (")
 PRINTUSASCII = %d33-126
Dans le contexte du standard IEC-62351 le champ SD-ID est obligatoirement comme suit :
 SD-ID = IEC@62351
Le standard IEC62351 spécifie les 3 éléments de STRUCTURED-DATA obligatoires comme

suit :
 IECversion : indique la valeur de la version du standard. Il est de la forme : PARAM-
NAME = IECversion, PARAM-VALUE = INTEGER. Le standard donne à PARAM-
VALUE la valeur 1
 ID : identifie de manière unique le type de l'événement de cyber sécurité qui est
tracé. Il est de la forme : PARAM-NAME = ID, PARAM-VALUE = INTEGER ou OID (cf.
ci-dessous)
 Text : fourni une information textuelle sur l'événement. Il est de la forme : PARAM-
NAME = Text, PARAM-VALUE = 128UTF-8-STRING
Et 5 éléments de STRUCTURED-DATA optionnels comme suit :

 Source : fourni l'identité unique de l'équipement ou de l'application qui a généré
l'événement. Il doit être utilisé lorsque 2 entités ont le même nom indiqué par le
champ AppName de l'entête (cf. RS-6164 - SYSLOG-04-01 : Entête d'un message
syslog). PARAM-NAME = Source, PARAM-VALUE = 64UTF-8-STRING
 Extrainfo : si besoin, ce champ vient compléter le champ Text ci-dessus. Il est de la
forme : PARAM-NAME = Extrainfo, PARAM-VALUE = 32UTF-8-STRING
 SOE : cet attribut indique le numéro de séquence de l'événement généré par l'entité,
c'est à dire que chaque fois qu'un événement est généré, cet attribut est incrémenté
de 1. Cet attribut est de la forme : PARAM-NAME = SOE, PARAM-VALUE = INTEGER
 UsrID : fourni l'identifiant unique de l'utilisateur associé à l'événement généré. Il est
de la forme : PARAM-NAME = UsrID, PARAM-VALUE = 32UTF-8-STRING
Note :
 le champ LogType (obligatoire) correspond au champ MSGID de l'en-tête du

message syslog (cf RFC 5424 et RS-6164 - SYSLOG-04-01 : Entête d'un message
syslog)
 le champ Sev (obligatoire) est utilisé pour le calcul de la valeur du champ PRI de
l'en-tête du message syslog (idem)
 le champ ProdName correspond au champ AppName de l'en-tête du message
syslog
Le corps du message Syslog est donc de la forme suivante : il est compris entre les
caractères [* et *] et comprend :
 Le champ SD-ID qui prend la valeur IEC@62351
 La version du standard sous la forme IECversion="1"
 L'identification du type de l'événement de cyber sécurité. C'est le champ ID de
l'IEC62351-14. Il est de la forme ID="entier" ou ID="OID" (voir ci-dessous)
 Une information textuelle sur l'événement. Il est de la forme Text="état du serveur
AD ou de l'action exécutée"
La future norme définit le champ ID comme un entier (cf. RS-6193 - SYSLOG-04-04 :

Identifiant des événements). Mais cet entier n'est guère pratique à utiliser car peu intelligible
pour un humain. L'utilisation d'un OID à la place d'un entier a été proposée au groupe
de normalisation par Rte et est en cours d'évaluation à la date de rédaction de la
présente exigence.
SYSLOG-04-03 : Utilisation éventuelle du champ MSG RS-6194

Les équipements qui ne peuvent pas formater les attributs IECversion, ID, Text, ExtraInfo,
SOE, Source et UsrID comme indiqués dans la table 13 du standard IEC62351-14 (cf. RS-
6165 - SYSLOG-04-02) doivent utiliser le champ MSG (la dernière partie optionnelle d'une
entrée Syslog) pour écrire ces informations.
SYSLOG-04-04 : Identifiant des événements RS-6193

L'IEC 62351-14 est encore en cours de rédaction de cette partie à l'heure où nous écrivons,
aussi cette partie ne peut être figée et devra être mise à jour.
Une première version définissait les identifiants des événements de cyber sécurité comme des
entiers. Elle associait pour cela des plages de valeur à différentes classes d'événements avec
des formules comme par exemple : (IEC standard number × 10000) to ((IEC standard number
× 10000) + 9999) ce qui correspond à une plage allant de 623510000 à 623519999. Cette
représentation n'est guère pratique à utiliser.
L'utilisation d'un OID à la place d'un entier a donc été proposée au groupe de normalisation
et est en cours d'évaluation. Dans les exigences décrivant en détail les informations remontées
(SYSLOG-20 à SYSLOG-27) l'utilisation d'OIDs a été privilégiée. Les OIDs des événements
commencent par 1.0.62351 (cf. http://oid-info.com/get/1.0.62351).
SYSLOG-04-05 : Sévérité des événements RS-6147

Le standard IEC 62351-14 définit 6 niveaux de sévérité pour un événement de sécurité (les
valeurs correspondantes sont définies dans la RFC 5424) :
 emergency (value 0) : l'équipement est inutilisable,
 alert (value 1) : une action doit être entreprise immédiatement,
 critical (value 2) : indique une situation critique (aucune action immédiate requise),
 error (value 3) : indique une erreur,
 notice (value 4) : indique une situation normal mais significative,
 warning (value 5) : pour un avertissement.
SYSLOG-10 : Centralisation des journaux RS-6024

La centralisation de journaux consiste à les exporter depuis les équipements où ils ont été
générés vers une machine centrale. Cette opération a pour objectifs de :
 Disposer d’un environnement de stockage correctement dimensionné au regard des
contraintes fonctionnelles et légales,
 Assurer la haute disponibilité des journaux sur un équipement central distinct de
l’équipement émetteur,
 Simplifier la consultation des journaux en évitant aux personnes en charge de leur
exploitation à se connecter à plusieurs équipements,
 Faciliter le recoupement d’événements entre plusieurs équipements sources,
 Faciliter la sauvegarde de journaux et la régulation de la période d’archivage légal.
Exigence :
Chaque trace de sécurité doit être transmise dès que possible au serveur de collecte, afin de
limiter autant que possible la perte de journaux en cas d'indisponibilité de l'équipement. Notons
que le serveur de collecte pourra être un relai local au site, qui retransmettra les traces au
collecteur national distant (cf. RS-6562 - SRV-03 : Relai local de collecte de journaux (Syslog)).
SYSLOG-11 : Pas de traitement local des journaux RS-6027

Étant générés par des sources différentes, les événements de différents équipements n’ont
pas forcément exactement le même format, même s'ils sont censés se conformer à la CEI
62351-14. Par conséquent, des actions de conversion peuvent être nécessaires pour en faciliter
l’exploitation.
Toutefois, il est fortement déconseillé d’effectuer la conversion sur les équipements ayant
générés les journaux de peur de dénaturer les événements, de perdre certaines informations,
voire d'ouvrir la voie à des attaquants. Ces opérations seront donc faites sur l’équipement
central de collecte (SIEM), suite au transfert.
Exigences :
Les accès aux journaux de sécurité sont réservés au rôle "supervision de sécurité" (cf. RS-
5907 - RBAC-02 : Définition des rôles à Rte) et en lecture uniquement. Il est impératif
d'interdire la modification d'un journal de sécurité par un administrateur, y compris
l'effacement ou la suppression d'événements. Seuls les processus automatiques peuvent écrire
dans les journaux de sécurité, jamais un utilisateur.
SYSLOG-12 : Sécurisation du transport des journaux RS-6016

Pour fiabiliser le transfert de journaux, et dans la mesure du possible, il est demandé de

recourir au protocole TCP qui limite les pertes de données en offrant des fonctions de
réémission de paquets, de mise en cache du côté de l’émetteur et d’acquittement du côté du
destinataire.
Pour assurer la confidentialité et l’intégrité des flux de transfert de journaux, il est demandé
d’utiliser le protocole TLS (en suivant les exigences exprimées dans RS-6149 - TLS :
sécurisation des flux TCP) lors du transfert, ce qui permet d’établir un canal de transmission
dédié après authentification mutuelle de l’équipement de sécurité et du serveur de collecte
grâce à des certificats issus de l'IGC industrielle (cf. RS-5756 - IGC : Infrastructure de Gestion
de Clés publiques (PKI) de Rte).
Les deux autres modes : TCP sans TLS, et UDP, sont des dérogations à la politique de sécurité
de R#SPACE, acceptables seulement pour les premiers postes 'd'.
Port de
Protocole RFC Mécanismes de sécurisation
destination
Authentification du serveur (voire du
Syslog sur client).
5425 TCP / 6514
TCP/TLS Chiffrement et Intégrité des données
Garantie de réception des paquets
Syslog sur TCP 6587 TCP / 514 Garantie de réception des paquets
Syslog sur UDP 5426 UDP / 514
Dans le cas recommandé (TLS), deux modalités de mise en œuvre sont possibles. La première
est la cible pour R#SPACE, la seconde tolérée pour les premiers postes 'd' :
 Syslog chiffré en mode « Encrypted channel » et « peer checking » : chiffrement et
vérification de l’identité du serveur,
 Syslog chiffré en mode « Encrypted channel » : chiffrement uniquement.
SYSLOG-13 : Modes de transfert et adresses de collecte RS-6025

Le mode utilisé pour le transfert des journaux vers l’équipement central est le mode temps
réel : chaque trace est poussée au plus tôt par l'équipement qui l'a généré vers le collecteur
centralisé (mode push). Les paquets Syslog doivent être transmis aux serveurs de collecte à
des adresses IP v4 configurables :
 Serveur de collecte Syslog - ADMIN.
 Serveur de collecte Syslog - TCD.
 Serveur de collecte Syslog - STCD.
En fonction du domaine de l'Active Directory industriel de Rte auquel le poste électrique est
rattaché. Les ressources SIIV devront centraliser leurs journaux sur les serveurs rattachés au
domaine STCD. Les autres sur les serveurs TCD.
Point d'attention :
L'adresse IP des ressources devant transmettre leurs journaux à un serveur de collecte Syslog
devra être connue de ce serveur de collecte, car un filtrage par liste blanche des adresses IP
sera réalisé.
SYSLOG-14 : Dimensionnement du stockage local de la journalisation RS-6029

Les journaux générés sont stockés localement en attendant d’être transférés vers une entité
centrale. Suffisamment d’espace doit être prévu selon les besoins de l'équipement. Les
recommandations suivantes s’appliquent à l’ensemble des serveurs d’infrastructures système
et réseau (stockage local) :
 Créer un espace de stockage limité et dédié aux journaux, afin d’éviter de saturer le
stockage de masse des équipements.
 Mettre en place une politique de rotation (un mécanisme de tampon circulaire où les
nouvelles informations remplacent les plus anciennes), pour gérer dans la durée
l'espace limité et éviter une saturation ; en aucun cas une saturation des journaux ne
doit perturber le fonctionnement d'un équipement.
 Le dimensionnement de l'espace de stockage dédié sera basé le conseil de l'IEEE 1686-
2013 § 5.2.2 : à savoir au moins 2048 événements dans un tampon circulaire.
SYSLOG-15 : Supervision de l’espace de stockage attribué à la RS-6028

journalisation
Il est nécessaire de superviser l’espace de stockage dédié au journal de sécurité pour les
raisons suivantes :
 Éviter l’indisponibilité des équipements, à cause d’une saturation du stockage. Notons
que l'utilisation de tampons circulaires permet d'éviter une saturation.
 Signaler la perte de traces en cas d'écrasement d'éléments non encore transmis par le
réseau au collecteur.
Note :
La détection de proportions inhabituelles de journalisation par rapport à une activité normale,
qui peut être le signe d'un incident de sécurité en cours, sera réalisée par le collecteur et non
par l'IED lui-même.
SYSLOG-20 : Informations relatives à la gestion des clés de RS-6317

cybersécurité
La section 6.3.5 de la future norme IEC 62351-14 spécifie les événements de cyber sécurité
qui sont associés à la gestion des clés de cyber sécurité (mise en œuvre des certificats et de
la GDOI) dans le cadre de l'IEC 62351-9, et qui doivent être journalisés. Ces événements sont
rappelés ci-dessous.
Cyber security
Severity event Object
MNEMONIC Text
(Sev) Identifier
(OID)
Certificate profile
CERT_PROFILE_MISMATCH warning 1.0.62351.9.0
mismatch
Algorithm mismatch,
CERT_ALG_MISMATCH alarm 1.0.62351.9.1 result: failed
verification
Format mismatch,
CERT_FORM_MISMATCH warning 1.0.62351.9.2 result: failed
verification
Mandatory format
CERT_PKCS12_MISMATCH warning 1.0.62351.9.3
(PKCS #12) mismatch
Optional format
CERT_PKCS8_MISMATCH warning 1.0.62351.9.4 (PEM., PKCS#8)
mismatch
OID errors when
using Certificate
Authorization List
CERT_OID_ERROR_AVL_EXT warning 1.0.62351.9.5
Extensions
(avl62351Extention
mismatch)
OID errors when
using Certificate
Authorization List
CERT_OID_ERROR_AVL_ENTRY warning 1.0.62351.9.6
Entry Extensions
(avl62351EntryExt
mismatch)
OID errors when

using Certificate
CERT_OID_ERROR_AVL_PROTID warning 1.0.62351.9.7
Authorization List
Protocol Identifiers
OID errors when
using Certificate
Authorization List
CERT_OID_ERROR_AVL_EXT warning 1.0.62351.9.8
Extensions
(avl62351Extention
mismatch)
notice (results Communicating
in inability to entities need to
NO_LOCAL_CERT 1.0.62351.9.9
communicate possess at least on
securely) public/private key pair
Insufficient
CERTREG_MISSING_CN warning 1.0.62351.9.10 registration data
Missing CN
Insufficient
CERTREG_MISSING_OTP warning 1.0.62351.9.11 registration data OTP
not available
Insufficient
registration data
CERTREG_MISSING_PRE_CERT warning 1.0.62351.9.12 Missing Pre-existing
credential information
not available
Insufficient
registration data
CERTREG_MISSING_DN warning 1.0.62351.9.13
Missing DN for CSR
generation
Missing information
CERT_MISSING_RCERT notice 1.0.62351.9.14 acceptable root CA
certificates
Missing information of
CERT_NO_CA warning 1.0.62351.9.15 CA address for
enrolment
No registration
CERT_NO_REG_INFO warning 1.0.62351.9.16 information available
about enrolling entity
Proof of possession
CERT_POP_ERROR error 1.0.62351.9.17 error (CSR could not
be validated)
Proof of identity error
CERT_POI_ERROR error 1.0.62351.9.18
(OTP or manufacturer
device certificate
error)
CERT_SCEP_PROT_ERROR error 1.0.62351.9.19 Errors related to SCEP
CERT_EST_PROT_ERROR error 1.0.62351.9.20 Errors related to EST
Errors related to EST
during the update of
CERT_EST_TA-UPDATE_ERROR error 1.0.62351.9.21
CA certificates (using
Root CA Key Update)
Errors related to
CERT_TAMP_ERROR error 1.0.62351.9.22
TAMP
CERT_VAL_EXPIRED alarm 1.0.62351.9.23 Certificate expired
CA signature
CERT_VAL_SIG_ERROR alarm 1.0.62351.9.24
verification failure
CERT_VAL_REVOKED alarm 1.0.62351.9.25 Certificate revoked
Certificate not
CERT_VAL_NO_AVL_MATCH warning 1.0.62351.9.26
contained on CertAVL
CertAVL signature
AVL_VAL_SIG_ERROR alarm 1.0.62351.9.27
validation error
Failures for CertAVL
AVL_VAL_COMP_ERROR warning 1.0.62351.9.28
components
AVL_VAL_EMPTY_LST notice 1.0.62351.9.29 Empty list provided
Remarques :
Les erreurs suivantes spécifiées dans IEC 62351-9 sont absentes de l’IEC 62351-14 :
Severity Cyber security event Object
MNEMONIC Text
(Sev) Identifier (OID)
Invalid hash
warning 1.0.62351.9.30
information
Authentication
warning 1.0.62351.9.31
failure
Invalid id
warning 1.0.62351.9.32
information
Attributes not
warning 1.0.62351.9.33
supported
warning 1.0.62351.9.34 SA payload error
warning 1.0.62351.9.35 ID Payload error
Certificate payload
warning 1.0.62351.9.36
error
IEC 62351-9 s'appuie sur les RFC 2407, 2408 et 2409 rendues obsolètes par une succession
de RFC dont la plus récente spécifie un certain nombre d'erreurs non présentes dans l’IEC
62351-14.
SYSLOG-21 : Informations sur le Contrôle d'Accès (RBAC) RS-6314

associés au RBAC (décrit dans IEC 62351-8) qui doivent être journalisés, par les équipements
qui ont implémenté les mécanismes correspondants. Ces événements sont rappelés ci-
dessous.
Cyber security
Severity event Object
MNEMONIC Text
(Sev) Identifier
(OID)
Successful user
authentication
RBAC_USR_AUTH_AUTHZ_SUCCESS notice 1.0.62351.8.0
and association
on server
Successful
update of
RBAC_PERM_ASSIGN_SUCCESS notice 1.0.62351.8.1
permission
assignment
LDAP repository
RBAC_NO_REPO_CONN_LDAP warning 1.0.62351.8.2
not accessible
RADIUS server
RBAC_NO_REPO_CONN_RADIUS warning 1.0.62351.8.3
not accessible
JWT provider not
RBAC_NO_REPO_CONN_JWT warning 1.0.62351.8.4
accessible
revocation
RBAC_NO_REPO_CONN_PKI warning 1.0.62351.8.5 repository not
available
No RBAC
credential
provided
(missing RBAC
RBAC_NO_CRED warning 1.0.62351.8.6 extension in
certificates or no
JWT token or no
RADIUS
information)
authentication of
RBAC_INVALID_TOKEN alarm 1.0.62351.8.7
subject failed
validity period of
access token
RBAC_TOKEN_VALIDITY_ERROR alarm 1.0.62351.8.8
could not be
verified
authentication of
RBAC_TOKEN_VERIFICATION_FAILED alarm 1.0.62351.8.9 access token
failed
RBAC_TOKEN_ROLEID_UNKNOWN alarm 1.0.62351.8.10 RoleID unknown
role definition
RBAC_TOKEN_ROLEDEF_UNKNOWN warning 1.0.62351.8.11
unknown
AoR could not be
RBAC_TOKEN_AOR_UNKNOWN warning 1.0.62351.8.12
resolved
revision number
RBAC_TOKEN_REV_MISMATCH warning 1.0.62351.8.13
mismatch
Cryptographic
RBAC_TOKEN_ALG_MISMATCH alarm 1.0.62351.8.14 algorithm
mismatch
revocation
RBAC_TOKEN_NO REVOCATION warning 1.0.62351.8.15 information not
available
revocation
RBAC_TOKEN_NO REVOCATION_EXP warning 1.0.62351.8.16 information
expired
Operation not
possible (DNP3) -
RBAC_TOKEN_EXT_OP_INVALID_USR warning 1.0.62351.8.17
No matching
user
Access token out
RBAC_TOKEN_EXT_OUT_OF_SEQ warning 1.0.62351.8.18 of sequence
(DNP3)
Validity period of
RBAC token
RBAC_ATTRIB_INVALID alarm 1.0.62351.8.19
outside the base
credential validity
No matching
RBAC_ATTRIB_NO_MATCH_BASE_CRED warning 1.0.62351.8.20 base credential
for RBAC token
Revocation
RBAC_ATTRIB_NO_REV_INFO warning 1.0.62351.8.21 information not
available
Validity period of
RBAC_JWT_INVALID alarm 1.0.62351.8.22
RBAC token
outside the base

credential validity
No matching
RBAC_JWT_NO_MATCH_BASE_CRED warning 1.0.62351.8.23 base credential
for RBAC token
Shared secret to
RBAC_RADIUS_SERVER_CRED_MISMATCH alarm 1.0.62351.8.24 RADIUS server
not matching
Provided
username and
RBAC_RADIUS_USR_PWD_MISMATCH alarm 1.0.62351.8.25 password
combination does
not match
Remarque : les événements suivants sont spécifiés dans l’IEC-62351-8, mais absents de
l’IEC-62351-14 :
Severity Cyber security event
MNEMONIC Text
(Sev) Object Identifier (OID)
warning 1.0.62351.8.26 access token issuer unknown
warning 1.0.62351.8.27 operation unsuccessful
sequence number already
warning 1.0.62351.8.28
used
warning 1.0.62351.8.29 access token not provided
certificate revocation
warning 1.0.62351.8.30
information unavailable
warning 1.0.62351.8.31 expired public-key certificate
revocation state could not be
warning 1.0.62351.8.32
verified
warning 1.0.62351.8.33 revoked public-key certificate
validity period of access
warning 1.0.62351.8.34
token could not be verified
SYSLOG-22 : informations sur les GOOSE et les Sampled Values RS-6315

associés aux GOOSE (IEC 61850-8-1) et aux Sampled Values (IEC 61850-9-2) qui doivent être
journalisés. Ces événements sont rappelés ci-dessous.
Cyber security
Severity
MNEMONIC event Object Text
(Sev)
Identifier (OID)
No GOOSE
GOOSE_NON_EXISTENT notice 1.0.62351.6.0
subscription
GOOSE subscription
GOOSE_ACTIVATE notice 1.0.62351.6.1
activated
GOOSE message
GOOSE_SUBSCRIBE notice 1.0.62351.6.2
received
Received GOOSE
GOOSE_SEC_CHECK_PASS notice 1.0.62351.6.3 message security
check passed
Received GOOSE
GOOSE_SEC_CHECK_FAIL alarm 1.0.62351.6.4 message security
check failed
Received GOOSE
GOOSE_REPLAY_DETECTED alarm 1.0.62351.6.5 message replay
detected
Received GOOSE
GOOSE_NO_REPLAY_DETECTED notice 1.0.62351.6.6 message no replay
detected
Received GOOSE
message does not
GOOSE_NO_AUTHVALUE notice 1.0.62351.6.7
have authentication
value
Received GOOSE
GOOSE_AUTHVALUE notice 1.0.62351.6.8 message have
authentication value
GOOSE MAC
GOOSE_MAC_GEN_OK notice 1.0.62351.6.9
generation successful
GOOSE MAC
GOOSE_MAC_GEN_FAIL alarm 1.0.62351.6.10
generation failed
GOOSE MAC
GOOSE_MAC_VERIFY_OK notice 1.0.62351.6.11
verification pass
GOOSE MAC
GOOSE_MAC_VERIFY_FAIL alarm 1.0.62351.6.12
verification failed
SV_NON_EXISTENT notice 1.0.62351.6.13 No SV subscription
SV subscription
SV_ACTIVATE notice 1.0.62351.6.14
activated
SV_SUBSCRIBE notice 1.0.62351.6.15 SV message received
Received SV message
SV_SEC_CHECK_PASS notice 1.0.62351.6.16
security check passed
Received SV message
SV_SEC_CHECK_FAIL alarm 1.0.62351.6.17
security check failed
Received SV message
SV_REPLAY_DETECTED alarm 1.0.62351.6.18
replay detected
Received SV message
SV_NO_REPLAY_DETECTED notice 1.0.62351.6.19
no replay detected
Received SV message
SV_NO_AUTHVALUE notice 1.0.62351.6.20 does not have
authentication value
Received SV message
SV_AUTHVALUE notice 1.0.62351.6.21 have authentication
value
SV MAC generation
SV_MAC_GEN_OK notice 1.0.62351.6.22
successful
SV MAC generation
SV_MAC_GEN_FAIL alarm 1.0.62351.6.23
failed
SV MAC verification
SV_MAC_VERIFY_OK notice 1.0.62351.6.24
pass
SV MAC verification
SV_MAC_VERIFY_FAIL alarm 1.0.62351.6.25
failed
Remarque : Il n'y a pas de message Syslog pour indiquer qu'il y a eu une perte de message
pour les GOOSE (cf. état 8 de la section 6.2.1.1 de l’IEC 62351-6) et pour les Sample Values
(cf. état 8 de la section 6.2.2.2 de l’IEC 62351-6) :
Severity Cyber security event Object

MNEMONIC Text
(Sev) Identifier (OID)
GOOSE message
alarm 1.0.62351.6.26
lost
alarm 1.0.62351.6.27 SV message lost
SYSLOG-23 : Informations relatives à TLS RS-6540

La section 6.3.1 de la future norme IEC 62351-14 spécifie les événements de cyber sécurité,
relatifs à la sécurité des communications IP, laquelle est garantie par le protocole TLS (cf. IEC
62351-3), qui doivent être journalisés par les équipements qui ont implémenté ce protocole.
Ces événements sont rappelés ci-dessous.
Cyber security
Severity
MNEMONIC event Object Text
(Sev)
Identifier (OID)
TLS ciphersuites
(proposed and
TLS_CIPHER_MISMATCH alarm 1.0.62351.3.0
configured) not
matching
TLS Version negotiation
TLS_WRONG_VERSION alarm 1.0.62351.3.1 results in TLS version <
1.0
TLS Version negotiation
TLS_WEAK_VERSION warning 1.0.62351.3.2 results in 1.0 < TLS
version > 1.2
TLS Version change
during session
TLS_VERSION_CHANGE alarm 1.0.62351.3.3
renegotiation or session
resumption
No renegotiation
TLS_NO_RENEG alarm 1.0.62351.3.4
performed by TLS client
No matching root CA
TLS_NO_ROOT_MATCH alarm 1.0.62351.3.5 certificate available for
verification
Received certificate too
TLS_CERT_SIZE_MISMATCH alarm 1.0.62351.3.6
large
No certificate material
TLS_NO_LOCAL_CERT alarm 1.0.62351.3.7 available (either locally
or received)
Certificate Validation:
TLS_NO_CA_MATCH alarm 1.0.62351.3.8 no matching CA
certificate available
Certificate Validation:
TLS_NO_IND_TRUST_MATCH alarm 1.0.62351.3.9 no matching local root
of trust available
TLS_NO_CRL warning 1.0.62351.3.10 CRL not accessible
OCSP responder not
TLS_NO_OCSP warning 1.0.62351.3.11
accessible
Revocation check error,
TLS_CRL_EXP warning 1.0.62351.3.12
if CRL expired
TLS_OCSP_RES_EXP warning 1.0.62351.3.13 if OCSP response
expired

TLS_CERT_REVOKED alarm 1.0.62351.3.14 if received certificate
was revoked
Received certificate
TLS_CERT_EXP alarm 1.0.62351.3.15
already expired
No matching signature
TLS_SIG_ALG_MISMATCH alarm 1.0.62351.3.16 algorithm to the
certificate components
Error validating the
TLS_CERT_VAL_ERR alarm 1.0.62351.3.17 signature of received
certificate
SYSLOG-25 : informations génériques RS-6537

La section 6.2 de la future norme IEC 62351-14 spécifie les événements de cyber sécurité
génériques (c'est à dire indépendants des normes IEC) qui doivent être journalisés. Ces
événements sont rappelés ci-dessous.
Cyber
security
Severit event
MNEMONIC Text
y (Sev) numerical
event
identifier (ID)
LOGIN_OK notice 1.0.62351.14.0 Log-in successful
Password expired,
LOGIN_OK_PW_EXPIRED notice 1.0.62351.14.1
Log-in successful
Log-in failed -
LOGIN_FAIL_WRONG_CR notice 1.0.62351.14.2
Wrong credentials
Log-in failed -
LOGIN_FAIL_PW_EXPIRED alarm 1.0.62351.14.3
Password expired
LOGIN_FAIL_3_TIMES alarm 1.0.62351.14.4 Log-in failed 3 times
Log-in failed too
LOGIN_FAIL_SESSIONS_LIMIT alarm 1.0.62351.14.5
many user sessions
User locked – Wrong
LOCK_USER_WRONG_CR alarm 1.0.62351.14.6
credentials
Log-out (user logged
LOGOUT_USER notice 1.0.62351.14.7
out)
Log-out by user
LOGOUT_TIMEOUT notice 1.0.62351.14.8
inactivity (timeout)
Viewed Security
VIEW_SEC_EV_LIST_OK notice 1.0.62351.14.9 Event logs
successfully
1.0.62351.14.1 File hash check
FILE_HASH_CHECK_FAIL alarm
0 failed
1.0.62351.14.1 File digital signature
FILE_DS_CHECK_FAIL alarm
1 check failed
Storing and writing
1.0.62351.14.1
WRITE_CERTS_FAIL notice certificates in the
2
entity failed
1.0.62351.14.1 Software update
SW_UPDATE_OK notice
3 was successful
1.0.62351.14.1 Software update
SW_UPDATE_FAIL alarm
4 failed
1.0.62351.14.1 View of Security
VIEW_SEC_EV_LIST_FAIL notice
5 Event list failed
Admin password
1.0.62351.14.1
PW_RESET_FACTORY_DEF alarm reset to factory
6
default
1.0.62351.14.1 Clear Security
SEC_EV_CLEAR_FAIL notice
7 events failed
1.0.62351.14.1 User account
USER_ACCNT_CREATE_OK notice
8 created successfully
USER_ACCNT_ENABLE_OK notice
9 enabled successfully
USER_ACCNT_DISABLE_OK notice
0 disabled successfully
USER_ACCNT_DEL_OK notice
1 deleted successfully
USER_ACCNT_CREATE_FAIL notice
2 creation failed
USER_ACCNT_ENABLE_FAIL notice
3 enabling failed
USER_ACCNT_DISABLE_FAIL notice
4 disabling failed
USER_ACCNT_DEL_FAIL notice
5 deletion failed
1.0.62351.14.2 New role assigned to
USER_NEW_ROLE_OK notice
6 user successfully
1.0.62351.14.2 Permission changed

USER_PERMISSION_CHANGE_OK notice
7 successfully
1.0.62351.14.2 Permission added
USER_PERMISSION_ADDED_OK notice
8 successfully
User role
1.0.62351.14.2
USER_ROLE_REMOVED_OK notice assignment removed
9
successfully
User permission
1.0.62351.14.3
USER_PERMISSION_REMOVED_OK notice removed
0
successfully
1.0.62351.14.3 New role created
NEW_ROLE_CREATE_OK notice
1 successfully
1.0.62351.14.3 Role deleted
ROLE_DELETE_OK notice
2 successfully
1.0.62351.14.3 User password
USER_PW_CHANGE_OK notice
3 changed successfully
1.0.62351.14.3 Change of user
USER_PW_CHANGE_FAIL notice
4 password failed
1.0.62351.14.3 New user role
USER_NEW_ROLE_FAIL notice
5 assignment failed
1.0.62351.14.3 Permission change
USER_PERMISSION_CHANGE_FAIL notice
6 failed
1.0.62351.14.3 Addition of
USER_PERMISSION_ADDED_FAIL notice
7 permission failed
User Password
1.0.62351.14.3
USER_PW_CHANGE_FAIL_SHORT notice change failed - too
8
short
User Password
1.0.62351.14.3
USER_PW_CHANGE_FAIL_POLICY notice change failed -
9
policy check failed
1.0.62351.14.4 User session role
USER_SESSION_ROLE_CHANGE_OK notice
0 changed successfully
1.0.62351.14.4 User session role
USER_SESSION_ROLE_CHANGE_FAIL notice
1 change failed
1.0.62351.14.4 Role assignment
USER_ROLE_REMOVED_FAIL notice
2 removal failed
1.0.62351.14.4 User permission
USER_PERMISSION_REMOVED_FAIL notice
3 removed failed
1.0.62351.14.4 New role creation
NEW_ROLE_CREATE_FAIL notice
4 failed
1.0.62351.14.4
ROLE_DELETED_FAIL notice Role deletion failed
5
TCP communication
1.0.62351.14.4
TCP_COMM_LOG_SUBS_FAIL alarm with security log
6
subscriber failed
Log data hash check
1.0.62351.14.4
LOG_DATA_HASH_FAIL alarm failed (Log data
7
altered)
TCP communication
1.0.62351.14.4
TCP_COMM_LOG_PUBL_FAIL alarm with security log
8
publisher failed
TCP communication
1.0.62351.14.4 with security log
TCP_COMM_LOG_SRV_FAIL alarm
9 server failed - Event
not sent
Communication
1.0.62351.14.5
COMM_CS_NEGOTIATION_FAIL alarm failure - Cipher suite
0
negotiation failed
Communication
1.0.62351.14.5
COMM_KEY_NEGOTIATION_FAIL alarm failure - Key
1
negotiation failed
Communication
1.0.62351.14.5
COMM_PEER_AUTHENTICATION_FAIL alarm failure - Peer
2
authentication failed
Communication
COMM_PACKET_AUTHENTICATION_FAI 1.0.62351.14.5
alarm failure - Packet
L 3
authentication failed
1.0.62351.14.5 Security log file
LOG_FILE_DEL_BY_USER alarm
4 deleted by user
1.0.62351.14.5 Security log file
LOG_FILE_DEL_BY_SYS notice
5 deleted by system
1.0.62351.14.5 Security logs edited
LOG_FILE_EDIT_BY_USER alarm
6 by user
1.0.62351.14.5 SSL Connection
SSL_CONN_OK notice
7 successful
SSL
1.0.62351.14.5
SSL_CERT_ACCEPTED_OK alarm connection/certificat
8
e accepted
TLS certificate
1.0.62351.14.5
TLS_CERT_CHECK_DIS_OK alarm validation check
9
disabled successfully
SSL Connection
1.0.62351.14.6
SSL_CONN_FAIL_CERT alarm failed - Certificate
0
validation failed
1.0.62351.14.6 SSL Connection
SSL_CONN_FAIL_IKE alarm
1 failed - IKE failed
1.0.62351.14.6 Time sync source
TIME_SYNC_SRC_OK notice
2 OK
1.0.62351.14.6 Time sync source
TIME_SYNC_SRC_FAIL notice
3 failed
Virus detected by
1.0.62351.14.6 Antivirus software
AV_VIRUS_FOUND alarm
4 running on the
source
Failed to update
1.0.62351.14.6
AV_UPDATE_FAIL notice Antivirus signatures
5
on the source
New certificate
1.0.62351.14.6
NEW_CERT_GEN_OK notice generated
6
successfully
CSR approved and
1.0.62351.14.6
PKI_CSR_OK alarm certificate issued
7
successfully
1.0.62351.14.6 Certificate Signing
PKI_CSR_FAIL alarm
8 request failed
1.0.62351.14.6 Certificate about to
PKI_CERT_EXP_NEAR alarm
9 expire
1.0.62351.14.7 Certificate validation
X509_CERT_OK alarm
0 succeeded
1.0.62351.14.7 Certificate validation
X509_CERT_FAIL alarm
1 failed
Certificate validation
1.0.62351.14.7
X509_CERT_EXPIRED alarm failed - Certificate
2
expired
1.0.62351.14.7
X509_CERT_REVOKED alarm failed - Certificate
3
revoked
1.0.62351.14.7 failed - Certificate
X509_CERT_UNTRUSTED alarm
4 signature check
failed
Transfer CRL into

1.0.62351.14.7
CRL_TRANSFER_OK notice the entity
5
successfully
1.0.62351.14.7 Failed to transfer the
CRL_TRANSFER_FAIL alarm
6 CRL into the entity
Unknown certificate
1.0.62351.14.7
CRL_NOT_AVAILABLE alarm revocation status.
7
CRL not available
1.0.62351.14.7
CRL_EXPIRED alarm CRL expired
8
OCSP
1.0.62351.14.7
OCSP_COMMUNICATION_FAIL notice communication
9
failure
OCSP: Unknown
1.0.62351.14.8
OCSP_UNKNOWN_STATUS notice certificate revocation
0
status
Certificates
1.0.62351.14.8
TRANSFER_CERTS_OK notice transferred to the
1
entity successfully
1.0.62351.14.8 Unidentified Syslog
UNKNOWN_SYSLOG_EV notice
2 event
Installed entity
1.0.62351.14.8
ADD_ENTITY_CERT_OK alarm certificate
3
successfully
Removed entity
1.0.62351.14.8
REMOVE_ENTITY_CERT_OK alarm certificate
4
successfully
Installed trust
1.0.62351.14.8
ADD_TRUST_ANCHOR_CERT_OK alarm anchor certificate
5
successfully
Removed trust
1.0.62351.14.8
REMOVE_TRUST_ANCHOR_CERT_OK alarm anchor certificate
6
successfully
Failed to transfer
1.0.62351.14.8
TRANSFER_CERTS_FAIL notice certificates to the
7
entity
Failed to read
1.0.62351.14.8
READ_CERTS_FAIL notice certificates from the
8
entity
1.0.62351.14.8 Password file
TRANSFER_PW_FILE_OK notice
9 transferred and
stored in the entity

successfully
Password file read
1.0.62351.14.9
READ_PW_FILE_OK notice or exported from the
0
entity successfully
Failed to transfer
1.0.62351.14.9
TRANSFER_PW_FILE_FAIL notice password file to the
1
entity
Failed to read
1.0.62351.14.9
READ_PW_FILE_FAIL notice password file from
2
the entity
SYSLOG-26 : Informations relatives à la sécurité des documents XML RS-6538

relatifs à la sécurité des documents XML (cf. IEC 62351-11) qui doivent être journalisés par
les équipements qui ont implémenté les mécanismes correspondants. Ces événements sont
rappelés ci-dessous.
Severity Cyber security event

MNEMONIC Text
(Sev) Object Identifier (OID)
XML signature
XML_SIG_GEN_SUCCESS notice 1.0.62351.11.0 generation
successful
XML signature
XML_SIG_GEN_FAIL alarm 1.0.62351.11.1
generation failed
8. TLS : Sécurisation des flux TCP par TLS

8.1 Description

Key RS-6149
Répond aux besoins RS-5821 - Confidentialité des mesures physiques classées ICS
RS-5826 - Confidentialité et intégrité des systèmes d'administration
RS-5751 - Intégrité des flux d'informations du poste électrique
RS-5936 - ANSSI-03 : Recommandations sur TLS
Transport Layer Security (TLS), ou en français sécurité pour la couche de transport est un
protocole de sécurisation des échanges TCP/IP. TLS a pour prédécesseur « Secure Sockets
Layer (SSL) ». Les flux TCP sont protégés en intégrité et authenticité, ou en intégrité
seulement, par le protocole TLS.
TLS-01 : Versions du protocole TLS RS-6152

Les seules versions du protocole autorisées pour R#SPACE seront TLS 1.2 et TLS 1.3, en
application des règles ANSSI R3, R4 (voir guide ANSSI sur le déploiement de TLS).
TLS-02-01 : Suites cryptographiques d'intégrité seule, pour TLS 1.2 RS-6169

Pour la sûreté, seule l'intégrité des informations et des commandes est impérative. Aussi
lorsqu'il est nécessaire que le trafic soit observable, une suite cryptographique offrant intégrité
seule doit être utilisée. Le support d'au moins une des deux suites suivantes est demandé côté
serveur. Côté client, les deux suites suivantes doivent être supportées, pour pouvoir interagir
avec n'importe quel serveur.
 TLS_ECDHE_ECDSA_WITH_NULL_SHA (clé du serveur ECDSA, PFS, mais HMAC-SHA1
pour l'intégrité).
 TLS_RSA_WITH_NULL_SHA256 (clé du serveur RSA, pas de PFS, mais HMAC-SHA256
pour l'intégrité).
Nota :
 l'utilisation de SHA1, bien que déconseillée (car non conforme au RGS de l'ANSSI) ne
pose pas de problème dans le cas d'un HMAC.
 les clés RSA sont en phase d'obsolescence, car les tailles de clés deviennent trop
grandes.
TLS-02-02 : Suites cryptographiques de chiffrement pour TLS 1.2 RS-6150

Quand la confidentialité est nécessaire, seules des suites avec PFS (Perfect Forward Secrecy,
la clé de session ne peut pas être retrouvée a posteriori) sont conservées, et seul le support
des clés ECDSA et RSA est demandé (pas de PSK). Ne sont conservées que des suites encore
recommandées par l'IETF et conformes au RGS, afin d'atteindre les objectifs d'interopérabilité,
de performance et d'agilité cryptologique en cas de découverte de vulnérabilités. Parmi les
suites recommandées sur https://www.iana.org/assignments/tls-parameters/tls-
parameters.xhtml, ne sont donc conservées que les suites suivantes :
Pour l'utilisation de clés RSA, côté serveur :

 TLS_DHE_RSA_WITH_CHACHA20_POLY1305_SHA256
 TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305_SHA256
 TLS_DHE_RSA_WITH_AES_256_CCM
 TLS_DHE_RSA_WITH_AES_128_CCM
 TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384
 TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
 TLS_DHE_RSA_WITH_AES_256_GCM_SHA384
 TLS_DHE_RSA_WITH_AES_128_GCM_SHA256
Pour l'utilisation de clés ECDSA, côté serveur :

 TLS_ECDHE_ECDSA_WITH_CHACHA20_POLY1305_SHA256
 TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384
 TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256
TLS-02-03 : Extensions nécessaires pour TLS 1.2 RS-6155

Nous listons ici les extensions nécessaires, dans le cadre de l'utilisation de TLS 1.2 dans
R#SPACE. Par souci d’exhaustivité, nous mentionnons à la fin les extensions non utiles et donc
non nécessaires.
Extensions nécessaires pour TLS 1.2 :

La recommandation R13 du guide ANSSI recommande le support des extensions suivantes :
 supported_groups (0x000A) : Extension définie par le RFC 8422, permet
d'informer sur les courbes elliptiques supportées par les deux parties pour l'échange
de clé ECDH.
 signature_algorithms (0x000D) : Extension définie par le RFC 5246, pour
l'utilisation des algorithmes de hachage.
 encrypt_then_mac(0x0016) : Cette extension, définie dans le RFC 7366 n'est
nécessaire que si une suite non AEAD est utilisée (typiquement AES-CBC). Ne
s'applique donc qu'au cas TLS 1.2.
 extended_master_secret (0x0017) : Extension définie par le RFC 7627
 renegotiation_info(0xFF01) : Extension définie par le RFC 5746 voir guide ANSSI
§2.4
Extensions non nécessaires pour TLS 1.2 :
 signed_certificate_timestamp, aussi appelé sct (0x0012) : Cette extension, définie par

le RFC 6962 permet de lier le certificat présenté, à une trace dans un journal public
("log Certificate Transparency") de l'IGC, dans le but de faciliter la détection de
certificats frauduleux ou invalides. Certificate Transparency est très lié à une
utilisation sur le réseau Internet public, et à la présence de multiples IGC, et ne sera
donc pas utilisé pour le CCN.
TLS-03-01 : Suites cryptographiques d'intégrité seule, pour TLS 1.3 RS-6151

Pour la sûreté, seule l'intégrité des informations et des commandes est impérative. Aussi
lorsqu'il est nécessaire que le trafic soit observable, une suite cryptographique offrant
seulement l'intégrité, sans chiffrement, doit être utilisée. Une telle suite est en cours de
standardisation (https://tools.ietf.org/html/draft-camwinget-tls-ts13-macciphersuites-02) et
sera certainement prise en compte dans la CEI 62351.
TLS-03-02 : Suites cryptographiques de chiffrement pour TLS 1.3 RS-6173

Si la protection de la confidentialité est nécessaire, en plus de l'exigence d'authentification

pour la sûreté, les cinq suites du protocole doivent être supportées :
 TLS_AES_128_GCM_SHA256
 TLS_AES_256_GCM_SHA384
 TLS_CHACHA20_POLY1305_SHA256 (RFC 5439)
 TLS_AES_128_CCM_SHA256
 TLS_AES_128_CCM_8_SHA256 (RFC 6655)
TLS-03-03 : Détails pour TLS 1.3 RS-6156

Cas du 0-RTT
TLS 1.3 implémente un mécanisme de rétablissement immédiat de connexion en réutilisant
une clé précédemment négociée, sans aucun échange de paquet (d'où le 0-RTT). Ce
mécanisme permet une attaque par rejeu (replay attack), même si l'attaquant ne sais pas a
priori ce qu'il rejoue (mais souvent le contexte lui permet). Il s'ensuit que le 0-RTT ne devra
être activé que pour accéder à des ressources statiques ou des actions idempotentes.
Le mécanisme 0-RTT doit être désactivé dans le cas général.

Exception : Le mécanisme 0-RTT peut être toléré à certains endroits, moyennant la fourniture
d'éléments de preuve que l'accès est limité à des actions idempotentes. Pour une discussion
complète sur la sécurité de TLS 1.3, voir https://github.com/tlswg/tls13-spec/issues/1001.
Extensions nécessaires pour TLS 1.3

Aucune actuellement.
Extensions non utiles pour TLS 1.3

L'extension Encrypted SNI (encore en draft https://datatracker.ietf.org/doc/draft-rescorla-tls-
esni/) n'apporte aucun bénéfice de sécurité dans le contexte de R#SPACE (où un équipement
remplis une seule fonction, un attaquant en position d'observer le trafic n’obtiendrait pas moins
d'information en présence de SNI chiffré). L'extension n'a néanmoins pas d'effet négatif, et si
elle est supportée, n'a pas besoin d'être désactivée.
TLS-04-01 : Support du protocole OCSP par les clients TLS RS-6167

toujours valide (cf. RS-6123 - IGC-11 : Répondeur OCSP de validité des certificats). Les clients
TLS devront supporter l'extension TLS status_request RFC 6066, OCSP stapling), et en cas de
support par le serveur, devront vérifier la réponse OCSP attachée par celui-ci à la connexion.
En l'absence d'une réponse OCSP attachée au certificat du serveur à l'ouverture de session

(OCSP stapling), le client devra, si l'attribut désignant le répondeur OCSP est bien présent dans
le certificat, contacter le répondeur OCSP pour vérifier la validité du certificat.
 En présence de la réponse "certificat connu (good)", l'établissement de connexion peut
procéder.
 En présence de la réponse "certificat révoqué (revoked)" ou "certificat inconnu
(unknown)", l'établissement de connexion doit être interrompu et une alerte de sécurité
levée.
En cas de problème technique (réponse en erreur du répondeur OCSP, ou absence de

réponse), la connexion doit être établie mais une alerte de sécurité levée. Ceci favorise la
disponibilité au léger détriment de l'assurance que le certificat est encore valide.
Note : il n'y a pas de service agrafage de réponse OCSP (OCSP stapling) pour le certificat du
client dans TLS.
TLS-04-02 : Support du protocole OCSP par les serveurs TLS RS-6168

toujours valide. La pile TLS du serveur doit supporter l'extension status_request ( RFC 6066,
couramment appelée "OCSP stapling" que l'on peut traduire par « agrafage OCSP »), afin que
le serveur puisse fournir dès l'établissement de la connexion une preuve courante de non
révocation de son certificat. Les serveurs TLS devront renouveler régulièrement la réponse
OCSP, agrafée à leur certificat, qui indique qu'à l'heure de l'émission de la réponse, le certificat
n'avait pas été révoqué.
Pour l'authentification du client, en l'absence de mécanisme équivalent pour leur certificat

(l'OCSP stapling malheureusement non supporté pour les clients dans TLS) le serveur devra
faire une requête OCSP pour vérifier que le certificat présenté n'a pas été révoqué.
9. Contraintes
ANSSI-01 : Non-réplication des mots de passe nationaux RS-5959
L'ANSSI demande que les mots de passe nationaux de l'AD industriel ne soient pas répliqués
localement sur les machines du site, ceci afin d'éviter d'exposer les hachés des mots de passe.
En particulier, dans son document NP_ActiveDirectory_NoteTech, l'ANSSI précise la chose

suivante lors de la mise en place d'un RODC (règle 4, priorité 1) :
« La fonctionnalité permettant la mise en cache des informations d’identification des
utilisateurs sur un RODC doit être utilisée uniquement pour mettre en cache les informations
de connexion des comptes utilisateurs sans privilège du site. Si la sécurité physique du RODC
n’est pas garantie, les informations de connexion des comptes avec privilèges ou des comptes
d’utilisateurs n’appartenant pas au site ne doivent pas y être stockées afin de limiter les risques
de compromission de l’annuaire. »
ANSSI-02 : Choix et dimensionnement des mécanismes cryptographiques RS-6171
L'annexe B2 du RGS (Référentiel Général de Sécurité de l'ANSSI) disponible à l'URL

https://www.ssi.gouv.fr/uploads/2015/01/RGS_v-2-0_B1.pdf fixe le cadre de ce qui est
acceptable en matière d'algorithmes cryptographiques, et conditionne donc le sous-ensemble
de l'IEC 62351 acceptable par Rte, particulièrement dans la configuration des protocoles
faisant usage de la cryptographie, tels que GDOI et TLS. En découle notamment l'interdiction
de l'utilisation des algorithmes faibles suivants.
Algorithmes de condensat :
 MD5, même dans la construction HMAC,
 SHA-1, même dans la construction HMAC.
Algorithmes de chiffrement :
 RC4, à cause du biais exploitable,
 TripleDES (taille de bloc trop petite, niveau de sécurité effectif de la clé inférieur à
128 bits d’entropie).
En découle par ailleurs l'interdiction des tailles trop faibles pour le dimensionnement de
certains algorithmes :
 L'interdiction de clés RSA de taille inférieure à 2048 bits,
 L'interdiction des groupes DH de taille inférieure à 2048 bits pour les échanges de
clés.
En découle aussi les recommandations suivantes :

 Préférer les configurations des protocoles garantissant la propriété de PFS (Perfect
Forward Secrecy) quand elle est disponible,
 Préférer les modes de chiffrement AEAD,

 préférer les constructions encrypt-then-mac à mac-then-encrypt quand AEAD n'est
pas disponible.
ANSSI-03 : Recommandations sur TLS RS-5936
Le document "Recommandations de sécurité relatives à TLS" de l'ANSSI met en place des

règles à respecter pour un déploiement sécurisé de TLS, (cf.
https://www.ssi.gouv.fr/actualite/le-nouveau-guide-de-recommandations-de-securite-
relatives-a-tls/).
Ces règles sont à modérer par l'arrivée depuis de TLS 1.3 (RFC 8446) et le fait que dans
certains cas une suite cryptographique en intégrité pure (authentification des deux parties ou
du serveur seul, et authentification des trames sans chiffrement) peut être désirable en cas de
besoin de confidentialité nul et pour favoriser l'observabilité du trafic (cas de la résolution
d'incidents). Par ailleurs l'IETF maintient aussi une liste de fonctionnalités conseillées de TLS.
Nos exigences font un travail d'unification des recommandations ANSSI, IETF et IEC 62351,
en rendant ainsi certaines fonctionnalités - optionnelles pour l'IEC 62351 - obligatoires pour
RTE.
ANSSI-04 : Recommandations sur SSH RS-6329
Le document "Recommandations pour un usage sécurisé d'(Open)SSH", note technique N°

DAT-NT-007/ANSSI/SDE/NP de l'ANSSI met en place des règles à respecter pour un
déploiement sécurisé de SSH.
(Cf. https://www.ssi.gouv.fr/uploads/2014/01/NT_OpenSSH.pdf).
ANSSI-05 : Recommandations pour le cloisonnement du système RS-6340
Le guide de l'ANSSI intitulé "Recommandation pour la mise en place de cloisonnement

système", fournit un ensemble de recommandations permettant de restreindre les
conséquences possibles de comportements inattendus, et donc de ralentir la progression d'une
attaque.
Cf.https://www.ssi.gouv.fr/uploads/2017/12/guide_cloisonnement_systeme_anssi_pg_040_v
1.pdf.
CRE-01 : Confidentialité des informations commercialement sensibles RS-5820
Le code de l'énergie (article L.111-72) prévoit que « chaque gestionnaire de réseau public de
transport d'électricité préserve la confidentialité des informations d'ordre économique,
commercial, industriel et financier ou technique dont la communication serait de nature à
porter atteinte aux règles de concurrence libre et loyale et de non-discrimination. La liste de
ces informations est déterminée par décret en Conseil d'État. Les mesures prises par les
opérateurs pour assurer leur confidentialité sont portées à la connaissance de la Commission
de Régulation de l'Énergie ». Ces Informations Commercialement Sensibles (ICS) sont définies
dans le code l'énergie.
Les courbes de charge des clients de Rte - hormis celles des producteurs de plus de 100 MW
- sont considérées comme des Informations Commercialement Sensibles et ne doivent pas
être divulguées en dehors de Rte. Pour les producteurs avec un raccordement de plus de
100 MW, les données de production sont libres (règlement REMIT).
Au sein de Rte, les ICS peuvent être de diffusion confidentielle ou restreinte, selon l’analyse
de la typologie des données faites par les métiers. La directive confidentialité (DIR-ACI-DAR-
04-00023 indice 3) actuellement en vigueur recommande d’utiliser la classification "diffusion
restreinte" dans la majeure partie des cas. Pour mémoire, une donnée classifiée "RTE" est
confidentielle vis-à-vis de l’externe.
On notera par ailleurs que les sanctions en cas de non-respect des règles de confidentialité
sont très fortes, nominatives et relèvent du droit pénal, d'où l'importance des actions de
sensibilisation réalisées à RTE et l'importance des mesures mises en œuvre pour éviter tout
incident de confidentialité.
FIN DU DOCUMENT

(Rte-Cyber) NT-DI-CNER-DCCL-PIM-19-00210-Ind.2 RSPACE Specs Cybersécurité Des Lots SAMU-SCU-BCU

Transféré par

Informations du document

Titre original

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

(Rte-Cyber) NT-DI-CNER-DCCL-PIM-19-00210-Ind.2 RSPACE Specs Cybersécurité Des Lots SAMU-SCU-BCU

Transféré par

Droits d'auteur :

Formats disponibles

Date d’approbation : 23/09/2019

Projet R#SPACE - Spécifications de cyber sécurité des

Documents annulés : [Documents annulés]

Accessibilité : Filières : Domaine GED :

RTE Métier DI Privé

Processus local DEVIN

Centre National Expertise Réseaux

Rédacteurs Vérificateurs Approbateurs

Lieu de conservation (ou...) : [Lieu de conservation]

1.1 Sans l’Infrastructure de Gestion de Clés de Rte

Les exigences du paquet n°1 sont :

1.2 Sécurisation de l’accès au réseau local

Les exigences du paquet n°2 sont :

Les exigences du paquet n°3 sont :

1.4 Signatures et révocations

Les exigences du paquet n°4 sont :

1.5 Sécurisation des messages rapides

Les exigences du paquet n°5 sont :

2. ADMS : Administration sécurisée

Priorité Phase 1 - Pilotes Fonction modifiée le 2019-07-25

Les protocoles d'administration doivent assurer :

2.2 Exigences fonctionnelles

ADMS-01 : Chiffrement du flux d'administration RS-5831

ADMS-02 : Confidentialité et intégrité des flux SNMP de gestion des RS-5829

En cas d'utilisation de SNMP pour superviser et administrer des équipements (commutateurs

Utilisation du "Transport Security Model" (TSM)

Utilisation du "User Security Model" (USM)

ADMS-03 : Vérification des signatures des logiciels RS-6198

En introduction, nous présentons les principes du mécanisme de signature des logiciels :

ADMS-04 : Vérification de la signature des fichiers de configuration RS-6207

ADMS-05 : Enrôlement des équipements dans l'IGC RS-6224

Les protocoles retenus sont EST et SCEP :

Autant que possible, l'enrôlement sera automatique : à la connexion au réseau, la machine

ADMS-05-01 : support en priorité du protocole d'enrôlement EST RS-6211

ADMS-05-02 : Support du protocole d'enrôlement SCEP RS-6212

Pour le protocole d'enrôlement SCEP il est donc demandé :

ADMS-06 : Port dédié au réseau local d'Administration RS-6216

Le système R#SPACE vise la ségrégation des flux d’administration issus du Poste

ADMS-07 : Sessions administratives des IED, RBAC et temporisation RS-6409

Pour l'établissement d'une connexion d'administration sur l'équipement, conformément au

Valeurs Valeur par

Note : la valeur 0 pour la temporisation signifie que le mécanisme de déconnexion

ADMS-09 : Configuration du répondeur OCSP de validité des certificats RS-6440

ADMS-10 : Configuration du point de distribution de la liste de RS-6442

3. EXPS : Exploitation sécurisée

3.2 Exigences fonctionnelles

EXPS-01 : Sécurisation des flux MMS RS-6221

EXPS-02 : Sécurisation des Sampled Values et GOOSE RS-6205

EXPS-03 : Utilisation de certificats pour l'authentification RS-6222

La session ouverte sur le PO ou le PA utilisera le certificat de deux manières :

EXPS-04 : Déconnexion automatique des utilisateurs RS-4357

Pour les IHM :

Pour les connexions MMS :

EXPS-06 : Durcissement des IED contre les cyber-attaques RS-6303

 Réduction de la surface d'attaque : toutes les interfaces exposées devront être

Dans le cas où une instance de Linux tourne sur un IED :

EXPS-07 : Durcissement des machines Linux contre les cyberattaques RS-6306

4. GDOI : Service de distribution de clés de session dans

Priorité Phase 1 - Hors Fonction modifiée le 2019-07-25

4.2 Exigences fonctionnelles

GDOI-01 : Protocole IKE v1, authentification des clients. RS-6175

GDOI-02 : IKE v1, Modes RS-6177

GDOI-03 : IKE v1, Groupes de Galois RS-6179