la course aux mises à jour de sécurité

Que l’on soit simple utilisateur de son ordinateur à la maison (OS Apple, Linux ou Microsoft), de son téléphone portable ou tablette (iPhone, iPad, Samsung Galaxy...), ou responsable d’un SI d’entreprise (infrastructure ESX, équipements réseau ou sécurité...), nous sommes confrontés au besoin de mettre à jour nos équipements… Mais pour quoi faire, si je n’ai pas de nouvelles fonctionnalités ? Tout simplement pour des besoins de sécurité.

En effet, avoir un équipement à jour (aussi bien au niveau OS que Firmware) est important car cela permet de se protéger contre les attaques visant des vulnérabilités connues.

petit rappel sur la vie d’une vulnérabilité

T0 : une vulnérabilité est découverte par un individu, elle est plus ou moins critique mais n’est pas encore dévoilée au grand jour. A cette étape, si elle est exploitée, elle permettra de faire une attaque de type 0 Day, cependant une bonne expertise est indispensable pour exploiter ce type de faille (pas de toolkits).

T1 : la vulnérabilité est publiée, soit par l’éditeur, soit par des sociétés ou communautés externes, avec une communication sur les différentes versions impactées.

T2 : à cet instant, plusieurs étapes indépendantes :

• L’éditeur va proposer une version corrective ou un patch de mise à jour afin de corriger la vulnérabilité (dans le meilleur des cas).
• Certaines vulnérabilités sont facilement exploitable, des articles sont mis en ligne sur les différents forums spécialisés (parfois même en mode pas à pas).
• Des toolkits sont publiés pour exploiter facilement la vulnérabilité.

T3 : la mise à jour (ou le correctif) est appliqué, la vulnérabilité n’est plus exploitable.

évaluation de la vulnérabilité

En parallèle, il y a la gestion de cette vulnérabilité, deux éléments sont important à déterminer : l’impact et la probabilité. Nous pouvons définir une matrice en fonction de ces deux éléments :

1. Si l’impact est faible, et la probabilité faible (vulnérabilité difficile à exploiter dans son environnement), nous pouvons choisir de ne pas mettre à jour.
2. Si l’impact est faible, et la probabilité forte (par exemple sur un serveur Web en frontal sur Internet), il faut regarder les enjeux sur une éventuelle exploitation de la vulnérabilité (est-ce que j’ai des informations confidentielles ? nominatives ?) et choisir s’il faut corriger ou prendre un risque.
3. Si l’impact est fort (arrêt du service, récupération d’informations…), et la probabilité faible, là aussi il faut regarder en fonction des enjeux.
4. Si l’impact est fort et la probabilité forte, la situation est critique, un  plan d’action doit être mis en place rapidement pour corriger la vulnérabilité.

Nous pouvons voir ici qu’une vulnérabilité devient très critique lorsque l’impact est fort (perte de production, récupération d’informations sensibles…) et qu’elle a une forte probabilité d’être exploitée, par exemple si des toolkits d’attaque existent, ou si la vulnérabilité est facilement exploitable.

Avec des toolkits, des attaques pourront être réalisées par un grand nombre de personnes et de manière non ciblée car on utilise des outils « clé en main » . Cela devient tellement facile que l’on peut attaquer tout le monde via des robots, surtout si l’exploitation de cette vulnérabilité est intéressante comme par exemple pour installer un Trojan… Parfois, même sur des vulnérabilités avec de forts impacts, le toolkit est disponible avant la mise à disposition de la mise à jour par l’éditeur… Il faut également savoir que les toolkits utilisent très souvent plusieurs vulnérabilités pour avoir une plus grande force de frappe (plusieurs vulnérabilités avec un faible impact initial mais une probabilité forte peuvent devenir très critiques).

les solutions

Cependant sur un environnement de production, cela est plus complexe. En effet, il faut faire une validation sur la mise en place de cette mise à jour ou correctif, et s’assurer qu’il n’y ait pas d’impact fonctionnel sur l’application elle-même, mais également sur l’éco-système, puis mettre en place des procédures pour la mise à jour. Cela peut prendre plusieurs semaines si ce n’est pas clairement défini via des processus déjà établis et rodés. Parfois même la mise en place d’un correctif ou d’une mise à jour représente un plus gros risque sur la production que l’exploitation potentielle de la vulnérabilité.

Maintenant si cette vulnérabilité a un impact critique et que l’on ne peut pas mettre à jour (correctif pas encore fourni, impact important lors de la mise à jour…), ou que l’on a pas les équipes ou process pour corriger rapidement… Il reste quelques possibilités, qui sont de plus applicables avant même que l’éditeur sorte le correctif (à T1) :

• Prier, croiser les doigts, courir en criant dans tous les sens… ne rien faire…
• Mettre en place des Work-around (solutions de contournement) pour éviter d’exploiter la vulnérabilité (ACLs par exemple)
• Sortir du placard son IPS/IDS et définir «  la signature » de l’exploitation de la vulnérabilité (souvent communiquée par les éditeurs spécialisés, ou via des regex personnalisables) pour protéger ses équipements vulnérables. Si l'IPS/IDS est déjà en place, vérifier que sa base de signature a été mise à jour avec la signature concernée.
• Utiliser des solutions de virtual-patching (très à la mode, et sans doute une vraie réponse sur de grosses infrastructures, type Cloud Computing) pour bloquer l’exploitation de la vulnérabillité dans l’attente de la correction sur l’équipement.

Quoiqu’il en soit, le plus important est d’avoir une bonne vision de son parc existant et de son contexte, avec les différentes vulnérabilités (corrigées ou non), d’estimer régulièrement les risques associés à ces vulnérabilités (via des analyses de risque) et de mettre en place un plan d’action pour réduire ces risques.

Guillaume

Crédit photo : © Thomas Jansa & © cherezoff - Fotolia.com