Un runbook SOC est une procédure opérationnelle détaillée qui standardise la réponse à un type d'incident spécifique : trigger conditions, étapes d'investigation chiffrées, commandes prêtes à exécuter, critères de décision, escalades, actions de containment, post-mortem. Le NIST SP 800-61 Rev 2 (Computer Security Incident Handling Guide) structure tout runbook mature autour de 6 phases : Preparation, Detection and Analysis, Containment, Eradication, Recovery, Post-Incident Activity. Un SOC opérationnel en 2026 maintient typiquement 30 à 80 runbooks distincts couvrant les classes d'incidents les plus fréquents, exécutés manuellement par les analystes ou orchestrés via une plateforme SOAR (Cortex XSOAR, Splunk Phantom, Tines, Swimlane). Cet article détaille 5 runbooks prêts à adapter pour les classes d'incidents les plus courants en 2026 : phishing avec credential harvesting détecté, ransomware early indicator, lateral movement Active Directory, exfiltration data suspectée via DLP, compromission cloud account avec activité IAM anormale. Chaque runbook inclut trigger conditions, 8 à 12 étapes structurées, critères d'escalade et templates de communication.
Anatomie d'un runbook SOC
Un runbook standardisé suit une structure type qui garantit reproductibilité et formation rapide.
┌──────────────────────────────────────────┐
│ HEADER │
│ - Nom, version, date dernière revue │
│ - Auteur, owner, contributors │
│ - Severity, scope, RACI │
│ - Tags ATT&CK techniques │
├──────────────────────────────────────────┤
│ TRIGGER CONDITIONS │
│ - Quelles alertes déclenchent ce runbook │
│ - Sources de données nécessaires │
├──────────────────────────────────────────┤
│ INITIAL TRIAGE (5-10 min) │
│ - Validation alerte vs faux positif │
│ - Évaluation scope préliminaire │
├──────────────────────────────────────────┤
│ INVESTIGATION (10-60 min) │
│ - Étape 1, 2, 3... avec commandes │
│ - Critères de progression │
├──────────────────────────────────────────┤
│ CONTAINMENT │
│ - Actions immédiates (isolate, disable) │
│ - Validation impact business │
├──────────────────────────────────────────┤
│ ERADICATION & RECOVERY │
│ - Suppression cause racine │
│ - Restauration service │
├──────────────────────────────────────────┤
│ POST-INCIDENT │
│ - Documentation finale │
│ - Lessons learned │
│ - Mise à jour runbook │
├──────────────────────────────────────────┤
│ ESCALATION CRITERIA │
│ - Quand escalader L1 → L2 → L3 │
│ - Quand notifier IR / DPO / direction │
├──────────────────────────────────────────┤
│ TEMPLATES │
│ - Communications email/Slack │
│ - Ticket structure │
└──────────────────────────────────────────┘Runbook 1 — Phishing avec credential harvesting détecté
Trigger : utilisateur signale un email suspect via bouton dédié OU alerte SIEM sur clic vers domaine malveillant connu OU détection EDR de connexion à page phishing.
Severity initiale : medium. Élevée à high si credential probable saisi, critical si compte privilégié.
ATT&CK : T1566 (Phishing), T1110 (Brute Force) si credentials utilisés ensuite, T1078 (Valid Accounts).
Étape 1 — Réception et triage initial (5 min)
1.1 Récupérer l'email original (raw .eml ou .msg)
- Si signalé via bouton "Report Phishing" : extraire depuis dashboard
- Si remonté via SIEM : récupérer dans mailbox utilisateur
- Conserver headers complets (Received, Authentication-Results, ARC-*)
1.2 Identifier les indicateurs (IOC)
- Sender address (envelope From + display From)
- Reply-To si différent
- URLs dans le body (toutes, y compris dans liens texte)
- Attachments (filename + SHA256)
- Subject line keywords
1.3 Classer le type de phishing
- Credential harvesting (lien vers fake login)
- Malware delivery (attachment ou drive-by)
- Business Email Compromise (impersonation, fraude virement)
- Spear phishing cibléÉtape 2 — Enrichissement IOC (5 à 10 min)
# URL dans threat intel
# VirusTotal, urlscan.io, AbuseIPDB
curl -s "https://www.virustotal.com/api/v3/urls/$(echo -n 'https://fake-login.example.test' | base64 | tr -d '=' | tr '/+' '_-')" \
-H "x-apikey: $VT_API_KEY" | jq '.data.attributes.last_analysis_stats'
# Domaine WHOIS et âge
whois fake-login.example.test | grep -E 'Creation Date|Registrar'
# Hash attachment dans VirusTotal
curl -s "https://www.virustotal.com/api/v3/files/$ATTACHMENT_SHA256" \
-H "x-apikey: $VT_API_KEY" | jq '.data.attributes.last_analysis_stats'
# Email sender domain : SPF, DKIM, DMARC
dig TXT fake-domain.test | grep -E 'spf|dkim|dmarc'Étape 3 — Évaluation impact utilisateur (10 min)
3.1 L'utilisateur a-t-il cliqué sur le lien ?
- Logs proxy (Zscaler, Netskope, Cloudflare Gateway)
- Logs EDR DeviceNetworkEvents
- Browser history si accès à l'endpoint
3.2 L'utilisateur a-t-il saisi des credentials ?
- Demander directement à l'utilisateur (toujours)
- Logs IdP (Okta, Entra ID) : authentification depuis IP suspect
- Risk score IdP (Entra ID Identity Protection, Okta ThreatInsight)
3.3 L'utilisateur a-t-il téléchargé/exécuté un attachment ?
- Logs EDR DeviceProcessEvents et DeviceFileEvents
- Comparer hash local vs hash IOCÉtape 4 — Containment (5 à 30 min)
SI CREDENTIALS PROBABLES :
4.1 Reset password forcé immédiat (IdP central)
4.2 Révocation tous tokens/sessions (Entra ID Revoke-AzureADUserAllRefreshToken,
Okta Clear User Sessions, Google Workspace Clear Cookies)
4.3 Activation MFA si pas déjà actif
4.4 Surveillance compte 7 jours pour activité suspecte
SI MALWARE EXÉCUTÉ :
4.5 Isoler endpoint via EDR (CrowdStrike contain, SentinelOne quarantine)
4.6 Analyse forensique mémoire et disque
EN PARALLÈLE :
4.7 Bloquer URL/domaine au niveau proxy + DNS interne
4.8 Bloquer hash attachment au niveau EDR + email gateway
4.9 Rechercher autres utilisateurs ayant reçu le même email (search mail server)
4.10 Quarantiner les autres exemplaires si présents en mailboxÉtape 5 — Communication
Template Slack vers utilisateur :
Bonjour [PRÉNOM],
Suite au signalement d'un email suspect, le SOC a identifié une tentative
de phishing. Nous avons pris les actions suivantes par précaution :
- Réinitialisation de votre mot de passe (vous recevrez un email de
réinitialisation dans les 5 minutes)
- Déconnexion de toutes vos sessions actives sur les services entreprise
Aucune action de votre part n'est requise hormis la création d'un nouveau
mot de passe à votre prochaine connexion.
Si vous remarquez un comportement inhabituel sur vos comptes dans les
prochains jours (emails inattendus, fichiers modifiés), contactez-nous
immédiatement à soc@example.test.
Merci pour votre signalement, qui nous aide à protéger l'organisation.
L'équipe SOCÉtape 6 — Post-incident
6.1 Documentation finale (ticket SIEM/SOAR)
6.2 Mise à jour des règles de détection si pattern nouveau
6.3 Ajout des IOCs au TIP interne (MISP, OpenCTI)
6.4 Si campagne large : alerte interne tous utilisateurs
6.5 Si BEC ou impersonation CEO : notification DPO et direction
6.6 Statistique mensuelle phishing pour reportingRunbook 2 — Ransomware early indicator
Trigger : EDR détecte chiffrement massif fichiers en série OU alerte sur création de processus suspect (vssadmin, wmic shadow copy delete) OU ransomware family signature.
Severity initiale : critical (toujours).
ATT&CK : T1486 (Data Encrypted for Impact), T1490 (Inhibit System Recovery), T1489 (Service Stop).
Étape 1 — Confirmation immédiate (3 min)
1.1 Identifier l'host source : DeviceName, IP, utilisateur
1.2 Volume affecté : combien de fichiers déjà chiffrés
1.3 Pattern d'extension : .locked, .encrypted, .name-of-ransomware
1.4 Présence d'une note de ransom (ReadMe.txt, RECOVER.html, etc.)
1.5 Identifier la famille via signature : Lockbit, BlackCat/ALPHV, BlackBasta, Akira, PlayÉtape 2 — Containment ULTRA-PRIORITAIRE (5 à 10 min)
# 2.1 ISOLER l'endpoint immédiatement (pas de discussion)
# Via EDR
crowdstrike-cli contain --device-id $DEVICE_ID
# ou
sentinelone-cli isolate --hostname $HOSTNAME
# 2.2 Bloquer accès réseau au niveau switch ou firewall
# (en complément EDR au cas où agent compromis)
# Quarantine VLAN forcé
# 2.3 Identifier shares réseau accessibles par l'host
# pour détecter propagation potentielle
nmap --script smb-enum-shares -p 445 $HOST_IP
# 2.4 Désactiver compte utilisateur dans AD
# (si compromission credentials suspectée)
Disable-ADAccount -Identity $USERNAME
# 2.5 Vérifier autres hosts avec même pattern dans dernière heure
# Search EDR pour processus identique sur autres machinesÉtape 3 — Investigation initiale (15 à 60 min)
3.1 Initial access vector
- Email phishing ? (corréler avec runbook 1)
- RDP brute force ? (vérifier 4625 récents)
- Exploit vulnérabilité externe ? (vérifier perimeter logs)
- Compromis supply chain ? (logiciel récemment installé)
- Insider threat ?
3.2 Persistence et lateral movement
- Tâches planifiées créées récemment
- Services Windows nouveaux
- Accounts créés ou élevés en privilèges
- Credential dumping (corréler runbook 5)
3.3 Données affectées
- Quels shares réseau accédés depuis l'host
- Quelles bases de données accessibles depuis le compte
- Sauvegardes accessibles ?
3.4 Famille de ransomware
- Identifier précise via NoMoreRansom.org, ID Ransomware
- Vérifier si decryptor public existe
- Profil habituel du groupe (TTP, victimologie, demandes)Étape 4 — Activation IR formel
4.1 Notifier immédiatement :
- CISO / RSSI
- Direction (CTO, COO, CEO selon impact)
- Direction juridique (RGPD, communication)
- Cyber-assurance si applicable
4.2 Activer cellule de crise IR
- SOC + IR + IT Ops + Legal + Communication
4.3 Considérer assistance externe
- CSIRT pré-contractualisé (Mandiant, CrowdStrike Services,
Sekoia, Synacktiv, Wavestone IR)
- Pour OIV : ANSSI CERT-FR notification obligatoire
4.4 Notification réglementaire
- CNIL sous 72h si données personnelles affectées (RGPD article 33)
- NIS2 : notification ANSSI sous 24h pour entités essentielles
- Selon secteur : ACPR, ARCEP, etc.Étape 5 — Eradication et recovery (heures à jours)
5.1 Décision : payer ou non
- Position FBI/ANSSI : ne pas payer (finance crime, garantie zéro)
- Décision direction + cyber-assurance + legal
5.2 Restauration depuis backups
- Vérifier que les backups ne sont pas chiffrés (objectif principal des
attaques ransomware modernes)
- Identifier dernier backup propre (avant compromission)
- Restaurer en environnement isolé d'abord, valider intégrité
5.3 Reset complet credentials
- Tous les comptes potentially compromis
- krbtgt password reset (deux fois, 24h d'intervalle) si AD compromis
5.4 Patching et hardening
- Corriger la vulnérabilité d'initial access
- Hardener configuration (EDR partout, MFA partout, segmentation)Étape 6 — Post-incident
6.1 Post-mortem complet (NIST 800-61 phase 6)
6.2 Mise à jour des runbooks avec lessons learned
6.3 Threat hunting proactif sur autres machines
6.4 Communication interne et externe selon stratégie
6.5 Reporting régulateur final
6.6 Tabletop exercise dans les 3 mois pour tester améliorationsRunbook 3 — Lateral movement Active Directory
Trigger : alertes corrélées sur lateral movement (PsExec usage, WMI process creation, RDP from unexpected source) OU détection BloodHound activity OU successful Kerberoasting / AS-REP Roasting.
Severity initiale : high.
ATT&CK : T1021 (Remote Services), T1047 (WMI), T1003 (Credential Dumping), T1558 (Steal or Forge Kerberos Tickets).
Étape 1 — Confirmation et scope (5 à 15 min)
1.1 Identifier les hosts impliqués
- Source(s) du lateral movement
- Destination(s) accédée(s)
- Compte utilisé pour le mouvement
1.2 Évaluer privilèges du compte compromis
- User standard, admin local, admin domain ?
- Service account ?
- Comptes service AD avec SPN (potentiel Kerberoasting prior)
1.3 Tracer la chronologie
- Initial compromise timestamp
- Premier mouvement détecté
- Étendue actuelle (combien d'hosts touchés)Étape 2 — Containment ciblé (10 à 30 min)
# 2.1 Désactiver compte AD compromis
Disable-ADAccount -Identity "user.compromised"
# 2.2 Forcer expiration de ses tickets Kerberos
# (TGT et tous TGS issus)
klist purge -li 0x3e7 # purge tickets pour compte machine
# Reset password compte = invalidation tickets next refresh
# 2.3 Reset password du compte compromis
Set-ADAccountPassword -Identity "user.compromised" -NewPassword (Read-Host -AsSecureString)
# 2.4 Si admin domain compromis : reset krbtgt (DEUX FOIS, 10h d'intervalle)
# Cela invalide tous les Golden Tickets potentiels
Reset-KrbtgtKeyInteractive.ps1
# (script Microsoft officiel)
# 2.5 Isoler les hosts confirmés compromis via EDR
# (mais garder access pour forensics)
crowdstrike-cli contain --device-id $DEVICE_ID --keep-rtrÉtape 3 — Investigation forensique (1 à 4 h)
3.1 Sur chaque host source de mouvement
- Process tree complet
- Outils utilisés (Mimikatz, BloodHound, PsExec, Impacket)
- Fichiers déposés ou modifiés
- Tickets Kerberos extraits (si Mimikatz lsadump::tickets)
3.2 Chemins de privilege escalation
- BloodHound queries pour reproduire le chemin attaquant
- Identifier ACL abuse, GPO abuse, certificate abuse (ADCS ESC1-8)
3.3 Persistence Active Directory
- Création comptes (DCSync de Directory Replication permissions)
- Ajout aux groupes privilégiés
- Modification ACL Domain Admins, Enterprise Admins, Schema Admins
- Création GPO suspectes (Group Policy Objects nouveaux)
- Création Service Principal Names (SPN)Étape 4 — Eradication large
4.1 Reset comptes potentially affected
- Tous comptes admin AD (Domain Admins, Enterprise Admins,
Schema Admins, Backup Operators, Account Operators)
- Comptes service avec SPN
- Comptes ayant historique connexion sur hosts compromis
4.2 Audit AD complet
- Suppression comptes non légitimes
- Reset ACL modifiées
- Suppression GPO non légitimes
4.3 Reset krbtgt (deux fois, 10-24h d'intervalle)
Indispensable si compromission domaine confirmée.
Sans cela, les Golden Tickets potentiellement créés restent valides.
4.4 Audit ADCS si présent
- Vérification ESC1-ESC14 dans Certify ou PSPKIAudit
- Reset templates compromisÉtape 5 — Hardening post-incident
5.1 Tier 0 / Tier 1 / Tier 2 model
- Séparation stricte comptes admin domain (Tier 0) vs admin server (Tier 1)
vs admin workstation (Tier 2)
- Postes administrateurs dédiés (PAW)
5.2 Protected Users group + Authentication Policy Silos
5.3 LSA Protection (RunAsPPL)
5.4 Credential Guard
5.5 Réduction surface (suppression comptes service inutiles, désactivation NTLM
là où possible)Runbook 4 — Exfiltration de données suspectée (DLP alert)
Trigger : alerte DLP sur transfert volume anormal OU détection upload vers cloud storage non autorisé OU détection patterns de données sensibles dans flux sortant.
Severity initiale : high si données sensibles, medium si périmètre incertain.
ATT&CK : T1567 (Exfiltration Over Web Service), T1041 (Exfiltration Over C2 Channel), T1048 (Exfiltration Over Alternative Protocol).
Étape 1 — Validation et caractérisation (10 min)
1.1 Volume et destination
- Combien de Mo/Go transférés
- Destination IP / domain / service
- Protocole (HTTPS, SMTP, FTP, DNS tunneling)
1.2 Type de données
- PII (numéros sécurité sociale, IBAN, etc.)
- PCI (cartes bancaires)
- Propriété intellectuelle (code source, designs)
- Données réglementées (santé, RH)
1.3 User et host source
- Compte concerné
- Endpoint utilisé
- Légitimité business du transfert ?Étape 2 — Classification incident vs faux positif
Investigation différenciante :
- Upload légitime mal catégorisé (faux positif) ?
- Insider threat (employé exfiltre intentionnellement) ?
- Compte compromis utilisé par attaquant externe ?
- Malware exfiltrant automatiquement ?
Critères pour vrai positif :
- Volume disproportionné par rapport à activité habituelle
- Destination non-business (Dropbox personnel, Mega, Pastebin)
- Heures inhabituelles (nuit, weekend)
- Combiné avec préavis démission ou conflit RH récent
- Combiné avec autres alertes sécurité sur l'utilisateurÉtape 3 — Containment mesuré
3.1 Si confiance haute compte compromis externe :
- Désactivation compte immédiate
- Reset credentials
- Isolation endpoint
- Voir runbook lateral movement
3.2 Si insider threat suspecté :
- PAS d'action immédiate visible (préserver l'évidence)
- Notification IMMÉDIATE direction RH + juridique
- Préservation forensique (image disque, mémoire)
- Surveillance discrète des activités
- Coordination action concertée
3.3 Si accident utilisateur :
- Contact utilisateur, pédagogie
- Si possible, suppression données chez destinataire
- Mise à jour formationÉtape 4 — Investigation forensique
# Logs proxy détaillés
splunk search 'index=proxy src_user="user.suspect"
| stats sum(bytes_out) by dest_host, dest_url
| sort -sum(bytes_out)
| head 50'
# Logs cloud storage si applicable
# Microsoft Purview, Google Workspace Audit, AWS CloudTrail
# - Quels fichiers téléchargés ou partagés
# - Quels destinataires externes ajoutés
# Endpoint forensics
# - USB connecté ?
# - Email envoyé en pièce jointe ?
# - Capture d'écran activé sur écran sensible ?Étape 5 — Notification réglementaire
5.1 Évaluer si data breach au sens RGPD
- Données personnelles affectées ?
- Volume et nature
- Risque pour les personnes concernées
5.2 Notification CNIL
- Sous 72h si breach RGPD article 33
- Document data breach register interne
5.3 Information personnes concernées
- Si risque élevé (article 34 RGPD)
- Communication directe ou publique selon ampleur
5.4 Pour secteurs spécifiques
- HDS : notification ANSI/ASIP Santé
- Bancaire : ACPR
- OIV : ANSSI/CERT-FRRunbook 5 — Cloud account compromise (IAM activity anormale)
Trigger : alerte CSPM sur création de rôle IAM avec privilèges excessifs OU CloudTrail event suspicious (nouvelle key access créée, login depuis IP inhabituelle, escalade privilege) OU alerte GuardDuty / Defender for Cloud.
Severity initiale : high. Critical si compte production ou root account.
ATT&CK : T1078.004 (Valid Accounts: Cloud Accounts), T1098.001 (Account Manipulation: Additional Cloud Credentials).
Étape 1 — Évaluation rapide (5 à 10 min)
1.1 Identifier l'identité concernée
- User IAM, Role IAM, Service Account
- Permissions actuelles (effective permissions)
- Origine (création récente ou ancienne)
1.2 Évaluer activité anormale
- IP source : géolocalisation, connue ?
- User-Agent : SDK officiel, navigateur, outil tiers ?
- Volume d'API calls vs baseline
- APIs invoquées : management plane (création ressources, IAM) vs data plane (lecture S3)?Étape 2 — Containment cloud (5 à 15 min)
# 2.1 AWS : désactiver toutes les access keys
aws iam list-access-keys --user-name suspicious-user
aws iam update-access-key --user-name suspicious-user \
--access-key-id AKIA... --status Inactive
# 2.2 AWS : détacher toutes les policies
aws iam list-attached-user-policies --user-name suspicious-user
aws iam detach-user-policy --user-name suspicious-user --policy-arn ...
# 2.3 AWS : supprimer console password
aws iam delete-login-profile --user-name suspicious-user
# 2.4 Azure : disable user dans Entra ID
Set-MgUser -UserId user@example.test -AccountEnabled:$false
# 2.5 GCP : désactiver service account
gcloud iam service-accounts disable sa@project.iam.gserviceaccount.com
# 2.6 Tous : révoquer sessions actives
# AWS : aws iam delete-session-token (ne s'applique qu'à STS tokens)
# Azure : Revoke-MgUserSignInSessionÉtape 3 — Investigation CloudTrail / Activity Log (30 à 90 min)
3.1 Récupérer toutes les actions du principal compromis
sur les 30 derniers jours minimum
3.2 Identifier les actions à risque
- CreateUser, CreateRole, CreatePolicy
- AttachUserPolicy, AttachRolePolicy
- CreateAccessKey
- PutRolePolicy, PutUserPolicy
- AssumeRole vers rôles privilégiés
- CreateBucket, PutBucketPolicy (data exposure)
- ModifyDBSnapshot, CopySnapshot (data exfiltration)
3.3 Tracer les ressources créées ou modifiées
- Inventaire complet des changements
- Reverse engineering du chemin attaquantÉtape 4 — Eradication large
4.1 Suppression artefacts attaquant
- Comptes IAM créés
- Roles avec trust policy externe inattendue
- Access keys non légitimes
- Lambda functions backdoor
- EC2 instances de cryptojacking (si applicable)
4.2 Reset credentials autres comptes potentially affected
- Si compte avait permissions élevées : audit large
4.3 Si root account AWS compromis
- Reset password root
- Reset MFA root (réémission token)
- Audit complet de toutes les ressources créées
- Considérer migration vers nouveau compte AWSÉtape 5 — Hardening post-incident
5.1 Migration vers OIDC federation
- Suppression des access keys long-lived restantes
- Federation depuis CI vers cloud via OIDC
5.2 SCP (Service Control Policies) pour limiter le scope possible
5.3 GuardDuty / Defender for Cloud activé partout
5.4 IAM Access Analyzer activé pour détection chemins risk
5.5 CloudTrail multi-region + Organization trail + KMS encryption + log file integrity validation
5.6 Alerting sur APIs sensibles (Console login from unusual IP, IAM changes, etc.)Outils SOAR pour automatiser
L'automation des runbooks via SOAR libère 60 à 80 % du temps L1 sur les actions répétitives.
| SOAR | Type | Particularité |
|---|---|---|
| Cortex XSOAR (Palo Alto) | Commercial leader | Marketplace 800+ packs intégrations |
| Splunk Phantom (SOAR) | Commercial | Intégration native Splunk SIEM |
| Tines | Commercial | No-code workflow, démarrage rapide |
| Swimlane | Commercial | Personnalisation forte, low-code |
| Shuffle | Open source | Open source, communauté grande |
| n8n + plugins security | Open source | Workflow général + bundles sécu |
Actions automatisables sans risque
- Enrichissement IOC (VirusTotal, AbuseIPDB, MISP).
- Création ticket SOAR/Jira/ServiceNow.
- Notification Slack/Teams.
- Recherche cross-source (SIEM + EDR + cloud).
- Génération rapport de triage.
Actions à garder en humain
- Containment (isolate endpoint, disable account) sans validation.
- Communication externe (CNIL, clients).
- Décision payer rançon ou non.
- Reset krbtgt domaine (impact opérationnel majeur).
Métriques et amélioration continue
Les KPIs qui pilotent un programme runbook efficace.
| Métrique | Définition | Cible 2026 |
|---|---|---|
| MTTD (Mean Time to Detect) | Temps entre incident et détection | Inférieur à 1 heure pour critical |
| MTTR (Mean Time to Respond) | Temps entre détection et containment | Inférieur à 4 heures pour critical |
| Runbook utilisation rate | % d'incidents traités via runbook formal | Supérieur à 80 % |
| Runbook update frequency | % runbooks revus dans les 90 jours | 100 % |
| FP rate par runbook | % faux positifs détectés via runbook | Suivi par règle, tendance baissière |
| Escalation rate L1→L2 | % alertes escalées | 15 à 30 % typique |
| Customer satisfaction (interne) | Survey utilisateurs après IR | Supérieur à 4/5 |
Points clés à retenir
- Un runbook SOC est une procédure standardisée pour un type d'incident, structurée selon les 6 phases NIST SP 800-61 (Preparation, Detection, Containment, Eradication, Recovery, Post-Incident).
- Cinq runbooks couvrent 70 % des incidents fréquents : phishing avec credential harvesting, ransomware early indicator, lateral movement AD, exfiltration data via DLP, cloud account compromise.
- Le SOAR (Cortex XSOAR, Splunk Phantom, Tines, Shuffle) automatise 60 à 80 % du temps L1 sur l'enrichissement et la notification. Garder en humain les actions à fort impact opérationnel.
- La maintenance est non négociable : revue trimestrielle systématique, mise à jour post-incident sous 7 jours, versioning Git, tests semestriels via tabletop exercises.
- Les KPIs MTTD et MTTR pilotent l'efficacité. Pour critical : MTTD inférieur à 1 heure, MTTR inférieur à 4 heures avec runbook structuré et SOAR.
Pour aller plus loin
- Alertes SOC : 7 cas d'analyse pas-à-pas - règles de détection qui déclenchent les runbooks.
- Container escape : techniques et défenses - contexte technique pour runbook lateral movement vers infrastructure container.
- Sécurité d'un VPS : checklist - hardening qui réduit le périmètre exposé au SOC.
- Secrets management cloud - prévention des compromissions IAM cloud.
