IA dans le SOC : orchestrer des agents spécialisés

L’intelligence artificielle (IA) transforme déjà les opérations de sécurité, mais son intérêt ne réside pas dans un outil universel. Pour les équipes de Security Operations Center (SOC), le modèle le plus robuste associe plusieurs agents spécialisés, chacun intégré à une étape précise de la réponse à incident.

Cet article présente une architecture d’orchestration applicable aux environnements combinant SIEM, gestion des incidents, sandbox et SOAR. Il détaille aussi les prérequis, les contrôles de sécurité et un script PowerShell générique pour chaîner ces capacités sans donner à un agent unique un périmètre excessif.

Pourquoi une IA unique ne suffit pas dans un SOC

La réponse à incident couvre des tâches très différentes : ingérer des millions d’événements, qualifier une alerte, reconstruire une chronologie, analyser un fichier malveillant, puis exécuter une mesure de confinement. Ces opérations ne reposent ni sur les mêmes données, ni sur les mêmes modèles, ni sur les mêmes niveaux de criticité.

Une IA généraliste peut résumer un événement ou proposer une hypothèse, mais elle ne devrait pas disposer simultanément des droits nécessaires pour interroger toute la télémétrie, modifier les tickets et isoler des postes. Cette concentration augmente le rayon d’impact d’une erreur de modèle, d’un prompt injecté ou d’un compte compromis.

L’approche par agents spécialisés permet au contraire de :

• limiter les données accessibles à chaque étape ;
• attribuer des permissions différentes selon la fonction ;
• remplacer un composant sans reconstruire toute la chaîne ;
• imposer une validation humaine avant les actions irréversibles ;
• mesurer séparément la qualité de chaque agent.

Quatre agents pour couvrir le cycle de réponse à incident

Agent SIEM : détection et triage

L’agent connecté au système de gestion des événements et des informations de sécurité (SIEM) traite les flux de télémétrie, rapproche les signaux faibles et réduit le bruit avant présentation à un analyste.

Son rôle n’est pas nécessairement de fermer automatiquement les alertes. Il peut d’abord enrichir chaque signal avec un niveau de confiance, les entités concernées, les règles déclenchées et les raisons de la corrélation.

Les sorties utiles sont structurées plutôt que rédigées uniquement en langage naturel :

• identifiant de l’alerte et horodatage ;
• utilisateurs, hôtes, adresses IP et ressources impliqués ;
• hypothèse de détection ;
• score de confiance et justification ;
• indicateurs à transmettre aux étapes suivantes.

Agent de gestion de cas : contexte et investigation

Le deuxième agent travaille sur le dossier d’incident. Il rassemble les événements associés, reconstruit une chronologie, détecte les incidents historiques similaires et met à jour les champs du ticket.

Cette étape est particulièrement utile lorsque plusieurs alertes apparemment indépendantes concernent le même utilisateur, le même poste ou la même charge de travail cloud. L’agent doit toutefois conserver la distinction entre faits observés, corrélations et hypothèses.

Un résumé opérationnel de qualité doit répondre à quatre questions :

• Que s’est-il passé et quand ?
• Quelles identités ou ressources sont concernées ?
• Quelles preuves soutiennent l’hypothèse actuelle ?
• Quelle action est recommandée, avec quel niveau de confiance ?

Agent sandbox : analyse et renseignement

L’agent de sandbox analyse les fichiers, URL ou charges utiles suspectes dans un environnement isolé. Il peut extraire les indicateurs de compromission (IOC), observer les comportements déclenchés et transmettre les résultats au dossier d’incident.

La séparation est essentielle : une sandbox doit recevoir uniquement les éléments nécessaires à l’analyse. Les données confidentielles présentes dans un fichier ne doivent pas être exportées vers un service d’IA externe sans contrôle de classification, de rétention et de résidence.

Les résultats doivent rester exploitables par machine : hachages, domaines, adresses IP, chemins, clés de registre, processus observés et verdict. Le résumé humain vient compléter ces données, pas les remplacer.

Agent SOAR : réponse et remédiation

Le dernier agent transforme les résultats validés en actions de réponse via un système d’orchestration, d’automatisation et de réponse (SOAR). Il peut préparer un playbook, demander une approbation ou exécuter une action autorisée comme la révocation d’une session ou le confinement d’un hôte.

Le SOAR ne doit pas interpréter seul un texte libre pour décider d’une action critique. Les actions doivent être sélectionnées dans une liste contrôlée, avec des paramètres validés, une journalisation complète et une possibilité de retour arrière lorsqu’elle existe.

Comparer les responsabilités des agents

Le découpage suivant aide à attribuer les permissions et à définir les critères de validation avant intégration.

Contrats de données et garde-fous opérationnels

L’orchestration devient fragile lorsque chaque agent produit un texte différent. Définissez un contrat commun, idéalement en JSON, avec des champs obligatoires et des valeurs contrôlées. Le champ confidence doit être accompagné d’une justification ; un score isolé ne constitue pas une preuve.

Les prérequis minimaux sont les suivants :

• un identifiant stable pour l’alerte et le cas ;
• une horloge et un format de date communs ;
• une classification des données avant transmission ;
• une authentification distincte pour chaque webhook ou API ;
• des comptes de service sans privilèges d’administration globale ;
• une journalisation des requêtes, réponses, erreurs et décisions humaines ;
• un mécanisme de corrélation permettant de retrouver toute l’exécution.

Le délai de propagation dépend de chaque produit : ingestion SIEM, création du cas, analyse sandbox et exécution SOAR peuvent être asynchrones. Le workflow doit donc gérer les statuts accepted, running, completed et failed, plutôt que considérer une réponse HTTP réussie comme la fin du traitement.

Mise en œuvre

L’exemple suivant fournit un orchestrateur PowerShell 7.4 compatible avec des webhooks internes. Il ne dépend d’aucune API propriétaire : chaque outil de sécurité doit exposer un adaptateur respectant le contrat JSON défini par votre équipe.

Prérequis et permissions minimales :

• PowerShell 7.4 ou version ultérieure ; aucun module additionnel n’est requis ;
• accès réseau HTTPS vers les quatre endpoints ;
• un jeton limité aux opérations prévues par ces endpoints ;
• droits de lecture sur le fichier d’alerte local ;
• droits d’écriture sur le répertoire de sortie ;
• permissions applicatives propres à chaque produit, sans rôle tenant-wide si l’éditeur permet un périmètre plus restreint.

Par défaut, le script fonctionne en simulation. Il produit un fichier JSON de traçabilité et affiche les payloads qui seraient envoyés. L’exécution réelle nécessite le commutateur -Execute.

1[CmdletBinding()]
2param(
3    [Parameter(Mandatory = $true)]
4    [ValidateScript({ Test-Path -LiteralPath $_ -PathType Leaf })]
5    [string]$AlertPath,
6 
7    [Parameter(Mandatory = $false)]
8    [string]$OutputPath = '.\soc-orchestration-result.json',
9 
10    [Parameter(Mandatory = $false)]
11    [switch]$Execute
12)
13 
14Set-StrictMode -Version Latest
15$ErrorActionPreference = 'Stop'
16 
17# Les URI sont fournies par l’environnement afin de ne pas inscrire de secrets dans le script.
18$endpoints = [ordered]@{
19    Siem     = $env:SOC_SIEM_WEBHOOK
20    Case     = $env:SOC_CASE_WEBHOOK
21    Sandbox  = $env:SOC_SANDBOX_WEBHOOK
22    Soar     = $env:SOC_SOAR_WEBHOOK
23}
24 
25foreach ($name in $endpoints.Keys) {
26    if ([string]::IsNullOrWhiteSpace($endpoints[$name])) {
27        throw "La variable d’environnement SOC_$($name.ToUpper())_WEBHOOK est absente."
28    }
29}
30 
31$token = $env:SOC_WEBHOOK_TOKEN
32if ($Execute -and [string]::IsNullOrWhiteSpace($token)) {
33    throw 'SOC_WEBHOOK_TOKEN est obligatoire avec -Execute.'
34}
35 
36function Invoke-SocAgent {
37    param(
38        [Parameter(Mandatory = $true)]
39        [string]$Name,
40 
41        [Parameter(Mandatory = $true)]
42        [string]$Uri,
43 
44        [Parameter(Mandatory = $true)]
45        [hashtable]$Payload
46    )
47 
48    $json = $Payload | ConvertTo-Json -Depth 10
49 
50    if (-not $Execute) {
51        Write-Host "[SIMULATION] $Name -> $Uri"
52        Write-Output ($Payload | ConvertTo-Json -Depth 10)
53        return [pscustomobject]@{
54            agent  = $Name
55            status = 'simulated'
56            data   = $Payload
57        }
58    }
59 
60    $headers = @{
61        Authorization = "Bearer $token"
62        Accept        = 'application/json'
63    }
64 
65    try {
66        $response = Invoke-RestMethod -Method Post -Uri $Uri -Headers $headers -ContentType 'application/json' -Body $json
67        return [pscustomobject]@{
68            agent  = $Name
69            status = 'completed'
70            data   = $response
71        }
72    }
73    catch {
74        throw "L’agent $Name a échoué : $($_.Exception.Message)"
75    }
76}
77 
78# Lecture de l’alerte et création d’un identifiant de corrélation stable.
79$alert = Get-Content -LiteralPath $AlertPath -Raw | ConvertFrom-Json
80$correlationId = [guid]::NewGuid().ToString()
81$receivedAt = [DateTime]::UtcNow.ToString('o')
82 
83$triage = Invoke-SocAgent -Name 'siem' -Uri $endpoints.Siem -Payload @{
84    correlationId = $correlationId
85    receivedAt    = $receivedAt
86    alert         = $alert
87}
88 
89$case = Invoke-SocAgent -Name 'case-management' -Uri $endpoints.Case -Payload @{
90    correlationId = $correlationId
91    triage        = $triage.data
92}
93 
94$sandbox = Invoke-SocAgent -Name 'sandbox' -Uri $endpoints.Sandbox -Payload @{
95    correlationId = $correlationId
96    case          = $case.data
97    indicators    = $alert.indicators
98}
99 
100# Le SOAR reçoit les résultats précédents. L’adaptateur doit appliquer sa propre politique d’approbation.
101$soar = Invoke-SocAgent -Name 'soar' -Uri $endpoints.Soar -Payload @{
102    correlationId = $correlationId
103    case          = $case.data
104    sandbox       = $sandbox.data
105    executionMode = if ($Execute) { 'execute' } else { 'simulate' }
106}
107 
108$result = [ordered]@{
109    correlationId = $correlationId
110    executionMode = if ($Execute) { 'execute' } else { 'simulate' }
111    startedAt     = $receivedAt
112    completedAt   = [DateTime]::UtcNow.ToString('o')
113    agents        = @($triage, $case, $sandbox, $soar)
114}
115 
116$result | ConvertTo-Json -Depth 20 | Set-Content -LiteralPath $OutputPath -Encoding utf8
117Write-Host "Résultat écrit dans $OutputPath"

L’alerte d’entrée peut respecter ce contrat minimal. Les noms de champs doivent rester cohérents entre les adaptateurs afin que les agents puissent être remplacés indépendamment.

1{
2  "alertId": "INC-2026-0001",
3  "severity": "high",
4  "title": "Suspicious sign-in followed by unusual process activity",
5  "createdAt": "2026-09-04T08:15:00Z",
6  "entities": [
7    {
8      "type": "user",
9      "value": "analyst@example.com"
10    },
11    {
12      "type": "host",
13      "value": "WS-042"
14    }
15  ],
16  "indicators": [
17    {
18      "type": "ip",
19      "value": "203.0.113.10"
20    }
21  ]
22}

Configurez les endpoints et exécutez d’abord une simulation. Les valeurs de retour attendues sont status = simulated pour les quatre agents et executionMode = simulate dans le fichier de sortie.

1$env:SOC_SIEM_WEBHOOK = 'https://soc-adapter.example.invalid/siem'
2$env:SOC_CASE_WEBHOOK = 'https://soc-adapter.example.invalid/case'
3$env:SOC_SANDBOX_WEBHOOK = 'https://soc-adapter.example.invalid/sandbox'
4$env:SOC_SOAR_WEBHOOK = 'https://soc-adapter.example.invalid/soar'
5 
6.\soc-orchestrator.ps1 -AlertPath .\alert.json -OutputPath .\simulation.json

Après validation des payloads, le mode d’exécution transmet le jeton Bearer aux adaptateurs. Chaque endpoint doit retourner un document JSON ; les erreurs HTTP ou les réponses non exploitables doivent faire échouer le workflow plutôt que déclencher une remédiation silencieuse.

1$env:SOC_WEBHOOK_TOKEN = Read-Host 'Jeton des adaptateurs SOC' -AsSecureString
2$plainToken = [System.Net.NetworkCredential]::new('', $env:SOC_WEBHOOK_TOKEN).Password
3$env:SOC_WEBHOOK_TOKEN = $plainToken
4 
5.\soc-orchestrator.ps1 -AlertPath .\alert.json -OutputPath .\execution.json -Execute
6 
7Get-Content -LiteralPath .\execution.json -Raw | ConvertFrom-Json |
8    Select-Object correlationId, executionMode, startedAt, completedAt

Pour la vérification en production, contrôlez la présence du même correlationId dans les journaux des quatre adaptateurs, comparez les statuts remontés par les outils et confirmez qu’aucune action SOAR n’a été exécutée pendant la simulation. La propagation complète doit être mesurée sur votre environnement, car elle dépend des files d’attente, des analyses asynchrones et des limites de débit de chaque produit.

Dépannage des erreurs courantes

Le script signale une variable d’environnement absente

Les quatre URLs sont obligatoires, même en simulation, car elles font partie du contrat d’orchestration. Vérifiez leur présence dans le même processus PowerShell avec Get-ChildItem Env:SOC_* et contrôlez qu’aucun nom n’a été mal recopié.

L’exécution échoue avec une erreur 401 ou 403

Le jeton est absent, expiré ou insuffisamment autorisé. Vérifiez l’audience attendue par l’adaptateur, sa durée de validité et son périmètre. Ne corrigez pas le problème en attribuant un rôle administrateur global : créez plutôt un compte de service distinct par intégration.

Un agent répond mais le workflow reste incomplet

Une réponse HTTP réussie ne garantit pas que l’analyse est terminée. L’adaptateur doit retourner un identifiant de traitement et un statut exploitable si l’opération est asynchrone. Ajoutez ensuite une étape de polling ou de rappel événementiel avec le même correlationId.

Le résumé de l’IA contredit les preuves

Traitez le texte généré comme une hypothèse. Revenez aux événements bruts, aux résultats de sandbox et aux journaux d’identité. Bloquez toute action automatique lorsque les preuves obligatoires sont absentes, contradictoires ou classées avec une confiance insuffisante.

Ce que l’équipe doit mettre en place lundi matin

Commencez par cartographier les quatre fonctions sur les outils déjà déployés, puis définissez un schéma JSON commun et un identifiant de corrélation. Mesurez séparément le bruit réduit par le triage, le temps de constitution du dossier, la qualité des IOC et le taux d’actions SOAR approuvées.

Déployez ensuite l’orchestration en mode simulation, sur un jeu d’incidents historiques représentatif. N’activez les actions de confinement qu’après validation des faux positifs, des permissions, des journaux d’audit et du processus de retour arrière.

Si votre SOC possède déjà plusieurs automatisations spécialisées, l’étape suivante n’est probablement pas d’ajouter une IA supplémentaire. C’est de formaliser leurs contrats, de réduire leurs privilèges et de faire circuler entre elles des résultats vérifiables plutôt que des résumés isolés.