◆ Pour le responsable du SOC et le RSSI

Laissez vos agents SOC agir.
Chaque réponse passe par votre politique.

L’agent ne détient aucun identifiant sur votre EDR, votre SIEM ou votre fournisseur d’identité. Il propose ; la règle décide.

Parlons-en 30 min →Voir le tableau de votre politique

◆ Pour le responsable du SOC et le RSSI

Laissez vos agents SOC agir. Chaque réponse passe par votre politique.

L’agent ne détient aucun identifiant sur votre EDR, votre SIEM ou votre fournisseur d’identité. Il propose ; la règle décide.

Parlons-en 30 min →Voir le tableau de votre politique

Là où le pilote se bloque

Le triage est livré en quelques semaines. Puis quelqu’un demande si l’agent peut isoler l’hôte.

Un SOC a trois couches qui décident. L’identité dit où l’agent peut se connecter. L’orchestration dit dans quel playbook il se trouvait. Aucune des deux ne dit si cette action-là avait le droit de s’exécuter.

CoucheRépond àComposants
DétectionEst-ce qu’il se passe quelque chose ?SIEM, EDR, NDR
OrchestrationQu’est-ce qui s’exécute ensuite ?Playbooks SOAR
IdentitéQui peut se connecter à quoi ?IAM, PAM, SSO
AutoritéCette action, sur cette cible, a-t-elle le droit de s’exécuter maintenant ?Personne. Jusqu’ici, l’analyste.

ZIFFER décide si une action proposée s’exécute. Il ne détecte rien, il ne rend pas le triage plus juste, et il ne remplace ni votre SIEM ni votre SOAR.

Là où le pilote se bloque

Le triage est livré en quelques semaines. Puis quelqu’un demande si l’agent peut isoler l’hôte.

Un SOC a trois couches qui décident. L’identité dit où l’agent peut se connecter. L’orchestration dit dans quel playbook il se trouvait. Aucune des deux ne dit si cette action-là avait le droit de s’exécuter.

  • DétectionEst-ce qu’il se passe quelque chose ?SIEM, EDR, NDR
  • OrchestrationQu’est-ce qui s’exécute ensuite ?Playbooks SOAR
  • IdentitéQui peut se connecter à quoi ?IAM, PAM, SSO
  • AutoritéCette action, sur cette cible, a-t-elle le droit de s’exécuter maintenant ?Personne. Jusqu’ici, l’analyste.

ZIFFER décide si une action proposée s’exécute. Il ne détecte rien, il ne rend pas le triage plus juste, et il ne remplace ni votre SIEM ni votre SOAR.

◆ Trois étapes, une seule politique

L’agent enquête librement. Seule votre règle lui permet de répondre.

  • Enquêter. Chaque appel d’outil est une proposition. Les actions de forme fixe sont des entrées de catalogue, et l’agent ne peut pas en exprimer une hors du catalogue.
  • Répondre. Réversible et dans le périmètre : autorisée en 41 ms. Irréversible ou à fort impact : mise en attente d’un quorum de deux personnes nommément désignées, qui signent les octets exacts qui s’exécuteront. Aucune règle : refusée.
  • Prouver. Chaque issue, refus compris, laisse un reçu signé : l’alerte, la version de la politique, qui a approuvé, ce qui s’est exécuté. Ce reçu est l’enregistrement de décision que votre auditeur demande.

◆ Trois étapes, une seule politique

L’agent enquête librement. Seule votre règle lui permet de répondre.

  • Enquêter. Chaque appel d’outil est une proposition. Les actions de forme fixe sont des entrées de catalogue, et l’agent ne peut pas en exprimer une hors du catalogue.
  • Répondre. Réversible et dans le périmètre : autorisée en 41 ms. Irréversible ou à fort impact : mise en attente d’un quorum de deux personnes nommément désignées, qui signent les octets exacts qui s’exécuteront. Aucune règle : refusée.
  • Prouver. Chaque issue, refus compris, laisse un reçu signé : l’alerte, la version de la politique, qui a approuvé, ce qui s’est exécuté. Ce reçu est l’enregistrement de décision que votre auditeur demande.

Sur une vraie garde

La règle décide, pas le modèle.

Un agent trompé par un ticket empoisonné et un agent qui a toujours raison rencontrent la même table.

PropositionCibleÉvaluationIssue
isolate_hostPoste de testLOW✓ autorisée · 41 ms
isolate_hostServeur applicatif de productionHIGH■ en attente · 2 sur 2 approbateurs de garde
isolate_hostContrôleur de domaineaucune règle✕ refusée · un humain le fait depuis la console, comme aujourd’hui
block_indicatorPare-feu périmétrique, IP hors liste d’autorisationLOW✓ autorisée
block_indicatorPare-feu périmétrique, IP sur la liste d’autorisation des partenairesHIGH■ en attente · 2 sur 2
disable_userCompte standard, vol d’identifiants confirméHIGH■ en attente · 2 sur 2
revoke_sessionsCompte standard, dans votre limite horaireLOW✓ autorisée
revoke_sessionsCompte d’administration ou de directionHIGH■ en attente · 2 sur 2
delete_logsToute cibleaucune règle✕ refusée · consigné

LOW est une décision qui vous appartient. Ce que vous évaluez LOW, vous avez accepté que l’agent puisse le faire sur une mauvaise lecture de l’alerte. Évaluez LOW ce que vous pouvez annuler, bornez-le par classe de cible et par heure, et laissez les reçus vous dire quand l’élargir.

Ce qui change sur le terrain

Aujourd’hui, proposition seuleAvec une couche d’autorité
L’agent trie en quelques secondes et écrit une recommandation. Un analyste ouvre la console EDR et isole l’hôte, ouvre la console du pare-feu et bloque l’IP, ouvre le fournisseur d’identité et révoque les sessions, puis documente ce qu’il a fait.La même recommandation est un ensemble de propositions. Celles que votre politique évalue LOW s’exécutent telles qu’elles sont proposées. Celles évaluées HIGH sont mises en attente de la signature des approbateurs de garde. Celles qu’aucune règle ne couvre sont refusées et consignées.
Le temps gagné au triage est redépensé à l’exécution. Le pilote montre un meilleur analyste, pas un SOC plus rapide.L’analyste examine des issues, pas une file d’attente.

Deux chiffres bougent, et les deux se mesurent dans votre SOC : la part des actions de réponse qui ne passent plus par un clavier humain, et le temps entre la détection et la première action de confinement. Un troisième reste plat par construction, à zéro : les actions irréversibles prises sans la signature d’une personne nommément désignée.

Parlons-en 30 min →

Sur une vraie garde

La règle décide, pas le modèle.

Un agent trompé par un ticket empoisonné et un agent qui a toujours raison rencontrent la même table.

  • isolate_hostPoste de testLOW ✓ autorisée · 41 ms
  • isolate_hostServeur applicatif de productionHIGH ■ en attente · 2 sur 2 approbateurs de garde
  • isolate_hostContrôleur de domaineaucune règle ✕ refusée · un humain le fait depuis la console, comme aujourd’hui
  • block_indicatorPare-feu périmétrique, IP hors liste d’autorisationLOW ✓ autorisée
  • block_indicatorPare-feu périmétrique, IP sur la liste d’autorisation des partenairesHIGH ■ en attente · 2 sur 2
  • disable_userCompte standard, vol d’identifiants confirméHIGH ■ en attente · 2 sur 2
  • revoke_sessionsCompte standard, dans votre limite horaireLOW ✓ autorisée
  • revoke_sessionsCompte d’administration ou de directionHIGH ■ en attente · 2 sur 2
  • delete_logsToute cibleaucune règle ✕ refusée · consigné

LOW est une décision qui vous appartient. Ce que vous évaluez LOW, vous avez accepté que l’agent puisse le faire sur une mauvaise lecture de l’alerte. Évaluez LOW ce que vous pouvez annuler, bornez-le par classe de cible et par heure, et laissez les reçus vous dire quand l’élargir.

Ce qui change sur le terrain

  • Aujourd’hui, proposition seuleL’agent trie en quelques secondes et écrit une recommandation. Un analyste ouvre la console EDR et isole l’hôte, ouvre la console du pare-feu et bloque l’IP, ouvre le fournisseur d’identité et révoque les sessions, puis documente ce qu’il a fait.Avec une couche d’autoritéLa même recommandation est un ensemble de propositions. Celles que votre politique évalue LOW s’exécutent telles qu’elles sont proposées. Celles évaluées HIGH sont mises en attente de la signature des approbateurs de garde. Celles qu’aucune règle ne couvre sont refusées et consignées.
  • Aujourd’hui, proposition seuleLe temps gagné au triage est redépensé à l’exécution. Le pilote montre un meilleur analyste, pas un SOC plus rapide.Avec une couche d’autoritéL’analyste examine des issues, pas une file d’attente.

Deux chiffres bougent, et les deux se mesurent dans votre SOC : la part des actions de réponse qui ne passent plus par un clavier humain, et le temps entre la détection et la première action de confinement. Un troisième reste plat par construction, à zéro : les actions irréversibles prises sans la signature d’une personne nommément désignée.

Parlons-en 30 min →

S’adapte à la pile que vous exploitez déjà.

Vos agents, vos orchestrateurs et vos systèmes restent où ils sont. Ce qui change, c’est qui détient l’identifiant.

Via MCP, ZIFFER publie votre catalogue d’actions comme les outils de l’agent. Un appel au SDK fonctionne aussi, et le HTTPS simple également.

n’importe quel modèleMistral, OpenAI, Anthropic, ou un modèle à poids ouverts sur votre propre matériel. L’agent, le modèle et le framework ne changent pas.
n’importe quel orchestrateurXSOAR, Splunk SOAR, Tines et Torq gardent leurs playbooks. ZIFFER décide de ce qui a le droit de s’exécuter, pour chaque agent qui atteint vos systèmes en passant par ZIFFER.
n’importe quel systèmeEDR, SIEM, pare-feu, fournisseur d’identité, gestion de tickets : chacun reçoit un identifiant à portée limitée que seul ZIFFER peut utiliser. Vos systèmes n’acceptent les actions de réponse automatisées que depuis l’identité de ZIFFER.

La condition : ZIFFER ne couvre un agent que là où cet agent ne détient aucun identifiant propre. Un agent construit avec une clé d’API EDR dans un fichier de configuration reste hors du mur tant que cette clé n’est pas révoquée. Vos analystes gardent leurs consoles et leurs propres comptes.

S’adapte à la pile que vous exploitez déjà.

Vos agents, vos orchestrateurs et vos systèmes restent où ils sont. Ce qui change, c’est qui détient l’identifiant.

Via MCP, ZIFFER publie votre catalogue d’actions comme les outils de l’agent. Un appel au SDK fonctionne aussi, et le HTTPS simple également.

n’importe quel modèleMistral, OpenAI, Anthropic, ou un modèle à poids ouverts sur votre propre matériel. L’agent, le modèle et le framework ne changent pas.
n’importe quel orchestrateurXSOAR, Splunk SOAR, Tines et Torq gardent leurs playbooks. ZIFFER décide de ce qui a le droit de s’exécuter, pour chaque agent qui atteint vos systèmes en passant par ZIFFER.
n’importe quel systèmeEDR, SIEM, pare-feu, fournisseur d’identité, gestion de tickets : chacun reçoit un identifiant à portée limitée que seul ZIFFER peut utiliser. Vos systèmes n’acceptent les actions de réponse automatisées que depuis l’identité de ZIFFER.

La condition : ZIFFER ne couvre un agent que là où cet agent ne détient aucun identifiant propre. Un agent construit avec une clé d’API EDR dans un fichier de configuration reste hors du mur tant que cette clé n’est pas révoquée. Vos analystes gardent leurs consoles et leurs propres comptes.

◆ Ce que vous remettez

Ce que le responsable du SOC rapporte. Ce que l’auditeur demande. Un seul enregistrement répond aux deux.

Par garde, vers le haut

  • Actions proposées, autorisées, mises en attente et refusées
  • Actions exécutées hors politique : zéro, par construction
  • Actions exécutées dans la politique qui étaient mauvaises : comptées, avec le reçu qui montre quelle règle les a laissées passer
  • Temps entre l’autorisation et l’exécution, sur les actions autorisées
  • Latence des approbateurs sur les actions en attente, et mises en attente expirées sans signature

Après l’incident, à l’auditeur

  • Quelles actions de réponse ont été prises, quand, par quelle identité, et qui a approuvé
  • Chaque refus consigné : une instruction injectée qui a tenté de supprimer des sauvegardes est une preuve, pas du bruit
  • La version de la politique sur laquelle chaque action a été évaluée
  • La double autorisation, le mot de l’auditeur pour notre quorum de deux personnes nommément désignées
  • La non-répudiation : un reçu signé derrière chaque chiffre, pas une ligne de journal qu’un administrateur peut modifier

Aujourd’hui, cette réponse s’assemble à partir de l’historique du SOAR, des journaux d’audit de l’EDR et de fils de discussion. Un reçu ZIFFER porte tout cela pour chaque action d’agent, dans un registre que votre propre administrateur ne peut pas réécrire une fois l’enregistrement ancré. Mêmes clauses publiées que la liste de contrôle de la page d’accueil : AC-3(2) pour la double autorisation, AU-10 pour la non-répudiation.

◆ Ce que vous remettez

Ce que le responsable du SOC rapporte. Ce que l’auditeur demande. Un seul enregistrement répond aux deux.

Par garde, vers le haut

  • Actions proposées, autorisées, mises en attente et refusées
  • Actions exécutées hors politique : zéro, par construction
  • Actions exécutées dans la politique qui étaient mauvaises : comptées, avec le reçu qui montre quelle règle les a laissées passer
  • Temps entre l’autorisation et l’exécution, sur les actions autorisées
  • Latence des approbateurs sur les actions en attente, et mises en attente expirées sans signature

Après l’incident, à l’auditeur

  • Quelles actions de réponse ont été prises, quand, par quelle identité, et qui a approuvé
  • Chaque refus consigné : une instruction injectée qui a tenté de supprimer des sauvegardes est une preuve, pas du bruit
  • La version de la politique sur laquelle chaque action a été évaluée
  • La double autorisation, le mot de l’auditeur pour notre quorum de deux personnes nommément désignées
  • La non-répudiation : un reçu signé derrière chaque chiffre, pas une ligne de journal qu’un administrateur peut modifier

Aujourd’hui, cette réponse s’assemble à partir de l’historique du SOAR, des journaux d’audit de l’EDR et de fils de discussion. Un reçu ZIFFER porte tout cela pour chaque action d’agent, dans un registre que votre propre administrateur ne peut pas réécrire une fois l’enregistrement ancré. Mêmes clauses publiées que la liste de contrôle de la page d’accueil : AC-3(2) pour la double autorisation, AU-10 pour la non-répudiation.

Objections du SOC

Ce que le responsable du SOC demande avant la première réponse automatisée.

Notre EDR isole déjà automatiquement sur les détections à forte confiance.

Gardez-le. Ce chemin est déclenché par vos règles de détection sur votre télémétrie. ZIFFER se place sur le chemin où un agent LLM, ayant lu un texte que vous ne contrôlez pas, propose la même action. Même issue, déclencheur différent, problème d’autorisation différent.

Notre SOAR a déjà des étapes d’approbation.

Il gouverne ses propres playbooks. Il ne voit pas l’agent qui appelle directement l’API de l’EDR, ni le copilote de votre outil de tickets, ni le prochain agent que quelqu’un livrera. La politique doit se placer là où passent les actions de tous les agents, sinon c’est une politique pour un seul outil.

Mettre des actions en attente de deux personnes tue le temps de réponse à 3 heures du matin.

L’enrichissement, la révocation des sessions d’un utilisateur standard et le blocage d’une IP inconnue sont les actions que vous évaluez LOW, et celles-là s’exécutent en millisecondes. Seules les actions que personne ne peut annuler sont mises en attente. Le quorum est un rôle : deux quelconques de vos approbateurs de garde nommément désignés. Une mise en attente que personne ne signe expire et est consignée comme telle. Elle ne devient jamais silencieusement une autorisation.

Nous allons garder l’agent en mode proposition seule pour l’instant.

C’est l’état de tous les pilotes aujourd’hui, et c’est là que le retour s’arrête. La revue vous dit quelles actions de réponse pourraient être LOW sans risque dès demain, lesquelles votre politique mettrait en attente, et lesquelles aucune règle ne devrait jamais couvrir.

Nous allons attendre que notre éditeur de SOAR livre cela.

Ils le livreront pour leurs playbooks. Demandez-leur si cela couvre les agents qu’ils n’orchestrent pas, et si le reçu peut être vérifié sans accès à leur console.

Objections du SOC

Ce que le responsable du SOC demande avant la première réponse automatisée.

Notre EDR isole déjà automatiquement sur les détections à forte confiance.

Gardez-le. Ce chemin est déclenché par vos règles de détection sur votre télémétrie. ZIFFER se place sur le chemin où un agent LLM, ayant lu un texte que vous ne contrôlez pas, propose la même action. Même issue, déclencheur différent, problème d’autorisation différent.

Notre SOAR a déjà des étapes d’approbation.

Il gouverne ses propres playbooks. Il ne voit pas l’agent qui appelle directement l’API de l’EDR, ni le copilote de votre outil de tickets, ni le prochain agent que quelqu’un livrera. La politique doit se placer là où passent les actions de tous les agents, sinon c’est une politique pour un seul outil.

Mettre des actions en attente de deux personnes tue le temps de réponse à 3 heures du matin.

L’enrichissement, la révocation des sessions d’un utilisateur standard et le blocage d’une IP inconnue sont les actions que vous évaluez LOW, et celles-là s’exécutent en millisecondes. Seules les actions que personne ne peut annuler sont mises en attente. Le quorum est un rôle : deux quelconques de vos approbateurs de garde nommément désignés. Une mise en attente que personne ne signe expire et est consignée comme telle. Elle ne devient jamais silencieusement une autorisation.

Nous allons garder l’agent en mode proposition seule pour l’instant.

C’est l’état de tous les pilotes aujourd’hui, et c’est là que le retour s’arrête. La revue vous dit quelles actions de réponse pourraient être LOW sans risque dès demain, lesquelles votre politique mettrait en attente, et lesquelles aucune règle ne devrait jamais couvrir.

Nous allons attendre que notre éditeur de SOAR livre cela.

Ils le livreront pour leurs playbooks. Demandez-leur si cela couvre les agents qu’ils n’orchestrent pas, et si le reçu peut être vérifié sans accès à leur console.

Gardez l’analyste. Retirez l’identifiant.

Trente minutes avec votre responsable du SOC. Vous repartez avec vos actions de réponse évaluées LOW, HIGH ou refusées, et le reçu type que votre auditeur recevrait. Si la proposition seule vous suffit aujourd’hui, la note de validation le dit.

Parlons-en 30 min →

Mise en service sous 48 heures · spécification ouverte · vérifiez avant de payer

Gardez l’analyste. Retirez l’identifiant.

Trente minutes avec votre responsable du SOC. Vous repartez avec vos actions de réponse évaluées LOW, HIGH ou refusées, et le reçu type que votre auditeur recevrait. Si la proposition seule vous suffit aujourd’hui, la note de validation le dit.

Parlons-en 30 min →

Mise en service sous 48 heures · spécification ouverte · vérifiez avant de payer