Passer au contenu principal
Image d'illustration de l'article de blog intitulé « Comprendre la gestion continue de l'exposition aux menaces (CTEM) »
Guide détaillé

Comprendre la gestion continue de l'exposition aux menaces (CTEM)

La gestion continue de l'exposition aux menaces (CTEM) est un cadre programmatique en cinq étapes visant à réduire en permanence l'exposition aux risques de sécurité dans le monde réel. Cette approche s'appuie sur l'analyse des vulnérabilités en y ajoutant une hiérarchisation fondée sur les risques, la validation des conditions d'exposition et de l'efficacité des contrôles, ainsi qu'une mobilisation inter-équipes visant à mettre en œuvre les mesures correctives.


La plupart des programmes de gestion des vulnérabilités se contentent de dire « nous l'avons détectée » et « nous l'avons corrigée ». CTEM ajoute l'étape que la plupart des programmes omettent : vérifier que l'exposition est bel et bien fermée et que les contrôles fonctionnent comme prévu.

Cet article détaille les exigences de chaque étape à l'échelle de l'entreprise, les points où les programmes achoppent généralement, et comment évaluer si vos efforts en matière de CTEM permettent de réduire les risques ou s'ils ne font que générer de l'activité.

Le CTEM expliqué

La gestion continue des risques liés aux menaces repose sur un cadre en cinq étapes . Gartner a mis en place le programme « » afin d’aider les organisations à réduire systématiquement leurs risques en matière de sécurité. Ces cinq étapes sont les suivantes : définition du périmètre, analyse, hiérarchisation, validation et mobilisation.

Contrairement aux évaluations périodiques de la vulnérabilité , qui aboutissent principalement à des listes de constatations, le CTEM met l’accent sur la question de savoir si les conditions d’exposition sont identifiables et si des mesures concrètes peuvent être prises de manière réaliste, ainsi que sur la capacité des mesures correctives et des contrôles à modifier de manière mesurable cette réalité. Le modèle CTEM intègre dans son processus de hiérarchisation la faisabilité réelle d'une attaque, les contrôles compensatoires, le niveau de criticité des actifs et l'accessibilité des voies d'attaque, autant d'éléments contextuels que les scores CVSS ne fournissent pas à eux seuls.

Le CTEM modifie son modèle opérationnel pour adopter une approche proactive : il passe d'une évaluation périodique et d'un système de tickets à un cycle continu qui identifie les éléments essentiels, vérifie si les vulnérabilités peuvent être exploitées ou permettre un déplacement latéral, confirme l'efficacité des contrôles et met en œuvre des mesures correctives dont la responsabilité est clairement définie.

La gestion traditionnelle des vulnérabilités identifie les CVE et les classe en fonction de leur niveau de gravité selon le score CVSS. Cela permet d'obtenir des résultats, mais cela ne répond pas à la question qui préoccupe réellement les responsables de la sécurité : quelles vulnérabilités un attaquant peut-il réellement exploiter pour accéder à des ressources critiques ?

Le CTEM élargit la définition du terme « exposition » au-delà des vulnérabilités pour y inclure toute lacune nécessitant des mesures d'atténuation. Une évaluation complète des vulnérabilités prend en compte non seulement les CVE non corrigées, mais également les erreurs de configuration, les risques liés à l'identité, les autorisations excessives, les ressources exposées vers l'extérieur, l'informatique fantôme ou toute autre situation qu'un attaquant pourrait exploiter. L'objectif n'est pas de dénicher davantage de problèmes. Elle concentre les efforts de remédiation sur les vulnérabilités les plus importantes pour votre environnement spécifique.

[Découvrez comment la gestion des risques s'inscrit dans une stratégie de sécurité plus large]

Le CTEM ne remplace pas la gestion des vulnérabilités. Il s'agit d'un programme structuré qui s'articule autour de vos processus existants d'analyse, de hiérarchisation et de correction, en s'appuyant sur le contexte métier afin de les rendre plus efficaces. Résultat : moins de vulnérabilités non corrigées, une correction plus rapide et des investissements en matière de sécurité ciblés là où les risques sont les plus élevés.

Pour bien comprendre ce qu'apporte le CTEM, il faut d'abord identifier les limites des approches traditionnelles.

Pourquoi la gestion traditionnelle des vulnérabilités présente des lacunes

Le problème ne réside pas dans la couverture des processus. Il s'agit d'une vérification. Si de nombreux programmes de gestion des vulnérabilités bien établis disposent généralement de processus de scan, de hiérarchisation et de correction, certains considèrent encore que la correction est achevée dès qu’un correctif a été appliqué, souvent sans vérifier que la faille a bien été comblée.

[Découvrez comment fonctionne la correction automatisée des vulnérabilités, pourquoi les limites de gouvernance sont importantes et comment un déploiement par étapes aide les organisations à combler leurs lacunes en matière de sécurité sans créer de nouveaux risques opérationnels]

Cela crée un angle mort crucial entre l'action et le résultat. Sans validation continue, les équipes peuvent supposer que le risque a été réduit alors que la vulnérabilité sous-jacente persiste en raison de déploiements ayant échoué, d'une dérive de configuration ou de correctifs incomplets.

Les modèles d'évaluation périodique ne font que creuser davantage ce fossé. Dans de nombreux environnements, les analyses programmées peuvent laisser subsister des failles nouvelles ou modifiées jusqu’au prochain cycle de collecte, en particulier dans les environnements cloud, SaaS et d’identité, qui évoluent rapidement. Les pirates n'attendent pas que votre analyse soit programmée.

L'utilisation d'outils cloisonnés fragmente le contexte. Les scanners, les rapports de tests d'intrusion, les inventaires d'actifs et les systèmes de gestion des tickets ne partagent souvent pas leurs données. Les équipes de sécurité finissent par devoir essayer manuellement de mettre en corrélation les résultats issus d'outils disparates afin de se faire une idée cohérente des risques réels.

Une hiérarchisation fondée uniquement sur la gravité génère des carnets de commandes ingérables. Un score CVSS vous indique, de manière théorique, le degré de gravité potentiel d'une vulnérabilité. Cela ne vous indique pas si cette vulnérabilité existe sur un système capable d'accéder à vos contrôleurs de domaine, ni si un code d'exploitation circule actuellement.

Aucune vérification permettant de s'assurer que les contrôles fonctionnent réellement. La plupart des programmes permettent de vérifier si un correctif a été déployé. Peu d'entre vous confirment que l'exposition est bel et bien terminée. Une vulnérabilité CVE corrigée sur un système mal configuré peut tout de même rester accessible par une autre voie.

Dans le cadre du CTEM, le terme « validation » peut désigner notamment la vérification de la possibilité réelle d'exploiter une vulnérabilité dans l'environnement, la confirmation de la couverture des contrôles face aux techniques pertinentes, ainsi que la revérification de l'élément ou de l'état concerné après correction.

Le déficit organisationnel. Les équipes de sécurité identifient des anomalies. Les équipes chargées de l'exploitation informatique sont responsables de la mise en œuvre des mesures correctives. En l'absence de processus de travail et de gouvernance communs, les vulnérabilités validées restent en attente d'une fenêtre de mise à jour dont le service de sécurité n'a aucune visibilité.

Pour les RSSI, cette lacune organisationnelle constitue souvent le problème le plus difficile à résoudre. Il s'agit autant d'un défi en matière de gouvernance, de gestion des risques et de responsabilité que d'un défi technique.

Le CTEM comble chacune de ces lacunes en considérant l'exposition aux risques liés à l' , ainsi que la réduction de ces risques , comme un programme continu et intégré. La section suivante explique en détail le fonctionnement de chaque étape.

[En savoir plus sur la méthodologie de gestion des menaces et des vulnérabilités]

Les cinq étapes du CTEM

Les cinq étapes du processus CTEM forment un cycle continu. Chaque étape alimente la suivante, et le cycle se répète à mesure que votre environnement évolue et que les menaces émergentes nécessitent une mise à jour des priorités en matière de périmètre, de détection et de validation.

Il est essentiel de bien comprendre l'ensemble du cycle CTEM, depuis la définition initiale du périmètre jusqu'à la mise en œuvre des mesures correctives validées, afin de concevoir un programme qui permette une réduction mesurable des risques, plutôt qu'une simple succession d'activités récurrentes.

1. Définition du périmètre

La définition du périmètre permet de déterminer quelles parties de l'environnement seront évaluées et comment l'exposition sera mesurée. Il ne s'agit pas uniquement d'un exercice technique. Cela nécessite un accord entre les acteurs de la sécurité et ceux de l'entreprise sur les niveaux d'actifs concernés pour chaque cycle, en se fondant autant sur les objectifs métier que sur les risques techniques.

Les décisions relatives au périmètre d'intervention doivent être réexaminées régulièrement, à mesure que les priorités de l'entreprise évoluent. Une fusion, le lancement d'un nouveau produit ou le passage au télétravail peuvent tous modifier la liste des actifs les plus critiques et, par conséquent, déterminer les risques qui nécessitent une attention prioritaire.

La surveillance continue de l'ensemble des éléments dans des environnements distribués implique des compromis, notamment en termes d'impact sur le réseau et de volume d'alertes. La définition du périmètre nécessite un accord négocié précisant quels niveaux d'actifs bénéficient d'une couverture continue, lesquels font l'objet d'une évaluation périodique, et qui est habilité à adapter ce périmètre à mesure que l'environnement évolue.

Que signifie « continu » d'un point de vue opérationnel ?
Tous les signaux d'un programme CTEM ne sont pas mis à jour à la même fréquence. Certaines sources de données, telles que l'état des terminaux et la télémétrie, peuvent être disponibles en temps quasi réel, tandis que d'autres (comme les analyses de vulnérabilité d' ) restent périodiques. Les organisations doivent définir des seuils acceptables en matière d'actualité des données pour chaque niveau d'actifs. Si une source de données est régulièrement obsolète, ses résultats doivent être considérés comme moins fiables jusqu’à ce qu’ils soient revalidés.
Les programmes CTEM échouent souvent lorsque les équipes partent du principe que toutes les données d’entrée sont d’une actualité équivalente. Dans la pratique, pour garantir la précision, il est nécessaire de mettre à jour en permanence les données d'inventaire et de valider la propriété et le contexte des actifs.

Les informations issues du renseignement sur les menaces éclairent les décisions relatives à la portée de l'analyse en mettant en évidence les types d'actifs qui sont activement ciblés. À mesure que le paysage des menaces évolue (par exemple, lorsque les acteurs malveillants commencent à cibler activement les appareils VPN), ces types d'actifs gagnent en priorité dans le cadre du cycle actuel.

[Découvrez comment les informations sur les cybermenaces orientent les décisions en matière de sécurité]

Une erreur courante au début consiste à considérer la définition de la portée comme un « énumération exhaustive ». Dans le cadre du CTEM, la phase de cadrage définit les enjeux et la manière dont la réussite est mesurée ; la phase de découverte recense ce qui existe dans le cadre de ce périmètre.

2. Découverte

La détection des ressources dans le cadre du CTEM permet de cartographier la surface d'attaque au-delà de l'inventaire traditionnel des ressources, en englobant les vulnérabilités, les erreurs de configuration, les ressources exposées vers l'extérieur, l'informatique fantôme et les expositions d'identité.

Dans les environnements vastes et complexes, l'analyse de plus de 50 000 terminaux nécessite généralement de combiner plusieurs méthodes de collecte, notamment la télémétrie des terminaux (lorsqu'elle est gérée), les données réseau et de scan, ainsi que les sources du plan de contrôle du cloud ou des services SaaS (API). Les approches basées sur des agents et celles sans agent présentent chacune des avantages et des inconvénients, et les différents environnements — sur site, dans le cloud et hybrides — posent des défis spécifiques. Chaque méthode présente également des différences en termes de couverture, d'actualité et de fiabilité, notamment en ce qui concerne les actifs éphémères.

L'informatique parallèle et les appareils non gérés constituent souvent les principales lacunes en matière de visibilité, car ils échappent totalement à la couverture des analyses standard et sont donc les plus susceptibles de receler des vulnérabilités non détectées.

Les applications SaaS posent un défi similaire. Les divisions opérationnelles adoptent souvent des outils basés sur le cloud sans consulter les services informatiques ou de sécurité, ce qui crée des risques qui n'apparaissent jamais dans les inventaires traditionnels des actifs.

L'identité et la propriété des actifs font partie de vos principaux résultats de recherche. Les constatations relatives à l'exposition qui ne peuvent être associées à un propriétaire entraînent systématiquement un blocage dans la mobilisation. Maintenez une correspondance fiable entre les identifiants techniques (nom d'hôte, ID d'instance, compte, locataire d'application) et les équipes métier qui en sont responsables.

C'est pourquoi la gestion de la surface d'attaque externe (EASM) est devenue un élément important de la phase de découverte. Les outils EASM offrent une visibilité en continu sur les ressources exposées à Internet, y compris celles qui ne figurent pas nécessairement dans les inventaires internes.

La détection des failles d'identité nécessite une intégration avec les données du fournisseur d'identité, et pas seulement une analyse des terminaux. Un compte de service disposant de droits d'administrateur de domaine et qui n'a pas été utilisé depuis 18 mois peut constituer une faille de sécurité, même s'il n'apparaît pas lors d'un scan de vulnérabilités.

3. Hiérarchisation des priorités

La hiérarchisation des risques se fonde sur l'exploitabilité, l'impact potentiel et la pertinence pour les attaquants, plutôt que sur la seule gravité selon le score CVSS.

Les volumes importants de résultats hors contexte sont souvent difficiles à mettre en œuvre ; pour établir des priorités, il faut prendre en compte la criticité des actifs, les signaux d'exploitation, le contexte de contrôle et la pertinence des chemins accessibles afin de cibler les efforts. Pour établir efficacement des priorités dans des contextes concrets, il faut :

  • Niveaux de criticité des actifs : Définis par l'organisation, et non par l'outil d'analyse
  • Signaux de disponibilité des exploits : Tels que l'EPSS (Exploit Prediction Scoring System) et le catalogue des vulnérabilités exploitées connues de la CISA
  • Analyse des voies d'attaque : . Cette analyse identifie les vulnérabilités permettant aux attaquants de se déplacer latéralement vers les actifs les plus stratégiques.

Une étape pratique pour établir des priorités consiste à distinguer les vulnérabilités accessibles depuis Internet de celles accessibles en interne, qui permettent un déplacement latéral.

Les risques liés à Internet ont tendance à retenir immédiatement l'attention. Cependant, les vulnérabilités accessibles en interne, telles que les risques liés à l'identité, les privilèges excessifs ou les relations de confiance mal configurées, peuvent constituer des vecteurs d'attaque à fort impact pour les ressources critiques.

Une hiérarchisation efficace tient compte de ces deux aspects. Elle pondère les vulnérabilités en fonction de leur accessibilité et de leur rôle dans la progression de l'attaquant, et non pas uniquement en fonction d'une gravité abstraite.

L'analyse des voies d'attaque consiste à déterminer comment un attaquant pourrait enchaîner plusieurs failles de sécurité afin d'atteindre des cibles de grande valeur. Ce contexte est essentiel à la prise de décision : il fait évoluer la hiérarchisation des priorités, qui passe d'un simple exercice de notation mécanique à un jugement fondé sur l'évaluation des risques, permettant de déterminer quelles expositions constituent la menace la plus crédible pour les actifs critiques de l'entreprise. Une vulnérabilité CVE présentant un score CVSS de 6 sur un actif adjacent à un contrôleur de domaine peut justifier une priorité plus élevée qu'une vulnérabilité CVSS de 9 sur une machine de développement isolée.

4. Validation

La validation permet de vérifier si les contrôles de sécurité détectent ou bloquent les techniques associées aux vulnérabilités jugées prioritaires, et de confirmer si ces vulnérabilités représentent un risque réel d'attaque dans l'environnement. Elle permet également de déterminer si les contrôles atténuent efficacement ces risques, en recourant à des approches telles que le « purple teaming », les tests ciblés ou la simulation d'attaques et de violations (BAS).

Deux modes de validation répondent à des objectifs différents à l'échelle de l'entreprise :

  • Validation adversaire : Les équipes « Red Team » et le BAS testent des scénarios d'attaque spécifiques visant des actifs critiques en simulant un comportement réaliste de la part d'un adversaire. Ce processus est périodique, mobilise d'importantes ressources et aboutit à des résultats très fiables.
  • Vérification continue de la correction (nouvelle vérification de l'actif/de l'état) : Permet de confirmer qu'une vulnérabilité spécifique a été corrigée sur un actif donné. Il peut s'exécuter automatiquement après la correction (lorsque la télémétrie et les workflows le permettent) et offre une assurance continue.

Dans la pratique, les organisations ont généralement tendance à privilégier un mode plutôt que l'autre, plutôt que de les combiner. La validation par simulation d'attaques est généralement périodique (souvent annuelle ou trimestrielle pour les scénarios à haut risque), mobilise d'importantes ressources et aboutit à des conclusions très fiables, tandis que la vérification continue des mesures correctives est mise en œuvre de manière moins systématique.

Les tests d'intrusion en sont un exemple courant : ils fournissent des informations précieuses sur la manière dont un attaquant pourrait exploiter des vulnérabilités à un moment donné, mais ils ne permettent pas de confirmer si ces vulnérabilités restent corrigées à mesure que l'environnement évolue. Un test d'intrusion réalisé en Q1 ne permet pas de valider l'état des contrôles en Q3.

C'est pourquoi la validation doit vérifier que deux conditions sont remplies :

  • La question est de savoir si cette vulnérabilité peut réellement être exploitée dans le contexte actuel ou si des contrôles appropriés empêchent cette technique d'attaque
  • Déterminer si l'exposition reste fermée au fil du temps, en tenant compte des dérives de configuration, des redéploiements ou des changements de politique susceptibles de réintroduire un risque

Sans ces deux vérifications, la remise en état peut sembler achevée alors que les conditions d'exposition réapparaissent sans que l'on s'en aperçoive.

[Comprenez en quoi la recherche de menaces diffère de la validation]

5. Mobilisation

Le service « Mobilisation » coordonne les mesures correctives entre les équipes de sécurité et informatiques. Les conclusions se traduisent par des mesures concrètes, avec une répartition claire des responsabilités et des échéances précises.

Les priorités en matière de remédiation doivent refléter les objectifs de l'entreprise. Une vulnérabilité confirmée sur un système essentiel à la génération de revenus justifie un délai de réaction différent de celui qui s'appliquerait à la même vulnérabilité sur un outil interne à faible niveau de criticité.

C'est à cette étape que la plupart des programmes CTEM d'entreprise s'enlisent. La section suivante aborde ce sujet en détail.

Le déficit de mobilisation

La mobilisation échoue lorsque le service de sécurité est responsable des constatations et que le service informatique est chargé des mesures correctives, mais qu'aucun des deux n'assume la responsabilité du transfert.

Le schéma est bien connu : le service de sécurité identifie une vulnérabilité validée, crée un ticket et attend, tandis que le service informatique l’ajoute à la liste des tâches en attente et la programme pour une prochaine fenêtre de modification de l’ . En attendant, la position reste ouverte.

Une mobilisation efficace nécessite également des voies d'exception explicites. Toutes les expositions validées ne peuvent pas attendre les fenêtres de modification standard.

Les organisations devraient définir des critères permettant de déterminer dans quels cas les résultats présentant un risque élevé peuvent déroger aux cycles de déploiement habituels, ainsi que des procédures claires d'approbation et de retour en arrière. En l'absence de ces procédures d'exception, les expositions validées entrent en concurrence avec les tâches opérationnelles courantes et restent souvent en suspens, bien qu'elles aient été classées par ordre de priorité.

Exigences en matière de gouvernance pour la correction automatisée. Toutes les détections ne peuvent pas déclencher une correction automatisée d . Les organisations doivent disposer de politiques claires précisant quels types de problèmes peuvent être résolus automatiquement et lesquels nécessitent un examen dans le cadre de la gestion du changement.

Une séquence de déploiement progressive, par anneaux, permet de limiter la portée des répercussions. Le déploiement progressif par anneaux signifie que les modifications sont mises en œuvre par étapes au sein des anneaux de déploiement : test, haute priorité, puis déploiement à grande échelle. Chaque cycle vérifie la stabilité avant que le suivant ne commence.

C'est l'intégration ITSM qui détermine si la mobilisation fonctionne. Les résultats du CTEM doivent être intégrés à votre système de gestion des tickets existant (ServiceNow Vulnerability Response en est un exemple courant) avec suffisamment de contexte pour que les équipes informatiques puissent intervenir sans qu'une étape de triage supplémentaire soit nécessaire.

Le ticket doit mentionner la vulnérabilité spécifique et les actifs concernés, le contexte métier et le niveau de criticité des actifs, les mesures correctives recommandées, ainsi que le SLA établi en fonction du risque validé.

Système métriqueCe qu'il mesure

Délai moyen de correction (MTTR) pour les anomalies critiques validées

Délai entre la validation et la mise en œuvre confirmée des mesures correctives
Taux de cession de propriétéPourcentage de constatations validées pour lesquelles un responsable a été désigné dans le cadre du SLA
Taux de réussite à l'examen de revalidationConstatations pour lesquelles la mise en conformité a été achevée et la revalidation obtenue, par rapport aux constatations classées sans revalidation

La mobilisation désigne la mise en œuvre coordonnée de mesures correctives déclenchée par un constat validé. Il ne s'agit pas d'une intervention en cas d'incident déclenchée par une menace active. Cette distinction revêt une importance particulière pour la gouvernance et la conception des processus.

Cela dit, les conclusions validées du CTEM devraient servir de base à l'élaboration des plans d'intervention. Les organisations qui identifient leurs principales vulnérabilités sont mieux à même de limiter les incidents et de s'en remettre si ces vulnérabilités venaient à être exploitées avant que les mesures correctives ne soient menées à bien.

Pour combler le déficit de mobilisation, il ne suffit pas de modifier les processus. Cela nécessite également de repenser le fonctionnement de la validation.

Validation des expositions réelles

C'est dans cette lacune de validation que la plupart des programmes suscitent une fausse confiance. Le suivi du déploiement des patchs ne revient pas à confirmer la résolution de la vulnérabilité. Un système corrigé peut toujours être accessible par une autre voie d'attaque si les configurations sous-jacentes ou les voies d'accès restent inchangées.

Une règle de pare-feu destinée à bloquer une technique d'attaque peut, dans la pratique, ne pas parvenir à la bloquer. C'est pourquoi la validation doit aller au-delà de la simple confirmation de la mise en place des mesures de sécurité. Il doit être vérifié qu'elles sont efficaces contre les techniques spécifiques qu'un attaquant utiliserait pour exploiter une vulnérabilité donnée. La validation permet de confirmer le risque réel, et pas seulement la gravité théorique.

Il existe deux modes de validation, chacun ayant un objectif différent :

  1. Validation adversaire : Les exercices de « red teaming » et les tests BAS permettent de vérifier si des scénarios d'attaque spécifiques parviennent à porter atteinte à des actifs critiques. Ce processus mobilise d'importantes ressources et a généralement lieu tous les trimestres ou une fois par an.
  2. Vérification continue de la correction (nouvelle vérification de l'actif/de l'état) : Permet de confirmer qu'une vulnérabilité spécifique a été corrigée sur un actif donné. Il s'exécute automatiquement après la correction et assure une assurance continue.

L'analyse du chemin d'attaque établit le lien entre les deux. Il répertorie les expositions qui, une fois enchaînées, permettent d'accéder aux actifs phares d' :. Ce contexte modifie l'ordre des priorités. Une vulnérabilité de gravité moyenne sur un élément d'infrastructure offrant un accès à vos contrôleurs de domaine est plus urgente qu'une vulnérabilité critique sur un système isolé.

Mesure de l'efficacité des contrôles. Le contrôle de sécurité (règle de pare-feu, politique EDR, correctif) bloque-t-il réellement la technique d'attaque associée à cette vulnérabilité ? Ou bien bloque-t-elle une autre technique tout en laissant la bonne ouverte ?

La validation étant désormais en place, la question suivante est de savoir comment CTEM s'intègre aux outils et aux processus que vous utilisez déjà.

Intégration du CTEM dans les processus existants

Mener le projet CTEM en parallèle est le moyen le plus rapide de créer des conflits de priorités au sein des opérations informatiques. Le service de sécurité insiste pour que des mesures correctives soient prises immédiatement ; le service informatique fonctionne selon des cycles de changement de deux semaines. L'objectif est l'intégration dans les flux de travail existants, et non la création d'un nouveau processus parallèle à ceux-ci.

Lorsqu'il est correctement mis en œuvre, le CTEM contribue à rationaliser les opérations en réduisant les transferts manuels, en éliminant les étapes de triage redondantes et en accélérant le passage des résultats validés vers les mesures correctives.

  • Intégration ITSM : les résultats du CTEM d' sont transférés vers votre système de gestion des tickets existant. La structure du ticket est essentielle : elle doit fournir suffisamment d'informations contextuelles (importance stratégique de l'actif, risque validé, action recommandée, SLA) pour permettre aux équipes informatiques d'intervenir sans qu'il soit nécessaire de transmettre le dossier à un autre service.
  • Le SIEM comme source d'informations pour la définition du périmètre et l'analyse exploratoire : Les données SIEM mettent en évidence les menaces actives ainsi que les comportements anormaux qui permettent de déterminer quels actifs sont concernés par le cycle CTEM en cours. Il s'agit d'un complément au programme, et non d'un substitut à celui-ci.
  • Éviter le problème des processus parallèles : Les organisations qui gèrent le CTEM comme un programme de sécurité distinct créent des conflits de priorités pour les opérations informatiques. Le service de sécurité exige une correction immédiate. Le service informatique fonctionne selon des cycles de changement de deux semaines. En l'absence de gestion des exceptions pour les résultats validés critiques, le conflit est de nature structurelle.
  • Compatibilité avec la gestion du changement informatique : Le déploiement progressif par anneaux et les fenêtres de changement sont compatibles avec la mobilisation CTEM si le modèle de gouvernance est conçu à cet effet. L'essentiel est de mettre en place des procédures d'exception pour les constatations critiques validées qui ne peuvent pas attendre la prochaine fenêtre de maintenance prévue.

Le CTEM est particulièrement efficace lorsqu’il fait office de couche de liaison au sein de votre infrastructure de sécurité : il recueille les données provenant du SIEM, des scanners de vulnérabilité, des fournisseurs d’identité et des systèmes de gestion des actifs, puis transmet les résultats hiérarchisés et validés à l’ITSM afin de coordonner les mesures correctives.

Cette évolution vers des flux de travail intégrés reflète les tendances générales du marché. Les entreprises délaissent les outils ponctuels et fragmentés au profit de plateformes qui regroupent la détection, la hiérarchisation, la validation et la correction. L'objectif est de transformer les risques identifiés en actions coordonnées, afin de favoriser une culture de la sécurité proactive.

Une fois le CTEM intégré aux processus existants, l'étape suivante consiste à évaluer où en est votre programme à l'heure actuelle.

Maturité du programme CTEM

Où en est votre programme aujourd'hui ? Trois niveaux de maturité constituent un cadre d'auto-évaluation.

Niveau 1 : ponctuel/réactif

Des analyses de vulnérabilité sont effectuées régulièrement. Les vulnérabilités sont classées par ordre de priorité en fonction du seul score CVSS. La responsabilité de la remise en état n'est pas clairement établie. Aucune validation officielle ne confirme que les corrections fonctionnent. À ce niveau, les risques liés à la sécurité sont traités de manière réactive, généralement à la suite d'un incident ou d'une constatation d'audit, plutôt que dans le cadre d'un programme structuré et continu. Les services de sécurité et informatiques fonctionnent à partir de systèmes distincts, avec des transferts manuels.

Niveau 2 : Périodique/structuré

Les calendriers d'analyse définis sont liés aux niveaux de criticité des actifs. L' de hiérarchisation fondée sur les risques tient compte du contexte des actifs. Il existe un processus officiel de gestion des tickets entre le service de sécurité et le service informatique. Des tests d'intrusion ou des analyses BAS sont effectués au moins une fois par an. Le MTTR est suivi pour les constatations critiques.

Niveau 3 : En continu / automatisé

Au niveau 3, le programme fonctionne comme un système continu et auto-renforçant : visibilité en temps réel sur l'ensemble des terminaux, hiérarchisation automatisée à l'aide des données EPSS et CISA KEV, intégration ITSM avec création automatisée de tickets et suivi des SLA, vérification continue des mesures correctives, gouvernance du déploiement par anneaux et indicateurs de mobilisation communiqués au niveau du programme. Il en résulte une opération de sécurité dans laquelle la réduction des risques est mesurable, et non pas simplement supposée.

Ce qui permet à une organisation de passer du niveau 1 au niveau 2 relève généralement d'une décision de gouvernance, et non d'un choix d'outils. La définition des niveaux de criticité des actifs, la mise en place de modèles de responsabilité et la création de procédures formelles de transfert ne nécessitent pas de nouvelles technologies.

Ce qui permet à une organisation de passer du niveau 2 au niveau 3 , c'est généralement un choix en matière d'outils et d'intégration. La visibilité en temps réel, la hiérarchisation automatisée et la validation continue nécessitent des fonctionnalités de plateforme que les outils d'analyse périodique d' s ne fournissent pas.

Quel que soit le niveau de maturité, l'objectif reste le même : concentrer les efforts de sécurité sur les vulnérabilités qui présentent le plus grand risque concret pour l'entreprise, plutôt que de mener des actions qui ne se traduisent pas par une réduction mesurable des risques.

Les niveaux de maturité constituent un cadre d'auto-évaluation. Les indicateurs permettent de suivre les progrès réalisés.

Comment évaluer le succès du CTEM

Les indicateurs qui comptent sont les indicateurs de résultats, et non les indicateurs d'activité. Le nombre de tickets et la fréquence de lecture vous permettent de déterminer le niveau d'activité du programme. Le MTTR sur les anomalies critiques validées vous permet de savoir si le système fonctionne correctement.

Système métriqueCe qu'il mesureNiveau de maturité
MTTR pour les anomalies critiques validéesDélai entre la validation et la mise en œuvre confirmée des mesures correctivesNiveau 2+
Durée de la fenêtre d'expositionCombien de temps les risques hautement prioritaires restent-ils sans solution ?Niveau 2+
Couverture de validationPourcentage d'actifs critiques et de voies d'attaque validés au cours du cycle actuelNiveau 3
Réduction du taux de faux positifsBaisse du nombre de résultats dont la validation confirme qu’ils ne sont pas réellement exploitablesNiveau 3
Évolution des scores de risqueÉvolution de la posture de sécurité d'une organisation au fil du temps, à l'aide d'une méthodologie de notation cohérenteNiveau 2+

Les organisations de niveau 2 suivent généralement l'évolution du MTTR et du score de risque. Les organisations de niveau 3 ajoutent la couverture de validation et la durée de la fenêtre d'exposition comme indicateurs principaux.

Maintenant que l'on dispose d'une vision claire des exigences du CTEM et de la manière d'évaluer les progrès réalisés, la dernière question qui se pose est de savoir dans quelle mesure les différentes plateformes prennent en charge ce cadre.

Comment Tanium facilite la gestion continue de l'exposition aux menaces

De nombreux programmes CTEM piétinent car les outils qui identifient les risques ne sont pas les mêmes que ceux qui permettent d'y remédier. Tanium contribue à combler ce fossé.

La plateforme informatique autonome de Tanium, « », offre aux équipes de sécurité et informatiques une plateforme unique et unifiée pour l'identification, la hiérarchisation, la correction et la validation post-correction, ce qui permet au cycle de se dérouler sans transfert vers des systèmes déconnectés ni attente de l'actualisation de données d'analyse obsolètes.

Une découverte continue grâce à des informations en temps réel sur les terminaux

Tanium offre une visibilité en temps réel sur l'état des terminaux gérés, ce qui permet aux équipes d'identifier les ressources et les modifications au fur et à mesure qu'elles se produisent, plutôt que de se fier uniquement à des analyses périodiques. Tanium permet d'étendre la couverture aux appareils non gérés, qu'ils se trouvent dans des environnements sur site, distants ou dans le cloud, contribuant ainsi à réduire les angles morts généralement associés à l'informatique parallèle.

Une hiérarchisation des priorités fondée sur l'évaluation des risques et tenant compte du contexte

Tanium facilite la hiérarchisation des priorités en fonction des risques grâce à plusieurs fonctionnalités. Par exemple, Tanium Benchmark permet de déterminer des scores de risque en temps réel et de comparer les indicateurs d'un client à ceux de ses pairs du secteur, aidant ainsi les équipes à concentrer leurs efforts de correction là où le risque est le plus élevé par rapport à leur environnement. La solution « Tanium Guardian » permet aux organisations de faire face aux vulnérabilités de type « zero-day » et aux failles nécessitant une intervention urgente, grâce à l'association d'une analyse en temps réel des terminaux et d'analyses ciblées ainsi que d'options de correction proposées par les experts en sécurité de Tanium.

De l'évaluation à l'action sur une seule et même plateforme

Tanium permet aux équipes de passer de l'identification des vulnérabilités à la mise en œuvre de mesures correctives sans avoir à changer d'outils ni de sources de données. Il est possible de donner suite aux résultats directement depuis la même plateforme, qu'il s'agisse de la gestion des correctifs , de la gestion des ou de modifications de configuration, ce qui contribue à réduire les délais entre la détection et la correction.

Validation continue de la réduction des risques

Plutôt que de partir du principe que les mesures correctives sont efficaces, Tanium permet aux équipes de vérifier les changements intervenus dans l'état des terminaux après la mise en œuvre de ces mesures, en utilisant les mêmes données en temps réel que celles utilisées pour la détection. Cela permet de vérifier en permanence si les expositions ont bien été réduites, et pas seulement si les mesures correctives ont été enregistrées comme achevées.

Foire aux questions sur le CTEM

La mise en place d'un programme CTEM soulève des questions concrètes quant aux avantages du CTEM, à sa comparaison avec ce dont vous disposez déjà, à ce qu'il faut réellement pour le faire fonctionner, et à la question de savoir si cet investissement se traduit par une réduction mesurable des risques. Voici ce que vous devez savoir.

Quelle est la différence entre le CTEM et la gestion traditionnelle des vulnérabilités ?

La gestion des vulnérabilités vise à identifier et à corriger les failles connues (souvent des CVE) selon un calendrier défini.

Le CTEM est un modèle opérationnel plus global qui identifie en permanence les éléments critiques, détecte les conditions d'exposition sur l'ensemble de la surface d'attaque, établit des priorités en fonction de la probabilité réelle d'une attaque et de son impact sur l'activité, vérifie la vulnérabilité et l'efficacité des contrôles, et met en œuvre des mesures correctives en attribuant clairement les responsabilités.

Quelle est la différence entre l'ASM et le CTEM ?

La gestion de la surface d'attaque (ASM) vise principalement à identifier et à recenser les actifs exposés vers l'extérieur ainsi que les vulnérabilités, tandis que le CTEM fonctionne comme un programme complet qui prend en compte les expositions internes et externes, vérifie si celles-ci représentent un risque concret et coordonne les mesures correctives via les workflows informatiques existants.

Quels sont les outils qui soutiennent un programme CTEM ?

Le CTEM n'est pas une catégorie de produits, mais un programme qui s'applique à plusieurs types d'outils liés à chacune des cinq étapes du cycle :

  • La définition du périmètre d' s'appuie sur des plateformes de renseignements sur les menaces, la base de données de gestion des configurations (CMDB) et les systèmes d'inventaire des actifs d' , ainsi que sur les données SIEM, afin de déterminer quels niveaux d'actifs sont concernés pour chaque cycle et lesquels sont les plus activement ciblés.
  • La découverte nécessite des scanners de vulnérabilité, des plateformes de gestion des terminaux basées sur des agents, des outils EASM et des données provenant de fournisseurs d'identité.
  • Les outils d' s de hiérarchisation des priorités doivent intégrer l'EPSS et le catalogue KEV de la CISA, parallèlement à l'analyse des voies d'attaque, et ne pas se limiter aux scores CVSS.
  • L' de la validation (la lacune la plus courante) nécessite des outils de simulation de violations et d'attaques (BAS) ou des capacités de vérification continue des mesures correctives, permettant de confirmer qu'une correction spécifique a bien éliminé une vulnérabilité précise, et pas seulement qu'un correctif a été déployé.
  • La mobilisation dépend de l'intégration ITSM (; ServiceNow est une solution couramment adoptée par les entreprises) et de la présence d'informations contextuelles suffisantes dans chaque ticket pour permettre aux équipes informatiques d'intervenir sans étape de triage supplémentaire.

Et c'est justement cette dernière fonctionnalité — qui permet de vérifier que l'exposition est bien fermée — que la plupart des suites d'outils ne parviennent toujours pas à offrir de manière systématique.

En quoi la gestion continue de l'exposition aux menaces améliore-t-elle la résilience en matière de cybersécurité ?

Le CTEM vise à renforcer la résilience en réduisant le délai entre le moment où une exposition à haut risque est constatée et celui où l'on confirme qu'elle a pris fin. Les cycles continus remplacent les programmes d'analyse périodiques qui laissent de nouvelles vulnérabilités non détectées pendant des jours, voire des semaines. Une hiérarchisation fondée sur les risques, qui tient compte de la criticité des actifs, de la disponibilité des exploits et de l'analyse des voies d'attaque, permet de concentrer les efforts de correction sur les vulnérabilités susceptibles d'atteindre réellement les actifs critiques, plutôt que de générer des listes de tâches en attente classées selon des scores de gravité abstraits.

L'un des avantages moins évidents de la cyber-résilience d' , , réside dans la validation de l'efficacité des contrôles. Un système corrigé, s'il se trouve sur un hôte mal configuré, peut tout de même faire l'objet d'une exploitation via une autre voie d'attaque. La phase de validation du CTEM permet de vérifier que les mesures de contrôle sont efficaces contre les techniques spécifiques associées à une exposition donnée, et pas seulement qu'une mesure corrective a été enregistrée comme achevée.

Les organisations qui procèdent à des validations en continu sont mieux préparées lors de la gestion des incidents, car elles ont déjà vérifié quelles mesures de sécurité sont efficaces dans des conditions réelles, plutôt que de le découvrir au moment où cela compte le plus.

Découvrez comment les informations en temps réel sur les terminaux soutiennent votre programme CTEM. Prenez rendez-vous pour une démonstration à l'adresse afin de découvrir comment Tanium aide les entreprises à réduire leur exposition aux risques grâce à une visibilité en continu et à des mesures correctives intégrées.