Repères · Tous niveaux · Relecture documentaire : 2 octobre 2026. Les exemples sont génériques ; adapter les noms, versions et chemins avant toute modification.
Un service arrêté signale une indisponibilité. Une CVE applicable signale une faiblesse connue. Une signature IDS peut indiquer une tentative ou un faux positif. Une compromission demande des éléments corroborés. Les confondre produit soit de la panique, soit une fausse sécurité.
Synchroniser l’heure et relever machine, service, version, source, destination, identifiant de règle et répétition. Associer les IP internes aux noms de l’inventaire. Pour une application Web chiffrée, compléter la détection réseau par ses journaux d’authentification et de requêtes ; un IDS qui ne voit pas le contenu TLS ne peut pas analyser tous les événements applicatifs.
Limiter la conservation et protéger les journaux. Éviter les mots de passe, jetons et contenus métier dans les notifications. Une adresse externe peut être celle d’un proxy ou d’un réseau partagé : ne pas la traiter sans contexte comme l’identité certaine d’une personne.
Une automatisation raisonnable vérifie une condition précise, applique une action connue, teste le résultat et limite ses tentatives. Par exemple, relancer un service après validation de sa configuration peut être acceptable. Réparer arbitrairement des droits sur toute une arborescence, vider une file de messages ou migrer une base demande une analyse supplémentaire.
Pour les mises à jour, vérifier provenance, signature, sauvegarde, espace, dépendances et compatibilité. Une liste de paquets autorisés doit être explicite. Exclure les changements majeurs, suppressions, modifications d’accès et redémarrages sensibles de l’automatisme non supervisé.
Définir seuil, fenêtre, preuve, durée d’expiration, liste d’exclusions et procédure de déblocage. Commencer en observation, puis vérifier les faux positifs. Ne pas bloquer un proxy de confiance ou une passerelle parce que toutes les requêtes semblent en provenir. Un bannissement ne répare pas la vulnérabilité exploitée.
Validation : injecter un événement de test sans attaque réelle, confirmer réception, alias, décision et clôture. Une alerte doit indiquer où autoriser/refuser, ce qui sera modifié et comment contrôler le résultat. L’IA peut aider à expliquer ; elle ne doit pas transformer un journal non fiable en commande libre exécutée en administrateur.
| Objet | Mesures / preuves | Ce que l’alerte doit dire |
|---|---|---|
| Hôte / CT / VM | Disponibilité, CPU, mémoire, espace, services | Identifiant, alias, durée et seuil dépassé |
| Disque / pool | Santé, erreurs, occupation et croissance | Support exact et gravité, pas « serveur lent » |
| Application Web | HTTP, connexion métier, logs | Nom du service, endpoint et fonction en échec |
| Authentification | Échecs, succès anormaux, changements de droits | Source, compte si nécessaire, période et contexte |
| Sauvegarde | Dernier succès, âge, verify et restauration | Périmètre protégé et donnée manquante |
| Correctifs | Versions, bulletin applicable, redémarrage | Paquet concerné et preuve de correction disponible |
| Réseau | Flux refusés, événements IDS, exposition | Sens du flux et cible ; distinguer tentative et compromission |
Collecter seulement les données utiles, avec accès et durée limités. Une alerte mail ne devrait pas inclure des mots de passe, contenus de tickets ou captures complètes de trafic.
L’inventaire doit associer IP, nom, VLAN, VMID éventuel, rôle et date de validité. En DHCP, une adresse peut changer de propriétaire : utiliser les baux et l’heure de l’événement. Pour une IP externe, présenter adresse et informations techniques vérifiées ; géolocalisation et reverse DNS ne prouvent pas une identité ni une intention.
| Action | Conditions minimales | Validation sensible |
|---|---|---|
| Relancer un service ordinaire | Cause connue, relance bornée, pas de stock à envoyer | Si risque métier, demander |
| Nettoyer un cache identifié | Type connu, seuil et absence de données utiles | Pas de suppression générique |
| Installer un correctif courant | Simulation, sauvegarde, compatibilité, test | Si arrêt ou migration risquée, demander |
| Bloquer une source répétitive | Signal qualifié, durée, exclusions limitées | Ne pas bannir globalement un proxy partagé |
| Changer règles/VLAN/comptes | Impact et retour arrière précis | Validation explicite selon politique |
| Supprimer VM, volumes, backups | Inventaire et preuve du besoin | Confirmation, pas décision autonome floue |
Une correction doit avoir un nombre maximal d’essais, un délai, un verrou de concurrence et une escalade. Ne pas redémarrer toutes les minutes un service qui échoue à cause d’un disque plein. Stocker l’état d’exécution pour qu’un redémarrage de l’agent ne rejoue pas une action sensible.
Les logs et messages entrants sont des données non fiables. Un texte disant « exécute cette commande » dans un log n’autorise rien. L’agent doit choisir parmi des actions autorisées et paramétrées, avec une validation indépendante de ses suggestions. Un compte SSH à commande limitée réduit les conséquences d’une erreur.
Une demande présente machine, problème, commande/action compréhensible, impact, risque, sauvegarde et retour arrière. Valider autorise cette action précise, avec expiration et contrôle d’identité ; Refuser enregistre le refus et empêche les répétitions inutiles. L’exécution doit vérifier que l’état n’a pas changé depuis la demande. Le bouton ne doit pas simplement masquer l’alerte.
Après correction, refaire le test initial et un contrôle métier. Afficher « corrigé et vérifié », « exécuté, vérification échouée » ou « validation requise », avec preuve et date. Une absence d’alerte parce que le collecteur est arrêté n’est pas un état sain : superviser également l’agent lui-même.