LA SECURITE DES SYSTEMES DE CONTROLE/COMMANDE 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
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
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
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 étatique puissante 1. La découverte de ce virus en 2010 a été largement médiatisé (voir Wikipédia 2 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 fait l objet de campagnes de sensibilisation menées en particulier par l ANSSI. Un guide 3 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
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
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 couches fonctionnelles 4, 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
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
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
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). Déclinaison : Figure 5 : Modèle générique en couches 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. iii. iv. 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é». 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). 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
vi. vii. viii. ix. 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. Une couche reçoit des informations de synthèse sur le fonctionnement d une couche inférieure. 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. 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
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 : On peut chercher à suivre l exemple du domaine aéronautique, en définissant des niveaux de type DAL 5 (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). On peut également s inspirer des travaux en cours au titre de l ISA 99.03.03 6, 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
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
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
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 critiques des systèmes d arme : Tous ces acteurs sont associés dans la mise en œuvre d une IGC 7 (IGC croisées 8 ) 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
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
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
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
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