Gestion de la réponse aux incidents

Une connexion, une mise à jour logicielle et une requête Web sont des événements : des faits observables concernant des actifs informatiques. La plupart des événements sont normaux. Un événement indésirable a une conséquence négative, comme une panne de disque, une coupure de courant ou une infection par un logiciel malveillant.

Décider quand une réponse de sécurité est nécessaire

Un incident de cybersécurité compromet effectivement ou de manière imminente, sans autorisation légale, la confidentialité, l’intégrité ou la disponibilité d’informations ou de systèmes. Il comprend aussi les violations effectives ou imminentes de lois, de politiques ou procédures de sécurité ou de politiques d’utilisation acceptable. L’organisation rédige des critères d’incident afin que les analystes puissent appliquer cette définition de manière cohérente.

L’utilisation d’un mot de passe volé par un attaquant est un incident avant même qu’un vol de données soit confirmé. Une coupure de courant ordinaire est un événement indésirable, mais ne remplit généralement pas les critères d’un incident de sécurité. Une violation de données est un type d’incident impliquant un accès à des données ou leur divulgation sans autorisation. Une attaque par déni de service peut être un incident sans violation de données.

Une alerte est un signal qui appelle une investigation. Lorsque les preuves remplissent les critères écrits, un analyste déclare un incident : il ouvre le dossier d’incident, désigne un responsable et active les règles de gravité, de réponse et de communication du plan. Traiter chaque alerte comme un incident crée du bruit ; attendre la preuve d’un vol laisse passer des incidents qui menacent déjà les systèmes.

Relier les phases

Le cycle classique regroupe le travail en quatre phases :

1. Préparation : établir les pouvoirs, les contacts, les accès, les outils, la journalisation, les sauvegardes et les procédures mises en pratique.
2. Détection et analyse : valider les signaux, établir ce qui s’est passé, trouver les actifs affectés et évaluer l’impact.
3. Endiguement, éradication et rétablissement : arrêter les dommages, supprimer les accès de l’attaquant et leurs causes, puis rétablir des services fiables.
4. Activité après incident : examiner la réponse et suivre les améliorations.

Les référentiels de certification peuvent diviser le travail intermédiaire en étapes distinctes, pour un total de sept étapes. Ils décrivent le même travail plus en détail. Les phases se chevauchent. Un analyste peut découvrir un second compte compromis pendant l’endiguement et revenir à la détermination du périmètre. Un nettoyage échoué peut conduire à isoler de nouveau un système.

Lire le modèle actuel du NIST

La publication NIST SP 800-61 Revision 3, parue en avril 2025, inscrit la réponse aux incidents dans les six fonctions du cadre de cybersécurité (CSF) 2.0. Gouverner, Identifier et Protéger soutiennent la préparation par une gestion des risques plus large. Détecter, Répondre et Rétablir organisent la réponse aux incidents elle-même. La catégorie Amélioration de la fonction Identifier recueille les enseignements de toute activité, y compris d’un incident en cours.

Par exemple, pendant l’endiguement, une équipe découvre que sa liste de contacts cloud est périmée. Elle la met immédiatement à jour et consigne le changement pour la revue. Elle n’a pas besoin d’attendre le rétablissement de tous les services pour améliorer sa préparation. La résolution des incidents peut prendre des semaines ou des mois ; ne partager les enseignements qu’à la fin laisserait donc une lacune connue pendant toute cette période.

Une réponse nécessite à la fois des pouvoirs et un moyen pratique de les exercer. Trois niveaux de documentation relient les décisions de la direction aux actions dans une console.

Donner un rôle clair à chaque document

La politique définit l’engagement de la direction, le périmètre, les définitions et les pouvoirs, notamment qui peut déconnecter un système. Le plan explique comment l’organisation répond : rôles, catégories d’incidents, niveaux de gravité, voies d’escalade, communication, ressources et documentation. Les procédures et scénarios de réponse expliquent les étapes et les décisions propres à certaines situations.

Un plan utilisable comprend des listes de contacts, des suppléants, des exigences relatives aux preuves, des liens vers les scénarios de réponse et un calendrier de révision. Il attribue des rôles qui restent valables malgré les changements de personnel. Si un seul dirigeant nommé peut approuver l’isolement et que cette personne est injoignable, le plan présente un point unique de défaillance. Autorise à l’avance l’endiguement dans des situations définies et désigne des suppléants pour les décisions.

Associer les décisions aux rôles

Le responsable d’incident coordonne le travail, attribue les tâches, suit la situation et prend les décisions dans la limite des pouvoirs prévus par le plan. Les intervenants en réponse aux incidents valident les résultats, préservent les preuves et réalisent les actions de réponse. Les équipes systèmes, réseau, cloud et développement apportent des modifications à leurs services.

La direction fournit les ressources et approuve les actions à fort impact. Les responsables des actifs expliquent l’impact sur l’activité et les priorités de rétablissement. Le service juridique conseille sur la préservation, les contrats et les notifications ; les relations publiques gèrent les déclarations publiques. Les ressources humaines interviennent dans les affaires concernant des salariés, et la sécurité physique facilite l’accès aux locaux.

Un CSIRT interne est une équipe de réponse aux incidents de sécurité informatique. Un modèle externalisé peut faire appel à un prestataire de services de sécurité gérés (MSSP) ou à une société de réponse sous contrat. Un modèle hybride combine des intervenants internes et des spécialistes externes. Pour les services cloud, consigne les couches gérées par le fournisseur et celles qui restent sous la responsabilité du client, ainsi que les moyens d’obtenir les preuves détenues par le fournisseur.

Planifier la communication avant l’incident

Le plan de communication précise qui reçoit un point de situation, qui l’envoie, quand, par quel canal et avec quel niveau de détail. Les destinataires internes comprennent les intervenants, la direction, les responsables des actifs, le centre d’assistance et le personnel concerné. Les destinataires externes peuvent comprendre les clients, les partenaires, les autorités de réglementation, les forces de l’ordre, les assureurs et les médias. La direction et le service juridique décident des notifications externes ; les analystes suivent le circuit prévu.

Utilise une communication hors bande si la messagerie électronique, la messagerie instantanée ou les systèmes d’identité sont peut-être compromis. Une conférence téléphonique distincte ou un service de messagerie indépendant empêche un attaquant présent dans l’environnement principal de suivre la réponse. Partage les détails de l’incident selon le besoin d’en connaître.

À 2 h 10, un analyste confirme un chiffrement sur un serveur de paie. Le plan classe l’incident au niveau de gravité 1. L’analyste appelle le responsable d’incident, qui ouvre une conférence téléphonique distincte et informe le RSSI. Le service juridique évalue les conséquences pour les données personnelles. Les relations publiques préparent une déclaration d’attente à soumettre pour approbation. Le dossier d’incident consigne chaque action et son heure.

Rendre la préparation concrète

Conserve des plans hors ligne, des contacts à jour des fournisseurs et du personnel, un inventaire des actifs, des schémas réseau, des journaux centralisés et synchronisés, des références de fonctionnement et des accès préautorisés pour les intervenants. Un kit d’intervention contient un ordinateur portable sain, des outils d’investigation numérique, des bloqueurs d’écriture, du stockage, des câbles, des sachets pour preuves et des formulaires de traçabilité. Révise le plan au moins une fois par an et après les incidents majeurs ou les changements importants ; vérifie que les contacts et les accès fonctionnent effectivement.

Un scénario de réponse indique les étapes et les décisions propres à un type d’incident, comme l’hameçonnage, un rançongiciel, la compromission d’un compte ou une exfiltration de données. Une procédure d’exploitation désigne souvent une procédure technique plus restreinte, comme l’isolement d’un hôte dans la console de détection et réponse sur les terminaux (EDR). Les équipes utilisent parfois ces termes différemment : définis-les donc dans le plan.

Rédiger des décisions que les intervenants peuvent suivre

Un scénario de réponse utile indique son déclencheur, les premières questions de triage, les preuves à recueillir, les rôles responsables, les actions d’endiguement et de rétablissement, les critères d’escalade, les étapes de communication et les conditions de clôture. Une simple liste de vérification ne peut pas déterminer si un compte d’administrateur compromis nécessite une réponse différente de celle prévue pour un compte ordinaire.

Prenons le signalement : « J’ai saisi mon mot de passe sur une page d’hameçonnage. » Un scénario de réponse peut guider l’intervenant dans les actions suivantes :

1. Confirmer le signalement et retrouver le message.
2. Utiliser les journaux de messagerie et du proxy pour identifier les destinataires, les clics et les utilisateurs qui ont saisi leurs identifiants.
3. Réinitialiser les mots de passe exposés, révoquer les sessions et les jetons, et supprimer les dispositifs d’authentification multifacteur ajoutés par l’attaquant.
4. Rechercher les accès de l’attaquant dans les journaux de connexion et vérifier les règles de boîte aux lettres qui transfèrent ou masquent les messages.
5. Bloquer l’expéditeur et l’URL, supprimer le message des boîtes aux lettres et informer les utilisateurs concernés.

Associe des décisions aux étapes. Par exemple, procède à l’escalade si le compte est privilégié ou si des connexions de l’attaquant apparaissent. Précise qui approuve les changements perturbateurs. L’automatisation peut effectuer les étapes courantes, mais une action comme l’arrêt d’un serveur critique conserve son étape d’approbation humaine.

Former aux différentes responsabilités

Les intervenants s’exercent avec le SIEM, l’EDR, les outils d’investigation numérique et les procédures relatives aux preuves. Les dirigeants s’entraînent à prendre rapidement des décisions sur l’interruption des services et les ressources. Tout le personnel apprend à signaler rapidement une activité suspecte et à préserver la situation pour l’investigation. Effacer un ordinateur portable après y avoir trouvé une demande de rançon peut détruire des preuves et retarder la détermination du périmètre.

Un exercice sur table met les décisions à l’épreuve par la discussion. Un animateur présente un scénario, puis ajoute de nouvelles informations par étapes, appelées stimuli d’exercice. Les participants utilisent le plan pour expliquer leurs prochaines actions. Cela révèle les pouvoirs mal définis, les contacts manquants et les hypothèses contradictoires sans modifier les systèmes de production.

Une simulation, ou exercice fonctionnel, amène les participants à réaliser des actions avec des outils dans un environnement de test, sous la pression du temps. Elle peut révéler l’échec d’une commande d’isolement ou une exportation de preuves plus longue que prévu. Un exercice grandeur nature associe plusieurs équipes, et souvent des partenaires externes, à la réponse.

Transformer les résultats des exercices en améliorations

Lors d’un exercice sur table consacré à un rançongiciel, cinq appels au centre d’assistance signalent à 7 h 30 le chiffrement de lecteurs partagés. À 8 h 15, un stimulus révèle la divulgation de fichiers des ressources humaines. À 10 h, un journaliste appelle. L’équipe doit décider qui déclare l’incident, qui approuve la mise hors ligne des serveurs, qui s’exprime publiquement et quelles sauvegardes peuvent être restaurées en premier.

Si personne ne connaît la durée de restauration, consigne une action telle que : « Responsable du stockage : tester une restauration complète du serveur de fichiers d’ici la fin du trimestre et noter la durée mesurée. » Mets à jour le scénario de réponse et teste-le à nouveau. Un exercice est utile lorsqu’il révèle des lacunes que l’organisation peut combler ; le considérer comme une épreuve à réussir encourage à cacher les faiblesses mêmes qu’il devrait révéler.

Les signaux de sécurité proviennent des alertes SIEM et EDR, des antivirus, des outils de détection réseau, des journaux du cloud et des identités, des outils de prévention des pertes de données et des signalements de personnes internes ou externes à l’organisation. Un signe précurseur indique un possible incident futur, comme un scan ou un nouveau code d’exploitation visant un logiciel utilisé. Un indicateur signale une activité qui a peut-être déjà eu lieu ou qui est peut-être en cours.

Reconstituer le contexte du signal

La collecte des journaux rend accessibles les enregistrements des terminaux, serveurs, équipements réseau, systèmes d’identité et services cloud. Des horloges synchronisées, généralement à l’aide du protocole NTP, facilitent leur comparaison. La corrélation relie les enregistrements par des attributs comme l’hôte, le compte, l’adresse et l’heure. L’enrichissement ajoute la criticité et le responsable de l’actif, le rôle de l’utilisateur, la localisation et la réputation liée aux menaces.

Un transfert sortant volumineux depuis un serveur de sauvegarde pendant sa tâche planifiée n’a pas le même sens que le même transfert effectué par un processus inconnu sur un ordinateur portable de l’accueil. La réputation peut aider à examiner un domaine, mais elle ne constitue qu’une partie du contexte.

Effectuer le triage

1. Lire l’alerte et comprendre ce que la règle a détecté.
2. Identifier l’hôte, l’utilisateur, le processus et l’heure.
3. Vérifier l’importance de l’actif, les privilèges, le comportement normal et les tickets de changement pertinents.
4. Examiner les ouvertures de session, les processus parents, les connexions et les fichiers associés.
5. Vérifier la réputation des domaines, des adresses et des empreintes de fichiers.
6. Décider si l’activité est bénigne, si l’alerte est un faux positif ou si un incident est suspecté. Procéder à l’escalade si des doutes persistent.

Une alerte qui identifie correctement une activité malveillante est un vrai positif. Un faux positif se déclenche pour une activité bénigne. Un faux négatif est une activité malveillante qui n’a produit aucune alerte ; elle ne figure pas dans la file d’attente. Un vrai négatif est une activité bénigne sans alerte.

Suivre les preuves jusqu’à la déclaration

À 7 h 55 UTC, une alerte EDR signale une commande PowerShell encodée sur FIN-LT-042. Son processus parent, WINWORD.EXE, a ouvert « Invoice_0310.docm » depuis un courriel. PowerShell a ensuite contacté un domaine enregistré trois jours auparavant. Ces éléments justifient de traiter le cas comme un incident suspecté et de l’examiner rapidement.

L’analyste décode la commande et découvre qu’elle télécharge et exécute un script en mémoire. Les enregistrements du proxy corroborent le téléchargement et le contenu du script établit le caractère malveillant de l’exécution. L’alerte est désormais un vrai positif confirmé. Le critère de l’organisation, « exécution confirmée de code malveillant sur un terminal de l’entreprise », justifie la déclaration de l’incident.

Un domaine récent ou une commande encodée peuvent aussi, pris isolément, apparaître dans une activité légitime. La décision repose sur l’ensemble des éléments et sur le critère écrit. De même, le démenti d’un utilisateur ne suffit pas à clôturer le dossier sans vérifier les données.

Tenir le dossier de réponse dès le début

Consigne le numéro de ticket, l’auteur du signalement, l’heure de détection en UTC, les observations, les sources de preuve et chaque action avec son auteur et son heure. Documente les faux positifs et utilise les résultats utiles pour le réglage. Si l’antivirus indique « Menace supprimée », examine l’arrivée et l’exécution avant de clôturer : la suppression d’un fichier ne dit pas si un autre code s’est exécuté, si des identifiants ont été exposés ou si un mécanisme de persistance subsiste.

La détermination du périmètre établit les hôtes, comptes, applications, données et sites affectés, ainsi que le point d’entrée et le maintien éventuel de l’activité de l’attaquant. Le premier hôte ayant déclenché une alerte est le point de départ de cette recherche. De nouvelles découvertes peuvent élargir le périmètre pendant l’endiguement et l’éradication.

Suivre chaque indicateur utile

Un pivot d’investigation consiste à rechercher dans d’autres preuves un attribut découvert dans l’affaire : une empreinte, un nom de fichier, un domaine, une adresse, un compte, une clé de registre ou un nom de tâche. Un domaine malveillant présent sur un ordinateur portable peut apparaître dans les enregistrements du proxy pour deux autres ordinateurs. Une ouverture de session depuis l’un de ces appareils vers un serveur de fichiers ajoute un autre hôte et un autre compte à examiner.

Pour chaque piste, demande-toi comment l’accès a commencé, ce qui s’est exécuté, quels mécanismes de persistance ont été installés, quels comptes ont été utilisés, où l’attaquant s’est déplacé, quelles données ont été consultées ou exportées et quand l’activité est apparue pour la première et la dernière fois. Consigne les systèmes comme affectés, suspects ou vérifiés sans résultat correspondant ; explique les preuves et la fenêtre de recherche qui justifient chaque statut.

Normaliser les heures avant le tri

Une chronologie réunit l’heure, la source, l’hôte, l’utilisateur et une description de l’événement. Conserve les horodatages et les décalages d’origine, convertis-les en UTC et consigne les erreurs d’horloge connues. Des horodatages locaux bruts provenant de fuseaux différents peuvent inverser l’ordre apparent d’une attaque.

Examine ces enregistrements issus d’une même investigation :

Soustrais un décalage positif pour obtenir l’heure UTC. Après conversion, la remise précède l’ouverture de session, l’exécution et la connexion. Conserve aussi la date, car la conversion peut faire passer d’un jour à l’autre. Un décalage enregistré avec l’événement permet de traiter les changements d’heure plus sûrement qu’un simple nom de ville.

Utiliser les volumes et les écarts de temps avec prudence

Les enregistrements de flux montrent l’envoi de 2,4 Go vers l’extérieur en 40 minutes. Les unités SI décimales donnent 2 400 Mo, et la durée est de 2 400 secondes :

Le débit moyen est de 1 Mo/s. Sur un poste de travail qui n’envoie habituellement que quelques mégaoctets par jour, c’est une raison sérieuse de rechercher une exfiltration. Le volume ne permet pas d’identifier les fichiers ; combine-le aux preuves relatives aux accès aux fichiers, aux processus et à la destination.

La durée de présence non détectée va de la compromission initiale à sa détection. Du 2 février à 14 h UTC au 19 février à 9 h 30 UTC, elle est de 16 jours et 19,5 heures. Une durée plus longue donne davantage de possibilités à l’attaquant et peut placer les premières activités au-delà de la durée de conservation des journaux.

Laisser apparaître les incertitudes dans la chronologie

Distingue les faits confirmés des hypothèses et indique chaque source de preuve. Écris « Les enregistrements antérieurs au 1er mars ne sont pas disponibles car la durée de conservation est de 30 jours » lorsque c’est la lacune constatée. Écrire « L’attaquant est arrivé le 1er mars » transformerait le début des preuves disponibles en une date de début non étayée. Réexamine l’endiguement lorsque de nouveaux pivots révèlent un autre chemin d’accès.

La gravité décrit l’impact d’un incident. La priorité détermine l’ordre de traitement à partir de l’impact et de l’urgence. Un transfert sortant de fichiers confidentiels en cours peut nécessiter un endiguement immédiat, même si un autre cas grave est déjà stabilisé. Le plan de l’organisation fournit l’échelle, les critères et les délais de réponse attendus.

Évaluer l’impact sur l’activité

Examine l’impact fonctionnel : quels services métier sont indisponibles ou dégradés ? Examine l’impact sur les informations : des informations privées ou exclusives ont-elles été exposées, ou l’intégrité des données a-t-elle été atteinte ? Évalue ensuite la capacité de rétablissement : les ressources existantes permettent-elles de rétablir le service de manière prévisible, faut-il des ressources supplémentaires, le rétablissement est-il incertain ou la perte est-elle irréversible ?

Examine aussi l’importance de l’actif, les utilisateurs et systèmes affectés, la sensibilité des données et le maintien éventuel de l’accès de l’attaquant. Un seul contrôleur de domaine compromis peut mettre de nombreux systèmes en danger. Compter les hôtes ayant déclenché une alerte sans considérer leur rôle peut fortement sous-estimer la gravité.

Appliquer l’échelle du plan

Voici un exemple d’échelle à quatre niveaux :

• Gravité 1, critique : un service essentiel à l’activité est indisponible, le vol de données confidentielles ou réglementées est confirmé, ou un attaquant détient des droits d’administrateur de domaine.
• Gravité 2, élevée : des serveurs ou des comptes privilégiés sont compromis, ou un logiciel malveillant se propage.
• Gravité 3, moyenne : un compte standard ou un poste de travail est compromis et isolé.
• Gravité 4, faible : une tentative a été bloquée ou une violation d’une politique est sans impact.

Selon un tel plan, la gravité 1 pourrait exiger une réponse sous 15 minutes à toute heure. Ces niveaux et délais appartiennent à cet exemple ; lors d’une réponse réelle, applique les critères de l’organisation concernée.

Choisir le prochain cas selon le risque et l’urgence

Trois cas arrivent : un logiciel publicitaire sur l’ordinateur portable d’un utilisateur standard ; un ajout inattendu au groupe Admins du domaine à 3 h 12, enregistré par l’événement de sécurité 4728 ; et un site Web défiguré sans preuve actuelle d’accès aux données. Examine d’abord la modification du groupe privilégié, car le contrôle de ce groupe par un attaquant menace tout le domaine. La perte d’intégrité du site Web et son impact public viennent ensuite ; le cas limité du logiciel publicitaire suit.

L’enregistrement de l’ajout au groupe doit encore être validé. Détermine s’il était autorisé, identifie le compte ajouté et vérifie son activité. Un signal à haut risque mérite une analyse rapide avant même que toutes ses implications soient confirmées. La classification par type, comme la compromission de compte, un rançongiciel ou une attaque d’application Web, permet de choisir le scénario de réponse et l’équipe spécialisée.

Procéder à l’escalade et à la remontée hiérarchique à bon escient

Le NIST distingue l’escalade, qui augmente les ressources ou les délais de réponse, de la remontée hiérarchique, qui associe un niveau supérieur de direction aux décisions de réponse. Un spécialiste de l’investigation numérique ou une société sous contrat ajoute de la capacité de réponse ; un RSSI qui décide d’arrêter ou non un service critique apporte un pouvoir de direction. Les deux peuvent intervenir dans le même cas.

Suis les déclencheurs du plan : les incidents critiques sont signalés au RSSI, la présence de données personnelles mobilise le service juridique et le responsable de la protection des données, et un usage abusif suspecté par un salarié mobilise les ressources humaines. Mets à jour la gravité lorsque les preuves évoluent, en indiquant l’heure et la raison. Un cas d’abord traité comme un logiciel publicitaire peut révéler un voleur d’identifiants et un accès plus étendu ; son classement doit évoluer avec ces découvertes.

Les preuves comprennent la mémoire, les données sur disque, les journaux, les captures de paquets, les messages, les captures d’écran, les enregistrements d’audit du cloud et les notes des intervenants. La collecte commence par les questions de l’affaire et le risque de perdre les données nécessaires pour y répondre.

Procéder par ordre de volatilité

La volatilité décrit la facilité avec laquelle les données changent ou disparaissent. La RFC 3227 donne cet exemple d’ordre, du plus volatil au moins volatil :

1. Registres du processeur et mémoire cache.
2. Tables de routage et ARP, tables des processus, statistiques du noyau et mémoire.
3. Systèmes de fichiers temporaires.
4. Contenu des disques.
5. Données de journalisation et de surveillance à distance.
6. Configuration physique et topologie réseau.
7. Supports d’archivage, y compris les sauvegardes.

Utilise cet ordre pour planifier la collecte, tout en vérifiant les durées de conservation et les conditions réelles. Un journal cloud sur le point d’expirer doit être préservé rapidement. Plusieurs intervenants peuvent préserver différentes sources en parallèle pendant que le responsable des preuves suit le travail.

Préserver les données à chaud avant de redémarrer

L’investigation à chaud recueille la mémoire, les processus, les connexions, les utilisateurs connectés, les fichiers ouverts et d’autres données changeantes d’un système en fonctionnement. Le redémarrage supprime les logiciels malveillants présents uniquement en mémoire, les connexions actives et d’éventuelles clés de chiffrement. L’isolement réseau peut arrêter les communications tout en gardant ces preuves disponibles.

Utilise des outils fiables depuis des supports externes en lecture seule ou une plateforme EDR. Les utilitaires propres à l’hôte suspect ont pu être modifiés par un attaquant. Le chargement d’un outil de collecte modifie malgré tout un système en fonctionnement : consigne ses commandes, leur heure, leur résultat et les effets inévitables afin qu’un autre analyste puisse comprendre l’acquisition.

Choisir la méthode d’acquisition adaptée

Une image disque à des fins d’investigation numérique est une copie bit à bit, comprenant l’espace non alloué et les données supprimées récupérables. Les formats courants comprennent les images brutes dd et Expert Witness (E01). Une copie logique recueille les fichiers visibles sélectionnés et laisse de côté les autres zones de stockage.

Pour un disque hors ligne, utilise un bloqueur d’écriture afin d’empêcher les écritures sur la source pendant la création de l’image. Les systèmes en fonctionnement et les volumes cloud nécessitent des outils à chaud ou des instantanés du fournisseur ; un bloqueur d’écriture hors ligne ne convient pas à ces acquisitions. Documente la méthode de collecte et les modifications qu’elle peut provoquer.

Exporte les journaux d’audit du cloud et des identités avant leur suppression à l’issue de la durée de conservation. Capture des instantanés de disques virtuels et obtiens les exportations administrateur des applications lorsque cela convient. Le contrat du fournisseur peut déterminer comment demander les preuves provenant des couches qu’il gère. Un instantané disque préserve l’état d’un disque ; recueille séparément la mémoire lorsque cette preuve volatile est nécessaire.

Effectuer une collecte sur un serveur en fonctionnement

Une alerte EDR montre une extraction d’identifiants sur un serveur de fichiers en production. L’intervenant l’isole d’abord par l’endiguement de l’EDR, en conservant le canal d’administration de sécurité. Il capture ensuite la mémoire sur un stockage externe et calcule immédiatement l’empreinte de la capture. L’équipe consigne alors les processus, les connexions et les entrées de démarrage automatique ; elle exporte les journaux de sécurité, système et PowerShell ; puis elle capture un instantané du disque virtuel ou une image disque.

Ce n’est qu’après la préservation que l’équipe décide d’arrêter ou de reconstruire le système. Une analyse antivirus complète avant la collecte peut supprimer des échantillons et modifier les métadonnées des fichiers. Lorsque l’isolement ne permet pas d’arrêter une destruction active, l’arrêt des dommages est prioritaire ; consigne pourquoi la perte de preuves a été acceptée.

Une preuve est fiable lorsque l’équipe peut expliquer son origine, la manière dont elle a été manipulée et si son contenu a changé. La chaîne de traçabilité des preuves, les contrôles d’intégrité et le stockage protégé répondent à différentes parties de cette question.

Consigner chaque transfert

La chaîne de traçabilité des preuves est le relevé continu de leur collecte, de leur manipulation, de leur transfert et de leur stockage. Attribue à chaque élément un identifiant lié au dossier. Consigne sa description, la marque et le modèle de l’équipement si nécessaire, son numéro de série, le lieu de collecte, la personne qui l’a recueilli, l’heure et les empreintes. Chaque transfert doit indiquer l’expéditeur, le destinataire, l’heure, le motif, les signatures et le nouveau lieu de stockage.

Scelle et étiquette les éléments physiques. Stocke les preuves numériques dans un espace contrôlé qui journalise les accès. Une empreinte identique n’explique pas une période non documentée durant laquelle un disque se trouvait hors du stockage contrôlé ; il s’agit d’une lacune de traçabilité, même si les octets sont ensuite vérifiés avec succès.

Établir une référence d’intégrité

Une empreinte cryptographique transforme des données en une valeur de longueur fixe. SHA-256 est un choix courant. MD5 et SHA-1 présentent des faiblesses connues en matière de collisions, même si les outils peuvent les enregistrer en complément de SHA-256. Une valeur SHA-256 identique constitue une preuve solide qu’une copie ultérieure contient les mêmes octets que l’élément enregistré ; elle n’identifie pas la personne qui a créé ces octets.

Pour une source stable comme un disque hors tension, calcule l’empreinte de la source lors de l’acquisition et vérifie l’image par comparaison. La source doit rester stable pour que cette comparaison ait un sens. Pour la mémoire vive, effectue d’abord la capture et calcule immédiatement l’empreinte du fichier obtenu. La mémoire change pendant l’acquisition ; tenter de calculer deux fois son empreinte en fonctionnement ne fournit donc pas de référence reproductible pour la source.

Une infime modification du contenu peut produire une empreinte très différente. Le texte « Case IR-2026-0142 » a pour préfixe SHA-256 45a24047 ; modifier le dernier chiffre pour obtenir « Case IR-2026-0143 » donne 8e5320c9. Consigne l’empreinte complète pour vérifier les preuves ; ces courts préfixes illustrent le changement.

Vérifier les transferts et analyser les copies

Supposons que l’empreinte de la capture mémoire M-03 soit calculée lors de son acquisition. Avant qu’un second analyste ouvre une copie transférée, il recalcule sa valeur SHA-256 et la compare à celle enregistrée lors de l’acquisition. Une différence signifie que la copie n’a pas passé la vérification. Examine l’élément source, le transfert, le stockage et les erreurs d’acquisition avant de t’y fier ; recommence l’acquisition si possible.

Calcule l’empreinte à l’acquisition, après les transferts et avant l’analyse. Conserve l’original préservé comme référence et analyse des copies de travail vérifiées. Inscris les empreintes dans le dossier de preuve de façon à rendre clair leur lien avec l’élément et l’heure.

Préserver les données aussi longtemps que nécessaire

La préservation comprend le stockage en lecture seule ou à écriture unique, les conteneurs de preuves chiffrés, le contrôle des accès et l’exportation des journaux qui expireraient autrement. Suspends la suppression ou la rotation des enregistrements nécessaires à l’investigation.

Une obligation de conservation, généralement émise par un conseil juridique, impose de conserver les informations pertinentes pour une procédure judiciaire ou une enquête en cours ou raisonnablement prévisible. Elle prévaut sur les calendriers habituels de suppression pour les données, personnes et systèmes désignés. Le service informatique confirme l’arrêt de la suppression et maintient l’obligation jusqu’à sa levée par le service juridique. La reconstruction d’un ordinateur portable n’autorise pas l’effacement de son disque d’origine soumis à cette obligation.

L’investigation numérique transforme les données préservées en réponses sur l’entrée, l’exécution, l’utilisation des comptes, la persistance, les déplacements et la perte de données. Pars de ces questions pour donner un objectif à l’examen.

Suivre les quatre phases de l’investigation numérique

La publication NIST SP 800-86 décrit la collecte, qui identifie et acquiert les données ; l’examen, qui extrait les informations pertinentes tout en préservant leur intégrité ; l’analyse, qui interprète ces résultats ; et la rédaction du rapport, qui explique les résultats, les méthodes, les outils et les recommandations. Extraire une ligne de commande relève de l’examen. Déterminer ce qu’elle montre au sujet de l’incident relève de l’analyse.

Lire les enregistrements Windows dans leur contexte

Le journal de sécurité peut montrer les événements suivants lorsque l’audit correspondant est activé :

L’événement 7045 du journal système enregistre l’installation d’un service. La journalisation des blocs de script PowerShell utilise l’événement 4104 dans un journal PowerShell. Conserve le canal avec l’identifiant d’événement afin qu’un autre analyste puisse retrouver le bon enregistrement.

Des échecs répétés suivis d’une réussite pour le même compte suggèrent une recherche de mot de passe, mais vérifie aussi la source et l’autorisation. Un ajout à un groupe peut relever de l’administration courante ou d’une acquisition de privilèges par l’attaquant. L’enregistrement établit l’action ; les preuves environnantes permettent d’en comprendre le sens.

La persistance sous Windows peut apparaître dans les clés de registre Run et RunOnce, les tâches planifiées ou les services. Prefetch peut montrer qu’un programme s’est exécuté, quand et à quelle fréquence, sur les systèmes où il est activé. L’historique du navigateur, les téléchargements, le contenu de la corbeille et les métadonnées de la table de fichiers principale ($MFT) apportent des informations sur l’activité des fichiers et des utilisateurs.

Vérifier les preuves Linux, mémoire et réseau

Les enregistrements d’authentification Linux se trouvent couramment dans /var/log/auth.log sur Debian et Ubuntu et dans /var/log/secure sur les systèmes fondés sur Red Hat. Examine l’historique du shell tel que ~/.bash_history, les tâches cron, les unités systemd, /etc/passwd, les clés ajoutées dans ~/.ssh/authorized_keys et les journaux d’accès Web. L’historique et les journaux locaux peuvent être incomplets ou modifiés ; recherche donc des enregistrements indépendants.

L’analyse de la mémoire, par exemple avec Volatility, peut révéler des processus, du code injecté, des modules chargés, des lignes de commande et des connexions qui n’ont jamais atteint le disque. Les paquets et les enregistrements de flux fournissent les destinations, les horaires et les volumes. Le trafic chiffré laisse lui aussi des métadonnées utiles, même lorsque son contenu est indisponible.

Construire et mettre à l’épreuve une explication

À 2 h 09 UTC, l’événement 4624 de type 10 enregistre une connexion de svc_backup depuis un hôte interne. Prefetch montre que RCLONE.EXE s’est exécuté pour la première fois à 2 h 14. Les flux du pare-feu montrent l’envoi de 2,4 Go vers l’extérieur entre 2 h 15 et 2 h 55. Cette séquence étaye l’hypothèse d’un accès RDP suivi d’un transfert sortant avec rclone.

Pour établir le lien, recherche une télémétrie réseau associée au processus, la ligne de commande, la configuration ou les journaux de rclone, ainsi que des preuves que cette utilisation du compte n’était pas autorisée. Un administrateur légitime peut utiliser le même logiciel. Présente les faits observés séparément de l’interprétation et précise les lacunes qui subsistent.

L’anti-forensique cherche à masquer l’activité en effaçant des journaux, en supprimant des éléments ou en modifiant les horodatages, pratique appelée falsification des horodatages. L’événement 1102 peut révéler l’effacement du journal de sécurité. Des heures de création NTFS dans $STANDARD_INFORMATION antérieures à celles de $FILE_NAME peuvent indiquer une falsification des horodatages. Examine ces indices avec d’autres artefacts ; les enregistrements locaux manquants soulèvent une question à vérifier à l’aide des journaux distants et d’autres preuves.

L’endiguement limite les dommages, la propagation et la perte de données tout en donnant du temps pour l’investigation. Choisis-le rapidement à partir du plan, du périmètre connu et des conséquences du maintien de l’activité de l’attaquant.

Comparer les compromis

Prends en compte les dommages potentiels et le vol de ressources, la préservation des preuves, la disponibilité des services, le temps et les ressources nécessaires, l’efficacité et la durée. Une mesure efficace pendant quelques heures peut ne pas convenir pendant plusieurs semaines. Consigne l’effet attendu et le coût pour l’activité afin de pouvoir réévaluer la décision lorsque le périmètre évolue.

L’endiguement à court terme agit immédiatement : isoler un hôte, déconnecter un chemin réseau, bloquer un domaine ou une adresse de l’attaquant, désactiver un compte compromis, révoquer les sessions et les jetons ou arrêter un service. L’endiguement à long terme permet de maintenir les activités essentielles sous certaines restrictions pendant la préparation de l’éradication. Il peut utiliser un segment réseau restreint, des autorisations réduites, des règles de pare-feu temporaires, des correctifs d’urgence et une surveillance renforcée.

Distinguer les niveaux de restriction

La segmentation limite les systèmes qui peuvent communiquer entre eux. L’isolement coupe un hôte de tout, sauf éventuellement de son canal d’administration de sécurité. La mise hors service retire entièrement un système du service, par exemple en le mettant hors tension. Un arrêt efface la mémoire volatile ; un isolement réseau réussi peut préserver cette preuve tout en bloquant les communications de l’attaquant.

Une console EDR peut signaler une demande d’isolement avant sa réussite. Vérifie l’état obtenu et le trafic. Vérifie aussi que le canal d’administration autorisé n’atteint que l’infrastructure de sécurité nécessaire à la réponse.

Coordonner les chemins d’accès connus

Si un attaquant dispose de plusieurs points d’appui, le blocage d’un seul hôte peut l’alerter tout en lui laissant d’autres accès. Il peut changer de compte, détruire des données ou lancer le chiffrement. L’endiguement coordonné neutralise ensemble les chemins connus après une détermination suffisante du périmètre. Un chiffrement ou une exfiltration en cours exige une action immédiate pour arrêter les dommages ; attendre de tout savoir peut aggraver les pertes.

Dans un cas d’hameçonnage, FIN-LT-042 et FIN-LT-057 ont contacté le domaine de l’attaquant, et un compte d’administrateur du service financier a accédé à un serveur de fichiers. À 10 h 30 UTC, les intervenants isolent les deux ordinateurs portables, bloquent le domaine au niveau du DNS et du proxy, désactivent le compte d’administrateur et révoquent ses sessions. Ils restreignent ensuite l’accès au serveur de fichiers, ajoutent de la journalisation et poursuivent la recherche d’indicateurs dans tout l’environnement.

La coordination couvre les hôtes, l’accès réseau et l’identité. La seule désactivation d’un compte local peut laisser utilisable un jeton cloud existant. Inclus ces sessions dans le plan d’endiguement et vérifie le résultat dans les journaux d’identité.

Vérifier que l’endiguement tient

Confirme l’état d’isolement dans l’EDR, examine les journaux DNS et du proxy à la recherche de nouvelles connexions de l’attaquant et vérifie si les comptes compromis peuvent encore s’authentifier. Recherche les activités associées aux indicateurs nouvellement découverts et révise le périmètre d’endiguement si nécessaire.

Certaines organisations choisissent une observation contrôlée pour en apprendre davantage sur un intrus avant l’endiguement. Comme elle laisse la possibilité de causer d’autres dommages, cette option nécessite l’approbation de la direction et du service juridique. Supprimer le fichier malveillant détecté ne suffit pas non plus comme stratégie d’endiguement : d’autres accès, mécanismes de persistance et identités exposées peuvent rester actifs après la disparition du fichier.

L’éradication élimine l’attaquant et ce qu’il a laissé : logiciels malveillants, portes dérobées, web shells, tâches, services, entrées de registre, comptes, clés SSH et autres mécanismes de persistance. La remédiation corrige les faiblesses qui ont rendu l’intrusion possible. Les deux nécessitent de vérifier tout le périmètre de l’incident.

Décider si le nettoyage permet de rétablir la confiance

La reconstruction à partir d’une image ou d’un modèle d’infrastructure sous forme de code dont la fiabilité est connue est plus sûre lorsqu’un attaquant disposait de droits d’administrateur, utilisait un rootkit ou a laissé des mécanismes de persistance inconnus. Un nettoyage ciblé peut convenir à un logiciel malveillant courant bien compris sur un système de faible valeur, à condition que la vérification couvre les modifications connues.

Une sauvegarde réalisée après la compromission peut restaurer l’accès de l’attaquant avec les fichiers légitimes. Vérifie le début de la compromission, le contenu de la sauvegarde et la fiabilité de l’image ou du modèle avant de l’utiliser. Préserve les preuves nécessaires avant de reconstruire un système affecté.

Supprimer les accès liés aux identités ainsi que les fichiers

Endigue rapidement les comptes et les sessions compromis. Coordonne le remplacement durable des identifiants après avoir fermé les chemins d’accès de l’attaquant et établi un environnement sain dans lequel utiliser les nouveaux secrets. Sinon, un intrus peut voler les nouveaux identifiants depuis le même hôte compromis.

Réinitialise les identifiants exposés des utilisateurs et des comptes de service, révoque les jetons, les sessions et les clés d’API, et effectue la rotation des secrets applicatifs. Supprime les méthodes d’authentification multifacteur ajoutées par l’attaquant, les règles de transfert et les comptes non autorisés. Prends en compte tous les identifiants exposés sur les systèmes compromis, y compris les comptes qui n’ont pas encore déclenché leur propre alerte.

Lorsque des tickets Kerberos falsifiés sont suspectés, le rétablissement coordonné d’Active Directory comprend deux réinitialisations du mot de passe KRBTGT, avec une réplication entre les deux. Les contrôleurs de domaine peuvent accepter les tickets protégés par le mot de passe actuel ou précédent ; une seule réinitialisation laisse donc la clé précédente utilisable. Il s’agit d’une action coordonnée à l’échelle du domaine, assortie de vérifications, et non d’une étape isolée de nettoyage d’un poste de travail.

Corriger la cause et vérifier la correction

Corrige les logiciels exploités et les erreurs de configuration, impose l’authentification multifacteur là où elle manquait, supprime les privilèges excessifs et ferme les services exposés. Si une correction complète n’est pas disponible, applique une mesure compensatoire, comme une règle de pare-feu applicatif Web ou un accès réservé au VPN, et consigne le risque restant.

Un serveur public contient un web shell introduit par une faille de téléversement non corrigée. L’équipe recherche d’autres serveurs vulnérables et en trouve deux. Elle reconstruit les trois à partir d’un modèle durci, déploie l’application corrigée, effectue la rotation du secret de base de données stocké dans la configuration de l’application et recherche les requêtes visant le web shell dans les journaux des serveurs.

Un scan de vulnérabilités confirme que la faille est corrigée. L’équipe vérifie les emplacements de persistance, effectue des scans avec des signatures à jour, recherche tous les indicateurs connus et surveille les ouvertures de session et les connexions de l’attaquant. Dans ce cas, sept jours de surveillance ne révèlent aucune requête réussie vers le chemin du web shell. Les critères d’éradication du plan déterminent si ces preuves sont suffisantes.

Corriger la faille de téléversement fermerait un chemin d’entrée, mais laisserait intacte toute porte dérobée existante. Supprimer uniquement le web shell retirerait un artefact tout en laissant en place l’application exploitable. La vérification nécessite donc des preuves sur les accès restants de l’attaquant et sur la correction de la faiblesse.

Le rétablissement ramène les systèmes et les services à leur fonctionnement normal par la restauration, la reconstruction, la reconnexion et les tests fonctionnels. Il peut commencer pour les systèmes non affectés ou vérifiés comme sains pendant que l’éradication se poursuit ailleurs.

Choisir des sources de restauration fiables

Vérifie que les sauvegardes ne présentent pas de corruption, de chiffrement ni de signes de compromission. Choisis un point antérieur à l’entrée de l’attaquant et vérifie la version ou l’empreinte des images de reconstruction. Une sauvegarde récente peut contenir le mécanisme de persistance que l’équipe vient de supprimer. Sa date ne suffit pas à établir qu’elle est saine.

Identifie le travail que la restauration laissera de côté. Une sauvegarde du 3 mars à 23 h UTC est antérieure de 7 heures et 20 minutes à une compromission qui commence le 4 mars à 6 h 20 UTC. Cet intervalle décrit l’ancienneté de la sauvegarde au moment de la compromission. Sa restauration fait perdre toutes les modifications ultérieures jusqu’à la mise hors service du système, y compris le travail légitime effectué après 6 h 20, sauf si des modifications saines peuvent être récupérées ailleurs.

Les sources possibles comprennent des fichiers vérifiés comme sains ou les copies locales des utilisateurs. Valide-les avant de les fusionner avec les données restaurées afin de ne pas réintroduire de contenu malveillant ni écraser des données fiables.

Restaurer selon l’ordre des dépendances

Les priorités métier et les dépendances techniques se conjuguent. Une application de progiciel de gestion intégré (PGI) a besoin de sa base de données ; la base de données et l’application peuvent d’abord nécessiter les services réseau, DNS et d’identité. Un ordre courant est : réseau et identité, base de données, PGI, puis outils de production de rapports. Démarrer l’application en premier peut produire un processus en cours d’exécution sans service utile derrière lui.

Utilise les objectifs de rétablissement convenus, notamment les durées d’interruption et les pertes de données acceptables, pour définir l’ordre. Confirme que les dépendances elles-mêmes sont fiables avant d’y connecter les systèmes restaurés. Une application critique reliée à un service d’identité compromis reste exposée.

Appliquer les critères de levée de l’isolement

Avant la reconnexion, vérifie que le système est reconstruit ou nettoyé, corrigé et exempt de mécanismes de persistance connus. Effectue la rotation des identifiants exposés, confirme que les outils de sécurité fonctionnent et transmettent leurs informations, mets en place une surveillance renforcée et obtiens l’accord du responsable de l’actif. Reconnecte les systèmes par étapes afin de pouvoir endiguer un comportement inattendu avant qu’il n’affecte l’ensemble du service.

Pour le serveur de fichiers reconstruit, l’équipe restaure une sauvegarde vérifiée, recherche les indicateurs connus dans les données, restaure les autorisations et demande au responsable de tester l’ouverture et la modification de fichiers représentatifs. Les contrôles de sécurité comprennent la transmission des informations par l’EDR et les connexions attendues. Le responsable approuve la remise en service après ces tests et l’équipe commence la période de surveillance convenue.

Distinguer la remise en service de la fin du rétablissement

Compare les processus, les connexions, les performances et le comportement du service à la référence de fonctionnement normale. Dans un plan de réponse, la surveillance renforcée peut durer 30 jours, avec des alertes supplémentaires sur les indicateurs de l’incident. Fixe la durée et les critères selon le cas et le plan.

Le responsable d’incident déclare le rétablissement achevé lorsque les services sont restaurés et stables, que la période de surveillance ne montre aucune activité de l’attaquant et que la documentation de réponse est complète.

Un rançongiciel chiffre des données ou verrouille des systèmes et exige un paiement pour en rétablir l’accès. Dans une double extorsion, les attaquants volent aussi des données et menacent de les publier. L’extorsion par menace de divulgation de données peut se produire sans chiffrement : les dommages visibles aux fichiers ne constituent donc qu’une partie de l’investigation.

Reconnaître l’activité avant le chiffrement

Une séquence d’attaque courante commence par un hameçonnage, des identifiants d’accès distant volés ou une vulnérabilité exposée. Les attaquants découvrent les systèmes, volent des identifiants, se déplacent latéralement, désactivent les outils de sécurité, attaquent les sauvegardes et exfiltrent des données avant le chiffrement massif.

Les signes avant-coureurs comprennent des outils inattendus d’administration à distance, de nouveaux comptes privilégiés, des transferts sortants volumineux et la suppression de clichés instantanés. Une commande comme vssadmin delete shadows doit être examinée dans le contexte de son processus et de son utilisateur. Ces signes précurseurs peuvent permettre aux défenseurs d’intervenir avant le début d’un chiffrement généralisé.

Suivre les trois premières étapes de réponse

La liste de vérification de la CISA pour les rançongiciels classe ces actions dans cet ordre :

1. Identifier et isoler immédiatement les systèmes affectés. Donner la priorité aux systèmes critiques. Si plusieurs systèmes ou sous-réseaux sont affectés, déconnecter au niveau du commutateur si nécessaire. Protéger les systèmes critiques non affectés et les sauvegardes contre les mêmes chemins d’accès.
2. Mettre hors tension uniquement si la déconnexion du réseau est impossible. L’arrêt sacrifie les preuves volatiles, notamment d’éventuelles clés et l’activité présente uniquement en mémoire, mais peut être nécessaire pour empêcher une propagation supplémentaire lorsque l’isolement est impossible.
3. Trier les systèmes en vue de leur restauration. Utiliser la liste des actifs critiques et les dépendances techniques pour déterminer quels services doivent être rétablis en premier.

Coordonne les actions par téléphone ou par un autre canal hors bande. Les attaquants peuvent surveiller la messagerie de l’entreprise et réagir en accélérant la destruction. Vérifie que l’isolement a réussi avant de t’y fier.

Préserver les preuves et établir l’étendue de l’attaque

Capture les preuves en mémoire et sur disque d’un échantillon représentatif de systèmes affectés et prends des instantanés des volumes cloud concernés. Préserve les demandes de rançon, les extensions des fichiers chiffrés, les échantillons de logiciel malveillant, les journaux et les indicateurs. Ces éléments aident à identifier la variante, à reconstituer l’entrée et les déplacements, et à soutenir l’investigation des partenaires participant à la réponse.

Utilise la note, l’extension et les échantillons pour rechercher un outil de déchiffrement disponible auprès de services fiables comme No More Ransom ou des forces de l’ordre. Examine aussi les accès antérieurs et une éventuelle exfiltration. La récupération des fichiers chiffrés ne permet pas de savoir si les attaquants disposent encore d’un compte, d’un jeton ou d’une porte dérobée.

Un samedi à 3 h 40 UTC, deux serveurs de fichiers présentent environ 1 200 renommages par minute, soit 20 par seconde, avec l’extension « .lckd ». L’intervenant isole les serveurs et le contrôleur de domaine utilisé par le compte de l’attaquant, et l’équipe réseau désactive la liaison montante du segment affecté. Les systèmes restent sous tension. Un intervenant capture la mémoire d’un serveur et conserve la note pendant qu’un autre vérifie les sauvegardes protégées.

Mobiliser les partenaires prévus par le plan

Le responsable d’incident associe la direction, le service juridique, l’assureur et les forces de l’ordre conformément au plan. Les conditions d’assurance peuvent exiger une notification rapide ou le recours à des sociétés de réponse agréées. Le service juridique détermine les obligations de notification applicables lorsque des données sont concernées. Suis ces travaux pendant que l’endiguement technique se poursuit. Une réinstallation immédiate détruirait les preuves et pourrait remettre un serveur sur un réseau auquel l’attaquant a encore accès.

Le rétablissement après une attaque par rançongiciel doit supprimer la capacité de l’attaquant à répéter les dommages. Endigue les accès connus, éradique la persistance, établis un environnement sain, remplace les identifiants exposés et restaure les données vérifiées sur des systèmes reconstruits. Ne remets en service que les systèmes vérifiés comme sains.

Protéger et tester la source de rétablissement

Les sauvegardes hors ligne, immuables ou protégées par un autre moyen peuvent résister aux tentatives de suppression des copies en ligne. Avant utilisation, vérifie que le point choisi est antérieur à la compromission, qu’il n’est pas chiffré et qu’il ne contient aucun outil ni mécanisme de persistance connu de l’attaquant. Une sauvegarde non chiffrée datant de la période de présence non détectée de l’attaquant peut rester dangereuse.

Mesure le débit de restauration à l’avance. En unités SI décimales, 48 To correspondent à 48 000 000 Mo. À un débit mesuré de 400 Mo/s, le transfert continu prend :

Cela représente 120 000 secondes, soit environ 33,3 heures. Si les services critiques ne nécessitent que 6 To, leur transfert prend :

Cela représente environ 4,2 heures. Il s’agit de durées de transfert. Les reconstructions, la validation, les dépendances et la reconnexion prennent aussi du temps : elles doivent donc figurer dans l’estimation opérationnelle du rétablissement. Restaure les services critiques selon l’ordre des dépendances au lieu de placer tous les ensembles de données au même niveau dans la file d’attente.

Examiner l’infrastructure d’identité

Les attaques par rançongiciel menées par des personnes impliquent souvent des identifiants privilégiés volés. Établis si des comptes privilégiés, des contrôleurs de domaine ou KRBTGT ont été compromis. Lorsque la compromission du domaine est établie ou raisonnablement suspectée, coordonne le rétablissement du domaine : reconstruis ou restaure des contrôleurs fiables, réinitialise les identifiants privilégiés et de service, examine la stratégie de groupe et effectue les réinitialisations requises de KRBTGT avec une réplication entre elles.

La stratégie de groupe peut distribuer des modifications à de nombreuses machines. Laisser en place une stratégie malveillante ou une identité de confiance contrôlée par l’attaquant peut compromettre des reconstructions de serveurs pourtant saines. Le périmètre détermine l’étendue de ce travail ; le chiffrement d’un seul poste de travail ne suffit pas à établir une compromission du domaine.

Comprendre ce que le paiement peut ou non régler

La CISA et le FBI déconseillent le paiement d’une rançon. Un paiement ne garantit ni un outil de déchiffrement fonctionnel ni la suppression des données volées. Les outils de déchiffrement peuvent être lents, défectueux ou incomplets. Le paiement finance d’autres crimes et la victime peut être ciblée à nouveau. En 2021, l’Office of Foreign Assets Control (OFAC) du département du Trésor américain a averti que les paiements liés aux rançongiciels peuvent enfreindre les sanctions. La direction travaille avec le conseil juridique et généralement avec l’assureur ; l’analyste ne décide pas de payer.

Présente à la direction les options de rétablissement vérifiées, les durées de restauration mesurées, l’exposition connue des données et les questions en suspens. Consulte des sources fiables d’outils de déchiffrement avant de considérer le paiement comme la seule solution. Un outil de déchiffrement ne supprime pas les mécanismes de persistance et ne corrige pas le chemin d’accès initial.

Poursuivre la réponse concernant les données volées

Le rétablissement du service ne règle pas la divulgation. Identifie les données prises et les personnes concernées, aide le service juridique à évaluer les obligations de notification et surveille les sites de divulgation pertinents. La promesse d’un attaquant de supprimer les copies ne peut pas être vérifiée.

Ensuite, renforce les sauvegardes protégées et les tests de restauration, impose l’authentification multifacteur pour les accès distants et détecte les activités précoces comme la suppression de sauvegardes. Partage les indicateurs appropriés avec les autorités ou les groupes sectoriels selon le processus approuvé par l’organisation.

Une revue après incident, ou revue des enseignements tirés, examine ce qui s’est passé, comment la réponse a fonctionné et ce qui doit changer. Partage les enseignements utiles dès qu’ils apparaissent pendant l’incident. Organise une revue structurée après les incidents importants, tant que les preuves et les décisions sont encore fraîches.

Préparer un récit commun de l’incident

Une revue a généralement lieu entre quelques jours et deux semaines après la clôture. Réunis les intervenants, les équipes techniques, les responsables des actifs, la direction et les autres parties concernées. Fais appel à un animateur pour maintenir la discussion sur son sujet. Un incident grave mérite sa propre revue ; les cas mineurs peuvent être regroupés lors de séances régulières.

Prépare la chronologie de l’incident, le journal des actions, le périmètre, l’impact et les mesures pertinentes. Distingue ce qui était connu au moment d’une décision des informations découvertes ensuite. Sinon, l’équipe risque de juger un choix initial raisonnable à partir de faits indisponibles pour la personne qui l’a pris.

Examiner la réponse autant que l’attaque

Passe en revue ce qui s’est passé et quand, la façon dont la détection a eu lieu et les étapes qui ont bien fonctionné. Examine ensuite les délais, les instructions peu claires, les outils et autorisations manquants et les informations nécessaires plus tôt. Identifie les signes précurseurs ou les indicateurs qui pourraient révéler une autre tentative.

Une revue sans blâme porte sur les systèmes, les processus et les décisions. Consigner qu’une personne a cliqué sur un lien d’hameçonnage est nécessaire pour expliquer l’entrée. S’arrêter là aide peu à comprendre pourquoi un seul clic a permis d’accéder à un serveur de fichiers. Recherche quelles mesures de sécurité, quels privilèges et quelles dispositions de réponse ont permis à l’impact de s’étendre.

Conserver ce qui a fonctionné et corriger les défaillances

Lors d’une réponse à un hameçonnage, l’EDR a détecté l’exécution en 15 minutes. Conserve la détection et vérifie qu’elle reste efficace. L’endiguement a pris 2,5 heures parce que l’analyste d’astreinte ne disposait pas des droits d’isolement dans l’EDR. Prévois une modification précise des accès avec un responsable et un test, dans les limites des pouvoirs prévus par le plan.

L’audit des accès aux fichiers manquait sur le serveur de fichiers ; l’équipe n’a donc pas pu établir quels fichiers avaient été lus. Consigne cette lacune dans les preuves et active un audit adapté. Le scénario de réponse pour les comptes omettait la révocation des jetons cloud ; mets-le à jour et fais pratiquer l’étape révisée aux intervenants. Ces constats concernent des défaillances différentes et nécessitent des actions distinctes.

Rédiger un rapport de retour d’expérience utilisable

Le rapport contient une synthèse pour la direction, une description et une chronologie de l’incident, son périmètre et son impact, la cause racine et les facteurs contributifs, les actions de réponse avec leurs heures, ce qui a fonctionné ou échoué, les actions correctives avec leurs responsables et leurs échéances, ainsi que les indicateurs de l’incident. Appuie les résultats sur les preuves et laisse apparaître les questions non résolues.

Reporte les changements approuvés dans le plan, les scénarios de réponse, les détections, les listes de contacts, la formation et le registre des risques. Partage les indicateurs ou les enseignements avec les groupes appropriés selon le processus approuvé. Prévois un emplacement de suivi pour la liste des actions afin que les réunions ultérieures puissent vérifier leur avancement.

« Mieux communiquer » ne définit ni responsable, ni changement, ni test de réussite. Une action utile pourrait préciser une conférence téléphonique distincte pour les incidents, son responsable, une échéance et un test vérifiant que le personnel d’astreinte peut la rejoindre sans accès aux identités de l’entreprise. La réunion de revue est terminée, mais le travail d’amélioration se poursuit jusqu’à la vérification des actions.

L’analyse des causes racines cherche à comprendre pourquoi les conditions d’un incident existaient. La cause directe est la cause technique immédiate. Les facteurs contributifs ont rendu l’incident plus probable ou plus dommageable. Une défaillance sous-jacente d’un processus peut expliquer pourquoi ces facteurs sont restés en place.

Suivre les causes au-delà de la première défaillance

La méthode des 5 pourquoi demande à plusieurs reprises pourquoi une défaillance était possible. Le nom décrit une approche et n’impose pas de s’arrêter exactement à cinq questions. Dans un cas de rançongiciel :

1. Les serveurs ont été chiffrés parce que l’attaquant a obtenu des droits d’administrateur de domaine.
2. Ces identifiants ont été récupérés sur un serveur accessible.
3. L’attaquant y a accédé par un compte VPN de prestataire sans authentification multifacteur.
4. Le compte bénéficiait d’une exemption temporaire d’authentification multifacteur accordée lors d’une migration deux ans auparavant.
5. Les exemptions n’avaient ni date d’expiration ni processus de revue.

L’absence de processus de revue est une cause sous-jacente dans cette chaîne. L’absence d’authentification multifacteur et l’exposition d’identifiants privilégiés restent des facteurs techniques à corriger. Un diagramme d’Ishikawa regroupe les causes possibles sous des catégories comme les personnes, les processus, la technologie et l’environnement. L’analyse chronologique recherche quelle mesure aurait pu arrêter ou révéler chaque étape.

Rédiger des actions avec une preuve de réalisation

Une action corrective doit préciser un changement, un responsable, une échéance, un résultat mesurable et une vérification. Par exemple : « Imposer l’authentification multifacteur aux 214 comptes VPN d’ici le 30 novembre ; responsable : responsable de la gestion des identités et des accès ; vérification par un rapport montrant qu’aucun compte VPN n’est dépourvu d’authentification multifacteur. »

Suis les actions dans le système de tickets ou de gestion des risques et vérifie leur efficacité, notamment lors d’un exercice ultérieur. Les actions préventives réduisent la récurrence ; les actions de détection révèlent plus tôt la prochaine tentative. Ajouter une revue à l’expiration traite le processus d’exemption, tandis qu’une alerte sur l’utilisation des comptes exemptés ajoute une détection. Une seule action n’a pas à couvrir toutes les parties de la correction.

Définir l’indicateur avant de le calculer

Le délai moyen de détection est la moyenne des durées entre le début de l’activité malveillante et sa détection. Le délai d’endiguement va généralement de la détection à l’endiguement ; le délai de remédiation va de la détection à la correction. Les équipes suivent aussi la durée de présence non détectée, les catégories et la gravité des incidents, ainsi que les cas détectés en interne et ceux signalés de l’extérieur. Précise les points de départ et d’arrivée, car les organisations utilisent certains noms d’indicateurs différemment.

Voici quatre délais de détection, en heures : 2, 30, 6 et 82 :

La moyenne est de 30 heures. Classe les valeurs dans l’ordre 2, 6, 30 et 82 ; la médiane est la moyenne des deux valeurs du milieu :

Le cas à 82 heures augmente fortement la moyenne. Présente les deux indicateurs et examine ce cas. Si l’endiguement a pris 1,5, 4, 3 et 9,5 heures, la moyenne est de 18 divisé par 4, soit 4,5 heures.

Ne compare les tendances qu’avec des définitions cohérentes et un contexte adapté. Une équipe récompensée uniquement pour la rapidité de clôture des tickets peut fermer des dossiers avant la fin de l’analyse. Associe à la rapidité des preuves que la réponse est complète et que les actions ont été vérifiées, afin que l’indicateur soutienne l’amélioration.