La lev´ee de doutes permet d’´ecarter les faux-positifs qui seraient ´eventuellement remon-t´es par le SIEM. Apr`es ce premier tri, la recherche d’informations importantes `a propos de ces ´ev`enements est ´egalement n´ec´essaire pour faciliter leur r´esolution. Enfin, des rapports d’incidents complets sont envoy´es aux personnes concern´ees.
Au cours de mon stage, j’ai ´egalement particip´e `a cette partie des activit´es du SOC de Conix afin de pr´eparer mon entr´ee dans l’entreprise `a la suite du stage.
Les ´ev`enements g´en´er´es par les IDS ou bien les alarmes cr´e´ees par les SIEM proviennent de sources de donn´ees, desquelles ils extraient des informations qui sont affich´ees dans les alertes.
Cependant, les syst`emes de d´etection d’intrusions ne poss`edent pas toujours toutes les informations n´ec´essaires `a l’appr´eciation de la criticit´e des alertes. J’ai en effet pu faire un constat simple `a propos des r`egles des IDS : la plupart d’entre eux ne basent leur d´etection que sur un motif pr´esent dans un paquet du r´eseau, sans se soucier du contexte dans lequel a ´et´e d´ecouvert ce paquet.
De nombreux faux-positifs sont obtenus de cette fa¸con, et des investigations humaines sont indispensables. Les connaissances obtenues par l’exp´erience et par le contexte m´etier du client permettent de diff´erencier les incidents r´e´els des faux-positifs. Mais il faut pour cela obtenir des informations pr´ecises sur l’intrusion d´etect´ee.
La premi`ere ´etape, lorsqu’un ´ev`enement ou une alarme sont cr´e´es, est d’obtenir plus de donn´ees concernant le contexte de d´etection.
4.3 Lev´ee de doutes 65
Au cours d’une d´etection bas´ee sur le r´eseau, des captures r´eseaux sont prises avec des outils tels que tcpdump ou Wireshark1. De cette fa¸con, il m’a ´et´e possible d’observer dans quelles conditions le trafic a ´et´e consid´er´e comme malicieux, et ainsi de pouvoir affirmer si l’alarme est dˆue `a une r´eelle intrusion ou non.
Si les ´ev`enements sont remont´es par des HIDS, il est int´eressant de lire les journaux d’´ev`enements des serveurs et services associ´es aux incidents. J’ai de ce fait pu recueillir des informations sur les actions en cours sur les applications au moment de l’« intrusion » pour d´eterminer avec plus de pr´ecision si l’alarme est un faux-positif.
Une fois que l’incident a ´et´e qualifi´e, il faut obtenir le plus d’informations possibles sur l’intrusion qui a ´et´e d´etect´ee.
Ces informations doivent ˆetre le plus exhaustives et pr´ecises possibles, afin d’assurer deux objectifs :
1. Informer les acteurs impliqu´es sur l’attaque, ses origines et ses cons´equences ; 2. Permettre une r´esolution rapide et sˆure.
Pour cela, le SOC r´edige des fiches d’incidents qui contiennent toutes ces donn´ees, et qui permettent de r´epondre `a plusieurs questions concernant l’intrusion : Qui ? Quoi ? Quand ? Comment ? O`u ?
En r´epondant `a toutes ces questions, je peux pr´esenter dans un fichier d’incident les diff´erents entit´es mises en causes, en obtenant notamment les adresses IP impliqu´ees, et si possible les noms d’hˆotes ou de domaines.
Ensuite, je peux ´egalement d´efinir le fonctionnement de l’intrusion. Si c’est une attaque lanc´ee contre un service, le payload applicatif lanc´e ou les diff´erentes ´etapes de l’attaque sont list´es. Dans le cas d’un malware, son nom, son fonctionnement ainsi que les actions malicieuses lanc´ees sont d´etaill´ees dans la fiche d’incident.
La p´eriode au cours de laquelle s’est d´eroul´ee l’intrusion est ´egalement not´ee, ainsi que la m´ethode utilis´ee.
C’est pour obtenir ces informations que des ´el´ements de contexte sont n´ec´essaires. Les logs permettent justement, sur une attaque r´eseau, d’obtenir les pr´ec´edents ´echanges entre la(les) victime(s) et l’(les) attaquant(s). Sur une intrusion utilisant un malware ou partant d’un syst`eme qui dispose d’un HIDS, ces logs ainsi que les diff´erents journaux du syst`eme permettent de retrouver des traces d’une pr´ec´edente activit´e malicieuse qui pourrait conduire `a l’intrusion en cours d’analyse.
Pour ma part, toutes les informations recueillies sont not´ees dans des fichiers textes permettant de centraliser les informations. Un exemple de mod`ele est donn´e en annexe E, page 105.
Suite `a l’obtention de ces informations, des fiches d’incidents compl`etes et d´etaill´ees sont envoy´ees aux personnes responsables de la s´ecurit´e, afin qu’ils puissent lancer les actions n´ec´essaires `a la r´esolution de ces incidents.
Ainsi, chaque fiche d’incident contient des recommandations sur les actions `a effectuer suite aux incidents relev´es.
La plupart des incidents que j’ai eu l’occasion de traiter durant mon stage ´etaient li´es `a la pr´esence de malwares sur des postes utilisateurs du syst`eme d’information client. Dans ces cas de figure, les principales recommandations sont d’effectuer des analyses anti-virus compl`etes, afin de supprimer les malwares pr´esents, et de blacklister les domaines et adresses IP contact´ees par ces malwares.
Si les intrusions proviennent de l’ext´erieur du r´eseau et visent des services du SI, nous recommandons d’appliquer les mises `a jours et patchs propos´es par les ´editeurs des logiciels utilis´es, ainsi que de proc´eder `a des audits r´eguliers afin d’´evaluer le niveau de s´ecurit´e de ces services.