La télémétrie informe l’agent, mais ne l’autorise pas
L’exemple de SOC agentique présenté par Cisco à la .conf26 associe des télémétries structurées Snort 3 et EVE, provenant de Cisco Secure Firewall et Cloud Control, à Splunk ES. Le pipeline dispose ainsi d’observations de sécurité exploitables par des systèmes automatisés.
Ce flux met en évidence une distinction essentielle pour les équipes réseau : accéder à la télémétrie d’un pare-feu ne signifie pas être autorisé à le modifier. Un agent peut contribuer à interpréter les événements, à structurer les constats et à formuler une réponse possible, tandis que l’administrateur conserve la décision finale sur les actions sensibles.
Le modèle le plus sûr sépare l’observation, la recommandation, l’autorisation, l’exécution et la vérification.
Cette séparation est indispensable, car une modification de pare-feu peut affecter aussi bien la disponibilité que la sécurité. Une recommandation cohérente au regard d’un flux d’événements peut avoir des conséquences plus larges sur les applications, les dépendances réseau, les accès distants ou les obligations de conformité.
Un workflow avec validation humaine
Un processus gardant l’administrateur dans la boucle peut s’articuler autour de six étapes :
Observer. La télémétrie structurée du pare-feu alimente le pipeline SOC et fournit les faits nécessaires à l’analyse.
Interpréter. L’agent regroupe les événements pertinents et explique pourquoi ils pourraient nécessiter une investigation ou une réponse au niveau des politiques.
Proposer. Toute action suggérée sur le pare-feu devient une modification révisable, et non une commande exécutée immédiatement.
Approuver. Un administrateur habilité vérifie le périmètre, les actifs concernés, le risque opérationnel et le résultat attendu.
Exécuter et vérifier. La modification approuvée suit le processus contrôlé de l’organisation, puis des vérifications confirment le résultat.
Conserver les preuves. La proposition, l’approbation, l’historique de configuration et le résultat des contrôles sont préservés pour les analyses et audits ultérieurs.
L’approbation ne doit pas se limiter à un clic formel. Le valideur doit comprendre ce qui va changer, pourquoi la modification est proposée, quels actifs seront touchés et comment restaurer l’état antérieur.
Une piste de preuves pour rendre les décisions auditables
Un workflow agentique peut produire de nombreuses conclusions intermédiaires. Sans piste de preuves, il devient difficile de reconstituer les raisons ayant conduit à recommander ou à autoriser une action.
Pour les opérations concernant les pare-feu, les éléments utiles comprennent notamment :
La télémétrie à l’origine de l’investigation
La recommandation de l’agent et sa justification
L’identité de l’administrateur ayant donné son accord
La modification de configuration prévue
L’état de la configuration avant et après l’exécution
Les résultats de vérification et les éventuelles opérations de retour arrière
Ces informations ne servent pas uniquement à préparer un audit. Elles permettent aussi d’analyser les faux positifs, d’améliorer les critères de validation, d’enquêter sur les incidents opérationnels et de distinguer clairement la recommandation d’un agent de la décision prise par un humain.
Définir clairement la frontière de contrôle
Un SOC agentique n’impose pas d’abandonner le contrôle aux agents. Une frontière bien conçue leur permet d’accélérer l’analyse tout en réservant les actions à fort impact à des personnes identifiées et responsables.
Le niveau de validation peut varier selon le risque. Une tâche à faible impact peut faire l’objet d’une révision rapide, tandis qu’une modification étendue des politiques doit nécessiter une analyse plus approfondie. Dans tous les cas, l’autorisation doit rester explicite et traçable.
La capacité de retour arrière est tout aussi importante. Si une modification de pare-feu entraîne un effet imprévu, l’équipe doit pouvoir retrouver la configuration précédente et la restaurer de manière contrôlée. La rapidité apportée par les agents ne doit jamais remplacer la rigueur de la gestion de configuration.
La place de ConnectMyAssets
L’exemple de Cisco décrit un parcours de télémétrie propre à un fournisseur et aboutissant dans Splunk ES. ConnectMyAssets complète ce type de workflow SOC avec une couche de gestion et de preuve sur site, indépendante des constructeurs, pour les infrastructures réseau multifournisseurs. L’agent n’a donc pas à devenir l’autorité finale sur les modifications de pare-feu.
Plusieurs modules ConnectMyAssets sont directement pertinents :
Firewall Management pour fournir aux administrateurs une vue structurée de la gestion des pare-feu dans l’environnement supervisé
Backup & History pour conserver les versions de configuration, retracer leur évolution et effectuer un retour arrière en un clic si une restauration est nécessaire
Compliance Engine pour évaluer l’infrastructure selon des politiques alignées sur NIS2, ISO 27001, PCI, CISA et NIST
Dynamic CMDB pour identifier les actifs concernés et replacer une réponse proposée dans son contexte d’infrastructure
Per-asset CVE Tracking pour rapprocher l’exposition aux vulnérabilités des actifs examinés
Credential Vault pour conserver les identifiants d’administration dans un cadre maîtrisé
AI Insights, exécuté localement, pour assister l’analyse sans transformer un service d’IA externe en plan de gestion non contrôlé
Ces fonctions contribuent à établir une chaîne claire entre l’observation de sécurité, l’action validée et les preuves conservées. La télémétrie peut alimenter le SOC, tandis que l’historique des configurations, les contrôles de conformité, le contexte des actifs et les mécanismes de restauration restent accessibles aux administrateurs responsables du réseau.
Il ne faut pas supposer que ConnectMyAssets remplace le parcours de télémétrie Cisco vers Splunk décrit dans la source. Son rôle est d’aider les opérateurs à préserver le contrôle, la traçabilité et la capacité de récupération autour des infrastructures multifournisseurs susceptibles d’être affectées par un workflow agentique.
Source : Cisco Blogs
