Sécurité IA pour analystes SOC : détecter les abus de LLM

L'analyste SOC en 2026 a une nouvelle classe d'incidents à détecter : abus de LLM, prompt injection, exfiltration via chatbots, tool calls détournés, recursive tool calling. Les outils sont matures (OpenTelemetry GenAI, Splunk/Sentinel/Elastic, Langfuse), les méthodologies existent (MITRE ATLAS, OWASP LLM Top 10), mais le savoir-faire opérationnel côté SOC reste à construire. Cet article documente les logs à collecter, les 5 alertes critiques, les runbooks par OWASP, l'intégration SIEM et un plan formation 8 semaines pour analystes SOC L1/L2/L3.

Pour les fondations détection : détecter une prompt injection en temps réel. Pour l'audit production : auditer un workflow agentique.

Le mandat SOC sur les abus LLM

Trois propriétés rendent la mission SOC sur l'IA spécifique :

1. Logs nouveaux : les attributs OpenTelemetry GenAI (1.27+) ne sont pas dans les SIEM par défaut, il faut configurer collecteurs et parseurs.
2. Alertes nouvelles : un canary token leaké, une combinaison interdite de tools, un burst recursive, autant de signaux qui n'existent pas dans les playbooks SOC classiques.
3. Coordination obligatoire : SOC + AppSec + Tech Lead sur incidents IA. Le SOC seul ne peut pas remédier sans coordination ML/dev.

Tip, Le SOC 2026 sur l'IA n'a pas à devenir expert ML. Il doit comprendre les patterns d'attaque, les logs à corréler, et les runbooks à exécuter. La technicité sous-jacente est portée par AppSec/Tech Lead.

Les logs à collecter

Six catégories essentielles

Format OpenTelemetry GenAI semantic conventions

Format standard depuis 2024 (semantic conventions 1.27+).

{
  "timestamp": "2026-04-30T23:23:45.123Z",
  "request_id": "req_8a92c4d1",
  "session_id": "sess_91fe...",
  "user": {
    "id": "u_42",
    "tenant_id": "company_a",
    "ip": "203.0.113.10",
    "auth_method": "oidc"
  },
  "gen_ai": {
    "system": "openai",
    "request": {
      "model": "gpt-4o",
      "max_tokens": 2000,
      "temperature": 0.7
    },
    "response": {
      "input_tokens": 1234,
      "output_tokens": 287,
      "finish_reason": "stop",
      "response_hash": "sha256:def..."
    }
  },
  "rag": {
    "query_text_hash": "sha256:abc...",
    "embedding_model": "text-embedding-3-large",
    "retrieved_chunks": [
      {"id": "doc1_chunk_3", "score": 0.89, "sensitivity": "internal"}
    ],
    "filter_applied": {
      "tenant_id": "company_a",
      "sensitivity_max": 10
    }
  },
  "security": {
    "input_score": 0.82,
    "input_signals": ["marker_regex", "classifier_ml"],
    "output_score": 0.0,
    "canary_leak": false,
    "action_taken": "allowed"
  },
  "cost_usd": 0.018,
  "duration_ms": 412
}

Émission via OTLP collector → SIEM (Splunk, Sentinel, Elastic, Chronicle).

Configuration OTel collector

# otel-collector-config.yaml
receivers:
  otlp:
    protocols:
      grpc:
        endpoint: 0.0.0.0:4317
      http:
        endpoint: 0.0.0.0:4318
 
processors:
  batch:
    timeout: 5s
  attributes/pii_masking:
    actions:
      - key: gen_ai.request.prompt
        action: hash
      - key: gen_ai.response.content
        action: hash
 
exporters:
  splunk_hec:
    endpoint: https://splunk.internal:8088
    token: ${SPLUNK_HEC_TOKEN}
    index: llm_security
  
  azure_monitor:
    instrumentation_key: ${AZURE_INST_KEY}
  
  elasticsearch:
    endpoints: ["https://elastic.internal:9200"]
    index: llm-security-logs
 
service:
  pipelines:
    traces:
      receivers: [otlp]
      processors: [batch, attributes/pii_masking]
      exporters: [splunk_hec, azure_monitor, elasticsearch]

Les 5 alertes SOC critiques

Alerte 1, Canary token leaked

Pattern : un token canari inséré dans le system prompt apparaît en sortie.

Sévérité : CRITIQUE, signal certain de jailbreak ou system prompt leakage.

Règle Splunk :

index=llm_security
| eval canary_tokens="SYS_CANARY_8a92f3b1,RAG_CANARY_91cd8e24"
| where match(gen_ai.response.content, canary_tokens)
| stats count by user.id, session_id, gen_ai.system
| where count >= 1

Runbook :

1. Confirmer : canary réellement leaké (vs faux positif).
2. Contenir : suspendre la session utilisateur immédiatement.
3. Investigation : quel prompt a déclenché le leak ? technique utilisée ?
4. Notifier : L2/L3 + AppSec lead + RSSI si données sensibles concernées.
5. Remédiation : analyser le bypass, mettre à jour les détections, tester en CI.
6. Post-mortem : leçons apprises, mise à jour playbooks.

Alerte 2, Markdown image exfiltration (EchoLeak class)

Pattern : sortie LLM contient ![...](https://...) vers domaine non-allowlisté.

Sévérité : CRITIQUE, exfiltration zéro-clic active.

index=llm_security
| rex field=gen_ai.response.content "!\[.*?\]\((?<exfil_url>https?:\/\/[^\)]+)\)"
| eval domain=lower(replace(replace(exfil_url, "^https?://", ""), "/.*$", ""))
| where NOT match(domain, "yourcompany.com$|trusted-cdn.example$")
| stats count, values(domain) as domains by user.id, session_id

Runbook : escalade immédiate critique, blocage session, investigation forensique, communication avec personnes concernées si exfil confirmée, notification RGPD si PII (72h CNIL).

Alerte 3, Burst tool calls (recursive tool calling)

Pattern : > 50 tool calls en 30s sur un agent normalement à 5/min.

Sévérité : Élevée, boucle ou compromission probable.

index=llm_security source=agent_logs
| bucket _time span=30s
| stats count as tool_calls_30s by user.id, agent_id, _time
| where tool_calls_30s > 50
| eval risk_level=case(
    tool_calls_30s > 200, "CRITIQUE",
    tool_calls_30s > 100, "ÉLEVÉE",
    1=1, "MODÉRÉE"
)

Runbook : kill switch immédiat sur la session, vérification budget consommé, analyse du pattern (tool en boucle ?), recharge mitigations (max_same_tool_consecutive).

Alerte 4, Score classifier injection répété

Pattern : > 5 détections d'injection en 10 min sur même user/IP.

Sévérité : Modérée à élevée, attaque ciblée probable.

index=llm_security
| where security.input_score > 0.7
| bucket _time span=10m
| stats count as detection_count by user.id, _time
| where detection_count > 5

Runbook : rate limit ciblé (user/IP), audit historique du user, threat intel partage, escalade si pattern coordonné multi-users.

Alerte 5, Combinaison tools interdite

Pattern : tools incompatibles invoqués dans la même session.

Sévérité : Critique, privilege escalation ou collusion.

index=llm_security source=agent_logs
| stats values(tool_name) as tools_used by session_id, user.id
| eval forbidden=case(
    mvfind(tools_used, "read_pii") >= 0 AND mvfind(tools_used, "send_external_email") >= 0, "PII_TO_EXTERNAL",
    mvfind(tools_used, "read_credentials") >= 0 AND mvfind(tools_used, "http_request") >= 0, "CREDS_TO_HTTP",
    1=1, ""
)
| where len(forbidden) > 0

Runbook : suspension immédiate session, audit forensique (qu'est-ce qui a été lu/envoyé), notification RSSI, possible notification RGPD selon données.

Mapping alertes ↔ MITRE ATLAS ↔ OWASP

Plan formation SOC 8 semaines

Semaines 1-2, Fondations IA pour SOC

Objectifs :

• Comprendre OWASP LLM Top 10 v2.
• Comprendre MITRE ATLAS (parallèle avec ATT&CK déjà connu).
• Différences IA vs cyber classique (probabiliste, surface étendue).

Lectures :

• OWASP LLM Top 10 développeurs.
• MITRE ATLAS.
• Détecter une prompt injection en temps réel.

Pratique :

• Lire 5-10 incidents publics IA (EchoLeak, Bing Sydney, AutoGPT cost explosion).
• Cartographier chaque incident sur MITRE ATLAS + OWASP.

Livrable : présentation interne "IA pour SOC" à l'équipe.

Semaines 3-4, Détection et SIEM

Objectifs :

• Maîtriser les attributs OpenTelemetry GenAI.
• Configurer SIEM pour parser les logs IA.
• Construire les 5 alertes critiques.

Pratique :

• Configuration OTel collector → SIEM.
• Création des 5 règles SIEM principales (canary, markdown exfil, burst, injection répétée, combo tools).
• Tests des alertes avec données synthétiques.

Livrable : règles SIEM déployées + dashboards opérationnels.

Semaines 5-6, Runbooks et simulation

Objectifs :

• Documenter runbooks par classe d'incident.
• Simuler incidents (purple team interne).
• Maîtriser escalade L1 → L2 → L3.

Lectures :

• Microsoft AI Red Team playbook.
• Empêcher l'exfiltration via chatbot RAG.
• Recursive tool-calling.

Pratique :

• Rédaction de 5 runbooks (correspondant aux 5 alertes critiques).
• Simulation d'incidents avec red team interne ou prestataire.
• Mesure MTTD / MTTR sur simulations.

Livrable : runbooks documentés + métriques de simulation.

Semaines 7-8, Opérations et coordination

Objectifs :

• Intégration aux processus SOC existants.
• Coordination AppSec + Tech Lead + DPO + RSSI.
• Communication direction sur KPI IA.

Pratique :

• Mise en place dashboard direction (KPI mensuel).
• Procédures de coordination cross-équipes.
• Premier rapport trimestriel SOC IA.

Livrable : dashboard + processus + premier rapport.

Runbook type, Canary token leaked (template)

# Runbook IR-AI-001, Canary Token Leaked
 
## Trigger
Alerte SIEM : canary token du system prompt apparaît en sortie LLM.
 
## Sévérité
CRITIQUE, confirme un jailbreak ou system prompt leakage actif.
 
## Mapping
- MITRE ATLAS : AML.T0024 *Exfiltration via ML Inference API*, AML.T0035 *LLM Model Inversion*
- OWASP : LLM07 *System Prompt Leakage*
 
## Étapes immédiates (< 15 min)
 
### 1. Confirmer (3 min)
- [ ] Vérifier que le canary détecté est le canary actif courant (pas obsolète).
- [ ] Confirmer match exact dans la sortie LLM.
- [ ] Identifier user.id, session_id, timestamp précis.
 
### 2. Contenir (5 min)
- [ ] Suspendre immédiatement la session utilisateur.
- [ ] Bloquer temporairement le user au niveau API gateway (15 min minimum).
- [ ] Si leak vers external service : couper l'accès réseau.
 
### 3. Notifier (5 min)
- [ ] Slack channel #soc-incidents : alerte L2.
- [ ] Email tech-lead-llm-app + appsec-lead.
- [ ] Si confirmation forensique : RSSI + DPO si PII.
 
### 4. Logger (2 min)
- [ ] Capture complète : prompt, sortie, contexte session, IP.
- [ ] Archiver pour forensique (rétention 1 an).
 
## Investigation (< 2h)
 
### Forensique
- Revue historique du user (autres tentatives ?).
- Identification de la technique utilisée :
  - Prompt direct demandant le system prompt ?
  - Roleplay / DAN-like ?
  - Crescendo (multi-tour) ?
  - Encoding / obfuscation ?
- Si Crescendo : revoir les N tours précédents.
 
### Cartographie de l'attaque
- Si attaque coordonnée (multiple users) : threat intel sharing.
- Si user interne (employé) : coordination RH.
 
## Containment / Eradication
 
### Court terme (24h)
- Régénérer un nouveau canary token + redéploiement.
- Mettre à jour les filters d'entrée pour bloquer le pattern observé.
- Ajouter le pattern au corpus régression CI.
 
### Moyen terme (1 semaine)
- Ré-audit du système prompt complet.
- Test adversarial avec PyRIT pour vérifier le bypass est neutralisé.
- Mise à jour des dashboards SOC.
 
## Communication
 
### Si exfiltration de données confirmée
- DPO : évaluation RGPD (Article 33, notification CNIL sous 72h si PII).
- Direction : briefing si impact business.
- Personnes concernées : si exfiltration confirmée et risque élevé (RGPD Article 34).
 
### Communication interne
- Post-mortem dans 1 semaine.
- Mise à jour wiki SOC.
 
## Métriques à mettre à jour
 
- TPR detection canary (régression test).
- MTTD : delay alerte → confirmation.
- MTTR : delay confirmation → containment.
- Patterns adverses observés (ajouter au threat model).
 
## Liens utiles
- [System prompt résistant aux injections](/ressources/llm-security/ecrire-system-prompt-resistant-injections).
- [Top 20 techniques jailbreak](/ressources/llm-security/top-20-techniques-jailbreak-llm-red-team).

Dashboards opérationnels

Dashboard L1 (temps réel)

Composants :

• Volume requêtes LLM dernière heure.
• Taux de détection injection (input score > 0.7).
• Top 10 users avec scores élevés.
• Alertes actives par sévérité.
• Runbooks suggérés par alerte.

Dashboard L2/L3 (corrélation)

Composants :

• Patterns d'attaque détectés (techniques MITRE ATLAS).
• Évolution drift sémantique sur golden set.
• Cross-corrélation user + session + tools utilisés.
• Coverage canary tests.
• Baseline normal vs anomalies.

Dashboard direction (mensuel)

Composants :

• Incidents IA total mois (par sévérité).
• MTTD / MTTR par classe.
• Coverage IA inventaire (% systèmes monitorés).
• Conformité EU AI Act / RGPD (% systèmes haut-risque conformes).
• Coût défensif vs incidents évités estimés.

Outils SOC IA recommandés

Pour l'observabilité spécifique LLM : Langfuse (open source self-hostable) est devenu standard. Combiné avec un SIEM via OTel export.

Coordination avec autres équipes

RACI incidents IA

Anti-pattern à éviter

Cellule IA SOC isolée : créer une équipe SOC IA séparée du SOC général. Erreur fréquente. Conséquences :

• Duplication d'efforts.
• Perte de cohérence avec processus existants.
• Pas de partage threat intel.
• Coût opérationnel élevé.

Bonne pratique : étendre le SOC existant avec compétences IA, intégrer aux flux SIEM/SOAR/threat intel généraux.

Évolutions attendues 2026-2027

• OpenTelemetry GenAI atteindra une maturité 1.0 stable.
• MITRE ATLAS Evaluations (similaire ATT&CK Evaluations) en cours pour évaluer les SOC sur la couverture ATLAS.
• AI-specific SOAR playbooks émergeront (Splunk, Sentinel, etc.).
• Threat intel feeds IA se développeront (OpenCTI galaxies ATLAS, MISP modules).
• Certifications SOC IA : émergence probable (équivalent SOC analyst pour IA).

Erreurs fréquentes SOC sur l'IA

Pour aller plus loin

• Détecter une prompt injection en temps réel, détail technique détection.
• Auditer un workflow agentique en production, observabilité.
• MITRE ATLAS, taxonomie attaques.
• Microsoft AI Red Team playbook, vue red team complémentaire.
• Empêcher l'exfiltration via chatbot RAG, comprendre EchoLeak.
• Recursive tool-calling, alerte burst tool calls.

Points clés à retenir

• Mission SOC 2026 sur l'IA : collecter logs OTel GenAI → règles SIEM par technique ATLAS → runbooks par classe → dashboards adaptés → coordination cross-équipes.
• 6 catégories de logs essentielles : API LLM, RAG, tool calls, détection sécurité, auth, cost. Format OpenTelemetry GenAI semantic conventions (1.27+).
• 5 alertes critiques : canary leaked, markdown image exfil (EchoLeak), burst tool calls (recursive), injection score répété, combinaison tools interdite.
• Plan formation 8 semaines : Fondations (1-2) → Détection/SIEM (3-4) → Runbooks/simulation (5-6) → Opérations/coordination (7-8).
• Stack outils : OTel collector + SIEM (Splunk/Sentinel/Elastic) + Langfuse/Phoenix Arize + OpenCTI/MISP.
• 3 niveaux dashboards : L1 temps réel, L2/L3 corrélation, direction mensuel.
• RACI clair obligatoire entre SOC L1/L2/L3 + AppSec + Tech Lead + DPO + RSSI.
• Anti-pattern dominant : cellule SOC IA isolée, toujours intégrer au SOC général.
• 8 erreurs fréquentes : pas de logs structurés, règles non-spécifiques, pas de runbooks, cellule isolée, coordination faible, pas de simulation, dashboards techniques only, règles obsolètes.

Le SOC 2026 sur l'IA est une extension naturelle du SOC général. Pas une nouvelle discipline, mais une adaptation des pratiques existantes à de nouveaux logs, alertes, runbooks. Maturité opérationnelle atteignable en 8 semaines de formation pour SOC L1/L2/L3 existants.