La plupart d’entre nous, en tant qu’êtres humains, avons déjà fait l’expérience de ce que l’on appelle communément la réaction de « combat ou fuite » : une réaction physique autonome, souvent intense, qui se manifeste par une accélération du rythme cardiaque, des tensions musculaires et des paumes moites. Elle peut s’accompagner d’un sentiment de panique, ainsi que d’une incapacité à prendre une décision qui nous empêche pratiquement de réfléchir de manière logique.
Les entreprises ont leur propre version de cette réaction, développée et perfectionnée au fil des années passées à faire face à des situations numériques menaçantes.
Le risque pour les entreprises est comparable à celui auquel sont exposés les êtres humains. Chez l’être humain, une activation trop fréquente, trop intense ou inappropriée de la réaction de lutte ou de fuite est impliquée dans diverses pathologies cliniques. Autrement dit, elle peut provoquer de réels dommages physiques. Dans le monde de l’entreprise, le déclenchement fréquent, intense ou potentiellement inapproprié d’une réaction numérique de lutte ou de fuite peut nuire à la santé de l’entreprise, en particulier dans le domaine de la sécurité.
À l’instar des célèbres « étapes du deuil », nous avons constaté l’émergence d’« étapes de réaction en matière de sécurité » au fil de plusieurs décennies consacrées à l’atténuation des menaces liées aux applications et aux infrastructures.
L’importance de choisir la bonne réponse
Se précipiter pour corriger le problème peut faire partie de ces réactions qui, à long terme, ne s’avèrent pas être la meilleure réponse. Il faut savoir que le premier correctif publié par Apache pour Log4j était lui aussi vulnérable, si bien que les organisations qui s’étaient empressées de corriger le problème ont dû tout reprendre depuis le début et appliquer de nouveau des correctifs à l’ensemble de leurs systèmes.
C’est ici que je m’arrête pour affirmer avec force que ne pas se précipiter pour remédier au problème ne signifie pas qu’il faut ignorer le risque ou privilégier l’inaction.
Il est particulièrement important de garder cela à l’esprit, car ne pas gérer de manière responsable les données qui alimentent une entreprise numérique entraîne des conséquences bien réelles. À la suite de Log4j, la Federal Trade Commission (FTC) des États-Unis « a averti qu’elle poursuivrait les entreprises du secteur privé qui n’auraient pas protégé les données des consommateurs exposées à la suite de Log4j ». (ZDNet)
Pourquoi l’atténuation des risques passe en premier
Ce n’est pas sans raison que l’atténuation précède la remédiation : elle permet notamment de contrer l’instinct humain qui pousse à « faire quelque chose » et à se précipiter sur la remédiation. Une atténuation rapide répond également à la nécessité de gérer les données des clients de manière responsable, en les protégeant contre toute exfiltration pendant l’élaboration du plan d’action de remédiation approprié.
L’atténuation doit être la première mesure prise, en particulier face à une vulnérabilité aussi répandue, qui nécessitera une analyse approfondie de la chaîne d’approvisionnement logicielle. La présence généralisée de cette vulnérabilité et la difficulté à déterminer précisément où peuvent se cacher les paquets et composants vulnérables expliquent probablement le constat selon lequel « les téléchargements vulnérables liés à #log4shell représentaient encore 46 % du total » au 4 janvier. (Sonatype)
Dans un monde où le numérique est la norme, de nouvelles failles de sécurité aux conséquences graves continueront inévitablement à perturber les activités et à solliciter des ressources déjà surchargées. Compte tenu de la complexité du portefeuille d’applications d’une entreprise — qui couvre souvent cinq générations d’architectures applicatives réparties entre le cœur du réseau, le cloud et la périphérie —, il faut partir du principe que la correction mobilisera l’essentiel du temps et de l’énergie. C’est pourquoi une atténuation rapide est si importante. Elle réduit la pression et permet d’adopter une démarche de correction plus réfléchie et plus complète, qui consiste notamment à vérifier que les correctifs publiés sont sûrs et à permettre aux développeurs d’effectuer les mises à jour, d’appliquer les correctifs et de réaliser les tests conformément aux cycles de publication existants.
Les organisations doivent veiller à disposer, dans tous leurs environnements, de points de contrôle permettant de mettre en œuvre des mesures d’atténuation. La protection des applications web et des API, l’inspection des contenus et les capacités de blocage déployées à des points de contrôle stratégiques constituent une sorte de « plateforme » d’atténuation face à ce type de vulnérabilités généralisées. Ces mêmes points de contrôle peuvent également fournir des informations précieuses en révélant les tentatives d’exploitation de ces vulnérabilités.
Conclusion
La plupart d’entre nous se souviennent des exercices d’évacuation incendie de leur enfance, au cours desquels nous apprenions à sortir de l’école en toute sécurité en cas d’incendie. J’ai également participé à des exercices en cas de tornade, et j’imagine que, partout dans le monde, des enfants se sont probablement entraînés à réagir en cas de tremblement de terre ou de tsunami. Disposer d’un plan et savoir comment le mettre en œuvre peut être essentiel pour réduire le temps passé à céder à la panique lorsque la nouvelle d’une vulnérabilité majeure tombe.
Alors, ne paniquez pas. Appuyez-vous sur des points de contrôle stratégiques et privilégiez une atténuation rapide afin de pouvoir procéder à une remédiation ciblée.
Et n’oubliez pas : l’entraînement réduit la panique. Planifier et réaliser votre propre « exercice d’alerte de sécurité » est loin d’être une mauvaise idée.
À propos de l’auteur
Lori MacVittie est ingénieure émérite et évangéliste en chef au sein du bureau du directeur technique de F5. Elle possède une expertise approfondie dans la fourniture d’applications, les stratégies d’automatisation et les infrastructures. Elle est réputée pour sa capacité à rendre la complexité intelligible, qu’elle définisse des garde-fous pour les agents d’IA, analyse des architectures multicloud fragiles ou explore les limites des systèmes évolutifs. Elle cumule plus de trente ans d’expérience dans le secteur, couvrant le développement d’applications, l’architecture informatique ainsi que l’exploitation des réseaux et des systèmes. Avant de rejoindre F5, elle a été rédactrice spécialisée dans les technologies et a reçu plusieurs distinctions. MacVittie est titulaire d’un master en informatique et est une autrice prolifique dont les publications couvrent la sécurité, le cloud et l’architecture d’entreprise. Elle est également une passionnée de jeux de société et de jeux vidéo, et assume pleinement ses avis bien tranchés sur le fromage.
Autres articles de Lori Mac VittieArticles de blog associés
F5 NGINXaaS pour Google Cloud : des applications résilientes et évolutives
Découvrez comment NGINXaaS s’intègre à Google Cloud pour renforcer les performances et la sécurité, et préparer vos applications critiques à un avenir propulsé par l’IA.
L’intégration de F5 Web Application Firewall (WAF) à AWS est disponible dès aujourd’hui
En faisant appel à un partenaire de déploiement AWS WAF tel que F5, vous pouvez renforcer la sécurité de vos applications web grâce à des règles personnalisées qui bloquent les schémas d’attaque courants, comme les injections SQL ou les attaques par scripts intersites (XSS).
Appliquer le principe de Peter Parker à l’inspection TLS
« Un grand pouvoir implique de grandes responsabilités. » Si l’on en trouve des échos chez Voltaire et Churchill, cette citation est surtout connue grâce aux bandes dessinées Spider-Man, où elle est attribuée à l’oncle Ben. Bien entendu, si cette phrase est si répandue dans la culture populaire, c’est notamment parce qu’elle peut s’appliquer à une multitude de situations et de sujets, y compris à l’inspection TLS.
Le NetOps a besoin de défenseurs, pas d’adversaires
Il est important de reconnaître que les équipes NetOps ne sont pas toujours celles qui font obstacle au déploiement de la dernière nouveauté, application ou service. Les freins à la rapidité sont souvent dus au fait que les organisations n’adoptent pas tous les principes du DevOps lorsqu’elles cherchent à transformer leurs opérations informatiques.
Mise à jour des services applicatifs : sécurité, rapidité et visiteurs suspects
Il est de nouveau temps de nous pencher sur les services applicatifs que les entreprises utilisent réellement pour rendre leurs applications plus rapides et plus sûres. On constate notamment une hausse du recours aux services de protection contre les bots, ainsi que la progression lente mais régulière de HTTP/2. Bien qu’il ne s’agisse pas d’une application…
Les templates prennent le contrôle du cloud
Les modèles s’imposent dans le cloud. Lisez le blog de F5 pour découvrir comment l’infrastructure en tant que code et les API déclaratives automatisent la mise à disposition des applications.