une architecture tolérante aux intrusions une architecture ... · deba, sarah khirani, malika...

Thse

Prpare au

Laboratoire dAnalyse et dArchitecture des Systmes du CNRS

En vue de lobtention du

Doctorat de lInstitut National des Sciences Appliques de Toulouse

Spcialit : Systmes informatiques

Par

Ayda Saidane

Ingnieur ENSI de Tunis

Conception et ralisation dune architecture tolrant lesintrusions pour des serveurs Internet

Soutenance le prvue le 28 janvier 2005 devant le jury :

Prsident Rapporteurs

Examinateurs

Jean Jacques Herv Ludovic Alfonso Yves Vincent

QuisquaterDebarMValdesDeswarteNicomette

Laboratoire dAnalyse et dArchitecture des Systme du CNRS

7, Avenue du Colonel Roche, 31077 Toulouse Cedex 4

Rapport LAAS Nxxxxx

Soutenance prvue le 28 janvier 2005 devant le jury!:

Laboratoire dAnalyse et dArchitecture des Systmes du CNRS 7, Avenue du colonel Roche 31077 Toulouse Cedex 4

Rapport LAAS Nxxx

prpare au

en vue de lobtention du

par

Dveloppement dune architecture gnrique tolranteaux intrusions pour des serveurs InternetUne architecture gnrique tolrante aux intrusionspour des serveurs Internet Une architecture tolrante aux intrusions pour des serveurs Internet Conception et ralisation dune architecture tolrant les intrusions pour des serveurs Internet

Thse soutenue le 28 Janvier devant le Jury :

Thse soutenue le 28 janvier 2005, devant le jury :

mes parents pour tout leur amour et leur soutien

ceux qui maiment et qui attendent avec impatience ma russite

En esprant tre toujours la hauteur de leurs attentes et de leurs esprances

- Ayda -

RemerciementsLes travaux prsents dans ce mmoire ont t effectus au Laboratoire dAnalyse etdArchitecture des Systmes du Centre National de la Recherche Scientifique (LAAS-CNRS). Je tiens remercier Monsieur Jean-Claude Laprie et Monsieur Malik Ghallab,Directeurs de recherche CNRS, qui ont assur la direction du LAAS-CNRS depuis monentre, de mavoir permis daccomplir mes travaux dans ce laboratoire.

Je remercie galement Monsieur David Powell et Monsieur Jean Arlat, Directeurs derecherche CNRS, responsables successifs du groupe de recherche Tolrance aux fauteset Sret de Fonctionnement informatique (TSF) pour leur accueil et pour la confiancequils mont accorde. Jexprime ma reconnaissance Monsieur David Powell qui apermis ma venue au LAAS et qui avec ses qualits scientifiques et humaines ma faitdcouvrir et apprcier la recherche pendant mon premier sjour dans le groupe.

Jexprime ma profonde reconnaissance Monsieur Yves Deswarte, Directeur deRecherche CNRS, et Monsieur Vincent Nicomette, Matre de Confrences lINSA deToulouse, qui ont dirig mes travaux de thse, pour mavoir encadr et soutenu tout aulong de cette thse. Je les remercie pour leurs conseils, leur soutien et leur disponibilit.Je tiens galement souligner leurs comptences scientifiques dont jai beaucoup tirparti. Je les remercie tous deux pour leur soutien constant et la confiance quils monttoujours tmoigne. Leurs lectures attentives des diffrentes versions du manuscrit etleur aide dans les moments de doute ont fortement contribu au bon droulement destravaux prsents dans ce mmoire. Quils trouvent ici un tmoignage de mon estime etde ma reconnaissance.

Jexprime ma profonde gratitude Monsieur Jean Jacques Quisquater, Professeur deluniversit catholique de Louvain, pour lhonneur quil me fait en prsidant mon jury dethse, ainsi qu :

M. Herv Debar Ingnieur de recherche France Tlcom, M. Ludovic M Professeur Suplc Rennes, M. Alfonso Valdes Chercheur SRI International, Menlo Park, CA, M. Yves Deswarte Directeur de recherche au CNRS, M. Vincent Nicomette Matre de Confrences lINSA de Toulouse,

pour lhonneur quils me font en participant mon jury de thse. Je remercie toutparticulirement Monsieur Herv Debar et Monsieur Ludovic M qui ont accept lacharge dtre rapporteurs.

Je tiens remercier Al Valdes, Josh Levy, Steven Cheung et Magnus Almgren et leurscollgues de SRI International pour leur aide et leurs conseils. Ces travaux sinscriventdans le cadre du projet DIT (Depandable Intrusion Tolerance) men en collaborationavec SRI International. Ce fut une exprience extrmement enrichissante. Jainormment apprci le travail en groupe avec les partenaires du projet au niveau

scientifique et humain. Jai tir de nombreux enseignements de leurs comptences et deleurs expriences.

Je voudrai remercier Bastien Continsouzas pour son aide prcieuse limplmentationde larchitecture. Je suis reconnaissante Vincent Nicomette et Cristophe Zanon pourleur aide la prparation de la dmonstration. Je remercie Fatma Cruszka, El AbassiaDeba, Sarah Khirani, Malika Medjoud, Ali Kalakech et Eric Alata pour leurs relecturesattentives qui ont permis damliorer la qualit de ce manuscrit. Mes remerciements vontnaturellement tous les membres du groupe TSF, permanents, doctorants et stagiairesqui mont permis de travailler dans dexcellentes conditions. Je remercieparticulirement Monsieur Mohamed Kaniche pour son soutien moral et ses conseilspendant les cinq annes passes dans le groupe TSF. Je voudrais aussi remercierMonsieur Yves Crouzet pour sa sympathie et son aide.

Dans ces moments importants, je pense trs fort ma famille en commenant par mesparents, Noureddine et Zaineb, mes frres et soeurs : Nadia, Mourad, Mehdi, Ahmed etSara. Un grand merci Amor qui est venu spcialement de Tunis pour assister masoutenance Je remercie aussi Baba Abdallah, Baba Azizi, Ommi Azizti, OmmiAziza, Ommi Zohra & Baba Haj, Fawzia & Maher, Khadija, Kacem & Walid,Habiba, Aziza, Baba Ali, Zaynouba, Tarrouka & Ghazgouz et tous les autresJe remercie aussi les gens qui ont facilit ma venue en France surtout Khalti Saida etAmm Abdallah

Je ne peux ne pas mentionner les gens qui mont soutenu, conseill et aid pendanttoutes ses annes : Olfa, Slim, Taha, Ali, Afef, El Abassia, Siba, Malika, Souad, Sarah etLeila pour leur prsence dans les moments les plus difficiles. Un grand merci tous mesamis Toulousains, qui ont toujours t l par leur prsence ou pense. Que ceux quejoublie me pardonnent : Noureddine, Tahar, Anas, Mariam, Caroline, Rania, Raoudha,Assawer, Anis

Je remercie mes amies de toujours, Jihne et kawther pour tout ce quelles ont fait pourmoi. Je tiens galement remercier Ayada, Mbarka, Hajer et Rachida pour leur amiti etleur soutien.

Table des matires

Introduction gnrale .........................................................................................................................................9

Chapitre 1 La scurit informatique!: de la prvention la tolrance aux attaques...............................13

1.1 Dfinitions................................................................................................................................................131.1.1 Confidentialit .................................................................................................................................141.1.2 Intgrit ............................................................................................................................................151.1.3 Disponibilit.....................................................................................................................................161.1.4 Autres proprits de scurit ...........................................................................................................16

1.2 Vulnrabilits et attaques ........................................................................................................................171.3 Politiques et modles de scurit ............................................................................................................20

1.3.1 Politiques dautorisation..................................................................................................................201.3.1.1 Politiques discrtionnaires (Discretionary Access Control)....................................................................211.3.1.2 Politiques obligatoires (Mandatory Access Control)...............................................................................221.3.1.3 Politiques de contrle de flux ...................................................................................................................251.3.1.4 Politique de scurit base sur les rles (RBAC).....................................................................................271.3.1.5 Or-BAC (Organization-based Access Control)........................................................................................27

1.3.2 Politiques et modles pour la disponibilit.....................................................................................291.4 Mise en oeuvre de la scurit ..................................................................................................................30

1.4.1 Protection centralise.......................................................................................................................301.4.2 L'approche du livre rouge................................................................................................................311.4.3 Le schma d'autorisation de MAFTIA............................................................................................321.4.4 Autres mcanismes de scurit .......................................................................................................33

1.4.4.1 Audit...........................................................................................................................................................331.4.4.2 Pare-feu......................................................................................................................................................341.4.4.3 Dtection dintrusion.................................................................................................................................35

1.5 Conclusion ...............................................................................................................................................37

Chapitre 2 La tolrance aux intrusions ........................................................................................................39

2.1 La sret de fonctionnement ...................................................................................................................392.1.1 Les concepts de la sret de fonctionnement .................................................................................392.1.2 Notions de fautes, erreurs, dfaillances ..........................................................................................41

2.1.2.1 Dfaillances ...............................................................................................................................................412.1.2.2 Erreurs........................................................................................................................................................422.1.2.3 Fautes .........................................................................................................................................................432.1.2.4 Pathologie des fautes.................................................................................................................................44

2.1.3 Les malveillances.............................................................................................................................452.2 La tolrance aux fautes ............................................................................................................................472.3 Tolrance aux intrusions et survivabilit ................................................................................................48

2.3.1 Techniques de tolrance aux fautes intentionnelles .......................................................................492.3.1.1 Quelques techniques classiques ................................................................................................................492.3.1.2 La Fragmentation-Redondance-Dissmination........................................................................................502.3.1.3 Techniques bases sur les schmas seuil...............................................................................................502.3.1.4 La redondance avec diversification ..........................................................................................................51

2.3.2 Mise en uvre de la tolrance aux intrusions!: exemples d'architectures tolrant les intrusion ..512.3.2.1 Larchitecture Delta4.................................................................................................................................512.3.2.2 Malicious and Accidental Fault Tolerance for Internet Applications (MAFTIA)..................................532.3.2.3 PASIS (Perpetually Available and Secure Information Storage)............................................................552.3.2.4 SITAR (A Scalable Intrusion-Tolerant ARchitecture for Distributed services).....................................572.3.2.5 Intrusion Tolerant Database System (ITDB)............................................................................................59

2.4 Conclusion ...............................................................................................................................................61

Chapitre 3 Une architecture tolrante aux intrusions pour serveurs Internet.........................................62

3.1 Systmes cibles ........................................................................................................................................623.2 Modle de fautes et hypothses des attaques..........................................................................................633.3 Une architecture tolrant les intrusions pour des systmes contenu statique .....................................64

3.3.1 Originalit ........................................................................................................................................653.3.2 Composants......................................................................................................................................67

3.3.2.1 Les mandataires .........................................................................................................................................673.3.2.2 Serveurs dapplication...............................................................................................................................683.3.2.3 Mcanismes de dtection ..........................................................................................................................68

3.3.3 La politique de tolrance aux intrusions!: gestion des rpliques et rponse aux alertes...............823.3.3.1 Politique de tolrance aux intrusions!: cas de larchitecture mono-mandataire......................................833.3.3.2 Politique de tolrance aux intrusions!: cas dune architecture multi-mandataires..................................84

3.4 Une architecture tolrant les intrusions pour des systmes contenu dynamique................................883.4.1 Composants......................................................................................................................................89

3.4.1.1 Le serveur de base de donnes..................................................................................................................893.4.1.2 Les mandataires .........................................................................................................................................913.4.1.3 Serveurs dapplication...............................................................................................................................933.4.1.4 Prise en compte de ladjudicateur dans la politique de tolrance aux intrusions ...................................96

3.4.2 Exemples..........................................................................................................................................973.4.2.1 Droulement !normal! dune requte ....................................................................................................973.4.2.2 Dtection de la corruption dun serveur ...................................................................................................98

3.5 Discussion ..............................................................................................................................................1003.6 Conclusion .............................................................................................................................................101

Chapitre 4 Mise en uvre dun prototype et mesures de performances.................................................104

4.1 Implmentation ......................................................................................................................................1044.1.1 Plateforme exprimentale..............................................................................................................1044.1.2 Les mandataires .............................................................................................................................106

4.1.2.1 Le gestionnaire des alertes ......................................................................................................................1074.1.2.2 Les modules spcifiques .........................................................................................................................112

4.1.3 Les serveurs dapplication.............................................................................................................1144.1.3.1 La bibliothque de base de donnes (DITSQL).....................................................................................1154.1.3.2 Le mdiateur ............................................................................................................................................117

4.2 Mesures de performances......................................................................................................................1184.2.1 Premire mesure ............................................................................................................................1194.2.2 Deuxime mesure ..........................................................................................................................1214.2.3 Troisime mesure...........................................................................................................................124

4.3 Conclusion .............................................................................................................................................126

Conclusion gnrale........................................................................................................................................128

Bibliographie ...................................................................................................................................................132

Annexe I ...........................................................................................................................................................140

Introduction gnrale

La connexion de systmes critiques Internet pose de srieux problmes de scurit. Eneffet, les techniques classiques de protection sont souvent inefficaces dans ce nouveaucontexte. Lenvironnement Internet est principalement caractris par limprdictibilitdes nouvelles attaques et surtout par le grand nombre dattaquants potentiels. Lesmoyens classiques de protection des systmes informatiques sont gnralement bass surle principe de la prvention des fautes accidentelles et des malveillances quicorrespondent aux intrusions (attaques actives). Dans le cadre de rseaux ouverts, telsquInternet, ces approches ont montr leur limite : on sait que de nouvelles attaques, plusperformantes, voient le jour rgulirement et parviennent mettre en dfaut cesmcanismes de protection. Il faut ds lors envisager que certains serveurs puissent trelobjet dattaques russies. Pour que de telles attaques ne puissent interrompre oucorrompre le service fourni aux utilisateurs lgitimes, il faut mettre en uvre denouvelles solutions.

Dans ce contexte, il est donc important de prvoir, ds la conception du systme,lutilisation des mcanismes de prvention de fautes, pour se prmunir des attaquesconnues. Mais il faut aussi prendre en compte des attaques inconnues et nouvelles quipourraient russir sinfiltrer dans le systme : pour cela, il faut mettre en place desmcanismes pour les tolrer en les dtectant puis en isolant les composants corrompus,de faon empcher la propagation de lattaque aux autres parties du systme. Pour quela raction du systme ce type dattaques puisse tre la mieux adapte possible, il fautque le systme ait des capacits de diagnostic prcis. Linterprtation du rsultat doitpermettre une reconfiguration optimale du systme, en essayant de limiter le pluspossible les rpercussions sur les performances perues par les utilisateurs.

Pour atteindre ces objectifs, nous proposons de mettre en uvre aussi bien des moyensde prvention comme les pare-feux que des mcanismes de tolrance aux intrusions,bass sur des mcanismes de redondance avec diversification. Pour permettre unemeilleure flexibilit et adaptabilit, nous avons choisi une politique qui sadapte auniveau dalerte du systme pour utiliser au mieux les ressources matrielles etlogicielles.

Cette thse se situe dans le cadre du projet DIT (Dependable Intrusion Tolerance) encollaboration avec SRI International. Ce projet sinscrit dans le programme OASIS(Organically Assured and Survivable Information Systems) de la DARPA1 qui a pour

1 US Defense Advanced Research Agency

Introduction gnrale 10

objectif de concevoir, dvelopper et valider des architectures, outils et techniques detolrance aux intrusions, en particulier partir de composants commerciaux (COTS).Dans ce contexte, nos travaux concernent la conception et la validation dunearchitecture gnrique, tolrant les intrusions, qui peut constituer un cadre gnral pourla mise en uvre de systmes dinformation srs. Nous dtaillons le cas particulier deserveurs Web tolrant les intrusions.

Nous avons abouti deux architectures que nous prsentons dans ce manuscrit, lapremire architecture, dveloppe majoritairement SRI, est destine des serveurs contenu statique. Dans cette premire architecture, aucune mise jour nest admisependant le fonctionnement du systme. Ceci correspond au fonctionnement dun serveurWeb mettant la disposition du public des informations stables, rarement mises jour.Mais certaines applications ncessitent la manipulation de donnes dynamiques quiprovoquent des modifications dans ltat du systme. Un exemple typique est celuidune agence de voyage sur Internet : des rservations, des modifications, desannulations sont faites en temps rel et des bases de donnes sont modifies descentaines de fois par jour. un instant t, il faut que ltat de la base de donnes reflte lasituation relle des places rserves et des places disponibles pour ne pas rserver desplaces plusieurs fois ou refuser des rservations alors quil y a des places disponibles.Pour cette raison, nous avons tendu larchitecture pour grer des donnes dynamiques.Cette deuxime architecture est majoritairement dveloppe au LAAS.

Notre architecture est compose dun ou plusieurs mandataires identiques, quireprsentent llment principal implmentant notre politique de tolrance, dunensemble de serveurs dapplications qui excutent des logiciels commerciaux (COTS)fournissant les services demands par les clients et dun ensemble de mcanismes dedtection derreurs (y compris des systmes de dtection dintrusion).

Cette architecture est base sur les techniques de redondance avec diversification. Ladiversification renforce les capacits du systme faire face aux attaques. En effet, uneattaque vise gnralement des failles spcifiques un certain systme dexploitation, unecertaine application ou une certaine plateforme matrielle et savre inefficace sur lesautres. En disposant de serveurs redondants et diversifis, le systme est capable desurvivre aux attaques qui ne peuvent corrompre quune partie de ces serveurs alors queles autres continuent fonctionner normalement.

Loriginalit de cette architecture rside dans son adaptabilit. En effet, en fonction de lasituation courante du systme (niveau dalerte), les mandataires peuvent adapter leniveau de redondance ainsi que la frquence et la svrit des contrles. Nous parvenonsainsi raliser un bon compromis entre scurit et performance, la scurit du systmetant toujours prioritaire.

Ce mmoire est structur en quatre chapitres :

- Le premier chapitre sintresse lvolution de la scurit informatique depuisles approches classiques bases sur une protection forte jusquaux nouvellesapproches de tolrance aux intrusions. Dans ce chapitre, nous prsentons aussisynthse de ltat actuel de la scurit sur Internet.

Introduction gnrale 11

- Le deuxime chapitre concerne la tolrance aux intrusions. Dans une premirepartie, nous introduisons les concepts de la sret de fonctionnementinformatique et les techniques de tolrance aux fautes. Ensuite, nous prsentonsune adaptation de ses concepts aux malveillances et nous prsentons quelquesmcanismes de tolrance aux intrusions. La dernire partie de ce chapitreprsente quelques architectures tolrantes aux intrusions.

- Le troisime chapitre prsente larchitecture tolrant les intrusions que nousavons dveloppe. Nous dtaillons la structure et les fonctionnalits de chaquecomposant de larchitecture. Nous prsentons aussi notre politique de tolranceaux intrusions en donnant des exemples des modes de recouvrement de lacorruption de certains composants du systme.

- Le quatrime chapitre sintresse limplmentation dun prototype. Nousdtaillons la mise en uvre de larchitecture et nous prsentons quelquesrsultats des performances du systme dans diffrentes configurations.

Chapitre 1

La scurit informatique : de laprvention la tolrance aux attaques

1

Dans ce chapitre, nous prsentons les concepts de base de la scurit informatique. Nousdfinissons les proprits primordiales de la scurit informatique : disponibilit,confidentialit et intgrit. Ensuite nous dfinissons les principales menaces vis--vis dela scurit informatique savoir les vulnrabilits et les attaques. La deuxime partie duchapitre concerne les politiques de scurit ; nous prsentons les diffrents types depolitiques dautorisation, qui ont pour but dassurer la confidentialit ou lintgrit dusystme, et quelques travaux concernant les politiques de disponibilit. Ensuite, nousprsentons des exemples darchitectures mettant en uvre ces politiques de scurit. Ladernire partie sintresse la scurit sur Internet.

1.1 Dfinitions

La scurit dun systme informatique est considre comme la combinaison de troisproprits [ITSEC 91] : la confidentialit, lintgrit, et la disponibilit de linformation.Notons que ces trois proprits se rapportent linformation, et le terme dinformationdoit tre pris ici dans son sens le plus large, couvrant non seulement les donnes et lesprogrammes, mais aussi les flux dinformation, les traitements, et la connaissance delexistence de donnes, de programmes, de traitements, de communications. Cette notiondinformation doit aller jusqu couvrir le systme informatique lui-mme, dont parfoislexistence doit tre tenue secrte (confidentialit). Pour tre plus prcis, il convient dedistinguer informations et mta-informations, les informations correspondent desdonnes identifies alors que les mta-informations correspondent des informationsindirectes relies aux informations ou aux services. Bien videmment, ce qui est mta-information un niveau dabstraction donn (par exemple, une application) peut tre uneinformation relle un niveau plus bas (par exemple, le systme dexploitation).

Donnons quelques exemples de mta-informations :

- linstant de dlivrance dun service, ou de la cration, modification oudestruction dun lment dinformation,

La scurit informatique : de la prvention la tolrance aux attaques 14

- lidentit de la personne qui a ralis une opration, le crateur dun lmentdinformation,

- lauteur dun document, lexpditeur ou le rcepteur dun message,- lemplacement ou ladresse dun lment dinformation, dune entit ou dun

dispositif de communication,

- lexistence dun lment dinformation ou dun service,- lexistence dun transfert dinformation, dun canal de communication, ou dun

message,

- loccurrence dune opration,- le niveau de sensibilit dun lment dinformation, ou dune mta-information,- la certitude ou le niveau de crdibilit dun lment dinformation ou dune

mta-information, etc.

Assurer la scurit dun systme consiste garantir la conservation dun certain nombrede proprits de scurit dfinissant les caractristiques de confidentialit, dintgrit, etde disponibilit qui doivent tre maintenues dans le systme. Ceci implique dempcherla ralisation doprations illgitimes contribuant mettre en dfaut ces proprits, maisaussi de garantir la possibilit de raliser des oprations lgitimes dans le systme. Cesproprits font partie de la politique de scurit du systme. Assurer la scurit dusystme, cest donc faire en sorte que les proprits de scurit soient toujours vrifies.

1.1.1 Confidentialit

La confidentialit peut tre dfinie comme la proprit dune information de ne pas trervle des utilisateurs non autoriss la connatre. Assurer la confidentialit, cestfaire en sorte que les informations soient inaccessibles ou incomprhensibles pour desutilisateurs non dsigns comme autoriss y accder [Deswarte et al. 03]. Cecicorrespond empcher un utilisateur de lire une information confidentielle quil nestpas autoris connatre mais aussi empcher un utilisateur autoris lire uneinformation de la divulguer dautres utilisateurs non autoriss y accder. Garantir laconfidentialit revient assurer que tous les canaux dinformations sont scuriss, cest--dire que tous les chemins que peut prendre linformation pour circuler dans le systmeou vers lextrieur sont contrls. Ceci entrane des contraintes fortes et des cotssouvent incompatibles avec les besoins rels ; dans la plupart des cas, on ne soccuperaque de scuriser un certain nombre de ces canaux.

La confidentialit des informations peut tre mise en dfaut par des fautesintentionnelles mais aussi par des fautes accidentelles. Un exemple de divulgationdinformations par faute accidentelle est le cas dun utilisateur qui se trompe dans ladestination du message lectronique et envoie une information sensible tout lepersonnel de son entreprise alors quil voulait juste lenvoyer une personne deconfiance.


1.1.2 Intgrit

Lintgrit de linformation est la proprit quelle soit correcte , cest--dire quellereflte la ralit, tout le temps. Cela signifie que le systme informatique doit permettreles actions autorises, forcer les actions obligatoires et empcher les actionsmalveillantes afin de garantir lintgrit des informations stockes dans ce systme. Enparticulier, il doit:

- forcer la cration dune information devant tre cre,

- permettre la cration autorise de linformation,

- permettre une modification autorise de linformation,

- empcher une modification indue de linformation, cest--dire une modificationpar des utilisateurs non autoriss ou une modification incorrecte par desutilisateurs autoriss,

- faire en sorte quaucun utilisateur ne puisse empcher la modification lgitime delinformation ; par exemple, empcher la mise jour priodique dun compteurde temps serait une atteinte contre lintgrit.

Pour assurer cette proprit, le systme doit mettre en uvre des mcanismesgarantissant la cration lgitime de linformation, des mcanismes vrifiant que lesmises jour effectues sont autorises et valides, des mcanismes garantissant laralisation des mises jour devant tre effectues ainsi quventuellement desmcanismes vrifiant la correspondance entre linformation et ce quelle reprsente.

Cette dfinition peut tre interprte dans un sens trs gnral. En particulier, desoprations non autorises peuvent affecter aussi bien des parties physiques du systmeque des parties logiques. Le premier type daltration consiste modifier un composantphysique, par exemple la modification dune carte puce par faisceau ionique. Nousnous intressons tout particulirement aux altrations qui portent sur les parties logiquesdu systme, cest--dire les programmes et les informations.

Ainsi dfinie, lintgrit des informations peut tre mise en dfaut par des fautesintentionnelles mais aussi par des fautes accidentelles. Dans le cadre des fautesintentionnelles, il est ncessaire dempcher toute altration non autorise delinformation. De plus, mme si un utilisateur est autoris modifier une donne, il fautempcher les abus de pouvoir, cest--dire empcher que cet utilisateur, par exemple unadministrateur systme, ne profite de ses droits pour altrer une information de manireinapproprie. Dans le cadre des fautes accidentelles, on doit sassurer que chaqueprogramme se comporte de manire correcte, cest--dire conformment aux fonctionsquil est cens remplir, y compris dans ses interactions avec les autres processus. Celarevient dire quil doit tre suffisamment fiable pour quon puisse assurer quilneffectuera pas une action non conforme au bon fonctionnement du systme.

Une atteinte contre lintgrit vise, soit introduire de fausses informations soit, provoquer des erreurs en modifiant ou en dtruisant linformation, pour que le servicedlivr par le systme produise un bnfice pour lattaquant, au dtriment desutilisateurs autoriss. Cest typiquement le cas des fraudes informatiques, o lattaquant


essayera de faire en sorte que les erreurs quil introduit ne soient pas dtectables et queles dfaillances qui en rsultent ne soient pas identifiables.

1.1.3 Disponibilit

La disponibilit est la proprit dune information dtre accessible lorsquun utilisateurautoris en a besoin. Cela signifie que le systme informatique doit :

- fournir laccs linformation pour que les utilisateurs autoriss puissent la lireou la modifier, et

- faire en sorte quaucun utilisateur ne puisse empcher les utilisateurs autorissdaccder linformation.

La disponibilit implique lintgrit, puisquil ne servirait rien de rendre accessible uneinformation fausse. La disponibilit implique galement des contraintes plus ou moinsprcises sur le temps de rponse du systme. La proprit de disponibilit sappliqueaussi au service fourni par le systme informatique.

Laccs au systme peut tre interrompu par des fautes accidentelles : par exemple, unefaute de programmation dans une application ou bien un vnement extrieur au systme(par exemple : coupure dlectricit, incendie ou tremblement de terre). Il peutgalement tre interrompu par des fautes intentionnelles, par exemple, un dni de servicequi a pour but dempcher le systme de remplir le service appropri. Ces fautescorrespondent une destruction volontaire, que ce soit du matriel, des donnes, desmessages, des moyens de communication, ou des processus de traitement, afindempcher le systme de fournir le service attendu.

Comme lintgrit, la disponibilit est une proprit relative aux fautes accidentelles etintentionnelles. Cependant, les moyens pour assurer cette proprit peuvent trediffrents pour les deux classes de fautes. La disponibilit est souvent nglige dans laconception des systmes critiques vis--vis de la scurit et quand elle est prise encompte, les fautes intentionnelles sont gnralement les seules classes de fautes prises enconsidration. Or du point de vue de lutilisateur, ce ne sont pas les fautes qui sontperues, mais bien les dfaillances qui en rsultent. Il est donc absolument ncessaire detolrer ou de prvenir la fois les fautes accidentelles et les fautes intentionnelles si lonveut assurer la disponibilit dun systme. La disponibilit na pas t le souci principalde la communaut de la recherche en scurit, puisque laccent tait principalement missoit sur la confidentialit dans le domaine militaire soit sur lintgrit dans le domainefinancier.

1.1.4 Autres proprits de scurit

Dautres proprits de scurit sont parfois prendre en compte, telles que laresponsabilit, lintimit, lauthenticit, lauditabilit, etc. Ces proprits peuvent tredfinies en termes de proprits de confidentialit, dintgrit et de disponibilitdinformations ou de mta-informations.


Par exemple, la proprit de responsabilit (accountability en anglais) peut treexprime en termes de disponibilit et dintgrit dun ensemble de mta-informationsconcernant lexistence dune opration, lidentit de la personne qui a ralis lopration,linstant de lopration, etc. Lintimit (privacy en anglais) concerne le respect desliberts individuelles et la protection de la vie prive. Elle se rapporte directement laconfidentialit dinformations (donnes nominatives ou caractre personnel) et demta-informations (identit de lutilisateur qui a effectu une certaine opration, qui amis ou reu un certain message, etc.).

Lanonymat (anonymity en anglais) correspond la confidentialit de lidentit de lapersonne qui a ralis une opration.

Lanalyse du trafic est une attaque contre la confidentialit de mta-informations decommunication, en vue dobtenir connaissance de lexistence dun canal, dun message,des identits, emplacements ou adresses de lmetteur et du rcepteur dun message, dela dure de la communication, etc.

Lauthenticit (authenticity en anglais) est la proprit dtre vrai . Pour un message,lauthenticit est quivalente lintgrit la fois du contenu du message (intgrit desinformations) et de son origine, ainsi quventuellement dautres mta-informationstelles que linstant dmission ou le niveau de classification (intgrit des mta-informations). De la mme manire, un document est authentique si son contenu na past altr (intgrit des informations) et optionnellement si lauteur dclar est vraimentlauteur et non un plagiaire, si la date de publication est correcte, etc. (intgrit des mta-informations). De la mme manire, un utilisateur prtendu est authentique si lidentitdclare est bien la bonne identit de cette personne.

Lauthentification est le processus qui donne confiance dans lauthenticit.

Lauditabilit et les proprits qui en sont drives (imputabilit, irrfutabilit, etc.)[Trouessin 00] correspondent la disponibilit et lintgrit dun ensemble de mta-informations relatives lexistence dune opration, lidentit de la personne qui aralis lopration, linstant de lopration, etc.

La proprit de non-rpudiation (non-repudiation en anglais) garantit quune personneayant ralis une opration dans le systme ne puisse nier lavoir ralise. Ellecorrespond la disponibilit et lintgrit de certaines mta-informations, par exemplelidentit de la personne qui a effectu lopration.

1.2 Vulnrabilits et attaques

De nos jours, les applications deviennent de plus en plus complexes et lintgration decomposants sur tagre (COTS) est une pratique courante mme dans le cadre dedveloppement de systmes critiques. La consquence directe de cette pratique estlaugmentation des failles de scurit dans ces systmes. En effet, lvolution du nombrede vulnrabilits ne cesse daugmenter : en 2000, 1090 vulnrabilits ont t identifie,par le CERT (Computer Emergency Response Team), alors quen 2003, ce chiffre atripl, atteignant 3784 vulnrabilits.


Une vulnrabilit dans un systme informatique est une partie de celui-ci pouvant treexploite pour violer des proprits de scurit. Les vulnrabilits peuvent treaccidentelles ou intentionnelles. Les vulnrabilits dorigine accidentelles correspondent diffrentes formes derreurs logiques qui peuvent survenir pendant la programmationou le fonctionnement du systme (exemple : les erreurs de configuration). Lesvulnrabilits dorigine intentionnelle peuvent tre dorigine malveillante ou non. Pourles vulnrabilits dorigine malveillante, il sagit de diffrentes fautes ou desfonctionnalits introduites dans le systme dans lobjectif dtre utilises ultrieurementpour lattaquer : par exemple, les attaques de types cheval de Troie ou bombe logique2.Pour les vulnrabilits intentionnelles dorigine non malveillante, il sagit gnralementdes fonctionnalits introduites, dans le systme, dans des conditions particulires pouraccomplir une certaine mission avec le minimum de risques. Par exemple, un directeurqui part en vacances et il a besoin que sa secrtaire lise son email et linforme en casdurgence. Pour lui donner le droit de lire son email, il y a deux solutions : 1) lui donnerson mot de passe, 2) lajouter dans le fichier .rhosts. Dans cette situation, il vaopter pour la deuxime solution qui reprsente une mesure de scurit mme si cettesolution constitue une vulnrabilit.

Il y a en particulier cinq problmes qui sont lorigine de 90% des vulnrabilits dansles systmes informatiques [Wong 02]. Ces problmes sont connus depuis des annesmalheureusement, ils figurent toujours la tte des vulnrabilits les plus exploites parles attaquants :

- Le dbordement de tampon ou de pile : il sagit probablement de la faute deprogrammation la plus souvent exploite par les attaquants. Le dbordement detampon peut tre exploit pour forcer un programme excuter un codemalicieux la place de son code original.

- Les vulnrabilits lies au formatage des chanes de caractres : il sagit dunenouvelle classe de vulnrabilits, dcouverte rcemment. Les formats des chanesde caractres sont des structures utilises dans les programmes C et C++ pourformater les entres/sorties. Ils contiennent des identificateurs spciaux (parexemple : %s pour les chanes de caractres, %d pour les entiers) qui peuvent treexploits par les attaquants pour rvler des informations sur les appels dans lapile ou les variables utilises dans les fonctions. En particulier, lidentificateur%n peut tre utilis pour craser des donnes en mmoire ce qui conduit auxmmes problmes du dbordement de tampon.

- Lauthentification est un composant critique pour la scurit dun systmeinformatique. Authentifier incorrectement un utilisateur neutralise tous les autresmcanismes de scurit comme le chiffrement, laudit ou lautorisation. Lerreurla plus courante pour lauthentification est lutilisation de faibles preuvesdauthentification pouvant tre forces par un attaquant (par exemple : un mot depasse facile deviner).

2 Les dfinitions prcises de ces attaques sont donnes dans le chapitre 2.


- Lautorisation est le mcanisme qui contrle les permissions daccs auxressources en se basant sur lidentit dun utilisateur dj authentifi. Parmi leserreurs les plus communes, on peut citer :

1- une mise en uvre insuffisamment sre : cest le cas quand un identificateurest exig pour lautorisation et quon suppose que celui-ci ne peut pas tredevin ou chang. Par exemple, un test sur une application bancaire sur leWeb a montr que le serveur Web utilise une variable JavaScript pour stockerle numro du compte. En changeant simplement cette variable il est possibledditer des informations concernant dautres comptes ;

2- trop de confiance dans les informations fournies par lutilisateur : parexemple, un serveur Web qui se base sur lutilisation des Cookies http dans leprocessus dautorisation, sachant que leur contenu est facilement falsifiable.Une telle action met en danger la scurit sur le serveur Web ;

3- les erreurs de forme non canonique : la majorit des mcanismes de contrledaccs sont bass sur les preuves dauthentification et les ressourcesdemandes. Plusieurs vulnrabilits sont lies des erreurs de forme noncanonique : par exemple, une application peut refuser laccs dun utilisateurau fichier /secure/secret.txt et lautoriser accder au fichier/public/../secure/secret.txt.

- Le chiffrement : une grande confiance est place dans les algorithmescryptographiques et leur robustesse. Cependant, il est difficile de trouver desprogrammeurs aussi comptents en mathmatique quen informatique. Ce quisignifie quil est possible quune erreur survienne lors de la conception ou de lamise en uvre dun algorithme de chiffrement. Une telle erreur fragiliseconsidrablement la scurit de lapplication.

Les vulnrabilits sont les portes dentres du systme informatique pour les attaquants.On pourrait penser que les attaquants sont la recherche de vulnrabilits inconnues parles dveloppeurs ou les administrateurs, mais dans la ralit, la majorit des attaquessont effectues en exploitant des vulnrabilits connues qui nont pas t corriges. Deplus, les attaquants sont de plus en plus rapides prparer leurs attaques ds quunenouvelle vulnrabilit est annonce. Par exemple, le ver Slammer (2003) a t lanc 6mois aprs la dcouverte de la vulnrabilit alors que le ver Witty (2004) a t lanc 24heures seulement aprs lannonce de cette vulnrabilit.

Les menaces mettant en danger la scurit du systme peuvent tre aussi bien dorigineexterne ou interne [Anderson 80]. Les menaces externes correspondent aux attaquantsexternes qui nont pas le droit de raliser des oprations lintrieur de celui-ci. Lesmenaces internes correspondent un utilisateur autoris qui agit illgitimement poursoctroyer plus de pouvoir ou un utilisateur privilgi qui agit avec malveillance et abusede son pouvoir. Les statistiques montrent que 70% des attaques au sein des entreprisessont dues des malveillances du personnel [Pescatore 02].

Pour amliorer le niveau de scurit dans les systmes, il faut prendre en compte lesexigences de scurit ds ltape de spcification et tenir compte de ces exigences tout


au long du processus de dveloppement. Il est indispensable de dfinir avec prcision lapolitique de scurit qui dcrit ces exigences.

1.3 Politiques et modles de scurit

Une politique de scurit est dfinie comme lensemble des lois, rgles et pratiques quirgissent la faon dont linformation sensible et les autres ressources sont gres,protges et distribues lintrieur dun systme spcifique [ITSEC 91]. Elle dfinitdune part lensemble des proprits de scurit qui doivent tre satisfaites par lesystme, cest--dire des proprits de confidentialit, dintgrit, et de disponibilit, etdautre part les rgles de scurit qui sont imposes au comportement du systme dans lebut dobtenir et de maintenir ces proprits.

Par exemple, une proprit de scurit pourra tre une information classifieconfidentielle ne doit pas tre transmise un utilisateur non habilit la connatre,alors quune rgle du schma dautorisation pourra tre le propritaire duneinformation peut accorder un droit daccs pour cette information nimporte quelutilisateur. Si la politique dautorisation est cohrente, il ne doit pas tre possible,partant dun tat initial sr (cest--dire satisfaisant les proprits de scurit),datteindre un tat dinscurit (cest--dire un tat o les proprits de scurit ne sontpas satisfaites) en appliquant les rgles du schma dautorisation [Deswarte et al. 03].

Les rgles de scurit expriment des contraintes sur le comportement du systme enexprimant les oprations autorises et celles qui sont interdites. Dans une politique descurit, les rgles doivent satisfaire les objectifs de scurit (confidentialit, intgrit, etdisponibilit), en fait, l'application de ces rgles doit avoir comme consquence lagarantie des proprits de scurit du systme. La violation d'une rgle de scurit neconstitue pas ncessairement une dfaillance vis--vis de la scurit, cest--dire le non-respect dune proprit de scurit, mais peut rendre le systme plus vulnrable. Ainsi,par exemple, une rgle peut spcifier que les mots de passe doivent tre choisis demanire alatoire dans un espace de donnes suffisamment grand. La violation d'unetelle rgle ne constitue pas immdiatement une dfaillance vis--vis de la scurit, maisexpose le systme des attaques par dictionnaire sur les mots de passes.

1.3.1 Politiques dautorisation

La plupart des politiques dautorisation sont bases sur les notions de sujets, dobjets etde droits daccs [Deswarte et al. 03]. Un sujet est une entit active, correspondant unprocessus qui sexcute pour le compte dun utilisateur. Dans ce contexte, un utilisateurest une personne physique connue du systme informatique et enregistre commeutilisateur, ou un serveur, sorte de personne morale reprsentant des fonctionsautomatiques de service, tel que serveur dimpression, serveur de base de donnes,serveur de messagerie, etc. Un objet est une entit considre comme passive quicontient ou reoit des informations. un instant donn, un sujet a un droit daccs surun objet si et seulement si le processus correspondant au sujet est autoris excuterlopration correspondant ce type daccs sur cet objet. Les droits daccs sontgnralement reprsents sous forme dune matrice de droits daccs, avec une ligne par


sujet, une colonne par objet, chaque case de la matrice contenant la liste des droits quepossde ( un instant donn) le sujet, dfini par la ligne, sur lobjet, dfini par lacolonne.

Les politiques de scurit sont gnralement dcrites par un modle formel, ce quipermet de vrifier que la politique est complte et cohrente, et que la mise en uvre parle systme de protection est conforme. Il existe deux types de modles :

- des modles spcifiques, dvelopps pour reprsenter une politiquedautorisation particulire, comme les modles de Bell-LaPadula [Bell et al. 76],de Biba [Biba 77], de Clark & Wilson [Clark et al. 87], etc. ;

- des modles gnraux, qui sont plutt des mthodes de description formelle,pouvant sappliquer toutes sortes de politiques, comme le modle HRU[Harrison et al. 76] ou le modle Take-Grant [Jones et al. 76].

Le modle HRU dcrit les droits sous forme de matrice de contrle daccs, et ne permetpas de faire directement de vrification de cohrence ou de compltude. En revanche, lemodle Take-Grant donne une reprsentation graphique des droits et de leur volution(par des rgles de modification du graphe), ce qui permet de faire certaines vrificationsautomatiques de cohrence. Nanmoins, pour un systme rel, de telles vrificationssont gnralement coteuses [Dacier 93] et incompltes : on ne peut vrifier, sans faireune numration totale, quil nest pas possible datteindre un tat dinscurit. Desextensions du modle HRU ont t proposes pour rsoudre ce problme, au prix decertaines restrictions sur les rgles du schma dautorisation. Cest le cas en particulierdu modle TAM [Sandhu 92] et du graphe des privilges [Dacier 94].

1.3.1.1 Politiques discrtionnaires (Discretionary Access Control)

Dans le cas dune politique dautorisation discrtionnaire, ce sont les sujets eux-mmesqui dfinissent leur discrtion, quels sont les accs autoriss sur les informations quilscontrlent. Ceci peut parfois amener le systme dans un tat dinscurit, cest--dire nesatisfaisant pas les proprits de la politique dautorisation qui a t choisie. La gestiondes droits daccs dans une telle politique, repose sur la notion de propritaire : toutsujet est propritaire dun ensemble dobjets, et chaque sujet peut prciser, pour lesobjets lui appartenant, les droits daccs accords aux autres sujets.

Une politique de scurit discrtionnaire contient donc typiquement la rgle suivante :

Un sujet s peut accorder un droit daccs d sur un objet o un autre sujet s si etseulement si s est le propritaire de lobjet o

titre dexemple, considrons la politique de scurit discrtionnaire mise en oeuvredans le systme de gestion des fichiers dUNIX. Les processus et les utilisateurs dusystme sont considrs comme les sujets, les objets tant les fichiers du systme. Lesoprations permettant daccder aux fichiers sont la lecture, lcriture et lexcution. ces oprations sont associs des droits daccs, nots respectivement r, w et x. Lapolitique de scurit contient les rgles suivantes :


- Rgle 1 : un utilisateur est propritaire des fichiers quil cre.

- Rgle 2 : un utilisateur est autoris modifier les droits daccs dun fichier si etseulement si le fichier lui appartient.

- Rgle 3 : un utilisateur est autoris accder un fichier si et seulement silpossde le droit daccs correspondant sur ce fichier.

Dans ce cas prcis, supposons que la politique vise respecter la proprit suivante :les utilisateurs qui nont pas le droit de lire un fichier ne doivent pas pouvoir enconnatre le contenu.

Une telle politique nest pas ralisable par des mcanismes dautorisationdiscrtionnaire, comme nous pouvons le montrer en utilisant une notation drive dumodle HRU :

- si u1 est propritaire du fichier f1, il peut donner lutilisateur u2 le droit delecture sur f1 :

(u1, f1, propritaire) =>(u2, f1, lire)

- u2 peut crer un fichier f2 (dans lequel il peut donc crire) sur lequel il peutdonner le droit de lecture u3 :

(u2, f2, crer) => (u2, f2, crire) ^ (u3, f2, lire)

- u2 peut donc recopier f1dans f2 pour transmettre les informations de f1 u3 linsudu propritaire u1 :

(u2, f1, lire) ^ (u2, f2, crire) ^ (u3, f2, lire) =>(u3, copie(f1), lire)

Une politique discrtionnaire nest donc applicable que dans la mesure o il est possiblede faire totalement confiance aux utilisateurs et aux sujets qui sexcutent pour leurcompte ; une telle politique est par l mme vulnrable aux abus de pouvoir provoquspar maladresse ou par malveillance.

De mme les politiques dautorisation discrtionnaire sont vulnrables aux attaques parchevaux de Troie. Dans ce cas, le systme ne peut en effet distinguer une demande dechangement de droit daccs provenant dun utilisateur de celle qui provient dun chevalde Troie sexcutant pour le compte de cet utilisateur son insu.

1.3.1.2 Politiques obligatoires (Mandatory Access Control)

Pour rsoudre les problmes des politiques discrtionnaires, les politiques ditesobligatoires imposent, par leur schma dautorisation, des rgles incontournables quisajoutent aux rgles discrtionnaires.

Dans ce type de politique dautorisation, aux sujets et aux objets du systme sontassocis des attributs de scurit et les rgles dcrivent les accs autoriss en termes deconditions qui doivent tre vrifies par les attributs. Ces rgles sont diffrentes selonquil sagit de maintenir des proprits lies la confidentialit ou lintgrit. Pour ce


qui concerne la confidentialit, lune des faons de spcifier ces rgles est dimposer auxobjets et aux sujets une structure hirarchique ; cest le cas des politiques multi-niveauxbases sur les rglements de scurit appliqus par les militaires pour la confidentialitdes documents.

Dans une telle politique, les informations et les utilisateurs appartiennent des classesde scurit prdfinies, correspondant des niveaux ordonns (par exemple, non-classifi, diffusion restreinte, confidentiel, secret, trs secret) et des catgories non-ordonnes entre elles (par exemple, cryptographie, nuclaire, mdical, etc.). chaqueutilisateur, on associe une habilitation correspondant un niveau de scurit et uncompartiment dfini comme un ensemble de catgories. De mme, chaqueinformation, on associe une classification correspondant galement un niveau descurit et un compartiment. Des rgles sont imposes pour dterminer quelleshabilitations permettent quels accs des informations de quelles classifications. Cesrgles sont incontournables, mme par les propritaires des informations.

Le modle de Bell et La Padula [Bell et al. 76] fournit un exemple de telles rgles :

- Rgle simple : un sujet si ne peut lire un objet oj que si son habilitation h(si )domine3 la classification c(oj) de lobjet :

(si, oj, lire) =>h(si) c(oj)

- Rgle toile : un sujet ne peut lire un objet oj et en crire un autre ok que si laclassification de ok domine celle d oj :

(si, oj, lire) ^ (si, ok, crire) => c(ok) c(oj)

Dans ce modle, la rgle simple interdit de lire des informations dune classificationsuprieure lhabilitation, et la rgle toile empche les flux dinformation duneclassification donne vers une classification infrieure, ce qui constituerait une fuitedinformation : on peut vrifier facilement que si h(sn) < c(oi), il nexiste pas de suites{i,j,...,k} et {l,m,...,n} telles que :

(sl, oi, lire) ^ (sl, oj, crire) ^ (sm, oj, lire) ^ ... ^ (sx, ok, crire) ^ (sn, ok, lire)

En effet, ceci conduirait (par la rgle toile et la rgle simple) :

c(oi) c(oj) h(sm) ... c(ok) h(sn) =>c(oi) h(sn)

ce qui est contraire lhypothse de dpart. Le modle permet donc de prouver que lapolitique est cohrente, cest--dire que le schma dautorisation ne peut conduire untat o la proprit une information classifie ne doit pas tre transmise un

3 Par dfinition, une classe A domine (avec la notation ) une classe B si et seulement si lafois le niveau de A est suprieur ou gal au niveau de B et le compartiment de B est inclus ougal au compartiment de A.


utilisateur non habilit la connatre ne soit pas respecte en appliquant les rglesimposes.

Le modle de la muraille de Chine [Brewer et al. 89] tudie le problme de laconfidentialit lintervention dune personne dans diffrents milieux en conflitdintrt. Ainsi ce modle dfinit la notion de classe dintrt. Il stipule quune personnene peut tre autorise consulter une information si elle connat dj une autreinformation en conflit dintrt avec la premire (leurs classes dintrt sont en conflit).Ainsi, par exemple, imaginons un consultant ayant accs aux informations de deuxsocits concurrentes A et B. Ds lors que le consultant a eu accs aux informations dela socit A, il lui est interdit de consulter toute information de la socit B puisque lesclasses dintrts de ces informations sont en conflit. En fait, le consultant a, au dpart,la libert de choisir linformation consulter, mais chaque dcision quil prend dressedevant lui une barrire quil ne peut plus franchir. La muraille de Chine est une image decette barrire. Cette politique correspond une rglementation impose aux agents dechange britanniques car leur travail les amne travailler pour diffrentes socits quipeuvent tre en situation de conflit dintrt.

Dautres politiques obligatoires ont t dveloppes pour le maintien de lintgrit. Cestle cas de la politique propose par Biba [Biba 77], qui applique lintgrit un modleanalogue celui de Bell-LaPadula pour la confidentialit. Dans ce modle, chaquesujet s on affecte un niveau dintgrit is(s), correspondant la confiance quon a dansce sujet (par exemple, en raison dun niveau de vrification des logiciels excuts par cesujet) et chaque objet o possde un niveau dintgrit io(o), correspondant au niveaudintgrit du sujet qui la cr. Les oprations dobservation, de modification etdinvocation, dun sujet par un autre sujet, sont autorises si les rgles suivantes sontvrifies (en plus des rgles discrtionnaires) :

Rgle 1 : (si, oj, observer) => is(si) io(oj)

Rgle 2 : (si, oj, modifier) => io(oj) is(si)

Rgle 3 : (si, sj, invoquer) => is(sj) is(si)

Ces rgles garantissent quune information ne pourra pas polluer une information dunniveau dintgrit suprieur. Le modle de Biba prsente un inconvnient analogue celui de Bell-LaPadula, cest--dire la dgradation des niveaux dintgrit : si uneinformation dun niveau dintgrit donn est utilise par un sujet dun niveau infrieur,tous les objets modifis ou crs par ce sujet partir de cette information seront dunniveau dintgrit infrieur. Il faut alors remonter artificiellement le niveau dintgrit decertains objets par des sujets de confiance (ne respectant pas les rgles).

Clark et Wilson [Clark et al. 87] proposent un autre type de politique obligatoire pourlintgrit. Dans leur modle, les objets sont de deux classes dintgrit : les UDIs(Unconstrained Data Items, ou donnes non contraintes) et les CDIs (Constrained DataItems, ou donnes contraintes). Les CDIs sont certifies par des procdures devrification dintgrit (IVPs, Integrity Verification Procedures), et ne peuvent tremanipules que par des procdures de transformation certifies (TPs, TransformationProcedures), qui maintiennent lintgrit des CDIs. Ces TPs correspondent donc au


concept des transactions bien formes, classique en traitement transactionnel. Lesystme maintient par ailleurs des listes de relations indiquant sur quelles CDIs peuventporter les TPs et quelles TPs peut excuter chaque utilisateur. Ces listes permettent demettre en uvre la sparation des pouvoirs (que Clark et Wilson appellent separation ofduty), en ce sens que pour raliser certaines transformations, il faut que plusieursutilisateurs excutent des TPs spares, lensemble de ces TPs ralisant latransformation complte. Un mcanisme appropri permet de remonter le niveaudintgrit des objets, cest--dire la transformation dUDI en CDI. Lintgrit dusystme repose donc sur le contenu des listes de relations, et sur la validit des IVPs etdes TPs, cest--dire que, dans ce modle, il est ncessaire de certifier les programmes,en plus de vrifier les droits lexcution.

Ces politiques obligatoires pour lintgrit ont gnralement t conues pour seprmunir contre la fraude. Mais, de mme que la protection est efficace aussi bien pourprvenir des fautes intentionnellement nuisibles que pour empcher la propagationderreurs dues des fautes accidentelles, on peut envisager dappliquer des politiquesdintgrit des systmes de scurit-innocuit. En particulier, [Totel 98] propose unepolitique et un modle adapts des systmes o cohabitent des logiciels de criticitsmultiples : en associant niveau de criticit et niveau dintgrit, le modle de Totelgarantit que des traitements trs critiques (dont les logiciels auront t validsintensivement) ne peuvent tre contamins par des logiciels moins critiques (donc moinsvalids). De mme, la notion de sparation des pouvoirs permet de relever les niveauxdintgrit : par exemple, des informations, peu sres prises isolment, mais provenantde sources diversifies peuvent produire des informations de plus haut niveaudintgrit, au moyen de transformations certifies, correspondant des mcanismes detolrance aux fautes (vote majoritaire, prise de mdiane, etc.).

1.3.1.3 Politiques de contrle de flux

Les politiques de contrle de flux traient le problme des canaux cachs4 en considrant,non seulement des oprations de lecture et dcriture sur des objets, mais galement desflux dinformations entre sujets. Elles sattachent donc spcifier les canaux detransmission prsents dans le systme, prciser les canaux lgitimes et identifier lescanaux cachs.

Une approche originale pour la reprsentation des flux dinformation dans un systmeconsiste caractriser les dpendances causales qui existent, diffrents instants, entreles objets du systme [d'Ausbourg 94]. Dans ce modle, un systme est reprsent sousforme de points (o, t). Un point dsigne, non pas un objet, mais ltat dun objet o linstant t. Certains de ces points sont des entres, dautres des sorties, et tous les autresconstituent des points internes au systme. Lensemble de ces points volue avec letemps et cette volution est due aux transitions lmentaires qui ont eu lieu dans lesystme. Une transition lmentaire peut, un instant t, associer une nouvelle valeur

4 Les canaux cachs sont des moyens dtourns utiliss pour transmettre, en contournant lesmcanismes de contrle daccs, des informations entre un utilisateur autoris accder cesinformations et un autre utilisateur non-autoris.


un objet o en ce point. Cet instant et cette nouvelle valeur dpendent donc de certainsautres points antrieurs.

La dpendance causale de (o, t) vis--vis de (o, t), avec t< t est note (o, t)(o, t).La fermeture transitive de la relation (note (* ) au point (o, t) dfinit lecne de causalit en ce point : cne(o,t) = { (o, t) tel que (o, t) * (o, t) }.

Rciproquement, on dfinit le cne de dpendance dun point (o, t) comme un ensembledes points qui dpendent causalement de (o, t) : dep(o, t) = { (o, t) tel que (o, t) * (o,t) }. Les dpendances causales reprsentent la structure des flux dinformation dans lesystme. Si un sujet possde une certaine connaissance du comportement interne dusystme, il est en mesure de connatre les dpendances causales. Dans ce cas, enobservant une sortie particulire xo, un sujet s peut tre en mesure dinfrer touteinformation appartenant cne(xo). Rciproquement en altrant une entre xi d usystme, s peut ventuellement altrer tous les points appartenant dep(xi ).

Les objectifs de scurit de ce modle peuvent tre relatifs la confidentialit ou lintgrit. Soit la notation suivante :

- Obss, lensemble des points quun sujet peut observer, Obss = xoOs cne(xo) oOs est lensemble des sorties xo, du systme, observables par le sujet s ;

- Rs, lensemble des points que s a le droit dobserver ;

- Alts, lensemble des points quil peut modifier, Alts = XiAs dep(Xi) o As estlensemble des entres xi, du systme, modifiables par le sujet s ;

- Ws, lensemble des points que s a le droit de modifier dans le systme.

Le systme est considr sr vis--vis de la confidentialit si s ne peut observer que lesobjets quil a le droit dobserver, cest--dire si Obss Rs. De la mme manire, lesystme est sr vis--vis de lintgrit si s ne peut agir que sur les objets quil a le droitde modifier, cest-dire, si Alts Ws.

En considrant un ensemble de niveaux associs aux sujets et aux objets, la propritObss Rs relative la confidentialit peut tre obtenue en imposant deux rglesanalogues celles dfinies dans la politique de Bell-LaPadula :

- un sujet nest autoris observer que les objets dont la classification est dominepar son habilitation ;

- si un objet o dpend causalement dun objet o, alors la classification de o doitdominer la classification de o.

Ce modle est particulirement intressant parce quil introduit une manire originale deformaliser les flux dinformations dans un systme. Lintrt principal de cetteformalisation rside dans son aspect minimal : la notion de dpendance causale permetde dcrire de manire stricte un flux dinformations. Toutefois, les implmentations dece modle qui ont t ralises semblent limites des applications assez spcifiques.


1.3.1.4 Politique de scurit base sur les rles (RBAC)

Une politique de scurit base sur les rles (RBAC pour Role-Based Access Control)[Sandhu 96], est une alternative aux contrles daccs classiques, savoir DAC et MAC.Les politiques RBAC permettent dexprimer prcisment les politiques dautorisationdune manire qui reprsente la structure naturelle dune organisation. Un rlereprsente de faon abstraite une fonction identifie dans lorganisation (par exemple,mdecin, infirmire, etc.). chaque rle sont associes des privilges, ensembles dedroits correspondant aux tches qui peuvent tre ralises par chaque rle. Enfin, lespermissions ne sont plus associes dune faon directe aux sujets, mais travers desrles. De mme, un sujet peut jouer plusieurs rles et inversement, un rle peut tre joupar plusieurs sujets. Ainsi, si le docteur Dupont est la fois chirurgien et directeur delhpital, en tant que chirurgien, il aura le droit daccs aux dossiers mdicaux, alorsquen tant que directeur, il pourra accder aux informations administratives. Unepolitique base sur les rles est relativement facile administrer, car elle estsuffisamment souple pour sadapter chaque organisation : la dfinition des rles peutreflter prcisment la structure de lorganisation. Les rles peuvent mme trestructurs de faon hirarchique, pour simplifier encore laffectation des privilges.Ainsi, comme les chirurgiens et les gyncologues sont ncessairement mdecins, onassignera des privilges au rle mdecin, et seulement des privilges supplmentairesau rle chirurgien dune part et au rle gyncologue dautre part. Avec une politiqueRBAC, il est facile dajouter un utilisateur : il suffit de lui assigner les rles quil peutjouer dans lorganisation. De mme il est relativement facile de faire voluer les tchessuite la cration ou la modification dun objet : il suffit de mettre jour les privilgesdes rles concerns. Cependant, les politiques RBAC ont des inconvnients : dune part,elles ne permettent gnralement que de grer des permissions , pas des interdictionsexplicites ou des obligations. Dautre part, il est difficile de grer certaines permissions.Par exemple, la rgle seuls les mdecins traitants peuvent lire les informationsmdicales du dossier dun patient est difficile implmenter dans un modle RBAC :il faut soit crer autant de rles mdecin traitant du patient X que de patients, soitmettre en uvre des rgles supplmentaires dans lapplication (par exemple, la gestionde la base de donnes des dossiers mdicaux), qui ne sont pas exprimables dans lemodle RBAC.

1.3.1.5 Or-BAC (Organization-based Access Control)

Le modle Or-BAC [Abou EL Kalam 03] a t conu pour rsoudre les problmes deRBAC. Dune part, il permet dexprimer des permissions, des interdictions et desobligations, mais aussi des recommandations, concept fort utile dans le domaine de lasant par exemple. Dautre part, il permet de prendre en compte des informations decontexte dans lexpression des rgles. Les informations de contexte permettent dactiverdes rgles spcifiques (par exemple, en cas durgence), ou de restreindre lapplication decertaines rgles des conditions topologiques ou chronologiques (certaines donnes nepeuvent tre consultes qu certains endroits, ou certaines heures), ou encore aucontenu de linformation (un mdecin peut consulter un dossier mdical, sil est indiqucomme mdecin traitant dans ce dossier). Dans Or-BAC, les rgles de scurit ne sontpas spcifies pour chaque objet, sujet et action, mais seulement en utilisant les entitsabstraites suivantes :


- organisations : une organisation peut tre dfinie comme une entit ayant un rleprofessionnel ou statutaire bien dfini, ou encore, un groupe structur dentitsactives, cest--dire de sujets (utilisateurs, quipes, ou autres) jouant certainsrles ; dans le domaine de la sant, une organisation peut tre le servicedurgence dun hpital, lunit de soin intensif dun hpital , etc. ;

- rles : les rles dans Or-BAC sont lis lorganisation ; en effet, mme si lessujets peuvent jouer des rles dans diffrentes organisations, ils nont pasforcment le droit de les jouer dans nimporte laquelle de ces organisations ; parexemple prenons le cas dun utilisateur qui joue les rles mdecin et radiologue dans lorganisation A mais pas forcment radiologue ni mdecindans lorganisation B ;

- vues : une vue est considre comme un ensemble dobjets satisfaisant uneproprit commune ; elle permet alors de structurer les objets et dajouter denouveaux objets au systme ; une mme vue (qui est une entit abstraite) peutcorrespondre des objets diffrents selon lorganisation ; par exemple la vue dossier mdical peut tre dfinie comme un ensemble de documents XML dansune organisation, et comme des lments dune base de donnes dans une autre ;

- activits : par analogie aux rles qui associent les sujets ayant les mmesfonctions et aux vues qui associent les objets satisfaisant une proprit commune,une activit associe les actions qui ont des objectifs communs ; une mme activitpeut correspondre des actions diffrentes selon lorganisation ; par exemplelactivit consultation peut correspondre, dans une organisation, laction lire un fichier, mais peut correspondre laction select sur une base dedonnes dans une autre ;

- contextes : permettent de spcifier les circonstances dans lesquelles lesorganisations accordent des permissions de raliser des activits sur des vues.

ce titre, Or-BAC distingue deux niveaux dabstraction :

- niveau abstrait, o la politique de scurit est exprime en fonction des entitsabstraites dcrites ci-dessus ; une rgle de la politique de scurit peut parexemple prendre la forme suivante : Recommandation (org, r, a, v, c) qui signifieque lorganisation org, dans le contexte c, recommande au rle r de raliserlactivit a sur la vue v. Les interdictions, obligations et permissions sont dfinisdune faon analogue ;

- niveau concret, portant sur des autorisations (ou obligations ou interdictions ourecommandations) concrtes associes, dans le contexte courant, un utilisateuru, un objet o et une action a. Ces faits (permission, obligation, interdiction ourecommandation) sont dduits, un moment donn, par instanciation des rglesde la politique de scurit. Ainsi, Or-BAC est un moyen de spcifier, dans uncadre homogne, plusieurs politiques de scurit pour des organisationsdiffrentes devant cooprer.


1.3.2 Politiques et modles pour la disponibilit

Il y a eu peu de travaux dans le domaine de la scurit qui se sont intresss ladisponibilit. Pourtant elle a t largement traite dans dautres domaines tels que lasret de fonctionnement et la tolrance aux fautes vis--vis des fautes accidentelles.Selon Parker [Parker 92] la disponibilit est le moins matris et le plus ignor desobjectifs de la scurit . Nanmoins, la disponibilit reste un objectif important, surtoutdans le cas des systmes critiques au mme titre que lintgrit ou la confidentialit.

Millen [Millen 92] a identifi deux types dattaque par dni de service : lutilisation deressources (allocation) et lpuisement de ressources. Dans ce dernier cas, un attaquantpuise les ressources limites du systme pour empcher les autres utilisateurs dyaccder. Millen dfinit une base de donnes (Database Protection Base) qui rpartit lesressources aux utilisateurs et qui a le pouvoir de retirer des ressources un utilisateur silne respecte pas le temps qui lui a t accord. Cette base permet de protger le systmecontre le dni de service.

Gligor [Gligor 83] dfinit le dni de service comme lchec du systme dfinir untemps maximum dattente (Maximum Waiting Time). En fait, un utilisateur devraitpouvoir accder un service partag demand dans un temps born partir de linstanto il a mis sa requte. Le modle dfinit la notion de privilge, et cest le systmedexploitation qui doit grer cette notion pour permettre au moins au groupedutilisateurs privilgis daccder aux ressources. Par exemple, si les ressources sontlimites et le systme est incapable de servir tout le monde, les utilisateurs privilgissont servis avant les autres.

Selon Cuppens [Cuppens et al. 99, Cuppens 00], une politique de disponibilit doitrglementer la ralisation de tches et l'utilisation de ressources ncessaires pour raliserces tches. L'objectif principal de cette politique est de spcifier les temps maximauxd'attente lorsque les agents demandent accder aux ressources et des dures maximaleslorsque les agents demandent raliser des tches. Cela correspond des obligations,pour le systme, de garantir ces temps maximaux d'attente (pour l'accs aux ressources)et ces dures maximales (pour la ralisation des tches). La prise en compte d'exigencesde disponibilit dans un systme passe par la spcification d'un rglement dedisponibilit. Il propose un modle du systme comprenant les notions de ressource, detche et de sujet utilisant des ressources pour raliser des tches. Ce modle permetgalement de reprsenter la dimension temporelle de manire pouvoir spcifier lesdates de dbut et de fin ainsi que la dure de ralisation d'une tche ou d'utilisation d'uneressource en utilisant la logique temporelle.

Toutes ces tudes identifient la disponibilit vis--vis du dni de service par puisementde ressources et ne considrent pas directement le cas des fautes accidentelles oumalveillantes pouvant affecter la disponibilit. De plus, elles ne considrent que le pirecas qui est le dni de service sans prendre en compte des exigences de type qualit deservice vis--vis de la disponibilit. Les deux premires approches proposent desmcanismes pour contrler le temps dutilisation des ressources par les utilisateurs. Maisces mcanismes sont insuffisants puisquils ne permettent pas de protger le systmecontre ce type dattaques. La troisime approche intervient pour intgrer les contraintesde disponibilit dans les spcifications dun systme en cours de dveloppement. Les


prvisions de disponibilit sont faites en considrant un ensemble de ressources et unensemble de tches sans prsence de fautes. Ce modle pourrait tre tendu latolrance aux fautes et aux intrusions cest--dire lobligation, pour le systme defournir les ressources demandes (et autoriss), mme en prsence dattaques ou dedfaillances accidentelles.

1.4 Mise en oeuvre de la scurit

Traditionnellement, le dveloppement dun systme scuris est souvent bas sur leprincipe de protection forte. Lobjectif des mcanismes de protection dans un systmeinformatique est dempcher un utilisateur malintentionn de nuire aux autresutilisateurs du systme [Lampson 71]. La nuisance peut se faire de diffrentes manires :1) en dtruisant ou en modifiant les donnes dun autre utilisateur, 2) en accdant ou encopiant les donnes dun autre utilisateur sans sa permission ou 3) en dgradant laqualit du service fourni un autre utilisateur (les attaques par dni de service). Pourfaire face de tels agissements, il faut mettre en uvre des mcanismes de contrledaccs, dautorisation et des mcanismes permettant de respecter les obligations incluesdans la politique de scurit.

1.4.1 Protection centralise

Le principe de protection est bas sur la notion de TCB, il sagit dun sous-systme descurit ou base de confiance informatique dun systme informatique [TCSEC 85]. LaTCB constitue lensemble des dispositifs matriels et logiciels destins accomplir lesfonctions de scurit du systme. La figure 1.1 nous prsente un exemple de TCBincluant une matrice des droits daccs et un moniteur de rfrence qui est unintermdiaire de confiance incontournable grant tous les accs aux ressources (objetslocaux et distants) du systme et contrlant toutes interactions.

Figure 1.1 Protection centralise

Le moniteur de rfrence gre ici tous les accs aux objets distants et locaux ce qui posede srieux problmes de point de vue performance et scurit. En effet, la TCBreprsente un point dur de larchitecture et la corruption de cette TCB permet aux


attaquants de prendre le contrle total du systme. De plus, cette TCB reprsente ungoulet dtranglement puisque tous les accs doivent passer par elle.

1.4.2 L'approche du livre rouge

Lapproche de protection adopte par le NCSC (National Computer Security Center)dans le livre rouge [NCSC 87] repose sur une distribution de la TCB sur lensemble dessites du systme. Dans cette approche, chacun des sites qui composent le systmepossde une TCB. Chaque TCB est charge de contrler tous les accs aux objetslocaux, que ces accs soient effectus par des sujets locaux ou distants. Un autre pointimportant noter est que, dans cette approche, chaque TCB fait confiance aux autresTCB du systme. Lorsquun sujet S1 accde un objet distant O3, la requte esttransmise par la TCB du site o S1 est situ, la TCB qui gre les accs sur lobjet O3.Cette dernire va faire confiance lauthentification de S1 par la TCB du site 1 et vadonc vrifier les droits daccs de S1 sur lobjet O3 quelle dtient localement pourautoriser ou refuser laccs demand. Rciproquement, la TCB du site de S1 faitconfiance la vrification des droits daccs du sujet S1 effectue par la TCB du site delobjet O3. Lensemble des TCB du systme qui se font mutuellement confiance estappel Network Trusted Computing Base (ou NTCB). La scurit globale du systmerepose donc sur la scurit de cette NTCB .

Figure 1.2 Approche livre rouge

Toutefois, cette approche prsente des inconvnients, la gestion dcentralise desinformations en particulier peut poser des problmes de cohrence. En effet, la matricedes droits daccs est rpartie sur tous les sites du systme, ce qui fait que le maintien dela cohrence de la politique dautorisation est trs difficile dans une telle situation : sichaque site na besoin de connatre que ses objets locaux, il doit en revanche connatreforcment tous les sujets du systme global pour tre capable de vrifier les accs quilspourraient raliser localement. Un autre inconvnient de cette approche est galement laconfiance qui doit tre accorde tous les administrateurs de scurit de chacun dessites. En effet, si un administrateur dune TCB quelconque est corrompu, lensemble dusystme est corrompu puisque les autres TCB lui font confiance. De ce fait, lintrusiondun site donne des privilges sur dautres sites.


1.4.3 Le schma d'autorisation de MAFTIA

Nous prsentons dans cette section le schma dautorisation propos dans le cadre duprojet MAFTIA [Abghour 04]5 implmentant des serveurs dautorisation pour desapplications rparties sur Internet. Les serveurs dautorisation sont des entits tiercesdignes de confiance, capables de grer des schmas dautorisations diverses et flexibles.

Le serveur dautorisation est un lment trs sensible du systme puisque la scuritglobale du systme repose sur son bon fonctionnement. En particulier, il doit tre fiablevis--vis des fautes accidentelles et vis--vis des fautes intentionnelles : un intrus quipourrait se rendre matre de ce serveur pourrait mettre en pril la scurit du systmetout entier. Pour empcher ce scnario, des techniques de tolrance aux fautes sont misesen uvre : le serveur dautorisation est compos de plusieurs machines, administresindpendamment par des personnes diffrentes. Les informations confidentielles sontfragmentes et dissmines sur lensemble des machines, tandis que les informationsnon confidentielles sont simplement rpliques sur ces machines. Dans ce cas, le serveurdautorisation napparat pas comme un point dur du systme, puisque le contrle dunnombre limit de machines par un intrus ou par des administrateurs malveillants ne metpas en pril la scurit du systme [Deswarte et al. 02]. Le serveur dautorisation a laresponsabilit daccorder ou de refuser lautorisation pour les oprations qui vont treexcutes par les diffrentes parties impliques. Plus prcisment, le serveurdautorisation est responsable de la gestion des droits daccs sur les transactions (unetransaction est compose de diffrentes oprations excutes sur diffrents objetsdistribus). Il reoit toutes les requtes dautorisation de transactions, il les analyse, etautorise ou non chaque transaction en fonction des informations quil possde. Afin deprendre ces dcisions, le serveur dautorisation stocke une matrice dans laquelle sontdfinis les droits daccs sur les objets persistants, et gre aussi des rgles qui dcriventet gnrent les preuves dautorisation. Ces dernires permettent aux objets autorissdinvoquer des objets persistants. Si une transaction est autorise, le serveurdautorisation fournit lobjet metteur de la requte un ensemble de permissions luipermettant de prouver quil est bien autoris effectuer chacune des oprations de latransaction. Ces preuves dautorisation devront tre par la suite prsentes au moniteurde rfrence situ sur le site de chaque objet invoqu. Le modle propos implmente unschma de dlgation qui obit strictement au principe du moindre privilge.

Chaque site du systme possde un moniteur de rfrence. Ce moniteur joue deux rlesprincipaux:

- il contrle tous les accs aux objets locaux, quelque soit leur nature (cest--direpersistants ou temporaires), et

- il gre de faon autonome tous les droits daccs sur les objets locauxtemporaires.

Ce moniteur de rfrence est charg dintercepter toutes les invocations aux objetslocaux et de vrifier que chaque invocation est bien porteuse dune capacit qui autorise

5 Larchitecture complte de MAFTIA sera traite dans le chapitre 2


laccs. Cette capacit a t gnre prcdemment soit par le serveur dautorisation si larequte daccs concerne un objet persistant du systme, soit par le moniteur derfrence lui-mme, si la requte daccs concerne un objet local temporaire.

Figure 1.3 MAFTIA : schma dautorisation

La collaboration du serveur dautorisation et des moniteurs de rfrence permetdassurer une protection efficace sans existence de point dur dans le systme : chaquemoniteur de rfrence ne fait confiance quau seul serveur dautorisation qui estcompos dun ensemble de sites dont une minorit peut dfaillir sans consquence sur lesystme. Par consquent, lintrusion dun site ne donne aucun privilge sur les autressites contrairement aux approches prsentes prcdemment.

1.4.4 Autres mcanismes de scurit

Dans cette section, nous prsentons quelques mcanismes de scurit utilissgnralement comme complment de la politique de scurit mise en uvre dans lesystme.

1.4.4.1 Audit

Les Critres Communs (Common Criteria for Information Technology SecurityEvaluation) proposent un cadre pour l'audit de scurit pour les systmes dinformation.Ce modle comprend six diffrentes fonctionnalits [CC 99] : 1) rponse automatiqueaux vnements de scurit, 2) gnration des donnes de l'audit de scurit, 3) analysedes donnes de l'audit de scurit, 4) revue des vnements de scurit, 5) slection desvnements de scurit et 6) stockage des donnes de scurit.

1) Reponse automatique aux vnements de scurit : la fonction danalyse dauditde scurit doit tre capable de dtecter les vnements susceptibles dentranerune violation de la politique de scurit. Une rponse automatique de telsvnements doit les arrter (terminaison du processus suspect, dconnexion dunutilisateur, dsactivation dun service, etc.).


2) Gnration des donnes de laudit de scurit : les CC exigent la gnrationdenregistrements daudit pour le dmarrage et larrt de la fonction daudit. Lesenregistrements doivent inclure : la date et lheure de lvnement, le type delvnement, lidentit du sujet responsable de lvnement et un champindiquant sil sagit dun vnement dchec ou de succs. Il est indispensable desassurer de lintgrit des donnes daudit avant de les prendre en compte.

3) Analyse des donnes de laudit de scurit : cette fonctionnalit dfinit lesmoyens automatiques exigs pour analyser et ventuellement rpondre auxvnements suspects. Les techniques danalyse sont habituellement bases surune analyse statistique ou sur des systmes experts. Cette analyse peut servir debase la dtection dintrusion.

4) Revue des vnements de scurit : cette fonctionnalit spcifie les conditionsrestrictives donnant lieu une revue des enregistrements daudit. Il sagitprincipalement de ne permettre laccs aux enregistrements daudit quauxadministrateurs autoriss.

5) Slection des vnements daudit : dans cette partie, les CC spcifient lesconditions dinclusion ou dexclusion dvnements de lensemble desvnements audits. Les critres dinclusion ou dexclusion sont spcifis dans lapolitique de scurit.

6) Stockage des donnes de scurit : cette fonctionnalit spcifie les conditions destockage dun vnement daudit. Gnralement, ces conditions concernent laprotection des enregistrements daudit et les moyens pour assurer leurdisponibilit et intgrit et de ne pas perdre des enregistrements.

1.4.4.2 Pare-feu

Actuellement, un grand nombre de rseaux sont p

une architecture tolérante aux intrusions une architecture ... · deba, sarah khirani, malika...

Documents

Neela Chandra annonce la 3 édition du festival Indian Arts Festival 2013.pdf · Natyam sitar, tablas, flûte, atelier kolam, contes ... Page 8 mythologie hindoue, ... le jeune berger

Architecture J2EE

Architecture Architecture N tiersbliaudet.free.fr/IMG/pdf/Archi-N-tiers.pdf · 2019-04-14 · Architecture-Archi N tiers – IPI - page 10/25 Architecture 1 tier centralisé Dans

Architecture procédurale

Cours Architecture

Architecture Orientée Service (Service-Oriented Architecture)

Les tracés d’un détour : café Les Entretiens, Café Le ...€¦ · AC/IALI/E/DEBA/ LES TRACÉS D'UN DÉTOUR Café Les Entretiens, Café Le Pèlerin, Centre d'affaires Saint-Hubert,

Architecture Stalinienne

Architecture caro

Architecture des Systèmes Informatiques …alexandre.grorud.free.fr/Formation/CNAM/Architecture%20...Architecture des Systèmes Informatiques 2 Architecture des Systèmes Historique

Architecture IPTV

Architecture simbad

Architecture des réseaux NGN Architecture de réseau

Vacances L’échappée belle, loin des soucis du quotidien · La magie d’un sitar indien emplit l’atmosphère, ... a permis à Fetta Fertane d’aller vers Malika pour l’aider

CATALOGUE 2017 - benjamins-media.org · Couleurs vives sur fond noir pour le livre, tablas, harmoniums, guimbarde et sitar pour le CD, on ne sait plus si c’est le graphisme qui

Architecture android

Architecture .NET

Architecture et fonctionnement carte PC wordgerald.petitgand.free.fr/documents/architecture/Architecture et... · Architecture et fonctionnement d’une carte mère pour PC Petitgand

Filière : ARCHITECTURE ARCHITECTURE ET TECHNOLOGIE Asma

Salon du développement durable ‘ Le Tempsreenchanterlemonde.com/wp-content/uploads/2016/04/CARREFOUR-DES...La pureté du son qu [il sait tirer du Sitar musiales …. Une expérience

Dossier presse CLIMATS 7mai07 - ciup.fr Pathak, sitar, chant / Jacqui Detraz, tabla / Béatrice Mahe danseuse de Kathak / Thierry Nadalini jongleur de couleurs DU VENDREDI 8 AU DIMANCHE

Architecture générale d'un SDMM. Architecture d'un système de présentation

Architecture Décentralisée

Architecture gothique

architecture islamique

Salon du développement durable ‘ Le Temps - tapovan.com JP V20 2016 publique.pdfLa pureté du son qu [il sait tirer du Sitar nous emmène vers les plus hautes sphères ... pour

MANUEL D'UTILISATION du DÉBA-Alcool/Drogues/Jeuaqcid.com/images/Intranet/Outils/Evaluations/DEBA... · Alcool/Drogues/Jeu; Version adaptée pour la formation de la première ligne

Architecture Voip

Linking Spatial-Temporal Points, Connectiforme web SITAR est en train d’évoluer vers un système avancé et participatif d’organisation de la connaissance, au ... les applications

NUIT DES MUSÉES - static.mycity.travel · de deux musiciens – au tabla et au sitar – et d’uneconteuse 18h30, 20h,21h30 ... du Château de Gruyères, animatrices encostume

European School of Architecture Architecture & Design ... · European School of Architecture Architecture & Design Mtres Studio Sketchup Pro //01 Modelado A través del temario el

05 décembre 2005 Institut Pasteur Architecture réseau ... · Architecture des réseaux sans ﬁl JRES 2005 1 Architecture des réseaux sans ﬁl Daniel AZUELOS Architecture réseau

ZEST architecture | Architecture Studio Barcelona

magie d'un sitar indien emplit I 'atmosphère. Malika, Nadia, Meryem, Maïssa, Fadela... s'ins- tallent I'une après l'autre clans la salle

Historique et architecture générale des ordinateursecariou.perso.univ-pau.fr/cours/...historique-architecture-general.pdf · Historique et architecture générale des ordinateurs