Fiches mémo SOC

Fiche 1 — MTTD et MTTR : les deux indicateurs vitaux

Indicateur	Définition	Cible conseillée	Lecture
MTTD (Mean Time To Detect)	Temps moyen entre le début d’un incident et sa détection par le SOC	< 10 minutes	Un MTTD court prouve une collecte et une détection efficaces.
MTTR (Mean Time To Respond)	Temps moyen entre la détection et le retour à la normale (confinement, éradication, récupération)	< 1 heure	Un MTTR long malgré un bon MTTD pointe vers la réponse : playbooks incomplets, escalades floues, manque d’automatisation.

Exemple : MTTD de 4 minutes mais MTTR de 9 heures = la détection va bien, la réponse est à reconstruire (runbooks, habilitations de confinement, automatisation des actions répétitives).

Fiche 2 — Cycle de traitement d’un incident

1. Détection et qualification (L1). Trier l’alerte en 15 minutes : vrai ou faux positif, criticité P1 à P4, ouverture du ticket horodaté.
2. Confinement. Isoler sans détruire : isolation réseau via l’EDR (jamais d’extinction brutale qui efface la mémoire), blocage du domaine au proxy et au DNS.
3. Éradication. Supprimer la cause : mots de passe réinitialisés, règles malveillantes supprimées, vecteur d’entrée fermé.
4. Récupération. Remise en production sous surveillance renforcée (72 heures à 7 jours selon la criticité).
5. Post-incident. Rapport structuré (chronologie, IOC, causes), retour d’expérience sans blâme, recommandations avec pilote et délai.

Fiche 3 — Runbook essentiel : réponse au phishing

1. Qualification (15 min max). En-tête du message, expéditeur réel, URL et pièces jointes, réputation. Aucun clic = P3, quarantaine simple.
2. Confinement. Quarantaine du message, blocage du domaine et de l’URL, isolation des postes ayant cliqué, révocation des sessions.
3. Éradication. Réinitialisation des mots de passe exposés, analyse complète, suppression des règles de transfert malveillantes.
4. Récupération. Remise en service contrôlée, surveillance renforcée 7 jours sur les comptes concernés.
5. Post-incident. IOC versés au fil de threat intelligence, exemple anonymisé pour la sensibilisation.

Escalade L1 vers L2 : clic sur un poste comptabilité, direction ou informatique ; plus de 5 destinataires ; suspicion de compromission de compte. P1 : qualification 10 minutes, escalade 15 minutes via l’astreinte.

Fiche 4 — KPI du tableau de bord mensuel

Indicateur	Cible	Source des données
MTTD	< 10 min	SIEM (détection moins première trace)
MTTR	< 1 h	Outil de tickets (clôture moins détection)
Taux de faux positifs	< 15 %	Alertes non pertinentes / total des alertes
Conformité aux playbooks	> 90 %	Incidents traités selon le runbook
Couverture MITRE ATT&CK	> 70 %	Techniques couvertes par au moins une détection

Présentez tendances et décisions, pas le volume brut d’alertes. Un KPI sans source fiable n’a aucune valeur.

Fiche 5 — Matrice RACI du SOC (extrait)

Activité	L1	L2	L3 / Forensique	Resp. SOC	RSSI / Direction
Qualification d’une alerte	R	C	—	I	—
Isolation d’un poste standard	R	A	—	I	—
Isolation d’un serveur de production	—	R	C	A	I
Blocage d’un domaine au proxy	R	A*	—	I	—
Communication externe / presse	—	—	C	R	A
Clôture et rapport d’incident	R	R	C	A	I

R = réalise, A = approuve (une seule personne par activité), C = consulté, I = informé. * P1 en heures ouvrées : approbation possible a posteriori sous 1 heure (procédure de crise).

Fiche 6 — Commandes et requêtes SIEM de base

Exemples tirés des cours SIEM et des livrables. Adaptez les noms d’index et de tables à votre plateforme.

Microsoft Sentinel (KQL) — courriels suspects

EmailEvents
| where SenderFromAddress contains "suspect"
| project Timestamp, RecipientEmailAddress, Subject, Url

Splunk (SPL) — exécutions PowerShell encodées

index=windows (EventCode=4688 OR EventCode=4104) powershell *-enc*
| stats count by User, ParentImage, CommandLine
| where count < 100

Chasse générique — beaconing DNS (requêtes régulières volumineuses)

index=dns
| stats count, avg(bytes_out) as volume by src_ip, query
| where count > 50 AND volume > 500

• Affinez toujours avec le contexte : processus parent inhabituel, utilisateur non administrateur, encodage combiné à une connexion réseau.
• Testez chaque règle sur 30 jours d’historique avant la mise en production, puis mesurez les faux positifs règle par règle.
• Journalisez les enrichissements (cache 24 h) et prévoyez un mode dégradé si une API de réputation est indisponible.