Dark background with blue code overlay
Blog

Rétrospective de Log4j, partie 4 : 5 leçons tirées de Log4j

Charlie Gero

Written by

Charlie Gero

January 13, 2022

Charlie Gero est vice-président & CTO de la division Enterprise d'Akamai et dirige le groupe Projets avancés. Il se concentre actuellement sur la recherche de pointe dans les domaines de la sécurité, des mathématiques appliquées, de la cryptographie et des algorithmes distribués, afin de mettre au point la prochaine génération de technologies qui protégeront la clientèle croissante d'Akamai. Grâce à ses recherches au sein d'Akamai, il a obtenu près de 30 brevets dans les domaines de la cryptographie, de la compression, des systèmes de réseau performants, de la diffusion multimédia en temps réel, etc. Il travaille chez Akamai depuis près de 15 ans, après avoir fondé une start-up et occupé des postes clés en informatique dans le secteur pharmaceutique et le domaine des réseaux.

lessons.png

Dans la partie 4 de la série rétrospective sur Log4j, je souhaite souligner les principaux points à retenir. Nous tirerons de nombreuses autres leçons à mesure que nos efforts pour éradiquer cette vulnérabilité progresseront. Cependant, nous observons déjà cinq points majeurs à retenir.

1. La nouvelle norme

La complexité des logiciels et la vitesse à laquelle les utilisateurs finaux exigent de nouvelles fonctionnalités continuent de croître rapidement et sans limites. Afin de répondre aux besoins des utilisateurs finaux dans les délais requis, les développeurs doivent compter sur un ensemble de bibliothèques, d'écosystèmes de langages, d'infrastructures et de services tiers qui se développe à grande vitesse. Par conséquent, une part croissante des fonctionnalités d'un logiciel est composée d'éléments que les développeurs eux-mêmes n'ont jamais touchés ou entièrement compris.

Dans n'importe quel graphique de dépendance logicielle, les vulnérabilités sont héritées des nœuds terminaux, ou du code et des services partagés, jusqu'au nœud racine, ou au produit en cours de programmation. À mesure que la proportion de ces nœuds terminaux ajoutée à un projet augmente de plus en plus, comme cela est nécessaire selon les informations ci-dessus, le risque d'une vulnérabilité augmente également.

Tout cela conduit à une conclusion inévitable : non seulement ces types de vulnérabilités sont là pour durer, mais ils vont continuer de croître, en termes fréquence comme d'impact.

C'est la nouvelle norme.

2. Le risque est récursif

Nous pensons souvent à tort aux risques liés aux systèmes, aux logiciels et aux fonctions que nous pouvons contrôler directement. Les entreprises plus avancées commencent à évaluer le risque d'éléments plus difficiles à contrôler, par exemple en demandant à leurs développeurs d'analyser la fiabilité d'une bibliothèque donnée.

Mais, étant donné qu'un nombre croissant de systèmes et de logiciels continuent d'être composés d'une multitude de couches de code tiers, les entreprises devront de plus en plus évaluer le risque d'une bibliothèque ou d'un partenaire donné, mais aussi les pratiques de cette communauté de développement ou de ce fournisseur, pour s'assurer qu'ils analysent également leurs dépendances.

Chaque nœud de l'arborescence des dépendances et de la chaîne d'approvisionnement doit être évalué par vous, vos partenaires et/ou la communauté de développement concernée afin de déterminer si les niveaux de risque tolérables sont atteints.

3. La visibilité augmente la vitesse

Même avec la mise en place des évaluations des risques mentionnées ci-dessus, des vulnérabilités vont survenir. C'est un fait que nous devons accepter. La question est de savoir comment nous pouvons gérer plus efficacement la situation lorsqu'elle se produit, et non comment nous pouvons l'empêcher complètement.

À cette fin, la visibilité est primordiale. De nombreuses entreprises ont du mal à appliquer des correctifs car elles ne savent pas quelles machines sont impactées en premier lieu. Les entreprises doivent mettre en place des systèmes qui offrent une visibilité sur ce qui s'exécute dans les centres de données et le cloud.

Plus la visibilité est complète et précise, plus une entreprise peut agir rapidement et corriger les ressources nécessaires.

4. Filtrer les évidences

De nombreuses vulnérabilités ne peuvent être exploitées que par le biais d'une chaîne de failles de sécurité. Éliminer n'importe quelle partie de la chaîne suffit souvent à empêcher une exploitation complète. Par conséquent, les systèmes qui filtrent les attaques antérieures et évidentes sont essentiels.

Les entreprises doivent privilégier les systèmes suivants :

  • Plateformes de protection des terminaux (EPP)
Protégez les terminaux contre les logiciels malveillants connus.
  • Web Application Firewalls (WAF)

Protégez les applications Web contre les charges utiles malveillantes et les acteurs de menace connus. Optez pour Kona, la meilleure protection d'Akamai.
  • Pare-feu DNS

Empêchez les terminaux d'accéder à des domaines malveillants et excluez les charges utiles DNS malveillantes. Optez pour la solution Akamai Enterprise Threat Protection.
  • Passerelle Web sécurisée (SWG)

Empêchez les terminaux de télécharger et de consulter des programmes et des sites malveillants sur Internet. Optez pour la solution Akamai Enterprise Threat Protection.
  • Authentification multifactorielle (MFA)

Réduisez le risque de vol d'informations d'identification permettant d'accéder à votre entreprise et d'y introduire une chaîne de failles de sécurité. Optez pour la solution Akamai MFA.
  • Segmentation basée sur l'identité

Limitez la capacité des logiciels et des systèmes pour qu'ils communiquent uniquement avec les machines nécessaires à l'exécution de leurs tâches. Optez pour Akamai Guardicore Segmentation.
  • Accès réseau Zero Trust (ZTNA)

Limitez l'impact des utilisateurs infectés entrant sur le réseau. Optez pour Akamai Enterprise Application Access.

5. Le principe du moindre privilège règne en maître

Pour terminer, les entreprises devraient adopter pleinement le principe du moindre privilège. Verrouillez les serveurs, les machines et les logiciels afin qu'ils interagissent uniquement avec les systèmes requis pour effectuer leurs tâches.

Par exemple, de nombreux systèmes qui passent des appels LDAP sortants dans le cadre de l'exploitation Log4j n'ont jamais eu besoin d'utiliser LDAP. Ces systèmes doivent disposer d'un accès à LDAP avec pare-feu.  Voici un autre exemple : si un service ne répond qu'aux demandes entrantes, bloquez les connexions sortantes.

En appliquant le principe du moindre privilège à tous les systèmes et logiciels que vous contrôlez, vous pouvez réduire considérablement la surface de menace lorsqu'une vulnérabilité survient et, dans de nombreux cas, arrêter la chaîne d'attaques avant qu'elle ne vous affecte.

En savoir plus

Merci de m'avoir accompagné dans cette série de publications. Bien qu'elle se termine ici, nos recherches et la protection des clients contre les vulnérabilités se poursuivent. N'hésitez pas à contacter votre interlocuteur Akamai si vous souhaitez en savoir plus sur nos recommandations pour l'atténuation de Log4j et d'autres menaces.

 



Charlie Gero

Written by

Charlie Gero

January 13, 2022

Charlie Gero est vice-président & CTO de la division Enterprise d'Akamai et dirige le groupe Projets avancés. Il se concentre actuellement sur la recherche de pointe dans les domaines de la sécurité, des mathématiques appliquées, de la cryptographie et des algorithmes distribués, afin de mettre au point la prochaine génération de technologies qui protégeront la clientèle croissante d'Akamai. Grâce à ses recherches au sein d'Akamai, il a obtenu près de 30 brevets dans les domaines de la cryptographie, de la compression, des systèmes de réseau performants, de la diffusion multimédia en temps réel, etc. Il travaille chez Akamai depuis près de 15 ans, après avoir fondé une start-up et occupé des postes clés en informatique dans le secteur pharmaceutique et le domaine des réseaux.