Maîtrise des Correctifs de Sécurité pour les Systèmes Navals

HAL Id: hal-01431543

https://hal.archives-ouvertes.fr/hal-01431543

Submitted on 11 Jan 2017

HAL is a multi-disciplinary open access archive for the deposit and dissemination of sci- entific research documents, whether they are pub- lished or not. The documents may come from teaching and research institutions in France or abroad, or from public or private research centers.

L’archive ouverte pluridisciplinaire HAL, est destinée au dépôt et à la diffusion de documents scientifiques de niveau recherche, publiés ou non, émanant des établissements d’enseignement et de recherche français ou étrangers, des laboratoires publics ou privés.

Maîtrise des Correctifs de Sécurité pour les Systèmes Navals

Bastien Sultan, Fabien Dagnat, Caroline Fontaine

To cite this version:

Bastien Sultan, Fabien Dagnat, Caroline Fontaine. Maîtrise des Correctifs de Sécurité pour les Sys- tèmes Navals. CIEL 2016 : 5ème Conférence en Ingénierie du Logiciel, Jun 2016, Besançon, France.

pp.1 - 6. �hal-01431543�

Maˆıtrise des Correctifs de S´ecurit´e pour les Syst`emes Navals

Bastien Sultan ¹ , Fabien Dagnat ² et Caroline Fontaine ³

1

Chaire de Cyber D´ efense des Syst` emes Navals Ecole navale, T´ ´ el´ ecom Bretagne, DCNS, THALES

Ecole navale – CC 600 ´ F29240 Brest CEDEX 09 bastien.sultan@telecom-bretagne.eu

2

IRISA, T´ el´ ecom Bretagne fabien.dagnat@telecom-bretagne.eu

3

Lab-STICC, CNRS, T´ el´ ecom Bretagne caroline.fontaine@telecom-bretagne.eu

R´ esum´ e

Un navire est un syst` eme complexe, op´ er´ e dans le but d’accomplir un ensemble de missions.

Les composants d’un tel syst` eme peuvent ˆ etre affect´ es de vuln´ erabilit´ es dont l’exploitation peut avoir des cons´ equences sur les missions en cours. Il est donc n´ ecessaire d’appliquer des correctifs r´ eduisant le risque li´ e ` a ces vuln´ erabilit´ es. Mais il est important de s’assurer que ces correctifs n’ont pas eux-mˆ emes d’impact n´ egatif sur les missions du navire. Nous proposons, dans cet article, l’architecture d’un processus de gestion des correctifs appliqu´ e au contexte des syst` emes navals. Nous extrayons de ce processus les probl´ ematiques prin- cipales qu’il pose : la mod´ elisation d’un syst` eme complexe, et le calcul des impacts li´ es aux correctifs et vuln´ erabilit´ es. Nous ´ evoquons ensuite l’int´ erˆ et de la f´ ed´ eration de mod` eles pour repr´ esenter le syst` eme naval, puis nous proposons une mesure de l’impact des cor- rectifs et vuln´ erabilit´ es sur la sˆ uret´ e de fonctionnement du syst` eme, bas´ ee sur l’utilisation d’automates temporis´ es.

Mots cl´ es : mesures d’impact, f´ ed´ eration de mod` eles, syst` emes navals, correctifs, cy- berd´ efense

Ships are complex systems operated to perform a given set of missions. Such systems can be affected by vulnerabilities which, when exploited, can impact their missions. Thus it is necessary to apply patches to mitigate these vulnerabilities, and fundamental to ensure that deployed patches does not negatively affect the system’s dependability. This paper puts forward a patch management process architecture applied to naval systems. An analysis of this process allows us to evoke the two main issues of our research: complex systems modelling and impact assessment. Then we present models federation as a tool for ships modelling, and an impact assessment approach based on trace analysis of timed automata.

Keywords: impact assessment, models federation, naval systems, patch management, cy- bersecurity

Introduction

R´ epondant ` a l’objectif d’acquisition de comp´ etences et de technologies en cybers´ ecurit´ e

prˆ on´ ee par le Livre Blanc de la D´ efense 2013, la Chaire de Cyber D´ efense des Syst` emes Navals

est n´ ee de la coop´ eration acad´ emique et industrielle entre T´ el´ ecom Bretagne, l’ ´ Ecole Navale,

DCNS et Thales. L’application de la recherche en cybers´ ecurit´ e au domaine naval est, en effet,

particuli` erement importante ` a l’heure o` u les bˆ atiments – civils ou militaires – embarquent un

grand nombre de syst` emes informatiques contrˆ olant notamment des actionneurs m´ ecaniques

d’importance critique, ou permettant au navire de communiquer, se localiser, percevoir son

environnement op´ erationnel.

Toute b´ en´ efique qu’elle soit en termes d’efficacit´ e et de pr´ ecision, la pr´ esence de ces syst` emes informatiques peut ouvrir des br` eches ` a un attaquant sachant les exploiter. Ces failles peuvent ˆ

etre logicielles, mat´ erielles, organisationnelles, humaines et posent le probl` eme de leur d´ etection et de leur comblement. V´ eritable processus critique du syst` eme naval, la maˆıtrise des correctifs palliant ces failles est au cœur des travaux dont la phase initiale est pr´ esent´ ee dans cet article.

Il convient, dans la premi` ere partie du document, de d´ efinir les notions essentielles mobilis´ ees par nos travaux. Nous nous attachons ensuite ` a pr´ esenter le mod` ele simplifi´ e d’un processus de gestion de correctifs, dont l’´ etude nous permet de d´ egager les deux probl´ ematiques majeures du projet de recherche : la repr´ esentation du syst` eme, et les calculs d’impact et de risque des correctifs et vuln´ erabilit´ es. La partie 3 permet d’exposer notre mani` ere d’aborder ces deux th´ ematiques et de mettre en ´ evidence leurs liens. Enfin, la partie 4 pr´ esente une d´ emarche d’estimation d’impact bas´ ee sur l’analyse de trace d’automates temporis´ es.

1 Le navire, un syst` eme complexe

Un navire, ou syst` eme naval, est un syst` eme complexe compos´ e d’un ensemble de sous- syst` emes, dont des syst` emes cyber-physiques (CPS), op´ er´ es par un ´ equipage dans le but d’ac- complir des missions. Les fonctions d’un syst` eme naval impliquent de nombreux acteurs. Par exemple, la navigation repose sur des capteurs GNSS et/ou des centrales inertielles, des syst` emes de traitement et d’analyse de leurs signaux, le choix de la route, l’op´ eration des syst` emes de propulsion... La s´ ecurit´ e de ces ´ equipements est primordiale : si l’un d’entre eux ne remplit pas son rˆ ole, cela peut mettre en p´ eril le syst` eme ou ses missions. Or, dans l’ex´ ecution de telles fonc- tions, des faiblesses peuvent affecter des acteurs divers (capteurs, actionneurs, proc´ edures, ...) et perturber ainsi les diff´ erentes ´ etapes des missions. La mise en place d’un correctif, ayant pour but de temp´ erer ces faiblesses, peut ´ egalement perturber le fonctionnement du navire. Il est donc n´ ecessaire d’´ etudier les impacts des vuln´ erabilit´ es et des correctifs sur le syst` eme. Cette

´

etude implique de d´ efinir les notions de syst` eme, vuln´ erabilit´ e, correctif et impact.

— Syst` eme : Un syst` eme est une entit´ e compos´ ee d’op´ erateurs, de proc´ edures, d’´ equipements mat´ eriels, de fonctions et de logiciels. Les composants de cette entit´ e œuvrent conjointement dans leur environnement op´ erationnel dans le but d’accomplir des missions donn´ ees [10]. Le syst` eme poss` ede une politique de s´ ecurit´ e [1] garantissant notamment la sˆ uret´ e de fonction- nement de ses ´ el´ ements.

— Vuln´ erabilit´ e : Une vuln´ erabilit´ e, ou faille, est une faiblesse dans la conception, la confi- guration, l’op´ eration ou la maintenance d’un syst` eme, qui peut ˆ etre exploit´ ee pour violer sa politique de s´ ecurit´ e. Une vuln´ erabilit´ e suit un cycle de vie [5] ; on peut ` a chaque stade de ce cycle associer un niveau de risque ` a la vuln´ erabilit´ e qui s’exprime en fonction de son impact et de la probabilit´ e de son exploitation.

— Correctif : Un correctif est une mesure, ou un ensemble de mesures (action, dispositif mat´ eriel, logiciel, proc´ edure, ...) qui r´ eduit la possibilit´ e d’exploiter une vuln´ erabilit´ e [9].

Son application peut ˆ etre temporaire ou permanente.

— Impact : L’impact de l’exploitation d’une vuln´ erabilit´ e (resp. du d´ eploiement d’un correctif,

des op´ erations de d´ eploiement de ce correctif) est l’ensemble des retomb´ ees de l’exploitation

d’une vuln´ erabilit´ e (resp. du d´ eploiement d’un correctif, des op´ erations de d´ eploiement de ce

correctif) sur la capacit´ e du syst` eme ` a accomplir ses missions de mani` ere sˆ ure. Ces impacts

permettent de comparer les cons´ equences de chacun de ces ´ ev´ enements, et donc de d´ ecider

de la d´ emarche la plus adapt´ ee lors de la d´ ecouverte d’une faille, en fonction des missions

en cours (faut-il appliquer un correctif ? Si oui, lequel ?).

Collecte des mod` eles du

navire 1-1

F´ ed´ eration de ces mod` eles

1-2 Sp´ ecification

des propri´ et´ es du navire 1-3

Identification des failles et correctifs

2-1 Calcul

de risque et d’impact

2-2 D´ ecision

(choix correctif et planification) 2-3

D´ eploiement et validation 2-4

Figure 1 – Processus d’analyse du syst` eme (1) et de gestion des correctifs (2)

2 Le processus de gestion des correctifs de s´ ecurit´ e

La gestion des correctifs a ´ et´ e trait´ ee par plusieurs articles [5, 7, 12, 11]. Nous pouvons proposer, en nous inspirant de ces travaux et notamment de [7], les grandes ´ etapes d’un processus de gestion des correctifs adapt´ e ` a notre contexte (cf. figure 1). Nous ajoutons toutefois une ´ etape suppl´ ementaire, moins trait´ ee par les publications du domaine mais qui nous semble cruciale : le calcul de l’impact des op´ erations de d´ eploiement d’un correctif. En effet, ces op´ erations peuvent suspendre temporairement certains processus critiques, ce qui peut ˆ etre intol´ erable. Par exemple, la d´ esactivation d’un automate de contrˆ ole pendant un temps donn´ e peut interrompre le cours de certaines missions.

Le processus propos´ e commence par la phase d’identification des vuln´ erabilit´ es (2-1). Cette

´

etape a pour but d’agr´ eger les informations d’int´ erˆ et ayant trait aux failles des diff´ erents

´

el´ ements du syst` eme. Or, de tr` es nombreux sous-syst` emes cohabitent au sein du navire : cer- tains sont g´ en´ eriques et largement utilis´ es dans d’autres contextes, alors que d’autres sont tr` es sp´ ecifiques et ont ´ et´ e con¸ cus ad hoc. Cette tˆ ache s’appuie donc sur l’analyse de sources diverses comme par exemple des flux d’information publics des producteurs de COTS, des informations plus confidentielles pour les composants

sur-mesure

ou des vuln´ erabilit´ es non publi´ ees.

De la mˆ eme mani` ere, la phase d’identification des correctifs (2-1) s’attache ` a passer en revue les contre-mesures permettant de combler chaque faille. Cette ´ etape se rapproche de la pr´ ec´ edente car des contre-mesures peuvent ˆ etre publi´ ees, notamment en ce qui concerne les vuln´ erabilit´ es affectant les composants g´ en´ eriques. Parfois, aucune contre-mesure n’est connue.

Il s’agit donc d’agr´ eger les informations disponibles, mais aussi de concevoir des correctifs sp´ ecifiques (qui peuvent ˆ etre des mesures temporaires simples, comme l’isolement physique d’un composant du syst` eme, sa mise hors-service ou son remplacement).

A partir des informations rendues disponibles par les deux premi` ` eres ´ etapes du processus, un ensemble de calculs d’impact et de risque vont pouvoir ˆ etre men´ es (2-2). Les r´ esultats de ces calculs guideront les choix des correctifs ` a appliquer, en permettant la comparaison des retomb´ ees des diff´ erents correctifs sur la capacit´ e du syst` eme ` a r´ ealiser ses missions (2-3).

Trois analyses distinctes sont propos´ ees :

1. l’analyse du risque associ´ e aux vuln´ erabilit´ es, recouvrant le calcul d’impact de chaque ex-

ploitation possible des vuln´ erabilit´ es et l’estimation de leur probabilit´ e ;

2. le calcul d’impact des correctifs, ayant pour vis´ ee de d´ eterminer l’impact de chaque correctif envisag´ e, une fois d´ eploy´ e au sein du syst` eme ;

3. le calcul d’impact du d´ eploiement des correctifs : il s’agit ici de d´ eterminer l’impact de l’op´ eration de d´ eploiement de chaque correctif sur le syst` eme.

Connaˆıtre ces impacts se r´ ev` ele donc essentiel ¹ . Les cinq tˆ aches de ce processus sont n´ ecessaires

`

a la phase de d´ ecision, o` u le choix des correctifs et la planification de leur d´ eploiement sont arrˆ et´ es. p Trois probl´ ematiques principales se r´ ev` elent ` a l’analyse de ce processus : la collecte d’informations et leur analyse sont le pr´ ealable indispensable au processus ; les calculs d’impact et de risque associ´ es aux vuln´ erabilit´ es et correctifs sont au cœur de nos travaux ; enfin, la repr´ esentation du syst` eme est une probl´ ematique transverse et critique, n´ ecessaire ` a chaque

´

etape du processus de gestion de correctifs.

Nous avons choisi pour le moment de nous concentrer sur les calculs d’impact et de risque et la repr´ esentation du syst` eme.

3 F´ ed´ eration de mod` eles et calcul d’impact

Une repr´ esentation suffisamment compl` ete du syst` eme est n´ ecessaire. Sa taille en fait toute- fois un probl` eme non trivial : comment mod´ eliser un syst` eme de cette ampleur ? Notre d´ emarche doit s’appuyer sur l’acquisition de connaissances aussi compl` etes que possible des diff´ erentes facettes du syst` eme ´ etudi´ e. En effet, s’il est certain qu’une unique repr´ esentation ne peut pas rendre compte de la complexit´ e d’un syst` eme naval, de nombreux mod` eles peuvent ˆ etre ´ etablis et utilis´ es, chacun repr´ esentant un aspect diff´ erent. Par exemple, une d´ ecomposition syst´ emique ou la description d’un processus ne contiendra pas les mˆ emes informations qu’un plan du bˆ atiment ou qu’un r` eglement int´ erieur, mais viendra les compl´ eter. Ces mod` eles peuvent ˆ etre obtenus par l’´ etude de syst` emes existants, en s’appuyant sur l’expertise des acteurs impliqu´ es dans la conception, la r´ ealisation et l’op´ eration des syst` emes navals. Mais, du fait de la forte diversit´ e de navires, constructeurs, cadres d’emploi, missions, ..., la nature de ces mod` eles est variable d’un syst` eme ` a l’autre. Un second probl` eme se pose alors : comment ´ etablir une m´ ethode de repr´ esentation adaptable ` a des syst` emes aussi divers ?

Pour r´ epondre ` a ces deux probl´ ematiques, notre angle d’approche est la f´ ed´ eration de mod` eles [8]. La f´ ed´ eration de mod` eles lie les diff´ erentes abstractions de l’objet mod´ elis´ e, et s’adapte ` a chaque syst` eme : elle ´ etablit un m´ eta-mod` ele ²

sur-mesure

de chaque bˆ atiment en fonction des mod` eles disponibles et n’a donc pas pour but d’analyser tous les navires suivant un ensemble pr´ ed´ efini de mod` eles.

Cette mod´ elisation sert notamment la tˆ ache centrale du processus de gestion des correctifs : les calculs de risque et d’impact. Une vuln´ erabilit´ e ou un correctif affectant un (ou plusieurs) composant(s) du syst` eme, nous souhaitons d´ eduire de notre f´ ed´ eration de mod` eles la d´ ependance composants / missions ³ . [13] propose une m´ ethode d’estimation de l’impact d’une attaque sur une mission, en s’appuyant entre autres sur un graphe de d´ ependance repr´ esentant les

1. Dans l’´ etat actuel de nos recherches, nous nous concentrons sur les impacts sur la sˆ uret´ e de fonctionnement du syst` eme. Nous verrons en partie 4 comment ils peuvent ˆ etre calcul´ es ` a partir des mod` eles.

2. M´ eta-mod` ele signifie ici ”ensemble des mod` eles f´ ed´ er´ es”. Ce m´ eta-mod` ele n’est pas calcul´ e : il ne s’agit pas de fusionner les mod` eles disponibles en une seule repr´ esentation. Chacun des mod` eles f´ ed´ er´ es reste exprim´ e dans son formalisme d’origine.

3. Nous pouvons d´ eduire de la f´ ed´ eration de mod` eles d’autres informations qui peuvent servir au calcul

d’impact. La d´ ependance mission / composant est le seul aspect ´ evoqu´ e dans cet article.

liens mission / tˆ ache ⁴ / composant. [4, 3, 6] analysent des navires militaires suivant le m´ eta- mod` ele Abstraction Hierarchy de Jens Rasmussen, servant ` a lier les missions du syst` eme ` a ses composants ` a travers cinq niveaux d’abstraction croissante (composants, trois niveaux de fonctions et de processus, missions). La f´ ed´ eration des mod` eles disponibles peut donc aboutir ` a ce type d’abstraction qui permet d’exprimer les d´ ependances n´ ecessaires aux calculs de risque et d’impact. Elle permet aussi de sp´ ecifier les propri´ et´ es de sˆ uret´ e de fonctionnement du syst` eme, qui sont n´ ecessaires au type de mesure d’impact pr´ esent´ e dans la partie suivante.

4 Calcul d’impact et automates temporis´ es

Pour exprimer un impact en termes de sˆ uret´ e de fonctionnement, nous devons mod´ eliser le comportement du syst` eme et ses missions, ce qui peut ˆ etre fait grˆ ace aux automates tem- poris´ es[2]. En effet, une mission peut ˆ etre vue comme un enchaˆınement d’´ etats ; par exemple, pour un navire de mesures oc´ eanographiques : navire ` a quai → ₁ en transit vers zone → ₂ cam- pagne de mesures → ₃ en transit vers port → ₄ mission achev´ ee. De mˆ eme, le fonctionnement des sous-syst` emes composant le bˆ atiment peut ˆ etre mod´ elis´ e par un ensemble d’automates. Ces automates, qui sont eux-mˆ emes des mod` eles comportementaux du syst` eme, sont constuits ` a partir de la f´ ed´ eration de mod` eles.

La d´ ependance composants / missions peut ˆ etre illustr´ ee grˆ ace ` a cette repr´ esentation. Par exemple, nous pouvons construire nos automates pour qu’ils v´ erifient la propri´ et´ e suivante : la transition → 1 ne peut ˆ etre tir´ ee que si l’automate mod´ elisant le comportement de la propulsion du bˆ atiment atteint un ensemble d’´ etats indiquant que ce sous-syst` eme est : en fonctionnement, en mesure de recevoir les consignes des op´ erateurs, et en mesure d’ex´ ecuter ces consignes.

Notre objectif est donc de mod´ eliser le syst` eme sous la forme de deux ensembles d’auto- mates : les automates syst` eme, repr´ esentant le comportement des composants du navire, et les automates mission, repr´ esentant le d´ eroulement des missions. La d´ ependance entre ces deux ensembles est exprim´ ee par le lien entre les automates syst` eme et les automates mission. Nous ajoutons ´ egalement une temporisation ` a nos automates, pour mod´ eliser les d´ elais de fonction- nement des sous-syst` emes.

Dans son ´ etat de fonctionnement nominal, le syst` eme permet l’ex´ ecution des missions. Cela implique, au niveau des traces d’ex´ ecution des automates, la v´ erification de certaines propri´ et´ es : par exemple, l’automate syst` eme A peut atteindre l’´ etat s en un temps t, ou l’automate mission M peut atteindre l’´ etat mission achev´ ee. Un correctif, ou une attaque issue de l’exploitation d’une vuln´ erabilit´ e, peut mener ` a une modification du comportement du syst` eme. Nous pou- vons donc repr´ esenter cette transformation par une

mutation

des automates syst` eme. Cette mutation peut ˆ etre un ensemble d’ajouts/suppressions d’´ etats et transitions, ou la modification des horloges (pour repr´ esenter une modification des temps de fonctionnement d’un composant donn´ e). Nous v´ erifions ensuite ces propri´ et´ es sur les traces d’ex´ ecution des automates

mut´ es

. Une mesure d’impact peut ˆ etre d´ eduite de cette v´ erification : par exemple, une mesure

sim- pliste

serait de consid´ erer le nombre de propri´ et´ es qui ne sont plus satisfaites.

Conclusion

La gestion des correctifs de s´ ecurit´ e est un enjeu majeur des navires modernes. Ces navires sont des syst` emes complexes, constitu´ es de composants de nature diverse. De tels composants

4. Une mission est vue comme un ensemble de tˆ aches.

peuvent ˆ etre affect´ es par des vuln´ erabilit´ es, qui sont temp´ er´ ees par des correctifs. Or, les cor- rectifs comme les vuln´ erabilit´ es ont des impacts sur les missions du navire : un processus de gestion de correctifs doit permettre de comparer leurs cons´ equences, pour faire le choix qui aura un impact minimal sur les missions du bˆ atiment. Ce processus s’appuie sur une repr´ esentation – aussi compl` ete que possible – du syst` eme, obtenue par f´ ed´ eration de mod` eles, et sur des cal- culs de risque et d’impact. L’analyse de traces d’ex´ ecution d’automates temporis´ es nous permet d’obtenir une mesure d’impacts sur la sˆ uret´ e de fonctionnement du syst` eme naval. Ce ne sont toutefois pas les seuls impacts possibles li´ es ` a une vuln´ erabilit´ e ou ` a un correctif : la suite de nos travaux s’attachera ` a envisager des modes de calcul int´ egrant ces autres aspects.

R´ ef´ erences

[1] A. Abou El Kalam. Security of critical infrastructures and Networks. Habilitation ` a diriger les recherches, Institut National Polytechnique de Toulouse - INPT, December 2009.

[2] G. Behrmann, K. G. Larsen, O. Moller, A. David, P. Pettersson, and W. Yi. Uppaal - present and future. In Decision and Control, 2001. Proceedings of the 40th IEEE Conference on, volume 3, pages 2881–2886 vol.3, 2001.

[3] A. M. Bisantz, C. M. Burns, and E. Roth. Validating methods in cognitive engineering: A com- parison of two work domain models. Proceedings of the Human Factors and Ergonomics Society Annual Meeting, 46(3):521–525, 2002.

[4] A. M. Bisantz, E. Roth, B. Brickman, L. L. Gosbee, L. Hettinger, and J. McKinney. Integrating cognitive analyses into a large scale system design process. Proceedings of the Human Factors and Ergonomics Society Annual Meeting, 45(4):434–438, 2001.

[5] B. Brykczynski and R. A. Small. Reducing internet-based intrusions: Effective security patch management. IEEE Software, 20(1):50–57, Janvier 2003.

[6] C. M. Burns, D. J. Bryant, and B. A. Chalmers. Boundary, purpose, and values in work-domain models: Models of naval command and control. IEEE Transactions on Systems, Man, and Cyber- netics - Part A: Systems and Humans, 35(5):603–616, Sept 2005.

[7] C.-W. Chang, D.-R. Tsai, and J.-M. Tsai. A cross-site patch management model and architecture design for large scale heterogeneous environment. In Security Technology, 2005. CCST ’05. 39th Annual 2005 International Carnahan Conference on, pages 41–46, Octobre 2005.

[8] C. Guychard, S. Guerin, A. Koudri, F. Dagnat, and A. Beugnard. Conceptual interoperability through Models Federation. In Semantic Information Federation Community Workshop, 2013.

[9] L. M. Jaworski. Tandem threat scenarios : a risk assessment approach. In 16th National Computer Security Conference : Proceedings, pages 155–164, 1993.

[10] Department of Defense. Department of Defense Handbook : System Security Engineering – Program Management Requirements, MIL-HDBK-1785. 1995.

[11] US Department of Homeland Security / National Cyber Security Division / Control Systems Security Program. Recommended Practice for Patch Management of Control Systems. D´ ecembre 2008.

[12] J.-T. Seo, D.-S. Choi, E.-K. Park, T.-S. Shon, and J. Moon. Patch management system for multi- platform environment. In Parallel and Distributed Computing: Applications and Technologies:

5th International Conference, PDCAT 2004, Singapore, December 8-10, 2004. Proceedings, pages 654–661, Berlin, Heidelberg, 2005. Springer Berlin Heidelberg.

[13] X. Sun, A. Singhal, and P. Liu. Who touched my mission: Towards probabilistic mission impact

assessment. In Proceedings of the 2015 Workshop on Automated Decision Making for Active Cyber

Defense, SafeConfig ’15, pages 21–26, New York, NY, USA, 2015. ACM.