Niveau Debutant

Architecture & Fondamentaux du SOC

Comprendre la structure, les roles, les workflows et les outils d'un Security Operations Center moderne

Sommaire

🏗 Architecture SOC - Tiers 1/2/3

Un SOC (Security Operations Center) est l'centre nerveux de la securite d'une organisation. Il fonctionne sur un modele de triage par niveaux permettant d'escalader les incidents selon leur complexite et leur severite.

Pourquoi c'est important : À 3h du matin, 400 alertes tombent après une vague de phishing. Sans architecture en Tiers 1/2/3, tout le monde traite tout et le vrai ransomware passe. Avec les tiers, le Tier 1 filtre en 10 minutes et le Tier 2 ne reçoit que les 5 cas graves. C'est ce qui sépare un SOC qui tient l'astreinte d'un SOC submergé.
L'analogie qui aide : Pense aux urgences d'un hôpital : l'accueil trie (Tier 1), le médecin généraliste diagnostique (Tier 2), le chirurgien opère (Tier 3). Personne ne demande au chirurgien de prendre la température à l'entrée.

Structure Hierarchique du SOC

┌─────────────────────────────────────────┐ │ SOC Manager / CISO │ │ (Supervision Strategique) │ └──────────────────┬──────────────────────┘ │ ┌──────────────────┴──────────────────────┐ │ SOC Team Lead / Senior │ │ (Coordination operationnelle) │ └──────┬───────────────┬──────────────────┘ │ │ ┌────────────┴──┐ ┌───────┴────────────┐ │ Tier 3 │ │ Tier 2 │ │ Experts │ │ Analystes │ │ (Forensics) │ │ (Investigation) │ └───────────────┘ └───────┬────────────┘ │ ┌──────────┴──────────────┐ │ Tier 1 │ │ Analystes SOC │ │ (Triage & Monitoring) │ └─────────────────────────┘

Tier 1 - Analyste SOC (Triage)

Le premier niveau de defense. Les analystes Tier 1 sont responsables du monitoring continu et du triage initial des alertes.

Competences Tier 1 : Lecture de logs, compréhension des alertes SIEM, connaissance de base des protocols reseau, utilisation d'EDR, documentation d'incidents.

Tier 2 - Analyste Securite (Investigation)

Le deuxieme niveau approfondit l'investigation des alertes escaladees par le Tier 1.

Tier 3 - Expert Securite (Forensics)

Le troisieme niveau est compose d'experts specialises dans l'analyse forensique et la reponse avancee.

Important : Dans les petits SOC, un seul analyste peut couvrir plusieurs tiers. L'objectif est de toujours maintenir une separation claire des responsabilites meme avec peu de personnel.
Démonstration pas à pas : Alerte EDR « mimikatz.exe sur PC-COMPTA-04 » à 22h14. Étape 1 : Tier 1 ouvre le ticket, vérifie l'asset dans l'inventaire et qualifie P2. Étape 2 : Tier 1 escalade avec capture d'écran et hash. Étape 3 : Tier 2 corrèle avec les logs SIEM et trouve une connexion RDP anormale. Étape 4 : Tier 2 isole la machine et transmet au Tier 3 pour forensique mémoire. Livrable : ticket documenté et horodaté, sans coupure inutile.

SOC Types

Pièges classiques : Escalader sans contexte (« regardez cette alerte » sans asset, heure ni criticité). Confondre MSSP et Tier : externaliser ne supprime pas le besoin de triage interne. En entretien, ne dis jamais « le Tier 1 fait du forensique » : chaque tier a son périmètre.
À vous de jouer : Une alerte P3 « scan de ports » et une alerte P1 « ransomware confirmé » arrivent ensemble, un seul analyste Tier 1 est présent. Que fait-il en premier ?
Voir la réponse

Il traite la P1 en priorité : ouverture du ticket, vérification rapide, escalade immédiate au Tier 2 avec contexte. La P3 est mise en file et qualifiée ensuite. Prioriser par sévérité et impact, pas par ordre d'arrivée.

👥 Roles et Responsabilites

Chaque membre du SOC a un role precise dans la chaine de securite. Voici les principaux postes et leurs responsabilites.

Pourquoi c'est important : Lors d'un audit, l'auditeur demande « qui a validé le confinement du serveur de paie ». Si les rôles sont flous, personne ne répond et l'audit échoue. Des responsabilités claires permettent de savoir qui décide, qui exécute et qui rend compte, surtout sous pression.
L'analogie qui aide : Comme une équipe de foot : le manager définit la stratégie, le capitaine organise sur le terrain, les joueurs exécutent. Si tout le monde veut être gardien, le but reste vide.

SOC Manager

SOC Team Lead

Security Analyst (Tier 1/2/3)

Threat Hunter

Incident Responder

SOC Engineer

Démonstration pas à pas : Incident phishing signalé par un utilisateur. Étape 1 : l'analyste Tier 1 qualifie et applique le runbook. Étape 2 : le Team Lead valide l'escalade vers l'Incident Responder. Étape 3 : le Responder confine et demande au SOC Engineer de bloquer le domaine au proxy. Étape 4 : le Threat Hunter cherche d'autres victimes. Livrable : chaque action est tracée avec son auteur et son heure.
Conseil : En tant que debutant, visez d'abord un poste de Tier 1 Analyst. C'est la base solide pour evoluer vers des roles plus specialises.
Pièges classiques : Vouloir viser directement Threat Hunter sans passer par le triage : tu manques les fondamentaux de lecture de logs. Autre erreur : le SOC Engineer qui modifie une règle SIEM en production sans validation, et aveugle tout le SOC pendant une semaine.
À vous de jouer : Qui valide une escalade critique et qui isole techniquement la machine ?
Voir la réponse

Le SOC Team Lead valide l'escalade et la décision critique, l'Incident Responder ou l'analyste Tier 2 exécute le confinement avec l'appui du SOC Engineer. Décision et exécution restent séparées pour garder le contrôle.

🔄 Workflow d'un Incident SOC

Le cycle de vie d'un incident SOC suit un processus structuré inspiré du framework NIST SP 800-61.

Pourquoi c'est important : Le jour d'un ransomware, sans workflow NIST tu confines trop tard et tu effaces les preuves en éteignant les machines. Avec les 4 phases, tu sais quoi faire à chaque heure : détecter, analyser, contenir, capitaliser. Le management et la justice exigent cette traçabilité.
L'analogie qui aide : Comme une enquête policière : constat (détection), enquête (analyse), interpellation (réponse), procès-verbal et retour d'expérience (post-incident). Sauter une étape fait échouer tout le dossier.

Les 4 Phases du Cycle de Vie

┌──────────────┐ ┌──────────────┐ ┌──────────────┐ ┌──────────────┐ │ 1. Detection │ ──▶ │ 2. Analyse │ ──▶ │ 3. Reponse │ ──▶ │ 4. Post- │ │ & Tri │ │ & Escalade │ │ & Contain. │ │ Incident │ └──────────────┘ └──────────────┘ └──────────────┘ └──────────────┘ │ │ │ │ Alertes SIEM Investigation Containment Lessons Learned Alertes EDR Correlation Eradication Hardening Threat Intel Qualification Recovery Playbook Update User Reports Documentation Communication Metrics Review

Phase 1 : Detection et Triage

  1. Reception de l'alerte (SIEM, EDR, NDR, email, telephone)
  2. Verification de l'alerte : est-ce un vrai positif ?
  3. Classification de severite (P1 a P4)
  4. Ouverture du ticket d'incident (ServiceNow, Jira)
  5. Documentation initiale : timestamp, sources, premieres observations

Phase 2 : Analyse et Escalade

  1. Recherche de contexte : logs historiques, Asset inventory
  2. Correlation avec d'autres alertes / IOC
  3. Determination de l'impact (scope, systèmes touches)
  4. Escalade si necessaire (Tier 2, Tier 3, Management)
  5. Enrichissement avec Threat Intelligence
Démonstration pas à pas : Alerte SIEM « connexion impossible travel » pour le compte direction. Étape 1 : détection, ouverture du ticket P2 avec horodatage. Étape 2 : analyse, corrélation avec les logs VPN et enrichissement Threat Intel sur l'IP. Étape 3 : réponse, réinitialisation forcée du mot de passe et révocation des sessions. Étape 4 : post-incident, ajout d'une règle de détection et note au rapport. Livrable : ticket complet de l'alerte à la leçon apprise.

Phase 3 : Reponse et Containment

  1. Containment court terme : Isolation reseau, desactivation de comptes
  2. Containment long terme : Patch, reconfiguration, migration
  3. Eradication : Suppression du malware, nettoyage du systeme
  4. Recuperation : Restauration des services, verification
  5. Communication : Notification aux parties prenantes

Phase 4 : Post-Incident

  1. Post-mortem / Post-incident review
  2. Identification des ameliorations
  3. Mise a jour des playbooks
  4. Creation de nouvelles regles de detection
  5. Reporting et metriques
Regle d'or : Ne jamais detruire de preuves pendant l'investigation. Toute action de reponse doit etre documentee et horodatee pour maintenir la chaine de preuve.
Pièges classiques : Éteindre la machine infectée et perdre la mémoire vive, ou rebrancher trop vite le poste « pour rendre service » avant éradication. Autre faute : documenter après coup, sans horodatage, ce qui rend le rapport inutilisable en audit.
À vous de jouer : Tu suspectes un ransomware : éteins-tu le poste immédiatement ?
Voir la réponse

Non. Tu isoles du réseau via EDR ou pare-feu sans éteindre, pour préserver la mémoire, puis tu suis le runbook : ticket, escalade, forensique. Éteindre détruit les preuves volatiles.

🔧 Tool Stack SOC

Un SOC moderne utilise un ecosysteme d'outils interconnectes. Voici les categories essentielles.

Pourquoi c'est important : Sans SIEM central, chaque alerte reste isolée : l'EDR voit le malware, le firewall voit la connexion, personne ne relie les deux. La veille d'un audit, tu dois prouver la couverture de bout en bout. La tool stack connectée (sources vers SIEM vers SOAR vers ticketing) donne cette vision unique.
L'analogie qui aide : Comme la tour de contrôle d'un aéroport : les radars (EDR, NDR), la radio (logs), l'ordinateur central (SIEM) et les procédures d'urgence (SOAR). Sans tour, les avions se croisent à l'aveugle.

SIEM (Security Information and Event Management)

Le coeur du SOC. Collecte, normalise et corrige les evenements de securite.

EDR (Endpoint Detection and Response)

Surveillance avancee des postes de travail et serveurs.

NDR (Network Detection and Response)

SOAR (Security Orchestration, Automation and Response)

Démonstration pas à pas : Phishing reçu par 30 utilisateurs. Étape 1 : le SIEM agrège les signalements et l'EDR remonte l'URL. Étape 2 : le SOC enrichit via la TIP (MISP) et confirme le malveillant. Étape 3 : le SOAR bloque le domaine au proxy et met en quarantaine les mails. Étape 4 : ticket TheHive créé et notification envoyée. Livrable : 30 alertes regroupées en un seul incident traité.

Outils Complementaires

Architecture de reference : Les flux de donnees suivent generalement : Sources → Collecteurs → SIEM → Detection/Correlation → SOAR → Ticketing → Notification.
Pièges classiques : Acheter un SIEM avant de brancher les bonnes sources : tu as un moteur sans carburant. Autre erreur : multiplier les outils sans intégration, chaque console devient un silo et le temps de réponse explose.
À vous de jouer : Quel est le chemin d'une donnée d'alerte, de la source à la notification ?
Voir la réponse

Sources vers collecteurs vers SIEM pour détection et corrélation, puis SOAR pour la réponse automatisée, puis ticketing et notification. Si un maillon manque, l'alerte se perd ou arrive sans contexte.