Interdépendance des infrastructures critiques
En raison de besoins économiques, organisationnels et fonctionnels de plus en plusn importants, les grandes infrastructures critiques (par exemple. énergie, transport, télécommunications, etc.) dépendent de plus en plus les unes des autres. Ces interdépendances peuvent être bipartites ou multiples entre plusieurs IC.
Certaines de ces interdépendances sont relatives à l’infrastructure de production d’électricité (IPE), dans la mesure où l’IPE dépend des autres infrastructures (par exemple, le besoin de l’IPE en carburant pour faire fonctionner ses générateurs, le besoin de l’IPE en technologies de l’information pour faire fonctionner ses systèmes de contrôle-commande, son besoin en eau pour le refroidissement de certains composants) et d’un autre côté, presque toutes les autres infrastructures dépendent de l’IPE.
Par ailleurs, ces infrastructures critiques intègrent, pour des besoins évidents de fonctionnement et de gestion de données, des technologies et systèmes d’information et de communication eux mêmes fragiles et présentant des risques de défaillance, en particulier vis-à-vis des malveillances volontaires, mais également vis-à-vis des fautes physiques et fautes d’interaction ou de conception involontaires du système. Ces interdépendances (entre IC, entre IC et IIC, et entre IIC appartenant à différentes IC) peuvent conduire à des défaillances en cascade. (lorsque la défaillance d’une infrastructure conduit à la défaillance d’autres infrastructures) et des défaillances en escalade (lorsqu’une défaillance mineure dans une infrastructure provoque rapidement une panne grave de la même infrastructure). En outre, ces phénomènes d’interdépendances, et donc de pannes en cascade potentielles, sont amplifiés par l’ouverture et la dérégulation des marchés, autrefois contrôlés par des monopoles d’état et maintenant ouverts à une concurrence féroce. Ces facteurs économiques rendent la gestion et le fonctionnement des IC plus cruciaux encore et doivent être pris en considération. D’un autre côté, la taille importante (en étendue et en structure) de l’infrastructure critique introduit différentes vulnérabilités (et donc des menaces correspondantes). Il faut tenir compte par exemple des problèmes de disponibilité des ressources et services et des dysfonctionnements des systèmes informatiques en particulier. De plus, les différentes interdépendances et connexions entre les différentes IC agissent sur l’économie de façon directe en raison des différents contrats et accords économiques établis avec les différentes infrastructures, ce qui rend la gestion d’une IC plus complexe que si cette dernière était complètement isolée.
Vulnérabilités et menaces dans les infrastructures critiques
Afin de couvrir l’ensemble des vulnérabilités et menaces liées à une infrastructure critique, il nous semble nécessaire de différencier plusieurs niveaux de vulnérabilités : vulnérabilités au niveau de l’infrastructure critique, vulnérabilités au niveau du réseau d’énergie électrique, vulnérabilités au niveau de l’infrastructure d’information critique. Ces trois catégories sont détaillées dans les paragraphes suivants :
Vulnérabilités touchant l’infrastructure critique . Parmi ces vulnérabilités, on peut citer : Les différentes interdépendances entre deux IC, entre les organisations qu’elles composent, ou entre l’IC et l’IIC qu’elle inclut, ne sont pas vraiment des vulnérabilités mais elles peuvent y conduire. Le vieillissement de composants matériels et physiques utilisés. L’absence de savoirs et connaissances suffisants pour la gestion d’une IC particulière. L’utilisation de certaines technologies standardisées ayant des vulnérabilités (par exemple des protocoles comme http, des systèmes d’exploitation vulnérables, etc.), connues du grand public (disponibilité de l’information). Les infrastructures critiques ont une architecture dynamique, ce qui pose un problème de mise à jour des matériels et de l’organisation générale.
Une infrastructure critique contient des composants hétérogènes qu’il faut utiliser et il faut veiller à leur fonctionnement correct et continu.
Les infrastructures critiques ont généralement une taille considérable, il est donc nécessaire de tenir compte du besoin de passage à l’échelle (scalability) et de la multiplicité des composants qu’elle peut inclure, de leur complexité et de la complexité de leurs interconnexions. Vulnérabilités touchant le réseau d’énergie électrique, parmi lesquelles on peut citer les coupures de ligne physiques, les surcharges de lignes de transport ou de distribution, les pannes au niveau des centrales, des stations de transport ou de distribution, etc.
Vulnérabilités touchant l’infrastructure d’information critique. Ces vulnérabilités seront détaillées de façon plus approfondie dans la section suivante qui donne une description des infrastructures d’information critiques et introduit les points de sécurité sur lesquels nous nous concentrons dans cette thèse.
Définition et enjeux d’une infrastructure d’information critique
L’infrastructure d’information critique peut être menacée par des groupes criminels, par des services de gouvernements étrangers hostiles, par des terroristes, par des hackers, ou par des menaces internes. En outre, ces IIC intègrent des technologies de l’information fragiles (protocoles complexes, utilisation de systèmes d’exploitation vulnérables, logiciels et matériels ayant des failles connues), devant faire face à des menaces spécifiques (défaut de fonctionnement, erreurs de programmation, erreurs humaines, malveillances, etc.), pouvant mener à des pannes plus graves au niveau de l’IC qu’elles contrôlent et donner en fin de compte les mêmes résultats qu’une défaillance globale de l’IC elle-même.
Besoins et exigences de sécurité dans les infrastructures critiques : Dans le but de prendre en compte les différentes caractéristiques d’une infrastructure d’information critique dans le cadre de notre étude, nous devons gérer et mettre en évidence de manière plus claire les différentes propriétés et exigences de sécurité, la disponibilité des services offerts, l’intégrité des données utilisées et leur confidentialité vis-à-vis de tiers non autorisés, etc.
En particulier, afin de faire face à l’évolution de l’environnement de l’infrastructure critique, la structure de l’IIC doit prendre en compte un certain nombre de caractéristiques conceptuelles et fonctionnelles [Moteff & Parfomak 2006] que l’on va détailler dans ce qui suit:
Complexité : généralement, afin d’assurer des besoins opérationnels et fonctionnels, une IIC contient des systèmes (logiques et physiques) complexes, ouverts, hétérogènes, distribués et collaboratifs, dont certains doivent être accessibles par des utilisateurs internes et externes. Dans cette optique, il est absolument nécessaire de prévoir des outils et moyens afin de gérer au mieux cette complexité des systèmes d’information inclus dans l’IC, ainsi que les systèmes et les composants spécifiques à l’IC elle-même (par exemple, les systèmes de production, transport et distribution de l’énergie électrique dans le réseau d’énergie électrique).
Caractère multinational : afin de favoriser le développement économique et de favoriser les aspects de collaboration, une IIC peut s’étendre sur plusieurs zones géographiques, potentiellement dans différents pays voisins (par exemple, le réseau électrique européen qui relie entre-autres, la France, la Belgique, l’Italie, l’Espagne, etc.). Cette extension territoriale et géographique de l’IIC implique de tenir en compte des procédures et normes différentes de création, d’administration et d’utilisation des systèmes d’information qui peuvent être propres à chaque région ou pays.
Extensibilité en taille et structure : pour prendre en compte les changements continuels de structure et l’aspect dynamique de l’architecture de l’IC en général et de l’IIC en particulier, l’IIC doit assurer des propriétés de souplesse, flexibilité et extensibilité en taille et en structure, en nombre d’utilisateurs et de composants, etc.
Caractère multi-organisationnel : pour des raisons économiques, fonctionnelles et organisationnelles, une IIC interconnecte plusieurs organisations qui sont susceptibles de collaborer. Plus particulièrement, ces différentes organisations qui participent à une même IC ou appartenant à différentes IC, peuvent coopérer afin de négocier l’utilisation de certaines ressources ou l’achat de certains services. Ceci permet aux différentes organisations de fournir des ressources à des utilisateurs externes tout en gardant leur indépendance et autonomie. D’un autre côté, avec l’ouverture et la dérégulation des marchés, certaines de ces organisations peuvent être en concurrence entre elles, et donc mutuellement méfiantes. C’est le cas en particulier en Europe, où des entreprises régionales, nationales ou multinationales sont en concurrence mais doivent coopérer pour produire, transporter et distribuer l’énergie électrique.
Politiques et modèles de sécurité
La politique de sécurité organisationnelle est définie dans les Critères Communs (Common Criteria) [CC, 2006] comme un ensemble de règles, procédures, codes de conduite ou lignes directrices de sécurité qu’une organisation impose pour son fonctionnement. Une politique de sécurité est spécifiée par :
des objectifs de sécurité qui doivent être satisfaits, par exemple : “les soumissions à des appels d’offres doivent rester secrètes (c’est-à-dire, ne doivent pas être divulguées à des organismes concurrents)”;
des règles exprimant la manière dont le système peut évoluer de manière sécurisée, par exemple : “l’organisation propriétaire d’une ressource (par exemple, un fichier) est autorisée à accorder des droits d’accès sur la ressource à d’autres organisations qui coopèrent avec elle”.
Une politique de sécurité ne garantit pas, à elle-seule, la sécurité et le bon fonctionnement du système. Pour en vérifier la cohérence, la politique de sécurité est généralement associée à un modèle formel, qui permet d’abstraire la politique de sécurité, de gérer sa complexité, de détecter et de résoudre les situations conflictuelles et de vérifier que tous les objectifs de sécurité sont couverts par les mesures préalablement identifiées. En outre, la politique de sécurité doit être mise en œuvre par les mécanismes de sécurité appropriés, par exemple, des listes de contrôle d’accès (ou ACL, pour Access Control Lists), des règles de filtrage au niveau des pare-feux, des moyens cryptographiques, etc. Dans la pratique, ces mécanismes peuvent être sélectionnés (par exemple, au moyen d’un produit commercial sur étagère) et configurés, ou spécifiés, développés et mis en œuvre spécifiquement, si aucun produit existant ne satisfait totalement les objectifs de la politique ou n’implémente complètement les règles de la politique.
La plupart des politiques de sécurité ne sont en fait que des politiques d’autorisation. L’autorisation vise à permettre aux utilisateurs enregistrés de réaliser toutes les actions légitimes, tout en empêchant que des utilisateurs non-enregistrés mènent quelle qu’action que ce soit dans le système, et des utilisateurs enregistrés réalisent des actions qui ne sont pas légitimes. Les politiques d’autorisation sont le plus souvent mises en œuvre par les mécanismes de contrôle d’accès présents dans la plupart des systèmes informatiques ou dans les équipements de réseaux
(routeurs, pare-feux, etc.). Mais bien souvent il est important que la politique de sécurité contienne aussi des règles d’obligation, en plus des règles d’autorisation et d’interdiction, et rares sont les produits existants capables d’implémenter des règles d’obligation.
Extension d’OrBAC aux systèmes collaboratifs
Dans PolyOrBAC, le modèle OrBAC est utilisé pour spécifier les politiques de contrôle d’accès locales au sein de chaque organisation faisant partie de l’IIC, avec des extensions pour la collaboration entre ces organisations. Grâce aux règles abstraites d’OrBAC, il est possible de spécifier dans un format unique des règles de sécurité de plusieurs systèmes distribués et hétérogènes, tout en offrant un fonctionnement adaptable et flexible pour chaque organisation. OrBAC n’est pas le seul modèle qu’on peut utiliser pour définir des politiques de sécurité dans le contexte des services Web. En 2006, un modèle a été proposé pour appliquer des politiques de contrôle d’accès aux services Web. Dans ce modèle, la politique, appelée WS-Policy, est exprimée en XACML . Cette étude présente des concepts de base pour la sécurisation des services Web et définit des conditions nécessaires pour assurer la mise en œuvre de services Web sécurisés. Elle propose aussi une architecture permettant d’appliquer les WS-Policies. Cette étude peut servir d’inspiration pour spécifier des politiques de sécurité dans les services Web, même si nous préférons utiliser le formalisme OrBAC, qui est très différent de celui de WS-Policy.
Il existe en outre différents travaux utilisant des modèles de contrôle d’accès pour la sécurité des services Web, mais ils ne satisfont pas réellement aux besoins des IIC. Ainsi en 2004, le modèle S-RBAC (Service-Oriented RBAC) a été proposé comme modèle de contrôle d’accès et comme architecture de sécurité axée sur les services Web. Par rapport à d’autres modèles basés sur RBAC, celui-ci a l’avantage de mieux prendre en compte les caractéristiques spécifiques de l’architecture orientée service (SOA) propre aux services Web. À notre connaissance, ce modèle est celui qui se rapproche le plus de la méthodologie de notre travail. Ce qui différencie PolyOrBAC, c’est que notre but principal est de gérer à la fois la sécurité de chacune des organisations et de leurs interactions par les services Web, et non pas seulement de définir des politiques de contrôle d’accès pour les services Web.
Table des matières
INTRODUCTION GENERALE ET PROBLEMATIQUE
CHAPITRE 1. SECURITE DES SYSTEMES D’INFORMATION DANS LES INFRASTRUCTURES
CRITIQUES
1.1 LES INFRASTRUCTURES CRITIQUES
1.1.1 Classification des infrastructures critiques
1.1.2 Exemples d’infrastructures critiques
1.1.3 Interdépendance des infrastructures critiques
1.1.4 Vulnérabilités et menaces dans les infrastructures critiques
1.2 DEFINITION ET ENJEUX D’UNE INFRASTRUCTURE D’INFORMATION CRITIQUE
1.2.1 Besoins et exigences de sécurité dans les infrastructures critiques
1.2.2 Interdépendance des infrastructures d’information critiques
1.2.3 Vulnérabilités et menaces dans les infrastructures d’information critiques
1.3 ÉTUDES ET TRAVAUX EXISTANTS
1.3.1 IRRIIS – Integrated Risk Reduction of Information-based Infrastructure Systems
1.3.2 TCIP – Trustworthy Cyber Infrastructure for the Power Grid
1.3.3 CRUTIAL – CRitical UTility InfrastructurAL resilience
1.4 CONCLUSION DU CHAPITRE 1
CHAPITRE 2. MODELES ET POLITIQUES DE SECURITE
2.1 POLITIQUES ET MODELES DE SECURITE
2.2 MODELES DE CONTROLE D’ACCES TRADITIONNELS
2.2.1 Modèle de contrôle d’accès basé sur les rôles (RBAC)
2.2.1.1 Avantages du modèle RBAC
2.2.1.2 Inconvénients du modèle RBAC
2.2.2 Modèle de contrôle d’accès basé organisation (OrBAC)
2.2.2.1 Concept de rôle et relation Habilite ()
2.2.2.2 Concept de vue et relation Utilise()
2.2.2.3 Concept d’activité et relation Considère()
2.2.2.4 Concept de contexte et relation Définit()
2.2.2.5 Expression de politiques de sécurité dans le modèle OrBAC
2.3 MODELES DE CONTROLE D’ACCES POUR LA COLLABORATION
2.3.1 Gestion centralisée de la sécurité
2.3.2 Gestion décentralisée de la sécurité
2.3.3 Le modèle Multi-OrBAC
2.3.3.1 Règles de sécurité Multi-OrBAC
2.3.3.2 Avantages et inconvénients de Multi-OrBAC
2.3.4 Modèle d’organisation virtuelle
2.3.4.1 Modèle de sécurité pour les organisations virtuelles
2.3.4.2 Avantages et inconvénients du modèle d’organisation virtuelle
2.3.5 Le modèle O2O (Organisation 2 Organisation)
2.3.5.1 Présentation de la notion de VPO
2.3.5.2 Dépendance des droits d’accès avec les rôles
2.3.5.3 Gestion des utilisateurs et rôles
2.3.5.4 Avantages et inconvénients du modèle O2O
2.4 CONCLUSION DU CHAPITRE 2
CHAPITRE 3. POLYORBAC : SCHEMA-CADRE DE SECURITE POUR LA COLLABORATION
3.1 EXTENSION D’ORBAC AUX SYSTEMES COLLABORATIFS
3.2 COLLABORATION ET INTEROPERABILITE AVEC LES SERVICES WEB
3.2.1 Architecture Orientée Services (SOA)
3.2.2 Normes des services Web
3.3 EXTENSIONS DU MODELE ORBAC POUR LES SERVICES WEB
3.3.1 Politique globale et politiques locales
3.3.2 Images de services Web et utilisateurs virtuels
3.3.3 Limites des services Web et nécessité de vérification à l’exécution
3.4 EXPRESSION ET VERIFICATION DES INTERACTIONS PAR SERVICES WEB
3.4.1 Contrats et politiques-contrats
3.4.2 Expression des politiques-contrats sous forme d’automates temporisés
3.4.2.1 Expression des permissions
3.4.2.2 Expression des interdictions
3.4.2.3 Expression des obligations
3.4.2.4 Identification des situations de conflits
3.4.3 Vérification des politiques-contrats
3.5 RECAPITULATION DU FONCTIONNEMENT GENERAL DE POLYORBAC
3.5.1 Création et publication d’un service Web par un prestataire
3.5.2 Négociation et signature du contrat
3.5.3 Invocation et exécution du service Web
3.6 CONCLUSION DU CHAPITRE 3
CHAPITRE 4. ÉTUDE DE CAS ET APPLICATION DE POLYORBAC
4.1 INFRASTRUCTURE DE PRODUCTION, TRANSPORT, ET DISTRIBUTION D’ENERGIE ELECTRIQUE
4.2 DESCRIPTION DU SCENARIO DE DELESTAGE
4.2.1 Architecture de l’infrastructure
4.2.2 Déroulement du scénario de délestage
4.3 ARCHITECTURE DE L’INFRASTRUCTURE D’INFORMATION CRITIQUE
4.4 VISION POLYORBAC DU SCENARIO DE DELESTAGE
4.4.1 Définition des services Web
4.4.2 Contrôle d’accès et vérification pour SW1-demande_d’armement
4.4.2.1 Règles OrBAC pour la demande d’armement par le TS CC
4.4.2.2 Automate de SW1-demande_d’armement au niveau du TS CC
4.4.2.3 Règles OrBAC de SW1-demande_d’armement dans la politique du DS CC
4.4.2.4 Automate de SW1-demande_d’armement dans le CIS du DS CC
4.4.3 Contrôle d’accès et vérification pour SW2-ordre_d’armement
4.4.3.1 Automate de SW2-ordre_d’armement du côté DS CC
4.4.3.2 Règle OrBAC de l’armement dans la politique du DS SS
4.4.3.3 Automate de SW2-ordre_d’armement du côté du DS SS
4.5 CONCLUSIONS DU CHAPITRE 4
CHAPITRE 5. MISE EN ŒUVRE ET IMPLEMENTATION DU SCHEMA-CADRE POLYORBAC
5.1 OBJECTIF DE LA MISE EN ŒUVRE
5.1.1 Présentation du scénario de l’expérimentation
5.1.2 Besoins et contraintes du prototype
5.2 MISE EN PLACE DE L’EXPERIMENTATION
5.2.1 Description de la plateforme d’émulation
5.2.2 Définition des composants de base liés à PolyOrBAC
5.2.3 Présentation des outils de l’expérimentation
5.2.4 Implémentation des mécanismes de collaboration par services Web
5.2.5 Implémentation des mécanismes de contrôle d’accès OrBAC
5.2.6 Implémentation des mécanismes de vérification des interactions par contrats
5.3 EXECUTION DU SCENARIO EN FONCTIONNEMENT NORMAL
5.4 FONCTIONNEMENT DU SCENARIO EN PRESENCE D’ERREURS
5.4.1 Double invocation du même service
5.4.2 Erreur d’Invocation non attendue
5.4.3 Violation d’une condition OrBAC sur le contexte
5.4.4 Erreur due à une tentative d’extension de privilège
5.4.5 Erreur liée à une échéance temporelle non respectée
5.4.6 Erreur dans les contrats en raison d’un message non attendu
5.5 CONCLUSION DU CHAPITRE 5
CONCLUSION GENERALE
