Qu'est-ce que la réponse à incident ?

Les phases : NIST 800-61 et SANS PICERL

Les deux référentiels de référence - NIST SP 800-61 et le processus de gestion d'incident du SANS, souvent abrégé PICERL - décrivent le même travail avec des découpages différents :

La différence relève de la comptabilité, pas du fond. Ce qui compte, c'est que votre équipe sache nommer la phase où elle se trouve - chaque phase a un objectif différent, et les mélanger (éradiquer avant d'avoir fini de cartographier, par exemple) est exactement ce qui permet aux attaquants de survivre à la réponse.

1. Préparation. Tout ce qui se fait avant l'incident : listes de contacts, playbooks, journalisation qui couvre réellement les systèmes critiques, accès à l'outillage forensique, et entraînement. C'est la phase que la plupart des équipes sous-financent - et celle qui décide du déroulement des autres.
2. Identification. Confirmer qu'un événement est un incident, le cartographier - quels systèmes, quels comptes, depuis quand - et classer la sévérité. Résistez à l'envie de corriger pendant cette phase : chaque changement peut détruire des preuves et alerter l'attaquant.
3. Confinement. Limiter le rayon d'impact : isoler des hôtes, désactiver des comptes, bloquer l'infrastructure de l'attaquant. Le confinement court terme arrête l'hémorragie ; le confinement plus durable maintient l'activité pendant la préparation de l'éradication.
4. Éradication et restauration. Supprimer l'accès et la présence de l'attaquant - malware, mécanismes de persistance, identifiants compromis - puis restaurer les systèmes depuis un état sain connu, en surveillant de près toute tentative de retour.
5. Leçons apprises. Dans les jours qui suivent, tant que la mémoire est fraîche : ce qui s'est passé, ce qui a fonctionné, ce qui a échoué, et ce qui change - nouvelles détections, failles comblées, playbooks mis à jour. Cette phase sépare les équipes qui progressent de celles qui rejouent le même incident.

Le triage par sévérité : tout incident n'est pas une crise

Tout traiter comme critique est aussi destructeur que ne rien traiter ainsi : les équipes s'épuisent, et les vraies crises se noient dans le bruit. La plupart des équipes utilisent trois ou quatre niveaux de sévérité, attribués à l'identification et réévalués quand le périmètre évolue. Quatre questions font l'essentiel du travail :

• Sensibilité des données - le système touché héberge-t-il des données réglementées, confidentielles ou clients ?
• Propagation - s'agit-il d'un poste isolé, ou d'identifiants valables dans tout l'environnement ?
• Impact métier - une activité génératrice de revenus ou liée à la sûreté est-elle touchée ?
• L'horloge réglementaire - des obligations de notification se déclenchent-elles (les 72 heures du RGPD, règles sectorielles), et quand le compte à rebours a-t-il commencé ?

La sévérité dicte le tempo. Un incident de faible sévérité peut attendre les heures ouvrées ; un incident critique active toute l'équipe, un lead d'incident et la communication vers la direction - immédiatement.

Les premières 48 heures

Les premières heures d'un incident sérieux donnent le ton de toute la suite. Une carte approximative de ce à quoi ressemble une bonne exécution :

• Heures 0-2 : confirmer que l'incident est réel, ouvrir un canal de communication dédié hors bande, nommer un lead d'incident, et démarrer un journal chronologique - chaque action, chaque horodatage, chaque décision.
• Heures 2-12 : cartographier avant de corriger. Quels comptes, hôtes et données sont touchés ? Appliquer un confinement court terme là où le risque de propagation dépasse la valeur de l'observation discrète.
• Heures 12-24 : informer la direction avec des faits, pas des spéculations. Impliquer le juridique si des données réglementées peuvent être concernées, et préserver les preuves forensiques - images disque, mémoire volatile - avant toute reconstruction.
• Heures 24-48 : passer de la réaction au plan : étapes d'éradication, ordre de restauration, cadence de communication. Si l'incident dépasse vos capacités ou franchit des seuils légaux, le renfort IR externe doit déjà être engagé à ce stade - pas à l'étude.

L'erreur précoce la plus fréquente est la remédiation silencieuse : réinstaller une machine avant la fin de la cartographie. Cela donne le sentiment d'avancer, et cela détruit précisément les preuves nécessaires pour répondre à la question qui compte le plus - sont-ils encore là ?

Qui fait quoi : les rôles pendant un incident

Les intitulés varient ; les fonctions, non. Un minimum viable, même dans une petite équipe où une personne cumule plusieurs casquettes :

• Lead IR (commandant d'incident) - porte les décisions et le tempo, et protège l'équipe technique de la surcharge de réunions de statut.
• Responsable communication - une seule voix vers la direction, le juridique, les régulateurs et les clients. Personne d'autre ne communique vers l'extérieur.
• Forensique et analyse - établit ce qui s'est réellement passé : point d'entrée, latéralisation, persistance, exfiltration.
• Greffier - tient la chronologie. Cela semble administratif ; c'est inestimable pour la revue post-incident et pour toute suite juridique.

Mesurer la réponse : MTTD, MTTR et ce qu'ils cachent

Deux métriques dominent le reporting IR : le MTTD, temps moyen de détection - combien de temps les attaquants restent avant d'être repérés - et le MTTR, temps moyen de réponse ou de restauration selon l'interlocuteur ; précisez lequel vous mesurez. Les deux méritent d'être suivis. Aucun ne dit tout : les moyennes masquent les cas extrêmes, et une intrusion passée inaperçue échappe entièrement aux deux chiffres.

Boucler la boucle : c'est par la réponse que la défense progresse

Ce n'est pas un hasard si les phases se terminent par les leçons apprises. Chaque incident réel est une vérité terrain sur votre environnement qu'aucun rapport d'éditeur ne peut égaler : il vous dit quelles détections se sont déclenchées et lesquelles auraient dû, quelles étapes de playbook ont fonctionné, et quelles hypothèses ont cédé.