Questions d'entretien ingénieur SIEM Elastic, de Fleet aux règles EQL

Un ingénieur Elastic Security construit le SIEM sur la suite Elastic et le tient en état. Il déploie Elastic Agent par Fleet, écrit les pipelines d'ingestion qui ramènent pare-feu, Active Directory, Microsoft 365 ou proxy au schéma ECS, active et règle les règles de détection, et surveille que chaque source envoie bien ses journaux. Les questions d'entretien d'ingénieur SIEM sur Elastic partent de ce périmètre, qui se situe entre le build SOC et l'exploitation.

Le marché mélange deux profils sous le libellé ELK. L'administrateur Elasticsearch connaît les shards, la JVM et le cycle de vie des index, mais n'a parfois jamais écrit une règle EQL. L'analyste SOC sait lire une alerte dans Kibana, sans savoir pourquoi un champ mal typé rend une règle muette. Le poste demande les deux moitiés. Le candidat décrit une source réellement intégrée de bout en bout, du syslog brut jusqu'à la première alerte.

Le niveau se voit vite sur les détails d'exploitation : une exception posée sur un nom de processus, un look-back oublié, un contrôleur de domaine muet depuis la veille. Le PDF reprend l'entretien complet sur six axes, avec un cas de migration de SIEM et une grille de notation.

La stack Elastic qu'un ingénieur SIEM fait tourner

Elastic Agent et Fleet

Un agent unique installé sur les postes et les serveurs, piloté depuis Kibana par Fleet. Les intégrations (Windows, System, Microsoft 365, pare-feu) se rangent dans des politiques par type de machine. Le Fleet Server fait le lien entre les agents et le cluster et doit être dimensionné pour le parc.

Pipelines d'ingestion

Les traitements appliqués à chaque document avant indexation : découpage du message, conversion des dates, renommage des champs. Chaque intégration livre ses pipelines et prévoit un point d'extension (logs-<dataset>@custom) pour les ajouts locaux. C'est là que se règle la qualité des données vues par les règles.

Elastic Common Schema (ECS)

Le schéma de champs commun à toutes les sources : source.ip, user.name, process.name, event.category. Les règles prédéfinies et les vues de l'application Security s'appuient dessus. Une source mal normalisée ne déclenche rien, sans message d'erreur.

Règles de détection

Elastic Security propose sept types de règles : requête personnalisée, seuil, corrélation d'événements (EQL), ES|QL, indicator match, new terms et machine learning. Plusieurs centaines de règles prédéfinies sont maintenues par Elastic. Le travail consiste à choisir celles qui correspondent aux sources présentes, puis à les régler.

EQL et ES|QL

Deux langages de requête propres à Elastic. EQL décrit des séquences d'événements ordonnés, par exemple un processus suivi d'une connexion réseau sur le même hôte. ES|QL enchaîne filtres, calculs et agrégations, utile pour compter des échecs de connexion par utilisateur.

Elastic Defend

L'EDR d'Elastic, déployé comme une intégration de l'agent. Il fournit une télémétrie détaillée des processus, fichiers et connexions, des protections contre les malwares et, selon l'abonnement, des actions de réponse comme l'isolement d'un poste. Certaines organisations gardent un autre EDR et n'utilisent Elastic que comme SIEM.

Alertes, timeline et cas

Les alertes sont stockées dans un index dédié par espace Kibana. Les analystes les traitent avec l'arbre de processus, la timeline et les cas, qui regroupent alertes et notes. L'ingénieur configure ces outils et les droits qui vont avec.

Niveaux de données et cycle de vie

Les données passent d'un niveau rapide (hot) à des niveaux moins chers (warm, cold, frozen) selon une politique de cycle de vie. Le niveau frozen s'appuie sur des searchable snapshots dans un stockage objet. Ce choix fixe le coût de la rétention et la vitesse des recherches historiques.

Le poste existe chez les organisations qui ont choisi la suite Elastic pour leur SIEM, auto-hébergée ou sur Elastic Cloud, et chez les prestataires qui exploitent un SOC pour leurs clients. Dans un projet de build, l'ingénieur intègre les sources et pose les premières règles. En run, il règle le bruit, suit les sources muettes et monte les versions. Les prestataires qualifiés PDIS par l'ANSSI ajoutent leurs propres exigences de traçabilité et de séparation des clients. La certification Elastic Certified SIEM Analyst porte sur l'usage analyste d'Elastic Security, la certification Elastic Certified Engineer sur l'administration du cluster : aucune des deux ne couvre seule le poste.

Six points à valider chez un ingénieur Elastic Security

• Collecte avec Elastic Agent et Fleet
• Normalisation ECS et pipelines
• Règles EQL, ES|QL et prédéfinies
• Réglage des alertes et du bruit
• Rétention et dimensionnement
• Run et règles versionnées

Questions techniques pour un ingénieur SIEM Elastic

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.

1. Question 1 · confirmé

   Vous ajoutez 2 000 postes Windows et une centaine de serveurs Linux au SIEM. Comment organisez-vous les politiques d'agents dans Fleet ?

   Une bonne réponseDes politiques par usage (postes, serveurs Windows, serveurs Linux, contrôleurs de domaine) plutôt qu'une politique unique. Chaque politique porte ses intégrations (System, Windows avec le canal Sysmon, Elastic Defend si l'EDR est prévu) et un namespace qui sépare les données par périmètre. Un déploiement progressif par lots, avec une politique de test, et un Fleet Server dimensionné et redondé pour le nombre d'agents.

   Signal d'alerteUne seule politique pour tout le parc, des journaux Windows collectés sans filtre ni choix des canaux, ou aucune idée du rôle du Fleet Server.

2. Question 2 · confirmé

   Les journaux d'un pare-feu arrivent en syslog dans un format que l'intégration ne découpe pas. Comment les rendez-vous exploitables par les règles ?

   Une bonne réponseUn pipeline d'ingestion personnalisé branché sur le point d'extension prévu par Fleet (logs-<dataset>@custom), sans modifier le pipeline livré par l'intégration. Des processeurs dissect ou grok, puis date, convert et rename vers les champs ECS attendus par les règles : source.ip, destination.ip, destination.port, event.action, event.outcome. Un bloc on_failure qui marque le document au lieu de le perdre, et un test avec le simulateur de pipeline sur des lignes réelles.

   Signal d'alerteModifier directement le pipeline de l'intégration, perdu à la prochaine mise à jour, ou garder le message brut en se disant que les règles chercheront dans le texte.

3. Question 3 · confirmé

   Écrivez la logique d'une règle qui alerte quand Word lance PowerShell, qui ouvre ensuite une connexion réseau sur le même poste en moins d'une minute. Quel type de règle choisissez-vous ?

   Une bonne réponseUne règle EQL avec une séquence groupée par host.id et une fenêtre maxspan d'une minute : d'abord un événement process de type start dont le parent est winword.exe et le processus powershell.exe, puis un événement network lié au même processus (par process.entity_id quand la télémétrie Elastic Defend le fournit). Il explique qu'une règle de requête simple ne sait pas ordonner deux événements.

   Signal d'alerteUne règle de requête simple sur process.name:powershell.exe, qui déclenchera sur chaque script d'administration, ou un seuil de comptage sans notion d'ordre.

4. Question 4 · confirmé

   Une règle prédéfinie génère 300 alertes par jour, toutes liées à un outil d'inventaire légitime. Que faites-vous ?

   Une bonne réponseUne exception de règle ciblée sur des champs stables (chemin et signature de l'exécutable, compte de service, hôtes concernés), au besoin appuyée sur une liste de valeurs. Pas de désactivation de la règle. Il documente l'exception avec sa raison et une date de revue, et vérifie que l'exception ne crée pas un angle mort exploitable, par exemple un simple nom de processus qu'un attaquant peut copier.

   Signal d'alerteDésactiver la règle, ou poser une exception sur process.name seul, que n'importe quel binaire renommé contourne.

5. Question 5 · confirmé

   Le SIEM doit garder un an de journaux, mais les analystes cherchent surtout sur les quinze derniers jours. Comment organisez-vous le stockage ?

   Une bonne réponseDes niveaux de données : hot pour les jours récents interrogés par les règles et les analystes, puis warm, cold ou frozen avec des searchable snapshots pour l'historique, piloté par une politique de cycle de vie par data stream. Les règles de détection ne lisent que la fenêtre récente. Il sait que les recherches sur le tier frozen sont plus lentes et que certaines fonctions dépendent de la licence, et il distingue la durée de conservation exigée par le client de la durée utile à l'investigation.

   Signal d'alerteTout garder un an sur des disques rapides, ou supprimer au bout de quinze jours sans regarder l'exigence de conservation.

Elastic Security : les questions fréquentes

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.