Détecte des anomalies d'authentification sur événements hôte

01Observe les événements hôte

lab=/tmp/soria-ir-lot2-$USER
column -s, -t "$lab/source/host/windows-auth.csv"
column -s, -t "$lab/source/host/linux-auth.csv"

Chaque ligne conserve :

event_id
timestamp
source_type
asset_id
identity_id
event_kind
outcome
remote_ip
detail

L’ID source doit rester traçable dans l’alerte dérivée.

02Construis le burst Windows

DET-AUTH-001 regroupe par identity_id :

threshold = 3
window = 300 secondes

Pour ID-ADMIN :

10:00 W-001
10:01 W-002
10:02 W-003

Le troisième événement fait atteindre le seuil dans la fenêtre.

bash module2-detection-engineering.sh run "$lab"
grep 'DET-AUTH-001' "$lab/output/host-alerts.csv"

L’alerte conserve W-001|W-002|W-003.

03Vérifie le non-match

ID-USER-01 ne possède qu’un échec Windows isolé. Le test associé attend :

NO_ALERT

Ce cas négatif est aussi important que le cas positif : il vérifie que la règle ne transforme pas chaque erreur utilisateur en alerte.

04Répète sur Linux sans mélanger les sources

DET-AUTH-002 vise linux-auth et ssh_auth_failure.

L-001
L-002
L-003
→ groupe ID-SVC-WEB
→ alerte medium

Le même principe logique s’applique, mais le logsource et la sémantique d’événement restent distincts.

05Observe un faux positif réaliste

Le compte ID-MAINT produit lui aussi trois échecs Windows pendant un test de maintenance approuvé.

La règle doit d’abord alerter :

grep 'ID-MAINT' "$lab/output/raw-alerts.csv"

Puis le contexte connu est évalué :

cat "$lab/source/tuning/known-benign.csv"
grep 'ID-MAINT' "$lab/output/false-positive-review.csv"

Disposition :

KNOWN_BENIGN

06Ne détruis pas le raw

grep 'ID-MAINT' "$lab/output/raw-alerts.csv"
! grep 'ID-MAINT' "$lab/output/tuned-alerts.csv"

Le match est exclu uniquement de la vue ajustée. La preuve que la règle a effectivement matché reste disponible.

C’est une différence fondamentale entre « tuning » et « réécriture de l’histoire ».

07Pose les bonnes questions d’analyste

Pour une alerte d’authentification, demande :

Quelle identité ?
Quel actif ?
Quelle source d'événement ?
Combien d'échecs ?
Dans quelle fenêtre ?
Depuis quelle adresse représentée ?
Y a-t-il un changement ou une maintenance connue ?
Un succès a-t-il suivi ?
Existe-t-il une corroboration réseau ou application ?

Le triage complet viendra au Lot 3.

08Connais la limite du lab

Aucun Security Event Log Windows réel, auth.log, agent Wazuh ou contrôleur de domaine n’est interrogé. Les fixtures démontrent uniquement le comportement déterministe de la règle locale.