CyberArk, spécialiste de la protection des identités, indique comment se prémunir en 6 étapes de cette vulnérabilité qui frappe la librairie Java Log4J.
Il y a quelques jours déjà, une vulnérabilité de sécurité critique d’une bibliothèque de développement de logiciels open source largement utilisée appelée Log4j (ou Log4Shell) a été publiée dans CVE-2021-44228. Cette faille a le potentiel de provoquer l’exfiltration de données et/ou l’exécution de code à distance sur les serveurs utilisant ce composant pour les fonctionnalités du journal d’évènements.
CyberArk liste 6 étapes pour s’en protéger :
- Appliquer les patchs
Si vous ne l’avez pas déjà fait, prenez des mesures immédiates pour appliquer la mise à jour logicielle déjà publiée par Apache dans Log4j. Il est également important d’examiner les recommandations et les mises à jour des fournisseurs pour toutes les plateformes logicielles d’entreprise utilisées, ainsi que les intégrations de système d’exploitation et d’entreprise sous-jacentes. Vérifiez auprès de tous vos fournisseurs tiers qu’ils ont également corrigé le logiciel que vous utilisez.
- Déployer des défenses périphériques
Appliquez des règles WAF pour atténuer les tentatives d’exploitation courantes dans le cadre d’une stratégie complète de défense en profondeur.
- Protéger les identifiants fournis aux serveurs
Limitez l’accès aux variables d’environnement et aux informations d’identification locales afin de minimiser les risques immédiats posés par les attaquants opportunistes.
- Sécuriser les actifs de niveau 0
Restreignez l’accès à ces actifs de niveau 0
- Implémenter le moindre privilège pour les services et utilisateurs
Cette étape est essentielle pour atténuer le risque d’une attaque ciblée. Restreindre l’accès au niveau minimum requis – et le supprimer dès qu’il n’est pas nécessaire – peut fortement ralentir ou arrêter la progression d’un attaquant en empêchant les mouvements latéraux et, finalement, en minimisant le rayon de l’explosion (ou l’impact global).
- Permettre l’identification multi-facteurs lorsque c’est possible
Les attaquants ont beaucoup plus de chances de réussir lorsqu’ils n’ont pas à fournir un deuxième facteur d’authentification ou un autre élément d’approbation pour insérer leur code. C’est donc toujours une bonne pratique.