Réponse à incident : étapes, décisions et principes

Niveau : débutant à intermédiaire.

Prérequis : connaître les notions de compte, poste, serveur, journal, sauvegarde, actif critique et risque. Savoir distinguer un événement, une alerte et un incident facilite la lecture. Aucun outil spécialisé n’est nécessaire.

L’exercice est strictement défensif, local et fictif. Tu analyses une chronologie fournie, sans connexion à un service tiers, sans recherche de vulnérabilité et sans manipulation d’un système réel.

La réponse à incident désigne l’ensemble des activités utilisées pour préparer, détecter, analyser, contenir, éradiquer et restaurer après un événement de cybersécurité. Cet article explique comment le processus fonctionne et comment ses décisions s’enchaînent. Il ne décrit ni le recrutement, ni le salaire, ni le quotidien professionnel d’un spécialiste. La fiche métier réponse à incident répond à cette autre intention.

Une alerte est seulement un signal à qualifier. Un incident justifie une coordination et des mesures de traitement. Des seuils, des niveaux de gravité et une autorité de décision évitent de banaliser les alertes ou d’attendre une certitude absolue.

Le NIST SP 800-61 Rev. 3 inscrit la réponse dans la gestion globale du risque selon le CSF 2.0. Les activités de préparation et d’amélioration entourent les actions menées pendant l’incident. Le modèle reste cyclique : une restauration peut révéler une nouvelle trace et renvoyer vers l’analyse.

La préparation commence par un inventaire suffisamment fiable : actifs, propriétaires, dépendances, criticité, journaux disponibles, sauvegardes et contacts. Ajoute une matrice de gravité qui combine impact, étendue, sensibilité des données et urgence métier. Définis qui peut isoler un poste, suspendre un compte, arrêter un service, contacter un prestataire ou déclencher une communication.

Prépare des canaux alternatifs, car la messagerie habituelle peut être indisponible ou observée. Les listes de contacts doivent fonctionner hors du système touché. Les procédures indiquent les premières vérifications, les conditions d’escalade, les données à préserver et les critères d’arrêt. Elles ne doivent pas imposer une séquence aveugle face à tous les scénarios.

Les playbooks de réponse de la CISA illustrent la valeur de rôles, de points de décision, de listes d’actions et de coordination documentés. Adapte ce principe à ton contexte plutôt que de copier un document fédéral. Teste régulièrement les accès d’urgence, les numéros, l’export des journaux et la capacité à restaurer. Un plan jamais exercé reste une hypothèse.

Commence par consigner la source du signal, l’heure de réception, le système concerné et l’auteur du signalement. Préserve les données volatiles ou journaux pertinents selon la procédure, sans modifier inutilement l’hôte. Construis une chronologie en séparant trois colonnes : faits observés, interprétations et informations manquantes.

Cherche l’étendue : comptes, machines, applications, données et périodes potentiellement concernés. Recoupe plusieurs sources, par exemple fournisseur d’identité, EDR, application, pare-feu et administration cloud. Une adresse IP commune ou un nom de fichier ne suffit pas à attribuer une action. Vérifie les fuseaux, la dérive des horloges, les pertes de collecte et les changements légitimes.

Attribue une gravité provisoire et révise-la lorsque de nouveaux faits apparaissent. Une bonne qualification formule ce qui est connu, le degré de confiance, l’impact possible et la prochaine question. Elle inclut aussi une hypothèse concurrente, comme une opération d’administration autorisée. Le but n’est pas de raconter rapidement une attaque complète, mais de fournir assez de précision pour choisir une mesure proportionnée et réversible lorsque c’est possible.

Le confinement réduit la propagation ou l’exposition pendant que l’analyse continue. Il peut être court terme, comme isoler un poste du réseau, révoquer une session ou bloquer un indicateur très précis. Il peut aussi préparer une stabilisation plus durable, par exemple segmenter une zone ou migrer une fonction vers un environnement sain.

Chaque action comporte un coût. Couper un serveur peut interrompre un service essentiel, effacer de la mémoire utile ou avertir un acteur encore présent. Ne rien couper peut accroître l’impact. Évalue donc la criticité, la confiance dans le diagnostic, la propagation possible, la réversibilité et les exigences de preuve. Note qui autorise l’action et quel signal permettra de la lever.

Préfère une mesure ciblée si elle traite le risque : désactiver un compte compromis plutôt que tout l’annuaire, isoler un segment plutôt que toute l’organisation. Mais une mesure étroite n’est pas toujours suffisante. Contrôle son effet dans les journaux et surveille les chemins alternatifs. Le confinement n’est pas l’éradication : un poste isolé peut conserver la cause, et un mot de passe changé peut rester exposé si une session ou un jeton demeure valide.

L’éradication vise les éléments identifiés pendant l’analyse : logiciel malveillant, persistance, compte non autorisé, secret exposé, règle détournée, configuration faible ou vulnérabilité exploitée. Commence par établir une liste de constats reliés à des preuves. Pour chaque constat, associe une correction et une méthode de vérification.

Supprimer un fichier suspect ne suffit pas si un mécanisme le recrée. Réinitialiser un mot de passe ne suffit pas si des jetons restent actifs. Appliquer un correctif ne suffit pas si un autre hôte identique demeure vulnérable. Cherche donc les dépendances, les identités techniques et les variantes du même chemin. Les changements doivent passer par un contrôle adapté même sous pression, avec sauvegarde de configuration et possibilité de retour arrière.

Définis un niveau de confiance et les angles morts. Si l’intégrité d’un hôte reste incertaine, préfère une reconstruction depuis une source maîtrisée. Conserve les preuves nécessaires avec leur origine et l’historique des manipulations lorsque la situation l’exige.

Restaurer ne signifie pas seulement redémarrer. Définis l’état sain attendu : version corrigée, configuration approuvée, identités renouvelées, données cohérentes, dépendances disponibles et journalisation active. Choisis une source de restauration antérieure à la compromission supposée et vérifie son intégrité. Une sauvegarde récente peut déjà contenir la cause de l’incident.

Remets les services par étapes selon leur criticité. Teste dans un environnement isolé si possible, puis vérifie fonctions métier, accès, flux, alertes et données. Renforce temporairement la surveillance des actifs concernés.

Définis des critères de sortie observables : tests fonctionnels réussis, absence d’indicateur connu pendant une fenêtre convenue et validation métier. Un mode dégradé doit préciser les fonctions indisponibles, le risque résiduel et la date de réévaluation.

Tiens un journal de crise unique avec heures, décisions, auteurs, raisons, actions, résultats et prochaines échéances. Distingue le temps de l’événement, celui de sa découverte et celui de l’action. Cette trace soutient les relèves, évite les répétitions et permet d’expliquer les arbitrages après coup.

Adapte chaque message à son destinataire sans masquer les incertitudes. Les équipes techniques ont besoin d’indicateurs et de consignes précises. Les responsables métier ont besoin d’impacts, de dépendances et d’options. Les communications externes doivent être coordonnées avec les fonctions juridiques, protection des données, assurance et direction selon le contexte. N’affirme pas une attribution ou une exfiltration sans preuve suffisante.

L’ISO/IEC 27035-1:2023 structure les principes et le processus de gestion des incidents de sécurité de l’information. Elle aide à relier détection, évaluation, réponse et apprentissage, mais les obligations concrètes dépendent du secteur, du contrat et des données. Identifie ces obligations pendant la préparation, avec contacts et délais, au lieu d’improviser leur interprétation pendant la crise.

Organise un retour d’expérience lorsque les faits sont stabilisés. Reconstitue la chronologie, compare les décisions aux informations disponibles à l’instant où elles ont été prises et distingue chance, erreur et faiblesse structurelle.

Analyse ce qui a aidé ou ralenti : inventaire, télémétrie, escalade, accès d’urgence, sauvegardes, coordination, fournisseurs, capacité de restauration et communication. Transforme chaque enseignement retenu en action avec propriétaire, échéance et preuve attendue. Par exemple, « améliorer les logs » devient « activer et centraliser les événements d’administration de l’application, puis vérifier chaque semaine leur réception ».

Mesure les délais de qualification, de confinement et de restauration, ainsi que les sources absentes. Utilise ces indicateurs pour détecter les frictions. Mets à jour les playbooks, puis rejoue le scénario afin de vérifier les améliorations.

Travaille uniquement sur cette chronologie fictive d’une association :

09:02 alerte MFA répétée pour compte lea
09:05 connexion réussie depuis 192.0.2.40
09:08 ajout du compte lea au groupe facturation-admin
09:11 export de 12 fiches de test depuis demo-facturation
09:14 poste de lea déclaré éteint depuis 08:45

Le bloc 192.0.2.0/24 est réservé à la documentation. Crée un tableau local avec les colonnes heure, fait, hypothèse, donnée manquante, action proposée, autorité, critère de sortie. Classe provisoirement l’incident, propose un confinement ciblé et deux vérifications. Prépare ensuite une séquence d’éradication, de restauration et de retour d’expérience. Ne lance aucune commande et ne contacte aucun service.

Critère observable

Ton tableau doit conserver les cinq faits sans inventer d’événement, qualifier le vol de compte comme hypothèse, proposer la révocation des sessions et le retrait temporaire du groupe, demander les journaux du fournisseur d’identité et de l’application, puis définir un critère de réactivation. Il doit aussi mentionner que les douze fiches sont fictives et que la chronologie seule ne démontre ni l’identité de l’acteur ni une exfiltration externe.

• Confondre alerte et incident confirmé. Qualifie le signal et conserve le degré de confiance.
• Appliquer un playbook sans contexte. Vérifie impact, dépendances et réversibilité.
• Couper trop vite ou trop tard. Documente le risque des deux options et l’autorité de décision.
• Détruire les traces. Préserve les données pertinentes avant une modification irréversible lorsque la situation le permet.
• Déclarer l’éradication après une seule correction. Recherche sessions, secrets, hôtes similaires et mécanismes de retour.
• Restaurer une sauvegarde non vérifiée. Elle peut être corrompue ou contenir la cause.
• Communiquer une certitude excessive. Sépare faits, hypothèses et limites.
• Clore sans suivi. Attribue et teste les actions du retour d’expérience.

Un cycle générique ne remplace pas les règles internes, les contraintes de sûreté ou un conseil juridique adapté. La méthode améliore la coordination sans garantir l’absence de dommage ni l’identification complète de la cause.