Splunk reste un pilier de nombreux SOC. Encore faut-il passer du tableau de bord réactif à un hunting structuré. Le SPL n’est pas qu’un langage de requête : c’est un moyen de formuler des hypothèses sur le comportement adverse.
Partir d’une hypothèse, pas d’une curiosité
Un bon hunt commence ainsi :
« Si un attaquant obtient un compte privilégié, quelles traces doit-il laisser dans nos sources ? »
Puis vous déclinez cette hypothèse en signaux observables : logons anormaux, exécutions inhabituelles, accès à des parts sensibles, créations de tâches planifiées, etc.
Sans hypothèse, le hunting devient du scroll aléatoire dans les logs.
Normaliser avant d’aller loin
Avant d’écrire des SPL complexes :
- alignez les sourcetypes et CIM lorsque c’est pertinent
- vérifiez la couverture réelle (endpoints, IdP, firewall, EDR)
- documentez les champs utiles (
user,dest,src,process,parent_process, etc.)
Une recherche brillante sur des données mal normalisées produit surtout de la frustration.
Patterns SPL utiles en hunting
Quelques approches qui reviennent souvent :
- Baseline puis écart : établir le comportement normal d’un compte / host, puis chercher les outliers
- Chaînes process : corréler parent/enfant pour détecter des exécutions inhabituelles
- Fenêtres temporelles : comparer activité métier vs activité nocturne / week-end
- Pivot multi-sources : partir d’un host suspect puis élargir aux authentifications et flux réseau
Exemple de logique (à adapter à votre modèle de données) :
index=edr earliest=-7d
| stats count BY host process parent_process user
| where count < 3
| sort + countL’intérêt n’est pas la requête elle-même, mais la capacité à isoler le rare et le non conforme.
Industrialiser ce qui marche
Chaque hunt concluant doit produire un livrable :
- description de l’hypothèse
- requête SPL versionnée
- faux positifs connus et filtres
- décision : règle de détection, dashboard, ou hunt périodique
C’est ainsi que le hunting enrichit réellement la détection, au lieu de rester un exercice ponctuel.
Pièges à éviter
- Requêtes trop larges qui saturent le cluster
- Absence de time bounding clair
- Confusion entre « événement intéressant » et « incident confirmé »
- Aucune boucle de feedback avec l’IR après investigation
Conclusion
Le threat hunting Splunk efficace est méthodique : hypothèse, couverture data, SPL ciblé, validation, industrialisation. Les organisations qui progressent le plus sont celles qui traitent leurs recherches comme des actifs de détection, pas comme des scripts jetables.
Retour au blog