Plateformisation des outils cyber offensifs : quand et comment consolider

Qu’est-ce que la plateformisation des outils offensifs ?

Au fil des années, une équipe sécurité accumule des outils qui regardent l’organisation avec les yeux d’un attaquant : découverte de la surface externe, scanners de vulnérabilités, inventaire des actifs internes, surveillance des fuites, simulation d’attaque, outillage de pentest, notation des fournisseurs. Chacun a été acheté pour une bonne raison. Ensemble, ils produisent souvent plusieurs inventaires, plusieurs scores et plusieurs listes de priorités.

La plateformisation consiste à faire travailler ces fonctions sur une même donnée. Elle ne se réduit pas à acheter un seul produit. Elle répond à une exigence de fond : que la découverte, la priorisation, la validation et la remédiation parlent des mêmes actifs, avec le même contexte.

Une tendance de marché, à lire avec précision

Gartner a mesuré le mouvement dans une enquête publiée en septembre 2022, menée en mars et avril 2022 auprès de 418 répondants en Amérique du Nord, en Asie-Pacifique et dans la zone EMEA : 75 % des organisations engageaient une consolidation de leurs fournisseurs de sécurité, contre 29 % en 2020. Deux nuances s’imposent. L’enquête porte sur l’ensemble des fournisseurs de sécurité, pas sur les seuls outils offensifs. Et le motif dominant n’est pas l’économie : 65 % attendaient une meilleure posture de risque, 29 % seulement une baisse des dépenses de licences.

Pourquoi la dispersion coûte-t-elle si cher ?

Le coût d’un parc fragmenté ne se voit pas sur une facture. Il se voit dans le temps passé à réconcilier, et dans les décisions prises sur des données contradictoires.

Quatre symptômes fréquents

• Des inventaires divergents. L’outil de découverte externe trouve un sous-domaine que la CMDB ignore ; le scanner interne connaît un serveur que l’inventaire de sécurité n’a pas. Personne ne sait quelle liste fait foi.
• Des doublons. La même faiblesse remonte trois fois, sous trois noms, avec trois scores. Les équipes IT reçoivent trois tickets et en ferment un.
• Un contexte perdu. L’outil qui connaît la criticité métier d’un actif n’est pas celui qui connaît sa vulnérabilité, ni celui qui sait qu’un identifiant de son administrateur a fuité.
• Des priorités contradictoires. Chaque console a sa propre file. La décision finale se prend dans un tableur, à la main.

C’est l’une des erreurs de démarrage que nous relevons dans notre article sur la mise en œuvre du CTEM : empiler des consoles qui ne partagent ni l’inventaire ni le contexte recrée les silos que le programme devait supprimer. Le cadre CTEM ne prescrit pas d’outil, mais ses cinq étapes supposent que la donnée circule de l’une à l’autre.

Ce qu’il faut mettre en commun

1. Un inventaire partagé. Une seule fiche par actif, alimentée par toutes les sources, avec son propriétaire et sa criticité.
2. Un contexte commun. Exposition, vulnérabilités, droits, fuites et résultats de validation rattachés au même actif.
3. Une déduplication fiable. Elle repose sur des identifiants partagés : le nom normalisé des produits (CPE), l’identifiant des vulnérabilités (CVE), les techniques d’attaque (MITRE ATT&CK). Des schémas ouverts comme OCSF proposent un format commun pour les constats de sécurité, dont les constats de vulnérabilité.
4. Une priorisation unique. Une seule file, qui tient compte de la place de chaque faiblesse dans un chemin d’attaque. C’est le sujet de notre guide sur l’analyse des chemins d’attaque par graphe : un graphe n’a de sens que si ses nœuds viennent d’un inventaire consolidé.

Faut-il consolider ? Les critères de décision

La consolidation n’est pas toujours la bonne réponse. Le tableau suivant aide à trancher, outil par outil.

La dernière ligne compte davantage qu’il n’y paraît. Une plateforme consolidée contient la carte de vos faiblesses non corrigées : c’est une donnée sensible, dont la localisation et le régime juridique doivent être connus.

Quels sont les risques de la plateformisation ?

La dépendance

Plus une plateforme concentre de fonctions, plus en sortir coûte cher. Pour les entités financières, DORA formalise ce risque : l’article 28, paragraphe 8 impose des stratégies de sortie pour les services TIC qui soutiennent des fonctions critiques ou importantes, et l’article 29 demande d’évaluer le risque de concentration, notamment lorsqu’un prestataire n’est pas facilement substituable. Même hors du secteur financier, la discipline est saine : exiger l’export des données, une API documentée et des identifiants standards dès le contrat.

L’effet tunnel

Une plateforme unique impose sa vision. Ce qu’elle ne sait pas détecter disparaît du tableau de bord, et l’équipe finit par confondre « non signalé » et « absent ». Le correctif est simple à énoncer : garder un regard extérieur. Un test d’intrusion ou un exercice Red Team réguliers vérifient ce que la plateforme ne voit pas.

La concentration et le projet lui-même

La plateforme devient un actif critique : ses comptes d’administration ouvrent l’accès à tout l’inventaire d’exposition. Elle doit être protégée comme tel. Enfin, la migration est un projet. Gartner recommande de prévoir au moins deux ans pour une consolidation de fournisseurs de sécurité, et rappelle que le marché « se consolide toujours sans jamais être consolidé » : rachats et changements de feuille de route font partie du risque.

Une méthode de migration en six étapes

1. Cartographier le parc. Pour chaque outil : ce qu’il couvre, à quelle étape du cycle CTEM il contribue, qui l’utilise, où vont ses constats.
2. Choisir le référentiel d’inventaire. Décider quelle source fait foi pour les actifs, puis y rattacher toutes les autres.
3. Fixer le modèle de données. Clés de dédoublonnage, échelle de criticité, statuts de traitement communs.
4. Exécuter en parallèle. Faire tourner l’ancien et le nouvel outil sur le même périmètre pendant au moins un cycle, et mesurer le recouvrement réel des constats.
5. Retirer outil par outil. Ne débrancher un outil que lorsque ses constats propres sont couverts ou consciemment abandonnés.
6. Préserver la réversibilité. Tester l’export complet des données avant d’en avoir besoin.

Exemple : trois outils, une seule file

Exemple type. Une ETI de services utilise un outil de découverte externe, un scanner de vulnérabilités interne et des campagnes de simulation d’attaque, chacun avec sa console. Chaque mois, un analyste passe deux jours à réconcilier les exports dans un tableur.

La cartographie du parc montre que la découverte externe et le scanner se recouvrent largement sur les serveurs exposés, mais que seule la découverte externe voit les sous-domaines hérités d’une filiale. L’équipe choisit un inventaire de référence, aligne les identifiants de produits et de vulnérabilités, puis fait tourner l’ancien et le nouveau dispositif en parallèle pendant un trimestre.

Le scanner est retiré ; la simulation d’attaque est alimentée par l’inventaire commun. Un test d’intrusion annuel est maintenu pour garder un regard extérieur.

Ce scénario est construit à partir de situations courantes en mission, pas à partir d’un client identifiable.

Où BEAROPS intervient

Beareye se compose d’un Command Center, inclus, et de quatre modules : EASM, CAASM, CTI et Bearlink. Le Command Center centralise les vulnérabilités, le plan d’action et la Red Team automatisée. Au-delà, la suite BEAROPS réunit Beareye, Bearlink et Bearsploit, logiciel de pentest, sur un portail unique et des moteurs communs. Chaque produit s’achète seul, ce qui permet une consolidation progressive.

Limites de la plateformisation

Elle ne corrige pas l’organisation. Si personne n’est responsable des actifs ni des corrections, une plateforme unique produit une file unique que personne ne traite.

Elle ne garantit pas la couverture. Un outil retiré emporte parfois une capacité que la plateforme n’avait pas. Seule la phase d’exécution en parallèle permet de le savoir.

Elle déplace le risque. La dépendance envers plusieurs fournisseurs devient une dépendance envers un seul. C’est acceptable si la réversibilité a été prévue, risqué sinon.

Elle n’est pas toujours rentable. Une petite équipe avec deux outils bien intégrés n’a souvent rien à gagner à migrer. La consolidation se justifie par la donnée partagée et la qualité des décisions, pas par l’envie d’avoir moins de logos.