Rédiger des règles de détection et des alertes SIEM

Les règles de détection sont la logique encodée dans un SIEM qui définit les conditions constituant une alerte de sécurité. Sans bonnes règles de détection, un SIEM n'est qu'un système coûteux de stockage de journaux. Des règles bien conçues identifient des comportements précis d'attaquants — bourrage d'identifiants, déplacement latéral, exfiltration de données — tout en évitant de se déclencher lors d'opérations normales. L'ingénierie de la détection est la discipline qui consiste à rédiger, tester et maintenir ces règles en continu.

Chaque règle de détection comporte des éléments essentiels. Une source de données précise quels journaux sont interrogés. Une condition de filtrage précise quels événements correspondent. Un seuil ou un schéma définit combien d'événements, ou quelle séquence, déclenche l'alerte. Les métadonnées comprennent la gravité, la correspondance avec MITRE ATT&CK, la description et la réponse recommandée. Des règles bien documentées aident les analystes à comprendre rapidement la signification d'une alerte et la manière d'y répondre lorsqu'elle se déclenche.

Chaque règle de détection établit un équilibre entre la sensibilité (détecter tous les vrais positifs) et la spécificité (éviter les faux positifs). Une règle très sensible détecte toutes les variantes d'une attaque, mais génère un volume considérable de bruit d'alerte. Une règle très spécifique se déclenche rarement, mais peut ne pas détecter de nouvelles variantes d'attaque. Une bonne ingénierie de la détection commence par une spécificité élevée afin d'établir la confiance des analystes, puis élargit progressivement la portée à mesure que l'ajustement réduit les faux positifs et que la confiance dans la règle augmente.

Les règles basées sur un seuil se déclenchent lorsque le nombre d'événements dépasse une limite au cours d'une fenêtre temporelle. Elles sont idéales pour détecter les attaques basées sur le volume, telles que la force brute, l'analyse des ports et les attaques DDoS. Paramètres essentiels : seuil de comptage (nombre d'événements), fenêtre temporelle (nombre de minutes concernées) et champ de regroupement (par IP source, par utilisateur ou par hôte). Des seuils incorrects provoquent du bruit d'alerte ou des détections manquées — ajustez-les soigneusement à l'aide de données historiques de référence.

Les règles basées sur une séquence recherchent une chaîne ordonnée précise d'événements, ce qui est idéal pour détecter les schémas d'attaque en plusieurs étapes. Par exemple : e-mail d'hameçonnage reçu THEN pièce jointe malveillante ouverte THEN PowerShell lancé par une application Office. Chaque événement peut être bénin pris isolément, mais la séquence indique une compromission. La plupart des SIEM modernes (Splunk, Sentinel, Elastic) prennent en charge la mise en correspondance de séquences avec une corrélation temporelle entre les chaînes d'événements.

Sigma est un format ouvert et indépendant des fournisseurs permettant d'écrire des règles de détection, qui peuvent être converties dans des langages de requête propres aux SIEM (SPL pour Splunk, KQL pour Sentinel, Lucene pour Elastic). La communauté de la sécurité partage des milliers de règles Sigma sur GitHub, couvrant des techniques ATT&CK courantes. L'utilisation de Sigma permet aux organisations d'adopter des détections issues de la communauté sans les réécrire manuellement pour leur plateforme SIEM spécifique, ce qui accélère considérablement la couverture de détection.

Les règles de détection doivent être testées avant leur déploiement en production. Les bonnes pratiques comprennent : des tests unitaires avec des événements synthétiques représentant à la fois des scénarios de vrais positifs et de faux positifs, des tests par rejeu utilisant du trafic légitime enregistré afin de mesurer le taux de faux positifs, et des exercices d'équipe rouge durant lesquels la règle doit se déclencher lors de simulations d'attaque contrôlées. Des outils comme Atomic Red Team fournissent de petits scripts de test qui simulent des techniques ATT&CK précises en toute sécurité.

Après le déploiement d'une règle, un ajustement continu est nécessaire. Les techniques courantes comprennent : des listes d'exclusion pour les processus ou comptes connus comme légitimes qui déclenchent normalement la règle, l'autorisation de certaines IP sources (analyseurs, outils de surveillance), l'ajustement des seuils en fonction des taux de référence observés, et l'ajout de conditions contextuelles (déclencher une alerte uniquement si l'hôte est également accessible depuis l'extérieur). Documentez chaque exclusion en indiquant sa justification afin que les futurs analystes comprennent pourquoi elle existe.

Les règles de détection doivent comporter des niveaux de gravité qui orientent la priorisation par les analystes. Niveaux courants : Critical — exploitation active, rançongiciel, compromission d'un contrôleur de domaine. High — déplacement latéral, extraction d'identifiants, communication C2. Medium — reconnaissance suspecte, violations de règles. Low/Informational — événements inhabituels, mais pas immédiatement dangereux, qui méritent d'être suivis. La gravité doit correspondre à l'impact pour l'entreprise, et pas seulement à la gravité technique.

Les règles de détection ont un cycle de vie qui doit être géré activement. Les règles deviennent obsolètes lorsque l'environnement change (déploiement de nouveaux logiciels, modification des plages d'IP) et génèrent alors des faux positifs. Elles ne détectent pas les nouvelles techniques d'attaque à mesure que les adversaires évoluent. Bonne pratique : conserver les règles dans un système de contrôle de version (git), les examiner et les mettre à jour chaque trimestre, associer chaque règle à au moins une technique ATT&CK, et mesurer l'efficacité des règles (déclenchements par semaine, taux de vrais positifs) afin de retirer ou d'améliorer celles qui sont peu performantes.

Une carte de couverture de la détection superpose les règles de détection existantes à la matrice MITRE ATT&CK afin de visualiser les lacunes de couverture. Chaque technique couverte par au moins une règle est marquée en vert ; les techniques non couvertes sont marquées en rouge. Cette représentation révèle quelles phases d'attaque (par exemple, Persistance ou Exfiltration) ne bénéficient pas d'une couverture de détection, ce qui aide les équipes à prioriser le développement de nouvelles règles. Des examens réguliers de la couverture garantissent que le programme de détection suit l'évolution des techniques adverses.

Vérifiez votre compréhension des concepts de CompTIA Security+ (SY0-701) présentés dans cette leçon.

Dans cette leçon, vous avez appris que : les règles de détection encodent des comportements précis d'attaquants sous forme de conditions d'alerte dans le SIEM, que les règles basées sur un seuil et sur une séquence répondent à différents types de schémas d'attaque, et que Sigma fournit un format portable pour partager des détections au sein de la communauté de la sécurité. Nous allons maintenant étudier UEBA et l'analyse comportementale pour détecter les menaces internes et les comptes compromis.