Ce poste existe là où un SOC tourne sur Splunk Enterprise Security, en interne ou chez un prestataire de détection. L'ingénieur build y branche les nouvelles sources (Active Directory, pare-feu, EDR, Microsoft 365, proxy), choisit ou corrige l'add-on, vérifie que les champs collent au Common Information Model et maintient les détections. Les questions d'entretien d'ingénieur Splunk partent de cette chaîne, car une donnée mal parsée casse sans bruit toutes les règles qui la lisent.
Beaucoup de CV Splunk viennent de l'exploitation. Un administrateur qui connaît les indexeurs et le SPL n'a pas forcément touché aux data models, à l'asset and identity framework ou au risk-based alerting. Le profil inverse existe aussi, un analyste SOC habile en recherche qui n'a jamais écrit de props.conf. Les bons exemples citent le sourcetype, le data model et la détection concernés.
La version pratiquée compte aussi. Enterprise Security 8, sorti fin 2024, a changé le vocabulaire (detections, findings, investigations) et remplacé l'Investigation Workbench par l'interface issue de Mission Control, et la mise à niveau ne se défait pas. Le PDF reprend l'entretien complet en 30 questions, avec un cas de 20 minutes sur les comptes compromis.
Les briques Splunk d'une plateforme de détection
Universal forwarder et heavy forwarder
Les agents qui envoient les données vers Splunk. L'universal forwarder, léger, est installé sur les serveurs et les postes. Le heavy forwarder parse et filtre avant l'envoi, et sert souvent de point de collecte pour les API cloud. Le candidat doit savoir où se fait le parsing dans l'architecture en place.
Technology Add-ons (props.conf, transforms.conf)
Un add-on par source, qui découpe les événements, extrait les champs et les rattache au CIM. La plupart viennent de Splunkbase, certains sont à écrire ou à corriger. C'est là que se jouent la plupart des détections qui ne sonnent jamais.
Splunk Connect for Syslog (SC4S)
Le collecteur syslog conteneurisé fourni par Splunk, qui reconnaît le format de nombreux équipements réseau et sécurité et les envoie au HTTP Event Collector avec le bon sourcetype. Il remplace souvent un rsyslog maison sur les plateformes de sécurité.
Common Information Model et data models
Le CIM fixe des noms de champs communs à toutes les sources (user, src, dest, action). Les data models regroupent les événements par thème, comme Authentication, Network_Traffic ou Endpoint, et leur accélération rend les détections rapides. Sans conformité CIM, Enterprise Security ne voit pas la donnée.
Splunk Enterprise Security 8
L'application SIEM de Splunk. Elle porte les détections, l'asset and identity framework, les findings et la file d'analyse. La version 8, sortie fin 2024, a changé l'interface et le vocabulaire, et les montées de version vers la 8 ne se défont pas.
Risk-based alerting (RBA)
La méthode qui réduit le bruit du SOC. Les détections ajoutent un score de risque à un utilisateur ou à une machine au lieu de créer chacune une alerte, et un finding n'apparaît que quand le risque cumulé dépasse un seuil. Reste à savoir si le candidat l'a déjà mise en place et calibrée.
Clusters d'indexeurs et de search heads
L'architecture qui porte la charge et la disponibilité. ES demande un search head ou un cluster dédié et consomme beaucoup de calcul sur les indexeurs à cause des accélérations. Sur Splunk Cloud, une partie de ces choix est faite par Splunk, mais pas le dimensionnement des recherches.
ESCU, contentctl et Splunk SOAR
Le content pack ESCU fournit des centaines de détections maintenues par Splunk, et contentctl permet de les gérer sous forme de fichiers versionnés. Splunk SOAR automatise l'enrichissement et les premières actions de réponse à partir des findings.
On trouve ce poste dans les SOC internes des grandes organisations, chez les prestataires de détection, dont ceux qualifiés PDIS par l'ANSSI, et chez les intégrateurs qui construisent des SOC pour leurs clients. La mission mélange build (nouvelles sources, nouvelles détections, montées de version) et maintien de la plateforme, en lien étroit avec les analystes. Splunk appartient à Cisco depuis mars 2024 et beaucoup de clients passent de Splunk Enterprise à Splunk Cloud, ce qui déplace le travail de l'infrastructure vers la donnée et les détections. Pour les certifications, Splunk classe désormais l'Enterprise Security Certified Admin en legacy et propose les certifications Cybersecurity Defense Analyst, Engineer et Architect. Un CV qui cite ES sans exemple de data model ou de détection reste à vérifier.
Les points attendus d'un ingénieur Splunk ES
- Collecte et Technology Add-ons
- Conformité CIM et data models
- Détections et risk-based alerting
- Architecture et performance d'ES
- Détection as code et tests
- Run de la plateforme et lien avec le SOC
Cinq questions d'entretien pour un ingénieur Splunk sécurité
Chaque question vient avec ce qu'une bonne réponse contient et le signal qui doit vous alerter. Pas besoin d'être technique pour les poser : écoutez si le candidat raconte du vécu.
Question 1 · confirmé
Un nouveau pare-feu est indexé avec le bon sourcetype depuis une semaine, mais un tstats sur le data model Network_Traffic ne renvoie aucun de ses événements. Que vérifiez-vous ?
Une bonne réponseLe sourcetype est bon, donc il regarde ce qui fait entrer les événements dans le data model : les eventtypes et les tags (network, communicate) posés par le Technology Add-on, puis les champs CIM (src, dest, dest_port, action avec les valeurs allowed ou blocked). Il contrôle que l'index du pare-feu figure dans les contraintes d'index du CIM et que l'accélération du data model couvre cet index, puis compare un tstats avec et sans summariesonly pour savoir si le problème vient du résumé ou des données.
Signal d'alerteRelancer l'accélération sans regarder les tags. Ou réécrire les détections directement sur l'index brut du pare-feu, ce qui contourne le CIM et casse la logique d'ES.
Question 2 · senior
Le SOC reçoit 400 findings par jour, la plupart pour des comportements isolés et sans gravité. Comment passez-vous au risk-based alerting ?
Une bonne réponseLes détections bruyantes ne créent plus de finding : elles ajoutent un score de risque à un objet (utilisateur ou machine) dans l'index de risque, avec la technique MITRE ATT&CK en annotation. Une règle d'agrégation (détection basée sur les findings en ES 8, risk incident rule avant) lève un finding quand le score cumulé ou le nombre de techniques distinctes dépasse un seuil sur une période. Il calibre ces seuils sur l'historique, module le score selon la criticité de l'asset et normalise les objets de risque pour qu'un même compte ne soit pas compté sous deux noms.
Signal d'alerte« On monte les seuils » ou « on désactive les règles qui sonnent trop ». Aucune notion d'objet de risque ni d'agrégation sur une fenêtre de temps.
Question 3 · senior
Depuis l'installation d'Enterprise Security, les indexeurs tournent à 90 % de CPU, même la nuit. Où regardez-vous ?
Une bonne réponseDu côté des accélérations de data models, qui tournent en recherches planifiées sur les indexeurs. Dans la Monitoring Console, il regarde la durée de ces recherches, les data models accélérés que personne n'utilise, une plage de résumé trop longue et l'absence de contraintes d'index qui fait balayer tous les index. Viennent ensuite les détections trop fréquentes ou en temps réel, et celles qui lisent les données brutes au lieu de tstats. Il rappelle qu'ES demande davantage de capacité d'indexation par gigaoctet qu'un Splunk d'exploitation.
Signal d'alerteAjouter des indexeurs sans diagnostic, ou couper l'accélération des data models, ce qui casse la plupart des détections d'ES.
Question 4 · confirmé
Les journaux de sécurité Windows de 2 000 serveurs consomment plus de la moitié de la licence. Comment réduisez-vous le volume sans aveugler le SOC ?
Une bonne réponseIl mesure d'abord le volume par EventCode et par hôte, puis croise avec la liste des détections qui utilisent chaque code. Les codes bavards et inutilisés (par exemple 4662 ou les événements de la plateforme de filtrage Windows 5156 et 5158) sont filtrés dès l'universal forwarder dans le inputs.conf de l'add-on Windows. Il garde ce que lisent les détections (4624, 4625, 4672, 4720, 4728, 4769…) et peut retirer des champs verbeux avant l'indexation. Il fait valider la liste par le SOC avant de couper.
Signal d'alerteTout couper sauf 4625, ou filtrer sans vérifier quelles détections lisent quels événements.
Question 5 · confirmé
Trois personnes modifient les détections à la main dans l'interface d'ES. Comment les passez-vous sous Git ?
Une bonne réponseLes recherches, macros et lookups des détections vivent dans une app dédiée versionnée, avec une revue par merge request. La CI lance des tests sur des données d'attaque (le dépôt Splunk Attack Data, ou Atomic Red Team rejoué en labo), puis déploie l'app par le deployer du cluster de search heads, ou par l'Admin Config Service en Splunk Cloud. Il connaît contentctl, l'outil de Splunk qui décrit les détections en YAML. Il prévoit le cas des modifications faites dans l'interface, qui atterrissent dans le dossier local et priment sur la version déployée.
Signal d'alerteUn export manuel de temps en temps, ou « on sauvegarde le search head, ça suffit ».
Recevez la fiche d'entretien complète en PDF
La fiche pour mener l'entretien de bout en bout, prête à imprimer ou à partager avec le manager.
- 30 questions sur 6 axes, avec la bonne réponse, le signal d'alerte et la relance
- Le niveau visé pour chaque question
- Une mise en situation de 20 minutes et ce qu'on attend du candidat
- La grille d'évaluation de 1 à 4, axe par axe
Splunk Enterprise Security : les questions fréquentes
Un administrateur Splunk peut-il devenir ingénieur Splunk sécurité ?
Oui, s'il accepte d'apprendre la partie détection. Il connaît déjà les forwarders, les index et le SPL, ce qui fait gagner du temps. Il lui manque souvent le CIM, les data models, l'asset and identity framework et la logique des attaques. Une question sur une détection qui ne sonne pas le montre : un administrateur regarde la collecte, un profil sécurité regarde aussi les tags, le data model et la logique de la règle.
Quelles différences entre ingénieur Splunk ES et analyste SOC sur Splunk ?
L'analyste trie les findings, enquête et escalade. Il écrit des recherches SPL pour investiguer. L'ingénieur construit ce que l'analyste utilise : la collecte, la conformité des données, les détections, le risk-based alerting, les playbooks SOAR et la tenue de la plateforme. Les deux postes se parlent tous les jours, et un bon ingénieur SIEM a souvent fait quelques années d'analyse avant de passer au build.
Quel test technique est donné à un ingénieur Splunk sécurité ?
Un exercice d'une demi-heure sur une instance de test suffit. Le candidat reçoit des événements d'une source mal configurée, les rend conformes au CIM, puis écrit une détection en tstats sur le data model obtenu. Le candidat commente à voix haute. On voit en direct s'il sait où chercher un problème de sourcetype et s'il pense au bruit que sa détection produira.
Splunk Cloud ou Splunk Enterprise : le profil recherché change-t-il ?
En partie. Sur Splunk Enterprise, l'ingénieur gère aussi les serveurs, le dimensionnement, les clusters et les mises à jour. Sur Splunk Cloud, Splunk prend en charge l'infrastructure, mais il reste les forwarders, les add-ons, la conformité CIM, les détections, la gestion des apps via les outils de Splunk Cloud et le suivi de la consommation. La donnée et la détection, qui font le poste, ne changent pas.
Pour structurer vos autres entretiens, consultez aussi nos pages sur les questions d'entretien de recrutement, la méthode de l'entretien structuré et la grille d'évaluation d'entretien.
