De nombreux systèmes critiques de sûreté de fonctionnement, comme les systèmes de transport, intègrent des systèmes basés sur davantage de logiciels et sont, de plus, connectés et autonomes. De tels systèmes cyber-physiques exigent une grande assurance sur deux propriétés interdépendantes : la sécurité et la sûreté de fonctionnement qui doivent de plus en plus être conçues par co-ingénierie.
Les systèmes de transport dépendent de plus en plus du logiciel pour surveiller et contrôler le monde physique, y compris pour aider ou remplacer le contrôle traditionnellement effectué par l’être humain (par exemple, la conduite assistée/automatique dans les voitures, la conduite automatisées des trains/métros), ce qui rend la criticité de la sûreté de fonctionnement plus importante. En même temps, la connectivité croissante des systèmes (cyber-physiques) renforce également leur exposition aux menaces de sécurité, ce qui peut entraîner des risques de sûreté de fonctionnement. Cela nécessite, donc, une approche de co-ingénierie pour concevoir la sécurité et la sûreté [1].
L’ingénierie des exigences, une étape clé dans tout développement d’un système, est une activité particulièrement importante dans les systèmes de transport. Au fil des années, des méthodes très efficaces ont été développées à la fois pour faire face à la sécurité et à la sûreté de fonctionnement. L’élicitation des exigences axées sur des modèles de buts est une approche majeure d’ingénierie des exigences qui a développé le concept d’analyse des obstacles principalement pour raisonner sur la sûreté de fonctionnement [2]. Un obstacle peut être considéré comme une propriété indésirable (par exemple, une collision de trains) qui entrave directement les objectifs du système (par exemple, la sûreté des passagers) qui sont des propriétés désirées. Ce travail a été, plus tard, revisité pour faire face à la sécurité [3]. On a introduit la notion d’agents malveillants ayant un intérêt dans la réalisation de certains anti-buts (il s’agit du dual des agents « normaux » qui eux coopèrent à la réalisation d’un objectif du système). Le tableau 1 compare les approches de sûreté et les approches sécurité et met en évidence leur important socle méthodologique commun.
Bien que généralement considérées séparément, l’examen conjoint de la sûreté et de sécurité est intuitivement logique étant donné leurs fortes bases communes, notamment en matière de découverte des risques / menaces et d’identification des moyens pour y remédier. Une enquête exhaustive récente réalisée par le projet MERGE ITEA 2 a montré les principales tendances dans le domaine :
Sur la base de l’outil d’ingénierie des exigences Objectiver, nous avons expérimenté quelques variantes de co-ingénierie impliquant différents rôles d’analyse travaillant en coopération sur le même modèle : l’ingénieur système pour le comportement global du système et de l’architecture, l’ingénieur de sûreté pour identifier les modes de défaillance et de leur propagation et ingénieurs de sécurité pour analyser d’éventuelles attaques. Les résolutions des obstacles relatifs à la sûreté et à la sécurité sont examinées dans un deuxième tour. Une revue globale de validation régulière est aussi organisée avec tous les analystes.
| Ingénierie de sûreté de fonctionnement | Ingénierie de sécurité | |
|---|---|---|
| Catégorie de buts | But de sûreté | But de sécurité |
| Variante d’obstacle | Danger | Anti-but (menace) |
| Meilleur raffinement | Cause première | Vulnérabilité |
| Agent | Environnement (élément inattendu) | Hacker (malicieux) |
| Impact | Dommages sur les personnes et les biens, priorité sur les autres exigences (en particulier la disponibilité) | Mesuré en terme « business » (disponibilité du système, réputation, …) |
| Méthode de raffinement | Arbre d’analyse de fautes, HAZOP, FMECA | Arbres d’attaques, arbres de menaces |
| Technique de gestion des risques | Elimination d’obstacle Réduction d’obstacle Tolérance d’obstacle |
Isolation/supression de vulnérabilité Récupération d’attaques Réduction de l’impact d’une attaque |
| Types d’analyses | Analyse au moment du design. Mise à jour rare. Mais l’apprentissage des accidents du passé est une activité importante. | Surveillance au « runtime » pour découvrir des vulnérabilités et des comportements suspects. Des mises à jour fréquentes à « patcher ». |
| Normes et standards | IEC61508 (Générique) ISO26262 (Automobile) IEC50128 (Ferroviaire) DO178B/C, … |
Critères Communs |
A titre d’illustration simple, nous avons considéré le cas d’une voiture connectée. La figure 1 en illustre une architecture typique comprenant de nombreux composant de divers niveaux de criticité interconnecté via de nombreux canaux de nature différente. Nous nous sommes plus particulièrement focalisé sur le sous-système freinage automatique en nous appuyant sur les pratiques SAE recommandées.
La figure 2 montre un extrait de la co-ingénierie de la sécurité / sûreté . Le niveau supérieur montre la structure générale du système et identifie les principaux sous-systèmes. Le sous-système de freinage automatique est ensuite détaillé en se basant sur deux étapes clés : détection de la condition de freinage, puis le freinage à proprement parler. A côté de chaque exigence, une vue mixte du résultat de l’analyse des dangers / menaces est représentée (ceux-ci sont généralement présentés dans des diagrammes séparés). Les obstacles spécifiques sont étiquetés « SAFE » ou « SEC » selon le processus qui les a identifiés. Les profils spécifiques des attaquants peuvent également être capturés. Certaines techniques de résolution proposées dans [2] et [3] sont ensuite appliquées, par exemple, pour rendre l’attaque impossible ou pour réduire son impact. Certaines résolutions peuvent également faire face aux menaces mixtes et réduire ainsi le coût global pour rendre l’ensemble du système fiable.
La prochaine étape de notre recherche sera d’investiguer plus profondément les cyber-menaces dans le contexte des systèmes ferroviaires, en particulier dans le cadre du projet DIGITRANS. Nous prévoyons d’étoffer notre méthode et nos outils en nous basant sur des outils d’ingénierie système tels que Capella.
Références :
[1] D. Schneider, E. Armengaud, E. Schoitsch : “Towards Trust Assurance and Certification in Cyber-, Physical Systems, SAFECOMP Workshops, 2014.
[2] A. van Lamsweerde, E. Letier : “Handling Obstacles in Goal-Oriented Requirements Engineering”, IEEE Trans. on Software Engineering, Vol. 26 No. 10, Oct. 2000.
[3] A. van Lamsweerde et al : “From System Goals to Intruder Anti-Goals : Attack Generation and Resolution for Security Requirements Engineering”, in Proc. of RHAS Workshop, 2003.