Questions d'entretien ingénieur QRadar : DSM, building blocks, licence EPS

Sur un SIEM IBM QRadar, l'ingénieur s'occupe de tout ce que l'analyste ne voit pas. Il ajoute des log sources, corrige le parsing avec le DSM Editor, crée des propriétés personnalisées, ajuste les règles et les building blocks pour que les offenses aient un sens, et surveille la capacité des Event Processors. Les questions d'entretien d'ingénieur QRadar couvrent ces gestes et le vocabulaire propre à l'outil (QID, catégories, hiérarchie réseau, licence EPS).

Le contexte du produit compte. IBM a cédé QRadar SaaS à Palo Alto Networks en 2024, avec une offre de migration vers Cortex XSIAM, tandis que QRadar SIEM installé sur site reste chez IBM : la branche 7.5 a reçu l'update package 16 en 2026, et IBM publie aussi une version 7.6.0, sans passage direct depuis 7.5.0 UP16. Beaucoup de postes mêlent donc le maintien d'un QRadar sur site et la préparation d'une migration vers Splunk, Sentinel ou XSIAM.

Un CV qui cite QRadar parmi dix outils appelle la prudence. Un analyste qui a traité des offenses n'a pas forcément écrit un DSM ni lu une notification de dépassement d'EPS. Les preuves utiles sont une source maison rendue exploitable, une règle réécrite pour réduire le bruit, ou une mise à jour menée sur plusieurs appliances.

Les composants de QRadar qu'un ingénieur administre

Console et appliances gérées

La console porte l'interface, la gestion et les offenses. Les Event Collectors reçoivent et parsent, les Event Processors corrèlent et stockent, les Flow Processors traitent les flux réseau, les Data Nodes ajoutent du stockage et l'App Host héberge les apps. Un candidat doit savoir faire évoluer ce découpage.

Log sources, protocoles et WinCollect

Chaque équipement ou service est une log source, raccordée par syslog, par un protocole d'API (Microsoft 365, AWS) ou par l'agent WinCollect pour Windows. L'autodétection crée les log sources syslog toutes seules, ce qui aide autant que cela peut créer des doublons.

DSM et DSM Editor

Le DSM est le module qui parse les événements d'un type de source et les normalise. IBM en fournit des centaines. Pour une application maison, le DSM Editor permet d'écrire le parsing soi-même, et c'est souvent ce qui distingue un ingénieur d'un analyste.

QID, catégories et propriétés personnalisées

Chaque événement normalisé reçoit un QID, qui porte son nom, sa sévérité et sa catégorie. Les règles et les recherches s'appuient sur ces catégories pour couvrir toutes les sources. Les propriétés personnalisées extraient les champs que le DSM ne fournit pas.

Custom Rule Engine, règles et building blocks

Le moteur de règles teste chaque événement et chaque flux. Les building blocks sont des conditions réutilisables, les règles déclenchent des réponses, dont les offenses. La hiérarchie réseau et les définitions d'hôtes conditionnent la qualité de beaucoup de règles.

Offenses et magnitude

L'offense regroupe les événements liés à un même incident présumé. Sa magnitude combine pertinence, sévérité et crédibilité, et sert à trier la file des analystes. Un ingénieur doit pouvoir expliquer pourquoi une offense remonte en haut de la liste.

AQL et base Ariel

AQL, l'Ariel Query Language, interroge les événements et les flux stockés dans Ariel. Sa syntaxe ressemble au SQL, avec ses propres fonctions et clauses de temps. L'API Ariel permet d'extraire des résultats vers d'autres outils.

Licence EPS et FPM, conservation

QRadar se licencie au nombre d'événements par seconde (EPS) et de flux par minute (FPM), répartis entre processeurs. Les retention buckets fixent la durée de conservation par source. Les dépassements de licence et les disques pleins font partie des incidents du quotidien.

Apps QRadar

Des extensions installées sur l'App Host, comme Log Source Management pour gérer les sources en masse ou Use Case Manager pour rattacher les règles à MITRE ATT&CK. Leur compatibilité est à vérifier à chaque mise à jour.

QRadar est installé dans beaucoup de SOC internes de grandes organisations et chez des prestataires qui l'exploitent pour plusieurs clients grâce aux domaines. Le poste combine l'administration de la plateforme (appliances, mises à jour, capacité, licence) et l'ingénierie de la donnée et de la détection (DSM, propriétés, règles). Depuis la cession de QRadar SaaS à Palo Alto Networks en 2024, de nombreux projets portent aussi sur une migration, ce qui demande de savoir inventorier un existant et de connaître au moins un autre SIEM. Les certifications IBM sur QRadar existent mais pèsent moins qu'un DSM écrit ou une plateforme remise en ordre.

Six compétences attendues d'un ingénieur QRadar

• Architecture et déploiement
• Collecte, log sources et DSM
• Règles, building blocks et offenses
• Recherche AQL et propriétés
• Licences, capacité et rétention
• Exploitation et migration

Questions pour un ingénieur QRadar, avec les réponses attendues

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 · senior

   Le volume d'événements double après le rattachement d'une filiale. Comment faites-vous évoluer un QRadar installé sur une seule console tout-en-un ?

   Une bonne réponseIl sépare les rôles. Des Event Collectors au plus près des sources, notamment sur les sites distants, pour collecter, parser et garder les événements en file si le lien tombe. Des Event Processors pour la corrélation et le stockage, des Data Nodes pour ajouter de la capacité de stockage et de recherche à un processeur, un App Host pour sortir les apps de la console. La console garde l'interface et la gestion. Il réalloue la licence EPS entre processeurs et rappelle que toutes les appliances doivent être à la même version.

   Signal d'alerteAjouter de la mémoire et des processeurs à la console, sans toucher à l'architecture.

2. Question 2 · confirmé

   Une application maison envoie des logs que QRadar range en événements inconnus sous une log source générique. Comment les rendez-vous exploitables ?

   Une bonne réponseAvec le DSM Editor : un type de log source personnalisé, l'extraction de l'identifiant d'événement et des champs par expression régulière ou par JSON, puis un mappage vers des QID, existants ou créés avec leur catégorie de bas niveau et leur sévérité. Il crée les propriétés personnalisées utiles (compte, adresse source) et n'active pour les règles et l'indexation que celles qui servent. Il vérifie ensuite que les événements ne sont plus inconnus et que les règles par catégorie les voient.

   Signal d'alerteLaisser les événements inconnus et écrire des règles qui cherchent du texte dans le payload.

3. Question 3 · confirmé

   Vous reprenez un QRadar où la hiérarchie réseau ne contient plus que les plages par défaut et où les building blocks de définition d'hôtes sont vides. Quel effet cela a-t-il sur les offenses, et comment remettez-vous cela en ordre ?

   Une bonne réponseSans hiérarchie réseau, QRadar ne sait pas distinguer l'interne de l'externe ni pondérer les zones, donc les règles qui testent « local vers distant » ou une zone précise se trompent et la magnitude perd son sens. Sans définitions d'hôtes, les scanners, serveurs de sauvegarde et serveurs DNS déclenchent les règles comme n'importe quel poste. Il reconstruit la hiérarchie à partir de l'IPAM ou de la CMDB avec des poids par zone, remplit les building blocks de définition d'hôtes, place les exceptions dans des reference sets avec une durée de vie, puis compare le volume et la qualité des offenses sur deux semaines.

   Signal d'alerteFermer les offenses en masse chaque matin, ou ne pas savoir que la hiérarchie réseau influence les règles et la magnitude.

4. Question 4 · confirmé

   Écrivez une requête AQL qui sort, sur les sept derniers jours, les log sources qui ont perdu au moins la moitié de leur volume quotidien habituel.

   Une bonne réponseUne agrégation par log source et par jour, du type SELECT LOGSOURCENAME(logsourceid) AS source, DATEFORMAT(starttime,'yyyy-MM-dd') AS jour, COUNT(*) AS nb FROM events GROUP BY source, jour LAST 7 DAYS, puis la comparaison de chaque jour à la moyenne de la source, dans un rapport, un script appelant l'API Ariel ou un tableau de bord. Il utilise les fonctions AQL (LOGSOURCENAME, DATEFORMAT), place la clause de temps propre à AQL en fin de requête et sait qu'une requête sur sept jours d'événements se limite aux champs indexés pour rester rapide.

   Signal d'alerteUne recherche plein texte sur le payload, ou une syntaxe SQL classique avec une condition de date sur une colonne.

5. Question 5 · confirmé

   QRadar dépasse sa licence EPS tous les matins vers 9 heures. Que se passe-t-il pour les événements, et que faites-vous ?

   Une bonne réponseUn pic court passe par le mécanisme de tampon (burst handling) : les événements sont traités en retard, donc détectés en retard. Un dépassement qui dure remplit les files, et QRadar finit par perdre des événements, ce que signalent les notifications système. Il identifie les log sources qui pèsent le plus à cette heure, filtre à la source (WinCollect, équipements), revoit le coalescing et les règles de routage, réalloue la licence entre processeurs, et ne demande une extension qu'ensuite.

   Signal d'alerte« QRadar refuse les événements en trop » sans nuance, ou « on achète plus d'EPS » sans regarder d'où vient le pic.

Ingénieur QRadar : 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.