Blog Pourquoi votre stratégie de gestion des patches doit changer dès maintenant | Insight

Les exploits se déploient désormais en quelques heures, et non plus en quelques jours. La question n'est plus de savoir si vous serez impacté, mais si cela se produira selon vos conditions ou celles de l'attaquant.

Il y a quelques semaines, j'étais en pleine réunion lorsque mon ordinateur portable a décidé qu'il en avait assez d'attendre. J'avais repoussé la même mise à jour de correctif une fois de trop, et là, en plein milieu d'une phrase, il s'est éteint. Plus de « me le rappeler plus tard ». Aucune option de report.

Et le plus étonnant, c'est que je ne pouvais même pas lui en vouloir. J'ai attrapé mon téléphone, je me suis reconnecté à la réunion et j'ai poursuivi. Car cette politique (celle qui venait d'interrompre mon appel) est exactement celle que je recommande aux responsables de la sécurité d'adopter : imposer la perturbation selon ses propres conditions, et non celles de l'attaquant.

Appliquer les correctifs « à l'heure » signifie traiter les vulnérabilités critiques comme des incidents actifs, avec un délai de réponse mesuré en heures, et non des jours prescrits sur un calendrier.

Et si je dois demander à nos clients de repenser leur approche des correctifs, je me dois de l'appliquer moi-même.

Voici donc comment j'aborde ce sujet avec les responsables de la sécurité.

Le curseur dans ma tête

Cette image m'est venue lors d'une conversation, autour d'un déjeuner, avec un responsable de la sécurité à l'occasion de Cisco Live, et elle ne m'a plus quitté depuis. Imaginez un curseur. À une extrémité se trouve l'impact opérationnel : le risque de perturber votre activité. À l'autre extrémité se trouve un incident de sécurité : le risque d'être compromis. Chaque organisation se positionne quelque part sur cette échelle, qu'elle en ait conscience ou non, et sa position en dit long sur sa perception du risque.

Voici ce que la plupart des organisations signalent depuis des années. Lorsque vous appliquez un cycle de correctifs de 90 jours (et pour être honnête, c'était encore notre cadence chez Insight il n'y a pas si longtemps), vous prenez un pari. Vous vous dites : « Je préfère prendre le risque d'un incident de cybersécurité plutôt que celui de mettre à l'arrêt la production pour appliquer un correctif. » Vous avez positionné votre curseur fermement du côté de la protection des opérations. Vous estimez qu'une brèche est l'issue la moins probable, et vous optimisez donc contre la perturbation que vous voyez venir.

Je comprends parfaitement ce réflexe. Nous sommes attachés à nos processus. Nous sommes attachés à nos fenêtres de changement, à nos revues CAB, à nos contrôles ; ils existent pour assurer notre sécurité et la prévisibilité de nos opérations informatiques. Mais Mythos, comme d'autres modèles d'AI de pointe, a discrètement fait basculer les probabilités de ce pari, et de nombreux dirigeants n'ont pas encore réagi ni déplacé leur curseur de risque.

Ce que tout le monde néglige

Voici ce qui a changé ma propre vision des choses. Lorsque le délai entre la divulgation d'une vulnérabilité et l'apparition d'un exploit dans la nature passe de plusieurs jours à quelques heures (et, dans un avenir pas si lointain, à quelques minutes), la brèche cesse d'être l'issue improbable. Elle devient l'issue imminente.

Et voici l'élément sur lequel je souhaite vraiment que vous vous arrêtiez : une brèche constitue elle aussi une interruption de production. Vous ne pouvez pas éviter la perturbation en ne corrigeant pas. Vous ne faites qu'échanger un type de perturbation contre un autre.

Lorsque vous appliquez un correctif selon vos propres conditions, la perturbation est planifiée et maîtrisée. Vous l'avez programmée. Vos équipes sont en veille. Vos outils de restauration sont prêts. Si quelque chose tourne mal, vous le corrigez et vous poursuivez.

Lorsque vous subissez une brèche, vous connaissez également une interruption, mais cette fois non planifiée. Elle est inattendue, elle survient à 2 heures du matin lorsque vous ne disposez pas du personnel nécessaire, et elle est malveillante. La personne qui en est à l'origine a tout intérêt à vous maintenir à l'arrêt, et non à vous aider à redémarrer. C'est là tout l'enjeu de ce changement de perspective : planifiée et maîtrisée, contre inattendue et malveillante.

Vous ne choisissez plus si vous serez perturbé. Vous choisissez uniquement selon les conditions de qui cela se produira.

Deux approches, une même vulnérabilité

C'est la raison pour laquelle j'ai commencé à évoquer l'application de correctifs comme un incident plutôt que comme une tâche de maintenance. Même CVE, posture totalement différente.

Dans le modèle de maintenance, la question que nous posons est « Ce correctif risque-t-il de perturber la production ? » Nous mesurons le succès au pourcentage d'actifs couverts, et le délai se compte en semaines, voire en mois. Dans le modèle d'incident, la question devient « Quel est le rayon d'impact si nous ne corrigeons pas cette vulnérabilité ? » Nous mesurons le succès par le délai moyen de remédiation, et le délai se compte en heures. Lorsque l'exploitation ne prend que quelques heures, une fenêtre de maintenance mensuelle n'est plus un processus, c'est un facteur de risque qui accroît votre exposition opérationnelle.

Nous parlons désormais de déployer les correctifs selon le même type de workflow que celui attendu pour un incident de cybersécurité classique : détecter, trier, contenir, corriger, valider. Nous captons la divulgation grâce à une gestion continue de l'exposition aux menaces, nous identifions partout où elle se trouve au sein du parc informatique, nous utilisons le machine learning pour évaluer la probabilité réelle d'exploitation dans votre environnement spécifique, et nous validons ce résultat par des tests d'intrusion continus. S'il s'agit d'une vulnérabilité élevée à critique, un délai contractuel (SLA) se déclenche et nos équipes de réponse se mobilisent immédiatement.

Il ne s'agit pas de corriger l'intégralité du système dès la divulgation d'une faille. Il s'agit d'identifier le petit sous-ensemble de vulnérabilités présentant un risque réel et exploitable dans votre environnement, et de les traiter avec l'urgence propre à un incident.

À quoi cela ressemble-t-il un mardi matin ?

Plutôt que d'attendre le prochain cycle de correctifs, une vulnérabilité critique exposée à l'extérieur déclenche un workflow immédiat : l'équipe sécurité la signale, valide l'exposition, et lance l'application du correctif en quelques heures, exactement comme pour un incident actif.

Le gain contre-intuitif

Si vous êtes responsable des opérations, votre signal d'alarme se déclenche probablement : appliquer des correctifs plus fréquemment, cela signifie plus de perturbations, n'est-ce pas ?

En réalité, c'est l'inverse, et c'est l'argument que je souhaite voir les RSSI porter auprès de leurs partenaires opérationnels et métiers. L'une des principales raisons pour lesquelles les fenêtres de correctifs dérapent, c'est que nous laissons les correctifs s'accumuler, puis nous en déployons des dizaines dans des dizaines de sous-systèmes en une seule fois. En passant à une réponse en temps réel, vous corrigez un seul module concerné, isolément. Les risques de mauvaise surprise en aval chutent considérablement. Vous procédez par touches plus petites, plus maîtrisées, plus ciblées, et vous réduisez ainsi le risque opérationnel.

C'est un changement dans votre façon de fonctionner

Je ne prétendrai pas que la technologie constitue la principale difficulté. Ce n'est pas le cas. La difficulté est avant tout organisationnelle. Vous devez être prêt à rompre avec vos habitudes en matière de correctifs, et vous devez intégrer une véritable haute disponibilité à vos systèmes, car il est impossible de faire fonctionner de grandes applications monolithiques selon ce modèle sans mettre en péril votre application critique au quotidien. Cela implique une nouvelle approche de l'architecture, et cette réflexion doit dépasser largement le seul périmètre de l'équipe sécurité.

Je vous laisse sur la même question à laquelle je reviens sans cesse. Vous allez subir une certaine perturbation ; ce point n'est plus négociable. La seule chose que vous puissiez décider, c'est si elle sera planifiée et maîtrisée selon vos conditions, ou subie et imposée selon celles de l'attaquant.

Chez Insight, nous nous sommes portés client zéro de ce changement radical dans l'approche de la gestion des correctifs des systèmes informatiques. Nous avons fait face au même changement existentiel que tout le monde, restructuré notre approche de la sécurité et des opérations informatiques en conséquence, et ensuite seulement proposé cette approche à nos clients. Car peu importe qui a accès à Mythos. Il existe. Et il existe alors que des modèles aux capacités similaires s'apprêtent à voir le jour, dont certains ne sont pas développés par les « gentils ».

Ce qui compte, c'est de reconnaître que la manière de défendre votre entreprise a fondamentalement changé, et de déplacer votre curseur avant que quelqu'un d'autre ne le fasse à votre place.