Chapitre 4.2 Quiz - SIEM, SOAR et ingenierie de detection
Mode Quiz - Toutes les reponses sont masquees. Tentez chaque question avant de reveler la reponse.
Question 1
Une regle Sigma se declenche 300 fois par jour dans votre environnement, mais apres examen par les analystes, seulement 3 de ces alertes sont de vrais positifs. Calculez le taux de faux positifs, expliquez l'impact operationnel et decrivez l'approche de reglage correcte sans eliminer la couverture des vrais positifs.
Reveler la reponse
Reponse :
Calcul :
Total des alertes : 300/jour
Vrais positifs : 3/jour
Faux positifs : 297/jour
TFP = FP / Total = 297/300 = 99%
TVP = TP / Total = 3/300 = 1%
Precision = TP / (TP + FP) = 3/300 = 0,01 (1%)
Impact operationnel : Un analyste recevant 300 alertes/jour passe environ 1-2 minutes par alerte = 5-10 heures/jour sur cette seule regle. A 99% de TFP, les analystes commenceront a l'ignorer - la fatigue des alertes signifie que les 1% de vraies detections sont manques. C'est pire que de n'avoir aucune regle car cela degrade activement la reactivite du SOC.
Approche de reglage correcte - preserver la couverture TVP tout en reduisant le volume FP :
# Etape 1 : Analyser le modele FP - qu'ont en commun les 297 FP ?
# Exemple de resultat : tous les FP proviennent du compte svc-deploy executant des scripts SCCM
# Etape 2 : Ajouter un filtre cible dans la regle Sigma
detection:
selection_powershell:
Image|endswith: '\\\\powershell.exe'
selection_download:
CommandLine|contains:
- 'DownloadString'
- 'WebClient'
filter_known_good:
User|contains:
- 'svc-deploy' # Compte d'automatisation SCCM
- 'svc-wsus' # Compte de mise a jour WSUS
CommandLine|contains:
- 'WindowsUpdate' # Chemin de script connu
- 'SCCMInstall'
condition: selection_powershell and selection_download
and not filter_known_good
# Etape 3 : Valider - executer la regle modifiee sur 30 jours de donnees historiques
# Compter FP et TP - confirmer la reduction sans perdre la couverture TP
# Etape 4 : Si TFP encore eleve, envisager la conversion en score de risque
# Plutot qu'une alerte, ajouter un score de risque a l'entite
# Alerter uniquement quand le score de risque cumule depasse le seuil
Principe cle : Ne jamais supprimer largement (ex. : exclure tous les comptes svc-*). Supprimer specifiquement et documenter chaque suppression avec une date d'expiration pour revision.
Question 2
Vous redigez une detection EQL de sequence pour une chaine de processus "PowerShell - cmd.exe - net.exe". Elle ne se declenche aucune fois en 30 jours malgre les preuves provenant du renseignement sur les menaces que cette technique est utilisee dans votre industrie. Quelles sont les quatre raisons possibles pour zero detection, et comment diagnostiquez-vous chacune ?
Reveler la reponse
Reponse :
Raison 1 - Les evenements de creation de processus ne sont pas collectes
La defaillance la plus courante. L'ID d'evenement 4688 (creation de processus) requiert un changement de politique d'audit qui n'est pas active par defaut.
# Diagnostiquer : verifier si des evenements 4688 existent dans votre index
# KQL Elastic :
event.code:4688 | count
# Si zero - politique d'audit non configuree
# Correction : activer via GPO
# Config Ordinateur - Parametres Windows - Parametres de securite -
# Politique d'audit avancee - Suivi detaille - Auditer la creation de processus - Succes
# ET activer la ligne de commande :
auditpol /set /subcategory:"Process Creation" /success:enable
reg add "HKLM\\\\SOFTWARE\\\\Microsoft\\\\Windows\\\\CurrentVersion\\\\Policies\\\\System\\\\Audit" /v ProcessCreationIncludeCmdLine_Enabled /d 1
Raison 2 - Journalisation de la ligne de commande desactivee
L'evenement 4688 peut exister mais le champ process.command_line est vide car la journalisation de la ligne de commande requiert une cle de registre separee.
# Diagnostiquer : trouver les evenements 4688 avec CommandLine vide
event.code:4688 AND NOT process.command_line:*
# Si beaucoup de resultats - journalisation de la ligne de commande desactivee
# Correction : cle de registre ci-dessus + Sysmon comme source alternative
Raison 3 - Les attaquants utilisent un contournement direct parent-enfant (creux de processus, injection)
Si l'attaquant s'injecte dans un processus existant ou utilise l'instanciation d'objet COM, la chaine de processus ne correspond pas a powershell.exe - cmd.exe. L'attaque se produit mais la relation parent-enfant est differente.
# Diagnostiquer : rechercher net.exe avec des parents inattendus
event.code:4688 AND process.name:net.exe
| stats count by process.parent.name
# Si net.exe spawne par svchost, explorer, etc. - injection contournant la chaine
# Correction : ajouter une detection supplementaire pour net.exe spawne par tout parent inhabituel
Raison 4 - maxspan EQL trop court ou inadequation du nom de champ
La fenetre maxspan EQL peut etre plus petite que le timing reel de l'attaque, ou les noms de champs peuvent ne pas correspondre a votre mapping ECS.
# Diagnostiquer : executer chaque etape independamment
process where process.name == "powershell.exe" # Cela correspond-il a quelque chose ?
process where process.name == "cmd.exe" and process.parent.name == "powershell.exe"
# Si l'etape 1 correspond mais pas l'etape 2 - probleme de nommage de champ
# Verifier les noms de champs reels dans votre index :
GET logs-*/_mapping/field/process.parent.name
# Peut necessiter : winlog.event_data.ParentProcessName au lieu de process.parent.name
# Augmenter maxspan et tester :
sequence with maxspan=10m # Etait 2m - etendre pour les attaquants lents
Lecon operationnelle : Testez chaque regle de detection avec Atomic Red Team immediatement apres l'ecriture. Une regle qui n'a jamais ete validee contre une execution reelle a une couverture inconnue.
Question 3
Decrivez le playbook SOAR complet qui devrait s'executer automatiquement lorsqu'une alerte de Kerberoasting se declenche. Listez chaque etape, quelles donnees sont collectees, quelles actions automatisees sont prises et a quel point l'escalade humaine est requise.
Reveler la reponse
Reponse :
Declencheur : Evenement 4769 avec TicketEncryptionType=0x17 (RC4) depuis un compte non-ordinateur, > 3 comptes de service en 5 minutes depuis la meme IP source.
Etapes du Playbook Automatise :
Etape 1 - Enrichir l'identite source (automatise, ~30 secondes)
────────────────────────────────────────────────────────────────
ENTREES : source_ip, source_user depuis l'alerte
ACTIONS :
- Resoudre IP en nom d'hote via les journaux DHCP
- Interroger AD : obtenir les details complets du compte (groupes, dernier changement de MDP, MFA inscrit)
- Interroger EDR (CrowdStrike/Defender) : obtenir le processus qui a fait la requete Kerberos
- Etait-ce klist.exe, Rubeus.exe, GetUserSPNs.py, ou une application legitime ?
- Verifier l'inventaire des actifs : s'agit-il d'un poste de travail gere ou non gere ?
- Recherche de renseignement sur les menaces : cette IP est-elle apparue dans des incidents anterieurs ?
SORTIE : Profil source enrichi attache au cas
Etape 2 - Evaluer les comptes de service cibles (automatise, ~60 secondes)
────────────────────────────────────────────────────────────────────────────
ENTREES : liste des valeurs ServiceName depuis les evenements 4769
ACTIONS :
- Interroger AD pour chaque compte SPN cible :
- Est-ce un gMSA ? (mot de passe 240 caracteres - crackage infaisable - urgence plus faible)
- Quand le mot de passe a-t-il ete reinitialise en dernier ?
- A quels systemes ce compte a-t-il acces ?
- Est-ce un compte a hauts privileges (DA, EA, admin) ?
- Reference croisee : le hachage a-t-il ete vu dans les bases de donnees de violations connues ?
SORTIE : Notation de risque par compte cible (CRITIQUE si DA/EA, ELEVE sinon)
Etape 3 - Decision de confinement (automatise avec conditions)
───────────────────────────────────────────────────────────────
SI processus = outil malveillant connu (Rubeus.exe, GetUserSPNs.py) :
- AUTOMATISE : Isoler l'hote via EDR (isolation reseau, pas d'arret complet)
- AUTOMATISE : Desactiver le compte source temporairement (reactivation auto apres 4 heures)
- ESCALADER IMMEDIATEMENT au Niveau 2
SI processus = inconnu/suspect mais non confirme malveillant :
- AUTOMATISE : Bloquer l'IP source au pare-feu interne
- ESCALADER au Niveau 1 pour revision dans les 15 minutes
SI processus = legitime connu (SQL Server, IIS demandant son propre SPN) :
- JOURNALISER et FERMER comme faux positif
- Ajouter a la liste d'exceptions de la regle
Etape 4 - Forcer la reinitialisation des mots de passe des comptes cibles (humain requis)
───────────────────────────────────────────────────────────────────────────────────────────
PREPARATION AUTOMATISEE :
- Generer un ticket de reinitialisation de mot de passe dans ServiceNow/Jira
- Joindre la liste des comptes cibles avec l'age actuel du mot de passe
- Marquer les comptes necessitant une reinitialisation prioritaire (hauts privileges, ancien MDP)
ACTION HUMAINE REQUISE :
- Verifier que la reinitialisation ne brisera pas les services dependants avant execution
- Reinitialiser les mots de passe des comptes cibles (le hachage RC4 est maintenant invalide)
- Pour gMSA : declencher la rotation (automatise, mais l'humain doit approuver)
- Documenter quels comptes ont ete cibles dans le registre IR
Etape 5 - Pivot de chasse (automatise, s'execute en arriere-plan)
──────────────────────────────────────────────────────────────────
ACTIONS :
- Interroger SIEM : cette IP/utilisateur source a-t-il effectue un mouvement lateral reussi
dans les 24 heures suivant la tentative de Kerberoasting ?
- Chercher 4624 type de connexion 3 depuis l'IP source vers de nouveaux hotes
- Chercher de nouvelles demandes de tickets de service (4769) pour les SPN a haute valeur
- Interroger EDR : nouveaux processus, connexions reseau ou ecritures de fichiers
depuis l'hote potentiellement compromis ?
- Si evidence de mouvement lateral trouvee - escalader immediatement
SORTIE : Chronologie de l'activite de l'attaquant attachee au cas
Declencheurs d'escalade humaine :
- Outil malveillant confirme identifie
- Compte DA/EA etait cible
- Evidence de mouvement lateral detecte
- Le compte source est privilegie (personnel IT, compte de service avec droits admin)
- Plusieurs hotes affectes simultanement (comportement de type ver)
MITRE ATT&CK : T1558.003 (Kerberoasting), T1078 (Comptes valides), T1021 (Services distants)
Question 4
Vous executez le test Atomic Red Team T1003.006 (DCSync) contre un DC de laboratoire et verifiez votre SIEM Elastic. Aucune alerte ne se declenche. En parcourant la chaine de detection, identifiez les trois points de defaillance les plus probables et la commande de diagnostic pour chacun.
Reveler la reponse
Reponse :
Point de defaillance 1 - Politique d'audit avancee Windows : Acces DS non active
DCSync genere l'ID d'evenement 4662 (Acces aux services d'annuaire) uniquement quand "Auditer l'acces aux services d'annuaire" est active. Cette sous-categorie n'est pas activee par defaut, meme sur les DC.
# Diagnostiquer : verifier la politique d'audit actuelle sur le DC
auditpol /get /subcategory:"Directory Service Access"
# Si "Aucun audit" - les evenements ne sont pas generes quelle que soit la configuration SIEM
# Correction :
auditpol /set /subcategory:"Directory Service Access" /success:enable /failure:enable
# Ou via GPO : Config Ordinateur - Politique d'audit avancee - Acces DS - Auditer l'acces aux services d'annuaire
# Verifier : re-executer le test Atomic, puis verifier l'Observateur d'evenements Windows
Get-WinEvent -FilterHashtable @{LogName='Security'; Id=4662} -MaxEvents 10
Point de defaillance 2 - Agent Elastic / Winlogbeat ne collectant pas le journal Securite en volume suffisant
Meme avec la politique d'audit activee, le collecteur peut supprimer des evenements en raison d'un debordement de tampon, d'une limitation de debit ou d'une mauvaise configuration du canal.
# Diagnostiquer : verifier si des evenements 4662 existent dans Elastic (independamment de la regle)
# Kibana Dev Tools :
GET logs-system.security-*/_count
{
"query": {
"term": { "winlog.event_id": "4662" }
}
}
# Si count = 0 - probleme de collecte
# Verifier les journaux de l'Agent Elastic sur le DC :
# Windows : C:\\\\Program Files\\\\Elastic\\\\Agent\\\\data\\\\elastic-agent-*\\\\logs\\
# Chercher : "event dropped", "queue full", "failed to publish"
# Correction : augmenter la taille du journal Securite
wevtutil sl Security /ms:1073741824 # Definir la taille max a 1Go
Point de defaillance 3 - Inadequation du mapping de champ Sigma/EQL
La regle de detection fait reference a winlog.event_data.ObjectType mais le champ reel dans l'index Elastic peut etre winlog.event_data.Properties ou formate differemment par le pipeline d'ingestion.
# Diagnostiquer : trouver les noms de champs reels pour un evenement 4662 connu
# Confirmer d'abord qu'un 4662 existe (depuis le test manuel) :
Get-WinEvent -FilterHashtable @{LogName='Security'; Id=4662} -MaxEvents 1 |
Format-List *
# Puis dans Kibana - trouver le document brut et inspecter les noms de champs :
GET logs-system.security-*/_search
{
"query": {"term": {"winlog.event_id": "4662"}},
"size": 1,
"_source": true
}
# Inspecter le document retourne - comparer les noms de champs reels avec votre regle
# Inadequation courante : la regle verifie winlog.event_data.ObjectType contient "domainDNS"
# mais le champ reel est : winlog.event_data.ObjectClass = "domainDNS"
# Correction : mettre a jour la regle Sigma pour correspondre aux noms de champs reels
Tableau de synthese :
| Point de defaillance | Symptome | Commande de diagnostic |
|---|---|---|
| Politique d'audit non activee | Evenements 4662 absents de l'Observateur d'evenements | auditpol /get /subcategory:"Directory Service Access" |
| Collecte non fonctionnelle | 4662 absent du SIEM malgre sa presence dans l'Observateur | Requete de comptage Elastic pour event_id:4662 + journaux agent |
| Inadequation du nom de champ | 4662 dans le SIEM mais la regle ne se declenche jamais | Inspection du document brut dans Kibana Dev Tools |
MITRE ATT&CK : T1003.006 (DCSync) - cet exercice valide que votre detection pour le dump d'identifiants fonctionne reellement de bout en bout.
Fin du Quiz 4.2 - SIEM, SOAR et ingenierie de detection