Analyste SOC

L’analyste SOC (Security Operations Center), ou analyste de centre opérationnel de sécurité, surveille les événements de sécurité d’un système d’information. Il analyse les alertes, recherche les indices d’un incident et en évalue la gravité. Il documente ses constats pour que les équipes chargées de la réponse puissent agir. La surveillance peut se faire en temps réel ou après réception de rapports et de journaux. Le poste transforme ainsi des signaux techniques en situations compréhensibles et priorisées.

L’analyste examine notamment les journaux de systèmes et d’applications, les flux réseau et les alertes des outils de détection. Il distingue une activité attendue d’un événement qui appelle une investigation. Selon l’organisation, il notifie l’incident, recommande une mesure immédiate ou accompagne les équipes d’investigation. Il ne prend pas automatiquement en charge tous les correctifs : les entités responsables du traitement conservent cette mission.

Le périmètre varie entre un SOC interne à la DSI et une activité exercée en prestation. L’Apec distingue des postes N1 centrés sur le repérage, N2 tournés vers l’analyse approfondie et N3 consacrés aux cas complexes et aux cas d’usage spécifiques. Ces niveaux sont des repères dépendant du poste, pas une progression obligatoire pour chaque entreprise. Précisez les décisions que la personne pourra prendre seule et celles qu’elle devra escalader.

Analyste SOC, pentester et RSSI : qui fait quoi ?

• Analyste SOC : surveille, qualifie et documente les événements pour faciliter la réponse à incident.
• Pentester : mène des tests d’intrusion et des évaluations techniques pour identifier des vulnérabilités.
• RSSI : définit et fait appliquer la politique de sécurité du système d’information.

Ces métiers peuvent échanger des informations. Leurs responsabilités principales répondent à des besoins différents : exploiter les alertes, éprouver la sécurité technique ou piloter la politique de sécurité.

Une alerte utile perd de sa valeur si personne ne sait la qualifier, en mesurer la gravité ou la transmettre avec assez de contexte. L’enjeu du recrutement est de disposer d’une analyse qui permette aux équipes concernées de décider de la suite. Un rapport d’incident exploitable décrit les éléments observés, le raisonnement suivi et ce qui demeure incertain. Les tableaux de bord et la documentation à jour rendent également l’activité du SOC lisible.

Le besoin change selon la charge de surveillance et la répartition des responsabilités. Un poste centré sur le premier tri demande de reconnaître les signaux qui méritent une enquête et de suivre les voies d’escalade. Si la personne doit approfondir les investigations ou ajuster les règles de détection, il faut rechercher une autonomie technique plus large. Le titre du poste seul ne dit pas qui décide qu’un incident est avéré, qui contacte les équipes techniques ni qui suit les correctifs.

Exemple fictif : plusieurs alertes concernent une même machine à quelques minutes d’intervalle. Un analyste gagne à les rapprocher plutôt qu’à les transmettre séparément sans contexte. Il examine les journaux et les flux disponibles, explicite les indices qui soutiennent ou écartent l’hypothèse d’un incident, puis transmet un dossier priorisé selon les procédures du SOC. Cet exemple illustre une démarche, pas une procédure universelle.

Un mauvais cadrage peut confondre des métiers voisins. Rechercher un pentester pour assurer la surveillance courante, ou attendre d’un analyste SOC qu’il définisse seul la politique de sécurité, rend l’évaluation trompeuse. Les conditions de travail comptent également : les astreintes sont possibles, mais leur existence et leur rythme dépendent du poste. Précisez-les avant de comparer les candidatures. Identifiez aussi les équipes qui recevront les escalades et celles qui réaliseront le traitement, afin que le futur analyste connaisse sa marge d’action.

• Surveiller les journaux, les flux et les alertes pour repérer les activités suspectes.
• Analyser et qualifier les événements de sécurité à partir des indices disponibles.
• Évaluer la gravité d’un incident et prioriser sa prise en charge.
• Notifier les incidents et escalader les cas qui dépassent son périmètre de décision.
• Documenter les investigations et rédiger des rapports utilisables par les équipes de réponse.
• Transmettre des recommandations aux équipes chargées du traitement, selon le poste.
• Renseigner les tableaux de bord d’activité et tenir la documentation opérationnelle à jour.
• Contribuer à la collecte des journaux et à l’ajustement des règles de corrélation, selon son autonomie.

Plusieurs parcours peuvent préparer au métier. L’ANSSI cite une formation Bac +3 spécialisée en cybersécurité ou une première expérience en ingénierie des réseaux et des systèmes. L’Apec mentionne des parcours Bac +3 en informatique et Bac +5 spécialisés en cybersécurité. Ces voies aident à situer les acquis possibles. Elles ne suffisent pas, à elles seules, à établir la capacité d’une personne à qualifier un incident dans le SOC que vous organisez.

Examinez d’abord ce que le candidat sait faire avec des traces réelles ou reconstituées. Peut-il lire un journal, interpréter un flux réseau et relier des événements sans confondre coïncidence et preuve ? Comprend-il les systèmes, les protocoles et les techniques d’attaque assez bien pour formuler une hypothèse vérifiable ? Une formation pertinente peut apporter ce socle, mais une expérience réseaux et systèmes peut aussi l’avoir construit.

L’expérience à apprécier correspond aux responsabilités déjà exercées. Pour un poste consacré au premier tri, recherchez des situations où le candidat a identifié une anomalie, justifié sa qualification et transmis les bons éléments. Si le poste comporte une analyse approfondie, demandez comment il a évalué la gravité d’un incident et documenté les incertitudes. Pour un périmètre incluant l’amélioration de la détection, intéressez-vous à sa contribution aux règles de corrélation, à la collecte des journaux et à la mise à jour de procédures.

Vérifiez enfin la capacité à travailler avec les équipes chargées du traitement. Une analyse technique peut rester difficile à exploiter si les faits, la priorité et le destinataire de l’escalade ne sont pas clairs. La qualité d’un rapport d’incident ou d’un tableau de bord rend cet acquis observable, quel que soit le parcours initial.

Dans sa méthode de recrutement, GetPro utilise une grille de critères priorisés. Elle distingue les critères vérifiables sur le parcours de ceux à examiner en entretien, notamment à l’aide de questions ouvertes et d’exemples concrets. Avec l’accord préalable du candidat, une prise de références peut éclairer les compétences qui restent incertaines.

Pour évaluer un analyste SOC, partez des alertes qu’il devra traiter, des décisions qu’il pourra prendre et des équipes auxquelles il transmettra ses conclusions. Les étapes ci-dessous sont des conseils adaptés à ce rôle.

1. Fixez les critères du poste

Décrivez les sources utilisées par votre SOC, le niveau d’analyse attendu et les règles d’escalade. Distinguez le tri initial, l’investigation approfondie et la contribution aux règles de détection. Une personne chargée du premier tri doit reconnaître les signaux à examiner et transmettre un dossier clair. Un poste plus autonome exige de relier plusieurs indices, de défendre une priorité et d’expliquer les limites de son analyse. Préparez une grille courte : qualité de la qualification, raisonnement technique, choix d’escalade, documentation et coopération. Une réponse assurée mais sans éléments vérifiables constitue un signal d’alerte.

2. Examinez les réalisations passées

Demandez au candidat de décrire une alerte analysée, en retirant les informations confidentielles. Faites préciser les journaux ou les flux consultés, les hypothèses écartées, la gravité retenue et le destinataire du compte rendu. Une bonne réponse sépare les faits observés des déductions et explique les informations manquantes. Pour un poste incluant l’amélioration de la détection, demandez quelle règle a été ajustée et à partir de quel constat. Un récit limité au nom d’un outil renseigne peu sur la capacité d’analyse.

3. Proposez un cas pratique proche du poste

Présentez quelques alertes et extraits de journaux cohérents avec votre environnement, puis demandez une qualification et une note de transmission. Exemple fictif : deux alertes et un extrait de flux semblent concerner le même équipement. Demandez quels rapprochements seraient utiles, quel événement mérite une enquête et ce qui demeure incertain. Observez la démarche, les questions posées et la justification de la priorité. Le livrable peut être un court rapport distinguant indices, hypothèses, gravité et prochaine action. Ne récompensez pas une certitude que les données du cas ne permettent pas.

4. Vérifiez la communication et les limites d’autorité

Faites reformuler la conclusion pour une équipe systèmes ou de réponse à incident. Le candidat doit indiquer ce qu’il transmet, à qui, et quelle décision appartient au destinataire. Interrogez-le sur un désaccord de priorité : quels faits apporterait-il pour étayer son analyse ? S’il a déjà défini des procédures ou travaillé en équipe, demandez comment il a rendu ces échanges reproductibles. Un signal favorable est une formulation précise, qui permet au destinataire d’agir sans attribuer à l’analyste la responsabilité de tous les correctifs.

5. Recoupez les références et l’expertise

Avec l’accord du candidat, demandez à une référence professionnelle quel type d’alertes il traitait et à quel moment il escaladait. Cherchez une description des responsabilités réellement exercées, pas seulement un niveau N1, N2 ou N3. Si votre entreprise n’a pas d’expert capable d’apprécier le cas technique, associez à l’évaluation une personne qualifiée en supervision ou en réponse à incident. Conservez la même grille de critères pour comparer les candidats et signalez séparément les points que personne n’a pu vérifier.