Formats d’échanges du MITRE

Le MITRE a initié un certain nombre de projets relatifs au développement de formats d’échanges de données relatives aux codes malveillants :

• MAEC12 (Malware Attribute Enumeration and Characterization) : information sur les logiciels malveillants et leurs caractéristiques ;

• CybOX13 (Cyber Observable eXpression) : relatif aux événements de sécurité obser-vables ;

• STIX14 (Structured Threat Information eXpression) : sur les menaces de façon plus générale que MAEC ne le permet ;

• TAXII15 (Trusted Automated eXchange of Indicator Information) est dédié au trans-port de ce type d’informations ;

Aujourd’hui, les projets CybOX, STIX et TAXII (mais pas MAEC) sont en cours de migration vers une organisation alternative, OASIS et son comité CTI16 (Cyber Threat

In-telligence). Il est difficile de comprendre les implications de cette migration, voulue

apparem-ment par beaucoup d’acteurs pour permettre d’industrialiser les process, des organisations contribuant directement à OASIS, sans dépendre du bon vouloir du MITRE.

Le concept général de ces propositions de standards est de proposer de stocker et trans-porter cette information dans des formats structurés (XML, JSON) dont la définition est partagée par la communauté.

2.2.2.1 MAEC

Malware Attribute Enumeration and Characterization (MAEC) a été créé pour stocker

et échanger de l’information sur des logiciels malveillants et notamment leur comportement, artefacts et schémas d’attaque. Trois modèles de données superposables sont définis :

11. http://blogs.technet.com/b/mmpc/ 12. http://maec.mitre.org/ 13. http://cybox.mitre.org/ 14. http://stix.mitre.org/ 15. http://taxii.mitre.org/ 16. https://www.oasis-open.org/committees/tc_home.php?wg_abbrev=cti

MAEC Bundle. Ce modèle est destiné à stocker de l’information sur un échantillon de logiciel malveillant donné, à savoir dans un ordre croissant d’abstraction : les actions qu’il réalise, les comportements (behaviors) qu’il exprime et les capacités (capabilities) dont il dispose. Un comportement peut servir à définir l’une des façons dont une capacité est mise en œuvre, tandis qu’une ou plusieurs actions décrivent la façon dont un comportement est réalisé.

Un des exemples cité dans la documentation de MAEC décrit une capacité de persistance d’un logiciel malveillant qui peut avoir comme comportement le fait de s’assurer que le code est exécuté au démarrage de la machine (par exemple, en créant une copie de l’exécutable quelque part sur le disque et/ou en créant une entrée particulière dans la base de registres).

MAEC Package. Un Sujet Malveillant (Malware Subject) contient les détails d’un

échantillon particulier de logiciel malveillant (même condensat MD5 ou SHA-1) et de toutes variations minimes observées (noms de fichier différents par exemple), avec toutes les analyses réalisées sur ceux-ci.

Un package MAEC sert à stocker l’information sur un ou plusieurs Malware Subjects normalement reliés d’une façon ou d’une autre entre eux, par exemple les fichiers créés ou téléchargés lors d’une analyse dynamique d’un échantillon donné, des variantes de la même famille ou des fichiers détectés comme similaire par un algorithme de regroupement.

MAEC Container. Un container enfin vise, pour l’instant, à regrouper un ensemble de

packages.

Vocabulaires. Un certain nombre de vocabulaires essentiels sont définis dans la

spécifi-cation du langage MAEC¹⁷. Plusieurs sont directement en rapport avec nos travaux, par exemple celui qui liste (de façon non exhaustive) une liste de capacités pour les logiciels malveillants (cf. table 2.1 page suivante).

On retrouvera ensuite, par exemple, une définition de vocabulaire pour les objectifs tac-tiques de la capacité availability violation dans :

• AvailabilityViolationTacticalObjectivesVocab-1.0 : denial of service,

compro-mise local system availability, crack passwords, mine for cryptocurrency, comprocompro-mise access to information assets ;

ou encore des objectifs stratégiques :

• AvailabilityViolationStrategicObjectivesEnum-1.0 : compromise data

availabi-lity, compromise system availability et consume system resources.

Ce sont très clairement ces définitions de vocabulaire qui sont susceptibles de compléter ou d’interagir avec nos travaux.

Enumeration Value Description

command and control Indicates that the malware instance is able to receive and execute remotely sub-mitted commands.

remote machine manipulation Indicates that the malware instance is able to manipulate or access other remote machines.

privilege escalation Indicates that the malware instance is able to elevate the privileges under which it executes.

data theft Indicates that the malware instance is able to steal data from the system on which it executes. This includes data stored in some form, e.g. in a file, as well as data that may be entered into some application such as a webbrowser.

spying Indicates that the malware instance is able to capture information from a system related to user or system activity (e.g., from a system’s peripheral devices). secondary operation Indicates that the malware instance is able to achieve secondary objectives in

conjunction with or after achieving its primary objectives.

anti-detection Indicates that the malware instance is able to prevent itself and its components from being detected on a system.

anti-code analysis Indicates that the malware instance is able to prevent code analysis or make it more difficult.

infection/propagation Indicates that the malware instance is able to propagate through the infection of a machine or is able to infect a file after executing on a system. The malware instance may infect actively (e.g., gain access to a machine directly) or passively (e.g., send malicious email). This Capability does not encompass any aspects of the initial infection that is done independently of the malware instance itself.

anti-behavioral analysis Indicates that the malware instance is able to prevent behavioral analysis or make it more difficult.

integrity violation Indicates that the malware instance is able to compromise the integrity of a system. data exfiltration Indicates that the malware instance is able to exfiltrate stolen data or perform

tasks related to the exfiltration of stolen data.

probing Indicates that the malware instance is able to probe its host system or network environment ; most often this is done to support other Capabilities and their Ob-jectives.

anti-removal Indicates that the malware instance is able to prevent itself and its components from being removed from a system.

security degradation Indicates that the malware instance is able to bypass or disable security features and/or controls.

availability violation Indicates that the malware instance is able to compromise the availability of a system or some aspect of the system.

destruction Indicates that the malware instance is able to destroy some aspect of a system. fraud Indicates that the malware instance is able to defraud a user or a system. persistence Indicates that the malware instance is able to persist and remain on a system

regardless of system events.

machine access/control Indicates that the malware instance is able to provide the means to access or control the machine on which it is resident.

Table 2.1 – Exemple de vocabulaire MalwareCapabilityEnum-1.0 – capacités d’un logiciel malveillant - défini dans la spécification du langage MAEC.

2.2.2.2 STIX

Structured Threat Information eXpression (STIX)¹⁸ constitue en quelque sorte l’étape suivante, intégratrice d’un ensemble d’informations en rapport avec l’analyse des menaces qu’on les observe du point de vue du chercheur, du responsable de la sécurité des systèmes d’information ou encore d’un enquêteur judiciaire.

L’architecture de STIX comporte huit constructeurs :

Observables. Les observables permettent de décrire événements ou propriétés

mesu-rables dans les systèmes d’information (informations sur un fichier, valeur d’une clé de registre, une requête HTTP émise, etc.).

Indicators. Les indicateurs sont une combinaison d’observables et leur contexte,

cara-céristiques d’artéfacts ou de comportements d’intérêt dans un contexte de cyber-sécurité.

Incidents. Il s’agit de représenter des instanciations d’indicateurs à un instant donné

et dans un contexte donné, éventuellement liés à des acteurs ou des objets concernés.

Tactics, Techniques and Procedures (TTP). Cette catégorie permet de décrire les

actions entreprises par les acteurs malveillants pour réaliser un objectif donné : la succession d’opérations et d’outils (dont les logiciels malveillants) utilisés pour réaliser une opération de hameçonnage ou une attaque en déni de service par exemple.

Campaigns. Une campagne décrit une série d’actions d’un acteur malveillant, réalisant

des TTP et les incidents liés.

Threat Actors. Cette catégorie permet de décrire les acteurs malveillants.

Exploit targets. Les cibles d’exploitation sont des faiblesses ou des vulnérabilités dans

un logiciel, un système d’exploitation ou un système d’information.

Courses of Action. Il s’agit ici de décrire les mesures préventives ou correctrices à

prendre face à une menace.

Confrontation à notre problématique de l’investigation des botnets. On retrouve

donc bien dans ce modèle de stockage et d’échange d’information un grand nombre d’éléments qui nous semblaient utiles pour décrire les botnets, et d’autres en plus tels que ceux liés à la réponse à ces menaces. Combiné avec MAEC, ces modèles permettraient très certainement de représenter et échanger l’information qui nous intéresse.

En revanche, le format de données utilisé par ces modèles n’est pas directement exploi-table, mais pourrait être traduit entre les parties intéressées par des échanges, comme le

propose le projet MISP¹⁹ de plate-forme d’échange d’informations sur les logiciels mal-veillants qui combine une interface humaine compréhensible (dédiée à la gestion d’incidents) et des capacités d’export et prochainement d’import, notamment de données au format STIX.

2.2.3 Autres formats de données

Une autre catégorie d’informations partagées entre les acteurs de la sécurité est constituée par les indicateurs de compromission (IOC) qui se concentrent sur la détection des traces que peut laisser un type d’incident ou de menace donnés. Toutefois, on note un certain recouvrement avec les autres formats d’échange que nous venons d’aborder.

OpenIOC est un schéma de publication d’informations de type indicateurs de compro-mission proposé par la société MANDIANT. Il apporte assez peu de différences par rapport aux modèles mis en avant par le MITRE, donc nous ne le décrirons pas.

2.2.3.1 YARA

YARA²⁰ propose des perspectives beaucoup plus intéressantes. Il s’agit de compléter la caractérisation de codes malveillants basée par exemple sur la reconnaissance de condensats par la constitutions de signatures complexes combinant différentes caractéristiques qu’on pourra tester automatiquement avec l’outil YARA. Et bien évidemment ces règles YARA peuvent être ensuite partagées²¹.

Ces règles peuvent être appliquées directement sur le fichier suspect, ou encore sur une copie de la mémoire vive, ou après prétraitement par un module complémentaire (extraction des champs de l’en-tête PE ou ELF par exemple). Peuvent être testées : des chaînes de caractères, des chaînes hexadécimales, des expressions règulières.