Les professionnels de l'informatique sont aujourd'hui submergés d'annonces de vulnérabilités. La plupart du temps, il s'agit de produits que l'on n'utilise pas soi-même. Ou alors le produit est en service mais, en raison d'un rebranding du fabricant, il porte encore un ancien nom, ce qui entraîne une certaine confusion et un surcroît de travail de clarification. Outre la compréhension de la manière dont la faille est exploitée et de la forme que pourrait prendre une attaque, le responsable de la sécurité doit savoir quels produits sont actuellement utilisés. Cela devrait être visible dans unebase de données de gestion de la configuration (CMDB).Attention : un outil de gestion des vulnérabilités ne remplace pas un véritable outil de gestion des actifs. Un outil de gestion des vulnérabilités offre des interfaces avec de telles CMDB. Tenable lui-même propose de nombreuses aides à l'intégration.
La difficulté ne réside toutefois pas dans l'implémentation de l'outil, mais dans le fait d'établir le processus de gestion des vulnérabilités dans l'entreprise et de lui donner vie.
1. les systèmes IT classiques, serveurs sur site, commutateurs, clients ou autres.
2. systèmes OT
3. les actifs hybrides, les serveurs d'applications, par ex. les systèmes de base de données, les systèmes ERM / ERP ou autres.
4. actifs cloud ; IaaS, PaaS, SaaS.
5. actifs privés ; BYOD, par exemple : smartphone avec connexion au calendrier-mail, ordinateurs portables privés (VPN ou Terminal Server Access).
Pour ces cinq types, les responsabilités, les normes de sécurité et les parties prenantes sont différentes. La gestion des vulnérabilités doit donc être comprise comme un processus défini, connu et vécu dans toute l'entreprise.
"Know Your Assets" est plus qu'un simple mantra que les responsables informatiques peuvent réciter. Une gestion des vulnérabilités qui fonctionne signifie aussi savoir quels systèmes sont utilisés, quelles données sont conservées où et surtout qui s'en occupe. Tout cela est ensuite enregistré dans uneCMDB (Configuration Management Database). Dans le meilleur des cas, cette base est liée à un outil de gestion des vulnérabilités. Malheureusement, l'exploitation d'une CMDB est coûteuse et il n'y a que rarement un service qui vérifie dans quelle mesure les informations contenues dans cette base de données sont actuelles et disponibles.
Dans le meilleur des cas, les vulnérabilités sont rapidement identifiées grâce à des scans réguliers et transmises au moyen d'un outil de ticketing. C'est à partir de là que le véritable travail commence :
Toutes ces tâches ne peuvent pas être automatisées. Ici, il faut toujours une composante humaine - même s'il ne s'agit que de poser des questions à l'administrateur système.
Les vulnérabilités publiées ont généralement ce que l'on appelle unscore CVSS(Common Vulnerability Scoring System), qui indique leur dangerosité. Ce score est divisé en trois sous-catégories : Base, Temporal etEnvironmental.
Le score met l'accent sur la vulnérabilité et n'est pas applicable à chaque entreprise. Il est donc important de tenir compte de son propre "environnement". Qui a accès - le public, les clients, les collaborateurs ? De quoi a-t-on besoin pour l'exploiter ? Réseau, accès physique, utilisateurs locaux ? L'exemple suivant permet d'illustrer ce point.
"Si un système est accessible via le réseau, il est plus vulnérable que s'il se trouve dans un sous-sol fermé à clé et séparé du réseau".
Il est donc important de connaître ses actifs. Souvent, une faille est connue, discutée à chaud dans les médias et patchée à la hâte. Cette procédure précipitée comporte souvent des risques pour l'entreprise et peut nuire à la réputation de la VM. Respectez vos processus.
Tenable a défini à cet effet leVPR (Vulnerability Priority Rating), en abrégé une évaluation automatisée de la situation qui évalue la vulnérabilité en corrélation avec des informations étendues. La recommandation qui s'ensuit concernant la priorité des correctifs est destinée à soutenir l'équipe de sécurité. Ceci dans le but de répondre à la question suivante : notre équipe de sécurité a-t-elle toujours les connaissances et surtout le temps d'évaluer les nouvelles vulnérabilités ?
Blog de Tenable :Qu'est-ce que VPR et en quoi est-il différent de SVSS ?
Le transfert d'actifs en dehors du périmètre est devenu normal dans de nombreuses entreprises. Il en résulte de nouveaux risques qui doivent être contrôlés au moyen d'un outil de gestion des vulnérabilités.Tenable Attack Surface Management offre précisément cette fonction en scannant Internet et en utilisant des informations accessibles au public pour établir une liste des vecteurs d'attaque possibles. Il indique par exemple quelles IP sont accessibles dans mon bloc d'adresses publiques, quelles sont les vulnérabilités et quels actifs d'Amazone Web Services sont associés à mon entreprise.
Pour les actifs cloud, il est particulièrement important de savoir qui est responsable de quoi, cela fait partie d'une stratégie cloud et ne fait pas partie de la gestion des vulnérabilités. Chaque fournisseur de cloud aura un modèle de responsabilité partagée.
Sur la base de ce modèle, les responsabilités sont réglées, et il est important d'inclure dans la stratégie cloud la gestion des vulnérabilités, des correctifs et des actifs. Un système de gestion des vulnérabilités ne peut vérifier que ce qu'il connaît, c'est pourquoi une collaboration est souhaitable dès le début du projet.
Une gestion des vulnérabilités aide chaque entreprise à mieux connaître son infrastructure. Une gestion des vulnérabilités qui fonctionne n'est pas un outil que l'on installe une fois et qui résout ensuite tous les problèmes. C'est un processus qui doit être optimisé en permanence et qui doit être accepté et vécu par toutes les personnes concernées.
Une gestion des vulnérabilités qui fonctionne bien nécessite une CMDB et une gestion des correctifs. La CMDB sert de base pour identifier les actifs et la gestion des correctifs sert bien sûr à appliquer les correctifs.
Nous recommandons de focaliser la gestion des vulnérabilités sur une partie de l'infrastructure dans un premier temps, afin d'acquérir de l'expérience et d'en tenir compte dans le développement de la VM. N'oubliez pas que les actifs, les parties prenantes et le niveau de sécurité ainsi que sa perception ne sont pas toujours comparables.