Que testent vraiment les entretiens pour analyste en cybersécurité ?

Qui est vraiment dans la salle

Pour un poste d'analyste en cybersécurité, le premier entretien se fait rarement avec les RH seules. Le responsable SOC ou un analyste senior sera présent dès le début, car les questions importantes ne peuvent pas être posées par quelqu'un qui n'a jamais trié une alerte lui-même. Dans les petites entreprises, vous pourriez avoir directement le RSSI. Dans les grandes, il y a souvent d'abord un filtrage technique (un analyste senior ou chef d'équipe, 30-45 minutes, axé sur les scénarios) suivi d'un panel incluant le responsable du recrutement et parfois quelqu'un des opérations informatiques ou d'une équipe plateforme avec qui vous travailleriez — parce qu'une grande partie du travail consiste à escalader et transmettre, pas seulement à détecter.

Si l'entreprise gère un SOC mature, vous rencontrerez aussi peut-être le responsable du SIEM (Splunk, Microsoft Sentinel, QRadar, Elastic) et celui de l'EDR (CrowdStrike, Defender for Endpoint, SentinelOne). Ils posent des questions différentes car ils se préoccupent de modes de défaillance différents : le responsable SIEM veut savoir si vous savez écrire une recherche qui n'est pas médiocre ; le responsable EDR veut savoir si vous allez poursuivre un script PowerShell bénin pendant deux heures parce que vous n'avez pas vérifié le processus parent d'abord.

L'exercice technique : à quoi il ressemble

La plupart des évaluations techniques pour ce poste ne sont pas des tests de code. Ce sont des exercices de triage, car le triage est le métier. Formats courants :

• Triage d'alertes dans un SIEM en bac à sable ou un ensemble de captures d'écran. On vous donne une poignée d'alertes — une connexion depuis une géographie inhabituelle, un pic de requêtes DNS sortantes, une détection EDR marquée comme « suspecte » plutôt que « malveillante » — et on vous demande lesquelles vous escaladeriez, lesquelles vous fermeriez, et pourquoi. L'enquêteur observe votre ordre de raisonnement, pas votre réponse finale.
• Un pcap ou un extrait de logs. On pourrait vous remettre une sortie Wireshark ou des logs bruts de pare-feu et vous demander de reconstituer ce qui s'est passé : est-ce un scan de ports, une tentative de force brute échouée, du beaconing C2 sur un intervalle inhabituel. Certains endroits substituent un email de phishing avec en-têtes et vous demandent de lire la chaîne Received et d'évaluer les résultats SPF/DKIM/DMARC.
• Un scénario d'incident sur table. « Une note de ransomware apparaît sur un ordinateur portable de la finance à 16h un vendredi. Guidez-moi dans l'heure qui suit. » Cela teste si vous connaissez la forme du cycle de vie d'incident du NIST 800-61 — identification, confinement, éradication, récupération, leçons apprises — sans le réciter comme une liste. Les bons candidats isolent la machine avant de commencer à demander qui est responsable.
• Un exercice à emporter, moins souvent maintenant qu'il y a quelques années. Généralement un rapport d'incident écrit à partir d'un ensemble donné de logs, ou un court modèle de menace pour un système hypothétique. Si vous en recevez un, les enquêteurs vérifient si vous savez écrire pour quelqu'un qui n'était pas dans la salle — car les rapports d'incident sont lus par des personnes qui n'étaient pas sur l'appel.

Ce qui est rarement testé, malgré ce qu'impliquent les guides d'entretien génériques, c'est si vous pouvez réciter le modèle OSI ou définir « zero trust » de mémoire. Cela arrive au mieux comme questions d'échauffement. L'exercice existe pour voir ce que vous faites quand l'alerte est ambiguë, car la plupart des alertes sont ambiguës.

Les questions qui sondent vraiment la compétence

Certaines questions ressemblent à de la conversation mais ne le sont pas. Voici ce qu'elles vérifient vraiment :

« Décrivez-moi le dernier faux positif que vous avez fermé. » Ce n'est pas un test de mémoire. Cela vérifie si vous comprenez pourquoi c'était un faux positif — le mécanisme, pas seulement l'étiquette — et si vous avez ajusté quelque chose après, ou si vous avez juste cliqué sur fermer. Un analyste qui ne peut pas décrire l'ajustement d'une règle de détection ou la suppression d'une source bruyante n'a pas fait le travail assez longtemps pour réduire le bruit qu'il génère.

« Quel est votre processus quand vous recevez une alerte que vous ne comprenez pas ? » Ils écoutent pour une séquence : vérifier l'actif (est-ce un contrôleur de domaine ou l'ordinateur portable de quelqu'un), vérifier le comportement normal du compte, extraire les événements connexes dans une fenêtre de part et d'autre de l'alerte, vérifier si l'IOC apparaît ailleurs, puis décider. Si la réponse saute directement à « je l'escaladerais », c'est un signal d'alarme pour un enquêteur expérimenté, car tout escalader est ce que fait quelqu'un qui ne sait pas comment enquêter.

« Parlez-moi d'une fois où vous vous êtes trompé sur un incident. » C'est délibérément gênant. Les analystes qui n'ont traité que des tickets, pas de vrais incidents, n'ont souvent pas de réponse, car se tromper nécessite d'avoir pris une décision dans l'incertitude. Les enquêteurs utilisent cela pour séparer les personnes qui ont suivi un runbook de celles qui ont dû porter un jugement à 2h du matin avec des informations incomplètes.

« Comment maintenez-vous la veille sur les menaces à jour, et comment cela change-t-il ce que vous regardez ? » Pas « lisez-vous des blogs ». Ils veulent savoir si vous pouvez nommer un flux ou une source spécifique (la recherche sur les menaces d'un fournisseur, un ISAC, une liste IOC interne d'un incident précédent) et, plus important encore, donner un exemple de détection ou de chasse que vous avez construite à cause de quelque chose que vous avez lu — pas seulement que vous vous êtes abonné à une liste de diffusion.

Les questions sur MITRE ATT&CK ne demandent généralement pas de réciter des ID de tactiques. Elles vérifient si vous l'utilisez comme un outil de travail : pouvez-vous mapper une technique observée (disons, T1053 pour l'abus de tâche planifiée) à ce que vous vous attendriez à voir ensuite dans la chaîne, et si vous le reconnaîtriez si vous le voyiez.

À quoi ressemble une réponse superficielle

Pour quelqu'un qui gère vraiment un SOC, voici les signes révélateurs :

• Décrire la détection entièrement en termes d'outils (« nous avons utilisé Splunk et CrowdStrike ») sans mentionner ce que vous cherchiez ou quelle était la logique de la requête. Nommer le SIEM n'est pas la même chose que montrer que vous savez l'utiliser.
• Répondre « quel est le processus de réponse aux incidents » en listant les phases NIST dans l'ordre sans exemple attaché. N'importe qui peut mémoriser six mots. L'enquêteur veut un incident où le confinement était plus difficile que ne le fait paraître le manuel — parce qu'un système de production que vous ne pouvez pas simplement débrancher, ou un compte compromis qui est aussi le compte exécutant un service critique, c'est là qu'est le vrai jugement.
• Traiter chaque scénario comme si la réponse était « escalader à l'équipe de réponse aux incidents », sans démontrer que vous savez ce que cette équipe voudrait qu'on lui transmette d'abord : la portée, les hôtes affectés, l'heure du premier indicateur, si le confinement a déjà commencé.
• Confondre la gestion des vulnérabilités avec la détection. Être interrogé sur une CVE et ne pouvoir dire que « nous la corrigerions » sans mentionner les contrôles compensatoires, l'exposition ou l'exploitabilité dans votre environnement suggère que vous n'avez pas assisté à une réunion de priorisation des correctifs.
• Parler de certifications (Security+, CySA+, GCIH, OSCP) comme de réalisations plutôt que comme preuves de capacité spécifique. Un enquêteur qui détient lui-même GCIH demandera ce que vous avez fait dans les labos, pas si vous avez réussi.

Que faire avant votre prochain entretien

Choisissez deux incidents ou enquêtes de votre propre travail — réels, même petits — et soyez prêt à les décrire avec suffisamment de détails techniques pour qu'un autre analyste puisse suivre le raisonnement : ce qui a déclenché l'alerte, ce que vous avez écarté et comment, ce que vous feriez différemment. C'est une préparation plus utile que n'importe quelle liste de questions génériques, car c'est ce que l'enquêteur essaie réellement de vous faire produire.

Si vous postulez simultanément à plusieurs postes SOC ou analyste et que les annonces demandent toutes des combinaisons d'outils légèrement différentes (Sentinel ici, QRadar là, une plateforme SOAR que vous n'avez touchée qu'une fois), jobmarket.pro lit chaque annonce en entier et prépare une candidature à partir de votre expérience réelle, sans inventer de familiarité avec des outils que vous n'avez pas utilisés.