Détection et réponse à incident

Détection et réponse à incident

1. Journalisation et alerte (A09)

   Neuvième risque du classement 2025. Une intrusion non détectée est une intrusion qui dure : la question n'est pas seulement « cela s'est-il produit ? » mais « combien de temps avant que je le sache ? ».

   Ce qu'il faut journaliser

   • connexions et échecs d'authentification ;
   • changements de privilèges et création de comptes ;
   • accès aux données sensibles et exports en masse ;
   • modifications de configuration et de secrets ;
   • échecs applicatifs inhabituels.

   Ce qu'il ne faut pas journaliser

   Mot de passe, jeton, carte bancaire, donnée personnelle complète. Un journal qui contient un secret devient une cible, et un journal plein de secrets coûte cher à protéger.

   L'alerte

   Un journal sans seuil d'alerte n'est qu'un fichier. Quelques signaux à surveiller en priorité : échecs d'authentification en rafale, accès inhabituels à des données sensibles hors heures ouvrées, et toute élévation de privilège.

2. Réponse à incident

   La réponse à incident se prépare à froid. En pleine crise, personne n'improvise bien : les décisions se prennent à partir d'un document écrit avant.

   1. Préparer : qui décide, qui intervient, comment joindre l'ANSSI ou le client, comment préserver les preuves.
   2. Détecter et qualifier : périmètre, données concernées, impact.
   3. Contenir : isoler sans détruire les traces.
   4. Éradiquer et corriger : la cause, pas seulement le symptôme.
   5. Réagir : information des personnes concernées, notification aux autorités si obligatoire.
   6. Apprendre : retours d'expérience écrits, mesures ajoutées au guide de production.

   Deux échéances à connaître : le RGPD impose de notifier une violation de données à l'autorité de contrôle dans les meilleurs délais et, lorsque le risque est élevé, aux personnes concernées ; NIS2 impose aux entités concernées de signaler les incidents d'impact important à l'ANSSI, selon les règles nationales de notification.

   Le réflexe de départ, avant toute analyse : préserver les preuves. Redémarrer une machine ou purger des journaux fait perdre ce qui désigne la cause.

3. Observation et déplacement latéral

   La référence publique pour décrire le comportement d'un attaquant est MITRE ATT&CK, qui organise ses techniques en tactiques. L'intérêt n'est pas la liste : c'est la méthode.

   Sur une machine compromise, on regarde ce que le processus fait réellement : les processus lancés, les connexions sortantes, les clés d'accès lues, les comptes utilisés. La plupart des intrusions ne restent pas sur la machine d'entrée : elles se déplacent latéralement vers d'autres machines, ce qui n'apparaît sur aucun pare-feu puisqu'il s'agit de trafic autorisé par des identifiants volés.

   La parade tient en deux points : principe du moindre privilège — un compte de service ne fait que ce qu'il lui faut — et surveillance des comptes — un usage inhabituel d'un compte service doit remonter.

4. Exercices

   1. Plan d'incident : écrivez la procédure de réponse à incident de votre application : qui fait quoi, dans quel ordre, et à quoi on ne touche pas.
   2. Revue des journaux : relevez ce que votre application journalise aujourd'hui, et complétez la liste manquante.
   3. Exercice de crise : simulez la compromission d'un compte de service et décrivez les trois premiers gestes, sans rien détruire.