Assainir ou reconstruire : la décision qui engage toute une remédiation

Au matin du troisième jour, la question arrive, et elle n’a pas de bonne réponse. On nettoie, et l’on reprend le système tel qu’il est, avec le risque que l’attaquant soit resté quelque part. Ou l’on reconstruit, et l’on accepte des semaines d’arrêt, un budget qui n’existe pas et une liste de dépendances dont personne ne connaît la longueur. Cette décision engage tout le reste de la remédiation, et elle se prend presque toujours avec une connaissance incomplète de la compromission.

→ Lire l’explication complète de la marmotte

La séquence E3R, et l’endroit exact où la question se pose

L’ANSSI a publié en décembre 2023 un corpus de trois volets sur la remédiation, dont les deux premiers sont disponibles : un volet stratégique à destination des décideurs, et un volet opérationnel sur le pilotage. Ils définissent la remédiation comme « le projet de reprise de contrôle d’un système d’information compromis et de rétablissement d’un état de fonctionnement suffisant », et la distinguent de l’investigation et de la gestion de crise, qui sont les deux autres dimensions de la réponse à incident. Le mot « suffisant » n’est pas un aveu de faiblesse : c’est la thèse du document.

La séquence proposée tient dans un acronyme, E3R : endiguement, éviction, éradication, reconstruction. L’endiguement arrête la progression de l’attaquant et « donne du temps au défenseur ». L’éviction élimine durablement l’adversaire du cœur de confiance, c’est-à-dire de l’administration informatique, et « dote d’une position d’où mener l’éradication ». L’éradication nettoie l’intégralité du système en éliminant les emprises résiduelles. La reconstruction, en parallèle, recrée ce que l’attaque a compromis ou détruit, et fournit les moyens d’atteindre les objectifs des deux étapes précédentes.

Le cœur de confiance est la notion centrale, et le document ne mâche pas ses mots sur l’enjeu : c’est « la brique centrale du système d’information, d’où l’attaquant est exclu de façon certaine et qui est indispensable pour mener les actions de remédiation. Sa reconstruction est une étape majeure. Son échec mène généralement à un cycle de compromission/remédiation qui peut s’étendre sur des mois voire des années. » C’est donc là, et nulle part ailleurs, que la question « assainir ou reconstruire » se pose en premier : pas sur l’ensemble du parc, mais sur la zone d’administration depuis laquelle tout le reste sera traité. Les raisons de la séparer du reste sont celles de la séparation du plan de contrôle et du plan de données et de l’administration en tiers.

Nettoyer : quand c’est possible, et à quelle condition

Le document ne condamne pas le nettoyage, il le conditionne, et la condition est sévère. « Il est risqué de tenter des évictions partielles à travers des mesures de nettoyage de systèmes compromis, sans création d’un environnement de confiance. Dans certains cas, rares, cette approche est la seule possible. Cependant, le nettoyage d’un environnement compromis par un adversaire compétent est très difficile, et les cas de re-compromissions ne sont pas rares. » La phrase décisive vient ensuite : « Une stratégie de simple nettoyage du cœur de confiance n’est donc recommandée que si on a une très forte assurance d’avoir identifié tous les points de persistance adverse. »

« Très forte assurance d’avoir identifié tous les points de persistance » est un critère vérifiable, et c’est ce qui le rend utile. Il ne se décrète pas en réunion : il se démontre par une investigation qui a couvert le périmètre, par des journaux antérieurs à l’intrusion, par une connaissance des modes de persistance employés, et par l’absence de zones aveugles. Si l’investigation n’a porté que sur les machines dont on avait les journaux, l’assurance n’est pas forte, elle est locale. Les modes de persistance à écarter, et la manière de les chercher, sont l’objet de la détection de la persistance d’un attaquant après incident ; la note du guide en rappelle l’étendue : implants, changements de configuration, modifications de droits, création ou altération de comptes locaux ou transverses.

Ce qui emporte la décision, dans la pratique, n’est pas le coût mais la perspective d’échec. Le document explique que « placer la barre haut dans l’éviction vise à éviter des cycles “tentative d’éviction”/“re-compromission”, qui épuisent et démoralisent les équipes avec des résultats souvent médiocres ». C’est le seul argument qui porte devant une direction, parce qu’il est quantifiable : un nettoyage raté ne coûte pas le prix du nettoyage, il coûte le prix de la remédiation suivante, plus le moral de l’équipe, plus la crédibilité de la fonction sécurité. Le volet stratégique le traduit en courbes de coût, et c’est le scénario le plus coûteux de tous.

Reconstruire depuis zéro : l’autre piège, moins connu

L’opposé a mauvaise presse auprès des financiers et bonne presse auprès des techniciens, et le guide le traite avec la même froideur. « Il est parfois tentant de recréer l’intégralité d’un système d’information, sans réimporter aucun élément du système compromis. Il est observé que si l’essentiel des fonctions centrales d’un système de taille modérée peut assez facilement être reconstitué ainsi, le retour à la normale se heurte rapidement à de nombreux obstacles difficiles à surmonter. »

L’obstacle principal a un nom, et c’est celui auquel on pense le moins : l’identité centralisée. Dans un système où les droits appliqués aux ressources réparties dans tout le parc, fichiers, boîtes aux lettres, accès aux services, dépendent d’identifiants centralisés, une reconstruction depuis zéro change ces identifiants, et il faut donc les adapter partout. Le guide cite classiquement les environnements Active Directory, dont la structure et les chemins d’attaque sont décrits dans la structuration d’Active Directory et la délégation sans escalade. La conclusion est une règle de périmètre : « il est recommandé de n’entreprendre ce type de reconstruction que dans des systèmes de taille limitée ou très maîtrisés ».

Les deux stratégies réelles : isolement ou sanctuarisation

Dans les faits, on ne tranche pas entre deux absolus mais entre deux manières de progresser, et le volet opérationnel les nomme.

Par isolement : le système est découpé en sous-réseaux isolés les uns des autres, et les services portés par chacun font l’objet d’un assainissement dédié, mené séparément ; les flux entre ces réseaux sont réouverts progressivement et très précisément. Le guide signale le prérequis, et il est redoutable : « une telle démarche requiert de connaître finement les flux réseaux applicatifs et d’être en capacité de les identifier rapidement ». Autrement dit, elle suppose une cartographie que peu d’organisations possèdent au moment où elles en ont besoin, ce qui est l’argument le plus concret en faveur de la segmentation décrite dans la limitation du mouvement latéral.

Par sanctuarisation : un nouveau réseau sain est créé, dans lequel les services assainis sont réinstallés ou réintégrés progressivement. Le guide note que cette démarche « se heurte généralement à des problématiques liées au changement d’adressage et de configuration réseau codée en dur ». Toute adresse IP écrite dans un fichier de configuration, un script ou un équipement devient un point de blocage, et personne ne tient la liste de ces adresses. C’est une facture différée de quinze ans de raccourcis d’exploitation, présentée au pire moment.

Dans les deux cas, la question se repose service par service, et c’est sa forme correcte. Le guide le dit pour la restauration d’un service vital : les serveurs qui le portent « peuvent être réinstallés ou importés, et nettoyés. Si une réinstallation offre de meilleures garanties, celle-ci peut être plus longue. » Garanties contre délai : c’est l’arbitrage entier, et il n’a pas la même réponse pour le contrôleur de domaine et pour le serveur d’impression. Notons au passage que la taille et la maîtrise du système déterminent les options disponibles avant l’incident : qui ne sait pas dire quels flux circulent entre ses zones n’a pas le choix entre nettoyer et reconstruire, mais entre nettoyer et improviser.

Les critères qui tranchent, et les trois scénarios

Six critères suffisent, et aucun n’est purement technique.

La profondeur de la compromission : l’attaquant a-t-il atteint le plan d’administration ? Si oui, la question du nettoyage ne se pose plus pour le cœur de confiance, elle se pose pour le reste. La qualité de l’investigation : dispose-t-on de journaux antérieurs à l’intrusion, de la couverture nécessaire, d’une chronologie défendable ? Sans cela, l’assurance d’avoir tout trouvé n’existe pas, et la méthode de la chaîne de conservation décide ici de la décision stratégique. Les sauvegardes : en existe-t-il d’antérieures à l’intrusion, sont-elles restaurables, et l’a-t-on vérifié avant l’incident, comme le recommande le test d’une restauration après sinistre simulé ? Une sauvegarde postérieure à l’intrusion restaure la porte dérobée avec les données, et c’est tout l’intérêt de la sauvegarde immuable.

La taille et la maîtrise du système, déjà vues, qui ouvrent ou ferment l’option de la reconstruction. La dépendance à une identité centralisée, qui transforme une reconstruction propre en chantier de reprise de droits. Et la pression métier, qui n’est pas une faiblesse de caractère mais une donnée du problème : certains services ne peuvent pas s’arrêter trois semaines.

Le volet stratégique range ces arbitrages en trois scénarios archétypaux, à adapter en conditions réelles, et les assortit d’une tendance de coût. Restaurer au plus vite des services vitaux : face à un péril immédiat, un nombre restreint de services redémarre, mais « cette approche ne traitera ni les causes racines de l’incident, ni ne protégera d’une résurgence de l’attaque à moyen terme », et le guide écrit sans ménagement que « la survie de votre organisation reste en question » ; coût initial faible, coût total très élevé. Reprendre le contrôle du système d’information : retour le plus rapide possible à l’état antérieur de la totalité du système, qui n’est pas restructuré, et « votre organisation reste à risque, tant que des changements substantiels n’auront pas été réalisés ». Saisir l’opportunité pour préparer une maîtrise durable : changements majeurs dès la remédiation, coût initial élevé, et un modèle de sécurité proactif plutôt que réactif.

Deux des sept recommandations qui accompagnent ces scénarios méritent d’être citées. « Sortez de l’immédiateté : se faire absorber par l’activité à la minute est un gouffre. Les incidents se gèrent en semaines et en mois. » Et : « Une remédiation se joue contre une intelligence hostile. Les changements adverses peuvent nécessiter des adaptations. La partie ne se termine jamais. » Pour que ces adaptations restent traçables, il faut tenir une main courante.

Ce que la décision n’est pas : viser un système étanche

Il reste à écarter l’objectif qui fait échouer la moitié des remédiations, et le guide s’en charge en une phrase qui devrait figurer dans toutes les notes de cadrage : « L’objectif de la remédiation est d’aboutir à un système sur lequel les activités adverses éventuelles sont détectées et neutralisées avant de devenir critiques. Au contraire, son but n’est pas de tendre vers un système étanche. »

La raison est arithmétique. « En pratique, il n’est jamais possible d’avoir une certitude d’éviction totale », et il est « généralement impossible, à grande échelle, d’obtenir la certitude qu’aucune porte dérobée, aucune faille ni aucun changement de configuration ne soient passés inaperçus ». Le guide en tire une recommandation d’économie des efforts qui mérite d’être assumée : « il est préférable de viser un niveau d’assurance moindre sur l’exhaustivité de l’éradication, tout en le complétant par des capacités de détection et de réaction ». Il observe en effet que des objectifs trop ambitieux sont abandonnés en cours d’exécution, par épuisement des ressources, ce qui est la pire des issues : le coût de l’ambition sans le bénéfice.

Dernier angle mort, systématique : lors de l’éradication, « il est tentant de se contenter de se focaliser sur les systèmes technologiquement maîtrisés : les postes et les serveurs sous système Windows, voire Linux ». Le guide liste ce qu’on oublie : équipements réseau, routeurs, commutateurs, pare-feux et terminateurs VPN ; systèmes rares ; et équipements reliés au réseau, imprimantes, baies de stockage, caméras, téléphonie, automates industriels, y compris de gestion technique du bâtiment. Avec une note dont la lucidité fait plaisir à lire : ces matériels « contiennent des socles systèmes anciens, des logiciels peu mis à jour, et des mots de passe par défaut », et « pour l’attaquant ce sont simplement des systèmes où personne ne surveille ses actions ». Le cas des imprimantes est traité dans la sécurisation des imprimantes réseau.

Un mot, pour finir, sur ce que le choix révèle. Une organisation qui peut reconstruire a su garder des sauvegardes hors d’atteinte, connaît ses flux, maîtrise ses dépendances d’identité et sait arrêter un service sans tuer son activité. Une organisation qui doit nettoyer en espérant n’a aucune de ces quatre choses. La décision se prend pendant la crise, mais elle a été préparée, ou non, pendant les cinq années précédentes, et c’est l’unique raison pour laquelle cette page a sa place ailleurs que dans une cellule de crise.

Sources

Cyberattaques et remédiation, volet stratégique : les clés de décision, ANSSI, 18 décembre 2023.
Cyberattaques et remédiation, volet opérationnel : piloter la remédiation, ANSSI, 18 décembre 2023.

🐝 Ce qui arrive si on s’en passe

Sans cœur de confiance reconstruit, chaque action de remédiation est menée depuis un environnement où l’attaquant est peut-être encore présent, et l’échec de l’éviction enclenche un cycle de re-compromission qui peut durer des mois voire des années. Sans investigation couvrant un périmètre défini, la décision de nettoyer repose sur une assurance locale prise pour une assurance générale, et la persistance qui n’a pas été cherchée n’a pas été trouvée. Sans cartographie des flux applicatifs, la stratégie par isolement est impraticable, et sans inventaire des adresses codées en dur, la stratégie par sanctuarisation s’arrête sur des blocages impossibles à anticiper. Sans sauvegarde antérieure à l’intrusion et vérifiée, la restauration réimporte la compromission avec les données. Et sans objectif de détection posé explicitement à la place d’un objectif d’étanchéité, l’éradication est abandonnée en cours de route par épuisement, laissant une organisation qui a payé le prix de l’ambition sans en obtenir le résultat.

🦫 Explication de la marmotte 🍫

Après une attaque informatique sérieuse, il faut reprendre le contrôle du système. Deux voies existent. Nettoyer : on cherche tout ce que l’attaquant a laissé derrière lui, on le retire, et on repart avec les mêmes machines. Reconstruire : on repart de machines neuves et on réinstalle, ce qui coûte beaucoup plus cher et prend beaucoup plus de temps.

Nettoyer n’est acceptable qu’à une condition, que l’agence nationale formule très clairement : être très sûr d’avoir trouvé tous les moyens par lesquels l’attaquant peut revenir. Et cette certitude est rare, parce que ces moyens sont nombreux et discrets, un programme caché, un réglage modifié, un compte créé, un droit ajouté. Si l’on se trompe, l’attaquant revient, il faut tout refaire, et l’équipe s’épuise. Le coût total devient alors bien supérieur à celui d’une reconstruction.

Reconstruire a aussi son piège, moins connu. Dans la plupart des organisations, les droits d’accès aux fichiers, aux messageries et aux applications reposent sur un annuaire central de comptes. Si l’on recrée cet annuaire à neuf, les comptes changent d’identifiant interne, et il faut réattribuer les droits partout. C’est faisable sur un petit système bien connu, très difficile sur un grand.

Dernière idée, la plus importante. Le but n’est pas d’obtenir un système d’où l’attaquant est certainement absent, parce que personne ne peut le garantir. Le but est d’obtenir un système où, s’il revient, on le voit et on l’arrête avant qu’il ne fasse de dégâts. Viser la perfection conduit à abandonner le chantier en route, épuisé, sans avoir gagné ni la sécurité ni le temps.

Pages voisines

La citent

Assainir ou reconstruire : la décision qui engage toute une remédiation

Elle cite

: les deux pages se citent l’une l’autre.

Assainir ou reconstruire : la décision qui engage toute une remédiation

Assainir ou reconstruire : la décision qui engage toute une remédiation

La séquence E3R, et l’endroit exact où la question se pose

Nettoyer : quand c’est possible, et à quelle condition

Reconstruire depuis zéro : l’autre piège, moins connu

Les deux stratégies réelles : isolement ou sanctuarisation

Les critères qui tranchent, et les trois scénarios

Ce que la décision n’est pas : viser un système étanche

Sources

🐝 Ce qui arrive si on s’en passe

🦫 Explication de la marmotte 🍫

À lire aussi

Pages voisines