Recruter un ingénieur détection : profil et évaluation

Votre SOC reçoit trop d'alertes inutiles et rate pourtant des comportements qu'il devrait voir ? Le problème tient souvent moins aux analystes qu'aux règles de détection elles-mêmes. L'ingénieur détection est le profil qui conçoit, teste et maintient ces règles. Ce guide vous aide à définir le poste, à repérer les bonnes compétences et à évaluer les candidats sur des cas concrets.

Ce que fait un ingénieur détection

Le detection engineering consiste à traiter la détection comme un produit logiciel : chaque règle répond à un besoin identifié, elle est écrite, testée, documentée, versionnée, puis mesurée et améliorée dans le temps. L'ingénieur détection est responsable de ce cycle de vie.

Ses missions habituelles :

Prioriser les comportements à détecter, à partir des menaces pertinentes pour votre organisation, des incidents passés et des retours de la chasse aux menaces.
Vérifier la collecte : les journaux nécessaires existent-ils, sont-ils bien parsés, conservés assez longtemps ?
Écrire les règles dans le langage de votre SIEM ou de votre EDR, souvent à partir de formats génériques comme Sigma.
Tester chaque règle contre une activité malveillante simulée et contre l'activité normale, pour mesurer sa capacité à détecter et son niveau de bruit.
Documenter : ce que la règle détecte, ses limites connues, la conduite à tenir pour l'analyste qui reçoit l'alerte.
Maintenir : ajuster les règles bruyantes, retirer celles qui ne servent plus, suivre la couverture par rapport à un référentiel comme MITRE ATT&CK.

Le poste se situe à la frontière entre le SOC, l'ingénierie et la connaissance des attaquants. C'est ce qui le rend précieux, et difficile à recruter.

Ingénieur détection, analyste SOC, threat hunter : bien distinguer

Ces trois rôles travaillent ensemble et se recoupent en partie. Les confondre dans une fiche de poste attire des candidats qui ne correspondent pas à votre besoin.

Rôle	Question centrale	Production principale
Analyste SOC	« Cette alerte est-elle un vrai incident ? »	Qualification et escalade des alertes
Threat hunter	« Qu'est-ce que nos outils n'ont pas vu ? »	Campagnes de chasse, hypothèses testées
Ingénieur détection	« Comment voir ce comportement de façon fiable et durable ? »	Règles testées, documentées et maintenues

Le threat hunter découvre, l'ingénieur détection industrialise. Si vous hésitez entre les deux, notre guide pour recruter un threat hunter détaille les prérequis de la chasse. Dans une petite équipe, un analyste N3 assure souvent une partie de l'ingénierie de détection : c'est une étape normale avant un poste dédié.

Quand ouvrir ce poste

Un ingénieur détection apporte le plus de valeur dans ces situations :

Vos analystes se plaignent du bruit. Une part importante des alertes est classée en faux positif, toujours pour les mêmes règles.
Vous avez déployé un SIEM ou un EDR sans personne pour l'exploiter. Les règles fournies par l'éditeur tournent telles quelles, sans adaptation à votre environnement.
Vos incidents révèlent des angles morts. Après chaque incident, vous constatez qu'aucune alerte n'a été levée alors que les traces existaient.
Vous dépendez d'un SOC managé et souhaitez garder en interne la maîtrise de ce qui est détecté, notamment pour vos applications métier.
La réglementation vous pousse à démontrer votre capacité de détection. C'est le cas pour de nombreuses entités concernées par NIS2, comme nous l'expliquons dans notre article sur les profils à recruter en priorité pour NIS2.

En revanche, si la collecte des journaux est encore lacunaire et qu'aucun processus de traitement des alertes n'existe, commencez par recruter un analyste SOC ou un ingénieur SIEM chargé de la collecte. Un ingénieur détection sans données ni analystes pour exploiter ses règles risque de s'épuiser sur des sujets qui ne sont pas les siens.

Les compétences à vérifier

La connaissance des techniques d'attaque

On ne détecte bien que ce que l'on comprend. Le candidat doit savoir décrire concrètement ce qu'une technique laisse comme traces : quel journal, quel événement, quels champs. Un bon signe : il évoque spontanément les variantes qu'un attaquant utiliserait pour contourner une règle trop étroite.

La maîtrise des données et des langages de requête

Lecture fine des journaux Windows, Linux et, selon votre périmètre, des journaux cloud et d'identité.
Aisance avec au moins un langage de requête de SIEM ou d'EDR, et capacité à en apprendre un autre rapidement.
Compréhension de la normalisation des données : un champ mal parsé rend une règle aveugle.

Les pratiques d'ingénierie

C'est ce qui distingue un ingénieur détection d'un bon analyste. Vérifiez :

l'usage d'un gestionnaire de versions (Git) pour les règles ;
l'habitude de la revue de code et des tests avant mise en production ;
le scripting (Python le plus souvent) pour automatiser les tests, les déploiements ou les enrichissements ;
l'intérêt pour une approche « detection as code », sans en faire un dogme si votre outillage ne s'y prête pas.

Le sens du compromis

Toute règle arbitre entre couverture et bruit. Le candidat doit savoir expliquer pourquoi il accepte quelques faux positifs sur un comportement critique, et pourquoi il préfère retirer une règle qui alerte cent fois par jour sans jamais rien trouver. Il doit aussi penser à l'analyste qui recevra l'alerte : une détection sans contexte ni conduite à tenir fait perdre du temps.

Les profils qui réussissent

Les ingénieurs détection viennent le plus souvent de :

l'analyse SOC N2 ou N3, avec une appétence pour l'automatisation et l'écriture de règles ;
l'ingénierie SIEM ou la sécurité système, avec une bonne maîtrise des données et des outils, à compléter par la culture offensive ;
le pentest ou la red team, pour des profils qui veulent passer côté défense et connaissent les techniques de l'intérieur ;
le développement ou le DevOps, plus rarement, pour des profils qui apportent les pratiques d'ingénierie et doivent acquérir la connaissance des attaques.

Choisissez selon ce qui manque à votre équipe. Une équipe d'analystes expérimentés gagnera à accueillir un profil plus ingénieur ; une équipe très outillée mais peu offensive gagnera à recruter un ancien pentester.

Comment évaluer un candidat

L'exercice pratique

Un entretien théorique ne suffit pas à juger la qualité d'une règle. Un exercice court, sur un environnement de lab ou un jeu de journaux réalistes, est bien plus parlant. Nous détaillons cette logique dans notre article sur l'évaluation des compétences au-delà du CV.

Un format efficace :

Décrivez une technique d'attaque précise et fournissez les journaux d'une exécution de cette technique, mêlés à de l'activité normale.
Demandez une règle de détection dans le langage de votre choix, ou en pseudo-code si le candidat ne connaît pas votre outil.
Demandez ensuite comment il la testerait, quels faux positifs il anticipe et comment un attaquant pourrait la contourner.
Terminez par une courte fiche à destination de l'analyste : que vérifier quand l'alerte se déclenche ?

Notez la démarche plus que la syntaxe. Une règle imparfaite accompagnée d'une analyse lucide de ses limites vaut mieux qu'une règle élégante dont le candidat ne voit pas les angles morts.

Les questions d'entretien

« Comment décidez-vous quelles détections écrire en premier ? » On attend une priorisation liée aux menaces, aux actifs critiques et aux incidents passés, pas une couverture exhaustive d'un référentiel.
« Une règle génère beaucoup de faux positifs. Comment procédez-vous ? » Une bonne réponse parle d'analyse des cas, d'exclusions ciblées et documentées, et de vérification que l'ajustement ne crée pas d'angle mort.
« Comment savez-vous qu'une règle fonctionne toujours six mois après ? » Le candidat devrait évoquer des tests réguliers, la surveillance de la collecte et le suivi des alertes.
« Racontez une détection dont vous êtes fier. » Cherchez un besoin clair, une méthode de test, un résultat mesurable de façon qualitative et un retour des analystes.
« Que pensez-vous des règles fournies par les éditeurs ? » Un candidat mûr y voit une base utile à adapter, ni une solution complète, ni un ensemble à ignorer.

Pour harmoniser la notation entre plusieurs intervenants, appuyez-vous sur notre guide pour structurer un entretien technique cyber.

Les erreurs à éviter

Publier une fiche de poste d'analyste SOC renommée. Si le poste consiste surtout à traiter des alertes, les ingénieurs détection le verront et ne postuleront pas.
Exiger la maîtrise d'un outil précis. Les langages de requête s'apprennent. La compréhension des attaques et la rigueur d'ingénierie, beaucoup moins vite.
Mesurer le nombre de règles. Cent règles bruyantes valent moins que vingt règles fiables. Fixez des attentes sur la qualité, la couverture des comportements prioritaires et la satisfaction des analystes.
Isoler le poste. Un ingénieur détection a besoin des retours des analystes, des threat hunters et de l'équipe de réponse à incident. Prévoyez ces échanges dès l'onboarding.
Laisser le processus traîner. Ces profils sont rares et souvent sollicités. Un calendrier d'entretiens resserré fait partie de votre attractivité.

En résumé

L'ingénieur détection transforme une collection de règles subies en une capacité de détection maîtrisée. Recrutez-le quand vos données sont disponibles et que vos analystes ont besoin d'alertes plus fiables. Évaluez-le sur sa compréhension des attaques, sa rigueur d'ingénierie et sa capacité à arbitrer entre couverture et bruit, idéalement à travers un exercice pratique.

Vous cherchez un ingénieur détection ? Chez Cyber Recrut, un recruteur et un praticien de la sécurité cadrent le poste avec vous et mènent la recherche ensemble. Nos candidats présélectionnés prouvent leurs compétences sur des labs pratiques, et vous ne payez qu'en cas de recrutement réussi. Découvrez notre méthode ou partagez votre besoin.