Planifier les catastrophes

On découvre rarement une catastrophe quand elle bat son plein. On ne tombe pas sur un bâtiment déjà englouti par les flammes : on aperçoit ou l'on sent d'abord de la fumée — un signal ténu qui ne ressemble pas encore à un désastre. Le feu se propage par degrés, et l'on ne mesure la gravité de la situation qu'une fois pris dedans. C'est l'image qui ouvre le chapitre 16 de Building Secure and Reliable Systems, et elle résume sa thèse : puisque les systèmes finiront inévitablement par connaître des défaillances de fiabilité ou des incidents de sécurité, on se prépare avant la crise, pas pendant. La planification des catastrophes (disaster planning) n'est pas un exercice d'espoir — espérer qu'un système survive, ou que les équipes improviseront une réponse correcte —, c'est un travail continu d'amélioration de sa capacité à se relever. La bonne nouvelle, soulignent les auteurs, c'est que les premiers pas sont pragmatiques et abordables.

Définir une « catastrophe »

Les systèmes complexes échouent de manières simples comme complexes, depuis la panne de service inattendue jusqu'à l'attaque d'un acteur malveillant cherchant un accès non autorisé. L'ingénierie de fiabilité et les bonnes pratiques de sécurité préviennent une partie de ces défaillances, mais sur le long terme, la panne est quasi inévitable. Mieux vaut donc nommer clairement ce qu'on cherche à affronter. Le livre énumère les formes que prend une catastrophe.

Type de catastrophe	Exemples	Détectabilité
Catastrophe naturelle	Séisme, tornade, inondation, incendie	Évidente, impact variable sur le système
Catastrophe d'infrastructure	Panne de composant, mauvaise configuration (misconfiguration)	Pas toujours diagnosticable, impact faible à fort
Panne de service ou de produit	Indisponibilité observable par les clients ou parties prenantes	Observable de l'extérieur
Dégradation près d'un seuil	Service opérant au bord de sa capacité	Souvent difficile à identifier
Attaquant externe	Accès non autorisé persistant avant détection	Faible : en moyenne ~200 jours pour détecter une intrusion
Divulgation de données sensibles	Fuite de données confidentielles	Variable
Vulnérabilité de sécurité urgente	Correctif critique à appliquer immédiatement	Traitée comme une attaque imminente

Les auteurs emploient les termes catastrophe (disaster) et crise (crisis) de façon interchangeable, pour désigner toute situation susceptible de justifier la déclaration d'un incident et le déclenchement d'une réponse. Un détail important : un événement minuscule — une simple erreur comptable — peut déclencher une réponse à incident d'ampleur. La frontière n'est pas l'intensité apparente du signal, mais la décision de mobiliser.

Des stratégies de réponse dynamiques

La gamme des catastrophes possibles est vaste, mais des plans de réponse flexibles permettent de s'adapter à des situations qui évoluent vite. Penser à l'avance aux scénarios envisageables, c'est déjà faire le premier pas pour s'y préparer. Et comme tout savoir-faire, la réponse à incident s'aiguise par la planification, la pratique et l'itération, jusqu'à devenir une seconde nature.

Les auteurs insistent sur un point contre-intuitif : la réponse à incident, ce n'est pas comme le vélo. Sans pratique régulière, les intervenants perdent leur mémoire musculaire. Le manque d'entraînement produit des réponses fracturées et des temps de récupération plus longs. Quand les compétences de gestion d'incident sont devenues réflexes, les experts métier (subject matter experts) fonctionnent naturellement pendant la crise — ils ne se débattent plus avec le processus lui-même au moment où il faudrait penser au problème.

Il est utile de segmenter le plan de réponse en phases : réponse immédiate, récupération à court terme, récupération à long terme, puis reprise des opérations.

   Réponse        Récupération      Récupération        Reprise des
  immédiate    →   court terme   →    long terme    →    opérations
 (triage, fix    (rétablir le      (redesign,         (retour à la
  d'urgence)      service,          corrections        normale,
                  exit criteria)    de fond)           postmortem)

La phase de récupération à court terme doit inclure la définition des critères de sortie (exit criteria) de l'incident — c'est-à-dire les conditions permettant de déclarer la réponse terminée. Un rétablissement réussi peut signifier restaurer un service à pleine capacité, mais la solution sous-jacente peut tout aussi bien reposer sur une nouvelle conception offrant le même niveau de service. Les critères peuvent aussi exiger d'avoir complètement atténué les menaces de sécurité identifiées par l'analyse de risque. Pour bâtir cette stratégie, l'organisation se prépare en : analysant les catastrophes potentielles ; constituant une équipe de réponse ; créant des plans de réponse et des manuels d'intervention (playbooks) détaillés ; configurant les systèmes ; testant procédures et systèmes ; et intégrant les retours des tests et évaluations.

L'analyse de risque, point de départ

L'analyse de risque de catastrophe (disaster risk analysis) est la première étape pour déterminer les opérations les plus critiques — celles dont l'absence provoquerait une disruption totale. Elle doit identifier trois choses : les systèmes dont l'endommagement ou l'arrêt incapaciterait les opérations (que l'on classe en mission-essentiel, mission-important ou non essentiel) ; les ressources, technologiques comme humaines, nécessaires à la réponse ; et les scénarios de catastrophe probables pour chaque système, regroupés par probabilité, fréquence et impact (faible, moyen, fort, critique).

Plutôt qu'une appréciation purement intuitive, le livre recommande une matrice standardisée croisant probabilité d'occurrence et impact, pour éviter la pensée de groupe (groupthink) et faire ressortir des risques non évidents. Les notes de risque indiquent où concentrer l'attention en premier, mais il faut traquer les valeurs aberrantes : un événement improbable peut mériter une note critique à cause de son impact potentiel. Le risque varie aussi selon l'implantation géographique — un site au Japon ou à Taïwan tiendra compte des typhons, un site du sud-est des États-Unis des ouragans —, et il évolue à mesure que l'organisation mûrit et intègre des systèmes tolérants aux pannes (circuits internet redondants, alimentations de secours).

Un système de gestion d'incident : IMAG

Pendant une urgence, certains ingénieurs réagissent sans réfléchir aux conséquences de leurs actes. Pour limiter ce risque, Google utilise un système appelé Incident Management at Google (IMAG), calqué sur l'Incident Command System (ICS) — le standard éprouvé des services de secours. Le cadre IMAG attribue des rôles critiques : commandant d'incident, responsables opérationnels, responsable de la communication. La grande idée est que ce sont des rôles, pas des individus : une même personne peut porter plusieurs rôles au cours d'un incident, et les rôles survivent au remplacement des personnes.

Constituer une équipe de réponse à incident (incident response, IR) suppose de choisir un modèle de dotation. Le livre en distingue trois, chacun avec ses arbitrages.

Modèle de dotation	Avantage	Limite
Équipe IR dédiée à plein temps	Disponibilité, formation, accès et temps garantis	Coût ; réservé aux organisations à besoins complexes
Double casquette (IR en plus du poste)	Économique, mobilise l'existant	Disponibilité et formation moins assurées
Externalisation à des tiers	Expertise spécialisée (ex. forensique) à la demande	Intervenants pas toujours immédiatement disponibles

On peut panacher : garder l'équipe IR en interne tout en externalisant l'analyse forensique, par exemple. Les rôles possibles incluent le commandant d'incident (incident commander) qui dirige la réponse, les SRE qui reconfigurent un système ou corrigent un bug, les relations publiques, le support client, le juridique, les ingénieurs de confidentialité (privacy engineers), les spécialistes forensiques chargés de la reconstruction et de l'attribution des événements, et les ingénieurs sécurité.

Charte, sévérité et priorité

La charte de l'équipe IR commence par sa mission — une phrase unique décrivant les types d'incidents traités —, puis son périmètre (technologies, utilisateurs, produits, parties prenantes), et enfin une définition explicite du succès : comment sait-on que le travail de l'équipe est terminé ?

Deux modèles complémentaires, à utiliser conjointement, structurent ensuite la réponse. Le modèle de sévérité (severity) catégorise l'incident selon la gravité de son impact ; le modèle de priorité (priority) définit la vitesse de réponse attendue. Le livre propose pour chacun une échelle à cinq points (0 à 4), 0 étant le plus grave / le plus prioritaire.

Dimension	Ce qu'elle quantifie	Évolution dans le temps
Sévérité	Gravité de l'impact (ex. intrus sur le réseau = sév. 0)	En général fixe une fois comprise
Priorité	Tempo de travail exigé (priorité 0 = on lâche tout)	Variable : baisse une fois le correctif critique posé

Faire diverger ces modèles entre équipes est un piège classique : si une équipe traite un incident en priorité 0 et une autre, mal informée du contexte global, en priorité 2, elles opèrent à des tempos différents et retardent la réponse. Des paramètres de fonctionnement (operating parameters) — délai de première réponse, délai de triage initial, SLO précisant quand l'IR doit interrompre le travail courant — gardent tout le monde synchronisé.

Plans de réponse, manuels d'intervention et OpSec

Un plan de réponse (response plan) guide l'intervenant à haut niveau : signalement de l'incident, triage, SLO, rôles et responsabilités, mobilisation (outreach) des équipes d'ingénierie, et communication. Les manuels d'intervention (playbooks) le complètent : ils listent les instructions précises, de bout en bout, pour une tâche donnée — accorder un accès administrateur temporaire d'urgence, extraire et analyser certains journaux, basculer un système en mode dégradé. Procéduraux par nature, spécifiques à chaque équipe, ils doivent être révisés fréquemment.

La communication mérite une attention particulière, car elle peut se retourner contre l'équipe IR.

Pré-positionner systèmes et personnes (prestaging)

Une fois l'analyse de risque faite, l'équipe IR créée et les procédures documentées, il faut identifier les activités de pré-positionnement (prestaging) à réaliser avant la catastrophe, pour chaque phase du cycle de vie de l'incident. Le pré-positionnement consiste typiquement à configurer les systèmes avec une rétention de journaux définie, des réponses automatiques, et des procédures humaines clairement établies — afin d'éliminer les angles morts entre sources de données, réponses automatisées et réponses humaines. L'équipe IR doit notamment prédéterminer les niveaux d'accès appropriés et les procédures d'escalade, pour que l'obtention d'un accès d'urgence ne soit ni lente ni alambiquée.

Côté configuration des systèmes, le livre énumère plusieurs ajustements qui réduisent le temps de réponse initial : intégrer la tolérance aux pannes et créer des bascules (failovers) ; déployer des agents forensiques (comme les agents GRR) sur le réseau, journalisation activée — sachant que les journaux de sécurité exigent une longue rétention, car la durée moyenne de détection d'une intrusion avoisine 200 jours, et un journal effacé avant la détection ne sert plus à rien ; conserver un jeu identique du matériel et du logiciel ayant servi aux sauvegardes, et mener des exercices de restauration périodiques ; et enfin disposer de plusieurs chemins de repli pour l'accès et la récupération — par exemple un ensemble de systèmes isolés du réseau (air-gapped) connus pour être sains, indispensable quand on ignore l'étendue d'une compromission.

Côté personnes, la formation dépasse la seule équipe IR. On forme les ingénieurs susceptibles d'assister l'IR aux différents rôles ; on apprend à tous les employés à reconnaître, signaler et escalader un incident via des canaux clairs et distincts ; et l'on fixe une limite de temps durant laquelle un premier intervenant peut se débattre avec un incident avant d'escalader — une fenêtre de 15 minutes, par exemple, à ajuster selon le niveau de risque accepté. Les critères de décision se fixent avant le feu de l'action, pour que les intervenants choisissent la voie la plus logique plutôt qu'une décision instinctive (mettre un système compromis hors ligne ? quelle méthode de confinement ?). On entraîne aussi les ingénieurs à gérer des priorités apparemment mutuellement exclusives — maintenir le maximum de disponibilité tout en préservant les artefacts pour l'enquête forensique — et à noter leurs propres actions, afin de les distinguer plus tard des traces laissées par un attaquant.

Tester les plans d'urgence

Une fois tous les matériels de préparation créés, il est essentiel d'en évaluer l'efficacité et de combler les déficiences. Sans procédures ni systèmes automatisés, même une équipe IR très compétente répondra de façon incohérente ; et des procédures documentées mais inaccessibles ou inutilisables ne seront jamais appliquées. On teste donc chaque couche — au minimum annuellement — sous plusieurs angles : auditer les systèmes automatisés, tester les processus, entraîner le personnel.

Type d'exercice	Intrusif ?	Ce qu'il valide	Trait distinctif
Audit des systèmes automatisés	Non	Sauvegardes, journaux, correctifs, alertes, outils de communication fonctionnent	Vérifie chaque règle d'alerte et ses dépendances
Exercice sur table (tabletop)	Non	Procédures documentées + prise de décision des équipes	Scénario « dont vous êtes le héros », 10–20 points de décision
Injection de fautes (fault injection)	Oui (ciblé)	Un composant isolé, sans mobiliser ses dépendances	Ex. filtre de faute du proxy Envoy : erreurs ou latence sur un % du trafic
Test multi-composants	Oui	Pannes simultanées, respect des ACL en bascule, fail closed	Va au-delà du simple exercice de pensée
Bascule à l'échelle du système	Oui	Le système entier survit à la perte d'un datacenter	Google coupe régulièrement le courant de bâtiments entiers
Red Team	Oui, non annoncé	Détection et réponse de bout en bout, facteur humain	Attaque offensive simulée, surprise pour les intervenants

Exercices sur table (tabletops)

Les exercices sur table sont des outils précieux, non intrusifs : comme ils ne mettent aucun système hors ligne, ils ne perturbent pas la production. À la manière du « Wheel of Misfortune » des SRE, l'animateur présente un scénario d'incident assorti de variations, et demande aux participants de démontrer — pas seulement de décrire — comment ils répondraient, en exécutant réellement les étapes de leur playbook. Cette ouverture permet d'inclure ingénieurs de terrain, direction, relations publiques et juristes. Quatre ingrédients en font la qualité : la crédibilité (un scénario réaliste, fondé sur des attaques et vulnérabilités connues, avec des pivots plausibles) ; les détails (artefacts réalistes — journaux, alertes, signalements clients — et un animateur bien préparé) ; les points de décision (10 à 20 pour une heure, à la « dont vous êtes le héros » : si l'on décide de couper le serveur de courrier compromis, on ne peut plus envoyer de notifications pour la suite) ; et des résultats actionnables (conclure sur ce qui a marché et ce qui doit s'améliorer, avec des actions assorties de propriétaires).

Tester en production

Certains scénarios doivent être éprouvés dans un environnement de production réel, là où sécurité et fiabilité se croisent. L'injection de fautes permet de tester un composant isolé sans mobiliser ses dépendances : le proxy HTTP open source Envoy, par exemple, dispose d'un filtre d'injection de fautes capable de retourner des erreurs arbitraires sur un pourcentage du trafic, ou de retarder des requêtes — de quoi vérifier qu'un système gère correctement les délais d'attente (time-outs) et, le jour venu, reproduire de façon contrôlée un comportement anormal observé en production. Le test humain vérifie ce qui se passe quand une personne clé est indisponible. Le test multi-composants examine les pannes simultanées et les questions de sécurité associées : lors d'une bascule, le système respecte-t-il les ACL existantes ? un service d'autorisation échoue-t-il fermé (fail closed) ? Enfin, la bascule à l'échelle du système vérifie la survie complète à la perte d'un site : tant qu'on n'a pas basculé sur le datacenter secondaire, on ne peut être certain de sa stratégie. Google coupe régulièrement le courant de bâtiments entiers pour vérifier l'absence d'impact visible par l'utilisateur — et pour que les techniciens soient rodés aux procédures d'extinction et de rallumage.

Red Team et boucles de rétroaction

En complément des tests annoncés, Google pratique des exercices de Red Team : du test offensif mené par son organisation Information Security Assurance, sans préavis aux intervenants (sauf la direction). Familière de l'infrastructure interne, la Red Team est bien plus productive qu'un test d'intrusion réseau classique ; elle se situe entre l'attaque purement externe et le risque interne (insider risk), complète les revues de sécurité en testant de bout en bout, et éprouve le comportement humain via hameçonnage et ingénierie sociale.

Les exemples de Google

Trois cas rendent ces principes concrets. En 2019, Google a testé sa réponse à un séisme majeur dans la baie de San Francisco : premiers secours aux blessés, aide au public, escalade de l'information vers la direction en cas de réseau cellulaire ou de LAN/MAN/WAN coupés, prise en charge des personnes bloquées sur les campus, et — point clé — transfert d'autorité vers des SRE et équipes situés hors de la zone sinistrée si les équipes locales ne pouvaient l'initier.

Enfin, en 2018, Google a reçu un préavis sur deux vulnérabilités du noyau Linux — SegmentSmack (CVE-2018-5390) et FragmentSmack (CVE-2018-5391) — capables, via des fragments IP et segments TCP spécialement forgés, de réduire d'un facteur ~20 la résilience d'un service au déni de service : un service capable d'encaisser normalement une attaque à 1 Mpps s'effondrait dès ~50 Kpps. La préparation a permis d'atténuer sur deux fronts : côté gestion d'incident, une équipe d'incident managers à plein temps ; côté technique, un correctif à chaud (ksplice) appliqué aux fonctions vulnérables sans redémarrage, rendu possible par une discipline de déploiement du noyau (objectif de moins de 30 jours pour toute la flotte) et des mécanismes pré-testés permettant d'accélérer le déploiement — au point d'obtenir rapidement l'approbation d'un VP pour patcher pendant un gel de code (code freeze).

À retenir

• Une catastrophe se définit largement (panne, dégradation, attaque, fuite, vulnérabilité urgente) et se révèle rarement d'un coup : la frontière n'est pas l'intensité du signal mais la décision de déclarer un incident et de mobiliser une réponse.
• La thèse du chapitre : on se prépare avant la crise, jamais pendant. La réponse à incident n'est pas comme le vélo — sans pratique régulière, la mémoire musculaire se perd et les réponses se fracturent.
• Une réponse efficace repose sur une équipe IR aux rôles clairs (pas des individus), un cadre de gestion d'incident — l'IMAG de Google, inspiré de l'ICS —, des modèles de sévérité (fixe) et de priorité (variable), des plans de réponse et des playbooks détaillés.
• Le pré-positionnement (prestaging) configure systèmes et personnes à l'avance : accès et escalades prédéfinis, journaux à longue rétention (intrusion détectée en ~200 jours en moyenne), chemins de repli air-gapped, formation à l'escalade et aux décisions sous contrainte.
• On teste sur tout le spectre : audits automatisés, exercices sur table non intrusifs (10–20 points de décision), injection de fautes ciblée, tests multi-composants (fail closed, respect des ACL), bascules à l'échelle du datacenter, et exercices Red Team non annoncés.
• DiRT illustre l'union sécurité-fiabilité : tester les identifiants breakglass tout en vérifiant, via la détection de signaux, que l'alerte se déclenche et que l'accès est légitime.
• Un exercice sans leçons appliquées « n'est que du divertissement » : postmortems sans blâme, mesures, boucles de rétroaction, et Purple Team comme test de non-régression des vulnérabilités.