Niveau Expert
Automatisation & Maturite SOC
Automatiser avec Azure, gerer la Threat Intelligence, integrer MDR/MSSP et mesurer la maturite
🤖 SOC Automation - Logic Apps & Azure Functions
L'automatisation avancee du SOC repose sur Azure Logic Apps pour le workflow orchestre et Azure Functions pour le code serverless event-driven.
Pourquoi c'est important : Lors d'une campagne de phishing massive un vendredi soir, traiter 200 mails à la main prend la nuit entière. Avec Logic Apps qui orchestre et Functions qui enrichit via VirusTotal et AbuseIPDB, le tri est fait en minutes. L'équipe ne garde que les cas confirmés, avec ticket et blocage déjà préparés.
L'analogie qui aide : Comme une cuisine centrale : Logic Apps est le chef qui répartit les plats, Functions sont les cuisiniers spécialisés (sauce VirusTotal, découpe AbuseIPDB). Sans chef, chacun cuisine dans son coin et le service s'effondre.
Architecture d'Automatisation SOC
Alert SIEM ──▶ Logic App ──┬──▶ Azure Function (Enrichissement)
(Sentinel) (Orchestrateur)│ │
│ ┌────▼────────────────┐
│ │ VirusTotal API │
│ │ AbuseIPDB API │
│ │ Shodan API │
│ └────┬────────────────┘
│ │
├──▶ Action: Isoler (FW API)
├──▶ Action: Ticket (ServiceNow)
└──▶ Action: Notify (Teams/Slack)
Azure Logic Apps - Exemples
// Logic App: Reponse Automatique au Phishing
// Declencheur: Alerte Sentinel de phishing
1. TRIGGER: Azure Sentinel - When alert is created
- Filter: AlertName contains "Phishing"
- Severity: High OR Critical
2. EXTRACT: Obtenir les IOCs de l'alerte
- Parse JSON: Sender, URL, Domains, IPs
3. ENRICHMENT: Azure Function "EnrichIOCs"
- VirusTotal: Verifier reputation URL
- AbuseIPDB: Verifier reputation IP
- OQRS: Verifier si domaine est lookalike
4. CONDITION: Si IOCs confirmes malveillants
a. CALL FUNCTION: BlockDomain (Zscaler API)
b. CALL FUNCTION: QuarantineEmail (Exchange API)
c. CREATE TICKET: ServiceNow (P2 - Phishing Confirme)
d. SEND MESSAGE: Teams channel #soc-alerts
e. UPDATE ALERT: Ajouter commentaires d'enrichissement
5. CONDITION: Si faux positif
a. CLOSE ALERT: Ajouter reason "False Positive"
b. UPDATE WHITELIST: Ajouter domaine legitimate
Azure Functions - Code
// Azure Function: EnrichIOCs (C#)
[FunctionName("EnrichIOCs")]
public static async Task<IActionResult> Run(
[HttpTrigger(AuthorizationLevel.Function, "post")] HttpRequest req,
ILogger log)
{
var request = await JsonSerializer.DeserializeAsync<IOCRequest>(req.Body);
var results = new List<IOCResult>();
foreach (var ioc in request.IOCs)
{
var result = new IOCResult { Value = ioc.Value, Type = ioc.Type };
// Enrichissement VirusTotal
if (ioc.Type == "url" || ioc.Type == "ip")
{
var vtResult = await _vtClient.ScanAsync(ioc.Value);
result.Reputation = vtResult.Malicious ? "malicious" : "clean";
result.Score = vtResult.DetectionRatio;
}
// Enrichissement AbuseIPDB
if (ioc.Type == "ip")
{
var abuseResult = await _abuseClient.CheckAsync(ioc.Value);
result.AbuseConfidence = abuseResult.ConfidenceScore;
}
results.Add(result);
}
return new OkObjectResult(results);
}
// Azure Function: IsolateHost (C#)
[FunctionName("IsolateHost")]
public static async Task<IActionResult> Run(
[HttpTrigger(AuthorizationLevel.Function, "post")] HttpRequest req,
ILogger log)
{
var request = await JsonSerializer.DeserializeAsync<IsolateRequest>(req.Body);
// Isoler via Azure NSG
await _nsgClient.AddRuleAsync(
request.HostName,
"SOC-Isolation",
"DenyAllInbound",
"*",
"*",
"*",
"Deny",
100);
// Notification
await _teamsClient.SendMessageAsync(
$"Host {request.HostName} isole automatiquement. Raison: {request.Reason}");
return new OkObjectResult(new { status = "isolated", host = request.HostName });
}
Scenarios d'Automatisation
- Enrichissement automatique : IOCs → Threat Intel APIs → Score de confiance
- Containment automatique : P1 alert → Isolation reseau → Ticket creation
- Provisioning securise : Demande d'acces → Validation manager → Creation compte
- Rotation de cles : Cron job → Rotation secrets → Verification → Notification
- Compliance scan : Planning → Scan vulnerabilites → Rapport → Alerte si ecart
Démonstration pas à pas : Alerte phishing haute sévérité dans Sentinel. Étape 1 : déclencheur Logic App et extraction des IOC. Étape 2 : Function EnrichIOCs interroge VirusTotal et AbuseIPDB. Étape 3 : si malveillant, blocage Zscaler, quarantaine Exchange, ticket ServiceNow P2 et message Teams. Étape 4 : si bénin, fermeture en faux positif et liste blanche. Livrable : réponse complète horodatée sans copier-coller manuel.
Critique : Tout code d'automatisation SOC doit passer par un processus de code review et de test avant deploiement. Une automatisation erronee peut paralyser les operations.
Pièges classiques : Déployer une Function IsolateHost sans test et isoler tout un VLAN de production. Ou coder les clés API en dur dans la Function : fuite assurée au premier audit. Code review et coffre de secrets obligatoires.
À vous de jouer : Ton playbook bloque automatiquement un domaine. Quelle sécurité ajoutes-tu avant mise en production ?
Voir la réponse
Une revue de code, des tests sur des faux positifs connus, un seuil de confiance et une validation humaine pour les domaines sensibles. Plus un bouton de rollback pour débloquer vite en cas d'erreur.
💡 Threat Intelligence Platform
Une TIP centralise, enrichit et distribue les indicateurs de compromission (IOCs) et les techniques, tactics et procedures (TTPs).
Pourquoi c'est important : Quand l'ANSSI publie des IOC d'une campagne active, sans TIP tu les copies à la main et tu les oublies dans un tableur. Avec MISP ou OpenCTI connecté au SIEM, le matching est automatique et l'alerte sort dès qu'une IP malveillante touche ton réseau. C'est vital avant un audit de couverture.
L'analogie qui aide : Comme un fichier des personnes recherchées : le niveau stratégique dit quelles gangs sévissent, le niveau technique donne les photos (hash, IP, domaine) que chaque patrouille (SIEM) peut reconnaître.
Niveaux de Threat Intelligence
- Strategique : Tendances de menaces, direction des investissements securite
- Tactique : TTPs des adversaires, objectifs, mode operandi
- Operationnelle : Campagnes actives, outils utilises, timing
- Technique : IOCs (IPs, domains, hashes, URLs), signatures
Sources de Threat Intelligence
- Open Source (OSINT) : MISP, AlienVault OTX, Abuse.ch, PhishTank, URLhaus
- Commerciales : Recorded Future, Mandiant, CrowdStrike Intelligence, Palo Alto Unit 42
- Gouvernementales : ANSSI, CISA, CERT-FR, ECHO CTI
- Communautaires : ISACs (sectoriels), FS-ISAC, H-ISAC
Framework MITRE ATT&CK
Le referentiel de TTPs le plus utilise pour mapper les comportements d'adversaires.
Reconnaissance ──▶ Ressource Dev ──▶ Intrusion ──▶ Exploitation ──▶ Installation
(T1595) (T1583) (T1190) (T1059) (T1053)
│ │
└──────────────────────────────────────────────────────────────┘
Exfiltration ──▶ Impact ──▶ Command & Control
(T1041) (T1486) (T1071)
Exemple de Integration TIP-SIEM
// Sentinel: Matching IOCs Threat Intel automatique
// Table ThreatIntelligence
threatintelligence
| where TimeGenerated > ago(7d)
| join kind=inner (
DeviceNetworkEvents
| where RemoteIP != ""
) on $left.IOCValue == $right.RemoteIP
| project Timestamp, DeviceName, RemoteIP, ThreatType, Confidence
Démonstration pas à pas : IOC malveillant reçu via MISP. Étape 1 : ingestion automatique dans la table ThreatIntelligence. Étape 2 : jointure KQL avec DeviceNetworkEvents sur 7 jours. Étape 3 : identification des machines ayant contacté l'IP et qualification par confiance. Étape 4 : création d'incident et partage en retour à la communauté. Livrable : détection corrélée avec traçabilité de la source.
Bonnes pratiques : 1) Automatiser l'ingestion des IOCs. 2) Enrichir avant de corréler. 3) Valider la fiabilite des sources. 4) Partager avec la communaute.
Pièges classiques : Ingérer des flux OSINT sans scoring : des milliers d'IOC périmés qui noient le SIEM. Ou utiliser un hash sans contexte TTP : tu bloques sans comprendre la campagne et tu rates le vrai vecteur.
À vous de jouer : Un IOC Abuse.ch signale une IP avec confiance faible. La bloques-tu directement ?
Voir la réponse
Non. Tu enrichis d'abord (VirusTotal, historique, criticité des assets exposés), tu surveilles ou mets en alerte, et tu ne bloques qu'avec une confiance suffisante et validation. Un blocage aveugle crée des faux positifs.
🏭 MDR / MSSP
MDR (Managed Detection and Response) et MSSP (Managed Security Service Provider) sont des modeles d'externalisation des operations de securite.
Pourquoi c'est important : Une ETI sans équipe 24/7 subit un ransomware un samedi sans personne pour répondre. Un MDR assure la détection et la réponse la nuit pendant que ton équipe garde le pilotage le jour. Mal cadré, tu perds la visibilité et découvres l'incident par la presse.
L'analogie qui aide : Comme la sécurité d'un site : le MSSP est le gardien qui tient les portes et les rondes, le MDR est l'équipe d'intervention qui analyse les intrusions et neutralise. Les deux protègent, pas de la même façon.
Differences MDR vs MSSP
| Critere |
MSSP |
MDR |
| Focus |
Infrastructure & operations |
Detection & reponse aux menaces |
| Services |
Firewall, IDS/IPS, logs, patching |
Monitoring, investigation, reponse |
| Analyse |
Alertes generees, triage basique |
Investigation profonde, threat hunting |
| Reponse |
Notification a l'equipe interne |
Actions correctives directes |
| Couverture |
24/7 infrastructure |
24/7 detection & reponse |
Avantages MDR
- Acces a des experts specialises sans les recruter
- Couverture 24/7 avec des equipes dediees
- Capacites de threat hunting avancees
- Temps de reduit (MTTD/MTTR plus faibles)
- Integrations avec les outils existants
Considerations pour le Choix
- Couverture geographique : Support local ou global ?
- Integration : Compatibilite avec votre stack technique
- SLA : Temps de reponse garanti, escalade
- Transparence : Reporting, visibilite des operations
- Cout : Opex vs Capex, modeles de pricing
Démonstration pas à pas : Alerte critique à 3h du matin. Étape 1 : le MDR détecte et investigue avec ton EDR. Étape 2 : il isole la machine selon le SLA et t'appelle via l'astreinte. Étape 3 : ton équipe valide la portée métier le matin. Étape 4 : rapport commun avec MTTD et MTTR contractuels. Livrable : réponse 24/7 sans recruter trois équipes de nuit.
Modele hybride recommande : Beaucoup d'organisations combinent un MSSP pour l'infrastructure avec un SOC interne ou MDR pour la detection et la reponse avancee.
Pièges classiques : Signer un MSSP qui ne fait que transférer des alertes brutes sans investigation, ou choisir sans SLA de réponse mesurable. En entretien, distingue clairement : MSSP gère l'infrastructure, MDR chasse et répond.
À vous de jouer : Tu as un petit SOC de jour uniquement. MSSP ou MDR pour la nuit ?
Voir la réponse
MDR, car tu as besoin de détection et réponse avec investigation, pas seulement de gestion d'infrastructure. Exige SLA, transparence des actions et compatibilité avec ta stack EDR et SIEM.
📈 SOC Maturity Model
Le modele de maturite evalue la capacite et l'efficacite d'un SOC a travers des niveaux croissants de sophistication.
Pourquoi c'est important : Devant un COMEX qui veut de l'IA partout alors que tu n'as ni playbooks ni KPI, le modèle de maturité justifie la feuille de route : viser d'abord le niveau 3 défini avant le niveau 5. Sans cela, tu investis dans la déception technologique alors que le triage de base échoue.
L'analogie qui aide : Comme les ceintures de judo : on ne vise pas la noire en un an. Chaque niveau exige des katas maîtrisés (SIEM, playbooks, KPI, hunting) avant de passer au suivant.
Niveaux de Maturite
Niveau 1: Initial ──▶ Alertes manuelles, reactif
Niveau 2: Developing ──▶ SIEM de base, procedures ecrites
Niveau 3: Defined ──▶ SOAR, playbooks, KPIs mesures
Niveau 4: Managed ──▶ Threat hunting, ML, automation avancee
Niveau 5: Optimizing ──▶ AI-driven, deception, purple teaming
Niveau 1 - Initial
- Alertes generees manuellement ou ad hoc
- Pas de procedures formelles
- Reaction aux evenements (pas de monitoring proactif)
- Outils basiques (antivirus, firewall)
- Personnel non dedie a la securite
Niveau 2 - Developing
- SIEM deploye avec regles de base
- Procedures ecrites pour les incidents courants
- Equipe SOC dediee (Tier 1)
- Logging systematique
- premieres metriques collectees
Niveau 3 - Defined
- Playbooks documentes et entraines
- SOAR deploie pour les automatisations de base
- KPIs mesures et reportes (MTTD, MTTR)
- Tier 1/2/3 operationnels
- Integration Threat Intelligence
Niveau 4 - Managed
- Threat hunting proactif
- Machine Learning pour la detection
- Automatisation avancee (SOAR complet)
- Red/Blue teaming regulier
- Metrics-driven improvement
Niveau 5 - Optimizing
- AI/ML au centre des operations
- Deception technology (honeypots)
- Purple teaming continu
- Automatisation quasi-totale
- Innovation et recherche
Objectif realiste : La plupart des organisations visent le Niveau 3-4. Atteindre le Niveau 5 necessite des investissements significatifs en personnel, outils et processus.
Evaluation de la Maturite
- Audit interne : Auto-evaluation annuelle avec grille de maturite
- Audit externe : Evaluation par un tier independant
- Cadres de reference : NIST CSF, ISO 27001, CIS Controls
- Benchmarking : Comparison avec le secteur d'activite
Démonstration pas à pas : Audit annuel de maturité. Étape 1 : auto-évaluation sur la grille niveaux 1 à 5 avec preuves (règles, playbooks, MTTD et MTTR). Étape 2 : audit externe pour valider. Étape 3 : positionnement au niveau 2 avec plan vers le niveau 3 (SOAR de base, playbooks entraînés). Étape 4 : présentation au CISO avec budget chiffré. Livrable : rapport de maturité et feuille de route.
Pièges classiques : Vouloir sauter du niveau 1 au niveau 5 avec de l'IA sans SIEM ni procédures : le projet s'effondre. Ou confondre conformité ISO 27001 et maturité opérationnelle réelle mesurée par MTTD et MTTR.
À vous de jouer : Ton SOC est au niveau 2. Quel objectif réaliste pour l'an prochain ?
Voir la réponse
Viser le niveau 3 défini : playbooks documentés et testés, SOAR de base, KPI MTTD et MTTR suivis, Tiers 1 et 2 opérationnels et Threat Intel intégrée. Le niveau 5 attendra.