Détection et analyse : identifier les véritables incidents

La phase de détection et d'analyse commence lorsqu'un incident de sécurité potentiel est identifié pour la première fois et se termine lorsque la portée et l'impact sont suffisamment compris pour commencer le confinement. Le principal défi de cette phase consiste à distinguer les vrais positifs des faux positifs — une alerte générée par une activité malveillante d'une alerte déclenchée par un comportement normal mais inhabituel. Une détection efficace nécessite des outils correctement configurés, des analystes formés et des références documentées de l'activité normale.

Les incidents sont détectés par plusieurs canaux : les alertes SIEM générées par des règles de corrélation, les détections EDR issues de l'analyse comportementale sur les points de terminaison, les signalements des utilisateurs (la détection initiale la plus courante pour le Phishing), les notifications de tiers (forces de l'ordre, fournisseurs de renseignements sur les menaces, services de notification de compromission), l'analyse automatisée (analyseurs de vulnérabilités ou CSPM signalant des anomalies) et la recherche proactive de menaces (investigation proactive). Chaque source présente un niveau de fiabilité différent et fournit des types de preuves différents.

Une détection efficace nécessite de collecter des journaux provenant de sources variées. Les principaux types de journaux comprennent : les journaux d'authentification (Windows Security Event Log, /var/log/auth.log) pour les connexions échouées ou réussies, les journaux réseau (pare-feu, VPC Flow Logs, proxy) pour les connexions inhabituelles, les journaux DNS pour les requêtes vers des domaines malveillants connus, les journaux des points de terminaison (EDR, Sysmon) pour la création de processus et l'activité des fichiers, ainsi que les journaux d'audit Cloud (CloudTrail, Azure Monitor) pour les appels d'API. Un SIEM agrège et corrèle ces sources disparates.

Les analystes du SOC trient chaque jour des centaines ou des milliers d'alertes, dont la plupart sont des faux positifs — des activités légitimes qui ont déclenché une règle de détection. Un faux positif fait perdre du temps aux analystes et crée une fatigue liée aux alertes, qui conduit à écarter les menaces réelles. Un vrai positif correspond à une activité malveillante réelle. Un faux négatif est le résultat le plus dangereux — une activité malveillante qui n'a généré aucune alerte. Ajuster les règles de détection pour réduire les faux positifs sans augmenter les faux négatifs constitue une compétence essentielle dans un SOC.

Les règles de corrélation SIEM combinent plusieurs événements de journaux individuels afin d'identifier des schémas révélateurs d'attaques. Exemple : une seule tentative de connexion échouée est normale ; 100 tentatives échouées depuis la même adresse IP en 60 secondes indiquent une attaque par force brute. Autre exemple : un utilisateur qui s'authentifie depuis les US à 9 h, puis depuis la Chine à 11 h, manifeste un déplacement impossible — ce qui indique probablement un compte compromis. Des règles de corrélation efficaces équilibrent la sensibilité (détecter les attaques réelles) et la spécificité (ne pas submerger les analystes de bruit).

Pendant l'analyse, les intervenants collectent des Indicators of Compromise (IoCs) qui caractérisent l'attaque : adresses IP suspectes, noms de domaines malveillants, hachages de fichiers de logiciels malveillants, clés de registre modifiées par l'attaquant, noms de processus inhabituels ou relations parent-enfant inhabituelles, ainsi que connexions réseau anormales. Les IoCs servent à : déterminer la portée (cet IoC est-il présent sur d'autres systèmes ?), enrichir les renseignements sur les menaces, bloquer tout nouvel accès de l'attaquant et élaborer des règles SIEM pour détecter une activité similaire à l'avenir.

L'analyse de la portée répond aux questions suivantes : What systèmes sont touchés ? Quelles données ont été consultées ou exfiltrées ? Comment l'attaquant est-il entré et quand ? Les intervenants utilisent l'analyse des journaux pour reconstituer la chronologie de l'attaque, identifier le vecteur d'accès initial, répertorier tous les systèmes auxquels l'attaquant a touché (mouvement latéral) et déterminer si des données ont été exfiltrées (pics de transferts sortants, répertoires de mise en attente des données). L'évaluation de la portée guide les décisions de confinement : il est impossible de contenir ce qui n'a pas été cartographié.

Les plateformes EDR (Endpoint Detection and Response) sont le principal outil technique pour l'analyse des incidents au niveau des points de terminaison. Les données de télémétrie EDR fournissent : les arbres d'exécution des processus (quel processus a lancé quel autre), l'activité du système de fichiers, les connexions réseau par processus, les modifications du registre et la détection de l'injection en mémoire. Pendant un incident, l'EDR permet aux analystes de rechercher simultanément un IoC sur tous les points de terminaison (recherche à l'échelle de l'entreprise), d'isoler un point de terminaison compromis du réseau et de récupérer des artefacts Forensic sans toucher physiquement au système.

Les preuves réseau constituent souvent la source la plus fiable pendant l'analyse d'un incident. NetFlow et VPC Flow Logs révèlent les connexions entre les systèmes sans afficher le contenu des charges utiles — ce qui est utile pour cartographier les mouvements latéraux. La capture complète de paquets (PCAP) affiche le contenu intégral des conversations, notamment les credentials, les données exfiltrées et les commandes C2 (si le trafic n'est pas chiffré). Les journaux de requêtes DNS révèlent les communications périodiques des logiciels malveillants avec des domaines C2. Les intervenants recherchent notamment : d'importants transferts de données sortants, des connexions vers des ports inhabituels, des schémas de communication périodique (connexions régulières toutes les N secondes) et des comportements d'analyse interne.

Reconstituer la chronologie de l'attaque est essentiel pour comprendre le temps de présence (combien de temps l'attaquant était présent avant la détection), identifier le vecteur d'accès initial (afin de corriger la vulnérabilité) et préserver les preuves dans l'ordre chronologique pour les procédures judiciaires. Les chronologies sont établies en corrélant les horodatages de plusieurs sources de journaux. La synchronisation temporelle (à l'aide de NTP) est essentielle : des journaux dont l'horloge système est incorrecte créent des lacunes et des contradictions dans les chronologies, ce qui fragilise les conclusions Forensic.

Toutes les alertes ne nécessitent pas l’activation complète du CSIRT. Les analystes utilisent des critères documentés pour déterminer les déclencheurs d’escalade : la découverte d’une violation de données confirmée déclenche les notifications réglementaires obligatoires ainsi qu’une escalade auprès de la direction. La découverte d’un logiciel malveillant qui s’est propagé au-delà d’un seul système déclenche l’intervention complète du CSIRT. Un seul courriel d’hameçonnage (sans clic) reste du ressort de l’analyste de niveau 1. Des seuils d’escalade clairement définis empêchent à la fois la surréaction (gaspiller des ressources pour des événements mineurs) et la sous-réaction (laisser des violations majeures prendre de l’ampleur alors qu’elles sont traitées comme de simples alertes).

Évaluez votre compréhension des concepts de CompTIA Security+ (SY0-701) abordés dans cette leçon.

Dans cette leçon, vous avez appris que : la détection repose sur diverses sources de journaux agrégées par un SIEM, avec des règles de corrélation qui identifient les schémas d’attaque composés de plusieurs événements, les IoCs recueillis pendant l’analyse servent à définir le périmètre de l’incident sur l’ensemble des systèmes et à élaborer des règles de blocage, et les faux négatifs constituent le résultat le plus dangereux, car ils permettent aux attaquants d’opérer sans être détectés. Nous allons maintenant étudier containment, Eradication et Recovery.