Validation humaine des agents de sécurité
Contenir une menace demande une décision, pas seulement une alerte.
L’analyste de permanence autorise la mesure sur son téléphone. La décision peut rejoindre le dossier d’incident.
Comment un agent IA de SOC obtient-il l’accord pour une mesure de confinement ?
Pushary demande l’accord de l’analyste sur son téléphone. Placez un appel avant l’isolement d’un hôte, la désactivation d’un compte ou un blocage. L’analyste accepte ou refuse sur l’écran verrouillé. Votre agent attend cette réponse au lieu de se fier seulement à un score. Sans réponse à temps, la mesure n’est pas exécutée. Chaque décision est conservée pour le dossier d’incident.
Ce qui demande un accord
Les actions à ne pas laisser partir seules
- isolateHost(hostId)
- Isoler une machine peut arrêter l’intrusion, mais aussi son utilisateur légitime. Sur le mauvais hôte, cela crée un nouvel incident.
- disableAccount(userId)
- Désactiver le mauvais compte interrompt immédiatement le travail d’une personne et génère des demandes au support.
- blockIndicator(type, value)
- Bloquer une adresse IP ou un domaine partagé peut couper des services sans lien avec l’alerte.
- revokeSessions(userId)
- Révoquer toutes les sessions peut être justifié par un vol d’identifiants, pas par une détection erronée. L’analyste doit distinguer les deux.
Le code
Un appel dans votre étape existante
Encadrez l’action concernée, pas l’agent entier. Les tâches sans risque continuent sans demander d’intervention.
pip install pusharyimport os
from pushary import PusharyServer
px = PusharyServer(api_key=os.environ["PUSHARY_API_KEY"])
def contain(alert, action):
# Enrichment and evidence collection never wait for anyone.
context = enrich(alert)
if action.reversible and context.confidence > 0.95:
return apply(action)
decision = px.decisions.ask(
external_id=alert.duty_analyst_id,
type="confirm",
question=(
f"{action.summary} on {action.target}? "
f"Confidence {context.confidence:.0%}. Impact: {action.user_impact}."
),
)
if not decision["approved"]:
return annotate(alert, "containment not authorized")
return apply(action)Qui décide
Décider sans être devant son ordinateur
La décision revient à l’analyste de permanence, parfois seul la nuit. Une demande dans un canal fonctionne en journée. À trois heures du matin, personne ne le lit forcément. Pushary joint son téléphone avec l’identifiant défini par votre planning.
Attendre un humain ne laisse-t-il pas plus de temps à l’attaquant ?
Parfois. Décidez donc mesure par mesure. L’enrichissement, la collecte de preuves et les actions faciles à annuler peuvent être exécutés puis revus. Demandez un accord lorsque l’erreur serait elle-même grave : isoler un hôte de production, désactiver un compte important ou bloquer un service partagé. Un simple score de confiance peut alors déplacer le risque de panne au lieu de le supprimer. La demande mobile vise à joindre rapidement la personne compétente, sans garantir un temps de réponse. Si le délai expire, la mesure protégée n’est pas exécutée et cette expiration reste visible dans l’historique.
Pour approfondir : NIST SP 800-61 sur la gestion des incidents de sécurité informatique.
Intégrez-le à votre produit. Vos utilisateurs ne créent pas de compte Pushary et ne nous paient rien.
Questions fréquentes
Les réponses à vos questions
Peut-on automatiser les détections fiables et valider le reste ?
Cela remplace-t-il notre outil d’astreinte ?
Que contient le dossier après l’incident ?
Et si l’analyste manque la demande ?
La validation humaine pour d’autres produits
Faites intervenir une personne là où sa décision compte.
Connectez chaque utilisateur une fois. Posez la question par un appel et exécutez l’action seulement après un oui. Chaque réponse est conservée.
Start free