Solutions / 01
SOC prêt pour l'IA
Une architecture d'opérations de sécurité où l'IA assiste le triage et l'enrichissement, où les actions à fort impact s'arrêtent devant un humain, et où chaque étape est auditable.
Le problème
La plupart des propositions visant à mettre de l'IA dans un SOC commencent par le mauvais bout. Elles ajoutent un modèle à une file de triage dont les données sous-jacentes ne sont pas normalisées, dont le contenu de détection n'est pas versionné, et dont le volume d'alertes est le symptôme d'une agrégation manquante plutôt que d'une intelligence manquante. Le modèle produit alors des synthèses assurées à partir d'entrées de mauvaise qualité, ce qui est pire que pas de synthèse du tout.
Le second échec est plus subtil. Un assistant capable d'agir — clore une alerte, isoler un poste, interroger un système — hérite de l'autorité de l'analyste sans en avoir la responsabilité. Si ses actions ne sont pas distinguables dans la piste d'audit, le SOC a discrètement perdu la capacité de reconstituer ses propres décisions.
Architecture
À quoi ressemble le système.
TÉLÉMÉTRIE
Sources, pipelines, lignage
SIEM
Plateforme et stockage
DÉTECTION
Detection-as-code, orientée risque
ENRICHISSEMENT
Contexte actif, identité, menace
ASSISTANCE IA
Triage et synthèse
VALIDATION HUMAINE
Approbation nominative, tracée
AUTOMATISATION
Réponse autorisée uniquement
L'architecture est en couches, afin que chacune puisse être construite, testée et raisonnée indépendamment. La télémétrie est construite avant d'être analysée. La détection s'exécute comme du contenu versionné. L'enrichissement et l'assistance IA se placent au-dessus de la détection plutôt que de la remplacer. L'automatisation n'exécute que ce qu'une politique — et, si nécessaire, une personne — a autorisé.
- Couche télémétrie
- Sources, pipelines, normalisation et lignage. Les limites de fidélité sont consignées ici, pour que les couches supérieures ne puissent pas supposer silencieusement plus que ce que les données supportent.
- Couche détection
- Detection-as-code : contenu sous contrôle de version, avec tests, revue et pipeline de déploiement. L'agrégation par le risque transforme des signaux isolés en quelque chose qui mérite l'attention.
- Enrichissement et assistance IA
- Assemblage de contexte, corrélation et synthèse. Les entrées et sorties de l'assistant sont journalisées comme des événements, si bien que sa contribution à une décision est reconstituable.
- Porte de validation humaine
- Une frontière explicite. Les actions au-delà d'un seuil d'impact défini s'y arrêtent et exigent l'approbation d'une personne nommée, approbation enregistrée avec l'action.
- Couche automatisation
- Exécute la réponse autorisée. Chaque action automatisée émet sa propre télémétrie, y compris ce qui l'a autorisée.
- Observabilité
- Entoure toute l'architecture : le pipeline est-il sain, le contenu de détection matche-t-il encore, l'assistant se comporte-t-il comme le mois dernier.
Compétences
- Architecture de télémétrie avec fidélité et lignage consignés
- Detection-as-code avec tests et pipeline de déploiement
- Alerting fondé sur le risque et agrégation des signaux
- Enrichissement de contexte depuis les sources actifs, identité et menace
- Triage et synthèse d'investigation assistés par IA
- Portes de validation humaine sur les actions à fort impact
- Automatisation de la réponse avec provenance complète des actions
- Observabilité du SOC — santé de la plateforme, des pipelines et du contenu
Contrôles de sécurité
- L'assistance IA opère par défaut en lecture seule ; les chemins d'écriture exigent une autorisation explicite
- Chaque entrée et sortie de l'IA est journalisée comme un événement de sécurité
- Les actions sont attribuées à l'identité qui les a autorisées, humaine ou de service
- Les seuils d'impact sont configurés et revus, non implicites dans la confiance du modèle
- L'assemblage du prompt et du contexte est traité comme une manipulation de contenu non fiable
- Les changements de contenu de détection suivent le même circuit de revue que tout autre code de production
Approche d'intégration
L'architecture est prévue pour être adoptée par étapes dans un SOC existant, dans l'ordre imposé par les dépendances : les données d'abord, puis le detection engineering, puis l'agrégation, et seulement ensuite l'assistance et l'automatisation. Chaque étape apporte de la valeur par elle-même, ce qui compte parce que les dernières échouent bruyamment lorsque les premières ont été sautées.
- Construire la télémétrie : inventaire, schéma, normalisation, contrôles qualité, lignage.
- Faire passer le contenu de détection sous contrôle de version, avec tests et pipeline de déploiement.
- Introduire l'agrégation par le risque, pour que le volume d'alertes reflète une conception et non la charge de triage.
- Ajouter l'enrichissement et l'assemblage de contexte comme un service que le SOC peut appeler et inspecter.
- Introduire l'assistance IA sur les chemins de lecture, journalisée de bout en bout.
- Définir les seuils d'impact et les portes de validation, puis automatiser en dessous.
Résultats attendus
- Un volume d'alertes déterminé par une conception d'agrégation plutôt que par la capacité de triage
- Un contenu de détection qui peut être testé et annulé
- Un contexte d'investigation assemblé une fois, non redérivé par chaque analyste
- Une contribution de l'IA visible et attribuable dans la piste d'audit
- Une automatisation limitée à ce qu'une politique a réellement autorisé
Limites
L'assistance IA dans un SOC reste un domaine de recherche actif, y compris chez KOR IT. Le mode de défaillance qui nous préoccupe le plus est la dégradation silencieuse : un assistant dont les synthèses restent fluides pendant que ses entrées se dégradent. L'architecture ci-dessus est conçue pour que cela soit détectable, non pour que ce soit impossible.