Comment mesurer la scurit informatique ?

Yves Deswarte Directeur de recherche au CNRS LAAS, Laboratoire dAnalyse et dArchitecture des Systmes, CNRS

Introduction
La scurit informatique, ou plutt la scurit des systmes dinformation, est

gnralement dfinie comme la combinaison de trois proprits [ITSEC 91] : la confidentialit, qui empche la divulgation dinformation des personnes non autorises la connatre, lintgrit, qui empche laltration dinformation, et la disponibilit, qui assure que les personnes autorises peuvent accder linformation lorsquelles en ont besoin. Notons que ces dfinitions qui se rapportent linformation pourraient tout aussi bien se rapporter au service fourni aux utilisateurs, comme dans les dfinitions lies la sret de fonctionnement [Laprie 96]. Ainsi la disponibilit peut se dfinir de faon quivalente comme la capacit du systme informatique tre prt dlivrer le service. Les travaux en sret de fonctionnement ont conduit dvelopper des techniques pour estimer ou mesurer la disponibilit, soit de faon statistique (par exemple, on dira quun systme est disponible 99% du temps), soit de faon probabiliste (probabilit qu un instant donn le systme soit prt dlivrer le service). De telles mesures quantitatives ne sont pas aussi faciles dfinir pour la confidentialit et lintgrit. La premire difficult vient de la nature des phnomnes considrer : la sret de fonctionnement sintresse principalement (mais pas exclusivement) des causes accidentelles (quon appelle fautes accidentelles), alors que la scurit des systmes dinformation se proccupe principalement (mais pas exclusivement non plus) des malveillances (ou fautes dlibres, cres dans lintention de nuire). Dans le cas de fautes accidentelles, il est assez naturel de considrer que les vnements sont indpendants et plus ou moins uniformment distribus dans le temps, ce qui se reprsente facilement par des processus stochastiques. Dans le cas des malveillances, il est plus difficile de considrer les attaques comme des phnomnes alatoires, puisquelles rsultent directement de la volont

de quelquun qui pourra choisir un moment propice, lancer plusieurs attaques en mme temps ou mme coordonner ses actions avec celles de complices. Une seconde difficult tient la dtection des atteintes la confidentialit, qui peuvent ne pas laisser de trace (les donnes divulgues ne changeant pas de valeur). Il en est souvent de mme pour les attaques russies contre lintgrit, o gnralement lattaquant fait en sorte que la fausse information quil introduit apparaisse authentique. Il est donc difficile didentifier des tats de dfaillance vis--vis de la confidentialit et de lintgrit, et il est encore plus difficile didentifier les instants de dfaillance correspondants. Ces difficults font quil nest pas possible dappliquer directement la scurit des systmes dinformation les mthodes dvaluation de la sret de fonctionnement. Trois approches ont t proposes pour valuer la scurit des systmes dinformation : lanalyse de risques, les critres dvaluation et lvaluation quantitative de la scurit oprationnelle. Ces trois approches seront dveloppes dans les prochaines sections.

Analyse de risques
On peut appliquer aux systmes dinformation des analyses de risques analogues

celles utilises dans le domaine des risques vis--vis de catastrophes naturelles ou industrielles. Il existe plusieurs mthodes globales dvaluation de la scurit dune installation informatique bases sur lanalyse de risques (Risk Assessment), et prenant en compte aussi bien des risques lis des accidents ou des phnomnes naturels (incendie, inondation, bogue de logiciel ou erreur de saisie, etc.) que ceux lis la malveillance (terrorisme, fraude, extorsion de fonds, etc.). En France, les mthodes les plus utilises ont t MARION [Lamre 1985], dveloppe et soutenue par le CLUSIF (Club de la scurit informatique franais) et lAPSAD (Assemble Plnire des Socits dAssurances Dommages), et MELISA dveloppe pour le compte de la Dlgation Gnrale pour lArmement et commercialise par la socit CF6, jusqu son absorption par la socit Telindus. Plus rcemment, le CLUSIF a dvelopp la mthode MEHARI (Mthode Harmonise dAnalyse de RIsques). On peut galement citer la mthode CRAMM, couramment utilise en Grande-Bretagne, et le projet europen CORAS1. Pour ces mthodes, les entraves la scurit des systmes informatiques sont gnralement classes en menaces, vulnrabilits et risques :

<http://www.nr.no/coras/>

Les menaces sont caractrises par les possibilits et les probabilits dattaque (au sens large) contre la scurit. Elles sont dfinies par la source (interne au systme ou externe), par la motivation des attaquants, par le processus dattaque, par la cible et par le rsultat (consquences de la russite dune attaque). Les vulnrabilits sont les fautes de conception ou de configuration, intentionnelles ou accidentelles, qui favorisent la ralisation dune menace ou la russite dune attaque. Les risques sont le rsultat de la combinaison des menaces et des vulnrabilits. Les risques doivent tre valus, soit pour obtenir le meilleur compromis possible entre scurit et cot pour un systme donn, soit simplement pour calculer le montant des primes dassurance pour couvrir ces risques.

Lidentification des menaces conduit les classer en menaces physiques (incendie, dgts des eaux, dfaillances dquipements, etc.), ou logicielles (bogues, spcificits de certaines versions qui pourront conduire des incapacits dvolutions, etc.), maladresses de certains utilisateurs, oprateurs ou personnels de maintenance (erreurs de saisie, mauvaises configurations, etc.), et malveillances (terrorisme, chantage, extorsion de fonds, fraude, piratage de donnes ou de logiciels, etc.). Les malveillances peuvent tre dorigine externe (par des individus non autoriss utiliser le systme dinformation) ou interne (par des utilisateurs autoriss, voire des concepteurs ou des administrateurs du systme dinformation). Les consquences des incidents peuvent tre des dgts en terme de matriel ou de donnes, ou des cots lis larrt ou la dgradation de lexploitation, ou encore des atteintes limage de marque de lentreprise. Les vulnrabilits sont des fautes de conception au sens large, cest--dire quelles peuvent tre introduites durant le dveloppement du systme, son installation, son exploitation ou sa maintenance. Ce sont des fautes dormantes dans le sens quelles ne produisent pas derreurs par elles-mmes, mais elles peuvent tre exploites par des fautes externes accidentelles ou des attaques. On peut gnralement identifier des vulnrabilits dans la gestion des incidents (plans de secours, organisation des sauvegardes, etc.), dans la scurit physique (contrle des accs aux locaux, matriel de lutte contre lincendie, etc.), ou dans la scurit logique (dfinition de la politique de scurit, mcanismes didentification et dauthentification, gestion des droits daccs, journalisation des vnements de scurit, protection des communications, etc.). Pour obtenir des mesures quantitatives, il convient alors destimer la frquence de ralisation des menaces (par exemple, une inondation est dite centenaire si elle survient en

moyenne tous les cent ans) susceptibles dexploiter les vulnrabilits identifies (par exemple, le fait quune digue soit tudie pour rsister des inondations dont la frquence est suprieure une par sicle), ainsi que les cots des consquences des incidents correspondants. Des mthodes de calcul, bases sur les principes des esprances mathmatiques permettent dvaluer le montant des primes dassurances contre ces risques, ou de justifier ou non le cot des parades (rduction des vulnrabilits ou protections pour rduire les consquences des attaques). Nanmoins ces mesures quantitatives restent sujettes caution, car il est gnralement impossible destimer les paramtres avec prcision (absence de statistiques plausibles) et de garantir la compltude des menaces et des vulnrabilits. La qualit de lanalyse de risques repose donc en grande partie sur la comptence de ceux qui la mnent. Cest souvent aussi une dmarche lourde et coteuse. Enfin, elle ne reprsente quun clich un moment donn, et elle devrait tre refaite en fonction de lvolution du systme et de son environnement. En rsum, lanalyse de risques est une dmarche utile, mais plus pour ses effets collatraux (sensibilisation et motivation des personnels et de la hirarchie aux problmes de scurit) que comme instrument de mesure de la scurit.

Critres d!valuation
Des critres dvaluation qualitative ont t dvelopps pour comparer la capacit de

divers systmes informatiques faire face des malveillances. Les premiers critres ont t dfinis par la dfense amricaine (DoD) dans ce qui est couramment appel le Livre Orange ou TCSEC (Trusted Computer System Evaluation Criteria) [TCSEC 1985], ainsi que dans les livres de diverses couleurs qui laccompagnent, comme le Livre Rouge ou TNI (Trusted Network Interpretation of the TCSEC) [TNI 1987]. Ces critres, bass la fois sur des listes de fonctions de scurit remplir et sur les techniques employes pour la validation, conduisent classer les systmes en 7 catgories (dans un ordre croissant de scurit : D, C1, C2, B1, B2, B3, A1). Les critres portent la fois sur la doctrine de scurit (par exemple, un contrle daccs discrtionnaire ou obligatoire), sur la responsabilit (par exemple, la journalisation des oprations lies la scurit), lassurance (cest--dire les mthodes de validation employes) et sur la documentation. Ces critres visaient satisfaire dabord les besoins du DoD, cest--dire quils privilgient la confidentialit plutt que lintgrit qui est le souci principal des systmes dits commerciaux. Ainsi, pour les systme de niveau B1 ou suprieur, un modle de scurit multi-niveau est impos, le modle de Bell-LaPadula. Dans ce modle, une classification est

attache chaque information, et une habilitation est assigne chaque utilisateur. Chaque classification et chaque habilitation est identifie par un niveau (par exemple, non-classifi, diffusion restreinte, confidentiel, secret, trs secret) et un compartiment qui est un ensemble de catgories (par exemple, nuclaire, cryptologie, tlcommunications, etc.). Les diffrentes classifications et habilitations sont donc ordonnes partiellement dans un treillis, cest--dire quune classification ou habilitation A domine une autre classification ou habilitation B si et seulement si la fois le niveau de A est suprieur ou gal celui de B et si le compartiment de B est inclus dans celui de A. Pour viter toute fuite dinformation, dans ce modle, deux rgles sont imposes : Rgle simple : un sujet (utilisateur, processus, ) ne peut lire un objet (information) que si son habilitation domine la classification de lobjet. Rgle toile : un sujet ne peut la fois lire un objet O1 et crire un objet O2 que si la classification dO2 domine celle dO1. Par la suite, des critres harmoniss europens ont t proposs [ITSEC 1991], visant surmonter les limites apparues dans lutilisation du Livre Orange : valuation de systmes plutt que de produits, prise en compte aussi bien de lintgrit et de la disponibilit que de la confidentialit, sparation entre les aspects fonctionnels et les aspects de validation. titre dexemple, 10 classes de fonctionnalits sont prdfinies, dont les 5 premires reprennent les fonctionnalits des catgories C1 B3 du Livre Orange (les fonctionnalits A1 sont identiques celles de B3, et pour la catgorie D, rien nest exig puisquelle correspond aux systmes nayant pas obtenu le niveau dvaluation vis). 5 autres classes de fonctionnalits sont dfinies pour les systmes haute intgrit, haute disponibilit, haute intgrit pour les transmissions, haute confidentialit pour les transmissions et enfin pour les rseaux hautes intgrit et confidentialit. Mais dautres combinaisons de fonctionnalits peuvent tre dfinies si le besoin sen fait sentir pour un systme ou une application particuliers. Dautre part, sont dfinis galement 6 niveaux dassurance de conformit, cest--dire de validation, nots de E1 E6. Des critres dassurance defficacit sont galement dfinis pour valuer la pertinence et la cohsion des fonctionnalits, la rsistance des mcanismes, la vulnrabilit de la construction ainsi que des critres lis lexploitation : facilit demploi et vulnrabilit en exploitation. Un manuel dvaluation des ITSEC est paru sous une forme provisoire [ITSEM 1992]. Plus rcemment, une collaboration internationale (mene par le NIST et la NSA aux Etats-Unis, le Canada, la France, la Grande-Bretagne et lAllemagne) a permis de dfinir des critres communs, qui forment la norme ISO/IEC 15408. Fortement inspirs des ITSEC dont

ils reprennent la sparation entre classes de fonctionnalits et niveaux dassurance, ils se caractrisent par la dfinition de profils de protection spcifiques pour des types de produits ou dapplications (par exemple, les pare-feux, les cartes puces, etc.). Un profil de protection est dfini par des fonctionnalits, un niveau dassurance de conformit et des critres dassurance defficacit adapts au type de produit ou dapplication. Cette notion de profil de protection doit permettre de comparer plus facilement diffrents produits valus, mais aussi de rduire les cots dune valuation. Globalement, les critres dvaluation sont un excellent guide pour le dveloppement de systmes haute scurit, et ils peuvent justifier des arguments marketing par la comparaison quils offrent entre diffrents produits. Cependant, une telle valuation est coteuse, surtout pour des niveaux dassurance viss levs, et elle nest valable que pour une version spcifique du produit ou du systme. Toute volution doit conduire une nouvelle valuation. Par ailleurs, comme pour lanalyse de risques, une valuation par les critres communs ne donnent quune vision statique de la scurit : on value comment le systme a t conu plutt que comment il est utilis au jour le jour. Enfin, une telle valuation tant essentiellement qualitative, les critres dvaluation ne peuvent pas tre considrs comme un instrument de mesure prcis de la scurit.

valuation quantitative de la scurit oprationnelle

Les sections prcdentes ont montr que les mthodes classiques dvaluation de la

scurit par analyse de risques ou par critres dvaluation se prtent mal des exigences pratiques que lon retrouve dans bon nombre de systmes actuels : modification frquente de la politique de scurit, volution rapide des configurations et des applications, ouverture sur des systmes ou des utilisateurs inconnus, etc. Dans de tels systmes, il convient surtout dobtenir un bon compromis entre scurit et facilit dutilisation, de partage de linformation et de coopration entre les utilisateurs. Ceci nous a conduit proposer une nouvelle approche pour une valuation quantitative de la scurit. Jusqu rcemment, lvaluation quantitative de la scurit tait limite quelques aspects particuliers, comme lvaluation de la bande passante des canaux cachs (exige partir du niveau B2 du Livre Orange) ou lapplication de la thorie de linformation lvaluation de lefficacit des mcanismes cryptographiques ou de la fragmentation des traitements par tranches de bits [Trouessin 1991]. Pourtant une valuation quantitative prsente de nombreux avantages :

Elle permet de surveiller les volutions de la scurit en fonction des modifications de configuration et dusage. Elle permet didentifier quelles modifications pourraient avoir le meilleur impact sur la scurit. Elle permet de ngocier avec les utilisateurs un meilleur compromis scurit/facilit dutilisation.

La mesure quantitative de la scurit que nous proposons reprsente la robustesse du systme, cest--dire sa capacit rsister de possibles attaques. La robustesse est une caractristique du systme un moment donn, elle est indpendante de la probabilit que le systme soit attaqu. Ceci ncessiterait, en effet, une modlisation de la population dattaquants et de leur stratgie de choix dune cible, ce qui nous semble lheure actuelle irralisable. Au contraire, notre tude ne sintresse quau systme informatique et ses protections, mises en uvre effectivement par les utilisateurs, toutes choses pour lesquelles on peut disposer de donnes tangibles. Cette approche est analogue lanalyse de couverture dans les systmes tolrant les fautes, o plutt que destimer les taux de dfaillance des composants, on value leurs possibles effets sur le fonctionnement global du systme.

4.1

Graphe des privilges

Notre dmarche repose sur une modlisation du systme informatique sous forme dun

graphe des privilges, modle abstrait que nous avons conu en 1994 [Dacier 1994]. Dans ce graphe, les nuds reprsentent des ensembles de droits (ou privilges), et les arcs des transferts de privilges : il existe un arc (tiquet M) allant de X Y sil est possible, ayant les privilges reprsents par le nud X dacqurir les privilges du nud Y, en utilisant la mthode M. Cette mthode peut tre un transfert licite de privilge (lutilisateur Y fait confiance X), ou un transfert implicite (Y est un sous-ensemble de X), ou encore une attaque lmentaire. Un poids peut tre affect aux diffrentes mthodes, selon la difficult pour un possible attaquant dexploiter la mthode ou selon le temps ncessaire pour raliser lattaque. Ce graphe peut tre analys pour identifier les possibilits de mettre en dfaut la politique de scurit du systme. En effet, partir de la politique de scurit, il est possible didentifier des attaquants potentiels (intrus externes, ou utilisateurs pouvant tenter dtendre leurs privilges ou dabuser de leurs privilges), et des cibles potentielles (ensembles de droits daccs des informations sensibles). La politique de scurit peut tre mise en dfaut sil existe (au moins) un chemin depuis lensemble des privilges dun attaquant potentiel jusqu une cible.

C 3 P1 1 insider 2 7 B 5 6 Adm 4 F
Figure 1 : exemple de graphe de privilges
Pour un arc X!Y : 1) X peut deviner le mot de passe dY 2) X peut installer un cheval de Troie pour Y 3) X peut exploiter une faille du mailer dY 4) Y est un sous-ensemble dX 5) Y utilise un programme quX peut modifier 6) X peut modifier un programme "s-uid" dY 7) X est dans le .rhosts dY

La figure 1 donne un exemple de graphe de privilges. Dans cet exemple, le nud insider reprsente les privilges minimaux de nimporte quel utilisateur autoris du systme. Les nuds B , C et F reprsentent les privilges de trois utilisateurs particuliers, alors que Adm reprsente les privilges du groupe des administrateurs du systme (dont F est membre) et P1 est un utilisateur virtuel correspondant un projet. Dans cet exemple, les mthodes 1, 2 et 3 correspondent des ngligences des utilisateurs P1, F et C ; alors que les mthodes 4 7 correspondent des transferts de privilges volontaires (justifis par la confiance des utilisateurs entre eux). Le graphe des privilges peut tre gnr automatiquement, par exemple en analysant la configuration dun systme Unix (ou dun ensemble de machines Unix interconnectes) pour en dterminer les vulnrabilits (en fonction dune liste de mthodes dattaque connues). De mme, partir dune description formelle de la politique de scurit, il est possible didentifier les nuds correspondants des attaquants potentiels (dans lexemple, le nud insider ), et ceux correspondant des cibles potentielles (dans lexemple, le nud C ). Les arcs peuvent tre affects dun poids reprsentant la difficult pour un attaquant potentiel possdant les privilges du nud origine de larc dobtenir les privilges du nud destination en utilisant la mthode M.

4.2

Calcul des mesures

partir du graphe pondr, on peut valuer la difficult pour chaque attaquant

potentiel datteindre chaque cible potentielle. Pour ce faire, le graphe des privilges est transform en une chane de Markov correspondant aux processus dattaque possibles. Les poids donns aux arcs en fonction des mthodes dattaque et du type de cible deviennent des

taux de succs correspondant leffort et au temps que lattaquant doit dpenser pour russir cette attaque : le taux sera dautant plus petit que leffort ncessaire la russite sera grand [Dacier 1996]. Il est alors possible de calculer des mesures significatives (effort moyen et temps moyen pour quun attaquant atteigne une cible) pour tous les couples (attaquant, cible) et ainsi destimer sous forme quantitative la scurit du systme. Nous avons dvelopp SOPE (outil dvaluation de la Scurit OPrationnelle), prototype de suite logicielle, qui rassemble et enchane un ensemble doutils permettant dautomatiser toutes ces phases : dfinition interactive de la politique de scurit, cration du graphe de privilges par analyse du systme de fichiers Unix, gnration des chanes de Markov et calcul des mesures. Ce prototype a t utilis pour valuer la scurit du rseau du LAAS pendant plusieurs annes, principalement dans le but de valider la pertinence des diffrentes mesures quil est possible dobtenir [Ortalo 1999a]. Avec SOPE, il est ainsi possible de calculer automatiquement, par exemple une fois par jour, des mesures pertinentes de la scurit dun systme informatique et ainsi de suivre au jour le jour lvolution de ces mesures, en fonction des modifications de configuration ou de la faon dont les utilisateurs mettent en uvre les mcanismes de protection. En cas dvolution dfavorable des mesures, il est possible didentifier automatiquement les modifications qui ont provoqu lvolution, ce qui donne des arguments aux administrateurs systmes pour discuter avec les utilisateurs et tenter de les convaincre de corriger leur faon de travailler.

Conclusion
La mthode dvaluation quantitative de la scurit oprationnelle a aussi t

applique avec succs des systmes dinformation prenant en compte non seulement le systme informatique mais aussi lorganisation de ses utilisateurs, leurs relations hirarchiques et leur confiance mutuelle. Ceci a conduit dvelopper une mthode de description des politiques de scurit adaptes aux besoins des entreprises, en liaison avec une valuation quantitative de la scurit des systmes dinformation correspondants. Cette mthode a t valide par une exprimentation sur une agence bancaire, organisation relle de taille significative [Ortalo 1999b]. Nanmoins ce type dapplication nest pas aussi facilement automatisable que pour un systme informatique.

Rfrences

[Dacier 1994] Marc Dacier et Yves Deswarte, "Privilege graph: an extension to the Typed Access Matrix model", European Symposium on Research in Computer Security (ESORICS 94), Brighton (UK), novembre 1994, Lecture Notes in Computer Science 875: Computer Security, ISBN 3-540-58618-0, 1994, Springer-Verlag, pp. 319-334. [Dacier 1996] Marc Dacier, Yves Deswarte, Mohamed Kaniche, "Models and tools for quantitative assessment of operational security", 12th International Information Security Conference (IFIP/Sec96), Samos (Grce), 21-24 mai 1996, dans Information Systems Security, Chapman & Hall, Ed. S.K. Katsikas and D. Gritzalis, 1996, pp.177-186. [ITSEC 1991] Critres dvaluation de la scurit des systmes informatiques (ITSEC), Office des publications officielles des communauts europennes, L-2985 Luxembourg, ISBN 92-826-3005-6 [Lamre 1985] J.M. Lamre, La scurit informatique : approche mthodologique, Dunod Informatique, ISBN 2-04-016503-7 (1985). [Laprie 1996] J.-C. Laprie et al., Guide de la sret de fonctionnement, Cpadus ditions, 1996, 370p., ISBN 2.85428.382.1, seconde dition. [Ortalo 1999a] Rodolphe Ortalo, Yves Deswarte et Mohamed Kaniche, "Experimenting with Quantitative Evaluation Tools for Monitoring Operational Security", IEEE Transactions on Software Engineering, Vol.25, N5, pp.633-650, septembre/octobre 1999. [Ortalo 1999b] Rodolphe Ortalo et Yves Deswarte, "Quantitative Evaluation of Information System Security Experimented in a Bank Organization", 2nd International Conference on Information System Security in the Financial Sector, Bratislava (Slovaquie), 24-25 mars 1999, pp.38-47. [TCSEC 85] TCSEC, Trusted Computer System Evaluation Criteria, DoD 5200.28-STD, Department of Defense, USA, December 1985. [TNI 87] TNI, Trusted Network Interpretation of the Trusted Computer System Evaluation Criteria, NCSC-TG-005, National Computer Security Center, 31 July 1987. [Trouessin 1991] Gilles Trouessin, "Quantitative evaluation of confidentiality by entropy calculation", 3 IEEE Computer 6Security Foundation Workshop IV, Franconia (USA), 18-20 juin 1991, pp.12-21. 7 5 1 2 4