Securite Industrielle GT Details Principales Mesures

.
Mesures dtailles
La cyberscurit des systmes industriels
Table des matires

.
1 Introduction
1.1 Contexte
1.2 Champ dapplication
1.3 Structure du corpus documentaire
1.4 Avis aux lecteurs
2 Considrations relatives la cyberscurit des installations industrielles 9

2.1 Liste des contraintes
2.2 Vulnrabilits
16
2.2.1 Matrise des installations
16
2.2.2 Dfaut de contrle daccs logique
18
2.2.3 Dfaut de contrle des interfaces de connexion
19
2.2.4 Cartographie non maitrise
19
2.2.5 Dfaut de matrise de la configuration
20
2.2.6 Utilisation dquipements vulnrables
21
2.2.7 Utilisation de protocoles vulnrables
22
2.2.8 Dfaut de contrle daccs physique
23
2.2.9 Dfaut de cloisonnement
23
2.2.10 Tlmaintenance
24
2.2.11 Terminaux nomades non matriss
24
2.2.12 Utilisation de technologies standards
25
2.2.13 Intervenants
25
2.2.14 Supervision insuffisante des vnements de cyberscurit
26
2.2.15 Absence de plan de continuit dactivit
26
2.2.16 Non prise en compte de la cyberscurit dans les projets
27
La cyberscurit des systmes industriels Mesures dtailles . 3
2.2.17 Absence de tests de cyberscurit
27
2.2.18 Absence de matrise des fournisseurs et prestataires
27
2.2.19 Environnement de dveloppement non scuris
28
2.2.20 Outils de dveloppement prsents
28
2.2.21 Non cloisonnement de ladministration
28
2.2.22 Dfinition des responsabilits
29
3 Mesures de scurit organisationnelles
31
3.1 Connaissance du systme industriel
32
3.1.1 Rles et responsabilits
32
3.1.2 Cartographie
33
3.1.3 Analyse de risque
34
3.1.4 Gestion des sauvegardes
35
3.1.5 Gestion de la documentation
35
3.2 Matrise des intervenants
36
3.2.1 Gestion des intervenants
36
3.2.2 Sensibilisation et formation
37
3.2.3 Gestion des interventions
38
3.3 Intgration de la cyberscurit dans le cycle de vie du systme industriel 39

3.3.1 Exigences dans les contrats et cahiers des charges
40
3.3.2 Intgration de la cyberscurit dans les phases de spcification 42

3.3.3 Intgration de la cyberscurit dans les phases de conception
43
3.3.4 Audits et tests de cyberscurit
44
3.3.5 Transfert en exploitation
45
3.3.6 Gestion des modifications et volutions
46
3.3.7 Processus de veille
47
4 . La cyberscurit des systmes industriels Mesures dtailles
3.3.8 Gestion de lobsolescence

3.4 Scurit physique et contrle daccs aux locaux
47
48
3.4.1 Accs aux locaux
48
3.4.2 Accs aux quipements et aux cblages
49
3.5 Raction en cas dincident
50
3.5.1 Plan de reprise ou de continuit dactivit
50
3.5.2 Modes dgrads
51
3.5.3 Gestion de crise
52
4 Mesures de scurit techniques

4.1 Authentification des intervenants : contrle daccs logique
53
54
4.1.1 Gestion des comptes
54
4.1.2 Gestion de lauthentification
57
4.2 Scurisation de larchitecture du systme industriel
59
4.2.1 Cloisonnement des systmes industriels
59
4.2.2 Interconnexion avec le systme dinformation de gestion
62
4.2.3 Accs Internet et interconnexions entre sites distants
63
4.2.4 Accs distants
64
4.2.5 Systmes industriels distribus
66
4.2.6 Communications sans fil
66
4.2.7 Scurit des protocoles
68
4.3 Scurisation des quipements
69
4.3.1 Durcissement des configurations
69
4.3.2 Gestion des vulnrabilits
72
4.3.3 Interfaces de connexion
74
4.3.4 quipements mobiles
75
4.3.5 Scurit des consoles de programmation, des stations dingnierie et des postes dadministration
76
4.3.6 Dveloppement scuris
78
4.4 Surveillance du systme industriel

4.4.1 Journaux dvnements
A Cartographie
A.1 Cartographie physique du systme industriel
79
79
83
83
A.1.1 Inventaire
83
A.1.2 Schma
84
A.2 Cartographie logique des rseaux industriels
84
A.2.1 Inventaires
84
A.2.2 Schma
85
A.3 Cartographie des applications
86
A.3.1 Inventaires
86
A.3.2 Schma
86
A.4 Cartographie de ladministration et de la surveillance du systme dinformation
86
B Journaux dvnements
89
Bibliographie
91
Chapitre 1
.
Introduction
1.1 Contexte
Le prsent document est issu des rflexions du groupe de travail sur la cyberscurit des systmes industriels pilot par lAgence nationale de la scurit des systmes
dinformation (ANSSI) 1 . Lobjectif des travaux de ce groupe, constitu dacteurs du
domaine des systmes automatiss de contrle des procds industriels et de spcialistes de la scurit des systmes dinformation (SSI), est de proposer un ensemble de
mesures pour amliorer le niveau de cyberscurit des systmes industriels.
Ce document sadresse tous les acteurs (entits responsables, chefs de projets,
acheteurs, quipementiers, intgrateurs, matres duvre, etc.) participant la conception, la ralisation, lexploitation et la maintenance des systmes industriels.
1.2 Champ dapplication

Le groupe de travail ne sest pas intress un secteur dactivit en particulier et les
lments contenus dans ce document ont donc vocation tre applicables tous les
secteurs. Certains dentre eux ont des spcificits qui nont peut-tre pas t dtailles
ou prises en compte dans le prsent document. En consquence, une dclinaison
sectorielle de ce document pourra tre ncessaire dans certains cas an de
prciser les modalits dapplication et prendre en compte les contraintes spciques.
Lensemble des mesures prsentes ont t penses pour des nouveaux systmes
industriels. Il est tout fait possible que les mesures ne puissent pas sappliquer
directement des systmes industriels existants et il conviendra donc dvaluer de
manire exhaustive les impacts avant toute mise en uvre.
1. Les membres du groupe de travail sont les socits et organismes suivants : Actemium, Airbus
Defence and Space, Arkoon-Netasq, A.R.C Informatique, Atos Worldgrid, Hirschmann, Cassidian
Cybersecurity, CEA, CLUSIF, DCNS, DGA Matrise de linformation, Euro systems, EXERA, GDF SUEZ,
Gimlec, INERIS, Itris Automation Square, Lexsi, Schneider Electric, Siemens, Sogeti, RATP, Solucom,
Thales, Total.
Il est galement possible que dans certaines situations des mesures ne puissent sappliquer sans adaptation (pour des raisons de compatibilit avec des systmes industriels existants ou des contraintes mtier spcifiques, par exemple). Ces cas particuliers
devront tre tudis spcifiquement et les mesures qui en dcouleront seront soumises
pour approbation lautorit de cyberdfense.
1.3 Structure du corpus documentaire

Les travaux du groupe de travail sont organiss en deux documents. Ce document
contient les mesures techniques et organisationnelles dtailles mettre en place sur
les systmes industriels en fonction des classes dfinies dans le guide de classification [13].
Il est donc important de commencer par lire attentivement le document cit prcdemment qui constitue le socle de la dmarche et contient la dfinition des termes
utiliss dans la suite de ce document.
1.4 Avis aux lecteurs

Les mesures prsentes dans le document sont des mesures de cyberscurit conventionnelles mais adaptes pour les systmes industriels. Lobjectif de ce document nest
en aucun cas de former les lecteurs la cyberscurit pour les systmes industriels.
Il a donc t suppos que les lecteurs disposaient de connaissances lmentaires
en matire de technologies de linformation et de la communication mais aussi de
cyberscurit ou quils pouvaient sappuyer sur des personnes disposant de ces comptences. La bonne application de certaines mesures ncessitera certainement un
travail dquipe entre des informaticiens et des automaticiens .
Note
Les publications de lANSSI sont diffuses sur son site Internet :
http://www.ssi.gouv.fr/publications/.
.
Toute
remarque
sur
ce
guide
peut
tre
adresse
systemes_industriels@ssi.gouv.fr.
Chapitre 2
.
Considrations relatives la
cyberscurit des installations
industrielles
Lobjectif de ce chapitre est de dresser un tat des lieux succinct de la cyberscurit des
systmes industriels. Pour ce faire, une liste des contraintes qui sont prsentes dans
ces systmes est tablie dans la section 2.1. Ces contraintes sont un des lments
qui distingue les systmes industriels des systmes dinformation de gestion. Il est
important de les identifier afin de proposer des mesures adaptes.
Dans la section 2.2, les principales vulnrabilits rencontres dans ces systmes sont
listes. Elles peuvent dcouler des contraintes listes dans la section prcdente mais
pas seulement. En particulier, on pourra retrouver dans cette section, des vulnrabilits couramment rencontres dans les systmes dinformation de gestion.
2.1 Liste des contraintes

Les contraintes sont un ensemble de faits sur lesquels il ne va pas tre possible dagir
et qui peuvent avoir un impact lourd sur la scurit du systme industriel concern. Il
sera trs important de prendre en compte ces contraintes lors du choix des mesures
de scurit mettre en uvre.
Rfrences
C1-MI
Thmes
Matrise des
installations
Contraintes
Multitude dintervenants sur une installation ce qui ne facilite pas la matrise des
actions effectues sur celle-ci.
Multitude de sites isols, notamment
dans les secteurs du transport, de la distribution deau ou de lnergie, bnficiant dune protection physique limite.
La documentation technique de linstallation peut tre limite. Ce qui entrane
une perte du savoir lors des dparts de
personnels et ne facilite pas le traitement
des incidents.
Certains fournisseurs font de la tlmaintenance depuis ltranger.
Sur certaines installations cohabitent
deux oprateurs diffrents, ce qui peut
parfois poser des problmes juridiques
en cas de modification de linstallation.
Par ailleurs, les systmes quils grent
peuvent aussi constituer une menace
entre eux.
Les installations sont souvent htrognes car venant de diffrents fournisseurs ou parce quelles ont volues
au cours du temps. Lhtrognit peut
tre impose pour des raisons de sret
fonctionnelle.
Rfrences
C2-CO
Thmes
Contrats
Contraintes
Les fournisseurs exigent davoir accs
leurs quipements en tlmaintenance
sous peine de ne pas les garantir.
La modification des systmes sans accord pralable du fournisseur peut entrainer une perte de garantie.
Il peut tre contractuellement interdit
de modifier linstallation existante mme
pour implmenter des mesures de cyberscurit.
Certains clients exigent davoir accs
distance aux informations relatives (historisation) la production du site. Pour
des raisons de simplicit, le transfert de
donnes se fait souvent sur un rseau
public comme Internet.
Rfrences
C3-REG
Thmes
Contraintes
Rglementation
Certaines rglementations imposent aux
oprateurs dexporter des donnes vers
un tiers. Par exemple, les dchetteries
doivent fournir un certain nombre de
donnes la DRIRE.
La traabilit est une exigence forte
dans certains domaines comme lagroalimentaire ou lindustrie pharmaceutique par exemple.
Remarque : les mesures de scurit
fonctionnelles imposes par la rglementation dun secteur peuvent renforcer le niveau de scurit de linstallation
et offrir un niveau de risque rsiduel acceptable.
La rglementation en matire de sret
peut limiter la possibilit de modification
des installations. En effet, la modification dune installation peut entraner la
perte dune homologation.
C4-GCH
Gestion
des
changements
Il nexiste pas denvironnement de test

permettant de sassurer de la nonrgression des installations.
Les interventions sur les installations ne
peuvent tre effectues que lors des priodes de maintenances.
Les fournisseurs offrent peu de support
pour aider les oprateurs qualifier les
impacts des mesures de scurit sur les
installations.
Rfrences
C5-OPE
Thmes
Oprations
Contraintes
Certains environnements demandent
une ractivit forte des oprateurs notamment en cas dincident. Les mesures
de scurit ne doivent pas nuire cette
ractivit.
Les oprateurs partagent souvent des
quipements, ce qui peut avoir un impact significatif sur la traabilit (utilisation de comptes gnriques par
exemple).
Les oprateurs doivent souvent visualiser ltat de linstallation en temps rel et
intervenir rapidement. De ce fait, ils ne
peuvent pas verrouiller les postes quils
utilisent.
C6-CECO
Contraintes
conomiques
Les mises jour des systmes existants

et lvolution des installations entranent
des cots importants pour le client.
Rfrences
C7-GOUV
Thmes
Gouvernance
de scurit
Contraintes
Lorsque la direction des systmes dinformation (DSI) se voit attribuer la mission de scuriser les systmes industriels,
elle na pas de lien hirarchique avec les
quipes charges de lopration de ces
derniers. Ceci complique ou ralentit la
mise en uvre de la cyberscurit.
Lorsque la scurisation des systmes industriels est confie une direction mtier, la cyberscurit a souvent une priorit basse et la responsabilit de la gestion des interfaces entre les systmes industriels et les systmes de gestion est
floue.
Il y a peu de personnel en charge de linformatique industrielle sur un site industriel.
Rfrences
C8-CTECH
Thmes
Contraintes
techniques
Contraintes
Les quipements sont dploys pour 15
20 ans. Lobsolescence limite leurs
possibilits de mise jour ainsi que lintgration de fonctions de scurit.
Certains quipements (comme les automates) et protocoles offrent des fonctionnalits de scurit limites voire inexistantes.
Les fournisseurs offrent peu de solutions
techniques permettant une gestion centralise des fonctions de scurit. Par
exemple, il nest souvent pas possible
de changer un mot de passe sur plusieurs quipements disperss gographiquement.
Sur certains systmes, les besoins de performance exigent quil ny ait pas de latence.
C9-CULT
Culture de la
scurit
Dans les milieux o la sret de fonctionnement est trs prsente, il y a souvent un sentiment que celle-ci permet
galement de rgler les problmes de
cyberscurit.
La scurit des systmes dinformation
nest pas aborde lors des cursus de formation et en particulier ceux des automaticiens.
Rfrences
C10-MAT
Thmes
Maturit des
solutions techniques
Contraintes
Il existe peu de comptences en matire de cyberscurit des systmes industriels.
Peu de fournisseurs intgrent la notion de cycle de dveloppement scuris
dans la ralisation de leurs produits.
2.2
Vulnrabilits
Les vulnrabilits des systmes dinformation industriels qui ont t identifies par le
groupe de travail sont listes ci-dessous.
Important
Les encadrs Pourquoi est-ce une vulnrabilit
? nont pas vocation tre
.
exhaustifs et sont l uniquement pour illustrer la vulnrabilit en question.
2.2.1 Matrise des installations

Gestion des correctifs de scurit
La gestion des vulnrabilits est complexe dans les systmes industriels. Dans de
nombreux cas, les mises jour ne pourraient tre faites que pendant les phases
de maintenance et, parfois, leur application peut entrainer la ncessit de requalifier
le systme industriel du point de vue de la sret de fonctionnement.
La priorit est donne lintgrit et la disponibilit de linstallation et, comme
lentit responsable dispose rarement dune plateforme dessai, elle ne peut pas effectuer de tests de non-rgression sur les correctifs ventuellement publis par les
fournisseurs.
Toutes ces raisons font que la plupart des installations nont pas de procdures ou de
mcanismes techniques pour lapplication des mises jour de scurit. En particulier,
les systmes de mise jour automatiques sont souvent incompatibles, notamment
avec les anciennes installations.
Pourquoi est-ce une vulnrabilit ?

La prsence de vulnrabilits connues non corriges dans une installation
augmente le risque dune intrusion.
De nombreux codes malveillants gnriques exploitent ce genre de vulnrabilits et le risque de contamination de linstallation est donc fortement
augment par labsence des mises jour
. de scurit.
Lors dune attaque cible, lattaquant commence souvent par la recherche
de vulnrabilits connues non corriges pour tenter de pntrer dans le systme. Une bonne politique dapplication des mises jour de scurit permet
dliminer ces vulnrabilits, ce qui complique fortement la tche de lattaquant.
Remarque
En 2013, de nombreux systmes industriels sont encore vulnrables aux virus
tels que Conficker apparu en 2009 et. pour lequel le correctif est pourtant
connu.
Pas de veille sur les vulnrabilits et les menaces

Les entits responsables de systmes industriels mettent rarement en place une veille
active sur les vulnrabilits des produits et technologies utiliss. Ceci est vrai malgr
lapparition de sources dinformation spcialises.
Aucune veille nest faite non plus sur lvolution de la menace ou des techniques
dattaque.

Labsence de veille sur les vulnrabilits ou obsolescences de produits ou
technologies utilises empche de ragir rapidement lors de la publication
de lune dentre elles.
.
Une veille active sur les techniques dattaque
ou sur lvolution de la menace
permet damliorer la pertinence de lanalyse de risque du systme industriel.
Elle permet galement dadapter les mesures de protection et de rduire le
temps dexposition du systme aux vulnrabilits.
2.2.2 Dfaut de contrle daccs logique

Dfaut de la politique de gestion des mots de passe
Il est frquent que les politiques de mots de passe soient insuffisantes ou incompltes.
Ceci peut impliquer les problmes suivants :
lutilisation de mots de passe par dfaut ;
la faible frquence de changement des mots de passe (par exemple due au
manque doutil pouvant mettre jour les mots de passe dun parc dautomates) ;
lutilisation de mots de passe faibles (parfois due des limitations de lquipement ou du logiciel).
Une premire tape pour un attaquant consiste souvent tenter de compromettre le compte dun utilisateur du systme pour y avoir accs, au moins
partiellement. Pour cela, une des techniques sa disposition consiste tenter
de rcuprer un mot de passe.
Lutilisation de mot passe par dfaut lui permet donc davoir accs directe. sur linstallation, souvent avec des
ment des comptes prsents par dfaut
privilges levs. Lorsque les mots de passe ont t changs, lattaquant
peut essayer les attaques par dictionnaire pour tenter de dcouvrir un mot
de passe et accder ainsi au compte concern. Cest pourquoi il est recommand dutiliser un mot de passe robuste et, dans la mesure du possible, de
le changer rgulirement.
Pas de gestion des comptes

Il est frquent que la politique de gestion des comptes dun systme industriel soit
inadapte ou inexistante.
Afin de faciliter les oprations, du fait du roulement des oprateurs ou de la multitude
de sites grer pour les quipes de maintenance, des comptes gnriques peuvent
tre utiliss.
Il est frquent quil ny ait pas de procdure de gestion des dparts et des arrives.
En particulier, un ancien employ pourra conserver son compte longtemps aprs son
dpart.
Il est galement courant de voir lutilisation de comptes privilges. Ceci peut tre
d une recherche de facilit de gestion des comptes utilisateurs ou des limitations techniques dun produit utilis. De nombreuses applications, par exemple, ne
sexcutent quavec des comptes de niveau administrateur .
Lutilisation de comptes gnriques augmente considrablement les risques
de compromission notamment du fait de la circulation du mot de passe. En
pratique, les mots de passe utiliss pour les comptes gnriques sont souvent
trop faibles ou nots sur des papiers faciles garer. Ne pas supprimer un
compte aprs le dpart de son titulaire. offre une possibilit daction un ancien employ mcontent. Dautre part, labsence de politique de gestion des
comptes diminue la visibilit sur le systme industriel concern (qui accde
quelles ressources ?). En cas de problme, il sera trs difficile den retrouver
lorigine.
2.2.3 Dfaut de contrle des interfaces de connexion

Sur certains systmes industriels, on note rgulirement une absence de politique de
gestion des interfaces de connexion. Par exemple, les ports USB ne sont pas bloqus
ou les ports Ethernet non utiliss sont laisss actifs.
Laisser des interfaces non matrises augmente la surface dattaque.
Par exemple, ne pas bloquer les ports USB peut favoriser lintroduction de
virus dans le systme ou la non-dsactivation des ports Ethernet offre la pos.
sibilit de raliser des branchements sauvages
pouvant perturber le fonctionnement du systme. Cela peut galement tre utilis pour lancer ultrieurement une attaque depuis lextrieur du site (en connectant un quipement
WiFi par exemple).
2.2.4 Cartographie non maitrise

La cartographie dun systme industriel nest pas forcment matrise. En particulier,
on pourra noter :
une prise en charge de linstallation du cblage rseau comme le cblage lectrique, avec un manque de prise en compte des contraintes de documentation ;
une insuffisance de la cartographie du systme industriel et notamment :

des topologies rseau,
des matrices de flux,
des inventaires des quipements matriels et logiciels du parc industriel,
pas de recensement des procdures dexploitation ;
une absence de vision des gnrations technologiques qui cohabitent et de
leurs vulnrabilits intrinsques.
De plus, lorsquune cartographie existe, les procdures ou les outils qui pourraient
permettre de la maintenir jour ne sont pas forcment mis en uvre.
La cartographie dun systme est un lment fondamental de la scurit des
systmes dinformation.
La bonne connaissance de son installation
permet notamment de dterminer
.
trs rapidement si une vulnrabilit concerne le systme en question, de faire
une analyse de risque pertinente ou de dterminer rapidement et efficacement ltendue dune compromission en cas dincident.
2.2.5 Dfaut de matrise de la conguration

Manque de contrle dintgrit ou dauthenticit
Il est trs rare que des mcanismes de contrle dintgrit ou dauthenticit soient mis
en place pour les firmwares, les logiciels, les programmes dautomates et applications
SCADA.
Labsence de mcanisme de contrle .dintgrit ou dauthenticit permet
un attaquant de diffuser une mise jour pige.
Absence de sauvegarde
Les sauvegardes sont souvent partielles, inexistantes ou disponibles chez le fournisseur
seulement. Lorsque des sauvegardes existent, le bon fonctionnement des procdures
de restauration en cas dincident est rarement test.

En cas de compromission du systme, .les sauvegardes peuvent permettre de
restaurer la configuration de linstallation dans un tat antrieur sain.
Modications en ligne non matrises

Il est possible de modifier chaud, sans mcanisme dauthentification ou de journalisation, des programmes dautomates ou des applications SCADA. Cette fonctionnalit trs utile lorsque les systmes fonctionnent en 24/7 prsente souvent trs peu
de mcanismes de cyberscurit.

Labsence dauthentification ou de journalisation permet un attaquant de
. dun automate. Cette modification
modifier de manire furtive le programme
pourra ne pas tre dtectable par les applications SCADA et les utilisateurs.
2.2.6 Utilisation dquipements vulnrables

Les quipements dvelopps pour les systmes industriels intgrent souvent des contraintes de sret de fonctionnement fortes mais rarement des contraintes de cyberscurit. En particulier, les fonctions de scurit sont souvent limites voire inexistantes
et les techniques de dveloppement employes envisagent rarement la prsence dun
attaquant sur le systme comme une menace.
La configuration des quipements ou logiciels prsents dans le rseau est rarement
durcie. En particulier, les services inutiliss sont souvent laisss activs comme dans
la configuration par dfaut.

Les quipements qui ont t dvelopps sans objectif de cyberscurit sont
plus susceptibles de prsenter des vulnrabilits qui pourront tre exploites
par un attaquant.
Afin de minimiser la surface dattaque,. il est ncessaire de dsactiver ou de
dsinstaller les services et logiciels inutiliss. Ainsi, si une vulnrabilit est
dcouverte dans un de ces composants, le systme industriel ne sera pas
vulnrable.
Remarque
Ninstaller que les lments indispensables est un principe de sret de fonc. risques de dfaillance, simplifie la
tionnement. Cela permet de rduire les
comprhension et la maintenabilit des installations
2.2.7 Utilisation de protocoles vulnrables

Les systmes industriels font souvent usage de protocoles rseaux nintgrant aucun mcanisme de scurit. Ces protocoles peuvent tre des protocoles classiques
comme telnet mais peuvent galement tre des protocoles spcifiques aux systmes
industriels comme Modbus, Profibus, EtherNetIP, etc.
Remarque : EtherNetIp est le nom dun protocole applicatif utilis par certains quipements (automates industriels et logiciels SCADA par exemple).
Diffrentes technologies sans fil (WiFi, GSM, Zigbee) peuvent avoir t adaptes
sans quune analyse de risque ait t mene ou sans que les mesures de protection
adaptes naient t mises en place.

Lutilisation de protocoles non scuriss peut permettre un attaquant de
modifier les trames la vole ou de forger des trames perturbant ainsi le
fonctionnement du systme industriel. Cela peut galement permettre de rcuprer des identifiants de connexion circulant en clair sur le rseau.
.
Lutilisation de technologies sans fil expose
le systme des problmes de
disponibilit car il est facile de brouiller, volontairement ou non, un signal.
Par ailleurs, lorsque linstallation sans fil nest pas scurise correctement,
lattaquant peut ventuellement modifier le trafic lgitime ou injecter du trafic
illgitime plus aisment que dans le cas dune infrastructure filaire.
2.2.8 Dfaut de contrle daccs physique

Dans de nombreux cas, les intervenants (mainteneurs, exploitants, etc) ont besoin de
pouvoir accder physiquement aux installations.
Selon le domaine dactivit, le systme industriel ou ses composants pourraient tre
localiss dans des usines, sur la voie publique ou dans dautres endroits qui ne permettent pas la mise en place dun contrle daccs physique efficace.
Labsence de contrle daccs physique permet un attaquant daccder
. ainsi toutes les protections primdirectement linstallation, contournant
triques qui pourraient avoir t mises en places.
2.2.9 Dfaut de cloisonnement

Il est courant quil ny ait pas de cloisonnement effectif entre un systme industriel
et le systme dinformation de gestion. Cette ouverture des rseaux industriels vers
le systme dinformation de gestion ou un rseau public comme Internet peut tre
due des raisons oprationnelles comme des contraintes de planning ou de mutualisation doutils ou des raisons de rduction de cots pour simplifier la remonte
dinformation du systme industriel vers le systme dinformation de gestion.
Par ailleurs, il est trs courant quil ny ait pas de cloisonnement non plus au sein
mme des systmes industriels ; entre ses diffrents sous-ensembles par exemple. Ceci
peut galement tre d des besoins de rduction de cots ou une mconnaissance
de la ncessit de cloisonner les systmes.

Labsence de cloisonnement entre les systmes facilite le travail dun attaquant qui peut voluer plus facilement dans le systme pour accder son
.
but.
Un cloisonnement efficace permettra aussi de limiter la propagation dun
virus.
Remarque
Le cloisonnement devrait tre une bonne pratique en matire de sret de
.
fonctionnement puisquil permet de limiter
les effets dun dysfonctionnement
des systmes sans mme parler de cyberscurit.
2.2.10 Tlmaintenance
La tlmaintenance et la tlgestion sont des pratiques de plus en plus courantes
pour les systmes industriels. Certains sont mme connects sur des rseaux publics
comme Internet ou les rseaux de tlphonie mobile. Ces accs distance peuvent
avoir t mis en place pour des besoins internes mais galement pour permettre des
oprations de maintenance par le fabriquant ou lintgrateur.
Les solutions techniques employes pour la tlgestion ou la tlmaintenance offrent
dans de nombreux cas un niveau de scurit faible.

Lutilisation daccs distance augmente considrablement la surface dat.
taque dun systme. En effet, il est difficile
de mettre en place des mesures
de protection physique sur ce type daccs.
2.2.11 Terminaux nomades non matriss

Il est de plus en plus courant que les intervenants utilisent des terminaux mobiles
comme des ordiphones ou des tablettes pour augmenter leur productivit en dplacement sur le terrain. Ceci est dautant plus vrai pour des grandes installations
distribues.
La scurit de ces terminaux nest pas forcment matrise et lon commence voir
apparatre lutilisation de matriel personnel pour remplir des missions professionnelles, ce que lon appelle parfois le Bring Your Own Device (BYOD).

Lutilisation de terminaux mobiles la scurit non-contrle augmente leur
. une porte dentre potentielle un
risque de compromission et offre ainsi
attaquant.
2.2.12 Utilisation de technologies standards

Pour des raisons de cot et dinteroprabilit des systmes industriels avec les systmes dinformation de gestion, les technologies utilises pour les premiers sont de
plus en plus standards. Ainsi, en termes de rseau, Ethernet et TCP/IP sont de plus
en plus employs pour remplacer les technologies propritaires qui taient utilises
auparavant. Les outils de dveloppement ou de maintenance font galement de plus
en plus appel des briques gnriques.

Lutilisation de briques standards expose les systmes lensemble des vulnrabilits quelles contiennent. Les systmes industriels sont alors vulnrables
des codes dattaque gnriques. .
A contrario, lutilisation de technologies propritaires ou rares nest pas une
protection en soi mais augmente la complexit ou le cot dune attaque du
fait du besoin de dvelopper soi-mme les programmes malveillants.
2.2.13 Intervenants
Les intervenants sur un systme industriel ne sont pas toujours sensibiliss la cyberscurit des systmes dinformation et ne connaissent pas forcment la politique de
scurit des systmes dinformation (PSSI) du systme sur lequel ils interviennent.

Labsence de sensibilisation la SSI entraine la multiplication des comportements risque pouvant faciliter une. compromission du systme cible. De
nombreux incidents, provenant dun manque de sensibilisation et dapplication de bonnes pratiques, sont rgulirement constats.
2.2.14 Supervision insufsante des vnements de

cyberscurit
En cas dincident sur une installation, les oprateurs et mainteneurs nenvisagent
pas forcment une action malveillante comme cause possible. Les intervenants sont
souvent peu qualifis pour identifier les vnements de cyberscurit.
La journalisation des vnements de scurit est souvent limite et peu exploite. Les
dispositifs de dtection dincidents ou de dysfonctionnements sont rares.
Lorsquune supervision des vnements de cyberscurit est effective, la multitude des
paramtres et la complexit de lenvironnement peuvent limiter lanalyse de lincident.

Ne pas superviser les vnements de cyberscurit dune installation limite
fortement la capacit de dtection et, a fortiori, de raction en cas dincident. Une intervention rapide peut .permettre de limiter les impacts dun
incident. De plus, dans certains cas, lorsque pour des contraintes mtiers
ou techniques il nest pas possible de dployer de mesure de protection, la
supervision est la seule mesure de scurit possible.
2.2.15 Absence de plan de continuit dactivit

Les plans de continuit dactivit ou les plans de reprise dactivit ne prennent pas
forcment en compte les vnements de cyberscurit. Les quipes oprationnelles
disposent rarement de consignes pour ragir un tel vnement. La rdaction dun
plan de gestion de crise pour la perte du contrle dune installation due un vnement malveillant est rarement envisage.

La mise en place de consignes de raction
des vnements de scurit
.
permet de rduire le temps de raction et de retour une situation normale.
2.2.16 Non prise en compte de la cyberscurit dans les

projets
Lors des phases de spcification et de conception du systme industriel, les documents
nintgrent gnralement aucune exigence en matire de cyberscurit.

Pour mettre en place des mcanismes de dfense efficaces, il est ncessaire
de prendre en compte la cyberscurit
. ds les phases initiales des projets
et en particulier ds le cahier des charges. Augmenter le niveau de scurit
dune installation existante est souvent plus compliqu et plus coteux.
2.2.17 Absence de tests de cyberscurit

Les tests avant mise en service (FAT et SAT) contiennent rarement des tests portant
sur la cyberscurit. Lors des oprations de maintenance, des tests de sret ou de
conformit du systme dinformation sont souvent prvus mais pas daudits de cyberscurit.
Pour que la cyberscurit dun systme industriel reste un niveau accep.
table, il est ncessaire de tester les mcanismes
mis en place tout au long de
la vie de linstallation.
2.2.18 Absence de matrise des fournisseurs et prestataires

Dans les projets de systme industriel, un audit du niveau de cyberscurit des fournisseurs et des prestataires est rarement envisag. Aucune procdure dchange scuris des informations nest prvue non plus. La traabilit des modifications lors
des diffrentes phases du projet nest pas prvue.

Dans certains cas, il peut tre plus ais.dattaquer le fournisseur pour toucher
le systme industriel cible que dattaquer le systme cible directement.
2.2.19 Environnement de dveloppement non scuris

Dans les projets de systme industriel, lenvironnement de dveloppement est rarement ddi ou scuris, que ce soit en interne ou chez les fournisseurs. Par exemple,
les machines de dveloppement sont souvent galement les machines de bureautique
et sont donc connectes Internet.
Lutilisation dun mme environnement de travail pour des tches dexposition et de sensibilit diffrentes augmente les risques de compromission.
Un environnement de dveloppement.non scuris, connect Internet par
exemple, permettra un attaquant ou un code malveillant de piger les dveloppements (firmware, programme automate, application SCADA, etc.)
2.2.20
Outils de dveloppement prsents
Dans de nombreux systmes industriels, les outils de dveloppement sont prsents sur
le rseau. Cela peut tre d au fait que certains produits ne distinguent pas les environnement de production et de dveloppement. Mais cela peut galement rsulter
de pratiques oprationnelles. Les stations dingnierie servent parfois de consoles de
supervision en mme temps.
La prsence des outils de dveloppement sur le rseau facilite la tche de
. modifier le comportement du syslattaquant qui pourra les dtourner pour
tme industriel, de manire lgitime en apparence.
2.2.21 Non cloisonnement de ladministration

Les systmes industriels ne prsentent souvent pas de cloisonnement des machines
dadministration. Souvent, ce sont les mmes machines qui sont utilises pour les
applications SCADA et pour ladministration des quipements.

Le dfaut de cloisonnement facilite la tche de lattaquant qui pourra avoir
.
accs ladministration des quipements
depuis les postes de supervision
SCADA, potentiellement trs exposs.
2.2.22
Dnition des responsabilits
Les responsabilits en matire de cyberscurit sont souvent mal identifies entre le

fournisseur, lintgrateur et lentit responsable du systme industriel. De mme les
responsabilits entre les directions mtier et la DSI ne sont pas forcment claires non
plus.
Des responsabilits peu claires font courir le risque quune partie du systme
industriel ne soit sous la responsabilit. de personne et ne reoive donc pas
les mesures de cyberscurit appropries.
Chapitre 3
.
Mesures de scurit organisationnelles

Les mesures organisationnelles prsentes ci-dessous sadressent lensemble des
acteurs impliqus sur les systmes industriels (chefs de projet, acheteurs, automaticiens, intgrateurs, dveloppeurs, quipes de maintenance, RSSI, etc.)
Important
Il revient lentit responsable de dfinir
. qui sera en charge de lapplication
des mesures de cyberscurit sur les installations.
Les mesures font rfrence aux chapitres de lISO 27002 [3] ainsi quaux recommandations du guide dhygine [14] et aux bonnes pratiques du guide sur la cyberscurit
des systmes industriels [10] publies par lANSSI. Certaines mesures sont galement
abordes dans le guide de classification [13].
Ces rfrences sont indiques dans un encadr comme celui prsent ci-dessous :
Rfrences
Guide de classification : fait rfrence au guide de classification [13].
Vulnrabilit : fait rfrence aux vulnrabilits indiques dans la section 2.2.
Guide SCADA : fait rfrence au guide
. sur les systmes industriels [10].
Guide dhygine : fait rfrence au guide dhygine [14].
ISO 27002 : fait rfrence aux chapitres de lISO 27002 [3] abordant le
sujet.
Les mesures sont indiques en recommandation et notes [R.x] lorsquil sagit dun
conseil. Elles sont indiques en directive et notes [D.x] lorsquil sagit dune obligation. Les mesures sont cumulatives. Ainsi, une installation de classe 2 doit appliquer
les mesures de classe 1 et une installation de classe 3 doit appliquer les mesures de
classe 1 et de classe 2.
3.1 Connaissance du systme industriel

Cette section regroupe lensemble des mesures qui permettent daccrotre la connaissance du systme industriel et de son environnement. Afin dassurer une bonne dfense, il est ncessaire davoir une connaissance trs approfondie de son systme,
des risques encourus et des menaces son encontre.
3.1.1 Rles et responsabilits

Rfrences
Guide de classification : 2.2.1
Vulnrabilit : 2.2.22
Guide SCADA : 2.3.1
ISO 27002 : 6.1.1
Classe 1
[R.1] Une chane de responsabilit de la cyberscurit devrait tre mise en place.
Elle devrait couvrir lensemble des systmes.
[R.2] Les responsabilits pour la cyberscurit devraient tre clairement dfinies pour
chacune des parties prenantes quel que soit laspect concern (dveloppement,
intgration, exploitation, maintenance, etc.).
Classe 2
[D.3] La recommandation R.1 devient une directive.
Classe 3
[D.5] La directive D.3 est renforce. Lidentit et les coordonnes du responsable
de la chane de responsabilit de la cyberscurit doivent tre communiques
lautorit de cyberdfense.
[D.6] La directive D.4 est renforce. Les limites de responsabilit doivent tre revues
priodiquement et au moins une fois par an.
3.1.2 Cartographie
Rfrences
Vulnrabilit : 2.2.4
Guide SCADA : BP09, BP02, 2.2.1 .
Guide dhygine : Rgles 1 et 2
ISO 27002 : 8.1.1
Classe 1
[R.7] Il est recommand de rdiger une cartographie :
physique du systme industriel ;
logique du systme industriel ;
des applications (flux).
Classe 2
[D.8] Il est ncessaire dtablir une cartographie :
physique du systme industriel ;
logique du systme industriel ;
des applications ;
de ladministration du systme.
[R.9] La cartographie et la documentation du systme industriel devraient tre revues
rgulirement, chaque modification du systme industriel et au moins une fois
par an.
Classe 3
Une description plus dtaille du contenu attendu pour une cartographie est disponible dans lannexe A
Remarque
Lutilisation doutils industriels comme les logiciels de Gestion de Maintenance Assiste par Ordinateur (GMAO) pour grer les inventaires peut tre
utile. Cela permet de disposer de lensemble des informations dans une
mme base et de les partager avec les. quipes mtier. De plus, la GMAO
contient dj bien souvent un inventaire des composants matriels comme
les automates, les interfaces homme-machine (IHM), capteurs et actionneurs
intelligents par exemple.
3.1.3 Analyse de risque

Rfrences
Vulnrabilit : NA
Guide SCADA : 2.2.2
ISO 27002 : cf. ISO 27005
Remarque
Il est recommand que lanalyse de risque pour la cyberscurit du systme
.
industriel soit intgre lanalyse de risque
globale du systme pouvant traiter par exemple des aspects de sret de fonctionnement.
Classe 1
[R.11] Les systmes industriels devraient faire lobjet dune analyse de risque pour la
cyberscurit, mme succincte.
Classe 2
[D.12] Les systmes industriels doivent faire lobjet dune analyse de risque pour la
cyberscurit suivant une mthode choisie par lentit responsable.
Classe 3
[D.13] La directive D.12 est renforce. Lanalyse de risque devra tre revue rgulirement, au moins une fois par an.
[R.14] Lanalyse de risque devrait tre ralise en collaboration avec un prestataire
labellis.
3.1.4 Gestion des sauvegardes

Rfrences
Vulnrabilit : 2.2.5
Guide SCADA : BP08
Guide dhygine : Rgle 36
Ref ISO 27002 : 12.3
Classe 1
[R.15] Un plan de sauvegarde des donnes importantes devrait tre mis en place
afin de permettre leur restauration en cas dincident.
[R.16] Les configurations devraient tre sauvegardes avant et aprs toutes modifications, y compris lorsque celles-ci ont t apportes chaud .
[R.17] Le processus de restauration des sauvegardes devrait tre test rgulirement.
Il pourrait tre test sur un chantillon limit mais reprsentatif du systme industriel dans son ensemble.
Primtre dapplication : Les donnes concernes sont toutes les donnes ncessaires la reconstruction du systme aprs un sinistre : les programmes, les fichiers de
configuration, les firmwares, les paramtres de procd (rglages dasservissement
par exemple), etc. Cela peut galement concerner des donnes ayant un aspect rglementaire comme des exigences de traabilit.
Classe 2
[D.18] Les recommandations R.15, R.16 et R.17 deviennent des directives.
Classe 3 Il ny a pas dexigence supplmentaire pour la classe 3.
3.1.5 Gestion de la documentation

Rfrences
Vulnrabilit : 2.2.5
Guide SCADA : BP09
Ref ISO 27002 : 8.1.1
Classe 1
[R.19] Le niveau de sensibilit de la documentation devrait tre dfini et apparatre

clairement sur les documents. Les documents devraient tre traits en consquence.
[R.20] Lensemble des documents relatifs la conception, la configuration ou
au fonctionnement du systme industriel devraient tre considrs comme sensibles.
[R.21] Les documents devraient tre stocks dans un systme dinformation dont le
niveau de sensibilit est adapt aux systmes industriels.
Remarque
La documentation des systmes industriels (analyses fonctionnelles, analyses
organiques, plan dadressage, etc.) est souvent stocke sur le systme de
gestion (bureautique) dont les exigences en matire de cyberscurit peuvent
. industriels. Les systmes de gestion
tre plus faibles que pour les systmes
sont souvent la premire cible des attaquants car ils permettent de collecter
facilement de nombreuses informations en vue de prparer, par exemple,
une attaque cible sur les systmes industriels.
Classe 2
[R.22] La confidentialit de la documentation devrait tre garantie.
[R.23] La documentation devrait tre revue intervalle rgulier pour :
sassurer que les documents ncessaires existent bien,
liminer ceux qui ne servent plus.
Classe 3
3.2
Matrise des intervenants
3.2.1 Gestion des intervenants

Rfrences
Vulnrabilit : 2.2.2
Guide SCADA : BP04
ISO 27002 : 15.1
Classe 1
[R.25] Des procdures de gestion des intervenants devraient tre mises en place,
notamment lors dune arrive ou dun dpart. Ces procdures devraient notamment traiter :
la cration et la destruction de comptes (cf 4.1),
la gestion des accs aux locaux,
la gestion des quipements mobiles (tlphones, tablettes, PC portables,
etc),
la gestion des documents sensibles.
[R.26] Un processus de gestion des comptences, afin de sassurer que les intervenants disposent des comptences ncessaires pour leurs missions, devrait tre
mis en place. Ce processus devrait en particulier intgrer le transfert de comptences, en cas de dpart ou de changement de poste, des personnes en charge
des systmes.
Classe 2
[D.27] Les recommandations R.25 et R.26 deviennent des directives.
Classe 3
[D.28] Une revue rgulire des intervenants et de leurs comptes doit tre effectue,
au minimum une fois par an.
Remarque
Suivant les rglementations applicables
. aux systmes industriels, il pourra
tre demand une enqute de scurit sur les intervenants
3.2.2 Sensibilisation et formation

Rfrences
Guide SCADA : 2.2.1
ISO 27002 : 7.2.2
Classe 1
[R.29] Les intervenants devraient tre habilits et forms la cyberscurit.
[R.30] Une charte de bonne conduite devrait tre mise en place et tous les intervenants devraient la signer lors de leur arrive.
Classe 2
Classe 3
[D.32] La directive D.31 est renforce. La formation des intervenants est obligatoire
AVANT toute intervention sur le systme industriel.
[R.33] Les formations de cyberscurit devraient tre dispenses par des prestataires
labelliss.
[R.34] Les sances de formation et sensibilisation la cyberscurit des systmes
industriels devraient tre dispenses en mme temps que les formations de
sret et de scurit du site.
3.2.3 Gestion des interventions

Rfrences
Ref vulnrabilit : 2.2.6
Ref ISO 27002 : 12.1.2
Classe 1
[R.35] Une procdure de gestion des interventions devrait tre mise en place afin
de pouvoir identifier :
la personne qui excute le travail et son donneur dordre ;
la date et lheure de lintervention ;
le primtre sur lequel le travail est excut ;
les actions ralises ;
la liste des quipements retirs ou remplacs (y compris, le cas chant,
les numros didentification) ;
les modifications apportes et leur impact.
[R.36] Lensemble des quipements matriels et logiciels utiliss pour les interventions sur les systmes industriels devraient tre recenss dans la gestion du parc
afin dtre bien identifis et maintenus jour (cf R.7).
[R.37] Lautorisation dintervention devrait tre valide par lentit responsable.

[R.38] Le processus dintervention devrait tre audit au minimum une fois par an
afin de sassurer du respect de la procdure.
Remarque
Ces lments peuvent tre intgrs aux
. permis de travail dj en place et
exigs pour certaines installations.
Classe 2
[D.39] Les recommandations R.35, R.36, R.37, et R.38 deviennent des directives.
[R.40] Pour les cas particuliers o lintervenant apporte ses propres outils (des outils
de diagnostic propres lquipementier par exemple), une procdure, mme
succincte, devrait tre mise en place pour vrifier que les quipements de lintervenant ont un niveau de scurit satisfaisant.
Une telle situation ne devrait arriver quen cas dabsolue ncessit et doit rester
exceptionnelle.
Classe 3
[D.41] Lutilisation doutils particuliers hors dun cadre prvu par la politique de
scurit du systme industriel est interdite. La recommandation R.40 devient
sans objet pour la classe 3.
3.3
Intgration de la cyberscurit dans le cycle de

vie du systme industriel
Lintgration de la cyberscurit dans le cycle de vie des systmes industriels est une
tape cl pour parvenir aux exigences attendues. Une attention particulire devra tre
porte la cyberscurit lors des phases de conception du systme industriel.
Il est conseill de ne pas traiter le cyberscurit de manire isole. Elle devrait tre intgre dans le projet comme un mtier, au mme titre que llectricit, la mcanique,
etc.
3.3.1 Exigences dans les contrats et cahiers des charges

Rfrences
Guide SCADA : 2.3.2 et 2.3.5
ISO 27002 : 15.1.2
Les projets peuvent tre raliss en interne ou tre externaliss. Dans ce cas, il conviendra de prciser les exigences attendues dans les cahier des charges.
De manire plus gnrale, lorsquil est fait appel une prestation extrieure, les
exigences en matire de scurit doivent tre explicites et contractualises.
Classe 1
[R.42] Les exigences identifies lors de la phase de spcification devraient tre intgres au cahier des charges.
[R.43] Le cahier des charges devrait intgrer une clause exigeant la dfinition dun
point de contact pour la cyberscurit du projet. Celui-ci devrait tre charg
de :
la liaison avec la chane de responsabilit de lentit responsable (cf 3.1.1) ;
la garantie du respect de la politique de cyberscurit ;
la communication sur les divergences par rapport aux exigences et les
autres non-conformits.
[R.44] Le cahier des charges devrait comprendre la liste des documents attendus
avec notamment :
une analyse de risque (cf 3.1.3) ;
une analyse fonctionnelle ;
une analyse organique ;
un dossier dexploitation et de maintenance ;
une cartographie (cf 3.1.2).
[R.45] Le cahier des charges devrait contenir des clauses demandant des tests de
cyberscurit, notamment lors des recettes usine et plateforme. La liste des tests
demands devrait suivre la recommandation R.71.
Classe 2
[D.46] Les recommandations R.42, R.43, R.44 et R.45 deviennent des directives.
[D.47] Le cahier des charges doit contenir une clause de confidentialit pour lensemble des informations du projet le ncessitant en prcisant la dure de conservation des documents.
[R.48] Le cahier des charges devrait contenir une clause de rvision rgulire de
lanalyse de risques. Le niveau de risque devrait tre prsent rgulirement
lentit responsable (par exemple pendant le comit de pilotage).
[R.49] Les documents de spcification fournis par le contractant devraient dcrire de
faon dtaille les moyens techniques, humains et organisationnels mobiliss
afin de permettre leur traabilit et de pouvoir vrifier leur niveau de cyberscurit.
[R.50] Le contractant devrait fournir un plan dassurance scurit dcrivant toutes
les mesures rpondant aux exigences de cyberscurit demandes (cf [8]).
[R.51] Le contractant devrait utiliser un environnement de dveloppement scuris
(cf 4.3.6).
[R.52] Le contrat devrait intgrer une clause pour que lentit responsable puisse
auditer le contractant ou les fournisseurs afin de vrifier que lensemble des
mesures de cyberscurit demandes sont bien appliques.
Classe 3
[D.53] Les recommandations R.48, R.49, R.50, R.52 et R.51 deviennent des directives.
[R.54] Le cahier des charges devrait contenir une clause exigeant la fourniture dquipements matriels et logiciels labelliss sur le plan de la cyberscurit.
[R.55] Le cahier des charges devrait exiger des concepteurs de logiciels une dmonstration que leurs processus de dveloppement emploient des mthodes
dingnierie ltat de lart, des processus de contrle qualit et des techniques
de validation afin de rduire les dfaillances logicielles et les vulnrabilits.
[R.56] Afin de faciliter lapplication de la recommandation R.55, le contractant devrait tre labellis.
3.3.2 Intgration de la cyberscurit dans les phases de

spcication
Rfrences
Guide SCADA : 2.3.2
ISO 27002 : 14.1.1
Classe 1
[R.57] Les exigences techniques devraient intgrer lensemble des mesures techniques prsentes dans le chapitre 4. titre dexemple, la conception devrait
prendre en compte :
la ncessit dauthentifier les intervenants (cf 4.1) ;
la ncessit de dfinir une architecture scurise (cf 4.2) ;
la ncessit de scuriser les quipements (cf 4.3) ;
la ncessit de pouvoir requalifier un systme suite des mises jour de
scurit.
[R.58] Des procdures et des moyens techniques devraient tre dfinis pour permettre des oprations de maintenance prventive et curative afin de maintenir
le niveau de cyberscurit dans la dure.
Par exemple, des modes dgrads pourraient tre prvus pour raliser des
mises jour. On pourra, par exemple, configurer les sorties dun automate
pour quelles restent sur leurs derniers tats, pendant la mise jour de son
firmware.
[R.59] La dfinition de la localisation des quipements devrait prendre en compte
leur scurit physique.
[R.60] Les spcifications du projet devraient exiger que les oprations non indispensables la conduite du systme industriel soient effectues sur un autre systme
dinformation. Les quipements et logiciels associs ne devraient pas tre prsents sur le systme industriel. titre dexemple, des postes bureautiques non
connects au systme industriel devraient tre prvus pour permettre la consultation de la documentation, le remplissage de feuilles de suivi, etc.
Classe 2
[R.62] La conception devrait intgrer des outils et mcanismes pour grer la scurit
et faciliter les exigences telles que :
la matrise de la configuration (cf 3.3.6) ;
le durcissement des configurations (cf 4.3.1) ;
la gestion des vulnrabilits (cf 4.3.2).
Classe 3
3.3.3 Intgration de la cyberscurit dans les phases de

conception
Rfrences
Guide SCADA : 2.3.2
ISO 27002 : 14.1.1
Classe 1
[R.64] Lors de la conception, les interfaces et la complexit du systme devraient
tre limites au maximum afin de limiter lintroduction de vulnrabilits lors de
limplmentation.
[R.65] Les caractristiques de cyberscurit des quipements (mcanismes dauthentification, sgrgation des droits, etc.) devraient tre intgres au processus
de choix de ceux-ci.
[R.66] Des rles devraient tre dfinis pour les intervenants. Ces rles devraient tre
intgrs dans la gestion des droits des comptes informatiques. Les rles devraient correspondre strictement aux missions de chacun (politique des moindres
privilges). En particulier, les utilisateurs et les administrateurs devraient tre
distingus (cf 4.1.1).
Classe 2
Classe 3 Il ny a pas de mesure supplmentaire pour la classe 3.
3.3.4 Audits et tests de cyberscurit

Rfrences
Guide classification : 2.2.5
Guide SCADA : 2.3.2
ISO 27002 : 12.7
Afin de sassurer que le niveau de scurit ne se dgrade pas au cours du temps,

il est ncessaire deffectuer rgulirement des tests ou des audits de cyberscurit.
Ceux-ci peuvent tre intgrs aux phases de maintenance et de tests fonctionnels.
Classe 1
[R.68] Des audits devraient tre mis en place rgulirement. Ces audits pourront
tre internes.
[R.69] Laudit doit tre suivi dun plan daction valid et suivi par lentit responsable.
Classe 2
[D.70] Les recommandations R.68 et R.69 deviennent des directives et sont renforces par la recommandation R.71 ci-aprs.
[R.71] Un programme daudit devrait tre mis en place avec les lments suivant :
des tests aux limites ;
des tests derreur des fonctions mtier ;
des tests de la vrification et de la gestion des exceptions ;
le droulement de scnarios de menace (tests de pntration et tentatives
de prise de contrle) ;
la vrification des mcanismes de scurit (dploiement de correctifs, analyse de journaux dvnements, restauration de sauvegarde, etc.) ;
lvaluation des performances du systme.
Important
Les tests de pntration pouvant entraner des dfaillances, ils doivent
.
tre excuts dans le cadre de maintenance
ou avant la mise en production des systmes.
[R.72] Les audits devraient tre raliss par des prestataires externes labelliss.
Classe 3
[D.74] Les audits devront tre effectus au moins une fois par an.
3.3.5 Transfert en exploitation

Rfrences
Guide classification : 2.3
Guide SCADA : 2.3.2
Remarque
Lentreprise en charge de lexploitation peut ne pas tre le propritaire du
systme et donc ne pas avoir t implique dans son projet de ralisation.
.
Cela peut concerner les cas de dlgations
de service public, de concession
dexploitation ou de contrat dexploitation avec obligation de rsultat par
exemple.
Classe 1
[R.75] Avant de mettre en exploitation un systme il faudrait :
tablir un tat des lieux exhaustif du niveau de cyberscurit du systme ;
sassurer des moyens disponibles pour le maintenir un niveau acceptable.
Classe 2
[D.76] Les systmes industriels doivent tre homologus par lentit responsable.
Classe 3
[D.77] Les systmes industriels doivent tre homologus et requirent une autorisation pralable de mise en service. Lhomologation doit tre faite par un organisme extrieur.
3.3.6 Gestion des modications et volutions

Rfrences
Guide SCADA : BP07
ISO 27002 : 14.2.2
La gestion des modifications concerne les programmes des automates, les applications SCADA, les fichiers de configurations des diffrents quipements (quipements
rseaux, capteurs et actionneurs intelligents par exemple), etc.
Classe 1
[R.78] Des outils devraient tre utiliss pour contrler rapidement les diffrences
entre la version courante et la version installer et sassurer que seules les
modifications ncessaires et demandes ont t appliques.
[R.79] Les mises jour et modifications apportes aux systmes devraient tre traces.
Classe 2
[R.81] Un processus de vrification des versions de programme en cours dexcution par rapport une version de rfrence devrait tre mis en place. Cela
permet de sassurer que les configurations excutes par le systme industriel
(les automates, les SCADA, etc.) sont bien les bonnes.
[R.82] Les modifications devraient tre values dans un environnement de test au
pralable.
Classe 3
[D.83] La recommandation R.78 devient une directive. Les impacts des modifications doivent tre valids par lentit responsable avant mise en production.
3.3.7 Processus de veille

Rfrences
Vulnrabilit : 2.2.1
Guide SCADA : 2.2.6
ISO 27002 : 12.6
Classe 1
[R.85] Un processus de veille sur les menaces et vulnrabilits devrait tre mis en
place.
Remarque
Ce processus devrait notamment reposer sur les sources ouvertes dis. (CERT-FR, ICS-CERT), les CERT
ponibles telles que les CERT nationaux
des quipementiers et des dveloppeurs de logiciels.
Classe 2
[R.87] La diffusion, par les fournisseurs, des bulletins de vulnrabilit pour lensemble des quipements matriels et logiciels utiliss dans le systme industriel
devrait tre contractualise.
[R.88] Un processus de veille sur lvolution des techniques de protection devrait
tre mis en place. Il pourrait tre bas galement sur des sources ouvertes
disponibles comme le site web de lANSSI.
Classe 3
[D.90] Un processus de veille sur lvolution des techniques dattaque et sur lvolution de la menace doit tre mis en place. En cas dvolution importante, une
rvaluation de lanalyse de risque doit tre engage.
3.3.8 Gestion de lobsolescence

La gestion de lobsolescence nest pas directement une mesure de cyberscurit mais
elle y contribue. Les quipements en phase dobsolescence peuvent contenir de nom-
breuses vulnrabilits qui ne seront jamais corriges. La gestion de lobsolescence est

un processus pouvant donc tre utile et ncessaire pour la gestion des vulnrabilits.
Rfrences
Vulnrabilit : 2.2.1
Classe 1
[R.91] Des clauses relatives la gestion de lobsolescence des quipements et logiciels, en indiquant par exemple la date laquelle ils ne seront plus pris en
charge, devraient tre intgres dans les contrats avec les fournisseurs.
[R.92] Un plan de gestion de lobsolescence pour remplacer les quipements et
applications obsoltes devrait tre mis en place.
Classe 2
Classe 3 Il ny a pas de mesure complmentaire pour cette classe.
3.4
Scurit physique et contrle daccs aux

locaux
3.4.1 Accs aux locaux

Rfrences
Vulnrabilit : 2.2.8
ISO 27002 : 11.1
Classe 1
[R.94] Une politique de contrle daccs physique devrait tre dfinie. Cette politique devrait notamment prvoir de :
rcuprer les cls ou badges dun employ son dpart (cf R.25) ;
changer rgulirement les codes de lalarme de lentreprise ;
ne jamais donner de cl ou de code dalarme des prestataires extrieurs

sauf sil est possible de tracer les accs et de les restreindre des plages
horaires donnes.
[R.95] Les accs aux locaux devraient tre journaliss et auditables.
Classe 2
[R.97] Les mcanismes de contrle daccs devraient tre robustes. On pourra se
reporter au guide de lANSSI sur le sujet [9].
[R.98] Les accs devraient tre mis sous vidoprotection.
[R.99] Laccs aux quipements devrait tre strictement rserv aux personnes habilites.
Classe 3
[D.101] Un systme de dtection dintrusion devra tre mis en uvre pour les zones
vitales, en particulier celles non occupes 24 heures sur 24.
3.4.2 Accs aux quipements et aux cblages

Rfrences
Vulnrabilit : 2.2.8
Guide SCADA : BP01
ISO 27002 : 11.2
Classe 1
[R.102] Les serveurs devraient tre installs dans des locaux ferms sous contrle
daccs (si possible dans des salles informatiques).
[R.103] Les units centrales des stations, les quipements rseaux industriels et les
automates devraient tre placs dans des armoires fermes cl.
[R.104] Des prises daccs au systme industriel ne devraient pas tre accessibles
dans les endroits ouverts au public.
Classe 2
[D.106] La recommandation R.104 est renforce par la directive suivante : les prises
daccs au systme industriel ne doivent pas tre accessibles dans les zones sans
surveillance.
[R.107] Lintgrit physique des cbles devrait tre protge (par exemple : un capotage).
[R.108] Lorsquelles ne sont pas utilises, les prises ddies la maintenance devraient tre obtures (bouchons, plaques doccultation...). Le retrait de lobturateur suit une procdure bien dfinie et est soumis autorisation pralable.
[R.109] Un dispositif de dtection douverture, avec remonte dalarme, devrait tre
mis en place sur les armoires des quipements sensibles. A minima, sur les
coffrets extrieurs contenant des composants sensibles, un moyen de contrle
visuel, comme la pose de scells par exemple devrait tre install. Le retrait de
ces moyens visuels devrait suivre une procdure bien dfinie et tre soumis
autorisation pralable.
Classe 3
3.5
Raction en cas dincident
3.5.1 Plan de reprise ou de continuit dactivit

Un plan de reprise ou de continuit dactivit permet de garantir la reprise ou la
continuit du service suite un sinistre, quelle quen soit lorigine. Ce plan de continuit dactivit, parfois dj existant pour rpondre des sinistres dorigine autre
que la cyberscurit devra rpondre lensemble des vnements redouts entranant un arrt du service rendu, tels quils ont t identifis dans lanalyse de risque
pour la cyberscurit. Pour plus de dtails, on pourra se reporter au guide dit par
le SGDSN [2].
Rfrences
Guide SCADA : 2.2.7
ISO 27002 : 17.1
Classe 1
[R.111] Un plan de sauvegarde des donnes sensibles devrait tre mis en place afin
de pouvoir reconstruire le systme aprs sinistre (cf 3.1.4).
[R.112] Les plans de reprise et de continuit dactivit devraient intgrer les incidents
de cyberscurit.
Classe 2
[R.113] Les plans de reprise et de continuit dactivit devraient tre tests rgulirement et au moins une fois par an.
Classe 3
3.5.2 Modes dgrads

Classe 1
[R.115] Les procdures dintervention devraient intgrer un mode durgence ( procdure bris de glace ) pour pouvoir intervenir rapidement en cas de besoin sans
dgrader significativement le niveau de cyberscurit du systme industriel. En
particulier, cette procdure durgence ne devrait pas affecter la traabilit des
interventions.
[R.116] Les systmes devraient intgrer des modes dgrads leur permettant soit de
sarrter sans provoquer de dgts (materiel ou humain), soit de continuer
fonctionner par un pilotage en mode manuel .
Classe 2 Il ny a pas de mesure supplmentaire pour cette classe.
Classe 3
3.5.3 Gestion de crise

Rfrences
Guide SCADA : 2.2.5
ISO 27002 : 17.1
Classe 1
[R.118] Un processus de gestion de crise devrait tre mis en place. Celui-ci devrait
permettre de dterminer :
que faire lors de la dtection dun incident ;
qui alerter ;
qui est la personne qui doit coordonner les actions en cas de crise ;
quelles sont les premires mesures appliquer.
[R.119] Le processus de gestion de crise devrait galement contenir une procdure
descalade pour grer les incidents au bon niveau de responsabilit et dcider
en consquence :
sil faut dclencher un plan de reprise dactivit ;
si une action judiciaire est ncessaire.
[R.120] La gestion de crise devrait galement dfinir une phase danalyse post incident dans le but de dterminer lorigine de lincident et damliorer la cyberscurit du systme industriel.
Remarque
Une note de lANSSI dcrit les bons rflexes
en cas dintrusion sur un systme
.
dinformation [4].
Classe 2
[R.121] Les procdures de gestion de crise devraient tre testes rgulirement et au
moins une fois par an.
Classe 3
Chapitre 4
.
Mesures de scurit techniques

Ce chapitre regroupe lensemble des mesures techniques sadressant lensemble
des acteurs impliqus sur les systmes industriels (chefs de projet, acheteurs, automaticiens, intgrateurs, dveloppeurs, quipes de maintenance, RSSI, etc.).
Important
Il revient lentit responsable de dfinir
. qui sera en charge de lapplication
des mesures sur les installations.
Les mesures sont indiques en recommandation et notes [R.x] lorsquil sagit dun
conseil. Elles sont indiques en directive et notes [D.x] lorsquil sagit dune obligation. Les mesures sont cumulatives. Ainsi, une installation de classe 3 doit appliquer
les mesures de classe 1 et de classe 2.
Les mesures font rfrence aux chapitres de lISO 27002 [3] ainsi quaux recommandations du guide dhygine [14] et aux bonnes pratiques du guide sur la cyberscurit
des systmes industriels [10] publies par lANSSI. Certaines mesures sont galement
abordes dans le guide de classification [13].
Ces rfrences sont indiques dans un encadr comme celui prsent ci-dessous :
Rfrences
Guide de classification : fait rfrence au guide de classification [13].
Vulnrabilit : fait rfrence aux vulnrabilits indiques dans la section 2.2.
Guide SCADA : fait rfrence au guide
. sur les systmes industriels [10].
Guide dhygine : fait rfrence au guide dhygine [14].
ISO 27002 : fait rfrence aux chapitres de lISO 27002 [3] abordant le
sujet.
Le primtre dapplication est prcis pour chaque famille de mesures, voire chaque
mesure. Sans prcision complmentaire, il est le mme pour toutes les mesures dune
famille. Par dfaut, le primtre comprend les quipements suivants :
Les quipements sur lesquels peuvent porter les mesures sont :
les serveurs, stations et postes de travail ;
les stations dingnierie et consoles de programmation ;
les quipements mobiles : ordinateurs portables, tablettes, ordiphones, etc. ;
les logiciels et applications de supervision (SCADA) :
les logiciels et applications de GPAO et de MES si existants ;
les interfaces homme-machine (crans tactiles) ;
les automates et units dportes (RTU) ;
les quipements rseau (commutateurs, routeurs, pare-feu, bornes daccs sans
fil) ;
les capteurs et actionneurs intelligents ;

Cette liste est un exemple et doit tre adapte au contexte de chaque systme.
Important
Certaines exigences font appel des mcansimes cryptographiques (chiffrement, signature, authentification, .etc.). Ces mcanismes devront tre
conformes aux annexes B du rfrentiel gnral de scurit [6].
4.1 Authentication des intervenants : contrle

daccs logique
4.1.1 Gestion des comptes
Rfrences
Vulnrabilit : 2.2.2
Guide SCADA : BP04
.
Guide dhygine : Rgles 8, 20 et 30
ISO 27002 : 9.1
Les comptes peuvent tre de diffrents types :

les comptes de session permettant laccs aux machines Windows et Linux ;
les comptes applicatifs permettant un intervenant de se connecter une
application SCADA par exemple. Ces comptes sont souvent grs par lapplication elle-mme ;
les comptes systmes utiliss pour quune application puisse sexcuter et
communiquer avec dautres applications (exemple : compte de service). Ces
comptes ne sont normalement pas utiliss par un intervenant.
Les comptes peuvent disposer de diffrents niveaux de privilges. En particuliers, les
comptes de niveau administrateur se dcoupent en deux catgories :
les comptes de privilges levs administrateur systme permettant ladministration informatique des quipements (serveurs, stations et quipements
rseau par exemple) et des systmes dexploitation ;
les comptes de privilge levs ingnieur de procd permettant daccder
des fonctions de configuration ou de programmation des applications SCADA
et automates par exemple.
Remarque
Pour des questions de facilit, les comptes sont souvent mlangs alors quils
.
devraient tre bien spars. Un ingnieur
de procd na pourtant pas
besoin dtre administrateur systme . Il sagit dune mauvaise pratique.
Classe 1
[R.123] Chaque utilisateur devrait tre identifi de manire unique.
[R.124] Tous les comptes disposant de privilges importants comme les comptes
administrateurs devraient tre protgs par un mcanisme dauthentification
comme un mot de passe par exemple. Les comptes utilisateurs et administrateurs devraient tre strictement spars.
[R.125] Les comptes gnriques, en particulier ceux disposant de privilges importants sont dconseills.
Lorsquils sont indispensables, leur utilisation devra tre limite des usages
trs prcis et tre documente.
[R.126] Des rles devraient tre dfinis, documents et implments pour que les
comptes des utilisateurs aient des privilges correspondant exactement leurs
missions.
[R.127] Un audit des dvnements lis lutilisation des comptes devrait tre mis
en place.
[R.128] Les comptes appartenant des personnels nintervenant plus sur le systme
industriel devraient tre supprims ou, a minima, dsactivs (cf R.25).
Classe 2
[D.129] Les recommandations R.123, R.124 et R.125 deviennent des directives. Les
comptes par dfaut et gnriques ne doivent pas tre utiliss sauf contrainte
oprationnelle forte. Les comptes disposant de privilges comme les comptes
administrateurs ne doivent pas tre des comptes gnriques et doivent tre
distincts des comptes utilisateurs.
[D.130] La recommandation R.126 devient une directive. De plus, les comptes avec
privilges devront tre valids par le responsable hirarchique de lutilisateur.
[D.131] La recommandation R.128 devient une directive et complte la directive
D.27.
[R.132] Une revue annuelle des comptes utilisateurs devrait tre mise en place. Elle
pourrait notamment permettre de vrifier la bonne application des directives
D.129 et D.130 et de la directive D.131. Cette revue devrait porter une attention particulire aux comptes dadministration.
[R.133] Lorsque cela est possible, un accs en lecture seule devrait tre configur
pour les interventions de maintenance de premier niveau.
[R.134] Si la gestion des comptes est centralise, la configuration de lannuaire centralis devra tre audite rgulirement et au moins une fois par an. Pour le
cas de lActive Directory, on pourra se reporter larticle [1].
Important
Une solution centralise (comme par exemple Active Directory, LDAP, etc.)
peut faciliter la gestion des comptes et
. droits des intervenants. Ce type de
solution peut galement crer un point de vulnrabilit unique et doit donc
tre tudi avec le plus grand soin.
Classe 3
4.1.2 Gestion de lauthentication

Rfrences
Vulnrabilit : 2.2.2
Guide SCADA : BP04
.
Guide dhygine : Rgles 9, 10, 11, 12 et 13.
ISO 27002 : 9.1
Classe 1
[R.136] Les diffrents composants (quipements et logiciels) ne doivent tre accessibles quaprs une authentification avec identifiant et mot de passe. Lorsque
cela est possible, la politique de mots de passe doit rpondre a minima aux
exigences suivantes :
les mots de passe doivent tre robustes (cf. [12]) ;
les mots de passe par dfaut doivent tre changs.
[R.137] Une temporisation dinhibition doit tre privilgie par rapport au blocage
en cas dchec dauthentification.
[R.138] Le mot de passe doit tre protg en confidentialit et en intgrit quand
celui-ci est transmis sur le rseau.
[R.139] Dans le cas o une authentification ne peut pas tre applique, du fait de
contraintes oprationnelles notamment, des mesures compensatoires devraient
tre dfinies et documentes. A titre dexemple, on pourra envisager :
dappliquer un contrle daccs physique ;
de limiter les fonctionnalits accessibles (consultation sans modification,
par exemple) ;
de mettre en place une authentification par carte puce sans code ;
de cloisonner plus fortement lquipement ;
etc.
Exemple
Dans une salle de contrle oprationnelle en 24/7, les intervenants ont
besoin de pouvoir agir vite sur les applications SCADA. Des comptes
individuels peuvent tre inadapts. Il peut tre envisageable dans ce cas
. de passe individuel car laccs
de ne pas exiger didentifiant et de mot
la salle de contrle est possible uniquement des intervenants habilits,
les accs physiques sont tracs, et la salle de contrle est occupe en
permanence.
[R.140] Les fichiers contenant les mots de passe ou leur empreinte devraient tre
conservs de manire assurer leur confidentialit et leur intgrit.
[R.141] Une procdure scurise pour la rinitialisation des mots de passe en cas
de perte devrait tre dfinie.
Classe 2
[R.143] Lorsque cela est possible, une authentification forte (carte puce, OTP,
etc.) devrait tre mise en place sur les postes de travail et serveurs. Cette mesure peut tre tendue aux quipements de terrain le permettant (automates,
entres/sorties dportes), etc.
[R.144] Lorsque la recommandation R.143 ne peut pas tre applique, la politique
de mots passe de la recommandation R.136 devrait tre renforce par :
conservation de lhistorique des mots de passe (par exemple les 5 derniers) ;
la vrification technique de la complexit du mot de passe ;
le renouvellement du mot de passe (par exemple au bout de 90 jours).
Remarque
Certains outils permettent de vrifier au moment de la dfinition dun
nouveau mot de passe sil nest pas trop proche des anciens. Lide peut
paratre sduisante car il est souvent ais de deviner un mot de passe
. autres mots de passe de lutilisadonn partir de la connaissance des
teur. Cependant, cette technique ncessite de conserver un historique
des mots de passe en clair, ce qui peut tre dangereux. Lhistorisation
simple peut tre faite en ne conservant que les empreintes.
[R.145] La journalisation des vnements de scurit doit enregistrer les checs

dauthentification et les authentifications russies des comptes privilges.
Classe 3
[D.147] La recommandation R.143 devient une directive pour les quipements exposs (postes de travail, ordinateurs portables, stations dingnierie, consoles
de programmation, pare-feu, VPN, etc.)
4.2
Scurisation de larchitecture du systme

industriel
4.2.1 Cloisonnement des systmes industriels

Rfrences
Vulnrabilit : 2.2.9
.
Guide SCADA : BP02
ISO 27002 : 13.1.3
Classe 1
[R.148] Les systmes industriels devraient tre dcoups par zones fonctionnelles ou
zones techniques cohrentes. Ces zones devraient tre cloisonnes entre elles.
[R.149] Une politique de filtrages entre les zones devrait tre mise en place. Pour
dfinir une politique de filtrage, on pourra notamment se reporter au guide sur
les pare-feu de lANSSI [11].
Pour les flux utilisant le protocole IP, on en rappelle nanmoins ici quelques
grands principes :
un flux est identifi par ladresse IP source, ladresse IP destination, le
protocole (par exemple UDP ou TCP) et, le cas chant, les numros de
port source et destination ;
les flux sont refuss par dfaut ;
seuls les flux ncessaires au fonctionnement du systme industriel sont
autoriss ;
les flux rejets doivent tre journaliss et analyss ;

tous les flux entrants ou sortants du systme industriel doivent tre journaliss.
Exemple
A titre dexemple, on rappelle quelques exemples de protocoles et de
ports utiliss par les protocoles industriels :
Modbus : TCP/502
S7 : TCP/102
EthernetIP : TCP/44818 et UDP/2222

OPCUA : TCP/4840
Pronet IO : TCP/UDP 34962, 34963, 34964
[R.150] Lorsque des flux non-IP doivent transiter entre deux zones distinctes, un filtrage devrait tre effectu sur les identifiants source et destination. Par exemple,
dans le cas dEthernet, on pourra effectuer le filtrage sur les adresses MAC
source et destination.
Par ailleurs, on pourra faire un filtrage sur les protocoles autoriss.
[R.151] Autant que possible, un cloisonnement physique devrait tre privilgi entre
les zones fonctionnelles du systme industriel. Indpendamment de la cyberscurit, le cloisonnement physique participe galement renforcer la disponibilit des systmes.
[R.152] Lorsque une sparation physique nest pas possible entre les zones fonctionnelles du systme industriel, un cloisonnement logique devrait tre mis en place.
Lutilisation des VLAN est un exemple de cloisonnement logique possible.
[R.153] Le rseau dadministration des quipements devrait tre cloisonn des autres
rseaux, a minima de manire logique. Le primtre porte sur les quipements
dinformatique classique comme les commutateurs, passerelles, routeurs, parefeu, etc.
[R.154] Les postes dadministration ne devraient pas avoir dautre usage. Ils ne devraient pas tre connects Internet ni un rseau de gestion.
Remarque
Les VLAN nont pas t conus comme un mcanisme de scurit. Leur
configuration devra tre faite avec .soin pour assurer le cloisonnement
de manire effective.
Exemple
Voici un exemple de cloisonnement logique :
1 VLAN dadministration pour les composants rseau, les postes
de travail dadministration et les serveurs dadministration ;
1 VLAN de serveurs ;
.
1 VLAN des postes de conduite ;
1 VLAN des postes de dveloppement ;
1 VLAN par procd contenant les automates et autres quipements associs (entres/sorties dportes, etc.).
Classe 2
[D.155] Les recommandations R.148, R.149, R.150, et R.151 deviennent des directives.
[D.156] Les recommandation R.153 et R.154 deviennent des directives. Il est possible que certains quipements, notamment dancienne gnration, ne permettent pas techniquement de raliser un tel cloisonnement. Dans ce cas, une
analyse spcifique devra tre mene pour tudier les contre-mesures possibles
et dfinir le niveau de risque rsiduel.
[R.157] Les flux devraient tre unidirectionnels entre les systmes industriels de classe
2 et les systmes industriels de classe 1. Lunidirectionnalit des flux pourra tre
assure par un pare-feu.
[R.158] Les rseaux dadministration des quipements devraient tre cloisonns physiquement des autres rseaux. A minima, ils devraient tre spars logiquement
laide de tunnels VPN. Lutilisation de produits qualifis pour ltablissement
de ces tunnels est recommande.
Classe 3
[D.159] Les flux doivent tre unidirectionnels entre des zones de classe 3 et de classe
infrieure. Lunidirectionnalit est assure physiquement par une diode.
[R.160] La diode devrait tre labellise.

[D.161] Les systmes industriels de classe 3 doivent tre physiquement spars des
systmes de classe infrieure. Lutilisation de cloisonnement logique est interdite.
Important
Des PLC sont parfois configurs avec deux coupleurs Ethernet diffrents pour
sparer les flux, un pour les communications avec les SCADA et lautre pour
les communications avec les quipements
de procd par exemple. Cette
.
mesure peut rpondre des besoins de sret de fonctionnement mais ne
constitue pas une protection contre certaines attaques. En effet, ltanchit
entre les deux coupleurs Ethernet nest pas garantie.
4.2.2 Interconnexion avec le systme dinformation de gestion

Rfrences
Vulnrabilit : 2.2.9
Guide SCADA : BP02
Guide dhygine : Rgles 21, 29
ISO 27002 : 13.1
Le systme dinformation de gestion et ses rseaux sont considrs par dfaut de

classe 1.
Classe 1
[R.162] Linterconnexion devrait tre protge par un dispositif de filtrage (pare-feu).
[R.163] Les flux devraient tre limits au strict minimum.
[R.164] Une politique de filtrage telle que celle dcrite dans la recommandation
R.149 devrait tre mise en place.
Classe 2
[R.166] Les flux sont unidirectionnels depuis le systme industriel de classe 2 vers
le systme dinformation de gestion. Lunidirectionnalit des flux pourra tre
assure par un pare-feu.
Classe 3
[D.167] Les flux doivent tre unidirectionnels entre les systmes industriels et les systmes de gestion. Lunidirectionnalit devra tre assure physiquement par une
diode.
[R.168] La diode devrait tre labellise.
4.2.3 Accs Internet et interconnexions entre sites distants

Rfrences
Vulnrabilit : 2.2.9
Guide SCADA : BP02
Guide dhygine : Rgles 4, 24
ISO 27002 : 9.4
Classe 1
[R.169] Les accs vers Internet depuis le systme industriel devraient tre limits. En
particulier, lensemble des postes de supervision et des quipements de terrain
ne devraient pas avoir daccs Internet.
[R.170] Rciproquement, les accs depuis Internet vers le systme industriel devraient tre limits.
[R.171] Les interconnexions entre des systmes rpartis sur des localisations diffrentes devraient garantir la confidentialit, lintgrit et lauthenticit des communications. On pourra utiliser un VPN IPsec par exemple.
[R.172] Un dispositif de filtrage (pare-feu) devrait tre mis en place au niveau des
passerelles dinterconnexion.
[R.173] Les passerelles dinterconnexion devraient tre configures de manire scurise. On pourra se reporter au guide de lANSSI [7].
Classe 2
[D.174] Les recommandations R.169, R.170, R.171, R.172 deviennent des directives.
[R.175] Les quipements utiliss pour linterconnexion devraient tre labelliss.
Classe 3
[D.176] Une interconnexion directe entre un systme industriel de classe 3 et un
rseau public ne doit pas tre autorise.
4.2.4 Accs distants

Rfrences
Ref vulnrabilit : 2.2.10
Rf guide dHygine : Rgle 18
Ref ISO 27002 : 9.4
Tldiagnostic, tlmaintenance et tlgestion

Le tldiagnostic est laction deffectuer distance, sous-entendu depuis lextrieur
des btiments dans lesquels se trouve le systme industriel, en passant potentiellement
par des rseaux non-matriss, un diagnostic dinstallation technique. Ceci ninclut
pas de modification de paramtrage.
La tlmaintenance est laction deffectuer distance, sous-entendu depuis lextrieur
des btiments dans lesquels se trouve le systme industriel, en passant potentiellement
par des rseaux non-matriss, des tches de maintenance sur des installations techniques. Cela implique de pouvoir faire des modifications de paramtres.
La tlgestion consiste prendre le contrle distance du systme industriel et pouvoir en faire la gestion complte. Si la tlgestion est utilise, les quipements utiliss
pour ce faire doivent tre intgrs au primtre du systme industriel. Lensemble des
mesures de scurit doivent donc galement sappliquer lensemble du systme.
Classe 1
[R.177] Lorsque des oprations de tlgestion, tlmaintenance ou tldiagnostic
sont ncessaires, les rgles suivantes devraient tre appliques :
les connexions devraient tre faites la demande de lentit responsable ;
lquipement de connexion distant devrait tre authentifi ;
le mot de passe de connexion devrait tre chang rgulirement ;
la journalisation devrait tre active ;
aprs un dlai prcis dinactivit, la connexion devrait tre ferme ;
lquipement devrait tre cloisonn et seuls les flux requis devraient tre
autoriss entre lquipement et le reste du systme industriel ;
les opration de tlmaintenance ne devraient tre faites qu laide de
protocoles scuriss, assurant notamment lintgrit et lauthenticit des
changes.
[R.178] Dans le cas dune connexion par modem noffrant pas de systme dauthentification robuste, a minima, un systme de rappel (call-back) devrait tre
utilis pour valider le numro de tlphone appelant.
[R.179] Lquipement de connexion utilis pour la tlmaintenance devrait tre labellis.
Classe 2
[D.180] La solution de tlmaintenance doit suivre les rgles suivantes :
elle doit assurer la confidentialit, lintgrit et lauthenticit des communications (exemple : VPN IPsec) ;
une authentification forte deux facteurs doit tre mise en place ;
les quipements de connexion doivent tre cloisonns du reste du systme
industriel et seuls les flux indispensables la tlmaintenance doivent tre
autoriss ;
la journalisation des vnements de scurit doit tre active.
[R.181] Une sonde de dtection devrait tre dploye au niveau de la passerelle
de connexion pour pouvoir analyser lensemble du trafic entrant et sortant
(cf R.279).
Classe 3
[D.182] La tlmaintenance ne doit pas tre autorise. Si des oprations de tlmaintenance taient imprativement ncessaires, les quipements distants et la
liaison doivent tre intgrs au primtre du systme de classe 3. Lensemble
des mesures de classe 3 doivent leur tre appliques et en particulier celles de
la section 4.2.5.
[D.183] Des solutions de tldiagnostic peuvent tre mises en place. Dans ce cas,
la solution doit mettre en place les mesures suivantes :
la connexion distante ne se fera que sur un serveur cloisonn ;
les donnes ncessaires au tldiagnostic seront pousses sur ce serveur
au travers dune diode. Cette diode devrait tre labellise.
4.2.5 Systmes industriels distribus

Un systme industriel est considr comme distribu ds lors que des mesures de
protection physique ne sont pas applicables lensemble des quipements et liens le
composant.
Classe 1
[R.184] Lensemble des flux transitant par des rseaux non-protgs physiquement
ou non-matriss devraient utiliser des protocoles scuriss. Ils devraient tre
protgs en confidentialit, en intgrit et authentifis.
[R.185] Lorsque cela est possible des passerelles VPN devraient tre dployes aux
extrmits des liaisons pour protger lintgralit du trafic.
Lquipement devrait tre positionn derrire un pare-feu ne laissant passer
que les flux strictement indispensables. En particulier, le trafic externe au VPN
devrait tre bloqu.
[R.186] Pour les liaisons ayant des besoins de disponibilit, lutilisation de rseaux
publics comme Internet devrait tre vite. Lutilisation de liaisons loues avec
des ressources ddies devrait tre privilgie.
[R.187] Les quipements utiliss dans la recommandation R.185 devraient tre labelliss.
Classe 2
[R.189] Il est recommand de dployer des sondes de dtection au niveau des passerelles dinterconnexion pour pouvoir analyser lensemble du trafic circulant
entre les sites. (cf R.279).
Classe 3
[D.190] Lutilisation de liaisons sur des rseaux publics ne doit pas tre autorise.
4.2.6 Communications sans l

Rfrences
Vulnrabilit : 2.2.8
ISO 27002 : 13.1
Remarque
Dans certains cas, lutilisation de rseau
. sans fil peut tre un secours lutilisation des rseaux publics filaires.
Classe 1
[R.192] Lusage de technologies sans fil devrait tre limit au strict ncessaire.
[R.193] En fonction de lusage, les flux de donnes devraient tre chiffrs et signs
ou seulement signs.
[R.194] Les points daccs sans fil devraient mettre en place les mcanismes suivants :
lauthentification du point daccs et du dispositif qui se connecte linfrastructure ;
les fonctionnalits de contrle daccs rseau (ex : EAP) ;
la journalisation des connexions.
[R.195] Les communications sans fil devraient tre cloisonnes au maximum en isolant les priphriques sans fil dans un rseau physique ou logique spar.
[R.196] Lorsque les vnements de scurit ne sont pas superviss par un dispositif
centralis, il est recommand que les vnements gnrs par les quipements
sans fil soient examins rgulirement.
[R.197] La porte des missions devrait tre rduite au maximum en diminuant la
puissance dmission.
Important
Mme avec une puissance rduite, il est possible de capter des missions dun rseau sans fil grande. distance en utilisant des antennes
et des dispositifs adapts.
Classe 2
[D.199] Les correctifs de scurit doivent tre appliqus systmatiquement sur les
quipements des rseaux sans fil.
[R.200] Une sonde de dtection dintrusion devrait tre dploye au niveau de linterconnexion entre le rseau sans fil et les autres rseaux du systme industriel.
Classe 3
[D.202] Lusage des technologies sans fil est fortement dconseill et doit tre limit
aux cas o il nexiste pas dautre solution.
[D.203] Lutilisation de technologie sans fil doit tre interdite sur toutes les liaisons
ayant des besoins critiques de disponibilit.
[D.204] Les vnements de scurit gnrs par les quipements sans fil doivent
tre centraliss et superviss en temps rel.
[R.205] Lensemble des quipements utiliss dans des rseaux sans fil devraient tre
labelliss.
4.2.7 Scurit des protocoles

Rfrences
Vulnrabilit : 2.2.7
Guide SCADA : BP05
ISO 27002 : 13.2
Classe 1
[R.206] Les protocoles non scuriss (http, telnet, ftp, etc.) devraient tre dsactivs
au profit des protocoles scuriss (https, ssh, sftp, etc.) pour assurer lintgrit,
la confidentialit, lauthenticit et labsence de rejeu des flux.
Classe 2
[R.207] Pour les protocoles ne pouvant pas tre scuriss pour des raisons techniques et oprationnelles, des mesures compensatoires devraient tre mises en
place comme :
mettre en place des protections primtriques (pare-feu) ;
encapsuler les flux dans un VPN pour en assurer lintgrit et lauthenticit.
Classe 3
Remarque
Les protocoles scuriss ne doivent pas toujours chiffrer les flux. Si les flux,
passent par des rseaux non-matriss, le chiffrement est sans doute ncessaire. En revanche, sur un rseau matris, le chiffrement nest pas toujours
.
souhaitable car incompatible avec lutilisation
de sondes de dtection. La
signature des donnes peut tre suffisante.
Labsence de chiffrement ne doit pas tre incompatible avec la recommandation R.138 et la directive D.142.
Important
Certains protocoles intgrent des mcanismes de vrification dintgrit des
donnes bass sur des CRC. Cette mesure,
efficace en sret de fonctionne.
ment, ne constitue pas une protection face des attaques dans le domaine
de la cyberscurit.
4.3
Scurisation des quipements
4.3.1 Durcissement des congurations

Rfrences
Vulnrabilit : 2.2.7
.
Guide SCADA : BP05, BP07, BP10, BP12
et 2.2.3
ISO 27002 : 12.6
Dsactivation des composants inutiles

Classe 1
[R.209] Sur les quipements, on devrait dsactiver :
les comptes par dfaut ;
les ports physiques inutiliss ;
les supports amovibles, sils ne sont pas utiliss ;
les services non indispensables (service web par exemple).
[R.210] Sur les postes de travail, ordinateurs portables et serveurs, on devrait galement supprimer ou, au minimum, dsactiver :
les outils de dbogage et de dveloppement des systmes en production ;
les donnes et fonctions de tests, ainsi que les comptes associs ;
lensemble des programmes non indispensables.
Remarque
Des lecteurs PDF et des logiciels de bureautique sont parfois installs sur des stations SCADA afin de pouvoir consulter des documents
. prfrable de mettre disposition
comme des modes opratoires. Il est
des utilisateurs dautres postes que les stations SCADA pour utiliser les
applications de bureautique et les lecteurs PDF (cf. R.60).
[R.211] Sur les automates et les applications SCADA,

les fonctions de dbogage (des intgrateurs et des quipementiers) devraient tre dsactives ;
les mnmoniques et commentaires ne devraient pas tre chargs dans les
quipements.
Classe 2
Classe 3
Renforcement des protections

Classe 1
[R.214] Les prconisations de durcissement des systmes dexploitation devraient
tre appliques pour chaque quipement. Le site web de lANSSI 1 contient de
nombreux guides et notes techniques sur ce sujet.
[R.215] Les applications doivent sexcuter avec les privilges strictement ncessaires
leur fonctionnement.
1. http://www.ssi.gouv.fr.
Classe 2
[R.217] Des outils de dfense en profondeur du poste de travail devraient tre mis
en place. En particulier, une liste blanche des applications ayant le droit de
sexcuter devrait tre mise en place sur les quipements.
[R.218] Pour les automates, lorsque les quipements le permettent, les mcanismes
suivants devraient tre activs :
la protection daccs la CPU et/ou au programme ;
la restriction des adresses IP pouvant se connecter ;
la dsactivation du mode de programmation distance.
Classe 3
[R.220] Les outils devraient tre labelliss.
Important
Lutilisation dun dispositif de protection antivirale peut ne pas tre adapt
aux systmes industriels pour les raisons suivantes :
les mcanismes de mise jour des signatures peuvent apporter des
vulnrabilits et ncessiter des connexions vers des systmes dinformation externes qui nexistaient pas jusqualors ;
un dispositif de protection antivirale
peut tre incompatible avec les
.
principes et exigences de sret de fonctionnement.
Lutilisation dun antivirus devrait sans doute se faire dans un poste ou un
serveur ddi comme indiqu dans la recommandation R.235 et la directive
D.241 mais elle nest pas recommande pour les autres composants du
systme industriel. Le durcissement des configurations, comme indiqu dans
les recommandations R.217 et R.218, doit tre privilgi.
Intgrit et authenticit
Classe 1
[R.221] Le processus de livraison de lensemble des logiciels, programmes et lments de configuration ainsi que de leurs mises jour devrait intgrer un mcanisme de vrification de lintgrit et de lauthenticit (signature). Les lments
concerns sont en particulier :
les firmwares ;
les systmes dexploitation et logiciels standards ;
les progiciels SCADA ;
les programmes dautomates et de SCADA ;
les fichiers de configuration des quipements rseau ;
etc.
Classe 2
[R.223] Lintgrit et lauthenticit des firmwares, logiciels et programmes applicatifs
(automates, SCADA, etc.) devraient tre vrifies rgulirement. Idalement,
cette tche devrait tre automatise et excute une fois par jour.
Classe 3
[D.224] La directive D.222 est renforce de la manire suivante. Les lments dont
lintgrit et lauthenticit doivent tre vrifies, doivent tre signs par le fournisseur (quipementier, dveloppeur, intgrateur,etc). La signature doit tre vrifie par lentit responsable la rception et par lquipement au chargement.
4.3.2 Gestion des vulnrabilits

Rfrences
Vulnrabilit : 2.2.1
Guide SCADA : BP11
.
ISO 27002 : 12.6
Classe 1
[R.226] Un processus de gestion des vulnrabilits doit tre mis en uvre afin de :
rechercher les correctifs disponibles pour corriger ces vulnrabilits ;
identifier les vulnrabilits connues et mesurer leurs impacts sur les systmes ;
dployer les correctifs en commenant par les plus importants ;
recenser les vulnrabilits qui nont pas pu tre corriges (soit par manque
de correctifs, soit parce que le correctif na pas pu tre appliqu en raison
de contraintes oprationnelles).
Remarque
Appliquer des correctifs nest pas une opration anodine. Il est important de sassurer de leur compatibilit avec le fonctionnement des applications. Le dploiement des correctifs doit tre intgr dans les plans de
maintenance des installations. Il peut,
. en effet, tre judicieux de mettre
en place les correctifs lorsque linstallation est larrt pour une maintenance mcanique par exemple. Aujourdhui, les correctifs concernent
galement les PLC et les quipements de terrain comme les capteurs et
actionneurs intelligents.
[R.227] Les correctifs de scurit doivent tre appliqus en priorit sur les quipements les plus exposs (postes de travail, PC portables, stations dingnierie,
consoles de programmation, pare-feu, VPN, etc.).
Classe 2
[D.228] Les vulnrabilits non corriges doivent tre clairement identifies. Un suivi
spcifique doit tre mis en uvre et des mesures palliatives doivent tre appliques pour diminuer lexposition due ces vulnrabilits.
[R.229] Les correctifs devraient tre valids par les fournisseurs avant le dploiement.
[R.230] Une vrification de lapplication effective des correctifs de scurit devrait
tre effectue. Cette vrification pourra constituer un indicateur de suivi de la
cyberscurit du systme industriel.
Classe 3
[R.232] Un environnement de test reprsentatif des systmes en production devrait
tre mis en uvre afin de sassurer de leur non-rgression aprs lapplication
des correctifs.
4.3.3 Interfaces de connexion

Rfrences
Vulnrabilit : 2.2.3
Guide SCADA : BP03
.
ISO 27002 : 12.6
Gestion des mdias amovibles

Classe 1
[R.233] Une politique dutilisation des mdias amovibles (cl USB, disquette, disque
dur, etc.) devrait tre dfinie.
[R.234] Lemploi des mdias amovibles devrait tre limit au strict minimum.
[R.235] Une station de dcontamination devrait tre installe afin danalyser et dcontaminer tous les priphriques amovibles avant de les utiliser sur le systme
industriel.
[R.236] La connexion des priphriques amovibles qui nont pas t vrifis par la
station de dcontamination devrait tre interdite.
[R.237] Des mdias amovibles ddis aux systmes industriels devraient tre mis
disposition des intervenants. Lutilisation de ces mdias pour tout autre usage
devrait tre interdite. Rciproquement, lutilisation de tout autre mdia devrait
tre interdite.
Classe 2
[D.238] Les recommandations R.233, R.234, R.235, R.236 et R.237 deviennent
des directives.
[R.239] Les ports de mdias amovibles devraient tre dsactivs lorsque leur utilisation nest pas ncessaire. Si le blocage physique nest pas possible, le port
devrait tre dsactiv logiquement.
Par exemple, on pourrait envisager les mesures suivantes :
le blocage des ports USB laide de mcanismes de scurit physiques
ou logiques, comme les verrous USB physiques (avec cls) ou par un logiciel de scurit capable de bloquer lutilisation de cls USB et autres
priphriques ;
le retrait ou la dconnexion des lecteurs de mdias amovibles.
Classe 3
[D.241] Un sas doit tre mis en place pour changer des donnes avec les systmes
industriels. Il doit tre plac dans une zone matrise. Cet change de donnes
est une action ponctuelle qui doit tre encadre par une procdure.
[R.242] La solution de sas devraient tre labellise.
Gestion des points daccs rseau

Classe 1
[R.243] Les points daccs rseau devraient tre clairement identifis et recenss.
[R.244] Les points daccs rseau non utiliss (commutateurs, hubs, baies de brassage, prises de maintenance sur les bus de terrain, etc.) devraient tre dsactivs.
Classe 2
[D.246] En cas de tentative de connexion et de dconnexion sur des ports rseau,
une alerte doit tre remonte et traite.
Classe 3
[D.247] Les points daccs rseau ne doivent tre accessibles que dans des locaux
matriss.
4.3.4 quipements mobiles

Rfrences
Guide dhygine : Rgles 5, 17 et 19 .
ISO 27002 : 11.2.6
Classe 1
[R.248] Lusage des priphriques personnels quels quils soient (ordiphones, tablettes, cls USB, appareils photos, etc.) devrait tre interdit.
[R.249] Une charte dutilisation des terminaux nomades et une signaltique pour
rappeler cette exigence devraient tre mis en place.
[R.250] Les quipements autoriss se connecter aux systmes devraient tre clairement identifis et valids.
[R.251] Lorsque lquipement contient des donnes sensibles, sa mmoire de stockage devrait tre chiffre.
[R.252] Un processus dattribution des terminaux mobiles devrait tre mis en place.
Il devrait permettre, a minima :
de valider lattribution du terminal par le responsable hirarchique ;
dassurer la traabilit entre le terminal et ses utilisateurs ;
de sensibiliser lutilisateur aux rgles dusage en vigueur.
Classe 2
[D.253] les recommandations R.248, R.249, R.251 et R.252 deviennent des directives.
[R.254] Les quipements utiliss devraient tre ddis au systme industriel, y compris ceux utiliss par des prestataires extrieurs.
[R.255] Ces quipements ne devraient pas quitter le site.
Classe 3
4.3.5 Scurit des consoles de programmation, des stations

dingnierie et des postes dadministration
Rfrences
Guide SCADA : BP13
ISO 27002 : 11.2.6
Les consoles de programmation sont des quipements nomades et les stations dingnierie des stations de travail fixes. Dans les deux cas, il sagit de postes ddis
lingnierie des processus du systme industriel. Il peut arriver que le terme poste
dadministration soit utilis ce qui peut prter confusion.
Les postes dadministration sont ddis ladministration des quipements dinfrastructure (commutateurs, serveurs, station, pare-feu, etc.) du systme industriel.
Pour les mesures techniques sur le cloisonnement des fonctions dadministration, on
pourra se reporter la section 4.2.1.
Classe 1
[R.257] Les stations dingnierie devraient respecter les rgles suivantes :
tre ddies aux activits dingnierie ;
ne pas tre connectes Internet ;
tre installes dans des locaux matriss (sous contrle daccs) ;
se voir appliquer les rgles de durcissement des stations de travail ;
tre teintes lorsquelles ne sont pas utilises.
[R.258] Les consoles de programmation devraient :
tre ddies aux activits de maintenance et dexploitation ;
ne pas tre connectes Internet ;
ne pas tre connectes dautres systmes que le systme industriel ;
appliquer les rgles pour les terminaux mobiles ;
appliquer les rgles de durcissement de configuration et de renforcement
des protections ;
tre stockes dans un local scuris ;
tre facilement identifiables (marquage visuel par exemple).
[R.259] Les postes dadministration devraient :
tre ddis ladministration des quipements dinfrastructure ;
ne pas tre connects Internet ;
appliquer les rgles de durcissement de configuration et de renforcement
des protections ;
tre installs dans des locaux matriss (sous contrle daccs) ;
tre teints lorsquils ne sont pas utiliss.
[R.260] Les outils de dveloppement ne doivent pas tre installs sur les machines
de production. Seuls les environnement de production (runtime) doivent tre
installs sur les serveurs et stations SCADA par exemple.
[R.261] La recommandation R.260 peut tre difficile appliquer dans le cas de lutilisation de systmes numriques de contrle-commande (SNCC). Il conviendra
alors dtudier des solutions compensatoires pour isoler le systme et rduire
sa surface dattaque.
Classe 2
[D.262] Les recommandations R.257, R.258, R.259, R.260 et R.261 deviennent
des directives.
Classe 3
[R.263] Les postes dadministration ne devraient pas tre utiliss pour la surveillance
permanente des systmes.
4.3.6 Dveloppement scuris

Rfrences
Ref ISO 27002 : 14.2
Classe 1
[R.264] Des rgles de bonne pratique de programmation devraient tre dfinies,
appliques et vrifies. Pour cela, on pourra par exemple utiliser les options
avances de certains compilateurs ou des outils ddis la vrification des
bonnes pratiques de programmation.
Remarque
Certains compilateurs, ateliers de dveloppement de SCADA et dautomates
disposent de nombreuses options pour remonter des avertissements supplmentaires lutilisateur. Ces options ne. sont souvent pas actives par dfaut.
Elles permettent pourtant dviter de nombreuses erreurs de programmation
et bogues pouvant induire des vulnrabilits.
Remarque
Lapplication et la vrification des bonnes
pratiques de programmation ne
.
permet pas dviter tous les bogues peuvant mener des vulnrabilits.
Classe 2
[R.265] Un environnement de dveloppement devrait tre ddi au systme industriel.
Remarque
Lenvironnement de dveloppement peut tre interne ou chez des four.
nisseurs. Dans ce cas il convient dindiquer
les exigences attendues
dans le cahier des charges (cf. R.51).
[R.266] En plus de bonnes pratiques de dveloppement voques dans la recommandation R.264, des rgles de dveloppement de scurit (secure coding)
devraient tre mises en place et appliques.
[R.267] Des outils danalyse statique et des tests de robustesses devraient tre utiliss
systmatiquement.
[R.268] Des audits de code devraient tre effectus par des prestataires externes.
Classe 3
[D.270] Le niveau de scurit de lenvironnement de dveloppement doit tre vrifi
par des audits.
4.4
Surveillance du systme industriel

Rfrences
Guide de mesures : 2.2.12

Guide SCADA : BP06, 2.2.4
ISO 27002 : 12.4
4.4.1 Journaux dvnements

Classe 1
[R.271] Une politique de gestion des vnements devrait tre dfinie. Elle devrait
permettre :
de dterminer quels sont les vnements pertinents prendre en compte ;
dorganiser leur stockage (volumtrie, dure de conservation, etc.) ;
de dfinir les conditions danalyse (en prventif, post-incident) ;

de dfinir quels sont les vnements qui doivent gnrer des alertes. Lannexe B fournit une liste dvnements en exemple.
[R.272] Les fonctions de traabilit devraient tre actives si les quipements et logiciels le permettent (syslog, SNMPv3, Windows Event, etc.).
[R.273] Un systme de gestion centralise et scurise des journaux dvnements
devrait tre mis en place. Ce systme devra en particulier assurer la sauvegarde, la confidentialit et lintgrit des journaux dvnements. On pourra se
reporter au guide de lANSSI [15].
[R.274] Les modifications des paramtres devraient tre traces et enregistres pour
les capteurs et actionneurs, fonctions dasservissement et de rgulation, etc.
Remarque
Une partie des changements de paramtres des processus peut, dans cer.
tains cas, tre dj enregistre au niveau
des applications de SCADA sous
forme dvnements ou de courbes.
Classe 2
[R.276] Les journaux devraient tre analyss rgulirement.
Classe 3
[R.278] Une solution de SIEM centralisant lensemble des journaux dvnements
de scurit devrait tre mise en place. Elle devrait permettre de corrler les
journaux en vue de dtecter des incidents de scurit. La solution de SIEM,
pour ne pas tre considre de classe 3, devra tre place derrire une diode
comme indiqu la directive D.159.
Moyens de dtection
Classe 1 Il ny a pas de mesure pour cette classe.
Classe 2
[R.279] Des moyens de dtection dintrusion devraient tre mis en place en priphrie des systmes et sur les points identifis comme critiques qui comprennent
notamment :
les interconnexions entre des systmes distants ;
les interconnexions des systmes de tlgestion ;
les interconnexions entre le SI de gestion et le SI industriel ;
les points de connexion spcifiques vers lextrieur (WiFi industriel par
exemple) ;
les stations sas ;
le rseau fdrateur de postes de supervision industriel (SCADA) ;
les rseaux dautomates jugs sensibles.
[R.280] Les moyens de dtection mis en uvre devraient tre labelliss.
[R.281] Les vnements collects par les sondes devraient tre centraliss.
[R.282] Un processus devrait clairement dcrire comment les vnements remonts
par les sondes sont pris en compte.
Classe 3
[D.283] Les recommandations R.279, R.281, R.282 deviennent des directives.
Annexe A
.
Cartographie
Les quipes qui exploitent et maintiennent les systmes industriels doivent pouvoir
sappuyer sur une documentation fiable et jour. Nous proposons dans ce chapitre
quatre types de cartographie diffrents niveaux pour avoir une connaissance aussi
prcise que possible du systme concern. Chacune de ces cartographies consistera
en une liste et en un schma qui organise les lments rfrencs.
A.1 Cartographie physique du systme industriel

Le point de vue physique correspond la rpartition gographique des quipements
au sein des diffrents sites. On pourra organiser cette cartographie sous la forme
dinventaires et dun schma.
A.1.1 Inventaire
Cet inventaire devra comporter notamment les lments suivants :
la liste des quipements communicants du systme industriel :
Cette liste comportera par exemple les automates, les entres sorties dportes,
les capteurs, les actionneurs, les variateurs de vitesse, les centrales de mesures,
les disjoncteurs, les interrupteurs, les serveurs physiques, les postes de travail,
les units de stockage. Pour chaque lment, on prcisera :
le nom ;
la marque ;
le modle ou la rfrence 1 ;
la version du firmware (software version) embarqu et la version du produit
(product version) si pertinent ;
les caractristiques matrielles si pertinent ;
lemplacement physique (btiment, pice, armoire, baie) ;
la liste des commutateurs relis ;
1. Certains quipements (les automates modulaires, par exemple) contiennent plusieurs rfrences.
la liste des quipements des rseaux de communication :

Cette liste comportera par exemple les commutateurs, les routeurs, les passerelles protocolaires, etc. Pour chaque quipement, on prcisera :
la marque ;
le modle et la rfrence ;
la version du firmware embarqu.
lemplacement physique (btiment, pice, armoire, baie).
Dans le cas de commutateurs Ethernet, on prcisera galement les numros de
VLAN pour chaque port du commutateur.
A.1.2 Schma
Il sagit de la reprsentation des diffrents sites gographiques, faisant apparatre :
les commutateurs, les numros de VLAN associs ;
les liens entre quipements ;
en cas dinstallation inter-site, les identifiants dinterconnexion (MPLS, VPLS,
numros de tlphone) ;
les quipements.
A.2
Cartographie logique des rseaux industriels
On sintresse ici la topologie logique des rseaux (les plan dadressage IP et nonIP, noms de sous-rseaux, liens logiques entre ceux-ci, principaux quipements actifs,
etc.). Cette cartographie pourra galement tre organise sous la forme dinventaires
et dun schma.
A.2.1 Inventaires
On propose de rpertorier les lments suivants :
les organisations :
avec pour chacune dentre elles,
le responsable.
la liste des plages dadresses IP :
avec pour chacune,
la liste des commutateurs en support ;
la description fonctionnelle de la plage IP ;
la
la
la
la
les interconnexions avec dautres plages.

liste des rseaux non-IP :
avec pour chaque rseau
la liste des adresses MAC ou des adresses spcifiques des protocoles
industriels sur le rseau ;
la liste des commutateurs en support ;
la description fonctionnelle du rseau ;
les quipements connects dautres rseaux (automates).
liste des points daccs non Ethernet :
avec pour chacun dentre eux,
la liste des ports daccs ;
ladressage en cas de protocole spcifique ;
la liste des quipements connects.
liste des serveurs logiques et des postes de travail :
avec pour chacun dentre eux, lorsque cela sapplique,
ladressage IP (rseau, masque, passerelle) ;
la version du systme dexploitation ;
le serveur physique en support ;
les applications mtier et leur version ;
les services et versions.
liste des automates et quipements de terrain communicants 2 :
avec pour chacun
ladressage IP (rseau, masque, passerelle), ladressage MAC et rseau
associ ou ladressage spcifique le cas chant ;
les applications mtier.
A.2.2
Schma
Il sagit de la reprsentation des ensembles IP (rseaux et sous-rseaux) et de leurs

interconnexions, faisant apparatre :
la description fonctionnelle de la plage IP ;
les interconnexions avec les autres plages IP ;
les routeurs, commutateurs et pare-feu ;
les quipements informatiques de scurit (relais filtrant, sondes, IDS, etc.).
Cette cartographie doit faire apparatre en particulier les points dinterconnexion avec
des entits extrieures (partenaires, fournisseurs de services, etc.) et lensemble des
interconnexions avec Internet.
2. entres sorties dportes, capteurs/actionneurs intelligents, etc.
A.3
Cartographie des applications
Le point de vue applicatif correspond aux applications mtier et aux flux de communication entre elles. Comme prcdemment, on pourra organiser cette cartographie
sous la forme dinventaires et dun schma.
A.3.1 Inventaires
On pourra notamment lister les lments suivants :
le responsable ;
le type dapplication (application SCADA, programme automate, historique,
etc.) ;
le nombre dutilisateurs ;
les quipements (physiques ou logiques) supports ;
les services en coute sur le rseau et ports rseaux associs ;
les flux applicatifs ;
la version de lapplication.
A.3.2 Schma
Il sagit dune reprsentation des composants des applications et des flux entre elles :
les programmes des automates ;
les applications de SCADA ;
les services dinfrastructure (DNS, NTP, passerelle Internet, etc.) ;
les services dadministration ( service dinventaires, dadministration distance,
etc.)
la matrice de flux associe chaque application et service.
A.4
Cartographie de ladministration et de la
surveillance du systme dinformation
Cette dernire cartographie ne sapplique que si une gestion centralise des droits
dadministration sur les quipements a t mise en place. Dans le cas o les droits
sur les quipements ne sont grs que par des comptes locaux, cette cartographie se
rduira une liste des comptes et des droits associs pour chaque quipement.
La cartographie devra contenir :
les annuaires (voir plus bas) ;

les infrastructures de gestion de cls ;
les systmes de mots de passe usage unique ;
les systmes de gestion de journaux et dvnements de scurit (collecteurs de
journaux, SIEM) ;
les systme de supervision (alarmes rseau, sondes de dtection, etc).
Le point de vue domaines dadministration reprsente le primtre et le niveau de
privilges des administrateurs sur les ressources du parc informatique. Cette cartographie contiendra
le cas chant, un schma Active Directory avec :
les domaines Active Directory et leur description,
les forts Active Directory,
les relations dapprobation avec les domaines externes chaque fort,
les caractristiques des relations dapprobation (bidirectionnelle, filtre,
etc.),
les serveurs support des Active Directory ;
sinon, la reprsentation de larchitecture dadministration avec
les zones de responsabilit des diffrents administrateurs,
linventaire des secrets (mots de passe, cls, etc.) et droits associs ladministration des ressources.
Ce point de vue permet, en cas de compromission dun compte dadministration,
didentifier le niveau de privilge de lattaquant et la portion du parc potentiellement
affecte.
Annexe B
.
Journaux d'vnements
Liste minimale (mais non exhaustive) des vnements daudit configurer :
tentatives dauthentification (russite ou chec) ;
actions des utilisateurs dans le systme ;
utilisation des comptes privilges ;
dfaillances des mcanismes de scurit ;
tentatives de connexions rseau ;
dmarrage et arrt des fonctionnalits daudit ;
activation, dsactivation et modification du comportement ou de paramtres
des mcanismes de scurit (authentification, gnration daudit, etc.) ;
actions entreprises en raison dune dfaillance du stockage des audits ;
toute tentative dexportation dinformations ;
utilisation de la fonction de gestion ;
modification du groupe dutilisateurs faisant partie dun rle ;
dtection dune violation physique ;
toute tentative dtablissement dune session utilisateur ;
tentatives de chargement, modification ou rcupration de programme, microprogramme ou firmware ;
modification de paramtres systmes (heure, adresse IP ou non IP, temps de
cycle, chien de garde,etc) ;
modification ou forage de donnes applicatives ;
passage dun quipement en mode stop, marche, stand-by, redmarrage.
Remarque
Les vnements peuvent tre centraliss sur un serveur de type syslog. De
nombreux quipements permettent en effet de configurer un serveur syslog
cible. Pour les journaux dvnements. Microsoft il existe des utilitaires permettant, pour chaque nouvel vnement enregistr, de lenvoyer vers un serveur syslog.
Pour plus dinformation consulter la note dinformation du CERTA [5] et la note technique relative aux recommandations de scurit pour la mise en uvre dun systme
de journalisation [15].
Bibliographie
.
[1]
Gerard De Drouas and Pierre Capillon. Audit des permissions en environnement

Active Directory. In SSTIC, 2012.
[2]
Secrtariat de la dfense et de la scurit nationale. Guide pour raliser un

plan de continuit dactivit. juin 2013.
[3]
ISO. ISO27002 : Security techniques - Code of practice for security management. 2013.
[4]
Agence nationale de la scurit des systmes dinformation. Note dinformation,

les bons rflexes en cas dintrusion. mai 2002.
[5]
Agence nationale de la scurit des systmes dinformation. Note dinformation

pour la gestion des journaux dvnement. mai 2008.
[6]
Agence nationale de la scurit des systmes dinformation. Rfrentiel gnral

de scurit. mai 2010.
[7]
Agence nationale de la scurit des systmes dinformation. Dfinition dune

architecture de passerelle dinterconnexion scurise. janvier 2012.
[8]
Agence nationale de la scurit des systmes dinformation. Guide de lexternalisation. mai 2012.
[9]
Agence nationale de la scurit des systmes dinformation. La scurit des

technologies sans contact pour le contrle des accs physiques. novembre
2012.
[10] Agence nationale de la scurit des systmes dinformation. Maitriser la SSI

pour les systmes industriels. juin 2012.
[11] Agence nationale de la scurit des systmes dinformation. Note technique
pour lutilisation des pare-feu. mai 2012.
[12] Agence nationale de la scurit des systmes dinformation. Recommandations
de scurit relatives aux mots de passe. mai 2012.
[13] Agence nationale de la scurit des systmes dinformation. Cyberscurit pour
les systmes industriels : Classification et mesures principales. 2013.
[14] Agence nationale de la scurit des systmes dinformation. Guide dhygine
informatique. janvier 2013.
[15] Agence nationale de la scurit des systmes dinformation. Recommandations

de scurit pour la mise en oeuvre dun systme de journalisation. dcembre
2013.
Ce guide sur la cyberscurit des systmes industriels a t ralis par lAgence nationale de la scurit des systmes dinformation (ANSSI) avec le concours des socits
et organismes suivants :
Actemium,
Airbus Defence and Space,
Arkoon-Netasq,
A.R.C. Informatique,
Atos Worldgrid,
Hirschmann,
Cassidian Cybersecurity,
CEA,
CLUSIF,
DCNS,
DGA Matrise de linformation,
Euro system,
EXERA,
GDF SUEZ,
Gimlec,
INERIS,
Itris Automation Square,
Lexsi,
Schneider Electric,
Siemens,
Sogeti,
RATP,
Solucom,
Thales,
Total.
propos de lANSSI
LAgence nationale de la scurit des systmes dinformation (ANSSI) a t cre le
7 juillet 2009 sous la forme dun service comptence nationale.
En vertu du dcret n 2009-834 du 7 juillet 2009 modifi par le dcret n 2011-170
du 11 fvrier 2011, lagence assure la mission dautorit nationale en matire de
dfense et de scurit des systmes dinformation. Elle est rattache au Secrtaire
gnral de la dfense et de la scurit nationale, sous lautorit du Premier ministre.
Pour en savoir plus sur lANSSI et ses missions, rendez-vous sur www.ssi.gouv.fr.
Version 1.0 Janvier 2014

Licence information publique librement rutilisable (LIP V1 2010.04.02)
Agence nationale de la scurit des systmes dinformation
ANSSI
- 51 boulevard de la Tour-Maubourg - 75700 PARIS 07 SP
.
Sites internet : www.ssi.gouv.fr et www.securite-informatique.gouv.fr
Messagerie : communication [at] ssi.gouv.fr

Securite Industrielle GT Details Principales Mesures

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Securite Industrielle GT Details Principales Mesures

Uploaded by

Copyright:

Available Formats

.

La cyberscurit des systmes industriels

Table des matires

1.2 Champ dapplication

1.3 Structure du corpus documentaire

1.4 Avis aux lecteurs

2 Considrations relatives la cyberscurit des installations industrielles 9

2.2.1 Matrise des installations

2.2.2 Dfaut de contrle daccs logique

2.2.3 Dfaut de contrle des interfaces de connexion

2.2.4 Cartographie non maitrise

2.2.5 Dfaut de matrise de la configuration

2.2.6 Utilisation dquipements vulnrables

2.2.7 Utilisation de protocoles vulnrables

2.2.8 Dfaut de contrle daccs physique

2.2.9 Dfaut de cloisonnement

2.2.11 Terminaux nomades non matriss

2.2.12 Utilisation de technologies standards

2.2.14 Supervision insuffisante des vnements de cyberscurit

2.2.15 Absence de plan de continuit dactivit

2.2.16 Non prise en compte de la cyberscurit dans les projets

La cyberscurit des systmes industriels Mesures dtailles . 3

2.2.17 Absence de tests de cyberscurit

2.2.18 Absence de matrise des fournisseurs et prestataires

2.2.19 Environnement de dveloppement non scuris

2.2.20 Outils de dveloppement prsents

2.2.21 Non cloisonnement de ladministration

2.2.22 Dfinition des responsabilits

3 Mesures de scurit organisationnelles

3.1 Connaissance du systme industriel

3.1.1 Rles et responsabilits

3.1.3 Analyse de risque

3.1.4 Gestion des sauvegardes

3.1.5 Gestion de la documentation

3.2 Matrise des intervenants

3.2.1 Gestion des intervenants

3.2.2 Sensibilisation et formation

3.2.3 Gestion des interventions

3.3 Intgration de la cyberscurit dans le cycle de vie du systme industriel 39

3.3.2 Intgration de la cyberscurit dans les phases de spcification 42

3.3.4 Audits et tests de cyberscurit

3.3.5 Transfert en exploitation

3.3.6 Gestion des modifications et volutions

3.3.7 Processus de veille

4 . La cyberscurit des systmes industriels Mesures dtailles

3.3.8 Gestion de lobsolescence

3.4.1 Accs aux locaux

3.4.2 Accs aux quipements et aux cblages

3.5 Raction en cas dincident

3.5.1 Plan de reprise ou de continuit dactivit

3.5.2 Modes dgrads

3.5.3 Gestion de crise

4 Mesures de scurit techniques

4.1.1 Gestion des comptes

4.1.2 Gestion de lauthentification

4.2 Scurisation de larchitecture du systme industriel

4.2.1 Cloisonnement des systmes industriels

4.2.2 Interconnexion avec le systme dinformation de gestion

4.2.3 Accs Internet et interconnexions entre sites distants

4.2.4 Accs distants

4.2.5 Systmes industriels distribus

4.2.6 Communications sans fil

4.2.7 Scurit des protocoles

4.3 Scurisation des quipements