Questions d'entretien analyste SOC QRadar, des offenses au tuning

QRadar reste très présent dans les SOC internes et chez les prestataires de services managés, souvent depuis des années, avec des règles accumulées et des sources hétérogènes. L'analyste y travaille en N1, N2 ou N3. Le N1 trie les offenses et escalade. Le N2 investigue, écrit ses requêtes AQL et propose des exclusions. Le N3 conçoit des règles et accompagne la réponse aux incidents.

La difficulté vient des CV qui citent QRadar après quelques mois de console. Ouvrir une offense et lire sa magnitude ne demande pas grand-chose. Expliquer pourquoi une attaque produit deux offenses, pourquoi un pare-feu tombe en « Unknown » ou comment exclure un bruit sans aveugler le SOC, si. La lecture des journaux Windows et la méthode d'investigation comptent aussi, car elles se transposent d'un SIEM à l'autre.

Reste la question de l'avenir de l'outil. IBM garde QRadar sur site, mais une partie des organisations migre vers un autre SIEM. Un analyste qui connaît la logique des règles, au-delà des menus, suivra cette migration sans perte. Le PDF complet compte trente questions et un cas d'investigation de vingt minutes.

QRadar vu depuis le poste de l'analyste

IBM QRadar SIEM

Le SIEM d'IBM, installé sur site ou chez un hébergeur. Il collecte les journaux et les flux réseau, les normalise, applique les règles de corrélation et crée des offenses. La version sur site continue chez IBM, avec la branche 7.5 puis 7.6. L'offre SaaS a été cédée à Palo Alto Networks en 2024.

Offenses et magnitude

L'offense est l'unité de travail de l'analyste : un regroupement d'événements autour d'une propriété (IP source, compte, destination). Sa magnitude, de 1 à 10, combine pertinence, sévérité et crédibilité. Elle aide au tri sans remplacer le jugement sur l'actif touché.

AQL (Ariel Query Language)

Le langage de requête de QRadar, proche du SQL, qui interroge les tables events et flows de la base Ariel. Un N2 doit l'écrire sans assistant graphique : filtres, GROUP BY, fonctions comme QIDNAME ou LOGSOURCENAME, période avec LAST ou START et STOP.

Règles et building blocks

Les règles testent les événements, les flux ou les offenses et déclenchent une action. Les building blocks sont des briques de tests réutilisées par plusieurs règles, par exemple la liste des serveurs DNS ou des scanners. C'est là que se règlent la plupart des faux positifs.

DSM et sources de logs

Le DSM traduit le format d'un équipement en événements normalisés, avec un QID et des catégories. Quand il échoue, les événements arrivent en « Unknown » et les règles ne les voient plus. L'analyste doit savoir le repérer, même si la correction revient à l'équipe build.

Reference sets et renseignement

Des listes tenues à jour (IP, domaines, hashes, comptes sensibles) que les règles et les requêtes consultent. Elles servent aux listes d'indicateurs, aux exclusions et au marquage des actifs critiques. X-Force apporte la réputation des adresses et des domaines.

Applications QRadar

Use Case Manager relie les règles aux techniques MITRE ATT&CK et montre la couverture. Analyst Workflow propose une interface d'investigation plus récente que l'onglet Offenses classique. D'autres applications ajoutent l'analyse comportementale des utilisateurs ou des tableaux de bord.

Sources Windows, EDR et réseau

La matière de l'investigation : journaux de sécurité Windows (4624, 4625, 4688, 4769), Sysmon, EDR, proxy, DNS, pare-feu, VPN, Entra ID. Un analyste QRadar vaut surtout par sa lecture de ces journaux, qui ne dépend pas de l'outil.

QRadar SOAR et ticketing

Le SOAR d'IBM (ex-Resilient) ou un autre outil d'orchestration enchaîne l'enrichissement, la création du ticket et certaines actions de réponse. L'analyste y suit les playbooks et propose les tâches à automatiser.

Le poste existe dans les SOC internes des grandes organisations et chez les prestataires de détection, dont certains visent ou détiennent la qualification PDIS de l'ANSSI. Le travail se fait souvent en horaires décalés, avec astreinte. Le niveau se lit au périmètre : le N1 trie et escalade, le N2 investigue et propose des ajustements, le N3 conçoit des règles et intervient en réponse à incident. Aucune certification IBM n'est exigée en pratique. Les offres demandent plutôt une expérience de l'AQL, de la création de règles et du dépannage des sources, et souvent un second SIEM, Sentinel ou Splunk, à cause des migrations en cours.

Les compétences à vérifier chez un analyste QRadar

• Triage et qualification des offenses
• Requêtes AQL
• Règles, building blocks et tuning
• Sources de logs et parsing DSM
• Investigation Windows, AD et réseau
• Réponse et escalade

Questions d'entretien pour un analyste SOC QRadar

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 · junior à confirmé

   Deux offenses arrivent en même temps : une de magnitude 8 sur un poste de travail, une de magnitude 3 sur un contrôleur de domaine. Laquelle ouvrez-vous en premier ?

   Une bonne réponseLa magnitude combine pertinence, sévérité et crédibilité, calculées par QRadar à partir des règles et de la hiérarchie réseau. Elle ne connaît pas toujours la valeur réelle de l'actif. Le bon réflexe : un coup d'œil rapide aux deux (règles déclenchées, nombre d'événements, catégories), puis priorité au contrôleur de domaine si l'activité est crédible. La personne signale aussi qu'une magnitude basse sur un DC trahit un paramétrage à corriger.

   Signal d'alerte« La 8, parce que c'est la plus haute », sans regarder l'actif touché. Ou aucune idée de ce qui compose la magnitude.

2. Question 2 · confirmé

   Dictez une requête AQL qui liste, sur les dernières 24 heures, les comptes Windows ayant plus de vingt échecs de connexion.

   Une bonne réponseUn SELECT sur la table events avec username et COUNT(*), un filtre sur les échecs d'authentification (catégorie de bas niveau, QIDNAME ou propriété EventID 4625 selon la normalisation), GROUP BY username, HAVING sur le compteur, ORDER BY décroissant et LAST 24 HOURS en fin de requête. Un profil solide filtre aussi sur le type de source pour ne pas lire tout le volume, et prévient que le même compte peut apparaître sous plusieurs formes (DOMAINE\compte, UPN, casse).

   Signal d'alerteDu SQL générique sans fenêtre de temps, une recherche texte dans le payload brut, ou l'aveu de ne jamais quitter l'interface graphique de Log Activity.

3. Question 3 · confirmé

   Une règle de brute force produit 300 offenses par jour, presque toutes dues à un serveur de supervision. Que proposez-vous ?

   Une bonne réponseD'abord confirmer la cause : compte de service, sonde, script mal configuré, avec le propriétaire du serveur. Ensuite une exclusion étroite (cette IP, ce compte, ce type d'événement), posée dans un building block ou un reference set plutôt qu'en dur dans la règle, documentée et revue à date fixe. La règle reste active pour le reste du parc. La personne vérifie ensuite le volume sur quelques jours et, si possible, fait corriger la source du bruit.

   Signal d'alerteDésactiver la règle, exclure tout le sous-réseau du serveur, ou fermer les 300 offenses chaque matin sans rien changer.

4. Question 4 · confirmé

   Les événements d'un pare-feu arrivent sous « Unknown » ou sont rangés dans la source SIM Generic Log. Qu'est-ce que cela signifie pour vos détections ?

   Une bonne réponseLe DSM ne reconnaît pas le format : nouvelle version du firmware, format de sortie changé, mauvais type de source ou détection automatique ratée. Les événements sont stockés, mais sans QID ni catégorie, donc les règles qui s'appuient sur les catégories ne les voient pas. C'est un angle mort. La personne vérifie la source et la mise à jour du DSM, ouvre une demande vers l'équipe build (DSM Editor, extension de source) et cherche dans le payload en attendant.

   Signal d'alerte« Ce n'est pas grave, les logs sont gardés. » Ne pas faire le lien entre parsing et déclenchement des règles.

5. Question 5 · confirmé

   Une offense signale des connexions RDP depuis un poste utilisateur vers dix serveurs en une heure. Comment confirmez-vous un mouvement latéral ?

   Une bonne réponseCôté serveurs, les événements 4624 de type 10 (et les 4625), le compte utilisé, les horaires et l'IP d'origine. Est-ce un compte d'administration ouvert depuis un poste bureautique ? Côté poste, l'arbre de processus dans l'EDR et les 4688 ou Sysmon : qui a lancé mstsc ou un outil d'accès à distance. Les flux réseau complètent si les journaux manquent. Puis une demande de changement ou un ticket d'intervention qui justifierait l'activité, la technique T1021.001 d'ATT&CK et une escalade si rien ne l'explique.

   Signal d'alerteAppeler l'utilisateur et clore sur sa parole, ou ne pas connaître les types d'ouverture de session Windows.

Analyste SOC 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.