SOC et AI-SDR

L'écran SOC et AI-SDR permet de suivre les détections de la plateforme, d'émettre des ordres de confinement typés et de les approuver ou les rejeter, de sceller et d'exporter les preuves d'un incident avec leur chaîne de garde, de réconcilier les appels à effet de bord dont l'issue est inconnue et de lire le catalogue des réactions permises. Chemin dans le portail : /security/soc, menu Sécurité et gouvernance > SOC et AI-SDR. Il sert aux analystes SOC (soc_analyst), aux responsables sécurité et aux administrateurs de tenant pendant un incident, et aux auditeurs qui lisent les preuves.

Ce que montre l'écran

L'écran (Soc dans portal/src/screens/security-kit.tsx) comporte cinq onglets.

• Ordres : tableau Ordres de confinement (« Uniquement des réactions typées, jamais une commande. »), lu dans GET /v1/soc/orders (50 lignes), colonnes Réaction, Type de cible, Cible, Mode (manual ou automatic), Statut (applied, pending_approval, rejected), Rayon d'impact, Demandé par, Approuvé par, État du kill switch (kill_switch.observed_state). Filtres : Statut et Incident. Un clic sur une ligne ouvre l'ordre chargé par GET /v1/soc/orders/{order_id}, avec son kill switch et ses reçus.
• Détections : tableau Détections, lu dans GET /v1/soc/detections (50 lignes), colonnes Type, Source, Gravité, Confiance, Incident, Heure. Filtres : Incident et Type. Les détections viennent des gardes, du DLP, du runtime et des webhooks.
• Preuves : un sélecteur Incident avec Appliquer, puis un badge Chaîne valide ou Chaîne invalide, les enregistrements scellés (Séquence, Type, Empreinte du contenu, Scellé par, Scellé le) et le journal de garde (Séquence, Action, Acteur, Empreinte, Le). « Chaque lecture est une entrée de la chaîne de garde. » Dessous, deux formulaires : Sceller une preuve et Exporter les preuves.
• Transactions : tableau lu dans GET /v1/soc/transactions, colonnes Transaction, Clé d'idempotence, Identifiant d'exécution, Statut, Mis à jour. Filtres : Statut (in_flight, committed, failed, interrupted, reconciled) et Identifiant d'exécution.
• Catalogue : la réponse JSON de GET /v1/soc/catalog : réactions permises et leurs types de cible, types de détection et playbooks, limites du garde de proportionnalité, et rôles du SOC.

Le formulaire Nouvel ordre comporte ces champs : Réaction (l'une de BLOCK_REQUEST, RATE_LIMIT, REQUIRE_APPROVAL, CANCEL_RUN, CANCEL_SUBAGENTS, SUSPEND_AGENT, SUSPEND_APPLICATION, DISABLE_TOOL, QUARANTINE_CONNECTOR, REVOKE_CREDENTIAL, DISABLE_MODEL_ROUTE, ISOLATE_NETWORK, TERMINATE_WORKLOAD, SUSPEND_IDENTITY, SUSPEND_TENANT, EMERGENCY_LOCKDOWN), Type de cible (par exemple agent), Cible (par exemple invoice-assistant), Raison (obligatoire), Incident, Rayon d'impact maximal, Confiance (par exemple 0.9).

Actions

Bouton ou action	Effet	Appel API	Rôles
Nouvel ordre (puis Créer)	Envoie un ordre de confinement typé. Le Response Policy Engine répond applied, pending_approval (approbation requise) ou le refuse.	POST /v1/soc/orders	Bouton : security_officer, tenant_admin ; serveur : security_officer, soc_analyst, tenant_admin
Approuver (menu de la ligne, ordre pending_approval)	Après une confirmation, approuve et applique l'ordre.	POST /v1/soc/orders/{order_id}/approve	security_officer, tenant_admin
Rejeter (menu de la ligne, ordre pending_approval)	Ouvre un formulaire avec une Raison facultative, puis Rejeter.	POST /v1/soc/orders/{order_id}/reject	security_officer, tenant_admin
Clic sur une ligne (Ordres)	Ouvre l'ordre avec son kill switch et ses reçus.	GET /v1/soc/orders/{order_id}	security_officer, tenant_admin, auditor, soc_analyst
Filtrer (Ordres, Détections, Transactions)	Applique les filtres de l'onglet.	GET /v1/soc/orders, GET /v1/soc/detections ou GET /v1/soc/transactions	security_officer, tenant_admin, auditor, soc_analyst
Clic sur une ligne (Détections, Transactions)	Affiche la ligne.	Aucun	Les mêmes
Appliquer (Preuves, sélecteur Incident)	Charge les enregistrements scellés avec l'état de la chaîne, et le journal de garde ; chaque lecture ajoute une entrée de garde.	GET /v1/soc/incidents/{incident_id}/evidence, GET /v1/soc/incidents/{incident_id}/custody	security_officer, tenant_admin, auditor, soc_analyst
Exécuter (Sceller une preuve)	Ajoute un enregistrement scellé (Incident, Type, par défaut note, Contenu JSON) à la chaîne de preuves de l'incident.	POST /v1/soc/incidents/{incident_id}/evidence	Formulaire : security_officer, tenant_admin ; serveur : security_officer, soc_analyst, tenant_admin
Exécuter (Exporter les preuves)	Après une confirmation, exporte les preuves et la chaîne de garde de l'Incident ; un lot contenant un secret est refusé.	POST /v1/soc/incidents/{incident_id}/evidence/export	Formulaire : security_officer, tenant_admin, auditor ; le serveur ajoute soc_analyst
Réconcilier (menu de la ligne, transaction interrupted, failed ou in_flight)	Enregistre l'issue réelle : Résultat committed ou not_executed, Référence fournisseur, Note.	POST /v1/soc/transactions/{transaction_id}/reconcile	security_officer, tenant_admin
Onglet Catalogue, Réessayer	Relit le catalogue.	GET /v1/soc/catalog	Tout utilisateur du tenant

Rôles

Le portail suit ROLES.socLead (security_officer, tenant_admin) pour Nouvel ordre, Approuver, Rejeter, Réconcilier et Sceller une preuve, et ROLES.evidenceReaders (security_officer, tenant_admin, auditor) pour Exporter les preuves, d'après portal/src/lib/kit.ts ; les autres utilisateurs voient « Nécessite l'un de ces rôles » à la place d'un formulaire. Le Control Plane (services/control-plane/src/eai/domains/soc/__init__.py, rôles dans services/control-plane/src/eai/domains/soc/catalog.py) décide :

Groupe	Rôles	Routes
SOC_READERS	security_officer, tenant_admin, auditor, soc_analyst	listes, détail d'un ordre, preuves, garde, export
SOC_ANALYST + SOC_LEAD	security_officer, soc_analyst, tenant_admin	nouvel ordre, scellé de preuve
SOC_LEAD	security_officer, tenant_admin	approbation, rejet, réconciliation

Un soc_analyst (rôle de la migration V161) peut créer des ordres et sceller des preuves par l'API, même si le portail lui masque ces formulaires. Chaque refus est audité sous soc.access.deny, chaque lecture sous soc.access. platform_admin passe tous les contrôles de rôle.

Tâches courantes

Confiner un agent pendant un incident

1. Vérifier les réactions permises. Chaque réaction n'accepte que certains types de cible. Onglet Catalogue. Résultat attendu : les réactions et leurs cibles, par exemple SUSPEND_AGENT sur agent. En cas d'échec : tenant_required signifie que le compte n'a pas de tenant.
2. Émettre l'ordre. Onglet Ordres > Nouvel ordre : Réaction SUSPEND_AGENT, Type de cible agent, Cible le nom de l'agent, Raison, Incident, puis Créer. Résultat attendu : le message Créé et une ligne applied ou pending_approval. En cas d'échec : containment_refused (HTTP 409) avec les raisons du Response Policy Engine (par exemple blast_radius_exceeded) ; target_not_allowed (HTTP 400) pour un mauvais type de cible.
3. Le faire approuver si besoin. Une réaction au-delà des limites manuelles ou toujours revue attend une seconde personne. Un autre security_officer ou tenant_admin ouvre le menu de la ligne > Approuver. Résultat attendu : le statut applied et son nom dans Approuvé par. En cas d'échec : separation_of_duties (HTTP 409) quand le demandeur approuve son propre ordre ; order_not_pending (HTTP 409) quand il est déjà décidé.
4. Surveiller le kill switch. L'ordre crée un kill switch dont l'état observé doit converger. Lisez État du kill switch, puis ouvrez l'écran Kill Switch. Résultat attendu : SUSPENDED_VERIFIED. En cas d'échec : voir la page Kill Switch.

Sceller et exporter les preuves d'un incident

1. Sceller une note. Un enregistrement scellé est chaîné au précédent par son empreinte. Onglet Preuves, formulaire Sceller une preuve : Incident, Type note, Contenu {"summary": "..."}, puis Exécuter. Résultat attendu : le résultat montre seq, content_sha256 et hash. En cas d'échec : not_found avec incident signale un identifiant d'incident inconnu.
2. Vérifier la chaîne. Saisissez l'incident dans Incident et cliquez Appliquer. Résultat attendu : Chaîne valide et le nouvel enregistrement dans le tableau. En cas d'échec : Chaîne invalide signifie qu'un enregistrement a été altéré ; gardez l'export et suivez le runbook SOC.
3. Exporter. Formulaire Exporter les preuves, Incident, Exécuter, puis acceptez la confirmation. Résultat attendu : le lot avec les enregistrements, les deux chaînes et le journal de garde. En cas d'échec : secret_detected (HTTP 422) signifie qu'un enregistrement contient un secret ; l'export est refusé et une détection secret_leak est enregistrée.

Réconcilier une transaction interrompue

1. La trouver. Onglet Transactions, Statut interrupted, Filtrer. Résultat attendu : les appels à effet de bord dont l'issue est inconnue. En cas d'échec : un tableau vide signifie que rien n'attend de réconciliation.
2. Vérifier chez le fournisseur. Seul le fournisseur sait si l'appel a eu lieu. Recherchez l'appel par sa clé d'idempotence chez le fournisseur. Résultat attendu : vous savez s'il a été validé.
3. Enregistrer l'issue. Menu de la ligne > Réconcilier, Résultat committed (avec Référence fournisseur) ou not_executed, Note, puis Réconcilier. Résultat attendu : le message Terminé et le statut reconciled. En cas d'échec : transaction_not_reconcilable (HTTP 409) quand la transaction n'attend plus de réconciliation.

Dépannage

Symptôme	Cause	Correction
forbidden (HTTP 403) avec required_roles	Vos rôles ne sont pas dans le groupe SOC de la route ; le refus est audité (soc.access.deny).	Demandez soc_analyst, security_officer ou tenant_admin.
« Nécessite l'un de ces rôles » à la place d'un formulaire	Le portail masque le formulaire pour vos rôles.	Utilisez un compte avec l'un des rôles listés.
containment_refused (HTTP 409)	Le Response Policy Engine a refusé l'ordre (réaction hors liste, cible non permise, rayon d'impact au-delà de Rayon d'impact maximal).	Lisez reasons, puis réduisez la cible ou relevez la limite.
unknown_reaction (HTTP 400)	La réaction n'est pas dans la liste permise.	Choisissez une réaction de la liste.
recover_requires_workflow (HTTP 422)	RECOVER n'est pas un ordre.	Utilisez Demander une reprise sur l'écran Kill Switch.
separation_of_duties (HTTP 409)	Le demandeur ne peut pas approuver sa propre demande.	Demandez à un autre security_officer ou tenant_admin.
order_not_pending (HTTP 409)	L'ordre n'attend pas d'approbation.	Actualisez le tableau.
secret_detected (HTTP 422) à l'export	L'export contient un secret.	Retirez le secret de la source des preuves, puis exportez à nouveau.
transaction_not_reconcilable (HTTP 409)	La transaction n'attend pas de réconciliation.	Actualisez le tableau.
Chaîne invalide	Un enregistrement scellé ou une entrée de garde ne correspond plus à son empreinte.	Conservez les preuves, ouvrez un incident et suivez le runbook SOC.

Pages liées

• Kill Switch
• Incidents
• Posture de sécurité
• Preuves et scellés
• Runbook SOC
• Brique kill switch des agents