Zeit-bis-zum-Patch-Metriken: Ein Überlebenszeitanalyse-Ansatz mit Qualys und Elastic

Einführung

Das Verständnis dafür, wie schnell Schwachstellen in verschiedenen Umgebungen und Teams behoben werden, ist entscheidend für die Aufrechterhaltung einer starken Sicherheitslage. In diesem Artikel beschreiben wir, wie wir mithilfe des Elastic Stack eine Überlebenszeitanalyse auf Daten zum Schwachstellenmanagement (VM) aus Qualys VMDR angewendet haben. Dies erlaubte es uns nicht nur, allgemeine Annahmen über die Teamgeschwindigkeit (wie schnell Teams ihre Arbeit erledigen) und die Behebungskapazität (wie viele Korrekturen sie übernehmen können) zu bestätigen, sondern auch messbare Erkenntnisse zu gewinnen. Da sich der Großteil unserer Sicherheitsdaten im Elastic Stack befindet, sollte dieser Prozess problemlos auf andere Sicherheitsdatenquellen übertragbar sein.

Warum wir es getan haben

Unsere Hauptmotivation bestand darin , von allgemeinen Annahmen zu datengestützten Erkenntnissen über Folgendes zu gelangen :

• Wie schnell verschiedene Teams und Umgebungen Sicherheitslücken beheben
• Ob die Patching-Performance die internen Service-Level-Ziele (SLOs) erfüllt
• Wo häufig Engpässe oder Verzögerungen auftreten
• Welche anderen Faktoren können die Patching-Leistung beeinflussen?

Warum Überlebenszeitanalyse? Eine bessere Alternative zur mittleren Sanierungszeit

Die mittlere Zeit bis zur Behebung (Mean Time to Remediate, MTTR) wird häufig verwendet, um zu verfolgen, wie schnell Sicherheitslücken geschlossen werden. Allerdings weisen sowohl der Mittelwert als auch der Median erhebliche Einschränkungen auf (ein Beispiel dazu folgt später in diesem Artikel). Der Mittelwert reagiert sehr empfindlich auf Ausreißer[^1] und setzt voraus, dass die Sanierungszeiten gleichmäßig um die durchschnittliche Sanierungszeit verteilt sind, was in der Praxis selten der Fall ist. Der Median reagiert weniger empfindlich auf Extremwerte, lässt aber Informationen über die Form der Verteilung außer Acht und sagt nichts über den langen Ausläufer der langsam zu behebenden Sicherheitslücken aus. Beide Verfahren berücksichtigen keine ungelösten Fälle, d. h. Schwachstellen, die über den Beobachtungszeitraum hinaus bestehen bleiben und daher oft vollständig ausgeschlossen werden. In der Praxis sind es gerade die Schwachstellen, die am längsten unentdeckt bleiben, die uns am meisten Sorgen bereiten sollten.

Die Überlebenszeitanalyse behebt diese Einschränkungen. Ursprünglich aus dem medizinischen und versicherungsmathematischen Bereich stammend, modelliert es Zeit-bis-Ereignis-Daten und berücksichtigt dabei explizit zensierte Beobachtungen, was in unserem Kontext bedeutet, dass Schwachstellen weiterhin bestehen. (Für weitere Details zur Anwendung im Bereich des Schwachstellenmanagements empfehlen wir dringend „The Metrics Manifesto“). Anstatt das Behebungsverhalten auf eine einzige Zahl zu reduzieren, schätzt die Überlebenszeitanalyse die Wahrscheinlichkeit, dass eine Schwachstelle über einen bestimmten Zeitraum ungepatcht bleibt (z. B. 90 % der Sicherheitslücken werden innerhalb von 30 Tagen behoben. Dies ermöglicht aussagekräftigere Bewertungen, wie beispielsweise den Anteil der innerhalb des SLO behobenen Schwachstellen (z. B. innerhalb von 30, 90 oder 180 Tagen).

Die Überlebenszeitanalyse liefert uns eine Überlebensfunktion , die die Wahrscheinlichkeit schätzt, dass eine Sicherheitslücke im Laufe der Zeit ungepatcht bleibt.

::: Diese Methode bietet einen besseren Überblick über die Wirksamkeit der Behebungsmaßnahmen und ermöglicht es uns, nicht nur zu beurteilen, wie lange Schwachstellen bestehen bleiben, sondern auch, wie sich das Behebungsverhalten in verschiedenen Systemen, Teams oder Schweregraden unterscheidet. Es eignet sich besonders gut für Sicherheitsdaten, die oft unvollständig, verzerrt und resistent gegenüber Annahmen der Normalität sind. :::

Kontext

Obwohl wir die Überlebenszeitanalyse in verschiedenen Umgebungen, Teams und Organisationen angewendet haben, konzentrieren wir uns in diesem Blog auf die Ergebnisse für die Elastic Cloud-Produktionsumgebung.

Berechnung des Vulnerabilitätsalters

Es gibt verschiedene Methoden zur Berechnung des Vulnerabilitätsalters.

Für unsere internen Kennzahlen wie die Einhaltung der Sicherheitsziele (SLO) für Schwachstellen definieren wir das Alter einer Schwachstelle als die Differenz zwischen dem Zeitpunkt, an dem eine Schwachstelle zuletzt gefunden wurde, und dem Zeitpunkt, an dem sie erstmals entdeckt wurde (in der Regel einige Tage nach der Veröffentlichung). Dieser Ansatz zielt darauf ab, Schwachstellen zu bestrafen, die durch die Wiedereinführung eines veralteten Basisimages entstehen. In der Vergangenheit wurden unsere Basisbilder nicht häufig genug aktualisiert, um unsere Zufriedenheit zu gewährleisten. Wenn eine neue Instanz erstellt wird, können Schwachstellen ab dem Tag ihrer Entdeckung ein beträchtliches Alter haben (z. B. 100 Tage).

Für diese Analyse halten wir es für sinnvoller, das Alter anhand der Anzahl der Tage zwischen dem letzten Funddatum und dem ersten Funddatum zu berechnen. In diesem Fall entspricht das Alter der Anzahl der Tage, an denen das System effektiv exponiert war.

„Alles flicken“-Strategie

In unserer Cloud-Umgebung verfolgen wir die Strategie, alles mit Patches zu versehen. Dies liegt daran, dass wir fast ausschließlich dasselbe Basisimage für alle Instanzen verwenden. Da Elastic Cloud vollständig auf Containern basiert, werden keine spezifischen Anwendungspakete (z. B. Elasticsearch) direkt auf unseren Systemen installiert. Unsere Flotte bleibt dadurch homogen.

Datenpipeline

Das Einlesen und Zuordnen von Daten in den Elastic Stack kann umständlich sein. Zum Glück gibt es viele Sicherheitsintegrationen , die diese Probleme nativ beheben, Qualys VMDR ist eine davon.

Diese Integration hat 3 Hauptinteressen gegenüber benutzerdefinierten Erfassungsmethoden (z. B. Skripte, Beats, …):

• Es reichert Schwachstellendaten aus der Qualys Knowledge Base nativ an, indem es CVE-IDs, Bedrohungsinformationen usw. hinzufügt, ohne dass Anreicherungspipelines konfiguriert werden müssen.
• Die Qualys-Daten sind bereits dem Elastic Common Schema zugeordnet, einem standardisierten Verfahren zur Darstellung von Daten, unabhängig von deren Herkunft: Beispielsweise werden CVEs immer im Feld vulnerability.id gespeichert. unabhängig von der Quelle.
• Eine Transformation mit der neuesten Sicherheitslücke ist bereits eingerichtet. Dieser Index kann abgefragt werden, um den aktuellen Status der Sicherheitslücken zu erhalten.

Konfiguration der Qualys-Agentenintegration

Für die Überlebenszeitanalyse müssen wir sowohl aktive als auch behobene Sicherheitslücken berücksichtigen. Um einen bestimmten Zeitraum zu analysieren, müssen wir die Anzahl der Tage im Feld max_days_since_detection_updated festlegen. In unserer Umgebung erfassen wir täglich Qualys-Daten, daher ist es nicht notwendig, eine lange Historie statischer Daten zu erfassen, da wir dies bereits getan haben.

Die Integration des elastischen Agenten von Qualys VMDR wurde wie folgt konfiguriert:

Sobald die Daten vollständig erfasst sind, können sie entweder in Kibana Discover (logs-* data view -> data_stream.dataset : "qualys_vmdr.asset_host_detection" ) oder in der Kibana Security App (Findings -> Vulnerabilities) überprüft werden.

Daten mit dem Elasticsearch-Client in Python laden

Da die Überlebenszeitanalyse in Python durchgeführt wird, müssen wir die Daten aus Elastic in einen Python-Dataframe extrahieren. Es gibt mehrere Wege, dies zu erreichen, und in diesem Artikel konzentrieren wir uns auf zwei davon.

Mit ES|QL

Am einfachsten und bequemsten ist es, ES|QL mit dem Pfeilformat zu verwenden. Der Python-Dataframe (Zeilen und Spalten) wird automatisch befüllt. Wir empfehlen, den Blogbeitrag „From ES|QL to native Pandas dataframes in Python“ zu lesen, um mehr Details zu erfahren.

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)

Aktuell gibt es bei ESQL eine Einschränkung: Wir können die Ergebnisse nicht seitenweise durchlaufen. Daher sind wir auf 10.000 Ausgabedokumente beschränkt (100.000, wenn die Serverkonfiguration geändert wird). Der Fortschritt kann anhand dieses Verbesserungsantrags verfolgt werden.

Mit DSL

Im Elasticsearch Python-Client gibt es eine native Funktion, um alle Daten aus einer Abfrage mit transparenter Paginierung zu extrahieren. Die Herausforderung besteht darin, die DSL-Abfrage zu erstellen. Wir empfehlen, die Abfrage in Discover zu erstellen und dann auf Inspect und anschließend auf die Registerkarte Request zu klicken, um die DSL-Abfrage zu erhalten.

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
    ))

Überlebensanalyse

Sie können den Code einsehen, um ihn zu verstehen oder ihn auf Ihren eigenen Datensatz anzuwenden.

Was wir gelernt haben

Ausgehend von den Forschungsergebnissen des Cyentia Institute haben wir verschiedene Methoden untersucht, um zu messen, wie lange es dauert, Schwachstellen zu beheben, indem wir Mittelwerte, Mediane und Überlebenskurven verwendeten. Jede Methode bietet eine andere Perspektive, durch die wir die Daten zur Patch-Zeit verstehen können, und der Vergleich ist wichtig, denn je nachdem, welche Methode wir anwenden, würden wir zu sehr unterschiedlichen Schlussfolgerungen darüber gelangen, wie gut Sicherheitslücken behoben werden.

Die erste Methode konzentriert sich ausschließlich auf Sicherheitslücken, die bereits behoben wurden. Es berechnet die mittlere und die durchschnittliche Zeit, die zum Ausbessern benötigt wurde. Das ist zwar intuitiv und einfach, lässt aber einen potenziell großen und wichtigen Teil der Daten außer Acht (die noch offenen Sicherheitslücken). Daher wird der tatsächliche Zeitaufwand für die Behebung tendenziell unterschätzt, insbesondere wenn einige Schwachstellen viel länger bestehen bleiben als andere.

Die zweite Methode versucht, sowohl geschlossene als auch offene Sicherheitslücken zu berücksichtigen, indem die Zeit, die sie bisher offen waren, herangezogen wird. Es gibt viele Möglichkeiten, den Zeitpunkt der Behebung der offenen Sicherheitslücken näherungsweise zu bestimmen, aber der Einfachheit halber haben wir hier angenommen, dass sie zum Zeitpunkt der Meldung bereits behoben waren (oder noch behoben sein werden?), was bekanntermaßen nicht der Fall ist. Es bietet aber eine Möglichkeit, ihre Existenz zu berücksichtigen.

Die dritte Methode verwendet die Überlebenszeitanalyse. Konkret verwendeten wir den Kaplan-Meier-Schätzer, um die Wahrscheinlichkeit zu modellieren, dass eine Schwachstelle zu einem bestimmten Zeitpunkt noch besteht. Diese Methode geht angemessen mit den offenen Sicherheitslücken um: Anstatt so zu tun, als wären sie behoben, behandelt sie sie als „zensierte“ Daten. Die daraus resultierende Überlebenskurve sinkt mit der Zeit und zeigt den Anteil der noch offenen Schwachstellen im Laufe von Tagen oder Wochen an.

Wie lange bleiben Sicherheitslücken bestehen?

Im aktuellen 6-Monats-Snapshot[^2] beträgt die mediane Zeit bis zum Patch bei geschlossenem System etwa 33 Tage und der Mittelwert etwa 35 Tage. Auf den ersten Blick erscheint das plausibel, doch die Kaplan-Meier-Kurve zeigt, was diese Zahlen verbergen: Nach 33 Tagen sind noch etwa 54 % geöffnet; nach 35 Tagen sind es noch etwa 46 %. Selbst nach etwa einem Monat, also nach dem „typischen“ Zeitpunkt, ist noch immer etwa die Hälfte der Probleme ungelöst.

Wir berechneten außerdem Statistiken über die bisher beobachteten Fälle (wobei offene Sicherheitslücken so behandelt wurden, als wären sie am Ende des Messzeitraums behoben worden). In diesem Zeitraum sind sie zufällig fast gleich (Median ~33 Tage, Mittelwert ~35 Tage), da sich die Alter der heute offenen Posten um etwa einen Monat gruppieren. Dieser Zufall kann die Durchschnittswerte beruhigend erscheinen lassen, aber er ist zufällig und instabil: Wenn wir den Snapshot auf kurz vor dem monatlichen Patch-Push verschieben, sinken diese Statistiken rapide (wir haben einen Median von ~19 Tagen und einen Mittelwert von ~15 Tagen beobachtet), ohne dass sich der zugrunde liegende Prozess ändert.

Die Überlebenskurve umgeht diese Falle, da sie die Frage beantwortet, wie viel Prozent der Geschäfte nach 30/60/90 Tagen noch offen sind, und einen Einblick in den langen Ausläufer bietet, der weit über einen Monat hinaus offen bleibt.

Alles überall auf die gleiche Weise patchen?

Die stratifizierte Überlebenszeitanalyse führt die Idee der Überlebenskurven noch einen Schritt weiter. Anstatt alle Schwachstellen gemeinsam in einem großen Pool zu betrachten, werden sie anhand einer aussagekräftigen Eigenschaft in Gruppen (oder „Schichten“) unterteilt. In unserer Analyse haben wir die Schwachstellen nach Schweregrad, Kritikalität der Assets, Umgebung, Cloud-Anbieter und Team/Abteilung/Organisation stratifiziert. Jede Gruppe erhält ihre eigene Überlebenskurve, und hier im Beispielgraphen vergleichen wir, wie schnell verschiedene Schweregrade von Schwachstellen im Laufe der Zeit behoben werden.

Der Vorteil dieses Ansatzes besteht darin, dass er Unterschiede aufzeigt, die im Gesamtbild sonst verborgen blieben. Wenn wir nur die Gesamtüberlebenskurve betrachten, können wir lediglich Schlussfolgerungen über die Wirksamkeit der Sanierungsmaßnahmen im Allgemeinen ziehen. Die Stratifizierung zeigt jedoch, ob bestimmte Teams, Umgebungen oder Schweregrade von Problemen schneller angegangen werden als die übrigen, und in unserem Fall, dass die Strategie, alles zu patchen, tatsächlich konsistent ist. Dieser Detaillierungsgrad ist wichtig, um gezielte Verbesserungen vorzunehmen. Er hilft uns nicht nur zu verstehen, wie lange die Behebung von Mängeln im Allgemeinen dauert, sondern auch, ob und wo tatsächlich Engpässe bestehen.

Wie schnell handeln Teams?

Während die Überlebenskurve betont, wie lange Schwachstellen offen bleiben, können wir die Perspektive umkehren, indem wir stattdessen die kumulative Verteilungsfunktion (CDF) verwenden. Der CDF konzentriert sich darauf, wie schnell Sicherheitslücken behoben werden, und zeigt den Anteil der Sicherheitslücken an, die bis zu einem bestimmten Zeitpunkt behoben wurden.

Unsere Entscheidung, die kumulative Verteilungsfunktion (CDF) darzustellen, liefert ein klares Bild der Geschwindigkeit der Behebung von Sicherheitslücken. Es ist jedoch wichtig zu beachten, dass diese Version nur Schwachstellen enthält, die innerhalb des beobachteten Zeitraums behoben wurden. Im Gegensatz zur Überlebenskurve, die wir über eine gleitende 6-Monats-Kohorte berechnen, um vollständige Lebenszyklen zu erfassen, wird die CDF Monat für Monat auf der Grundlage der in diesem Monat abgeschlossenen Artikel berechnet[^3].

Daher zeigt es uns, wie schnell Teams Schwachstellen beheben, sobald sie dies tun, und es spiegelt nicht wider, wie lange ungelöste Schwachstellen offen bleiben. Beispielsweise sehen wir, dass 83,2 % der im laufenden Monat behobenen Sicherheitslücken innerhalb von 30 Tagen nach ihrer ersten Entdeckung geschlossen wurden. Dies unterstreicht die Geschwindigkeit, mit der kürzlich erfolgreiche Patches eingespielt wurden, berücksichtigt aber nicht länger bestehende Sicherheitslücken, die weiterhin offen sind und deren Behebung voraussichtlich längere Zeiträume in Anspruch nehmen wird. Daher verwenden wir die CDF, um das kurzfristige Reaktionsverhalten zu verstehen, während die Dynamik des gesamten Lebenszyklus durch eine Kombination aus CDF und Überlebenszeitanalyse dargestellt wird: Die CDF beschreibt, wie schnell Teams nach dem Patchen handeln , während die Überlebenszeitkurve zeigt , wie lange Schwachstellen tatsächlich bestehen bleiben.

Unterschied zwischen Überlebenszeitanalyse und Mittelwert/Median

Moment mal, wir haben doch gesagt, dass die Überlebenszeitanalyse besser geeignet ist, um die Zeit bis zum Patchen zu analysieren und den Einfluss von Ausreißern zu vermeiden. In diesem Beispiel liefern Mittelwert-/Median- und Überlebenszeitanalyse jedoch ähnliche Ergebnisse. Worin besteht der Mehrwert? Der Grund ist einfach: In unseren Produktionsumgebungen gibt es keine Ausreißer, da unser Patching-Prozess vollständig automatisiert und effektiv ist.

Um die Auswirkungen auf heterogene Daten zu veranschaulichen, verwenden wir ein veraltetes Beispiel aus einer Nicht-Produktionsumgebung, in der es keine automatische Aktualisierung gibt.

ESQL-Abfrage:

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"

In diesem Beispiel führen Mittelwert und Median zu sehr unterschiedlichen Ergebnissen. Die Auswahl einer einzelnen repräsentativen Kennzahl kann schwierig und unter Umständen irreführend sein. Das Diagramm der Überlebenszeitanalyse stellt unsere Effektivität bei der Behebung von Schwachstellen in diesem Umfeld präzise dar.

Schlussbetrachtung

Die Vorteile der Überlebenszeitanalyse liegen nicht nur in der genaueren Messung, sondern auch in den Erkenntnissen über die Dynamik des Reparaturverhaltens. Sie zeigen, wo Engpässe auftreten, welche Faktoren die Reparaturgeschwindigkeit beeinflussen und ob diese mit unserem SLO übereinstimmt. Aus technischer Integrationssicht lässt sich die Nutzung der Überlebenszeitanalyse als Teil unserer operativen Arbeitsabläufe und Berichtserstellung mit minimalen zusätzlichen Änderungen an unserer aktuellen Elastic Stack-Konfiguration realisieren: Die Überlebenszeitanalyse kann im gleichen Rhythmus wie unser Patching-Zyklus ausgeführt werden, wobei die Ergebnisse zur Visualisierung zurück in Kibana übertragen werden. Der entscheidende Vorteil besteht darin, unsere bestehenden operativen Kennzahlen mit der Überlebenszeitanalyse zu verknüpfen, um sowohl langfristige Trends als auch die kurzfristige Leistungsentwicklung zu verfolgen.

Mit Blick auf die Zukunft experimentieren wir mit zusätzlichen neuen Kennzahlen wie Ankunftsrate, Abbrandrate und Fluchtrate , die uns eine Möglichkeit bieten, ein dynamischeres Verständnis davon zu gewinnen, wie Schwachstellen tatsächlich behandelt werden.

Die Ankunftsrate ist das Maß dafür, wie schnell neue Schwachstellen in die Umgebung gelangen. Die Tatsache, dass beispielsweise jeden Monat fünfzig neue CVEs auftauchen, gibt uns Aufschluss darüber, was wir in Bezug auf die Arbeitslast erwarten können, noch bevor wir mit der Messung von Patches beginnen. Die Ankunftsrate ist also eine Kennzahl, die nicht unbedingt Aufschluss über den Bearbeitungsrückstand gibt, sondern eher über die Belastung des Systems.

Die Burndown-Rate (Trend) zeigt die andere Hälfte der Gleichung: wie schnell Schwachstellen behoben werden im Verhältnis zu ihrer Entstehungsgeschwindigkeit.

Escape Rate fügt eine weitere Dimension hinzu, indem es sich auf Schwachstellen konzentriert, die an den Stellen vorbeischlüpfen, an denen sie hätten eingedämmt werden sollen. In unserem Kontext geht es bei einem Escape um CVEs, die Patch-Fenster verpassen oder SLO-Schwellenwerte überschreiten. Eine erhöhte Ausbruchsrate zeigt nicht nur, dass Schwachstellen existieren, sondern auch, dass der Prozess, der zu ihrer Kontrolle entwickelt wurde, versagt, sei es, weil die Patch-Zyklen zu langsam sind, Automatisierungsprozesse fehlen oder kompensierende Kontrollen nicht wie vorgesehen funktionieren.

Zusammen ergeben die Kennzahlen ein besseres Bild: Die Ankunftsrate zeigt uns, wie viele neue Risiken hinzukommen; die Burndown-Trends zeigen, ob wir mit diesem Druck Schritt halten können oder von ihm überwältigt werden; die Escape-Raten decken auf, wo trotz geplanter Kontrollen weiterhin Schwachstellen bestehen.

[1]:Ein Ausreißer in der Statistik ist ein Datenpunkt, der sehr weit von der zentralen Tendenz (oder weit von den übrigen Werten in einem Datensatz) entfernt ist. Wenn beispielsweise die meisten Sicherheitslücken innerhalb von 30 Tagen behoben werden, eine jedoch 600 Tage benötigt, ist dieser Fall von 600 Tagen ein Ausreißer. Ausreißer können Durchschnittswerte nach oben oder unten verzerren, und zwar auf eine Weise, die nicht dem „typischen“ Erleben entspricht. Im Kontext von Patching handelt es sich dabei um besonders schwer zu behebende Sicherheitslücken, die deutlich länger als üblich ungeschützt bleiben. Es kann sich dabei um seltene, aber wichtige Situationen handeln, wie etwa Systeme, die nicht ohne Weiteres aktualisiert werden können, oder Patches, die umfangreiche Tests erfordern.

[2]: Hinweis: Der aktuelle 6-Monats-Datensatz umfasst sowohl alle Schwachstellen, die am Ende des Beobachtungszeitraums noch offen sind (unabhängig davon, wie lange es her ist, dass sie offen waren/erstmals entdeckt wurden), als auch alle Schwachstellen, die während des 6-Monats-Zeitraums geschlossen wurden. Trotz dieses gemischten Kohortenansatzes zeigen die Überlebenskurven aus früheren Beobachtungszeiträumen konsistente Trends, insbesondere im frühen Teil der Kurve. Die Form und Steigung der Kurve über die ersten 30–60 Tage haben sich über verschiedene Momentaufnahmen hinweg als bemerkenswert stabil erwiesen, was darauf hindeutet, dass Kennzahlen wie die mittlere Zeit bis zur Behebung des Problems und das Verhalten bei der Behebung in der Frühphase keine Artefakte des kurzen Beobachtungszeitraums sind. Während langfristige Schätzungen (z. B. Obwohl die Daten des 90. Perzentils in kürzeren Zeiträumen unvollständig bleiben, spiegeln die aus diesen Kohorten gezogenen Schlussfolgerungen dennoch eine anhaltende und zuverlässige Patching-Dynamik wider.

[3]:Wir haben die CDF monatlich für die operative Berichterstattung (Durchsatz und SLO-Einhaltung für die im laufenden Monat abgeschlossenen Arbeiten) beibehalten, während die Kaplan-Meier ein 6-Monats-Fenster verwendet, um Zensierung angemessen zu behandeln und das Tail-Risiko in der gesamten Kohorte aufzudecken.