APPLICATION DE LA MÉTHODE À LA SÉCURISATION D’UNE ARCHITECTURE SCADA

Problème de l’application 

Reprenons le cas illustratif

L’application est composée du client Clt1 réalisant l’opération Read sur la ressource Res1 détenue par le composant Plc1. L’une des propriétés à garantir est P RT1 qui énonce que tout accès aux ressources doit respecter les droits d’accès. Après avoir réalisé un mécanisme d’exclusion mutuelle entre Plc1 et Plc2 pour la ressource Res1, Ciprian doit sécuriser l’architecture car celle-ci est maintenant soumise à divers accès extérieurs qui pourraient s’avérer dangereux. Il ne connaît pas bien le domaine de la sécurité, alors prudent, il préfère laisser à Philippe, architecte et expert en sécurité, le soin de concevoir ce modèle. Dans la section précédente nous avons décrit les problem cases et pourquoi nous les utilisons pour décrire le domaine. Différentes questions se posent alors, comment utiliser les problem cases, et comment ces problem cases alimentent la vérification et le diagnostic. 6.2 Domaine de la sécurité On considère qu’il existe un domaine relatif à la sécurité, et qu’il est composé d’un ensemble de problèmes et de solutions exprimées par des problem cases. La présentation de ce domaine est en partie extraite du travail de [OD17] sur les patrons de sécurités. 6.2.1 Architecture abstraite Pour exprimer les propriétés en LTL, et plus généralement pour exprimer les propriétés d’un problème, il est nécessaire d’imposer une architecture minimale sur les solutions. Comme le montre la figure 6.1, nous définissons dans l’espace du problème cette architecture par le biais d’une structure abstraite et d’un comportement générique, semblable au concept de machine dans [Jac01].La structure abstraite définit les constituants de base d’une architecture SCADA (clients, composants, ressources …). Nous prenons pour hypothèse que tout mécanisme de sécurité est inclus dans un constituant de l’architecture de type composant. Pour accéder à un composant de l’architecture, un client Clt doit émettre une requête req. Pour accéder à une ressource res détenue par un composant, cette requête contient l’opération à effectuer sur la ressource opRes. Un composant possède le comportement générique décrit dans la figure 6.2. De l’état Idle, le composant capte un message (receive()) provenant d’une fifo d’entrée, l’emmenant dans l’état de réception nommé Received. Si ce message lui est destiné (mine()=true), il le traite (Compute), sinon il le relaye (Sending). Après traitement, l’accès à la ressource est réalisé (Access), et une réponse est produite, potentiellement négative (NAK), puis transmise au client (Sending).

Point d’accès unique 

Pour s’assurer de l’intégrité d’un système et lutter contre de mauvais usages, une possibilité est de s’assurer que toutes les interactions entre les clients externes au système et le système soient bien autorisées. Cette solution n’est pas viable car elle suppose de vérifier l’intégralité des interactions entre le système (incluant des sous systèmes) et son environnement, réduisant ainsi la performance du système et causant des désagréments pour les utilisateurs. Une solution plus appropriée est de mettre en place un point d’accès unique au système. Ce mécanisme est appelé SAP (Single Access Point). Grâce à ce point d’accès unique, il est possible de vérifier les interactions du client avec le système conformément à une politique de sécurité donnée, en un seul endroit. Le mécanisme protège les frontières du système, facilite l’identification des clients, permet d’améliorer le contrôle et la surveillance des entrées et réduit la taille du code dédié à la sécurisation. 

Fonctionnement

Le mécanisme SAP unifie les points d’accès à la ressource res détenue par un composant C_SAP. Ainsi, toute requête req émise par un client Clt à destination d’un C_SAP, doit passer par le mécanisme SAP. Dans un premier temps, celui-ci appose une signature permettant de certifier aux autres composants son passage par C_SAP. Dans un second temps, si res est accessible, C_SAP réalise l’accès, et si res est inaccessible, C_SAP répond alors directement à la source de la requête avec une réponse négative (NAK) et le traitement se termine. Structure. SAP comprend la fonction check(req) qui vérifie si la ressource demandée res est accessible pour l’opération opRes. Propriétés. Nous ne présentons ici qu’une propriété de disponibilité que nous appellerons PRT_SAP. Celle-ci énonce que toute requête demandant l’accès à une ressource détenue par un C_SAP (request(C_SAP,req)), finira par être contrôlée (evt_check (C_SAP, req), ce qui s’exprime de manière triviale en LTL : P RT_SAP : [evt_request(C_SAP, req) ⇒ ♦evt_check(C_SAP, req)] (6.1) Solution. Une solution concrète est fournie par la figure 6.3. Cette solution a été capturée dans un contexte où le composant C_SAP fonctionnait conjointement avec d’autres mécanismes de sécurité (Checkpoint par exemple). 111 Partie , Chapitre 6 – Application de la méthode à la sécurisation d’une architecture SCADA Figure 6.3 – Exemple d’une solution utilisant le SAP 

Domaine de la sécurité

Point de contrôle 

Un système protégé doit être capable de répondre de façon appropriée lors des différents accès, c’est à dire laisser les clients autorisés à accéder au système, mais dans le même temps limiter l’accès aux clients interdits. Dans le cas où une requête viole les exigences de sécurité, une contre-mesure peut être déclenchée (pour ignorer un message ou envoyer une réponse négative). Il faut aussi prévoir à l’avance l’adaptation du système aux changements d’exigences en termes d’identification et d’autorisation. CHP (Checkpoint) est une solution à ce problème. Il peut être considéré comme l’application du pattern Strategy[Gam95] niveau du SAP [Sch+13]. Il définit l’interface qui devra être supportée par des implémentations concrètes afin de fournir le service d’identification et d’autorisation au SAP. Fonctionnement. Dans l’approche de Obeid [OD17] un CHP complète un SAP. Soit C_CHP, un composant de type CHP et cm, une contre-mesure. La requête req est d’abord contrôlée par un SAP, qui, si elle est valide, demande au CHP de la vérifier au regard d’une politique de sécurité. Si req respecte la politique de sécurité, elle est exécutée (en accédant à la ressource ou en transférant le message). Sinon, le CHP déclenche une contre-mesure cm appropriée à cette requête. Cm peut être une réponse négative envoyée à l’entité source de la demande. Structure. Le CHP comprend un composant décrivant des règles conformes à la politique de sécurité (par exemple, des autorisations d’accès), et un composant de contremesure. Il possède aussi un ensemble de fonctions. La fonction policy_conform (C_CHP, req) retourne vrai si req est conforme à la politique de sécurité de C_CHP. La fonction evt_execute (C_CHP, req) renvoie un événement quand C_CHP exécute req. La fonction counterOf (C_CHP, req) est la contre-mesure de C_CHP associée à la req. La fonction verify(req) vérifie si req respecte la politique de sécurité, et enfin la fonction trigAct(cm) déclenche une cm. Propriétés. Nous ne présentons qu’une propriété, PRT_CHP énonce que toute requête prise en charge (execute(c_chp, req)) a été vérifiée (verify(c_chp, req)), et est conforme à la politique de sécurité (policy_conform(c_chp, req)).