Analyste SOC L1 — Processus de réponse aux alertes

Voici la routine quotidienne d’un analyste SOC de niveau 1.
Le périmètre du L1 s’arrête au confinement. L’éradication, la remise en état et le retour d’expérience relèvent du L2 / de l’équipe IR.

Phase 1 — Réception de l’alerte

Étape 1 — Lire l’alerte

• Noter le nom de la règle, la sévérité, l’IP source, la cible et l’horodatage
• Ne pas agir tout de suite : lire et comprendre ce que dit l’alerte
• Où regarder : SIEM → Security Events → détails de l'alerte

Étape 2 — Rassembler le contexte

• Qui est l’IP source ? Interne ou externe ?
• Qui ou quoi est visé ? Est-ce un actif critique ?
• Quel service ou port est concerné ?
• Où regarder : SIEM → inventaire des actifs / CMDB

Étape 3 — Rechercher des alertes antérieures

• Cette IP ou ce compte a-t-il déjà déclenché des alertes ?
• Cela fait-il partie d’un schéma connu ou d’une campagne en cours ?
• Où regarder : SIEM → recherche par IP / compte / période

Phase 2 — Triage et qualification

Point de décision 1 — Est-ce un faux positif ?

Se demander : cette activité correspond-elle à un usage métier légitime ?
Pourrait-il s’agir d’un outil connu, d’une tâche planifiée ou d’un scan autorisé ?

Étape 4 — Confirmer le schéma d’attaque

• Analyser le volume, la fréquence, le compte visé et les horodatages
• Correspond-il à une technique connue ? (force brute, phishing, mouvement latéral, etc.)
• Recouper avec MITRE ATT&CK

Point de décision 2 — Y a-t-il eu une connexion ou une exécution réussie ?

Chercher : Event ID 4624 (Windows) / log d’authentification réussie / processus inattendu lancé.
Le moindre signe que l’attaquant est réellement entré ?

Phase 3 — Confinement (périmètre L1)

Étape 5 — Bloquer la source

• Bloquer l’IP source sur le pare-feu ou ajouter une règle de suppression dans le SIEM
• Documenter précisément ce qui a été bloqué et à quelle heure
• Pare-feu / SIEM → règle de blocage → consigner l'action

Étape 6 — Restreindre le service visé

• Désactiver ou limiter l’accès au service exposé (RDP, SMB, SSH, etc.)
• Seulement si c’est sans risque et sans impact sur la production

Important : si une action de confinement peut affecter la disponibilité d’un service critique pour l’activité, s’arrêter et en parler d’abord à son L2 ou à son chef d’équipe.

Phase 4 — Documentation

Étape 7 — Tout documenter (au fil de l’eau, pas seulement à la fin)

• Chronologie des événements
• IP source et cible
• Schéma d’attaque et techniques observées
• Toutes les actions menées, avec leur horodatage
• Verdict : vrai positif / faux positif / bénin
• Écrire comme si quelqu’un d’autre allait le lire demain

Outil de ticketing / gestion des dossiers → INC-XXXX

Étape 8 — Mettre en place une surveillance

• Surveiller l’IP source et le compte visé pendant au moins 24 h
• Noter toute récidive et la rattacher au dossier d’origine

Phase 5 — Clôturer ou passer la main

Si c’est résolu en L1

• Clôturer le dossier avec un verdict et un résumé clairs
• Vérifier que toutes les actions sont consignées

Si c’est escaladé au L2

Transmettre un brief écrit et propre, avec :

• IP source et cible
• Chronologie complète
• Actions déjà menées
• Questions ouvertes ou incertitudes

Règles clés à retenir

• Documenter au fur et à mesure : ne jamais reconstituer de mémoire à la fin
• Dans le doute, escalader : un bon L1 qui escalade vite vaut mieux qu’un L1 qui devine
• Ne jamais toucher à la production sans en parler d’abord à son chef d’équipe
• Un passage de relais propre au L2 est une réussite : le rôle est de trier, confiner et briefer, pas de tout résoudre seul

Aide-mémoire — Event ID Windows

Références : NIST SP 800-61 Rev. 2 · PICERL (SANS Institute) · MITRE ATT&CK