MtoM Mag - Le journal de l'MtoM.

Dès qu’un chercheur ou éditeur découvre une faille sur un produit, celle-ci est publiée via des canaux publics, dans le but d’informer tous les possesseurs de ce produit qu’ils sont à risque, et, en général, de proposer une remédiation.

À première vue, une bonne façon de gérer les vulnérabilités d’un parc informatique pourrait alors être de manière déclarative : Sur base d’un inventaire fiable des équipements, applications et systèmes d’exploitation composant un Système d’Information (SI), une veille autour des différents canaux de communication cyber pourrait permettre d’être alerté en cas de faille. Mais cela n’est pas suffisant pour assurer une détection complète des vulnérabilités, et ce pour plusieurs raisons.

Dans un premier temps, il est très rare de posséder un inventaire fiable à 100 % de tous les éléments d’un SI. Autant les postes de travail et serveurs sont assez bien recensés, autant les applications hébergées en Cloud, en SaaS ou encore les API exposées pour des besoins business et métier le sont moins. Tant d’éléments qui pourraient donc comporter des failles critiques. Aussi, cette gestion « déclarative » ne permettrait pas de détecter certains types de failles, tels que les ports réseaux ouverts, une mauvaise configuration de la couche système, des certificats de sécurité expirés…

Il est donc nécessaire de compléter une veille proactive par une gestion de vulnérabilités par la détection, à l’aide d’outils de scan

Leur principe global est de tester, sur une cible donnée, tout ce qui est visible d’un point de vue système, réseau et applicatif, afin d’y découvrir des potentielles failles. La veille déclarative n’en reste pas moins nécessaire car celle-ci permet, en cas de failles critiques, d’être informé plus rapidement que via des scans qui sont effectués de manière périodique.

La première étape dans une gestion efficace des vulnérabilités est donc d’identifier chaque élément du SI, et pas seulement ceux qui sont gérés par l’équipe informatique. À l’ère du cloud et des déploiements automatisés, cette tâche n’est pas forcément aisée. Les environnements exposés sur Internet (applications ou sites web, notamment) sont souvent des éléments assez peu maîtrisés, bien que parmi les plus critiques au vu de leur accessibilité. C’est pourquoi certaines solutions de scan de découverte existent, proposant notamment des scans basés sur des noms de domaines DNS pour les éléments exposés ou des scans de réseau IP pour les environnements on-premise. Des processus doivent également être mis en place pour intégrer les nouveaux déploiements à la gestion de vulnérabilités.

Une fois les éléments recensés, il faut se poser la question de la manière dont les scans actifs vont être réalisés. Plusieurs méthodes existent, qui sont à adapter selon la cible à scanner. Pour tout ce qui est connecté à un réseau IP, un scan primordial à effectuer est celui via le réseau, sans donner plus d’informations au scanner, que l’adresse IP ou le nom d’hôte de sa cible. Ce type de scan, que l’on pourrait qualifier de blackbox, permet d’avoir une vision de ce qu’un potentiel intrus, dans le SI, pourrait réussir à obtenir. Selon les équipements, il est souvent possible de récupérer de nombreuses informations sur la cible : système d’exploitation, version de celui-ci, applications hébergées sur certains ports… Cette première vision n’est donc pas à négliger.

Un deuxième point de vue complémentaire est de fournir au scanner des éléments d’identification sur la cible, afin qu’il puisse jouer une authentification sur celles-ci et aller plus loin dans la collecte d’information et les tests de vulnérabilités. Par exemple, la plupart des solutions de scan de vulnérabilités sont capables d’utiliser des protocoles tels que SSH (machines Linux et équipements réseau), RDP (machines Windows), SMB, HTTPS (pour les éléments utilisant une interface web) ou encore de s’interfacer avec des équipement de type bastion, ou coffre-fort de mot de passe. Par rapport aux privilèges du compte utilisé pour l’authentification, plus celui-ci à des droits élevés plus il apportera de visibilité sur la cible. Toutefois, selon les contextes, il n’est parfois pas possible d’utiliser un compte avec un niveau de droit élevé (root sur Linux ou NT AUTHORITY\SYSTEM sur Windows). C’est pourquoi certaines solutions peuvent également utiliser des agents, pour effectuer ces scans. Déployé manuellement ou via un outil de télédéploiement, le rôle de l’agent est d’apporter une vue exhaustive sur les applications et configurations système de la machine, et de remonter ces informations au scanner de vulnérabilités. Cependant, l’agent ne sera généralement pas capable d’identifier des failles réseau sur la machine, car il n’a pas de point de vue extérieur à celle-ci. Il est donc nécessaire de compléter la vision par un scan de type blackbox.

On comprend donc assez aisément que l’emplacement du scanner, physique ou virtuel, est un élément crucial de l’architecture d’une solution de gestion de vulnérabilités. Plus il est proche des cibles, plus il pourra récupérer d’informations sur celles-ci. Des notions de filtrage réseau et d’occupation des liens inter-sites sont aussi à prendre en compte. C’est pourquoi, il est souvent nécessaire de déployer plusieurs scanners, un par site physique ou par SI de criticité différente par exemple. Ces différents scanners peuvent ensuite être rattachés à une seule et même console, permettant de les piloter et de rassembler les différentes vulnérabilités sous forme de rapports, d’alertes et de tableaux de bord. Dans les cas où différentes solutions de scan sont utilisées, des agrégateurs de vulnérabilités existent, permettant également d’y intégrer des résultats d’audits offensifs.

Une fois les données sur les vulnérabilités existantes, celles-ci doivent être exploitées de plusieurs manières

La première recommandation est d’inclure les équipes métier dans les procédures de remédiation, car elles ont la connaissance de l’applicatif et de ses différentes contraintes. Les équipes sécurité doivent l’être également, car elles sont en général sollicitées pour évaluer l’impact d’une vulnérabilité vis-à-vis du contexte ou pour émettre des acceptations de risque. Le volet processus est, ainsi, très important dans un projet de gestion de vulnérabilités, au même titre que le volet technique.

Une deuxième recommandation est d’utiliser les différents scores émis par l’outil pour intégrer une notion de criticité ou sensibilité sur une machine ou un équipement. Cela peut être accompli au sein d’un logiciel de type CMDB (inventaire) ou d’un SIEM (System Information and Event Management). Un événement de sécurité détecté sur une machine pourrait, par exemple, être d’une sévérité plus importante s’il est connu que cette machine présente des vulnérabilités critiques.

Une gestion de vulnérabilités efficace permet donc de détecter les failles, les agréger et piloter leur remédiation afin d’assurer une maîtrise des éléments à risque du SI. En revanche, elle ne permet évidemment pas de se prémunir contre les failles « 0-day », qui, par définition, ne sont pas encore publiées, et ne peuvent alors pas être détectées par les scanners. Il est donc nécessaire de protéger le parc avec d’autres éléments de sécurité, tels que des EDR (Endpoint Detection and Response) ou leurs pendants sur le réseau, les NDR (Network Detection and Response).

https://www.synetis.com/