Enseignements de Log4j : Ne vous précipitez pas dans la remédiation
La plupart d’entre nous, partageant le trait d’être des êtres humains, avons vécu ce qu’on appelle communément « combattre ou fuir » – une réaction physique autonome souvent intense se manifestant par un cœur qui s’emballe, des muscles tendus et des paumes moites. Un sentiment de panique peut accompagner la réaction, ainsi qu’une paralysie décisionnelle qui rend notre capacité à penser logiquement pratiquement inexistante.
Chaque entreprise dispose de sa propre version de cette réponse, développée et perfectionnée au fil des années de réponse à des situations numériques menaçantes.
Le risque pour les entreprises est similaire à celui pour les êtres humains. Chez l’homme, une activation trop fréquente, intense ou inappropriée de la réaction de combat ou de fuite est impliquée dans une série de conditions cliniques. C’est une façon abrégée de dire qu’ils peuvent causer de réels dommages physiques. Du côté des entreprises, l’invocation d’une activation fréquente, intense ou potentiellement inappropriée d’une réponse numérique de combat ou de fuite peut être préjudiciable à la santé de l’entreprise, en particulier dans le domaine de la sécurité.
Tout comme les « étapes du deuil » bien connues, nous avons noté l’émergence d’« étapes de réactions de sécurité » au cours des décennies de travail visant à atténuer les menaces liées aux application et aux infrastructures.
L’importance de choisir la bonne réponse
Se précipiter pour remédier à un problème peut être une de ces réactions qui, à long terme, ne s’avère pas être la meilleure réponse. Considérez que le premier patch publié pour Log4j par Apache était également vulnérable , donc les organisations qui se sont précipitées pour corriger le problème ont dû recommencer et appliquer à nouveau les correctifs sur tous leurs systèmes.
C’est à ce stade que je m’arrête et affirme avec force que ne pas se précipiter pour mettre en œuvre les mesures correctives ne signifie pas ignorer le risque ou pécher par excès d’inaction.
Il est particulièrement important de s’en souvenir, car ne pas gérer de manière responsable les données qui alimentent une entreprise numérique a des conséquences concrètes. Dans le sillage de Log4j, la Federal Trade Commission (FTC) des États-Unis a « averti qu'elle s'en prendrait aux entreprises du secteur privé qui ne parviendraient pas à protéger les données des consommateurs exposées à la suite de Log4j. » ( ZDNet )
Pourquoi l’atténuation est primordiale
L’atténuation vient avant la réparation pour une raison, notamment pour répondre à l’instinct humain de « faire quelque chose » et de se précipiter vers la réparation. L’atténuation rapide répond également à la nécessité d’être des gestionnaires responsables des données clients en les protégeant contre l’exfiltration tout en formulant le bon plan d’action de correction.
L’atténuation doit être la première mesure à prendre, en particulier lorsqu’il s’agit d’une vulnérabilité aussi répandue qui nécessitera une exploration approfondie de la chaîne d’approvisionnement en logiciels. L'omniprésence et la difficulté de découvrir où se cachent les packages et composants vulnérables sont probablement à l'origine de la constatation selon laquelle « les téléchargements vulnérables pour #log4shell ont toujours atteint 46 % au total » le 4 janvier. ( Sonatype )
La réalité d’un monde numérique par défaut est que de nouvelles vulnérabilités de sécurité traumatisantes continueront de perturber les entreprises et de mettre à rude épreuve des ressources déjà débordées. En raison de la nature robuste d’un portefeuille application d’entreprise, qui s’étend souvent sur cinq générations d’architectures application réparties sur le cœur, le cloud et la périphérie, nous devons supposer que la correction consommera la majeure partie du temps et de l’énergie. C’est pourquoi une atténuation rapide est si importante. Cela soulage la pression et permet une approche plus délibérée et plus complète de la correction, une approche qui inclut la vérification de la sécurité des correctifs publiés et permet aux développeurs de mettre à jour, de corriger et de tester en fonction des cycles de publication existants.
Les organisations doivent s’assurer qu’elles disposent de points de contrôle dans tous les environnements qui prennent en charge l’atténuation. La protection du Web et des API, l’inspection du contenu et les capacités de blocage aux points de contrôle stratégiques fournissent une sorte de « plate-forme » pour atténuer ces types de vulnérabilités omniprésentes. Ces mêmes points de contrôle peuvent également fournir des informations précieuses sous forme d'exposition de tentatives d'exploitation de telles vulnérabilités.
Conclusion
La plupart d’entre nous se souviennent des exercices d’incendie de notre enfance, où nous nous entraînions à sortir de l’école en toute sécurité en cas d’incendie. J’ai également pratiqué des exercices de préparation aux tornades, et je suppose qu’il y a probablement des enfants dans le monde qui se sont entraînés à se préparer aux tremblements de terre ou aux tsunamis. Avoir un plan et savoir comment l’exécuter peut être essentiel pour réduire le temps passé en mode panique lorsque la nouvelle d’une vulnérabilité importante est annoncée.
Alors ne paniquez pas. Utilisez des points de contrôle stratégiques et concentrez-vous sur une atténuation rapide afin de pouvoir exécuter une correction ciblée .
Et rappelez-vous, la pratique réduit la panique . Planifier et exécuter votre propre « exercice d’incendie de sécurité » n’est pas du tout une mauvaise idée.