La sécurité des systèmes de contrôle-commande

Transcription

LA S ECURITE DES S YSTEMES DE
C ONTROLE /C OMMANDE
Ce document collectif a été élaboré par les consultants de COGISYS spécialisés en sécurité, et bénéficiant d’une
double compétence : SSI et systèmes industriels. Il propose une synthèse de différents travaux réalisés par
COGISYS, études ou missions de conseils, durant les dernières années. Il devra évoluer pour prendre en compte
les travaux de normalisation internationale en cours sur la sécurité des systèmes de contrôle industriels. Ce
document met l’accent sur les spécificités des systèmes de contrôle commande par rapport aux systèmes
d’information actuels. Il présente un rapide historique du domaine, puis propose une modélisation générique
pour faciliter l’étude des systèmes de contrôle commande. Enfin il met en avant quelques éléments clefs, qui
pourront aider à adapter une démarche d’analyse de la sécurité pour ces systèmes « temps réel » ou « temps
réflexe ».
Décembre 2012
Décembre 2012
SCADA et sécurité : deux mots dont le rapprochement est à la mode
Depuis la communication sur le virus « STUXNET », tout acteur, technique, médiatique ou politique, qui a
besoin d’affirmer son rôle en communiquant sur la sécurité des systèmes industriels, a ajouté l’acronyme
SCADA à son vocabulaire de la sécurité, sans en connaître totalement la portée.
Cet acronyme anglo-saxon signifie: Supervisory Control And Data Acquisition. Il est apparu dans les années 80,
pour désigner les nouveaux systèmes informatiques de supervision de procédés industriels automatisés. Ces
systèmes étaient alors développés sur des plateformes matérielles dédiées, dans la catégorie des miniordinateurs (calculateurs DEC PDP, HP1000, Honeywell, Foxboro, et, en France, MITRA et SOLAR). Ils étaient
mis en œuvre dans de nombreux domaines : pétrochimie, production d’eau potable, cimenterie, sidérurgie,
transport, production d’énergie… Ces systèmes informatiques particuliers étaient caractérisés par un système
d’exploitation « temps réel », qui constituait un socle pour des logiciels spécifiques à chaque installation. Ces
systèmes informatiques assuraient trois fonctions principales :
 La centralisation des opérations de supervision et de conduite des procédés industriels dans une salle
de contrôle unique, via des synoptiques physiques, puis des écrans et des claviers fonctionnels.
 La synchronisation des différentes unités spécialisées participant au procédé industriel, unités ellesmêmes pilotées par des automates et des régulateurs.
 La transmission périodique d’informations relatives à la production (compteurs, statistiques…) vers les
systèmes de gestion des entreprises ou des organismes, et éventuellement l’importation
d’informations relatives aux objectifs de production depuis ces mêmes systèmes de gestion des
entreprises.
Par opposition aux systèmes « informatiques de gestion » qui réalisaient des traitements « simples » sur une
grande quantité de données dans un délai raisonnable (souvent plusieurs heures), les systèmes « informatiques
industriels » réalisaient des traitements parfois complexes sur un nombre de données limité, dans un délai
contraint (inférieur à la seconde, parfois à la milliseconde). On peut également caractériser un système
informatique industriel par ses interactions avec des procédés physiques, alors que les systèmes informatiques
de gestion ne traitent que du monde virtuel des données (les automates de paiement se rattachent, en termes
de fonctionnalités et de technologies aux systèmes informatiques industriels).
Les premiers systèmes, développés spécifiquement au cas par cas, ont progressivement laissé la place à des
solutions à base de logiciels génériques, qui ont pris l’appellation « SCADA ». Ces SCADA offraient des fonctions
de supervision des automates programmables (PLC) et des stations de contrôle déportées (RTU). Les protocoles
d’échanges entre ces éléments, utilisant des « liaisons séries », ont été standardisés à la même période
(MODBUS, JBUS, …), ainsi que les langages de programmations des automates (introduction des principes du
GRAFCET en France par exemple).
Page 1
Décembre 2012
Système de gestion
SCADA
Contrôle/Commande
Figure 1 : Les systèmes SCADA historiques
A partir des années 85-90, la production en grand nombre des PC a bouleversé l’équilibre économique. Les
mini-ordinateurs du domaine industriels ont disparu, d’abord au profit de stations de travail, puis des PC.
L’augmentation de la puissance de calcul et des performances des PC a conduit à remplacer les systèmes
d’exploitation temps réel par les systèmes d’exploitation standards, de type Microsoft Windows. Les SCADA, ou
logiciels de supervision, ont été portés sur ces nouvelles plateformes incontournables, qui ont très vite
supporté les outils de configuration des automates. Dans certains cas, pour permettre le portage des logiciels
de supervision sans modification, sur les plateformes PC, des émulateurs des anciens systèmes temps réel ont
été développés.
Ces évolutions ne posent pas de problèmes particuliers jusqu’aux années 2000, marquées par la suprématie
des communications IP et l’explosion d’Internet. La notion de « système ouvert » devient un dogme. Les
communications sur les sites migrent progressivement des liaisons séries sur les réseaux locaux Ethernet
TCP/IP, qui sont supportés par toutes les plateformes informatiques. Les systèmes s’ouvrent avec des
interconnexions qui se multiplient.
Système de gestion
SCADA
Contrôle/Commande
Figure 2 : Les systèmes SCADA actuels
Page 2
Décembre 2012
STUXNET et la prise de conscience des risques
Sans entrer dans les détails du mode d’action de STUXNET, car il est difficile de vérifier les informations
publiées sur ce sujet, il apparaît clairement que ce virus, d’une complexité nouvelle, a demandé des efforts
importants pour sa mise au point et sa diffusion. Il exploiterait 4 failles de Windows, et le ver aurait une taille
d’un demi mégaoctet.
STUXNET est un virus qui a été importé dans le système Windows par une clé USB. Il s’attaque au logiciel
SCADA de Siemens (WinCC/PCS 7) et se propage localement dans les autres SCADA interconnectés.
Ce virus a la capacité de reprogrammer les automates programmables industriels et de camoufler ses
modifications.
Ce virus aurait modifié les commandes de turbines de centrales nucléaires et de centrifugeuses, en provoquant
des dégradations importantes. Le développement de ce virus a demandé la mise en commun de compétences
fortes, aussi bien sur le système d’exploitation (une faille au moins n’était pas publique lors du
développement), que sur le procédé industriel visé, et le vol d’un certificat racine d’une autorité de confiance.
Manifestement, ce virus n’a pas été développé par un petit groupe de hackers, mais bien par une organisation
1
étatique puissante .
2
La découverte de ce virus en 2010 a été largement médiatisé (voir Wikipédia sur ce sujet). Elle a fait prendre
conscience des risques que courent les infrastructures vitales des pays occidentaux, ainsi que l’intérêt de
pouvoir mener de telles cyberattaques sans exposer la vie des attaquants. Si les attaques sur les systèmes
d’information peuvent avoir des conséquences graves en termes économiques ou en termes d’image, les
attaques sur les systèmes de contrôle commande peuvent avoir des conséquences physiques directes et porter
atteinte directement à des vies humaines.
En France, le risque induit sur les infrastructures d’importance vitale (eau potable, production et transport
d’électricité et de gaz, télécommunications, réseau ferroviaire, transport routier, infrastructures portuaires…) a
3
fait l’objet de campagnes de sensibilisation menées en particulier par l’ANSSI. Un guide sur la sécurité des
systèmes industriels a été publié par l’ANSSI mi 2012. Ce guide se compose d’une première partie de
sensibilisation aux risques, et d’une seconde partie de préconisation de la démarche SSI sur les installations
industrielles. La lecture de ce guide est fortement recommandée.
1 Ce qui est confirmé par l’annonce récente du gouvernement américain, affirmant être à l’origine de ce virus.
2
https://fr.wikipedia.org/wiki/Stuxnet
3
http://www.ssi.gouv.fr/IMG/pdf/Guide_securite_industrielle_Version_finale.pdf
Page 3
Décembre 2012
Sécurité et Sûreté de Fonctionnement
Les notions de sécurité et de Sureté de Fonctionnement (SdF) sont clairement complémentaires pour des
infrastructures d’importance vitale, et plus généralement pour l’ensemble des systèmes industriels :
 La sécurité adresse les risques d’origine environnementale ayant un impact sur le système
 La sûreté adresse les risques provenant du système ayant un impact sur l’environnement
Historiquement, la sûreté de fonctionnement était prise en compte lors de la conception des systèmes, alors
que la sécurité était essentiellement traitée lors de l’installation par des mesures de protection physique.
L’ouverture des systèmes, introduite par les évolutions technologiques, impose de prendre en compte les
besoins de protection dès la phase de conception des systèmes.
Cette prise en compte ne doit pas se faire au détriment de la sûreté de fonctionnement et elle ne doit pas
introduire un niveau de complexité supplémentaire qui serait fatal à l’analyse de sûreté de fonctionnement.
L’introduction de l’analyse de risque SSI dans l’analyse de sûreté de fonctionnement pourra infléchir les
solutions d’architecture : par exemple, lorsque la SdF préconise un doublement d’un composant dans un
système, la SSI pourra préconiser la mise en parallèle de deux composants de sources différentes, qui
permettront d’obtenir une véritable redondance en réponse à une attaque.
Il ne peut donc pas y avoir deux démarches d’ingénierie distinctes, mais une démarche globale cohérente qui
intègre les apports des spécialistes des deux domaines, SdF et SSI.
Page 4
Décembre 2012
Le modèle en couches
Par analogie avec le modèle en couches des réseaux (modèle OSI), on structure les systèmes industriels en
4
couches fonctionnelles , depuis la couche physique (procédé physique), jusqu’au niveau « applicatif »
supérieur, correspondant généralement au système d’information de l’entreprise ou de l’organisme. La couche
supérieure du système industriel offre les services de gestion de la production. Elle fédère des systèmes d’aide
à la conduite, optionnels dans le modèle. Pour chaque sous-système du système industriel, on identifie au
niveau inférieur la couche de conduite (par exemple, pour une unité de production, son système de conduite,
pour un atelier d’énergie, son système de contrôle). Cette couche de conduite donne des consignes à la couche
de contrôle commande (automate, capteurs physiques, actionneurs) qui se situe directement au-dessus du
procédé physique.
Lire ce modèle par
analogie avec le modèle
OSI des réseaux : de la
couche physique en bas, à
la couche applicative la
plus abstraite en haut.
Figure 3 : Modèle en couches
Notre retour d’expérience met en évidence des difficultés à prendre en compte la sécurité dans les couches
basses, pour différentes raisons, bonnes ou mauvaises :
 Dans les systèmes existants, reprendre totalement l’ingénierie, pour insérer des mécanismes de
sécurité non prévus, remet en question les analyses de sûreté de fonctionnement, et fragilise le
système en ajoutant de nouvelles complexités.
 Dans les systèmes existants et relativement anciens (jusqu’à 15 ou 20 ans), le système n’est plus
évolutif (produit abandonné, offre de maintenance inexistante, absence totale de compétence dans la
technologie mise en œuvre), et il n’est donc pas possible d’intégrer des fonctions ou des composants
de sécurité.
 Les mécanismes de sécurisation informatique classiques, sur étagères, ne sont pas facilement
compatibles techniquement des contraintes « temps réel » ou « temps réflexe ».
 Dans certains cas, les technologies mises en œuvre restent différentes des technologies des systèmes
d’information, et il n’existe pas de solution de sécurité sur étagère, accessible à un coût raisonnable.
Les couches hautes d’un système industriel correspondent aux couches applicatives fonctionnelles, qui traitent
exclusivement des informations. La sécurité dans ces couches est prise en compte par les démarches SSI
traditionnelles (ISO 27xxx, SMSI, EBIOS, Méhari…).
4 Ce modèle reste très classique, inspiré de la « pyramide CIM » : le concept CIM (Computer Integrated Manufacturing) est décrit dans « Principles of Computer-Integrated
Manufacturing », édité par John Wiley & Sons en 1992.
Page 5
Décembre 2012
La sécurité des systèmes de contrôle commande (SSCC) adresse les couches de conduite (SCADA), de contrôle
commande (automatismes et régulations) et le procédé physique. Une démarche pour maîtriser la SSCC doit
donc être considérée comme un éclairage adapté des démarches SSI classiques, ou comme une aide à leur
mise en œuvre dans le contexte particulier des systèmes « industriels » ou des systèmes « temps réel », parfois
appelés SCADA, par extension du terme à l’ensemble des couches du système industriel.
Figure 4 : Vision de la SSI et de la SSCC dans le modèle en couches
Page 6
Décembre 2012
LES CINQ ELEMENTS CLES DE LA SECURITE DES SYSTEMES DE
CONTROLE/COMMANDE
Il convient d’identifier 5 éléments clés pour construire la sécurité des systèmes de contrôle commande :
1. Concevoir le système autour de la sécurité passive
2. Respecter le modèle en couches
3. Analyser la criticité du système et de ses sous-systèmes
4. Conduire une démarche SSI dans les couches supérieures du système
5. Maîtriser le réseau industriel
1. Concevoir le système autour de la sécurité passive
La sûreté de fonctionnement, pour les installations sensibles, se construit par une ingénierie orientée « sécurité
passive » : en cas de défaillance d’un organe de contrôle, l’architecture de l’installation est conçue de telle
façon que le procédé physique évolue naturellement, sans intervention, sans besoins externes, vers un état
sûr.
Ce principe, « la panne ou le dysfonctionnement du système de contrôle/commande met le procédé physique
dans un état sûr et stable », doit être adopté pour la SSCCC. Il est applicable aux systèmes des infrastructures
d’importance vitale lorsqu’ils mettent en œuvre des procédés physiques potentiellement dangereux. Cette
notion de danger doit être analysée par rapport à l’utilisateur (quels sont les risques pour les exploitants qui
mettent en œuvre le système ?), ou par rapport aux impacts sur services vitaux rendus par le système (quels
sont les risques pour les populations ?).
La sécurité passive des procédés physiques devrait être recherchée systématiquement, sauf lorsque des
performances particulières demandent de mettre le système physique en état instable dans certaines phases
(qui doivent restées très limitées), ou lorsque le procédé physique contrôlé est intrinsèquement instable : dans
ce cas, la sécurité de la couche contrôle/commande (couche basse temps réel, contrôlant le système physique)
doit faire l’objet d’une analyse de risque très poussée et d’une vigilance extrême en exploitation.
Ce principe ne protège pas le système contre la malveillance informatique, mais il en réduit les impacts
potentiels. Il s’inscrit totalement dans la démarche d’ingénierie orientée « sûreté de fonctionnement ».
Illustrations :
Si on prend l’exemple de « Stuxnet » sur les centrifugeuses iraniennes, une ingénierie de « sécurité passive »
aurait conduit à limiter physiquement la vitesse de rotation maximale en conception pour éviter la possibilité de
survitesse. La modification de la logique de l’automate de sécurité par le virus informatique, n’aurait alors pas
eu les effets destructeurs ; au pire, la centrifugeuse aurait été mise à l’arrêt, ou serait restée dans un état stable
ne permettant l’arrêt que par coupure des alimentations…
Page 7
Décembre 2012
2. Respecter un modèle en couches
Le modèle en couches préconisé (voir figure ci-après) offre un point de vue orienté « sûreté de fonctionnement
» du système : Pour se prémunir des attaques visant à mettre les sous-systèmes dans des états instables ou
dangereux, le cloisonnement des différentes couches doit être recherché systématiquement. Il met l’accent sur
les objectifs de disponibilité et d’intégrité du système. Le modèle en couche prend en compte l’ensemble des
éléments qui constituent le système : en particulier, les éléments des servitudes (énergie, climatisation…)
doivent être intégrés pour permettre une analyse complète du système. Le modèle en couche ne constitue pas
un angle d’analyse pour les seules phases de conception, mais doit être pris en compte également dans les
phases d’exploitation du système (une clé USB ne circule pas d’une couche à une autre, sans contrôle, par
exemple).
Figure 5 : Modèle générique en couches
Déclinaison :
La sécurité des systèmes contrôle-commande préconise le respect des exigences suivantes dans le cadre de la
décomposition en couches d’un système industriel :
i.
Chaque couche est autonome. Les traitements qu’elle effectue ne sont pas conditionnés par le
fonctionnement de la couche supérieure ou des sous-ensembles adjacents (de même niveau).
ii.
La couche basse est la couche la plus proche du procédé physique, c’est-à-dire la couche de
contrôle/commande. Cette couche contient les capteurs physiques, les actionneurs de bas niveau, les
automates de sécurité, le réseau temps réflexe entre automate – capteurs – actionneurs. Elle seule
s’interface directement avec le procédé physique. Elle assure la sécurité des automatismes du procédé :
on parle parfois des « automates de sécurité ».
iii.
Les couches « aide à la conduite » et « gestion de production » sont les couches hautes. Dans ces
couches est implémenté un système d’information (système informatique offrant des IHM), qui n’a pas
d’action directe sur le procédé physique (pas d’interfaces directes avec les actionneurs).
iv.
La couche conduite (SCADA) est la couche intermédiaire. Dans cette couche est implémenté un système
d’information, qui prend ses consignes de la couche d’aide à la conduite, et transmet des consignes à la
couche basse (une consigne n’est pas une commande directe sur le procédé physique, mais un plan
d’actions pour l’automate du niveau bas qui pilote le procédé).
v.
Les objets gérés par une couche correspondent à un niveau d’abstraction du procédé physique
caractéristique de la couche.
Page 8
Décembre 2012
vi.
Une couche donne des « consignes » à une couche inférieure, elle ne s’immisce pas dans ses
traitements : la consigne se rapporte à un objet de synthèse pour la couche inférieure.
vii.
Une couche reçoit des informations de synthèse sur le fonctionnement d’une couche inférieure.
viii.
Les couches sont asynchrones les unes par rapport aux autres. Les couches les plus basses fonctionnent
avec des constantes de temps plus faibles (temps réflexe) que les couches les plus hautes (temps
réfléchi). Ces constantes de temps restent néanmoins relatives, certains sous-systèmes étant « lents »
devant d’autres.
ix.
Les couches les plus basses traitent des objets plus fins (grandeurs physiques), qui seront corrélées,
fusionnées en objets plus élaborés dans les couches plus hautes.
x.
Un composant peut réaliser des fonctions de deux couches, il gère l’asynchronisme entre les deux
couches, ses traitements sont robustes par rapport à la couche haute, il assure une rupture réseau
entre les couches (pas de continuité technologique, rupture protocolaire).
L’intérêt du modèle en couches n’est donc pas d’imposer un cloisonnement total des différentes zones
sensibles d’un système industriel, mais d’identifier clairement les besoins d’échanges d’information, et de
s’assurer que ces échanges ne mettent pas en danger des éléments critiques du système. Le modèle en
couches, depuis son élaboration historique, cherche à faire coopérer l’ensemble des fonctions du système pour
améliorer sa productivité. On cherche donc à s’assurer que cette recherche d’amélioration ne conduit pas à un
effet opposé à celui recherché, en risquant de provoquer l’anéantissement total des capacités de production.
Page 9
Décembre 2012
3. Analyser la criticité du système et de ses sous-systèmes
Les mesures de protection doivent être adaptées en fonction de la criticité (au sens criticité opérationnelle) des
sous-systèmes, et du système lui-même. L’évaluation de la criticité opérationnelle faite à partir de la
décomposition fonctionnelle, en définition et en conception, doit permettre d’ajuster les mesures de
protection en fonction des enjeux réels, de manière cohérente.
Il s’agit donc, en partant de la criticité opérationnelle du système dans son ensemble, d’analyser les
contributions des différents sous-systèmes, puis des différents composants, par rapport à cette criticité pour
fixer des objectifs de sécurité atteignables, raisonnables d’un point de vue économique, comme d’un point de
vue sûreté de fonctionnement.
Déclinaison :
5
On peut chercher à suivre l’exemple du domaine aéronautique, en définissant des niveaux de type DAL (Design
Assurance Level), en analysant l’architecture du système :
Niveau A : Un défaut du système ou sous-système étudié peut provoquer un problème catastrophique
… (par rapport à l’objectif vital).
Niveau B : Un défaut du système ou sous-système étudié peut provoquer un problème majeur
entraînant … (par rapport à l’objectif vital).
Niveau C : Un défaut du système ou sous-système étudié peut provoquer un problème sérieux
entraînant un dysfonctionnement … (par rapport à l’objectif vital).
Niveau D : Un défaut du système ou sous-système étudié peut provoquer un problème pouvant
perturber … (objectif vital).
Niveau E : Un défaut du système ou sous-système étudié peut provoquer un problème sans effet sur …
(objectif vital).
6
On peut également s’inspirer des travaux en cours au titre de l’ISA 99.03.03 , avec l’introduction des « zones »,
auxquelles on peut, de la même manière, attribuer des niveaux de criticité. L'ISA 99.03.03 propose une méthode
pour définir le niveau de sécurité d’une installation, d’une zone ou d’un conduit. Il s’agit de déterminer le
vecteur SAL (pour Security Assurance Level) d’un système informatique. Pour connaître le vecteur SAL, il faut
évaluer la réponse du système face à des exigences de sécurité. A chacune des exigences est associé un niveau
de sécurité :
Niveau 1 : Les fonctions ne sont pas critiques du point de vue opérationnel et ne sont pas susceptibles
de faire l’objet d’attaques ;
Niveau 2 : Les fonctions ne sont pas critiques du point de vue opérationnel mais peuvent faire l’objet
d’attaques ;
Niveau 3 : Les fonctions sont critiques du point de vue opérationnel et peuvent faire l’objet d’attaques.
Elles ne nécessitent pas de réponse immédiate mais leur défaillance peut conduire à des impacts
importants en termes de performance et de résultat financier du fait de la perte totale des capacités
opérationnelles du système
5 Les niveaux DAL sont définis dans la norme DO 178
6 L’ISA (International Society for Automation) élabore des standards, dont l’ISA 99 : Security for Industrial Automation and Control Systems.
Page 10
Décembre 2012
Niveau 4 : Les fonctions sont critiques du point de vue opérationnel et peuvent faire l’objet d’attaques.
Elles exigent une réponse immédiate pour assurer la sécurité publique et environnementale du fait du
risque de perte des capacités opérationnelles du système et même de pertes humaines.
Chaque sous-système, puis chaque couche, puis chaque composant est alors classé par rapport à cette criticité
opérationnelle, qui induit des mesures particulières, en termes organisationnels et techniques, pour les phases
de conception, de vérification, voire éventuellement de qualification, pour les tests périodiques, la
maintenance. Ce classement permet d’obtenir une cartographie des éléments les plus critiques, qui
demanderont une analyse de sécurité plus développée et justifiée. Cette cartographie prend naturellement en
compte les interdépendances en termes de sûreté de fonctionnement comme de sécurité.
Page 11
Décembre 2012
4. Conduire une démarche SSI dans les couches hautes
La mise en œuvre d’une démarche d’analyse de sécurité (que l’on nomme « la démarche SSI ») pour les
couches hautes du modèle reste une mesure essentielle. Elle ne pose pas de problèmes particuliers, lorsque le
modèle en couches est bien construit, car le système cible ainsi limité perd progressivement ses spécificités de
proximité des procédés physiques et de contraintes « temps réel ».
L’analyse de risques est conduite sur la totalité du système, par une coopération entre sûreté de
fonctionnement et SSI. Les mesures de sécurité (principalement techniques) sont essentiellement mises en
œuvre dans les couches hautes. Elles doivent aussi prendre en compte tous les objectifs de sécurité qui n’ont
pas pu être implémentés dans les couches basses (en raison de contraintes de performances par exemple)
suivant le concept de la défense en profondeur.
En outre, la démarche de sécurité permet, le cas échéant, de traiter des objectifs de confidentialité, non pris en
compte dans les couches basses (a priori, les constantes de temps associées aux informations traitées dans les
couches basses, ainsi que leur proximité avec les procédés physiques, justifient cette position). Ces objectifs de
confidentialité peuvent participer à la protection du patrimoine industriel et technique national.
La mise en œuvre de la démarche de sécurité fait l’objet de plusieurs méthodes, dont la méthode EBIOS, qui
reste, en France, la méthode officielle pour les organismes d’importance vitale.
Cette analyse de risques prend en compte l’architecture du système, les échanges avec l’extérieur, les acteurs
qui interagissent avec le système. Elle doit intégrer la criticité des couches basses, qu’elle considère comme un
bien sensible en termes d’intégrité et de disponibilité. Nous préconisons la mise en œuvre d’EBIOS pour les
couches hautes, avec un niveau de granularité correspondant à la maturité du système cible en termes de
sécurité.
Page 12
Décembre 2012
5. Maîtriser le réseau industriel
Sous ce principe, on retrouve les besoins de confidentialité sur la conception du système, et de maîtrise de la
réalisation des composants. Face à la perte de la maîtrise technologique sur des composants numériques
standards, un des éléments de protection important sera la confidentialité lors des approvisionnements des
composants non maîtrisés dans les systèmes industriels d’importance vitale. Cette confidentialité
s’accompagne, de la volonté de maintenir des sources d’approvisionnement différentes, et de la mise en
œuvre de procédures de qualification des composants évoluées. Les solutions en apparence les plus
économiques seront analysées par rapport aux risques, aussi bien sous l’angle de la sécurité que sous l’angle de
la sûreté de fonctionnement. La maîtrise du réseau industriel sera élargie aux procédures d’exploitation et de
maintenance, qui permettront une évolutivité des systèmes en toute sécurité. Tous les fournisseurs de sousensembles d’un système doivent s’engager à fournir la liste des composants du sous-ensemble et à identifier
les sources de ses approvisionnements (arborescence technique du sous-ensemble), à garantir que le sousensemble n’est pas un vecteur de propagation d’une attaque, à proposer une organisation sure pour le soutien
du sous-ensemble, à coopérer en cas d’incident.
Illustration
L’exemple de la maîtrise du réseau industriel dans le domaine avionique, avec une responsabilisation conjointe
des équipementiers, des constructeurs et des compagnies aériennes pourra être repris pour les parties les plus
7
8
critiques des systèmes d’arme : Tous ces acteurs sont associés dans la mise en œuvre d’une IGC (IGC croisées )
qui leur permet de s’engager mutuellement dans leurs activités (co-certification des logiciels embarqués par
exemple).
A l’opposé, pour les parties les moins critiques, le modèle des approvisionnements de composants critiques au «
moindre coût », comme dans l’automobile, ne peut être appliqué qu’en mesurant les risques.
Il ressort de l’analyse de domaines industriels variés que ce principe est d’autant plus respecté que le système
est critique.
7 Infrastructure de Gestion de Clés
8 Les IGC sont dites « croisées » lorsqu’elles intègrent une procédure de reconnaissance mutuelle
Page 13
Décembre 2012
POINTS DE VIGILANCE
En complément de l’application des cinq principes ci-dessus, il convient de respecter un certain nombre de
points de vigilance particuliers dans les architectures des systèmes des infrastructures d’importance
vitale concernant :
 Les fonctions/services inter-couches.
 Les fonctions/services de passage en mode manuel.
 Les fonctions d’administration, de support et de maintenance.
Les fonctions/services inter-couches
Ces fonctions couvrent en particulier des interfaces du système avec l’extérieur, interfaces qui doivent faire
l’objet d’études particulièrement détaillées, autant du point de vue des procédures d’exploitation, que du point
de vue des architectures.
 La fonction de prise de contrôle à distance:
Ce type de fonction est souvent demandé par l’administrateur du système, qui souhaite limiter ses
déplacements, et pouvoir intervenir sur tous les composants en cas de dysfonctionnement. Ce type de
fonction doit être effectuée, seulement si le besoin opérationnel l’impose, en respectant des règles
strictes de sécurité (par exemple : gestion des droits d’accès –authentification, emplacement dédié à
la maintenance,…-, vérification des paquets de mise à jour –signature et origine-,…) La fonction de
télémaintenance : également demandée par l’exploitant pour faciliter les opérations de maintenance ;
elle ne doit être envisagée que lorsque le procédé physique critique n’est pas actif, et avec des
conditions très strictes assurant l’intégrité des échanges
 La fonction de téléchargement :
Nécessaire pour permettre l’évolutivité du système, et son maintien en conditions de sécurité, elle ne
doit être envisagée que lorsque le procédé physique critique n’est pas actif, et avec des conditions très
strictes assurant l’intégrité des logiciels téléchargés; elle doit être hiérarchisée par couche.
 La gestion de parc (de composants) :
Comme la fonction précédente, elle doit être organisée par couche.
 La fonction de synchronisation horaire :
Nécessaire pour assurer la synchronisation des composants, et assurer la synchronisation des
événements sur l’ensemble du système, elle doit être relayée par couche.
Ces fonctions présentent un risque important pour les systèmes des infrastructures d’importance vitale. En
effet, la démarche SSCC est basée sur une sécurité par couche (considérée dans le vocabulaire SSI comme
l’organisation de la « défense en profondeur »). Les risques non couverts par une couche doivent être pris en
charge par la couche supérieure. Une fonction traversant plusieurs couches annihile ainsi la sécurité mise en
œuvre puisqu’elle permet des échanges entre des couches sans passer par les mécanismes de protection des
couches intermédiaires.
Page 14
Décembre 2012
Ces fonctions présentent un risque élevé lorsque les technologies réseau mises en œuvre sont identiques dans
les différentes couches (typiquement avec la technologie IP) : le fait d’avoir une technologie commune ne doit
pas impliquer l’interconnexion automatique des réseaux des différentes couches, voire la mise en œuvre d’un
réseau étendu unique.
La mise en œuvre de réseaux dédiés à l’administration/exploitation technique ne doit pas déroger aux
principes de base : ils ne doivent pas constituer de « ponts directs » inter-couches, même s’ils se situent dans
des plans différents.
Enfin, un élément essentiel dans cette catégorie est constitué par la mise en œuvre de moyens d’accès ou
d’injection d’informations communs à plusieurs couches, rendue possible par la standardisation des interfaces :
ainsi l’utilisation des mêmes terminaux de maintenance, ordinateurs portables, PDA ou équivalents, connectés
à des constituants de plusieurs couches différentes doit être considérée comme la mise en œuvre d’une
fonction inter-couches ; de même, l’utilisation d’un même support amovible pour introduire ou acquérir des
informations sur des composants de plusieurs couches doit être considérée comme la mise en œuvre d’une
fonction inter-couches. Ce point est très important dans les phases d’exploitation d’un système. Il doit être pris
en compte dans l’analyse de risque, comme un vecteur de menace majeur.
Les fonctions/services de passage en mode manuel
 Le passage en mode manuel (prise en main directe du procédé physique au niveau des actionneurs)
coupe le procédé physique du système informatique et de ses contrôles. Ainsi les mesures de sécurité
mises en œuvre se trouvent désactivées, et l’analyse de risque doit en tenir compte. Si, de plus, le
principe de la « sécurité passive » n’est pas totalement appliqué, ce type de mécanisme présente un
risque maximum pour le système. Des mesures particulièrement poussées, relatives à l’ergonomie et à
la formation des exploitants, doivent être mises en œuvre.
Illustration :
Typiquement, ce type d’opération est à l’origine de nombreux accidents sur des installations
industrielles sécurisées, ce qui n’est plus totalement dans l’axe « malveillance informatique ».
Cependant, la possibilité de passage en mode manuel d’un système pourrait être volontairement
recherchée par un attaquant, qui voudrait profiter des vulnérabilités introduites par une exploitation en
mode manuel.
 Implémentation d’une fonction d’une couche dans la couche supérieure (souvent considérée comme
un moyen de secours pour piloter le procédé en mode manuel).
Illustration :
Par exemple, une commande d’actionneur (comme la fermeture d’une vanne) depuis le système de
conduite, ce qui peut revenir à court-circuiter le traitement fait par l’automate. Ce type de fonction est
souvent demandé par un exploitant, qui souhaite réduire ses interventions physiques sur le procédé.
L’implémentation doit assurer la sécurité du procédé physique : elle doit être mise en œuvre par
l’intermédiaire d’une consigne à l’automate, et non par une commande de l’actionneur.
Page 15
Décembre 2012
Les fonctions d’administration, de support et de maintenance
 La fonction d’administration des composants
 La fonction de gestion des configurations
 La fonction d’exploitation des journaux
 La fonction de mise à jour, automatique ou manuelle
 La fonction d’échange standard
 La fonction de restitution (inverse de la sauvegarde)
Ces fonctions représentent un danger pour le système, car la modification de sa configuration peut, si les
mesures de sécurité ne sont pas évaluées ou réévaluées en fonction des changements effectuées, désactiver
ou outrepasser des contrôles de sécurité. Elles sont néanmoins nécessaires pour assurer la sûreté de
fonctionnement et la sécurité du système, par ailleurs. Elles constituent des points de vigilance sur les aspects
organisationnels de l’exploitation, qui sont des axes majeurs d’une démarche de sécurité.
Ces fonctions peuvent être mises en œuvre dans des conditions de stress élevé (typiquement, incident de
fonctionnement), pour lesquelles le respect de procédures de sécurité ne constitue pas une priorité, et peut
même être considéré comme une gêne opérationnelle par les exploitants.
On peut supposer que ces fonctions, associées aux fonctions/services inter-couches, ont été à l’origine du
déploiement du virus STUXNET.
Une grande partie des risques relatifs à ces fonctions se maîtrise par des mesures organisationnelles.
Page 16
Décembre 2012
CONCLUSION
La démarche de sécurité des systèmes de contrôle commande diffère dans sa mise en œuvre de la démarche
de sécurité des systèmes d’information, mais elle reste basée sur les même principes :
 L’analyse de la criticité pour adapter les mesures à prendre aux enjeux réels, avec en particulier la
prise en compte des risques induits par les procédés physiques sur leur environnement.
 La mise en œuvre d’une analyse de risque, basée en principe sur la méthode EBIOS, mais intégrée dans
la mise en œuvre d’une analyse de sûreté de fonctionnement.
La prise en compte d’un existant introduit des contraintes majeures sur la démarche, qui devra être adaptée à
chaque situation, en alliant :
 des actions de sensibilisation aux risques,
 et des objectifs d’amélioration progressive, réduisant les risques les plus critiques en priorité.
COGISYS propose de structurer la démarche en deux phases :
 une phase d’analyse de l’existant, comprenant :

l’évaluation de la criticité,

l’analyse des risques,

la définition des objectifs d’amélioration,

et l’élaboration d’un schéma directeur,
 puis une phase de mise en œuvre du schéma directeur, comprenant pour chaque palier :

l’élaboration de mesures de sécurité,

leur application,

le contrôle de leur application,

et l’exploitation du retour d’expérience pour la préparation du palier suivant.
Cette démarche, de bon sens, s’inscrit dans la logique d’amélioration continue proposée par la norme ISO
27001.
Page 17

La sécurité des systèmes de contrôle-commande

Transcription

Documents pareils

Les couches LAVABLES - Ville de Terrebonne

Diaper Champ

COB Candy 1K Transparent Couleur / "Encre”

sin-out isonem - ODICE Innovation

Attestation de vente de gré à gré

Notes au professeur Initiation à MapInfo - TD 1 Prise en main

Tarifs

Instructions de bricolage Gâteau de couches Modèle

CADEAUX DE NAISSANCE Idées originales