Que fait réellement un analyste SOC Tier 1 toute la journée ?

Les offres d'emploi pour analyste SOC Tier 1 sont vagues à dessein car le rôle consiste surtout en un triage répétitif, et les entreprises savent que « surveiller les alertes et enquêter sur les incidents » sonne mieux que la réalité. Voici à quoi ressemble le travail de l'intérieur, ticket par ticket.

La file d'attente ne se vide jamais vraiment

Vous commencez un quart et il y a une file de tickets, généralement générée par un SIEM comme Splunk, Microsoft Sentinel ou QRadar. Chaque ticket est une alerte : une connexion depuis un pays inhabituel, un pic de trafic sortant, un fichier correspondant à une règle YARA, un compte utilisateur verrouillé cinq fois en dix minutes. Un SOC occupé en génère des centaines par jour, et la plupart sont d'abord le problème du Tier 1.

Vous ouvrez un ticket. Il vous donne un timestamp, une adresse IP source, peut-être un nom d'utilisateur, et la règle qui s'est déclenchée. Votre travail est de répondre à une seule question : est-ce quelque chose ou rien ? C'est tout. Vous ne réparez rien encore — vous décidez si cela mérite plus d'attention.

Le triage c'est 90% la collecte de contexte

Disons que l'alerte est « déplacement impossible » : un utilisateur s'est connecté de Chicago puis, 20 minutes plus tard, depuis Francfort. Avant de décider quoi que ce soit, vous collectez du contexte :

• Vérifiez le modèle de connexion normal de l'utilisateur dans le SIEM — voyage-t-il pour le travail, utilise-t-il un VPN, a-t-il un ordinateur portable qui signale mal la géolocalisation ?
• Vérifiez si l'authentification multifacteur a été satisfaite aux deux connexions, ou si la deuxième a utilisé un jeton en cache.
• Recherchez l'adresse IP source dans quelque chose comme VirusTotal ou AbuseIPDB — est-ce un nœud de sortie Tor connu, un fournisseur VPN, un FAI résidentiel ?
• Contactez directement l'utilisateur si le processus de votre SOC le permet — un message Slack comme « hé, tu te connectais depuis l'Allemagne vers 14h ? » résout la moitié de ces tickets en une réponse.

La plupart du temps, c'est un client VPN qui change de serveur ou un téléphone qui se synchronise sur LTE dans un endroit bizarre. Vous écrivez ce que vous avez trouvé, le marquez comme faux positif et fermez le ticket. C'est le travail, répété 30 à 60 fois par quart selon le volume de votre SOC et votre vitesse.

Savoir quand escalader — et rédiger l'escalade pour que Tier 2 n'ait pas à refaire votre travail

La vraie compétence n'est pas de détecter les malwares. C'est de savoir quand quelque chose ne colle pas assez pour escalader, et de rédiger l'escalade pour que Tier 2 puisse la traiter sans refaire votre triage de zéro. Une mauvaise escalade dit « connexion suspecte, veuillez enquêter ». Une bonne dit :

Utilisateur : jsmith@company.com
Alerte : Déplacement impossible (Chicago -> Francfort, 22 min d'écart)
Authentification multifacteur : Satisfaite aux deux connexions via notification push
Adresse IP (Francfort) : 185.220.101.x — correspond à la liste des nœuds de sortie Tor connus (score AbuseIPDB 94)
Réponse de l'utilisateur : Nie avoir voyagé ou utiliser un VPN ; signale l'absence d'invite MFA pour la deuxième connexion (possibilité de fatigue du push ?)
Recommandation : Escalader — possible compromission de compte via envoi de push MFA. Recommande la réinitialisation forcée du mot de passe et la révocation de session.

Cette rédaction a pris peut-être huit minutes mais elle économise vingt minutes à Tier 2. Les tickets comme celui-ci — où l'utilisateur nie l'activité et l'adresse IP est signalée — sont ceux qui comptent vraiment, et ils représentent peut-être 5% de votre file.

Les outils que vous utiliserez à chaque quart

Au-delà du SIEM, attendez-vous à vivre dans une poignée d'outils quotidiennement : une console EDR (CrowdStrike Falcon, SentinelOne, Defender for Endpoint) pour vérifier les arborescences de processus et isoler les hôtes si on vous l'ordonne, un système de ticketing (ServiceNow, Jira) pour suivre votre travail, des recherches de renseignement sur les menaces (VirusTotal, AbuseIPDB, urlscan.io) pour des vérifications rapides d'IOC, et souvent un document de runbook ou playbook qui vous dit exactement quelles étapes suivre pour chaque type d'alerte. Le travail Tier 1 est lourdement axé sur les playbooks à dessein — la cohérence importe plus que l'improvisation à ce niveau.

Pourquoi la répétition est en fait l'entraînement

La raison pour laquelle Tier 1 existe en tant que rôle distinct, plutôt que de renvoyer chaque alerte directement aux analystes seniors, c'est la reconnaissance de modèles par le volume. Après quelques centaines de tickets de déplacement impossible, vous commencez à reconnaître la forme d'un vrai par rapport à un changement de serveur VPN routinier avant même d'avoir fini de collecter le contexte. Cet instinct ne vient pas d'un cours — il vient de faire la version ennuyeuse du travail assez longtemps pour que l'incident réel rare se distingue vraiment.

Si vous tracez un chemin dans le travail en blue team, Korra Studio a des segments sur les bases des requêtes SIEM, les flux de triage du phishing, et ce qui distingue les responsabilités Tier 1 de Tier 2 en pratique.