• 6 heures
  • Moyenne

Ce cours est visible gratuitement en ligne.

course.header.alt.is_certifying

J'ai tout compris !

Mis à jour le 21/06/2023

Collectez les données nécessaires à la détection

Au début du cours, nous avions une mission. Dans le chapitre précédent, nous l’avons déclinée en risques, puis en événements.

Maintenant, comment détecter ces événements ?

C’est ce qu’on va voir dans ce chapitre !

Consignez les événements grâce aux logs

Pour détecter les événements que l’on cherche, il faut donc pouvoir suivre ce qui se passe sur le SI.

Observer les logs

Cela se fait en observant l’état des différents composants du SI. Pour cela, on va suivre en permanence les modifications et les actions effectuées sur les différents systèmes.

Dans la pratique, cela passe par l’observation des journaux.

Les journaux (ou logs, en anglais) sont des fichiers qui consignent les événements qui ont lieu sur un système : connexion, création de fichiers, etc.

Superviser les différents systèmes du SI

Les logs sont votre meilleure source d’information pour savoir ce qui se passe sur le SI ! Pour comprendre l’état des différents systèmes du SI, collectez et observez les logs de ces machines.

Superviser les applications

En plus des logs des différents systèmes sur les différents serveurs, il y a des logs applicatifs qui sont spécifiques à l’application ou l’outil qui fonctionne sur ces serveurs. Vous devrez aussi collecter ces logs pour détecter des événements liés à l’utilisation de ces applications.

Voilà un exemple de log applicatif :

185.180.143.136 - - [14/Mar/2023:14:48:37 +0100] "GET / HTTP/1.1" 401 574 "-" "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/60.0.3112.113 Safari/537.36"
185.180.143.136 - - [14/Mar/2023:14:48:44 +0100] "GET /dana-na/../dana/html5acc/guacamole/../../../../../../../etc/services?/dana/html5acc/guacamole/ HTTP/1.1" 400 150 "-" "-"
152.89.196.54 - - [14/Mar/2023:14:50:45 +0100] "GET /index.php?s=/Index/\x5Cthink\x5Capp/invokefunction&function=call_user_func_array&vars[0]=md5&vars[1][]=HelloThinkPHP21 HTTP/1.1" 404 181 "-" "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/78.0.3904.108 Safari/537.36"
172.104.11.4 - - [14/Mar/2023:14:57:57 +0100] "\x16\x03\x01\x00\x85\x01\x00\x00\x81\x03\x03h\x81\xA4%\xFE\xA8\xC3P\x22\xA3\x0B\x1F\xE2h\xE7\x01K\xF44\x1D\xE2\xB7m\xC7:\x83\xD4\x7F\x872Lq\x00\x00 \xC0/\xC00\xC0+\xC0,\xCC\xA8\xCC\xA9\xC0\x13\xC0\x09\xC0\x14\xC0" 400 150 "-" "-"
3.131.98.176 - - [14/Mar/2023:15:06:25 +0100] "GET / HTTP/1.1" 401 574 "-" "Mozilla/5.0 (Windows NT 6.1; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/101.0.4951.41 Safari/537.36"
2.57.122.80 - - [14/Mar/2023:15:07:21 +0100] "GET /sendgrid.env HTTP/1.1" 404 118 "-" "Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:77.0) Gecko/20100101 Firefox/77.0"
2.57.122.80 - - [14/Mar/2023:15:07:21 +0100] "GET /.env HTTP/1.1" 404 118 "-" "Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:77.0) Gecko/20100101 Firefox/77.0"
2.57.122.80 - - [14/Mar/2023:15:07:21 +0100] "GET /.sendgrid HTTP/1.1" 404 118 "-" "Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:77.0) Gecko/20100101 Firefox/77.0"
193.32.162.159 - - [14/Mar/2023:15:09:06 +0100] "GET / HTTP/1.1" 200 13 "-" "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/90.0.4430.85 Safari/537.36 Edg/90.0.818.46"
193.32.162.159 - - [14/Mar/2023:15:09:16 +0100] "GET /dispatch.asp HTTP/1.1" 404 181 "-" "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/90.0.4430.85 Safari/537.36 Edg/90.0.818.46"

Détectez des événements complexes avec les équipements spéciaux

En complément des logs des différentes machines du SI, vous avez de nombreux outils qui vous offrent une vision complémentaire.

Les équipements réseaux

En premier lieu, les logs des équipements réseaux vous permettent d’identifier des actions au niveau du réseau : les connexions, leurs horaires et le volume du trafic concerné, les adresses IP et noms de domaine connectés et même, dans certains cas, le contenu du trafic.

Toutes ces informations sont récupérables dans les logs des équipements dédiés :

  • le VPN ;

  • les pare-feux ;

  • les routeurs et commutateurs (switches, en anglais).

Les équipements de sécurité

En plus des équipements réseaux, il y a déjà des outils de sécurité qui vont faire un premier niveau de détection pour vous. Contrairement aux logs systèmes, applicatifs et réseaux qui décrivent des événements, les outils de sécurité vous permettent d’agréger directement des alertes qui sont facilement exploitables pour vous !

On peut citer les outils suivants :

  • les IPS ou IDS, pour Intrusion Detection/Protection System, sont des outils qui peuvent être installés n’importe où dans le réseau, et qui vont détecter (et bloquer, pour l’IPS) des traces d’attaques ;

  • le pare-feu applicatif, ou WAF (pour Web Application Firewall) détecte les attaques dans le contenu des requêtes web. Il protège donc uniquement des sites web contre des attaques spécifiques aux sites web ;

  • vous connaissez sans doute les antivirus (AV). Ils vont détecter des menaces sur des machines, soit en comparant les programmes à des listes de logiciels malveillants connus, soit en observant leur comportement. On parle parfois d’EPP (pour Endpoint Protection Platform) dans ce cas.

Les outils de détection et de réponse

Les outils de sécurité les plus modernes se présentent directement sous la forme d’une plateforme dans laquelle les alertes sont déjà agrégées. Depuis ces plateformes, vous pouvez aussi effectuer des actions sur les différents systèmes supervisés, ce qui vous permet non seulement de détecter, mais aussi de réagir. On peut citer :

  • les EDR (pour Endpoint Detection and Response), qui fonctionnent sur le même principe que les EPP, mais mettent en plus l’accent sur la corrélation automatique entre les différentes machines. Ils peuvent utiliser des flux de données externes sur les menaces, ou des algorithmes de Machine Learning pour identifier des comportements inhabituels ;

  • les NDR, pour Network Detection and Response, sont eux au niveau des équipements réseau. Ils ajoutent aux données centralisées des flux venant des équipements que nous avons présentés ci-dessus : pare-feu, WAF, proxy, etc. Ici encore, l’intérêt est qu’un premier niveau de corrélation et de détection est réalisé automatiquement, grâce à des algorithmes modernes ;

  • les XDR, pour Extended, cette fois, vont eux aussi plus loin que les EDR en ajoutant des données venant d’outils externes ou d’applications. Par exemple, un XDR va analyser l’activité des utilisateurs dans le cloud, ou un mail suspect contenant une pièce jointe, et lier cet événement à l’ouverture du document Excel malveillant qui était en pièce jointe ;

  • les MDR : oui, ça existe, et je suis tout à fait sérieux. Cela signifie Managed Detection and Response, et il s’agit ici non pas d’un outil, mais d’un service proposé par une entreprise.

Au centre, les serveurs, la base de données, la sonde (IPS/IDS) et un pare-feu relié aux postes de travail, à l'annuaire et à l'antivirus / EDR.
La collecte des logs

Collectez et centralisez vos logs

Tous ces logs générés par les différentes machines doivent être agrégés et conservés de manière centralisée. Vous vous facilitez ainsi la vie, en évitant d’avoir à rechercher tous vos logs sur chaque équipement.

Surtout, cela permet de les protéger ! Autrement, le traitement des incidents deviendrait impossible en cas de suppression (volontaire ou involontaire). Ou encore, imaginez : si votre SI venait à être chiffré par un rançongiciel, vous perdriez alors l’accès à tous vos logs.

Priorisez l’activation de vos logs

Dans la pratique, stocker les journaux et alertes de tous les équipements du SI représente un volume bien trop conséquent ! Vous ne pourrez pas tout collecter ni conserver.

On ne peut pas non plus les conserver trop longtemps. En particulier si ces logs sont nominatifs, ce sont des données personnelles, voire sensibles. Leur conservation est alors encadrée par la loi (comme le RGPD).

Bien noté. Je me demande comment identifier ce qui est le plus important à collecter ?

Pour déterminer quels journaux activer en priorité, partez de votre analyse de risques :

  • Quels sont les systèmes pour lesquels vous avez identifié que l’arrêt ou la compromission aurait le plus d’impact ?

  • De quels systèmes dépendent-ils en termes de données, de gestion et de sécurité ?

Pour la suite, déployez la collecte progressivement, un périmètre après l’autre, une réussite après l’autre.

Mettez en place la collecte des logs

Une fois les systèmes supervisés identifiés, concevez votre architecture de collecte sécurisée. Vous avez besoin :

  • d’un serveur de collecte qui va recevoir les journaux, les parser et les normaliser pour la suite du traitement ;

  • d’un outil d’archivage sécurisé des journaux, qui va stocker les événements collectés en fonction des politiques de rétention souhaitées ;

  • d'un outil de détection (que nous présenterons dans le chapitre suivant).

Dans un second temps, mettez en place la transmission des journaux. Elle peut se faire :

  • soit via un programme installé sur les différentes machines (on parle d’agent ou de forwarder) ;

  • soit par le système lui-même qui transfère tous les logs.

L'annuaire, les outils de sécurité, les outils réseau et les ordinateurs sont connectés au collecteur de logs. L'alerte peut ensuite être archivée ou visualisée dans le SIEM
L'architecture de la collecte de logs

À vous de jouer !

Vous rejoignez le SOC de l’entreprise Méditronique. Le SOC doit détecter ces risques :

  • l’exploitation d’une vulnérabilité web ; 

  • un attaquant qui se déplace sur le réseau bureautique ;

  • un attaquant qui compromet des identifiants d’une suite bureautique dans le cloud.

Pour y parvenir, vous pouvez collecter les logs suivants sur le réseau de l’entreprise :

  • logs de l’EDR ;

  • logs système des postes de travail ;

  • logs système des serveurs ;

  • logs des pare-feux ;

  • logs des bases de données ;

  • logs du proxy web ;

  • logs des switches Wi-Fi ;

  • logs des routeurs du réseau bureautique ;

  • logs système des machines dans le cloud ;

  • logs du serveur mail ;

  • logs des applications métiers dans le cloud ;

  • logs des applications bureautiques dans le cloud ;

  • logs des connexions au cloud provider ;

  • logs applicatifs du serveur web ;

  • logs système du serveur web. 

Remplissez le tableau suivant avec les logs à collecter dans cette liste.

Événement

Log(s) à collecter

L’exploitation d’une vulnérabilité web

 

Un attaquant qui se déplace sur le réseau bureautique

 

Un attaquant qui compromet des identifiants d’une suite bureautique dans le cloud

 

Et voilà la correction !

En résumé

  • Composants réseaux, systèmes et applicatifs : chaque événement qui a lieu sur un système informatique peut être consigné dans ce qui s’appelle un journal, ou log, en anglais.

  • En complément, les composants de sécurité comme les IDS, IPS, WAF, antivirus, EPP, EDR, NDR et XRD effectuent un premier niveau d’analyse et génèrent des journaux / alertes en conséquence.

  • Pour déterminer quels journaux activer en priorité, référez-vous au socle minimal de journalisation proposé par l’ANSSI, contextualisé par votre analyse de risques.

  • Stocker les journaux et alertes prend beaucoup de place : allez-y progressivement, une réussite après l’autre.

  • Pour vous simplifier la vie et assurer la sécurité de votre système, collectez et centralisez vos journaux : disponibilité garantie, consultation simplifiée, sauvegarde et archivage facilités…

Une fois ces données collectées, comment les analyser, les lier entre elles, et si possible, de façon automatique ?

C’est l’objet du prochain chapitre !

Exemple de certificat de réussite
Exemple de certificat de réussite