Mesure du temps nécessaire à l'application des correctifs : Une approche d'analyse de survie utilisant Qualys et Elastic

Introduction

Il est essentiel de comprendre la rapidité avec laquelle les vulnérabilités sont corrigées dans les différents environnements et équipes pour maintenir un niveau de sécurité élevé. Dans cet article, nous décrivons comment nous avons appliqué l'analyse de survie aux données de gestion des vulnérabilités (VM) de Qualys VMDR, en utilisant la pile Elastic. Cela nous a permis non seulement de confirmer des hypothèses générales sur la vélocité des équipes (la rapidité avec laquelle les équipes terminent leur travail) et la capacité de remédiation (la quantité de correctifs qu'elles peuvent prendre en charge), mais aussi de tirer des conclusions mesurables. Comme la plupart de nos données de sécurité se trouvent dans la pile Elastic, ce processus devrait être facilement reproductible à d'autres sources de données de sécurité.

Pourquoi nous l'avons fait

Notre principale motivation était de passer d'hypothèses générales à des idées étayées par des données concernant :

• La rapidité avec laquelle les différentes équipes et les différents environnements corrigent les vulnérabilités
• si la performance des correctifs répond aux objectifs internes de niveau de service (SLO)
• Où les goulets d'étranglement ou les retards se produisent-ils le plus souvent ?
• Quels sont les autres facteurs susceptibles d'affecter les performances des correctifs ?

Pourquoi l'analyse de survie ? Une meilleure alternative à la durée moyenne de remédiation

Le délai moyen de correction (MTTR) est couramment utilisé pour suivre la rapidité avec laquelle les vulnérabilités sont corrigées, mais la moyenne et la médiane souffrent toutes deux de limitations importantes (nous en donnons un exemple plus loin dans cet article). La moyenne est très sensible aux valeurs aberrantes[^1] et suppose que les délais d'assainissement sont équilibrés autour du délai d'assainissement moyen, ce qui est rarement le cas dans la pratique. La médiane est moins sensible aux extrêmes, mais elle ne fournit pas d'informations sur la forme de la distribution et ne dit rien sur la longue queue des vulnérabilités qui tardent à être corrigées. Aucun des deux ne tient compte des cas non résolus, c'est-à-dire des vulnérabilités qui restent ouvertes au-delà de la fenêtre d'observation, et qui sont souvent entièrement exclues. Dans la pratique, les vulnérabilités qui restent ouvertes le plus longtemps sont précisément celles qui devraient nous préoccuper le plus.

L'analyse de survie permet de pallier ces limites. Issue de la médecine et de l'actuariat, elle modélise des données temporelles en incorporant explicitement des observations censurées, c'est-à-dire, dans notre contexte, des vulnérabilités qui restent ouvertes. (Pour plus de détails sur son application à la gestion des vulnérabilités, nous vous recommandons vivement "The Metrics Manifesto"). Au lieu de regrouper les mesures correctives en un seul chiffre, l'analyse de survie estime la probabilité qu'une vulnérabilité reste non corrigée au fil du temps (par ex. 90% des vulnérabilités sont corrigées dans les 30 jours). Cela permet des évaluations plus significatives, telles que la proportion de vulnérabilités corrigées dans les délais impartis (par exemple dans les 30, 90 ou 180 jours).

L'analyse de survie nous fournit une fonction de survie qui estime la probabilité qu'une vulnérabilité reste non corrigée au fil du temps.

:: : Cette méthode offre une meilleure vision de la performance de la remédiation, nous permettant d'évaluer non seulement la durée de persistance des vulnérabilités, mais aussi la manière dont le comportement de remédiation diffère selon les systèmes, les équipes ou les niveaux de gravité. Elle est particulièrement bien adaptée aux données relatives à la sécurité, qui sont souvent incomplètes, biaisées et réfractaires aux hypothèses de normalité. :: :

Contexte

Bien que nous ayons appliqué l'analyse de survie à différents environnements, équipes et organisations, nous nous concentrons dans ce blog sur les résultats de l'environnement de production d'Elastic Cloud.

Calcul de l'âge de vulnérabilité

Il existe différentes méthodes pour calculer l'âge de vulnérabilité.

Pour nos mesures internes telles que l'adhésion à la vulnérabilité SLO, nous définissons l'âge de la vulnérabilité comme la différence entre la date à laquelle une vulnérabilité a été trouvée pour la dernière fois et la date à laquelle elle a été détectée pour la première fois (généralement quelques jours après la publication). Cette approche vise à pénaliser les vulnérabilités qui sont réintroduites à partir d'une image de base obsolète. Dans le passé, nos images de base n'étaient pas mises à jour assez fréquemment pour nous satisfaire. Si une nouvelle instance est créée, les vulnérabilités peuvent avoir un âge significatif (par exemple, 100 jours) à partir du premier jour de leur découverte.

Pour cette analyse, il nous semble plus pertinent de calculer l'âge sur la base du nombre de jours entre la dernière date de découverte et la première date de découverte. Dans ce cas, l'âge représente le nombre de jours pendant lesquels le système a été effectivement exposé.

Stratégie du "tout rapiécer".

Dans notre environnement en nuage, nous appliquons une politique consistant à tout patcher. En effet, nous utilisons presque exclusivement la même image de base dans toutes les instances. Comme Elastic Cloud fonctionne entièrement sur des conteneurs, il n'y a pas de paquets d'applications spécifiques (par exemple, Elasticsearch) installés directement sur nos systèmes. Notre flotte reste donc homogène.

Pipeline de données

L'ingestion et le mappage des données dans Elastic Stack peuvent être fastidieux. Heureusement, nous avons de nombreuses intégrations de sécurité qui gèrent cela de manière native, Qualys VMDR étant l'une d'entre elles.

Cette intégration a 3 un intérêt majeur par rapport aux méthodes d'ingestion personnalisées (par ex. scripts, rythmes, ...) :

• Il enrichit nativement les données sur les vulnérabilités à partir de la base de connaissances Qualys en y ajoutant les identifiants CVE, les informations sur les menaces, ... sans qu'il soit nécessaire de configurer des pipelines d'enrichissement.
• Les données Qualys sont déjà mappées sur le schéma Elastic Common Schema qui est une manière standardisée de représenter les données, qu'elles proviennent d'une source ou d'une autre : par exemple, les CVE sont toujours stockés dans le champ vulnerability.id, indépendamment de la source.
• Une transformation avec la dernière vulnérabilité est déjà en place. Cet index peut être interrogé pour obtenir l'état des dernières vulnérabilités.

Configuration de l'intégration de l'agent Qualys

Pour l'analyse de survie, nous avons besoin d'ingérer à la fois les vulnérabilités actives et les vulnérabilités corrigées. Pour analyser une période spécifique, nous devons définir le nombre de jours dans le champ max_days_since_detection_updated. Dans notre environnement, nous ingérons les données Qualys quotidiennement, il n'est donc pas nécessaire d'ingérer un long historique de données fixes, car nous l'avons déjà fait.

L'intégration de l'agent élastique Qualys VMDR a été configurée comme suit :

Une fois les données entièrement intégrées, elles peuvent être examinées soit dans Kibana Discover (logs-* data view -> data_stream.dataset : "qualys_vmdr.asset_host_detection" ), soit dans l'application Kibana Security App (Findings -> Vulnerabilities).

Chargement de données en Python avec le client elasticsearch

Étant donné que le calcul de l'analyse de survie sera effectué en Python, nous devons extraire les données d'elastic dans un cadre de données Python. Il y a plusieurs façons d'y parvenir et, dans cet article, nous nous concentrerons sur deux d'entre elles.

Avec ES|QL

Le moyen le plus simple et le plus pratique est d'utiliser ES|QL avec le format flèche. Il remplira automatiquement le cadre de données python (lignes et colonnes). Nous vous recommandons de lire l'article de blog From ES|QL to native Pandas dataframes in Python pour obtenir plus de détails.

from elasticsearch import Elasticsearch
import pandas as pd

client = Elasticsearch(
    "https://[host].elastic-cloud.com",
    api_key="...",
)

response = client.esql.query(
    query="""
   FROM logs-qualys_vmdr.asset_host_detection-default
    | WHERE elastic.owner.team == "platform-security" AND elastic.environment == "production"
    | WHERE qualys_vmdr.asset_host_detection.vulnerability.is_ignored == FALSE
    | EVAL vulnerability_age = DATE_DIFF("day", qualys_vmdr.asset_host_detection.vulnerability.first_found_datetime, qualys_vmdr.asset_host_detection.vulnerability.last_found_datetime)
    | STATS 
        mean=AVG(vulnerability_age), 
        median=MEDIAN(vulnerability_age)
    """,
    format="arrow",
)
df = response.to_pandas(types_mapper=pd.ArrowDtype)
print(df)

Aujourd'hui, nous avons une limitation avec ESQL : nous ne pouvons pas paginer dans les résultats. Nous sommes donc limités à 10 000 documents de sortie (100 000 si la configuration du serveur est modifiée). Les progrès peuvent être suivis grâce à cette demande d'amélioration.

Avec DSL

Dans le client python d'elasticsearch, il existe une fonctionnalité native permettant d'extraire toutes les données d'une requête avec une pagination transparente. La difficulté consiste à créer la requête DSL. Nous vous recommandons de créer la requête dans Discover, puis de cliquer sur Inspect, puis sur l'onglet Request pour obtenir la requête DSL.

query = {
    "track_total_hits": True,
    "query": {
        "bool": {
            "filter": [
                {
                    "match": {
                        "elastic.owner.team": "awesome-sre-team"
                    }
                },
                {
                    "match": {
                        "elastic.environment": "production"
                    }
                },
                {
                    "match": {
"qualys_vmdr.asset_host_detection.vulnerability.is_ignored": False
                    }
                }
            ]
        }
    },
    "fields": [
        "@timestamp",
        "qualys_vmdr.asset_host_detection.vulnerability.unique_vuln_id",
        "qualys_vmdr.asset_host_detection.vulnerability.first_found_datetime",
        "qualys_vmdr.asset_host_detection.vulnerability.last_found_datetime",
        "elastic.vulnerability.age",
        "qualys_vmdr.asset_host_detection.vulnerability.status",
        "vulnerability.severity",
        "qualys_vmdr.asset_host_detection.vulnerability.is_ignored"
    ],
    "_source": False
}

results = list(scan(
        client=es,
        query=query,
        scroll='30m',
        index=source_index,
        size=10000,
        raise_on_error=True,
        preserve_order=False,
        clear_scroll=True
    ))

Analyse de survie

Vous pouvez vous référer au code pour le comprendre ou le reproduire sur votre jeu de données.

Ce que nous avons appris

En nous appuyant sur les recherches de l'Institut Cyentia, nous avons examiné différentes façons de mesurer le temps nécessaire pour remédier aux vulnérabilités en utilisant des moyennes, des médianes et des courbes de survie. La comparaison est importante car, selon la méthode utilisée, nous pourrions tirer des conclusions très différentes sur la manière dont les vulnérabilités sont traitées.

La première méthode se concentre uniquement sur les vulnérabilités qui ont déjà été comblées. Il calcule le temps médian et moyen qu'il a fallu pour les réparer. Cette méthode est intuitive et simple, mais elle ne tient pas compte d'une partie potentiellement importante des données (les vulnérabilités encore ouvertes). Par conséquent, il tend à sous-estimer le temps réel nécessaire pour remédier à la situation, en particulier si certaines vulnérabilités restent ouvertes beaucoup plus longtemps que d'autres.

La seconde méthode tente d'inclure les vulnérabilités ouvertes et fermées en utilisant la durée pendant laquelle elles ont été ouvertes jusqu'à présent. Il existe de nombreuses options pour déterminer approximativement le délai de correction des vulnérabilités ouvertes, mais pour des raisons de simplicité, nous avons supposé qu'elles étaient (seront ?) corrigées au moment de la publication du rapport, ce qui, nous le savons, n'est pas le cas. Mais elle offre un moyen de tenir compte de leur existence.

La troisième méthode utilise l'analyse de survie. Plus précisément, nous avons utilisé l'estimateur de Kaplan-Meier pour modéliser la probabilité qu'une vulnérabilité soit toujours ouverte à un moment donné. Cette méthode traite les vulnérabilités ouvertes de manière appropriée : au lieu de prétendre qu'elles sont corrigées, elle les traite comme des données "censurées". La courbe de survie qu'il produit diminue avec le temps, montrant la proportion de vulnérabilités encore ouvertes au fil des jours ou des semaines.

Quelle est la durée de vie des vulnérabilités ?

Dans l'instantané actuel de 6 mois[^2], le délai de mise en place d'un correctif pour les systèmes fermés uniquement est de ~33 jours en médiane et de ~35 jours en moyenne. À première vue, cela semble raisonnable, mais la courbe de Kaplan-Meier montre ce que ces chiffres cachent : à 33 jours, ~54% sont encore ouverts ; à 35 jours, ~46% sont encore ouverts. Ainsi, même après le délai "normal" d'un mois, près de la moitié des problèmes n'ont pas été résolus.

Nous avons également calculé les statistiques observées jusqu'à présent (en traitant les vulnérabilités ouvertes comme si elles avaient été corrigées à la fin de la fenêtre de mesure). Dans cette fenêtre, ils sont presque identiques (médiane ~33 jours, moyenne ~35 jours) parce que l'âge des objets ouverts aujourd'hui est proche d'un mois. Cette coïncidence peut rendre les moyennes rassurantes, mais elle est fortuite et instable : si nous déplaçons l'instantané juste avant l'introduction du correctif mensuel, ces mêmes statistiques chutent brusquement (nous avons observé une médiane d'environ 19 jours et une moyenne d'environ 15 jours) sans que le processus sous-jacent n'ait changé.

La courbe de survie évite ce piège, car elle répond à la question "% toujours ouvert après 30/60/90 jours", et offre une visibilité sur la longue traîne qui reste ouverte bien au-delà d'un mois.

Patch tout partout de la même façon ?

L'analyse de survie stratifiée pousse plus loin l'idée des courbes de survie. Au lieu d'examiner toutes les vulnérabilités en une seule fois, elle les sépare en groupes (ou "strates") sur la base d'une caractéristique significative. Dans notre analyse, nous avons stratifié les vulnérabilités en fonction de leur gravité, de la criticité des actifs, de l'environnement, du fournisseur de services en nuage, de l'équipe, de la division ou de l'organisation. Chaque groupe a sa propre courbe de survie et, dans le graphique de l'exemple, nous comparons la rapidité avec laquelle les différentes vulnérabilités sont corrigées au fil du temps.

L'avantage de cette approche est qu'elle met en évidence des différences qui seraient autrement cachées dans l'agrégat. Si nous n'examinons que la courbe de survie globale, nous ne pouvons que tirer des conclusions sur les performances de l'assainissement dans son ensemble. Mais la stratification révèle si certaines équipes, certains environnements ou certains problèmes de gravité sont traités plus rapidement que les autres et, dans notre cas, si la stratégie "patch everything" est effectivement cohérente. Ce niveau de détail est important pour apporter des améliorations ciblées, car il nous aide à comprendre non seulement combien de temps prend la remédiation en général, mais aussi s'il existe de véritables goulets d'étranglement et où ils se trouvent.

À quelle vitesse les équipes agissent-elles ?

Alors que la courbe de survie met l'accent sur la durée pendant laquelle les vulnérabilités restent ouvertes, nous pouvons inverser la perspective en utilisant plutôt la fonction de distribution cumulative (FDC). Le CDF se concentre sur la rapidité avec laquelle les vulnérabilités sont corrigées, en montrant la proportion de vulnérabilités qui ont été corrigées à un moment donné.

Notre choix de tracer la CDF donne une image claire de la vitesse de remédiation, mais il est important de noter que cette version n'inclut que les vulnérabilités qui ont été corrigées dans la fenêtre temporelle observée. Contrairement à la courbe de survie que nous calculons sur une cohorte glissante de 6 mois pour saisir les cycles de vie complets, la FCD est calculée mois par mois sur les articles clôturés au cours de ce mois[^3].

En tant que tel, il nous indique la rapidité avec laquelle les équipes remédient aux vulnérabilités une fois qu'elles l'ont fait, et ne reflète pas la durée pendant laquelle les vulnérabilités non résolues restent ouvertes. Par exemple, nous constatons que 83,2% des vulnérabilités comblées au cours du mois actuel ont été résolues dans les 30 jours suivant la première détection. Cela met en évidence la vitesse d'application des correctifs récents et efficaces, mais ne tient pas compte des vulnérabilités plus anciennes qui restent ouvertes et dont le délai d'application des correctifs est susceptible d'être plus long. Par conséquent, nous utilisons la FCD pour comprendre le comportement de réaction à court terme, tandis que la dynamique du cycle de vie complet est donnée par une combinaison de la FCD et de l'analyse de survie : la FCD décrit la rapidité avec laquelle les équipes agissent une fois qu'elles ont trouvé une solution, tandis que la courbe de survie montre combien de temps les vulnérabilités durent réellement.

Différence entre l'analyse de survie et la moyenne/médiane

Attendez, nous avons dit que l'analyse de survie est préférable pour analyser le temps écoulé jusqu'à la mise en place du patch afin d'éviter l'impact des valeurs aberrantes. Mais dans cet exemple, l'analyse moyenne/médiane et l'analyse de survie donnent des résultats similaires. Quelle est la valeur ajoutée ? La raison en est simple : nous n'avons pas de valeurs aberrantes dans nos environnements de production, car notre processus de correction est entièrement automatisé et efficace.

Pour démontrer l'impact sur des données hétérogènes, nous utiliserons un exemple obsolète d'un environnement de non-production dépourvu de correctifs automatisés.

Requête ESQL :

FROM qualys_vmdr.vulnerability_6months
  | WHERE elastic.environment == "my-outdated-non-production-environment"
  | WHERE qualys_vmdr.asset_host_detection.vulnerability.is_ignored == FALSE
  | EVAL vulnerability_age = DATE_DIFF("day", qualys_vmdr.asset_host_detection.vulnerability.first_found_datetime, qualys_vmdr.asset_host_detection.vulnerability.last_found_datetime)
  | STATS
      count=COUNT(*),
      count_closed_only=COUNT(*) WHERE qualys_vmdr.asset_host_detection.vulnerability.status == "Fixed",
      mean_observed_so_far=MEDIAN(vulnerability_age),
      mean_closed_only=MEDIAN(vulnerability_age) WHERE qualys_vmdr.asset_host_detection.vulnerability.status == "Fixed",
      median_observed_so_far=MEDIAN(vulnerability_age),
      median_closed_only=MEDIAN(vulnerability_age) WHERE qualys_vmdr.asset_host_detection.vulnerability.status == "Fixed"

Dans cet exemple, l'utilisation de la moyenne et de la médiane donne des résultats très différents. Le choix d'une seule mesure représentative peut s'avérer difficile et potentiellement trompeur. Le graphique de l'analyse de survie représente avec précision notre efficacité à traiter les vulnérabilités dans cet environnement.

Réflexions finales

Les avantages de l'analyse de survie ne tiennent pas seulement à la précision des mesures, mais aussi à la compréhension de la dynamique du comportement en matière de correctifs, qui montre où se situent les goulets d'étranglement, quels sont les facteurs qui influent sur la vitesse des correctifs et s'ils sont conformes à nos objectifs stratégiques de développement. Du point de vue de l'intégration technique, l'utilisation de l'analyse de survie dans le cadre de nos flux de travail opérationnels et de nos rapports peut être réalisée avec un minimum de changements supplémentaires dans notre configuration Elastic Stack actuelle : l'analyse de survie peut être exécutée à la même cadence que notre cycle de correctifs, les résultats étant repoussés dans Kibana pour la visualisation. L'avantage définitif est d'associer nos mesures opérationnelles existantes à l'analyse de survie pour les tendances à long terme et le suivi des performances à court terme.

À l'avenir, nous expérimentons de nouvelles mesures telles que le taux d'arrivée, le taux d'épuisement et le taux d'évasion, qui nous permettront de comprendre de manière plus dynamique comment les vulnérabilités sont réellement traitées.

Le taux d'arrivée est la mesure de la vitesse à laquelle les nouvelles vulnérabilités pénètrent dans l'environnement. Le fait de savoir que cinquante nouveaux CVE apparaissent chaque mois, par exemple, nous indique à quoi nous attendre dans la charge de travail avant même de commencer à mesurer les correctifs. Le taux d'arrivée est donc un indicateur qui ne renseigne pas nécessairement sur l'arriéré, mais plutôt sur la pression exercée sur le système.

Le taux d'élimination (tendance) montre l'autre moitié de l'équation : la vitesse à laquelle les vulnérabilités sont corrigées par rapport à la vitesse à laquelle elles arrivent.

Le taux d'évasion ajoute encore une autre dimension en se concentrant sur les vulnérabilités qui échappent aux points où elles auraient dû être contenues. Dans notre contexte, une évasion concerne les CVE qui manquent les fenêtres de correction ou qui dépassent les seuils SLO. Un taux de fuite élevé ne montre pas seulement qu'il existe des vulnérabilités, mais aussi que le processus conçu pour les contrôler est défaillant, que ce soit parce que les cycles de correction sont trop lents, que les processus d'automatisation font défaut ou que les contrôles compensatoires ne fonctionnent pas comme prévu.

Ensemble, ces mesures permettent d'obtenir une meilleure vue d'ensemble : le taux d'arrivée nous indique la quantité de nouveaux risques introduits ; les tendances d'épuisement montrent si nous suivons le rythme de cette pression ou si nous sommes submergés par elle ; les taux de fuite révèlent où les vulnérabilités persistent en dépit des contrôles planifiés.

[1]:En statistique, une valeur aberrante est un point de données très éloigné de la tendance centrale (ou éloigné du reste des valeurs d'un ensemble de données). Par exemple, si la plupart des vulnérabilités sont corrigées dans un délai de 30 jours, mais que l'une d'entre elles prend 600 jours, ce cas de 600 jours est aberrant. Les valeurs aberrantes peuvent tirer les moyennes vers le haut ou vers le bas d'une manière qui ne reflète pas l'expérience "typique". Dans le contexte des correctifs, il s'agit des vulnérabilités particulièrement lentes à corriger qui restent ouvertes bien plus longtemps que la norme. Ils peuvent représenter des situations rares mais importantes, comme des systèmes qui ne peuvent pas être facilement mis à jour, ou des correctifs qui nécessitent des tests approfondis.

[2] : Remarque : l'ensemble de données actuel sur six mois comprend à la fois toutes les vulnérabilités qui restent ouvertes à la fin de la période d'observation (indépendamment de la date à laquelle elles ont été ouvertes ou vues pour la première fois) et toutes les vulnérabilités qui ont été fermées au cours de la période de six mois. Malgré cette approche de cohorte mixte, les courbes de survie des fenêtres d'observation antérieures montrent des tendances cohérentes, en particulier dans la première partie de la courbe. La forme et la pente des 30 à 60 premiers jours se sont avérées remarquablement stables d'un instant à l'autre, ce qui suggère que les mesures telles que le délai médian d'application des correctifs et le comportement de remédiation à un stade précoce ne sont pas des artefacts de la courte fenêtre d'observation. Alors que les estimations à long terme (par ex. 90e percentile) restent incomplètes sur des périodes plus courtes, les conclusions tirées de ces cohortes reflètent toujours une dynamique persistante et fiable des correctifs.

[3] : Nous avons conservé la CDF sur une base mensuelle pour les rapports opérationnels (débit et respect des SLO pour le travail effectué pendant le mois en cours), tandis que le Kaplan-Meier utilise une fenêtre de 6 mois pour traiter correctement la censure et exposer le risque de queue dans l'ensemble de la cohorte.