De quoi parle-t-on ?

L’ISO 27005 définit une vulnérabilité comme « une faiblesse d’un actif ou d’un groupe d’actifs qui peut être exploitée par une ou plusieurs menaces, où un actif est tout ce qui a une valeur pour l’organisation ». Pour le SANS, la gestion des vulnérabilités est « le processus par lequel les vulnérabilités informatiques sont identifiées et les risques liés à ces vulnérabilités sont évalués. Cette évaluation conduit à la correction des vulnérabilités et à la suppression du risque ou à une acceptation formelle du risque ». Au fil du temps, la gestion des vulnérabilités est devenue une pratique fondamentale de la cybersécurité et les professionnels du métier s’accordent aujourd’hui unanimement pour dire que c’est un processus essentiel pour minimiser la surface d’attaque de l’entreprise.

Source: https://blogs.gartner.com/augusto-barros/2019/10/25/new-vulnerability-management-guidance-framework/

La gestion des vulnérabilités est ainsi désormais intégrée dans tous les grands référentiels, standards, régulations sectorielles, guides ou bonnes pratiques de sécurité (ISO, PCI-DSS, guide d’hygiène de l’ANSSI, GDPR, accords de Bâle, LPM, NIS, …) et est même réglementaire dans certains contextes. Toute bonne politique de sécurité d’entreprise y accorde d’ailleurs un chapitre significatif.  Un mal nécessaire pour beaucoup.

Vulnérabilités : état de la menace

Cependant, en 2019, selon une étude menée par le Ponemon Institute[1] « 60% des incident de sécurité étaient [encore] la conséquence de l’exploitation d’une vulnérabilité pourtant connue mais non encore corrigée par les entreprises ».

Pour illustrer l’ampleur actuelle du phénomène, considérons la grande menace cyber de 2020 et probablement de 2021 : les ransomwares. Bien que les ransomwares se propagent généralement par des actions initiées par l’utilisateur, comme cliquer sur un lien malveillant dans un spam ou visiter un site web compromis, une grande partie de ceux-ci exploitent également des vulnérabilités informatiques. Ainsi, si on analyse en détail le top-5 des ransomwares les plus virulents en 2020 selon intel471[2], on constate que leurs « kill-chain » exploitent toutes des vulnérabilités (CVE).

Source: Hackuity & National Vulnerability Database (https://nvd.nist.gov/)

Autre constat, il s’agit souvent de vulnérabilités déjà référencées par le NIST lors de l’apparition du ransomware, parfois même depuis plusieurs années, et dont les éditeurs proposaient un correctif ou une méthode de contournement. Une récente étude de CheckPoint[3] vient confirmer que les vulnérabilités les plus anciennes sont toujours les plus exploitées. Mi-2020, plus de 80% des cyberattaques recensées utilisaient une vulnérabilité publiée avant 2017 et plus de 20% de ces attaques exploitaient même une vulnérabilité connue depuis plus de 7 ans.

Cela souligne l’importance – aujourd’hui encore – d’une installation rapide des mises à jour de sécurité comme mécanisme de défense pour minimiser les risques cybers. Sans grande surprise donc, la gestion des vulnérabilités – pourtant l’une des plus anciennes pratiques de la cybersécurité – reste pour Wavestone[4] l’un des défis majeurs à relever pour les RSSI en 2021. Faut-il pour autant essayer de corriger toutes les vulnérabilités ? Petit retour dans le passé.

« Vulnerability Assessment » vs. « Vulnerability Management »

Quand elles sont apparues sur le marché, à la fin des années 90, les premières solutions de gestion des vulnérabilités avaient un fonctionnement proche de celui d’un antivirus : l’objectif était de détecter le plus grand nombre possible de menaces potentielles. On parlait plus volontiers de « scanners de vulnérabilités ».

Le volume de vulnérabilités était alors relativement faible par rapport à aujourd’hui. En 2000, le NVD recensait environ 1 000 nouvelles vulnérabilités sur l’année contre plus de 18 000 en 2020.

Un traitement exhaustif et manuel des vulnérabilités était alors encore possible. Les scanners fournissaient la liste des vulnérabilités, leur pertinence dans le contexte de l’entreprise était analysée par les équipes IT et un rapport était envoyé aux responsables métiers. Une fois le rapport approuvé, les administrateurs corrigeaient la vulnérabilité et procédaient à une nouvelle analyse pour vérifier la bonne mise en place du correctif.

Source : National Vulnerability Database (https://nvd.nist.gov/)

Pendant les deux décennies suivantes, le nombre de vulnérabilités découvertes a augmenté de façon constante avec une véritable explosion à partir de 2017, tendance qui s’est poursuivie jusqu’à aujourd’hui. En 2020, c’est un record de plus de 18 000 nouvelles vulnérabilités qui ont été recensées et publiées par le NIST. Mais non, les développeurs ne codent pas de plus en plus mal ! Différentes raisons expliquent le nombre croissant de vulnérabilités divulguées :

1. L’innovation et la digitalisation accélérée des métiers conduisent à une augmentation des produits matériels et logiciels publiés. En 2010, le NIST enregistrait 22 188 nouvelles entrées dans son référentiel CPE, dont 1 332 nouveaux produits et 406 éditeurs. En 2020, c’est 324 810 entrées (+1 460 %), 35 794 nouveaux produits (+2 690 %) et 6 060 éditeurs (+1 490%) qui font leur apparition.
2. La demande de réduction des délais de mise sur le marché pousse les éditeurs à réduire les cycles de développement pour commercialiser leurs produits plus rapidement quitte à rogner sur les ressources nécessaires pour l’assurance qualité et les tests de sécurité.
3. La cybercriminalité est devenue une activité lucrative. Un nombre de plus en plus important de vulnérabilités est aujourd’hui attribué aux cybercriminels à la recherche de nouveaux outils pour soutenir leurs attaques.
4. En parallèle, le nombre d’experts et d’organisations indépendantes qui participent à la recherche et à la découverte des vulnérabilités est en augmentation. La démocratisation et l’industrialisation des programmes de Bug-Bounty n’y sont d’ailleurs pas étrangères.
5. Et enfin, sauf rares exceptions comme dans le RGPD, en l’absence de législation et de réglementation adéquates pour protéger les droits des consommateurs en cas de vulnérabilités dans les logiciels, l’industrie n’est pas incitée à investir dans des produits plus sûrs et à assumer la responsabilité des dommages causés.

Cependant le problème ne se trouve pas seulement dans le nombre plus élevé de vulnérabilités recensées dans les bases du NVD ou d’autres référentiels. Avec l’avènement de l’ultra-mobilité, le home-office, le cloud-computing, les médias sociaux, l’IoT mais aussi la convergence entre IT et OT, les Systèmes d’Information n’ont cessé de se complexifier et de s’étendre, de s’ouvrir et de multiplier le nombre de leurs fournisseurs, … autant de potentielles nouvelles portes d’entrées pour les cybercriminels.

En parallèle, les entreprises conscientes des risques déploient et opèrent un arsenal de détection des vulnérabilités qui s’étoffe continuellement et qui a gagné en maturité ces dernières années, voir qui s’est « commoditizé » :

• Tests d’intrusions, Red-teams,
• Scanners de vulnérabilités : sur la totalité du parc externe et/ou interne
• Veille en vulnérabilités
• SAST, DAST & SCA : souvent directement intégrés aux pipelines de développement
• Campagnes de bug-bounty

Toutes ces pratiques de détection sont complémentaires et généralement empilées dans une approche « best-of-breed » pour évaluer des briques spécifiques du SI. Malheureusement, c’est souvent une fois l’arsenal mis en place que les problèmes sautent aux yeux (liste non exhaustive) :

• L’hétérogénéité des formats de rendu : rapports au format PDF ou Excel pour les pentests, résultats des scans dans la console de l’outils, vulnérabilités sur la plateforme de bug bounty, …, contraignent souvent l’entreprise à adopter une gestion des vulnérabilités en silo. Il en est de même pour le scoring des vulnérabilités qui s’avère finalement être un patchwork entre CVSS et ses multiples versions, échelles propriétaires et savant mélange des deux.
• En découle l’incapacité à prioriser globalement les efforts de remédiation du fait d’une perception parcellaire et hétérogène du stock de vulnérabilités.
• La gestion de volumes de données devenus bien trop importants pour être traités manuellement : il n’est pas rare qu’une entreprise qui réalise des scans authentifiés sur son parc voit son volume de vulnérabilités dépasser plusieurs millions d’entrées dans la console du scanner.
• La difficulté à coordonner les actions de remédiation : identification du propriétaire d‘un actif et du porteur d’une action, échanges de mails, suivi d’avancement, reporting Excel, …
• La frustration des équipes en charge de la remédiation qui ne disposent pas de reporting factuel traduisant l’effort de remédiation sur la posture globale de sécurité de l’entreprise.

Face à ces problèmes, les entreprises n’ont d’autres choix que de travailler à la mise en place de processus souvent coûteux car s’appuyant sur des actions manuelles, le développement d’un outillage ad-hoc ou encore un assemblage de bric et de broc de solutions glanées çà et là. Le manque d’automatisation de ce processus est d’autant plus absurde qu’il mobilise généralement de rares et coûteux experts en cybersécurité sur des tâches à faible valeur comme de la compilation de données dans Excel, la recherche sans fin des bons interlocuteurs ou encore le suivi de fils de mails.

Dans son étude « Cost and consequences of gaps in vulnerability management responses » (2019), le Ponemon Institute estime que les entreprises de plus de 10 000 salariés ont consacré en moyenne en 2019 plus de 21 000 heures (soit près de 12 ETP) à la prévention, détection et traitement des vulnérabilités. Cela représente un total de plus de 1M$ pour un rapport qualité/prix finalement très décevant.

Le « patching paradox »

En théorie, la meilleure façon de rester protégé est de maintenir à jour chaque système en corrigeant chaque nouvelle vulnérabilité, au fil de l’eau, dès qu’elle est identifiée. IRL, la tâche s’avère aujourd’hui impossible en raison d’un nombre de vulnérabilités devenues bien trop important mais aussi des ressources humaines ou financières limitées, de l’existence de systèmes hérités et des délais de mise à disposition ou des contraintes de déploiement des patchs.

En définitive, quelle que soit sa taille, une organisation n’aura jamais assez de ressources humaines ou financières pour remédier à toutes ses vulnérabilités. L’industrie appelle d’ailleurs « Patching Paradox » la conviction – erronée – que plus de personnel affecté aux traitements des vulnérabilités équivaut à une meilleure sécurité.

Afin de réduire la pression pour augmenter les effectifs à un moment où il y a une pénurie d’experts sécurité qualifiés et pour éviter que la gestion des vulnérabilités ne devienne une course effrénée et perdue d’avance à vouloir corriger toujours plus de vulnérabilités, il est nécessaire aujourd’hui pour les entreprises de déterminer celles qui doivent l’être en priorité.

Après avoir vu dans ce premier article l’état de la menace et les problématiques actuelles liées à la gestion des vulnérabilités, nous verrons dans un second article les nouvelles approches à prendre en compte pour mieux gérer les vulnérabilités, notamment via la priorisation de la remédiation proposée par Hackuity.

[1] Ponemon Institute – Cost and consequences of gapes in vulnerability management responses – 2019

[2] https://intel471.com/blog/ransomware-as-a-service-2020-ryuk-maze-revil-egregor-doppelpaymer/

[3] https://www.checkpoint.com/downloads/resources/cyber-attack-trends-report-mid-year-2020.pdf

[4] https://www.wavestone.com/fr/insight/radar-rssi-quelles-priorites-2021/

Cet article Hackuity | Shake’Up – Le futur de la gestion des vulnérabilités: état de la menace et problématiques actuelles de gestion des vulnérabilités (1/2) est apparu en premier sur RiskInsight.

Les tests sont un élément important de la résilience opérationnelle et peuvent prendre de nombreuses formes, depuis les tests de reprise après sinistre pour assurer la continuité des services jusqu’aux simulations de crise de bout en bout pour examiner la prise de décision. Il permet de gérer les risques de manière proactive, d’intégrer le cadre de gestion des crises et d’améliorer en permanence les capacités telles que la continuité des activités, la gestion des crises, la reprise après sinistre (DR) et la résilience cyber. Il va sans dire que la formation joue un rôle important dans un tel programme d’essai.

« Une meilleure sensibilisation nourrit une culture organisationnelle qui englobe la résilience opérationnelle et, par conséquent, améliore la préparation de l’entreprise à faire face à l’adversité ».

D’une entreprise à l’autre, les bons programmes d’essai varient en nature, en ampleur et en complexité. En fonction de la structure et des activités de l’entreprise, les tests sont effectués à différents niveaux et endroits de l’organisation, avec la participation de parties externes (c’est-à-dire les fournisseurs critiques). En réalité, si les autorités de réglementation ne donnent que peu d’indications sur ce qui est « bon », les programmes sont souvent fragmentés et peuvent causer un véritable casse-tête.

PRINCIPES POUR LA CRÉATION D’UN PROGRAMME D’ESSAI RÉUSSI

Bien qu’il n’y ait pas de solution miracle pour créer un programme de test adapté, nous recommandons de suivre six principes directeurs pour en concevoir un qui soit efficace et adapté aux besoins de votre organisation. Le respect de ces principes pourrait améliorer considérablement les résultats du programme.

1. Penser à long terme

Lors de l’élaboration d’un programme de tests, il est primordial de définir ce que vous voulez atteindre en 3 ans. L’accent mis sur les résultats donne l’orientation requise tout en offrant la souplesse nécessaire pour remodeler le programme de tests chaque année afin de répondre aux changements tout en se concentrant sur l’objectif final. Commencez par de petits tests moins complexes, tels que des tests de fonctionnement, et passez à des exercices de simulation de crise très impliqués et réalistes.

2. Commencer par les menaces

Chaque test doit établir un lien avec la ou les menace(s) résultant d’un ou plusieurs scénarios d’incidents majeurs plausibles (et leurs impacts). Anticipez et comprenez les nouvelles menaces grâce à la surveillance du marché et tirez parti des rapports d’audit et des évaluations des risques lors de l’élaboration ou de la révision de votre programme.

3. Focus sur les services importants aux entreprises

Aligner les tests des dispositifs d’urgence existants sur les services commerciaux importants et les processus clés. Cela permet d’assurer la préparation en cas de situation à fort impact sur les entreprises et d’éviter les difficultés découlant d’un manque de vision de bout en bout.

4. Diversifier les tests

Les scénarios les plus probables et les plus impactants doivent être examinés avec différents groupes de parties prenantes par le biais de différents types de tests. Cela permet de s’assurer que la théorie fonctionne dans la pratique et que les différents réflexes sont ancrés dans l’ADN de l’organisation.

Pour obtenir plus d’avantages, il faut aller au-delà des plans d’urgence autonomes et des tests d’outils de communication et en examiner une combinaison avec les parties prenantes internes et externes, commerciales et techniques.

Le radar ci-dessus est un exemple indicatif de ce que serait un bon programme d’essai. Les catégories de menaces considérées sont aléatoires et pourraient être sélectionnées différemment, à condition de maintenir la diversification (mix-and-match).

Simulation de crise

Les simulations de crise examinent une situation de catastrophe hypothétique avec des parties définies et des cellules de stimulation multiples. Elles permettent de répéter l’établissement et la communication des besoins de rétablissement et de mener à bien les activités pertinentes. La simulation de crise peut être un exercice sur table (niveau 1), une simulation pratique (niveau 2), une simulation pratique de crise multi-cellules (niveau 3) ou une simulation pratique internationale multi-cellules avec plusieurs parties (niveau 4).

Cet article TESTEZ ET AUGMENTEZ VOTRE RÉSILIENCE : COMMENT CONSTRUIRE VOTRE PROGRAMME DE TEST est apparu en premier sur RiskInsight.