Niveau Expert

Automatisation & Maturite SOC

Automatiser avec Azure, gerer la Threat Intelligence, integrer MDR/MSSP et mesurer la maturite

Sommaire

🤖 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

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

Sources de Threat Intelligence

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

Considerations pour le Choix

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

Niveau 2 - Developing

Niveau 3 - Defined

Niveau 4 - Managed

Niveau 5 - Optimizing

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

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.