Classes d’attaques, vulnérabilités et actions normales

L’un des objectifs de la base de connaissances est de permettre de lier les actions de l’attaquant à leurs observations. Il est donc indispensable de disposer de l’ensemble des actions à observer. Ces actions sont divisées en deux catégories qui sont les actions d’attaques et les actions normales. Nous proposons donc une description des choix de modélisation qui concernent les classes d’attaques

ainsi que les vulnérabilités qui peuvent être exploitées par ces attaques. Ensuite, les possibilités de modélisation des actions normales sur un système sont étudiées.

A Classes d’attaques

Concernant les classes d’attaque, M4D4 fournit uniquement un mécanisme d’héritage de classes d’attaque sans proposer de peuplement de cette hiérarchie par des classes d’attaques concrètes. Il reste cependant à peupler cette hiérarchie. La hiérarchie est construite autour du prédicat attack- class(K) et inherits(K’,K) pour exprimer le fait que K’ est une sous-classe directe de la classe K. Le prédicat attacksubclass(K1, K) permet de caractériser K1 comme une sous-classe (directe ou indi- recte) de K. Dans M4D4, une classe d’attaque C peut être associée à une vulnérabilité exploitée V via exploits(C,V). Cette relation permet de lier les classes d’attaques et les vulnérabilités.

Comme indiqué au paragraphe précédent, un peuplement de la hiérarchie de classes d’attaques manque. CAPEC3 _{(Common Attack Pattern Enumeration and Classification) est un point de}

départ pour l’établissement d’une hiérarchie d’action malveillantes. Les attaques y sont en effet présentées hiérarchiquement. CAPEC sert de point de départ et de référence, mais ne limite pas nos choix de modélisation. Il est possible d’ajouter ou de raffiner certaines classes, d’ajouter de nouvelles classes (aux racines ou aux feuilles), d’utiliser de l’héritage multiple pour caractériser plusieurs aspects d’une même classe d’attaque.

Le listing 3.1 donne un aperçu d’une partie des faits traduisant certaines classes d’attaques importantes issues de CAPEC. La mise en œuvre du mécanisme d’héritage est illustrée par le listing 3.2. La réalisation de ce travail est longue (CAPEC référence environ 400 classes d’attaques) mais il est seulement nécessaire de le réaliser une seule fois car cette description est indépendante du système. Par contre, il est possible d’ajouter de nouvelles catégories ou de définir des nouvelles relations d’héritage au cas par cas.

Listing 3.1 – Faits Prolog définissant des classes d’attaques adaptées de CAPEC.

a t t a c k _ c l a s s ( c o d e _ i n j e c t i o n ). a t t a c k _ c l a s s ( f i l e _ s y s t e m _ f u n c t i o n _ i n j e c t i o n _ c o n t e n t _ b a s e d ). a t t a c k _ c l a s s ( c o m m a n d _ l i n e _ e x e c u t i o n _ t h r o u g h _ s q l _ i n j e c t i o n ). a t t a c k _ c l a s s ( d a t a _ e x c a v a t i o n _ a t t a c k s ). a t t a c k _ c l a s s ( d a t a _ i n t e r c e p t i o n _ a t t a c k ). a t t a c k _ c l a s s ( s n i f f i n g _ a t t a c k s ). a t t a c k _ c l a s s ( f u n c t i o n a l i t y _ m i s u s e ). a t t a c k _ c l a s s ( a b u s e _ o f _ c o m m u n i a t i o n _ c h a n n e l s ). a t t a c k _ c l a s s ( s o f t w a r e _ i n t e g r i t y _ a t t a c k s ). a t t a c k _ c l a s s ( m a l i c i o u s _ s o f t w a r e _ d o w n l o a d ). a t t a c k _ c l a s s ( g a t h e r _ i n f o r m a t i o n ). a t t a c k _ c l a s s ( f o o t p r i n t i n g ). a t t a c k _ c l a s s ( p o r t _ s c a n n i n g ).

Listing 3.2 – Faits Prolog définissant les relations d’héritage entre les différentes classes d’attaques.

i n h e r i t s ( port_scanning , f o o t p r i n t i n g ). i n h e r i t s ( footprinting , g a t h e r _ i n f o r m a t i o n ). i n h e r i t s ( r e s s o u r c e _ l o c a t i o n _ a t t a c k s , r e s s o u r c e _ m a n i p u l a t i o n ). i n h e r i t s ( i n p u t _ d a t a _ m a n i p u l a t i o n , r e s s o u r c e _ m a n i p u l a t i o n ). i n h e r i t s ( path_traversal , r e s s o u r c e _ m a n i p u l a t i o n ). i n h e r i t s ( i n f r a s t r u c t u r e _ m a n i p u l a t i o n , r e s s o u r c e _ m a n i p u l a t i o n ). i n h e r i t s ( f i l e _ m a n i p u l a t i o n , r e s s o u r c e _ m a n i p u l a t i o n ). i n h e r i t s ( buffer_attacks , d a t a _ s t r u c t u r e _ a t t a c k ). i n h e r i t s ( in t eg er _ at ta c ks , d a t a _ s t r u c t u r e _ a t t a c k ). i n h e r i t s ( pointer_attack , d a t a _ s t r u c t u r e _ a t t a c k ). i n h e r i t s ( p r i v i l e g e _ e s c a l a t i o n , e x p l o i t a t i o n _ o f _ p r i v i l e g e _ t r u s t ). 3. http ://capec.mitre.org/

3.2. ENRICHISSEMENT DES ÉLÉMENTS DE LA BASE DE CONNAISSANCES 57

B Vulnérabilités

Les vulnérabilités sont caractérisées dans M4D4 par le prédicat vulnerability(V), qui affecte une configuration logicielle C (affects(V, C)). Cette configuration logicielle vulnérable C est définie par les logiciels S qui la composent (takespartin(S, C)). M4D4 définit la règle not_vulnerable(H,V) qui exprime le fait que le nœud H n’est pas vulnérable à la vulnérabilité V si toutes les configurations affectées par V mettent en jeu au moins un produit non présent sur H. Cette règle implique une comparaison qui dépend fortement de la sémantique des numéros de versions de logiciels.

Dans notre approche, la connaissance de ces vulnérabilités permet principalement d’éliminer les signatures d’IDS qui détectent des attaques ciblant des vulnérabilités n’affectant pas une machine donnée.

C Actions normales

Une action normale correspond à une action qui, lorsqu’elle est prise individuellement, est légitime mais peut également constituer un maillon d’un scénario d’attaque. Il est donc important de les modéliser au même titre que les actions qui correspondent à des classes d’attaques. Différents dictionnaires ou taxinomies existent pour décrire les événements normaux qui peuvent survenir dans un système.

C.1 CEE (Common Event Expression)4 _{est un standard ayant pour objectif la normalisation}

des journaux d’événements. Une taxinomie est définie et contient une liste des différentes actions que l’on retrouve usuellement sur des systèmes. Ces noms d’actions permettent de caractériser des actions de type lectures/ écritures (read/ write/ modify/ copy/ execute/ access/ move), des actions d’authentifications (login/ logout), des actions mettant en jeu les connexions réseaux (upload/ download/ initiate / connect/ disconnect), des actions sur l’environnement (install/ uninstall/ update/ suspend) ou sur des services (start/ stop). Il faut cependant noter que toutes ces actions n’ont pas la même granularité. Par exemple, l’action access peut être un read, write ou un exec, un move peut être décomposé en un copy et delete.

C.2 CYBOX (Cyber Observable Expression)5

propose également une énumération d’actions standard (cyboxVocabs :ActionNameEnum). Les noms d’actions proposés sont à un niveau d’abs- traction très bas (getSystemTime, getLibraryHandle, getFileAttributes, create Thread. . . ) qui ne sont pas nécessairement pertinents pour un processus de corrélation d’alertes de haut niveau. De plus, ces actions ne sont pas hiérarchisées et sont donc présentées à plat. Par contre, il existe éga- lement une metaclasse cyboxVocabs :ActionTypeEnum qui recense des types d’actions. Ces actions sont plus génériques et sont comparables à celles issues du dictionnaire d’action de CEE. Le type cyboxVocabs :EventTypeEnum énumère les types d’événement d’un point de vue le leur origine (Re- gistry Ops, Service Mgt, DNS lookup, HTTP Traffic, Authentication Ops. . . ). Le modèle recense également (dans cyboxVocabs :EventTypeEnum) les types d’outils pouvant générer des observables (NIDS, NIPS, HIPS, Firewall, Router, Proxy, Gateway, SIM, Vulnerability Scanner. . . ).

C.3 XDAS (Distributed audit service)6

est un standard ayant pour objectif de définir un for- mat pour les rapports d’événements. Ce standard propose une taxinomie incluant des actions de gestions de comptes (création, activation, suppression, modification), des actions liées à la gestion des sessions (création, fermeture), à la gestion d’objets (création, suppression, requête, modifica- tion), à la gestion des services (installation, activation, désactivation, invocation, requête. . . ), à la gestion des accès à une ressource ou encore aux événements exceptionnels (démarrage du système, corruption, épuisement d’une ressource).

C.4 Choix du dictionnaire d’actions Au vu des différents formalismes et dictionnaires dis- ponibles pour caractériser les actions normales d’un système, nous proposons d’utiliser la liste des actions du dictionnaire de CEE qui semble être à la fois la plus pertinente du point de vue du

4. http ://cee.mitre.org 5. https ://cybox.mitre.org

niveau d’abstraction utilisé et qui offre un bon compromis entre exhaustivité et complexité. De plus, ce choix permet de construire une base d’actions normales et ne doit pas être limitatif. Il est donc possible d’étendre ce dictionnaire avec de nouvelles actions si nécessaire. Une action normale est définie par le prédicat action_class(A). Le listing 3.3 illustre le résultat de cette modélisation pour quelques actions.

Listing 3.3 – Faits Prolog définissant des actions normales issues de CAPEC.

a c t i o n _ c l a s s ( write ). a c t i o n _ c l a s s ( read ). a c t i o n _ c l a s s ( i n i t i a t e ). a c t i o n _ c l a s s ( login ). a c t i o n _ c l a s s ( logout ). a c t i o n _ c l a s s ( logout ). a c t i o n _ c l a s s ( connect ). a c t i o n _ c l a s s ( install ). a c t i o n _ c l a s s ( u n i n s t a l l ). a c t i o n _ c l a s s ( start ). a c t i o n _ c l a s s ( stop ). a c t i o n _ c l a s s ( upload ). a c t i o n _ c l a s s ( d o w n l o a d ).

Discussion Le choix de CAPEC comme référence pour constituer une hiérarchie de classes d’attaques a comme avantage de fournir un ensemble de données important. Cependant, certains choix de classification sont critiquables. Par exemple, les classes racines peuvent représenter des domaines d’attaques ou bien des mécanismes d’attaques, ce qui rend la recherche d’une classe d’at- taque donnée non intuitive. De même, il est intéressant de pouvoir identifier des classes d’attaques non pas selon leurs domaines d’appartenance ou selon les types de mécanismes mis en œuvre, mais par leurs effets (exécution de code arbitraire, élévation de privilège). Il faut alors considérer CA- PEC comme un point de départ qui peut être étendu en fonction des besoins. Par exemple, l’ajout d’une nouvelle classe racine modélisant les attaques permettant d’exécuter du code arbitraire permet d’ajouter une relation d’héritage entre cette classe nouvellement introduite les classes d’attaques pertinentes.

Cette sous-section a présenté les éléments de modélisation des actions possibles pour un attaquant sur un système. Certaines actions sont usuellement considérées comme normales en dehors de tout contexte alors que d’autres sont directement identifiables comme malveillantes. Dans chacun des cas, un dictionnaire de référence a été sélectionné pour permettre de nommer une action. La sous-partie suivante présente la modélisation des éléments de détection susceptibles de détecter la réalisation de ces différentes actions.