Pourquoi la découverte des actifs IT constitue la base d'un programme RBVM (Gestion des vulnérabilités basée sur les risques)
Sachant que l'on connaît actuellement plus de 236 000 vulnérabilités au total (et que l'on ajoute en moyenne 61 nouvelles vulnérabilités par jour à la base NVD), il est tout simplement impossible de remédier à chaque CVE ou vecteur de menace lorsqu'il apparaît. Alors, comment les entreprises gèrent-elles au quotidien ces menaces toujours plus nombreuses qui visent leurs utilisateurs finaux, leurs clients et leurs données… surtout dans un Everywhere Workplace de plus en plus hybride et distant ?
Tout d'abord et avant tout, il est essentiel de cartographier votre surface de risques. Pour cela, vous devez connaître les actifs connectés à votre réseau à tout moment. Nous avons demandé à deux experts (John J. Masserini, Senior Security Analyst chez TAG Cyber, et Chris Goetl, Vice President of Security Product Management chez Ivanti) leur méthode pour identifier les facteurs de cyber-risques propres à l'entreprise afin de prioriser les vulnérabilités.
Ci-dessous, découvrez un extrait de leur conversation. Pour écouter toute la discussion et connaître les meilleures pratiques pour les programmes RBVM en environnement réel, consultez l'enregistrement du webinar.
Découvrez tous les postes client de votre réseau (y compris ceux qui sont inconnus)
Chris Goettl : Je pense que tout le monde possède des structures de sécurité sur lesquelles on s’appuie pour comprendre et développer notre feuille de route de cybersécurité. Si vous regardez les principales structures de cybersécurité (NIST, CIS ou autre selon votre région), vous savez, les gros du cyber, le top 20 de l'ASD… elles comportent toutes un élément de découverte et de gestion des actifs. Et cela pour une raison simple, si l'on ne connaît pas ce qui constitue notre environnement, on ne peut pas le sécuriser. Ainsi, la découverte est un élément fondamental de tout programme de sécurité, qu'elle soit active ou passive, elle permet de se connecter à plusieurs sources de données et à réellement réunir un grand nombre d'informations concernant votre environnement.
Ivanti offre de nombreuses fonctions de découverte. Nos échanges avec nos clients comme nos enquêtes de sécurité ont montré que la plupart des entreprises ont une lacune d'environ 20-30 % dans leur compréhension de tous les périphériques réellement gérés dans leur environnement.
Donc, si l'on considère six ou sept points de données dans tout votre environnement (comme la solution de gestion des terminaux, la solution de gestion des actifs, votre solution de protection du poste client…), qu'il s'agisse d'EDR ou d'une plateforme quelconque de protection contre les menaces, chacun va correspondre à plusieurs machines gérées. Comparez ça avec les données de votre équipe Approvisionnement, et je vous garantis qu’avec toutes ces sources de données différentes, vous allez voir des pourcentages à deux chiffres de machines gérées par une source, mais pas par les autres. Si bien que jusqu'à 30 % de mon environnement est invisible à mes yeux dans l'une de mes sources de données.
L'une des principales raisons qui font de ce constat la base et les fondations de ces structures de cybersécurité, c'est que nous avons absolument besoin de voir ces près de 30 % d'angles morts dans notre environnement. Parce que si nous sommes incapables de les voir, les pirates eux les verront à coup sûr.
Pourquoi les périphériques IoT inconnus présentent un danger pour votre environnement IT
Chris Goettl : Plusieurs choses doivent vous inquiéter. D'abord, s'il existe une vulnérabilité sur ce périphérique. J'ai déjà vu des ampoules connectées utilisées pour des ataques DDoS à grande échelle. C'est juste un exemple, qui montre qu'un périphérique IoT totalement anodin peut devenir une menace et participer à une ataque à bien plus grande échelle.
Il peut exister un défaut sur ce périphérique, qui permetra à quelqu'un de le forcer à distance à passer à un état où les composants chauffants sont allumés et le restent, ce qui peut provoquer un incendie. Ce type de périphérique peut être utilisé contre nous d’une multitude de façons.
Récemment, il y a eu un problème avec des périphériques IoT du domaine médical. Ces robots se trouvent dans les hôpitaux, et il est possible de les déplacer pour aider le personnel à réaliser différentes tâches, qu'il s'agisse de transporter les équipements nécessaires pour soigner un patient, de livrer quelque chose au labo, etc. Dans ces périphériques, on a découvert un jeu de vulnérabilités qui permetait à quelqu'un d'écouter les conversations des personnes à proximité de l’appareil. Il était également possible de forcer ces périphériques à s'arrêter, et ils sont assez volumineux pour bloquer une porte. Sur un site médical, bloquer une entrée importante et forcer le périphérique à se verrouiller, devenant ainsi un obstacle, peut aussi causer des dégâts.
Tous ces périphériques, aussi insignifiants soient-ils, présentent potentiellement un risque pour l'environnement. Dans notre cas, c'est là que la découverte a détecté un périphérique qui doit se trouver là, mais doit être coupé du réseau parce qu'il n'est pas gérable du point de vue… peut-on lui appliquer un correctif ? Hélas, pas vraiment. Il peut recevoir des mises à jour de firmware, mais c'est un équipement qui ne va pas recevoir ce niveau de gestion. Isolez ces périphériques, mais assurez-vous de bien comprendre ce qui se trouve dans votre environnement et ce qui peut être utilisé contre vous.
Comment les informations d'actif permetent de prioriser l'application des correctifs
John Masserini : Comprendre ce qui est présent, c'est en quelque sorte la base pour construire un programme de gestion des vulnérabilités. Mais je dirais que l'étape suivante, c'est de vraiment maîtriser l'importance de ces périphériques notamment pour les flux de revenus de l'entreprise.
Quand on examine ce à quoi l'on applique des correctifs, comment on les applique, quel que soit le programme, tout dépend des coupures qu'on peut se permetre, du niveau de profits généré par le périphérique ou le flux de périphériques concerné, et de comment gérer les coupures ou de qui va assumer le risque si l'on choisit de ne pas éliminer les vulnérabilités ? Alors, je pense vraiment que comprendre à quel point ces périphériques sont critiques pour les activités de l'entreprise est un élément majeur dans toute évaluation des risques. Quand on parle de gestion des vulnérabilités basée sur les risques, il est essentiel de comprendre comment gérer ces risques pour chaque périphérique et chaque flux de travail.
J'ai toujours utilisé pour cela un programme PCA (plan de continuité des activités). La réalisation d'une analyse d'impact commercial, indispensable pour un programme de continuité des activités, est aussi précieuse pour un programme de gestion des vulnérabilités, car elle permet de comprendre les risques que présente une application, un environnement, etc. L'analyse d'impact est incroyablement intéressante pour l'entreprise, et capitale pour son département IT.
Chaque fois que vous arrivez dans une entreprise, vous entendez : « On veut des réponses immédiates. On ne veut aucune interruption et on veut garantir la satisfaction des clients. » Ce genre de choses. Et vous dites : « OK, voilà ce que ça va vous coûter. » Et on vous répond « Eh, oh, oh, on n'est pas si riches ! » Donc, vous passez rapidement à la discussion sur « quelle est la norme minimale acceptable pour ça ? » Combien êtes-vous prêts à… disons… on peut se permetre une coupure de deux heures entre 2 et 4 heures du matin un vendredi sur deux, ou un arrangement de ce type. Et il faut bien comprendre que cela impacte 80 % du chiffre d'affaires de l'entreprise, il faut vraiment y être sensible. On déploie peut-être les correctifs tous les trimestres, mais on applique certainement un autre niveau de tests pour les correctifs des environnements de genre, par rapport à un site interne qu'on utilise seulement pour partager des mèmes, par exemple.
Il existe en fait une différence fondamentale de criticité pour les différents périphériques de notre infrastructure, qu'il faut vraiment évaluer et mesurer pour s'assurer que notre analyse des risques est correcte.
Un grand nombre de ces éléments, croyez-le ou non, sont des éléments traditionnels. Vous pouvez exécuter d'anciens mainframes, utiliser des AS/400, ou bien avoir des périphériques tout neufs, mais où la vulnérabilité doit être corrigée via le Flash d'un nouveau firmware au lieu d'un simple déploiement de correctifs vers une bibliothèque. De nombreux modèles existent, ils constituent des éléments très différents d'une analyse des risques très différente. L'application d'un correctif à une application, si ça concerne Chrome sur un ordinateur portable Windows, présente un profil de risque très différent que si vous dites : « OK, je vais accéder à ce routeur critique et faire un Flash du firmware pendant la nuit. » Les risques sont juste totalement différents.
C'est pourquoi la compréhension de tous les éléments qui interagissent, d'après moi, tient à la fois de la découverte des actifs et de l'analyse des risques découlant de l'analyse d'impact. Je pense que toutes deux constituent des bases phénoménales pour construire une stratégie à long terme, quelle qu'elle soit, en matière de gestion des vulnérabilités basée sur les risques.
Connaître l’intégralité de votre réseau, c'est la première étape pour comprendre comment prioriser vos efforts de sécurité. En adoptant une approche basée sur les risques pour votre gestion des vulnérabilités, vous vous assurez de cibler les maillons faibles… et la découverte des actifs vous permet de tous les identifier, même ceux qui sont cachés.
Continuez à découvrir les meilleures pratiques des programmes RBVM en environnement réel, en visionnant le reste de cette discussion.