Les Signaux De Sécurité N’Autorisent Pas Une Action
Cisco Talos a observé le phishing comme mode d’accès initial dans 50 % de ses interventions au premier trimestre 2025. Il s’agit de ses propres interventions, pas de toutes les violations. L’observation montre néanmoins pourquoi un flux de sécurité ne doit pas traiter un score de modèle comme une autorisation d’agir.
Veracode indique que 45 % des échantillons de code générés par IA dans son évaluation 2025 ont échoué aux tests de sécurité. L’étude DORA 2025 a constaté une utilisation presque universelle de l’IA parmi ses répondants et une relation négative avec la stabilité des livraisons. Ces résultats ne prouvent pas que l’IA cause chaque défaut. Ils justifient de tester le travail assisté par IA dans le système de livraison réel.
Détecter Et Décider Sont Deux Fonctions Différentes
Les modèles neuronaux peuvent classer des logiciels malveillants, résumer des alertes et repérer des motifs dans la télémétrie. Leur sortie reste une preuve. Elle n’autorise pas à isoler un hôte, désactiver un compte ou modifier une configuration de production.
Ces actions dépendent de la criticité de l’actif, de la confiance, des preuves complémentaires, de l’impact métier, de la politique et de l’autorité du répondant. L’architecture doit distinguer clairement perception et autorisation.
Séparer La Perception De L’Exécution
1. La Perception Neuronale Produit Des Preuves
Un modèle peut signaler qu’un trafic ressemble à un motif connu. Conservez la source, la version du modèle, la confiance et le contexte.
2. Une Politique Explicite Évalue Les Conditions
Des règles peuvent exiger une preuve complémentaire, vérifier la classe de l’actif et décider s’il faut recommander un confinement ou demander une approbation. Elles restent susceptibles d’être incomplètes : versionnez-les et testez-les.
3. L’Autorité Contrôle L’Exécution
Un rôle d’incident nommé ou une identité de service strictement limitée exécute l’action approuvée. Les actions réversibles aux conséquences limitées peuvent être automatisées dans le cadre de la politique; les actions ambiguës ou à fort enjeu doivent être transmises à une personne autorisée avec les preuves et la possibilité de reprise.
4. Un Dossier De Décision Permet La Revue
Conservez les preuves, la politique, l’autorité, l’action, le résultat et les exceptions. Ce dossier est plus utile qu’une explication générée après coup.
Le Déploiement Fait Partie Du Modèle De Menace
Certains flux ne peuvent pas envoyer de télémétrie ou de preuves d’incident à un service externe. D’autres le peuvent avec des contrôles définis. Décidez selon la sensibilité, la latence, la connectivité, la garde du modèle, la journalisation et la reprise.
Un déploiement local ou déconnecté réduit certaines dépendances, mais crée des responsabilités de mise à jour, de supervision, de capacité et de cycle de vie du modèle. Consignez ces compromis au lieu de traiter l’emplacement comme une preuve de sécurité.
Commencer Par Une Décision De Sécurité
Choisissez une action, comme isoler un terminal ou désactiver un compte compromis. Définissez les preuves nécessaires, la politique, l’autorité d’approbation, l’identité d’exécution et la reprise. Testez les signaux contradictoires, les preuves périmées, l’indisponibilité de l’approbateur et les actions hors périmètre.
L’objectif n’est pas d’obtenir la certitude d’un modèle, mais d’utiliser des preuves incertaines sans leur donner une autorité incontrôlée.
Si un flux de cybersécurité détecte correctement les menaces mais possède une autorité d’action mal définie, discutez-en avec Evodant.