Aller au contenu principal

Tout était critique cette semaine. Il a bien fallu que quelqu'un choisisse.

PAN-OS, eMudhra, PHP2Shell, Node.js. Huit jours, six incidents, et aucun score pour vous dire quoi traiter en premier. Voici qui aurait dû décider, et à quel moment.

Christophe MazzolaChristophe Mazzola· Practicing CISO · Founder of Cyber Academy7 min de lecture
Une main actionnant un levier d'aiguillage sur un convoyeur, orientant un colis éclairé vers une voie dorée pendant que six colis identiques attendent sur des voies sombres

Huit jours. Six incendies.

Le 14 octobre, Palo Alto Networks a divulgué une faille PAN-OS permettant à un attaquant authentifié d'obtenir un accès root sur le pare-feu via l'interface de gestion. Elle avait déjà été exploitée en zero-day. Le 17 octobre, un chercheur a démontré que huit autorités de certification intermédiaires exploitées par eMudhra avaient des clés privées récupérables en moins d'une seconde. L'une de ces clés était le chiffre 4. Le 19 octobre, Unit 42 a signalé que des groupes de ransomware, dont Qilin, utilisaient une faille GlobalProtect pour contourner directement le MFA.

Le 21 octobre, PHP a publié des correctifs d'urgence pour PHP2Shell, une exécution de code non authentifiée sur toutes les installations PHP servant des requêtes web, après que les détails ont fuité un jour avant la date prévue. Le même jour, Node.js a publié dix CVE, dont un bug d'exécution de code à distance dans son décodeur Brotli. Le 22 octobre, Palo Alto a confirmé que PHP2Shell était présent dans toutes les versions de PAN-OS et Panorama, sans correctif disponible ni date annoncée. Les versions corrigées sont désormais estimées pour le 26 au 30 octobre, selon la branche de publication.

Si vous pilotez une fonction sécurité, vous n'avez pas patché votre chemin à travers cette semaine. Vous avez choisi, ou quelqu'un a choisi à votre place.

Les scores n'ont rien décidé

Alignons les chiffres.

L'exploit root PAN-OS, utilisé contre de vrais pare-feux : 8,6. Le contournement GlobalProtect, entre les mains d'opérateurs de ransomware : 7,8. L'effondrement eMudhra, une CA de confiance dont les clés de signature étaient recalculables par n'importe qui, qualifié par un ingénieur cryptographique de Mozilla d'incident à l'impact le plus élevé possible : l'incident lui-même n'a aucun score, et le seul CVE aval que CISA a évalué a obtenu un 5,4. PHP2Shell : 9,2 chez PHP, et qualifié par Palo Alto de problème de disponibilité sur ses propres pare-feux.

La veille de tout cela, Microsoft a publié plus de 1 400 CVE en un seul Patch Tuesday. Soixante-neuf étaient classés Critical. Celui déjà exploité était classé Important.

Un score CVSS décrit la gravité théorique d'une faille. Il ne sait rien de si quelqu'un l'exploite ce matin, de si elle est exposée sur internet dans votre périmètre, ni de ce qui se trouve derrière. Cette semaine, ces trois éléments constituaient toute l'histoire.

Votre politique de patch aurait planifié le vecteur ransomware pour le mois prochain

Ouvrez votre politique de gestion des vulnérabilités. Je parie qu'elle ressemble à ceci : Critical sous 7 jours, High sous 30, Medium sous 90.

Faites passer cette semaine à travers elle. PHP2Shell tombe dans le seau des 7 jours, c'est bien. La faille root PAN-OS exploitée est High : 30 jours. Le contournement GlobalProtect activement utilisé par des groupes de ransomware : High, 30 jours. eMudhra : Medium, 90 jours, à supposer que quelqu'un ait même ouvert un ticket.

Votre propre politique aurait classé les deux éléments que les attaquants utilisaient réellement comme des travaux de second rang, et accordé à une autorité de certification compromise un trimestre pour se remettre en ordre.

En tant qu'auditeur, c'est ce que je constaterais. Être lent est un écart. Un processus documenté qui vous rend lent lorsqu'on le suit à la lettre est un écart plus grave ; c'est une non-conformité A.8.8 visant une politique qui fait exactement ce pour quoi elle a été rédigée.

Les droits de décision se définissent en temps calme

Voici la question qui a différencié les organisations cette semaine. Qui pouvait retirer une interface de gestion de pare-feu d'internet à 23h00, sans attendre le comité de gestion des changements du jeudi ?

PAN-OS vous a donné deux raisons en huit jours de cesser d'exposer cette interface. Les préconisations de Palo Alto sur la première faille sont de restreindre l'accès à la gestion aux adresses internes de confiance, et il indique que la seconde est la plus dangereuse lorsque l'interface accepte des connexions depuis internet. C'est un changement de configuration qu'un ingénieur compétent effectue en quelques minutes. Dans la plupart des organisations, personne n'est autorisé à le faire seul.

Amazon a enregistré une tentative d'exploitation de PHP2Shell le 17 octobre, quatre jours avant la divulgation publique. CISA a accordé aux agences fédérales américaines trois jours sur la faille PAN-OS. Votre CAB se réunit chaque semaine. Le calcul ne fonctionne pas, et aucun niveau de talent technique ne comble un écart de gouvernance.

La procédure d'urgence doit exister avant l'urgence. Des personnes nommées. Les actions précises qu'elles peuvent entreprendre sans demander d'autorisation. La façon dont elles le consignent. À qui elles en rendent compte ensuite. Rédigez-la un mardi tranquille, répétez-la une fois, et elle sera là le samedi.

eMudhra était le vrai test

PAN-OS et PHP ont des correctifs, ou en auront. eMudhra n'a rien à installer.

Les navigateurs ont réagi vite. Chrome et Firefox ont bloqué les huit intermédiaires le 17 octobre, Microsoft et Apple ont suivi en quelques jours. eMudhra les a révoqués, et le 22 octobre a annoncé qu'il abandonnait entièrement le marché des certificats TLS.

Vos navigateurs vont bien. Vos conteneurs, VMs, appliances, keystores Java et chaque environnement Python embarquant sa propre copie de certifi sont une autre conversation. Node.js a dû intégrer la défiance dans sa propre version de sécurité. Go a publié de nouvelles versions pour cela.

La question que votre organisation devait réellement répondre était celle-ci : où faisons-nous confiance aux autorités de certification, et qui peut modifier cela partout à la fois ? La plupart ne peuvent pas répondre à la première moitié. C'est un problème d'inventaire, et l'inventaire cesse d'être une corvée informatique dès qu'un régulateur le demande. Sous NIS2, l'organe de direction approuve les mesures de gestion des risques et en répond.

L'ordre de décision

Avant le score, posez quatre questions.

  • Est-ce exploité ? KEV, l'avis du fournisseur, votre threat intel. Si oui, cela passe en priorité, quel que soit son score.
  • Est-ce exposé ? Exposé sur internet devance interne. Les interfaces de gestion devancent presque tout.
  • Qu'est-ce que cela touche ? L'identité, la confiance, les systèmes hébergeant vos données, les serveurs dont tout le monde dépend.
  • Quel est le score ? Utilisez-le pour classer ce qui reste.

Bruxelles est arrivé au même endroit. Depuis le 11 septembre, les fabricants soumis au Cyber Resilience Act doivent signaler les vulnérabilités activement exploitées. L'exploitation est le déclencheur, et le score n'y apparaît nulle part.

Conseil : Réécrivez vos SLA autour de ces questions. Exploité et exposé : heures. Exploité ou exposé : jours. Ni l'un ni l'autre : votre cycle normal, le score servant à départager. Remettez ensuite à votre auditeur une politique que vous pouvez réellement suivre.

Ce que votre comité de direction doit entendre cette semaine

Trois phrases.

Sommes-nous exposés à l'un de ces éléments, oui ou non. Ce que nous avons fait, et quand. Ce que nous avons choisi de laisser pour l'instant, et qui a validé ce choix.

Un décompte de CVE ne leur donne rien sur quoi agir. La troisième phrase est celle qui compte. En vertu de l'article 20 de NIS2, votre organe de direction approuve les mesures de gestion des risques de cybersécurité, supervise leur mise en œuvre et peut être tenu responsable des manquements. S'ils n'entendent jamais ce qui a été différé, ils ne peuvent pas en être propriétaires, et vous avez discrètement pris une décision qui leur appartenait.

Le backlog est une décision. Signez-le.

Vous ne corrigerez pas tout. Vous ne l'avez pas fait depuis des années. Le volume rend simplement impossible de continuer à faire semblant.

Tout ce qui attend a été accepté, que quelqu'un l'ait consigné ou non. Alors consignez-le. Un responsable nommé, la raison, le contrôle compensatoire le cas échéant, et une date de réexamen. Une vulnérabilité différée avec une signature est une décision de risque. Sans signature, c'est une omission que vous devrez expliquer plus tard.

Pour conclure

Des semaines comme celle-ci vont continuer à arriver. La découverte s'accélère plus vite que quiconque ne peut patcher, et chaque système de scoring continuera à vous remettre des listes où tout semble urgent.

Les organisations qui ont bien traversé cette semaine avaient une chose en commun. Elles savaient qui était autorisé à décider, dans quel ordre, et comment informer leurs supérieurs de ce qui avait été laissé sur la table. Leurs scanners étaient les mêmes que ceux de tout le monde.

C'est un travail de leadership. Personne d'autre dans l'organisation ne le fera à votre place.

Ce sont les compétences au cœur de trois de nos formations. Certified CISO by PECB pour les droits de décision et la conversation avec votre comité de direction. NIS 2 Directive Lead Implementer pour l'article 20 et ce dont votre organe de direction répond désormais. ISO 27001 Lead Implementer pour une politique de vulnérabilité que vous pouvez réellement suivre, et une acceptation des risques qui tient en audit.

Choisissez celle qui correspond à l'écart que cette semaine a mis en lumière.

Vous voulez recevoir la prochaine note de terrain dans votre boîte mail ?

La newsletter The GRC Brief. Cinq liens et une prise de position courte, chaque lundi à 8h CET. Trois minutes de lecture.