Les premières heures après une CVE critique : une liste de contrôle qui marche

Une vulnérabilité de sévérité maximale dans un composant central est publiée. À partir de cet instant, l'horloge tourne pour tout le monde, attaquants compris. La différence entre une journée calme et une mauvaise semaine tient rarement au correctif lui-même. Elle tient à ce que vous faites dans les heures qui le précèdent et qui le suivent. Voici la séquence que nous suivons, écrite pour que vous puissiez l'adapter à votre propre flotte.

Heure zéro : lisez l'avis deux fois

Lisez l'avis une fois pour comprendre la faille et une fois pour comprendre les conditions. La plupart des avis sérieux viennent avec des restrictions : seulement quand un module particulier est chargé, seulement dans un mode serveur particulier, seulement quand une fonction est joignable depuis le réseau. Ces restrictions décident lesquels de vos hôtes sont urgents, lesquels sont simplement concernés, et quelle atténuation convient.

Notez trois choses avant de toucher à quoi que ce soit : les noms des paquets concernés, la version amont corrigée, et les conditions d'exploitation. Tout ce qui suit est vérifié face à cette note.

Trouvez chaque hôte qui l'exécute

Interrogez la base de paquets de chaque hôte plutôt que de vous fier à ce que vous croyez installé :

for h in $(cat hosts.txt); do
  printf '%s: ' "$h"
  ssh -o BatchMode=yes "$h" 'rpm -q --qf "%{NAME}-%{VERSION}-%{RELEASE}\n" <package> 2>/dev/null || echo not-installed'
done | tee exposure-$(date +%F).txt

Puis vérifiez les conditions. Si la faille vit dans un module, listez ce qui est réellement chargé. Si elle exige qu'une fonction soit joignable, vérifiez si elle l'est. Triez le résultat en trois groupes : exposé et joignable, installé mais non exploitable tel que configuré, et absent. Le premier groupe est atténué maintenant.

Atténuez avant que le correctif n'existe

Il y a presque toujours quelque chose à faire avant qu'un paquet corrigé ne soit disponible : désactiver la fonction vulnérable, changer une valeur de configuration, poser une règle en bordure qui bloque la forme de requête dont l'exploit a besoin. Choisissez l'atténuation la moins perturbatrice qui ferme le chemin, et appliquez-la avec discipline :

• Tenez une liste de chaque atténuation que vous avez posée, pour pouvoir lever celles qui coûtent en performance une fois le vrai correctif arrivé. Les atténuations qui ne coûtent rien peuvent rester.

Construisez le correctif vous-même s'il le faut

Parfois le projet amont a publié les sources corrigées et la distribution ne les a pas encore empaquetées. Attendre est une option, mais pas la seule. Quand nous décidons de ne pas attendre, nous construisons le paquet nous-mêmes : à partir de la spécification propre du mainteneur de la distribution, dans un conteneur jetable propre, à partir de sources dont la somme de contrôle est vérifiée face à la page de téléchargement officielle du projet, avec un tag de version choisi pour que la build du fournisseur remplace automatiquement la nôtre quand elle arrive. Les paquets vont dans notre propre miroir avec leurs sommes de contrôle consignées. La méthode complète, avec les commandes, est dans Votre propre miroir RPM, et construire le correctif avant que la distribution ne le livre.

La décision de construire est un jugement, pas un réflexe. Construisez quand la faille est exploitée ou trivialement exploitable, que les hôtes concernés sont joignables, et qu'aucune atténuation ne ferme assez bien le chemin. Sinon, une atténuation solide plus une courte attente du paquet du fournisseur est généralement le choix le plus serein.

Tenez un registre, et prévenez les gens

Tenez une chronologie au fil de l'eau

Ouvrez un fichier texte brut à l'heure zéro et écrivez une ligne par action, avec l'heure : avis lu, inventaire fait, atténuation posée sur quels hôtes, paquet construit, chaque hôte corrigé, revue des journaux terminée. Cela coûte quelques secondes par ligne. Cela vous donne la fenêtre d'exposition exacte de chaque hôte, dont la revue des journaux a besoin, et cela transforme le rapport que vous devez ensuite en une relecture plutôt qu'en un exercice de mémoire.

Prévenez les gens avant qu'ils ne demandent

Les personnes qui dépendent des systèmes concernés entendront parler d'une vulnérabilité célèbre par les médias, souvent en quelques heures. Prévenez-les d'abord. Un court message indiquant si leurs systèmes sont concernés, ce qui a déjà été fait et quand le correctif arrivera vaut plus qu'un rapport parfait une semaine plus tard. Si une étape exige un arrêt, convenez du moment avec eux avant de le prendre.

Déployez un hôte à la fois, avec preuve

Chaque hôte reçoit une vérification avant et une vérification après, et les deux sont comparées, pas survolées :

php -m | sort > pre-modules.txt      # or the equivalent for your component
curl -s -o /dev/null -w '%{http_code}\n' https://<site>/health
# install, then reload gracefully
systemctl reload php-fpm
php -m | sort > post-modules.txt && diff pre-modules.txt post-modules.txt

Sur une flotte plus grande, automatisez la partie minutieuse plutôt que de la sauter. Un déploiement qui met à niveau un serveur par passe, échantillonne de vrais sites avant et après, et arrête tout le balayage et appelle un ingénieur dès qu'un seul site ne revient pas est à la fois plus rapide et plus sûr qu'un humain qui parcourt une liste la nuit.

Puis demandez-vous si la fenêtre a été utilisée

Corriger ferme la porte. Cela ne dit pas si quelqu'un l'a franchie pendant qu'elle était ouverte. Une fois le déploiement terminé, cherchez dans les journaux web et d'authentification la période entre la divulgation et le correctif sur chaque hôte exposé. Cherchez les formes de requêtes dont l'exploit a besoin, les processus ou fichiers inattendus créés dans cette fenêtre, et les connexions qui ne correspondent pas au schéma habituel. Notez ce que vous avez trouvé, y compris « rien », parce que les personnes qui dépendent de ces systèmes le demanderont.

La version courte

• Lisez les conditions, pas seulement la sévérité.
• Inventoriez depuis la base de paquets, pas de mémoire.
• Atténuez en quelques heures.
• Construisez le correctif vous-même seulement quand c'est justifié, et faites-le proprement.
• Tenez une chronologie et prévenez tôt les personnes concernées.
• Déployez un hôte à la fois avec des vérifications avant et après comparables, et un arrêt automatique.
• Relisez la fenêtre d'exposition dans les journaux, et rapportez-la.

Si une divulgation tombe et que vous souhaitez de l'aide pour la traiter sur votre propre plateforme, nous sommes là. Parler à un ingénieur

Related (rows[1])

Voir aussi : Réponse d'urgence aux vulnérabilités le jour même · Le socle de durcissement sur chaque hôte · Plateformes à jour et discipline de mise à niveau