Sûreté de fonctionnement, sécurité des systèmes d ... e Congrès de maîtrise des risques et de sûreté de fonctionnement - Saint-Malo 11-13 octobre 2016 La modélisation du

20e Congrès de maîtrise des risques et de sûreté de fonctionnement - Saint-Malo 11-13 octobre 2016

Sûreté de fonctionnement, sécurité des systèmes d’information et survivabilité des systèmes de systèmes

Dependability, information systems security and survivability of systems of systems

FLORI Anne, HOUDEBINE Jean Christophe, DURAND Gilbert, FARGETTON Hervé Aristè DGA Techniques navales 2 rue du Marché Avenue de la Tour Royale BP 40915 92160 Antony 83050 Toulon cedex tél : 01 46 74 54 10 tél : 04 22 43 37 00, 04 22 43 31 24 e-mail : {[email protected], e-mail : {[email protected],[email protected]} [email protected]}

Résumé Nous proposons une méthode originale pour traiter l’analyse des risques des systèmes de systèmes de Défense. Dans une première partie, nous nous attachons à rappeler les critères classiques d’évaluation des risques dans les trois disciplines de la sûreté de fonctionnement, de la sécurité des systèmes d’information et de la survivabilité et mettons particulièrement l’accent sur les différences entre les indicateurs choisis pour évaluer un système de systèmes et un système « simple ». Nousproposons ensuite une méthode reposant sur une modélisation à base d’un langage formel en argumentant nos choix et en détaillant les objectifs de la modélisation. Enfin dans la dernière partie nous présentons les étapes de la modélisation d’un cas particulier de système de systèmes de Défense soumis à des événements de natures accidentelle mais également intentionnelle (attaques physiques des matériels et attaques des réseaux de communication).

Abstract We propose a novel method for treating risk analysis of Defense systems of systems. In the first part, we endeavor to remind the classic risk assessment criteria in the three disciplines of dependability, information systems security and survivability. In this part we particularly focus on the differences between the indicators chosen to assess a system of systems and a simple system. We then propose a method based on a model designed using a formal language, arguing our choices and detailing the objectives of modeling. Finally in the last part we present the steps of modeling a particular case of Defense system of systems subjected to accidental and intentional events (physical attacks of the equipments and attacks of communication networks).

1 CONTEXTE

Dans le domaine de la Défense, les systèmes d’armes (avions, véhicules blindés, navires, drones…) et les systèmes de systèmes combinant plusieurs systèmes d’armes (groupe aéronaval, groupement tactique interarmes…) sont susceptibles d’être soumis à différents événements indésirables pouvant entraîner, selon les cas, des retards dans la mission (ensemble de tâches opérationnelles réalisées pour atteindre un objectif militaire), une remise en cause de la mission voire des dommages ou des victimes.

Les événements indésirables sont de différentes natures : • Agressions intentionnelles par des menaces « classiques » (missiles, torpilles, obus…) ou par des menaces

« asymétriques » telles que des attaques suicide ou des tirs de roquettes,• Attaques intentionnelles sur les réseaux de communication et les systèmes d’information,• Accidents (collision, échouage, crash…),• Sinistres (incendie industriel, voie d’eau…),• Pannes matérielles,• Dysfonctionnements logiciels.

Différentes disciplines traitent de ces événements notamment la survivabilité, la sûreté de fonctionnement, la sécurité des systèmes d’information, la sécurité incendie ou encore la sécurité des munitions et concourent à la définition des exigences et à l’évaluation des solutions techniques dans les Programmes des systèmes d’armes. Elles s’appuient chacune pour cela sur des méthodes d’analyse de risques techniques spécifiques, ce qui crée un relatif cloisonnement.

Il est nécessaire par ailleurs de prendre en compte de manière rigoureuse les recouvrements entre les disciplines afin d’éviter des sur-spécifications ou des incohérences coûteuses voire dangereuses. Il est donc primordial de disposer de méthodes et outils permettant d’effectuer des analyses globales de risques techniques, tous événements indésirables confondus, dans les phases de conception des systèmes et tout au long de leur cycle de vie de façon à évaluer et respecter le niveau de risques requis au préalable. Ces méthodes doivent pouvoir être alimentées, par les résultats d’évaluation obtenus dans les différentes disciplines (calculs de risque, simulations technico-opérationnelles, simulations physiques…).

Communication 6A /3 page 1/9


2 INDICATEURS RETENUS POUR ÉVALUER LES SYSTÈMES DE SYSTÈMES

Un système de systèmes (SdS), d'après sa définition dans le domaine de l'Armement, est un système complexe dont les constituants en interaction sont des systèmes indépendants sur le plan opérationnel et ont des cycles de vie distincts. Un SdS vérifie les critères suivants :

• Indépendance opérationnelle : si un SdS est désassemblé, ses constituants doivent être capables de remplir de façonautonome une mission propre ; en d’autres termes, chacun est indépendant des autres et a sa propre raison d’être.

• Indépendance managériale : de par leurs profils de vie propres, les constituants sont généralement acquisséparément ; ils sont intégrés pour constituer un SdS, mais chacun a sur le plan opérationnel une existence proprecomme défini par le critère précédent.

• Définition et configuration évolutives : de part le profil de vie propre de chacun de ses constituants, un SdS évolue aucours du temps, de façon réversible ou irréversible ; des missions, des fonctions et des systèmes peuvent êtreajoutés, supprimés ou modifiés en fonction de l'expérience acquise, de l'évolution des besoins ou des aléasopérationnels.

• Distribution géographique : les constituants sont généralement localisés en des lieux (métropole, théâtres, plates-formes) et des milieux (mer, terre, air, espace) différents ; ils peuvent facilement échanger entre eux de l'information,mais ils ne peuvent généralement pas échanger entre eux des quantités substantielles d'énergie ou de matière,contrairement aux systèmes dont les constituants sont colocalisés.

Les systèmes venant composer le SdS auront généralement fait l'objet d'étude de risques visant à répondre à des besoins de sûreté de fonctionnement, de sécurité de systèmes d'information ou de survivabilité définis par des niveaux d'exigences opérationnelles relatives à des critères spécifiques dont nous rappelons ci-après les plus classiques.

Dans le domaine de l'Armement [1], la sûreté de fonctionnement (SdF) d'un système est définie comme l’ensemble des critères(fiabilité, maintenabilité, disponibilité, sécurité) d'un système lui permettant de disposer des performances fonctionnelles spécifiées, au moment voulu, pendant la période voulue, et dans les conditions d’emploi prévues (conditions environnementales, conditions d’emplois et de soutien), sans dommage pour lui-même et son environnement. Selon la ou lesapplications auxquelles le système est destiné, les objectifs de performances visés peuvent être mis plus particulièrement sur l’un ou plusieurs des critères.

La sécurité1 des systèmes d’information (SSI) exprime quant à elle les besoins de sécurité à travers des critères de confidentialité, intégrité et disponibilité [2].

Enfin, la survivabilité d’un système, introduite en 1985 dans l’armée de l’air américaine, est définie dans le domaine de l'Armement [3] comme l'aptitude d'un système à accomplir sa mission (dans un état nominal ou dégradé) dans un contexte marqué par des événements indésirables, potentiels ou avérés. Dans le périmètre strict de la survivabilité, ces événements indésirables sont uniquement des agressions intentionnelles « classiques » (menées par des menaces « physiques »).

Les objectifs de performances de la survivabilité sont évalués au travers des critères de vulnérabilité et de susceptibilité : la (non) susceptibilité caractérisant la capacité du système à éviter d’être soumis aux effets de la menace, la (non)vulnérabilité2,sa capacité à résister aux effets de la menace et la restauration, sa capacité à recouvrer les capacités opérationnelles après avoir été soumis aux effets de la menace.

Alors que les systèmes critiques doivent satisfaire des niveaux d’exigences imposés par les normes de certification en termes de sûreté et de sécurité, la formalisation d’exigences équivalentes au niveau SdS n’est pas encore aussi structurée. Pourtant la mise en relation de systèmes ou encore l'impact de l'intégration d'un nouveau système dans un système de systèmes existant n'est pas sans conséquence sur le niveau global de résilience3 du SdS. Pour faire sens, les indicateurs de sûreté et de sécurité à choisir doivent être au plus près des missions du SdS et rendre compte de l'évolution temporelle de celui-ci ou de ses systèmes tout au long des missions du SdS. On pourra prendre, par exemple :

• Pour un critère de disponibilité, le temps d'exécution d'une mission ou le temps moyen de disponibilité d'un systèmeintégré dans un SdS ;

• Pour un critère de fiabilité, un taux de réussite d'une mission pour un SdS soumis à des agressions par rapport à unfonctionnement nominal du SdS ;

• Pour un critère de sécurité/protection, un temps moyen avant l'occurrence d'un événement indésirable ;• Pour un critère de confidentialité ou d'intégrité, le temps moyen avant intrusion ou le temps moyen de récupération

d'un système dans un SdS.

Il est important de ne pas se limiter sur le choix des indicateurs car l'analyse de risques d'un SdS peut se révéler comme un outil d'aide à la décision dans le choix des architectures de SdS.

3 MÉTHODOLOGIE DE MODÉLISATION D'UN SYSTÈME DE SYSTÈMES

La méthode a été construite pour répondre aux problématiques les plus significatives du traitement des risques d'un SdS inhérentes à sa définition, à savoir :

• la taille importante des systèmes le composant et la complexité des relations entre les systèmes,• la dépendance temporelle entre les systèmes,

1 Parfois nommée sécurité-immunité pour marquer la différence avec la sécurité de la sûreté de fonctionnement.2 Pour les systèmes terrestres, on préférera parler de protection plutôt que de vulnérabilité.3 La résilience est à la fois la capacité de résister à un traumatisme et celle de se reconstruire après lui. Extrapolée au domainedes systèmes de Défense, cette définition amène à faire le parallèle avec les capacités de vulnérabilité et de restauration.



• l'évolution des configurations.

La méthode repose sur une représentation macroscopique de chaque système intervenant dans le système de systèmes à étudier. On cherche ici davantage la cohérence entre les systèmes que la représentation exhaustive des systèmes. Les points essentiels de la méthode visent à :

• Définir les objectifs (comparaison de performances d'architectures, évaluation de la résilience d'un système, disponibilité d'un système, perte de données ...) et les indicateurs qui pourront les quantifier ;

• Identifier les interactions entre les systèmes et les différentes évolutions de fonctionnement et de dysfonctionnements des systèmes qui devront être gérées au cours de la modélisation ;

• Spécifier les scénarios d'attaques par les « menaces physiques » et les « menaces SSI » et les réactions des systèmes aux agressions pour des systèmes nominaux et dégradés.

La méthode de modélisation doit permettre de prendre en compte la forte dépendance temporelle des SdS sous deux formes : • Une forme déterministe liée aux différentes dates fixées pour exécuter les actions successives des systèmes ; • Une forme aléatoire liée aux défaillances des systèmes.

Ces contraintes temporelles orientent les choix des méthodes de traitement vers une modélisation temporelle des systèmes utilisant un traitement à base de simulation de Monte Carlo.

Par ailleurs, compte tenu de la complexité des SdS et de la variabilité des menaces, il est essentiel que la méthodologie de modélisation soit proche de la configuration architecturale du SdS pour des raisons de lisibilité et de facilité d'évolution des architectures et qu'elle puisse intégrer de façon simple toutes nouvelles attaques du SdS. Le langage de modélisation devra donc permettre de décrire des constituants (objets) et de définir leurs relations. Dans ce cadre, une des contraintes fortes de modélisation liée à la variabilité des architectures et des menaces étudiées pour les systèmes de systèmes est la capacité du langage à permettre de modifier le nombre de constituants d’un système de systèmes ainsi que le nombre de relations entre objets sans être amené à modifier le modèle complet.

La modélisation du SdS consiste ainsi à suivre les événements survenant sur ses constituants. Un événement correspondant à un phénomène aléatoire se produit en fonction d'une loi de probabilité temporelle ou instantanée et un événement correspondant à un phénomène déterministe se produit au bout d'un temps constant donné ou calculable (si la condition d'occurrence de l'événement est maintenue pendant cette durée). Dans l’approche choisie ici, nous nous sommes limités à la prise en compte d’événements discrets. Le simulateur de Monte Carlo doit donc planifier la date d’occurrence des événements soit par tirage aléatoire pour les événements dépendant d’une loi de probabilité temporelle ou par calcul pour les événements déterministes. L'état du SdS à un instant donné se définit alors comme l'ensemble des valeurs prises à cet instant par les variables d’état de ses constituants mais aussi par les dates d’occurrence des événements planifiés.

On considère que la vie du SdS est composée d'une suite de cycles, chaque cycle pouvant être décomposé en deux étapes : • dans une première étape, l'occurrence d'un événement a des conséquences directes. • dans une seconde étape, la modification due à l’événement entraîne des conséquences sur l’ensemble des

systèmes, propageant ainsi les effets de l'événement pour obtenir un nouvel état du SdS.

Une fois que le SdS est dans ce nouvel état, d'autres événements peuvent se produire.

La méthode doit permettre de décrire les événements et leurs conséquences directes et de propager les effets d'un événement à l’ensemble du système de systèmes en tenant compte des relations entre constituants. Compte tenu de la complexité des échanges d’informations au sein d’un système de systèmes, le choix de la méthodologie de modélisation est conditionné par la nécessité de gérer de façon automatique des boucles de dépendance (mise en commun d’informations au sein d’un ensemble de systèmes par exemple). La solution de modélisation la plus simple pour prendre en compte ces cas de bouclage consiste à répéter la propagation des conséquences d’un événement jusqu’à stabilisation du système.

Compte tenu des contraintes énoncées ci-dessus sur le choix de la méthode et suite à la réalisation de benchmarks sur des cas pilote de la Défense, la méthode a été mise au point à partir du langage de modélisation Figaro associé aux outils KB3 pour la modélisation du système et Yams pour le traitement à base de simulation de Monte Carlo, tous deux développés par EDF [4][5]. Ce choix est en particulier dû aux possibilités offertes par le langage Figaro et KB3 pour modifier facilement les architectures de système et pour gérer de façon implicite des dépendances bouclées. En effet, Figaro est un langage de haut niveau utilisant des quantificateurs, ce qui évite d’écrire à la main toutes les combinaisons possibles de relations entre les objets du système et ses menaces et permet ainsi de tester rapidement de nombreuses configurations de systèmes de systèmes.

4 RÉSULTATS DU CAS D'ETUDE

La méthode proposée a été testée sur un SdS de Défense impliquant plusieurs plateformes navales. Le SdS présenté ici sous une forme très simplifiée est la tenue de situation multi plateformes (TSMPF). La TSMPF est un SdS en cours de conception. Elle devra à terme être intégrée sur des plateformes navales permettant à ces dernières d'échanger des informations et de fusionner des données pour disposer d'une même situation tactique au sein des différentes plateformes composant la flotte.

Actuellement en phase de conception, la TSMPF est encore mal connue. Pourtant, pour la DGA, il est déjà essentiel de disposer d'indicateurs lui permettant de faire des premiers choix sur l'architecture de la TSMPF. C'est dans ce sens qu'à été déployée notre méthodologie de modélisation sur trois architectures de la TSMPF en comparaison avec le système actuellement intégré.

L'architecture fonctionnelle de la TSMPF est présentée sur la Figure 1 pour laquelle plusieurs architectures matérielles peuvent être envisageables. Trois d'entre elles ont fait l'objet d'une modélisation :



• Architecture d’intégration douce par ajout d’un méga senseur virtuel : la TSMPF est embarquée par ajout de 2 calculateurs TSMPF. Les pistes élaborées par la TSMPF sont injectées dans le CMS (Combat Management System) comme celles d’un nouveau senseur (le senseur TSMPF serait un méga senseur virtuel correspondant à l’addition de tous les senseurs de la TSMPF).

• Architecture d’intégration nominale par extension du CMS : la TSMPF est toujours embarquée par ajout de 2 calculateurs TSMPF et ses 2 calculateurs sont connectés au CMS pour une mise à jour directe de la table des pistes du CMS par celle de la TSMPF.

• Architecture d’intégration forte dans le CMS : la TSMPF est intégrée au CMS comme un module à part entière du CMS.

La Figure 2 présente la première de ces architectures dénommée « architecture d'intégration douce ».

Créer des pistes TSMPF

Fournir des plots

Pistes TSMPF

Temps

Transmettre les plots des senseurs

locaux

Plots locaux

Plots locaux

Plots locaux

Traiter les pistes

Emettre pistes LDT

Transférer les pistes LDT

Recevoir pistes LDT

Fournir les données

temporelles de synchronisation

Emettre plots des senseurs locaux

Recevoir plots des senseurs externes

Plots externes

Pistes veille

Pistes veille externes

Pistes veille externes

Situation tactique

Pistes veille localesTransférer les plots + pistes

TSMPF (si PFP)

Pistes tactiques

Plots externes

Plots locaux

Transmettre les pistes LDT

Pistes veille locales

Figure 1. Architecture fonctionnelle de la TSMPF



Figure 2. Architecture d'intégration douce d’implantation de la TSMPF au sein d’une plateforme navale

L’attribution des fonctions aux différents organes matériels est décrite par le Tableau 1.

Fonctions Description Organe matériel

Émettre plots des senseurs locaux Émettre les plots des senseurs de la PF locale sur le réseau RIFAN

Antenne RIFAN Recevoir plots des senseurs externes Recevoir les plots des senseurs des autres PF

sur le réseau RIFAN

Émettre pistes LDT Émettre les pistes LDT sur le réseau LDT Antenne LDT

Recevoir pistes LDT externes Recevoir les pistes LDT sur le réseau LDT

Fusionner les données senseurs Fusionner les données des senseurs pour créer les pistes LDT

CMS Traiter les pistes Traiter (compiler, identifier, classifier) les pistes d’origine LDT et/ou TSMPF

Transmettre les pistes LDT Transmettre les pistes LDT à l'antenne LDT

Transmettre les pistes TSMPF au CMS Transmettre les pistes TSMPF au CMS Connecteur

Transmettre les plots des senseurs à la TSMPF Transmettre les plots des senseurs à la TSMPF Passerelle

Fournir des plots Fournir les plots des senseurs Senseur

Créer des pistes TSMPF Créer, mettre à jour, supprimer les pistes TSMPF

TSMPF Transmettre les plots des senseurs locaux Transmettre les plots des senseurs à l'antenne

RIFAN

Transférer les plots + pistes TSMPF (si PFP) Transférer les plots des senseurs, les pistes TSMPF (si PFP) et autres données Réseau RIFAN/TSMPF

Transférer les pistes LDT Transférer les pistes LDT Réseau LDT

Fournir les données temporelles de synchronisation

Fournir les données temporelles pour la synchronisation des pistes TSMPF Serveur de temps

Tableau 1 : Fonctions principales de la TSMPF associées aux organes matériels

La construction des scenarii suppose une suite de séquences temporelles indiquant :



• Les événements de détection des menaces de type missile par les différents senseurs des plateformes en situation nominale et situations dégradées (destruction de certains équipements) et les créneaux d’engagement des menaces par les plateformes (plage temporelle pendant laquelle une plateforme peut détruire une menace si elle dispose d’une information de bonne qualité sur la menace) ;

• Les événements de début et de fin d'actions des menaces SSI sur les communications entraînant des ruptures de communication entre les plateformes ou occasionnant des baisses de débits des informations échangées conduisant à un fonctionnement dégradé de la TSMPF.

Les risques sont appréciés vis-à-vis de la remise en cause de certains des enjeux stratégiques de la mission de la TSMPF : • Ne pas pouvoir pister tous les objets d'intérêt ; • Ne pas pouvoir identifier les menaces ; • Ne pas pouvoir engager une menace.

Pour chacun des enjeux remis en cause, les indicateurs choisis pour rendre compte des besoins de disponibilité de la TSMPF sont les suivants :

• Durées de non détection : le total des temps d'absence d'information de détection sur chaque plateforme alors qu'il serait possible d'avoir cette information en l'absence de défaillance,

• Durées de non identification : le total des temps d'absence d'information permettant l'identification de la menace sur chaque plateforme alors qu'il serait possible d'avoir cette information en l'absence de défaillance,

• Durées de non engagement : le total des temps d'absence d'information permettant l'engagement de la menace sur chaque plateforme alors qu'il serait possible d'avoir cette information en l'absence de défaillance.

Les architectures de la TSMPF sont modélisées à partir d'objets génériques décrits par des classes de composants et des classes de menaces dans une base de connaissances.

Les principales informations véhiculées au sein des composants sont les suivantes : • le délai d’obtention et la période de rafraîchissement des plots des senseurs correspondant à chaque menace, • l’état de la piste LDT de chaque menace (inexistante, détectée, identifiée), • l’état de la piste de chaque menace sur la situation tactique (inexistante, détectée, identifiée, engageable).

Les scénarii d'attaques par les missiles sont pris en compte à travers des classes de détection et d'engagement. Les objets de classe « détection » relient une menace à un senseur et définissent chacun un créneau temporel pendant lequel la menace peut être détectée par le senseur. Ce créneau prend en compte la portée et les angles morts du senseur. Les objets de classe « engagement » relient une menace à une plateforme et définissent chacun un créneau temporel pendant lequel la menace peut être engagée par la plateforme. Ce créneau prend en compte la portée et les angles morts des armes.

Les scenarii d'attaques par les menaces SSI sont pris en compte à travers les actions de brouillage des communications. Chaque objet de type « menace SSI » définit un créneau de brouillage et peut être relié à des antennes de communication. Si l’objet « menace SSI » n’est relié à aucune antenne, le modèle simule une baisse du débit de communication entre toutes les plateformes pendant le créneau de brouillage. Si l’objet « menace SSI » est relié à une ou plusieurs antennes, le créneau de brouillage entraîne l’interruption complète des communications transitant par les antennes visées par la menace SSI.

Différentes architectures de SdS peuvent ensuite être testées dans KB3 (exemple sur la Figure 3 de l’implantation d’une architecture TSMPF d’intégration douce au sein de trois plateformes navales) en mettant en relation plusieurs objets de différentes classes de la base de connaissances, les interactions entre objets étant définies de manière générique par les règles établies dans les classes. Elles sont testées pour plusieurs configurations d'éloignement des plateformes les unes par rapport aux autres et pour plusieurs scenarii d’attaques mettant en jeu une ou plusieurs agressions par des menaces de type missile ou de type SSI.



Figure 3. Architecture d'intégration douce d’implantation de la TSMPF au sein de trois plateformes navales

L’évaluation des indicateurs est ensuite obtenue en exploitant numériquement le modèle à l'aide de la méthode de simulation de Monte Carlo proposée par l’outil Yams. Ce dernier utilise une instanciation Figaro 0 du modèle construit dans l'étape précédente et permet de générer automatiquement des séquences tirées aléatoirement tout en évaluant les indicateurs choisis au départ et décrits à l'aide d'expressions Figaro mettant en jeu les variables du modèle.

Les instants d’évaluation des indicateurs peuvent être définis par l’utilisateur sous forme d’intervalles échantillonnés et/ou d’instants ponctuels.

En fonction du besoin et pour chaque indicateur, différents résultats peuvent être étudiés (moyenne, écart type, variance, intervalles de confiance, fractiles, distribution avec un échantillonnage défini par l’utilisateur …). Pour exemple, la Figure 4 présente les distributions des durées de non engagement et la Figure 5, la valeur moyenne et l'écart-type des durées de non détection, de non identification et de non engagement obtenues pour l'architecture actuelle et les 3 architectures de la TSMPF intégrées sur 3 plateformes navales proches et donc capables de communiquer par UHF et soumises à une menace missile et à des agressions par des menaces SSI sur leurs antennes de communication. Les valeurs sont ici non réalistes, elles ne sont présentées que dans un but purement illustratif. Ces types de résultats obtenus pour différents scénarii d'attaque et configurations de déploiement opérationnel permettent d'évaluer l'architecture ayant les durées les plus faibles qui correspondra alors à l'architecture la plus efficace en terme de disponibilité opérationnelle.



0

0,005

0,01

0,015

0,02

0,025

0,03

0,035

0,04

0,045

0,05

0

]0,2

0[

[20,

40[

[40,

60[

[60,

80[

[80,

100[

[100

,120

[

[120

,140

[

[140

,160

[

[160

,180

[

[180

,200

[

[200

,220

[

[220

,240

[

[240

,260

[

[260

,280

[

[280

,300

[

[300

,320

[

[320

,340

[

[340

,360

[

[360

,380

[

[380

,400

[

[400

,420

[

[420

,440

[

[440

,460

[

[460

,480

[

[480

,500

[

[500

,520

[

[520

,540

[

[540

,560

[

[560

,580

[

[580

,600

[

[600

,620

[

[620

,640

[

[640

,660

[

[660

,680

[

[680

,700

[

[700

,720

[

[720

,740

[

[740

,760

[

[760

,780

[

[780

,800

[

>800

Prob

abilt

é

Durée de non engagement (s)

Architecture actuelle Architecture d'intégration douce Architecture d'intégration nominale Architecture d'intégration forte

Figure 4. Distribution de la durée de non engagement pour les 4 architectures

0

50

100

150

200

250

LDT TSMPF1 TSMPF2 TSMPF3

Durée de non détection

moyenne écart-type

020406080

100120140160180200


Durée de non identification

moyenne écart-type

0

100

200

300

400

500

600

700


Durée de non engagement

moyenne écart-type Figure 5. Valeur moyenne et écart-type des durée de non détection, de non identification et non-engagement pour les 4

architectures (LDT : architecture actuelle, TSMPF1 : architecture d'intégration douce, TSMPF2 : architecture d'intégration nominale, TSMPF3 : architecture d'intégration forte)

5 CONCLUSION

La méthode a donc permis de comparer 3 variantes d’architectures liées à l’introduction d’une nouvelle capacité de fusion de données dans le système de systèmes existant. Les résultats obtenus sur des scénarios représentatifs ont d’ores et déjà conforté la DGA dans ses choix d’intégration de la nouvelle capacité TSMPF. Le modèle initial devrait évoluer tout au long du développement du SdS.

La méthode est actuellement encore en cours d'évaluation sur d’autres systèmes en phase de conception. Il reste à tester sa robustesse et sa souplesse pour répondre à des évolutions des systèmes. Son utilisation pourrait également être étendue à des systèmes du domaine civil pour lesquels se posent des problèmes conjoints de protection contre des accidents et des comportements malveillants.



6 GLOSSAIRE

CMS Combat Management System

LDT Liaison de Données Tactiques

PF PlateForme

PFP PlateForme Principale

SdF Sûreté de Fonctionnement

SdS Système de Systèmes

SSI Sécurité des Systèmes d'Information

TSMPF Tenue de Situation Multi Plateformes

7 RÉFÉRENCES

[1] GUIDE DGA S-CAT N° 442 2008, Spécification et management de la sûreté de fonctionnement dans les programmes et opérations d’armement, 1re édition, Guide entretenu par le GT transverse « SdF des matériels d’armement ».

[2] Expression des Besoins et Identification des Objectifs de Sécurité, EBIOS, Méthode de gestion des risques, 2010, ANSSI/ACE/BAC.

[3] GUIDE DGA S-CAT N° 10032 2008, Guide de prise en compte de la survivabilité des systèmes de systèmes (SdS).

[4] Bouissou M., Bouhadana H., Bannelier M., Villatte N. 1991. Knowledge modeling and reliability processing: presentation of the FIGARO language and associated tools. Safecomp'91, Trondheim (Norvège). Note interne EDF R&D HT-53/91-67A, Fonds COLDER.

[5] Bouissou M., Humbert S., Muffat S., Villatte N. 2002. KB3 tool: feedback on knowledge bases, ESREL 2002, Lyon (France).


Documents

Sûreté de fonctionnement, sécurité des systèmes d ... e Congrès de maîtrise des risques et de sûreté de fonctionnement - Saint-Malo 11-13 octobre 2016 La modélisation du