Définition du Vulnerability Operation Center (VOC)

Une organisation, pas un outil

Un VOC est une unité spécialisée au sein d’une organisation qui sera responsable de l’identification, de l’évaluation, de la gestion et de l’atténuation des vulnérabilités dans les systèmes, les réseaux et les logiciels.

Il est important de spécifier que nous n’allons pas évoquer ici un outil, mais plutôt une organisation dans l’organisation. Le VOC est un concept, une façon de travailler et non un logiciel, bien sûr, vous aurez besoin de composants techniques pour déployer votre VOC, mais le VOC représente avant tout une méthodologie pour gagner en visibilité, en sécurité et en efficacité.

Quels sont les objectifs du VOC ?

L’objectif global du VOC est très simple : permettre une exécution professionnelle et organisée du cycle de gestion des vulnérabilités dans une organisation.

Pour ce, le VOC surveille généralement diverses sources d’information en liaison avec les failles de sécurité présentes, telles que les résultats de scan, les résultats de Pentest, les renseignements de sources ouvertes, les flux de CTI privés, les bulletins de sécurité, etc.

Dès lors, il se donne pour mission de coordonner les efforts afin de remédier efficacement les vulnérabilités présentes dans l’organisation. Sa philosophie générale est d’identifier de manière proactive les faiblesses potentielles et de prendre les mesures nécessaires pour prévenir les failles de sécurité ou en atténuer l’impact afin de garantir le niveau de sécurité nécessaire au bon fonctionnement de l’organisation.

Généralement, les organisations qui déploient un VOC le font de manière progressive, cela leur permet de se structurer petit à petit en couvrant trois besoins primaires :

• Centraliser toutes les informations sur les vulnérabilités présentes dans l’organisation, et ce quelle que soit la source

Il faudra alors que le VOC « aspire » des données depuis plusieurs référentiels, la source de données principale restant généralement les résultats de scan – mais ceci n’est pas exhaustif ! il sera tout à fait possible de connecter au VOC d’autres pratiques en liaison avec les vulnérabilités comme les résultats de Pentest ou même les résultats de BugBounty

• Une fois que toutes les données sont dans le puit de données du VOC, il sera alors possible non seulement d’évaluer l’ensemble du stock mais surtout de définir des règles pour prioriser le traitement et les mesures correctives ou dérogatoires.

Cela passe généralement par une méthode d’évaluation par les risques car c’est la seule qui permettra de comparer par exemple une mauvaise configuration Active Directory, une CVE présente dans le CISA KEV ou encore un code contenant des failles

• Finalement, quand les règles de priorisation seront établies et permettront de définir clairement ce qu’il faut corriger et à quelle échéance, le VOC devra synchroniser les actions entre l’équipe sécurité et les équipes en charge de la remédiation (souvent les équipes systèmes ou applicatives)

Une prise de conscience et un virage à prendre

L’échec du SOC

Quand j’évoque avec un professionnel de la sécurité les VOCs et leurs missions, vient très souvent un « contre argument fallacieux » de leur part : « Mais, ce que tu me décris, c’est la mission du SOC ! »

Et bien NON, justement, et c’est bien là le problème !

Depuis l’apparition des SOCs il y a quelques dizaines d’années, nous n’avons cessé de rajouter des sources d’information et surtout des missions au SOC ; nous atteignons maintenant un point de rupture, les équipes SOC ne peuvent plus gérer l’ensemble des tâches confiées.

Il est très simple d’en faire la preuve :

(a) Les attaques réussies se multiplient

(b) Le stock de vulnérabilités non-traitées ne cesse de grossir

(c) Demandez à une équipe SOC quel est le plan de priorisation sur la remédiation du stock de vulnérabilités ou des statistiques sur le stock global, vous entendrez les mouches voler…

En effet, nous tentons depuis des dizaines d’années de faire traiter les vulnérabilités par le SOC, mais cela ne fonctionne pas. La raison est finalement plutôt simple : ce n’est pas la mission du SOC.

Le SOC doit gérer des évènements/alertes, qui deviendront peut être des incidents – selon les organisations, le SOC assurera éventuellement la partie investigation ou passera le relais au CERT/CSIRT. Sa mission est réactive, il réagit en fonction d’un évènement ou d’une information.

De plus, les SOCs croulent littéralement sous les informations, faux positifs, faux négatifs et sont soumis à une pression constante. Dans ce genre de situation, la mission de prévention reste toujours en bas de la liste des choses à réaliser, c’est la raison principale de la croissance constante du stock de vulnérabilités, elles ne sont pas traitées convenablement car ce traitement n’est pas la priorité des équipes SOC.

Baromètre du CESIN

La meilleure preuve de cette prise de conscience provient des RSSI eux-mêmes, en 2023, le CESIN réalisait un sondage sur les priorités des RSSIs (Sondage OpinionWay) – le résultat est sans appel, 50% des RSSIs français déclaraient utiliser ou déployer un VOC dans leur organisation.

Le VOC, une équipe dédiée

Le déploiement d’un VOC nécessite une équipe dédiée, encore une fois, ne tentez pas d’utiliser du temps partagé avec votre équipe SOC pour remplir les missions du VOC, cela ne fonctionne pas.

Les professionnels présents au sein du VOC réaliseront principalement les tâches suivantes :

• Assurer la connexion avec les nouvelles sources de données quand elle se présentent (par exemple, parce que vous avez déployé un nouveau type de scanner de vulnérabilités)
• Analyser les vulnérabilités présentes
• Réaliser une veille en vulnérabilités
• Définir des arbres de décisions SSVC pour le tri automatique vers des stratégies de remédiation
• Créer des groupes de remédiation statiques pour des campagnes de crise (exemple Log4Shell)
• Suivre les tickets qui ont été générés automatiquement ou manuellement depuis l’outil de Cockpit VOC
• Définir et surveiller les SLAs de remédiation
• Suivre les indicateurs de régression de findings (typiquement un finding qui a été déclaré comme corrigé par l’équipe applicative mais qui est à nouveau détecté par le scanner)
• Créer des rapports statistiques sur l’évolution du stock de vulnérabilités
• Etc.

Pour exécuter les missions du VOC vous aurez donc principalement besoin d’analystes et d’une paire de managers pour orchestrer le tout. Les managers VOC recrutés devront savoir communiquer, car il faudra éduquer les différentes équipes de production sur les missions et objectifs du VOC.

Mise en œuvre d’un VOC

Les prérequis

Pour mettre en œuvre un VOC, vous aurez besoin absolument :

• De scanners de vulnérabilités : en effet, les résultats de scan sont la source première d’information pour un VOC – nulle crainte, vous pouvez aussi utiliser des scanners open-source si vous le désirez
• D’un outil de type « Cockpit VOC » – comme le SIEM est l’outil principal du SOC, le VOC possède son propre outillage, communément appelé « Cockpit VOC »
• D’une source de CTI – parfois le Cockpit VOC propose déjà une source de CTI, dans ce cas, pas besoin d’acheter les services d’un flux dédié

Certains éléments sont optionnels :

• Informations sur les actifs à intégrer dans le cockpit – cette partie n’est pas obligatoire, en effet, les scanners de vulnérabilités remontent de facto les informations liées aux actifs qui portent les vulnérabilités – néanmoins vous désirerez peut être enrichir ces données avec vos propres informations provenant d’une CMDB ou d’une analyse de risque
• Des sources de CTI additionnelles – à nouveau, un seul flux est nécessaire, mais si vous êtes mature dans votre processus de veille, peut être voudrez vous associer plusieurs sources de CTI dans votre Cockpit VOC pour améliorer votre jeu de données
• Connexion d’un système ITSM pour attribution des tickets. Même si cet élément est considéré comme optionnel, il peut s’avérer extrêmement important si votre objectif est d’assurer un liant efficace entre l’équipe sécurité et les équipes de remédiation

« Be cloud or not to be cloud ? »

Certains Cockpits VOC ne sont accessibles que sous la forme d’un service cloud. Selon vos contraintes de conformité ou de sécurité, vous ne pourrez peut-être pas envoyer les données qui concernent l’ensemble de vos vulnérabilités dans un service cloud. Dans ce cas, sélectionnez un cockpit qui peut fonctionner en mode local.

De plus, certains Cockpits VOC possèdent des capacités hybrides et peuvent fonctionner en mode service cloud mais aussi en mode local.

Exploitation

Si vous préparez bien votre projet, l’exploitation au quotidien du service de VOC ne représentera pas une tâche démesurée. Mais attention, la partie process est importante, si vous négligez cet aspect, vous ne serez efficace ni dans vos tâches de priorisation, ni dans l’automatisation des actions.

Définir un process global clair et accepté de tous

Vous devez à cette étape définir quel sera le cycle complet de traitement des vulnérabilités. Privilégiez les process simples et qui pourront être appliqués par tout le monde.

Il est important de communiquer auprès de toutes les parties prenantes et principalement auprès des équipes de production qui seront en charge des missions de remédiation. N’hésitez pas à organiser des ateliers, et à refaire une passe mensuellement pendant les six premiers mois du lancement d’un service VOC.

Il est primordial que chaque musicien joue sa partition, assurez-vous que chaque acteur ait bien compris sa mission au sein du cycle de gestion des vulnérabilités.

Définissez des arbres de décision SSVC

Il existe de multiples méthodologies permettant de prioriser les vulnérabilités et leur traitement. Je conseille vivement d’utiliser la méthodologie des arbres SSVC définie par le CISA (Voir : https://www.cisa.gov/stakeholder-specific-vulnerability-categorization-ssvc).

En effet, cette méthode possède l’avantage de faire un lien pragmatique entre l’évaluation des risques et vos capacités de remédiation.

Trois éléments doivent guider la création de l’arbre de décision SSVC :

1. La capacité de traitement, c’est-à-dire le nombre de personnes pouvant être mobilisées régulièrement pour mener des actions correctives.

2. L’appétence de l’organisation pour le risque, c’est-à-dire si l’organisation peut ou non prendre des risques, et à quelle échelle.

3. Les réglementations applicables à l’organisation, c’est-à-dire que certaines organisations sont soumises à des réglementations qui exigent un certain niveau de sécurité et que l’organisation doit fournir une capacité de traitement adéquate sous peine d’amendes ou de radiation.

Premièrement, commencez par définir vos pools de remédiation dans lesquels vos findings viendront se ranger ; j’en conseille 4 :

• IMMEDIATE (Sous 48 heures) : Les findings dans ce pool sont considérées comme extrêmement dangereuses et doivent être corrigées dans un délai extrêmement court. En général, il s’agit de vulnérabilités qui peuvent être exploitées et utilisées activement par des attaquants – et le plus souvent, il s’agit de findings portées par des actifs exposés sur Internet et directement accessibles par des attaquants.
• OUT OF CYCLE (Sous 1 à 4 semaines): Ces findings sont considérées comme dangereuses et le traitement ne peut pas attendre la prochaine période de remédiation planifiée. Toutefois, il n’est pas nécessaire de procéder à une correction immédiate (i.e. sous 48 heures). La planification dépend de l’urgence du traitement et de l’évaluation des risques associés, mais elle se situe généralement entre une semaine et quatre semaines à compter de la date de l’évaluation des risques.
• SCHEDULED : (Une à deux fois dans l’année – dates variables en fonction de l’organisation) : Une période de remédiation programmée existe dans l’organisation. Il s’agit souvent d’une période de 2 à 3 jours programmée à l’avance. La programmation de cette période dépend de l’activité de l’organisation et est généralement programmée pendant les périodes de moindre activité. Pendant cette période, les usagers savent à l’avance que les systèmes seront corrigés et que le service fourni par ces systèmes sera potentiellement perturbé.
• DEFER : le pool des findings qui sont mises de côté, oubliées, car ne représentent aucun risque.

Deuxièmement, définissez vos critères d’évaluation – de nombreux critères peuvent être utilisés pour la création de vos arbres de décision, par exemple :

• Score CVSS Base (la vulnérabilité elle-même)
• Score CVSS Environnemental (prise en compte des caractéristiques de l’actif qui porte les vulnérabilités)
• Score de risque « propriétaire » (mais il faut un score applicable à tous les type de vulnérabilités) – Exemple : Hackuity TRS
• Vulnérabilité Exploitable ou pas
• Vulnérabilité exploitée ou pas par les attaquants
• Situation physique de l’actif : connecté à Internet ou pas
• La vulnérabilité fait partie du catalogue CISA KEV ou pas
• Score EPSS (évaluation de la probabilité d’exploitation par les attaquants dans les 30 prochains jours)
• Critère CIA de l’actif : niveaux attendus de Confidentialité, d’Intégrité et de Disponibilité
• Etc.

Troisièmement, créez vos arbres – chaque branche de l’arbre sert à évaluer des critères pour ranger automatiquement les vulnérabilités (en fait les findings) dans les bons pools de remédiation – voici quelques exemples :

Rappelez-vous qu’il n’y a pas de bon ou de mauvais critère, les critères choisis dépendent de votre organisation, de ses contraintes et de ses objectifs.

Important : Les arbres peuvent évoluer avec le temps, en effet, il est envisageable que la première version de votre arbre de décision attribuera trop de findings dans le pool IMMEDIATE, et vos équipes de production ne pourront pas suivre. Il faudra alors adapter votre arbre pour qu’il soit compatible avec vos capacités de remédiation réelles et pas avec vos envies… Il est très important que les temporalités associées aux différents pools soient réalistes.

Un investissement stratégique

En conclusion, le Vulnerability Operation Center (VOC) représente un élément crucial dans la stratégie de cybersécurité des entreprises modernes. En centralisant la détection, l’analyse et la gestion des vulnérabilités, un VOC permet non seulement de réagir rapidement aux menaces, mais aussi de les anticiper et de les prévenir. Grâce à des processus rigoureux, un outillage adéquat et une équipe dédiée d’experts en vulnérabilités, le VOC assure une surveillance continue et proactive de l’environnement numérique de l’organisation.

La mise en place d’un VOC constitue un investissement stratégique qui renforce la résilience de l’entreprise face aux cyberattaques. Il contribue à protéger les actifs numériques, à préserver la confiance des partenaires et à garantir la continuité des opérations.

En fin de compte, un VOC n’est pas seulement une réponse aux vulnérabilités, mais une composante essentielle d’une posture de sécurité globale et dynamique.

Par Sylvain Cortes, MVP, co-fondateur des Identity Days