Recherche

Vulnérabilités logicielles : bonnes pratiques pour les identifier et les corriger

Les vulnérabilités logicielles sont inévitables. Pour y remédier, il convient d'appliquer des correctifs dans les meilleurs délais, ce qui est malheureusement plus facile à dire qu'à faire.

Publié par le | Mis à jour le
Lecture
6 min
  • Imprimer
Vulnérabilités logicielles : bonnes pratiques pour les identifier et les corriger

Pour les responsables informatique, les blocages peuvent être multiples : le système d'exploitation ou le logiciel en question n'est plus pris en charge par le support, le logiciel installé n'était pas connu et contenait des vulnérabilités. Il se peut aussi que les priorités opérationnelles business fixées par l'entreprise empêchent d'appliquer rapidement les correctifs, d'où la nécessité de mesures d'atténuation à court terme.

Des bonnes pratiques incontournables

Comme toujours, il est important de suivre les bonnes pratiques, par exemple définir une configuration standard et supprimer, autant que possible les privilèges utilisateur afin d'éviter le chargement de logiciels inconnus. Le recours à l'authentification à deux facteurs pour les connexions administrateur, l'attribution aux administrateurs de comptes utilisateur à plus faibles privilèges pour les tâches non administratives, le zonage des réseaux, la surveillance interne, etc., permettent de limiter les risques de vulnérabilités inconnues et l'impact que pourrait avoir leur exploitation.

Bien identifier ses actifs pour mieux détecter leurs vulnérabilités !

Ces mesures de base étant posées, la prochaine étape consiste à dresser la liste de ses actifs, avec les vulnérabilités connues qu'ils présentent. Il est important d'y inclure les protocoles exposés (Web, PHP, SQL et autres services d'entreprise).
Parmi les approches possibles, il est possible de procéder à l'évaluation manuelle à partir de la liste des actifs, et des logiciels installés, en s'appuyant sur des ressources Internet telles que des bases de données CVE (Common Vulnerabilities and Exposures) et des WARP (Warning, Advice and Reporting Point) pour identifier les vulnérabilités.
Bien que cette méthode n'entraîne pas de dépenses d'investissement, sa mise en oeuvre demandera d'importants efforts et elle sera probablement moins précise que des approches assistées par des outils.

Des outils ou services d'identification des vulnérabilités, déployés en interne ou sous forme de service, permettront d'analyser les actifs, d'identifier les éléments installés et de détecter les vulnérabilités présentes dans un large éventail de logiciels.
Des outils en Open Source sont disponibles pour les entreprises au budget serré, ainsi que des solutions commerciales, mais leur exploitation n'en exige pas moins une charge de travail supplémentaire.

L'analyse des vulnérabilités n'est pas une opération ponctuelle. Elle doit être effectuée régulièrement, ce qui explique la popularité croissante des services d'analyse des vulnérabilités, notamment de type Cloud. Toutefois, s'ils sont moins onéreux, et sont capables d'identifier les vulnérabilités les plus récentes et les correctifs correspondants, nombre de services Cloud couvrent uniquement les actifs connectés à Internet.

Le problème avec les approches d'analyse est que, même si elles incluent la détection de vulnérabilités génériques, la plupart d'entre elles ne prennent pas en charge les vulnérabilités inconnues.

La détection de menaces de type « zero-day » peut se révéler difficile, voire inutile, dans la majorité des cas. En revanche, elle revêt une importance capitale dès lors que l'on utilise un logiciel maison, en particulier une base de données en backend pour un site Web.
Les principaux risques encourus sont le Cross-Site Scripting, le Cross-Site Request Forgery et les injections SQL dans le code custom.

Seuls un examen du code ou un test d'intrusion permettent de détecter les failles. Dans l'idéal, ces opérations doivent faire partie intégrante du processus de développement et être exécutées par un testeur d'intrusions indépendant.

Sur ce point, la vigilance est de mise. Lorsque l'on décide de faire appel à un prestataire externe pour les activités de développement, il est important de s'assurer qu'il est responsable de la correction de toutes les vulnérabilités identifiées lors des tests d'intrusion. Il sera ainsi plus enclin à produire d'emblée un code exempt de problèmes. Les tests d'intrusion peuvent également servir à identifier d'autres vulnérabilités, mais en raison de leur coût élevé, il est préférable de les réserver aux aspects spécifiques de ses systèmes indétectables par d'autres méthodes.

Limiter les risques à défaut de pouvoir corriger ou éliminer toutes les vulnérabilités

Une fois qu'un maximum de vulnérabilités aura été identifié, corrigé ou éliminé, il en restera probablement certaines dont il faudra limiter les risques. Ceci est généralement possible à l'aide de fonctions existantes conçues pour détecter les attaques, de réduire leurs effets ou empêcher les attaquants d'exploiter les vulnérabilités.

L'exemple le plus simple que nous avons pu d'observer concernait une machine Windows XP utilisée pour un système de contrôle d'accès physique. Comme l'obsolescence de XP rendait impossible la mise à jour du système d'exploitation, la solution a été de déconnecter l'ordinateur du réseau afin d'en limiter l'accès physique aux deux seuls utilisateurs chargés d'assurer sa maintenance.

La technique bien connue du « Pass-the-Hash » est un problème plus complexe. Dans ce cas de figure, l'attaquant accède à la valeur de hachage des mots de passe et s'en sert pour accéder à d'autres machines, généralement via des comptes administrateur locaux. Même s'il est plus difficile de se procurer les valeurs de hachage dans les versions récentes de Windows, il est toujours possible d'utiliser des outils d'attaque courants pour s'emparer des valeurs de hachage stockées dans la mémoire des applications à authentification unique (SSO, Single Sign-On). Il convient donc de réduire l'impact de telles attaques en limitant l'accès et en réduisant les privilèges.

Comme indiqué précédemment, la mise en oeuvre de bonnes pratiques et la désactivation des comptes administrateur locaux permettent d'y parvenir. (Au besoin, il est possible de continuer à bénéficier d'un accès administrateur en démarrant en mode sans échec.) L'accès est ainsi restreint à un seul utilisateur doté de faibles privilèges.

Autre exemple, le ransomware WannaCry, qui a tiré parti de la vulnérabilité EternalBlue pour se propager. Des correctifs étaient certes disponibles pour cette faille, mais ils ne couvraient pas les anciennes versions des systèmes d'exploitation ou n'avaient pas été installés.
Pour atténuer les risques, des signatures IPS ont été développées et déployées par des prestataires de services gérés dans les heures qui ont suivi l'attaque. Elles ont permis de bloquer l'activité réseau d'EternalBlue.
Si ce procédé n'a pas stoppé la livraison initiale de WannaCry via les e-mails de phishing, il a empêché le ransomware de se propager sur le réseau local.

Ces techniques d'atténuation exigent le plus souvent la configuration d'outils déjà en place (système de détection des intrusions, pare-feu, journalisation, SIEM, etc.), mais aussi parfois la reconfiguration du réseau ou la mise en oeuvre d'outils supplémentaires. De plus, elles assurent une protection contre la vulnérabilité générale et non contre une attaque spécifique.
Par exemple, les signatures IPS pour WannaCry permettent de se prémunir contre toutes les attaques utilisant EternalBlue.

Pour résumer, la protection contre les vulnérabilités ne demande généralement pas d'investissements majeurs en logiciels ou en équipements. Bien qu'elle nécessite la mise en place d'une équipe opérationnelle dotée des compétences requises pour développer et appliquer des mesures d'atténuation, la portée de celles-ci s'étend souvent au-delà du cadre des vulnérabilités spécifiques à traiter.

Paddy Francis, CTO - Airbus CyberSecurity.

Livres Blancs #cloud

Voir tous les livres blancs
S'abonner
au magazine
Se connecter
Retour haut de page