DÉFENSE / INGÉNIERIE DE DÉTECTION
Une règle pour les repérer
Simulateur de création et de test d’une règle de détection.
AUTH / 165
Deux comportements, une couverture commune
Vous construisez des règles dans une console de détection simplifiée, inspirée d’un SIEM. Aucun compte ni service réel n’est modifié.
Sur Portail métier et Accès distant, détectez les rafales de mots de passe incorrects depuis l’extérieur, visant des comptes utilisateurs ou administrateurs : une source visant plusieurs comptes (pulvérisation), et plusieurs sources visant un même compte (attaque distribuée). Deux campagnes de chaque famille sont présentes dans chaque jeu.
Les journaux contiennent aussi des recettes internes, des refus MFA via le VPN d’entreprise, des rotations de secrets de comptes techniques, des comptes inconnus, des succès et des recettes sur les autres services. Ces activités sont hors de la cible annoncée. Parmi les échecs externes des comptes humains sur les services surveillés, les erreurs espacées et les petites séries restent légitimes : comparez leur rythme et leur diversité.
Ces informations de contexte sont fournies pour la simulation ; dans un environnement réel, elles doivent être vérifiées par investigation. Aucun type de compte ni origine ne suffit, seul, à qualifier une attaque.
2 pulvérisations + 2 attaques distribuées
0 épisode légitime alertéEntraînement + 4 jeux supplémentaires
Une ou deux règles, mêmes critères
01 / ENQUÊTER
Journaux d’authentification
Horodatages UTC · IP source et compte visé · Service · Résultat et motif · Origine : contexte réseau fictif fourni par l’infrastructure · Type : rôle du compte. Toutes les adresses externes sont réservées à la documentation.
Sans effet sur la règle
| HORODATAGE ↓ | IP SOURCE | UTILISATEUR | SERVICE | RÉSULTAT | ORIGINE | TYPE DE COMPTE | MOTIF |
|---|
02 / CONSTRUIRE
Vos règles de détection
Comprendre et choisir la fenêtre glissante
À chaque nouvel événement correspondant aux filtres, la règle regarde les dernières secondes pour la même IP ou le même compte, selon le regroupement choisi.
Les événements anciens sortent ; les nouveaux entrent. Le nombre d’événements ET le nombre d’éléments distincts doivent atteindre leurs seuils dans la même période.
Une fenêtre trop courte peut manquer une campagne ; trop longue, elle peut cumuler des erreurs légitimes. Le regroupement IP compte les comptes distincts ; le regroupement compte mesure les IP distinctes. Les services sélectionnés sont cumulés dans un même groupe, sans sous-groupe par service.
Comment sont comptées les alertes et les campagnes ?
La période [instant − durée, instant] inclut ses deux limites. Les événements à une même seconde sont traités ensemble. Dans chaque règle et chaque groupe, les fenêtres déclenchantes qui se chevauchent, même à leur limite, sont réunies en une alerte.
Une campagne est détectée si ses propres événements satisfont les deux seuils dans une fenêtre déclenchante. Plusieurs règles ou alertes signalant la même campagne ne comptent qu’une détection. Chaque épisode légitime présent dans les événements justificatifs d’une alerte compte une fois comme fausse alerte, même s’il est signalé plusieurs fois ou mêlé à une campagne détectée. Une alerte sans campagne correctement associée est également comptée comme bruit, une fois par épisode.
Précision = campagnes détectées / (campagnes détectées + épisodes alertés à tort). Rappel = campagnes détectées / campagnes présentes. Sans alerte : précision non définie, rappel nul et échec. Chaque jeu doit avoir quatre campagnes détectées et zéro épisode alerté à tort.
03 / COMPRENDRE
Bilan de détection
Précision : part des détections utiles parmi les détections utiles et les fausses alertes. Rappel : part des campagnes détectées. Chaque campagne et chaque épisode légitime alerté ne comptent qu’une fois.
Chaque alerte doit raconter quelque chose.
Testez vos règles pour examiner leurs événements justificatifs et les éventuelles campagnes manquées.