Schwachstellenmanagement-Prozess: Flussdiagramm von Scan bis Abschluss

Was ist schwachstellenmanagement-prozess: flussdiagramm von scan bis abschluss?

Schwachstellenmanagement ist der wiederkehrende operative Zyklus, der bekannte Schwachstellen über den gesamten Bestand hinweg findet, entscheidet, welche davon relevant sind, sie beheben lässt und das belegt. Der Auslöser ist ein Zeitplan und kein Ereignis: Ein Scan-Fenster öffnet sich gegen das Asset-Inventar, und alles Nachgelagerte hängt davon ab, dass dieses Inventar stimmt. Das Diagramm unten folgt einem Zyklus von Anfang bis Ende. Scan-Umfang und Abdeckung der Zugangsdaten werden vereinbart, bevor irgendetwas gescannt wird, der authentifizierte Scan läuft, Hersteller-Advisories treffen neben der eigenen Scanner-Ausgabe ein, Findings werden dedupliziert und bestätigt, eine Bewertung verbindet Schweregrad mit Ausnutzbarkeit und dem, was das Asset tatsächlich enthält, eine Frist und ein namentlich benannter Verantwortlicher werden zugeordnet, eine Änderung trägt die Behebung, ein erneuter Scan schließt das Finding entweder oder öffnet es erneut, und das Register sowie die Kennzahlen sind das, was das Management vor dem nächsten Fenster überprüft.

Das hier ist das Programm, nicht die Behebung selbst. Was ein einzelner Systemverantwortlicher innerhalb eines Tickets tut – das Finding gegen den eigenen Build validieren, zwischen einem Patch, einem Upgrade, einer Konfigurationsänderung und einer Außerbetriebnahme wählen, es testen und ausrollen – ist der Prozess der Schwachstellenbehebung, und er hängt an dem einen hier gezeichneten Schritt „Patch, Konfigurationsänderung oder kompensierende Kontrolle umsetzen“. Der Hersteller-Patch selbst, mit Anwendbarkeitsprüfung, Test außerhalb der Produktion, gestaffeltem Rollout und Rollback, ist Patch-Management – ein eigenständiger Zyklus, den dieser hier nutzt, statt ihn zu enthalten. Und der vollständige Workflow für Sicherheitsausnahmen – geschäftliche Begründung, kompensierende Kontrollen, ein von der Risikobewertung abhängiges Freigabeniveau, ein Registereintrag und eine Erneuerungsprüfung – liegt hinter der Entscheidung „Ausnahme mit Ablaufdatum genehmigt?“ und nicht in ihr. Diese Grenzen sichtbar zu halten ist es, was verhindert, dass ein Diagramm versucht, drei zu sein. Betrachten Sie das Folgende als Ausgangspunkt, der an Ihre eigene Sicherheitsrichtlinie, Ihre regulatorischen Pflichten und das Urteilsvermögen einer kompetenten Sicherheitsfachkraft anzupassen ist.

Vier Entscheidungen tragen den Prozess. „Ist jedes Asset im Scope scanbar?“ steht an erster Stelle, weil Abdeckungslücken unsichtbar sind: Ein Asset, das kein Scan-Template erreicht, liefert keine Findings, und ein sauberes Dashboard sieht im Bericht genauso aus wie ein ungescannter Bestand. „Bekannt ausgenutzt oder kritischer Schweregrad?“ ist die Priorisierungsweiche, und sie liegt in der Bahn des Analysten, weil der Nachweis der Ausnutzung von ihm stammt, während der damit eröffnete Notfallpfad beim Sicherheitsmanagement liegt, das die Befugnis hat, andere Arbeit zu unterbrechen. „Innerhalb der SLA behebbar?“ liegt bewusst in der Bahn Systemverantwortlicher / IT-Betrieb und nicht bei den Analysten – wer die Änderung durchführen muss, weiß, ob das Zeitfenster existiert – und der Nein-Zweig führt zu einer Ausnahmeentscheidung, die beim Sicherheitsmanagement liegt, weil die Akzeptanz eines Risikos ein Führungsakt ist und kein technischer. „Zeigt der erneute Scan das Finding als geschlossen?“ gibt den Prozess an die Analystin oder den Analysten zurück, sodass der Abschluss auf einem Nachweis beruht und nicht darauf, dass jemand ein Ticket als erledigt markiert.

Was dieses Flussdiagramm abdeckt

In dieser Vorlage

• Fünf Swimlanes (Schwachstellenanalyst, Systemverantwortlicher / IT-Betrieb, Change Manager, Sicherheitsmanagement und Hersteller) über sechs Phasen: Umfang und Erkennung, Scan und Aufnahme, Triage, Priorisierung und Zuweisung, Behebung und Verifikation sowie Bericht und Überprüfung
• Ein Abdeckungs-Gate vor jedem Scan: „Ist jedes Asset im Scope scanbar?“ schickt fehlende Zugangsdaten und nicht ausgerollte Agenten zur Behebung zurück, weil ein Asset, gegen das sich der Scanner nicht authentifizieren kann, fast nichts meldet und trotzdem als gescannt zählt
• Zwei Aufnahmewege in eine Warteschlange: die eigene Scanner-Ausgabe und ein Hersteller-Advisory, das über den Schritt „Advisory und die korrigierte Version veröffentlichen“ eintrifft, damit etwas, das zwischen zwei Scan-Fenstern angekündigt wird, nicht bis zum nächsten Zyklus ohne Verantwortlichen bleibt
• Ein Triage-Paar, das die meisten Diagramme in eine einzige Box zusammenlegen: „Finding auf dem Asset bestätigt?“ leitet unbestätigte Ergebnisse an „Als Fehlalarm mit Nachweis unterdrücken“ weiter, ein geschlossenes Endelement, das trotzdem einen Grund, ein Ablaufdatum und einen Genehmiger verlangt
• Bewertung und Frist als getrennte Schritte: „Nach CVSS, Ausnutzbarkeit und Asset-Wert bewerten“ liefert die Bewertung, „Bekannt ausgenutzt oder kritischer Schweregrad?“ trennt Notfallarbeit vom Routine-Band, und erst danach wird ein Verantwortlicher für die Behebung benannt und zur Rechenschaft gezogen
• Abschluss auf Basis von Nachweisen, mit zwei Schleifen und einem Fluchtweg: „Zeigt der erneute Scan das Finding als geschlossen?“ öffnet alles noch Vorhandene erneut, „Innerhalb der SLA behebbar?“ führt zu „Ausnahme mit Ablaufdatum genehmigt?“, und überfällige Findings werden eskaliert, bevor die Kennzahlen veröffentlicht werden

Wann Sie diese Vorlage verwenden sollten

• Sie schreiben einen Standard für Schwachstellenmanagement neu oder erstmals und brauchen ein Bild davon, wer scannt, wer bewertet, wer behebt und wer das Restrisiko akzeptiert
• Findings altern über ihre Fristen hinaus, und niemand kann sagen, ob sie bei der Triage, bei der Zuweisung, am Änderungsfenster oder beim erneuten Scan hängen bleiben
• Sie wählen einen Scanner aus oder ersetzen einen und wollen den Prozess abgestimmt haben, bevor Scan-Richtlinien, Zugangsdaten-Speicher, Asset-Gruppen und SLA-Bänder konfiguriert werden
• Sicherheit und IT-Betrieb sind uneins darüber, was als behoben gilt, sodass der erneute Scan, der Ausnahmeweg und der Eskalationspfad explizit geregelt und einem Verantwortlichen zugeordnet sein müssen
• Ein Auditor oder ein Sicherheitsfragebogen eines Kunden verlangt eine dokumentierte Beschreibung, wie Schwachstellen identifiziert, bewertet, behoben und verifiziert werden

So funktioniert es

1. Benennen Sie die Bahnen nach Ihren Rollen um

   Ersetzen Sie Schwachstellenanalyst, Systemverantwortlicher / IT-Betrieb, Change Manager, Sicherheitsmanagement und Hersteller durch die Rollen, die es bei Ihnen wirklich gibt. In einem kleinen Team sind Analyst und Systemverantwortlicher oft dieselbe Person: Führen Sie diese Bahnen zusammen, statt eine Übergabe zu zeichnen, die nur auf dem Papier existiert. Halten Sie das Sicherheitsmanagement trotzdem getrennt, denn die Ausnahme- und Eskalationszweige brauchen eine Instanz, die nicht zugleich die Behebung durchführt.

2. Schreiben Sie Ihre Regel für Scan-Umfang und Abdeckung

   Legen Sie fest, welche Assets im Scope sind, wie sie aus dem Inventar oder der CMDB dorthin gelangen, welche mit Zugangsdaten oder Agent gescannt werden und welche nicht, und wie oft jede Gruppe gescannt wird. Vermerken Sie die Ausnahmen und wer sie gewähren darf. Abdeckung ist die Zahl, die jeder anderen Zahl im Programm erst ihre Bedeutung gibt – setzen Sie sie also auf das Diagramm, statt sie in einer Tool-Einstellung zu belassen, die niemand liest.

3. Definieren Sie, wie ein Finding bewertet wird

   Legen Sie fest, welche Schweregrad-Skala Sie verwenden und woher der Score kommt, und dann, was Sie hinzufügen. Ein Schweregrad-Score beschreibt die technische Auswirkung; Nachweise zur Ausnutzung und der Asset-Kontext beschreiben, wie sehr Sie sich diese Woche kümmern sollten. Schreiben Sie die Kombination auf, die Sie tatsächlich verwenden, benennen Sie ihre Eingangsgrößen, und dokumentieren Sie, wer eine Bewertung außer Kraft setzen darf und auf welchem Nachweis das beruht.

4. Legen Sie die SLA-Bänder fest und starten Sie die Uhr

   Tragen Sie Ihre eigenen Behebungsfristen in das Diagramm ein und löschen Sie die Platzhalter. Stimmen Sie jedes Band mit denen ab, die es einhalten müssen, und legen Sie klar fest, wann die Uhr startet, denn Erkennungsdatum, Ticketdatum und Veröffentlichungsdatum des Herstellers erzeugen aus demselben Bestand sehr unterschiedliche Alterungsberichte. Legen Sie fest, was der Notfallpfad in der Praxis bedeutet und wer ihn eröffnen darf.

5. Vereinbaren Sie den Ausnahme- und Eskalationsweg

   Entscheiden Sie, wer eine Ausnahme genehmigen darf, welcher Nachweis dazugehört, wie lange sie höchstens laufen darf und welche kompensierende Kontrolle währenddessen aktiv sein muss. Vereinbaren Sie dann die Eskalation für alles, was ohne Ausnahme überfällig ist: wer informiert wird, ab welchem Alter, und was passiert, wenn sich danach nichts ändert. Beide Wege brauchen eine namentlich benannte Person statt eines geteilten Postfachs.

6. Entscheiden Sie, was den Abschluss eines Findings belegt

   Der Abschluss sollte auf einem erneuten Scan des betroffenen Assets beruhen, nicht darauf, dass ein Ticket als erledigt markiert wird. Schreiben Sie auf, welcher Scan das belegt, wie schnell er nach einer Behebung läuft, und was passiert, wenn der erneute Scan das Finding weiterhin meldet. Dokumentieren Sie, ob eine kompensierende Kontrolle ein Finding schließt oder nur mindert, denn diese beiden Konventionen erzeugen sehr unterschiedliche Register und sehr unterschiedliche Kennzahlen.

7. Gehen Sie ihn an einem echten Finding durch

   Nehmen Sie zwei Findings aus dem letzten Zyklus – eines, das rechtzeitig geschlossen wurde, und eines, das überfällig wurde oder als Ausnahme endete – und verfolgen Sie beide durch das Diagramm. Jeder Schritt, den Beteiligte beschreiben, der aber nicht gezeichnet ist, und jeder gezeichnete Schritt, der in der Praxis still übersprungen wird, ist der Befund, den Sie angehen sollten, bevor Sie den Prozess für andere veröffentlichen.

Häufig gestellte Fragen

Welche Schritte umfasst ein Prozess für Schwachstellenmanagement?

Ein Scan-Zyklus öffnet sich gegen das Asset-Inventar, und Umfang sowie Abdeckung der Zugangsdaten werden festgelegt, bevor irgendetwas läuft; Assets, die der Scanner nicht erreicht, werden korrigiert und erneut geprüft. Der geplante authentifizierte Scan läuft, und Hersteller-Advisories, die zwischen den Scans eintreffen, laufen in dieselbe Warteschlange ein. Findings werden dedupliziert und mit Exploit-Daten angereichert, dann gegen das Asset bestätigt, und alles Unbestätigte wird zusammen mit seinem Nachweis als Fehlalarm unterdrückt. Bestätigte Findings werden nach Schweregrad, Ausnutzbarkeit und Asset-Wert bewertet, an einen Notfallpfad oder ein Standard-Fristband weitergeleitet und einem namentlich benannten Verantwortlichen für die Behebung zugewiesen. Dieser behebt entweder innerhalb der Frist, nötigenfalls über ein Änderungsfenster, oder beantragt eine Ausnahme mit Ablaufdatum. Ein erneuter Scan bestätigt den Abschluss oder öffnet die Arbeit erneut. Zum Schluss wird das Register aktualisiert, überfällige Findings werden eskaliert, Kennzahlen zu Abdeckung, Alterung und Abschlussquote werden veröffentlicht, und das Management prüft den Trend vor dem nächsten Zyklus.

Was unterscheidet Schwachstellenmanagement von Patch-Management?

Schwachstellenmanagement ist der Zyklus, der Schwachstellen im gesamten Bestand entdeckt, bewertet und bis zu einem verifizierten Abschluss treibt, unabhängig davon, welche Behandlung sich am Ende ergibt. Patch-Management ist eine dieser Behandlungen: der operative Zyklus, der eine Herstellerversion nimmt, ihre Anwendbarkeit prüft, sie testet, terminiert und ausrollt. NISTs Leitfaden zur Planung von Enterprise-Patch-Management (SP 800-40 Revision 4) macht denselben Punkt aus der anderen Richtung, indem er Patching als vorbeugende Instandhaltung einordnet und als eine von mehreren Möglichkeiten, auf das Risiko einer Software-Schwachstelle zu reagieren. Die praktische Folge: Ein Schwachstellenprogramm, das nur an installierten Patches gemessen wird, unterschätzt sich selbst, denn auch Konfigurationsänderungen, Upgrades, Außerbetriebnahmen und kompensierende Kontrollen schließen Findings, und für manche Findings gibt es überhaupt keinen Patch zu installieren.

Reicht ein CVSS-Score zur Priorisierung der Behebung aus?

CVSS, gepflegt von FIRST, bewertet den technischen Schweregrad von 0,0 bis 10,0, und die qualitativen Bänder in Version 3.1 sind Niedrig 0,1 bis 3,9, Mittel 4,0 bis 6,9, Hoch 7,0 bis 8,9 und Kritisch 9,0 bis 10,0. Version 4.0, veröffentlicht 2023, behält einen Basis-Score bei und ergänzt explizite Threat- und Environmental-Metrikgruppen. Was CVSS bewusst nicht verrät, ist, wie wahrscheinlich eine Ausnutzung ist oder wie wichtig ein bestimmtes Asset für Sie ist. Teams ergänzen meist zwei weitere Signale: einen Score zur Ausnutzungswahrscheinlichkeit wie EPSS, ebenfalls von FIRST, der die Wahrscheinlichkeit schätzt, dass eine Schwachstelle in den nächsten dreißig Tagen in freier Wildbahn ausgenutzt wird, und täglich neu berechnet wird, sowie Nachweise tatsächlicher Ausnutzung wie CISAs Known-Exploited-Vulnerabilities-Katalog. Der Asset-Kontext ist der dritte Faktor, und den kennen nur Sie. Deshalb bewertet dieses Diagramm zunächst und leitet dann anhand von „Bekannt ausgenutzt oder kritischer Schweregrad?“ weiter, statt eine Liste einfach nach Score zu sortieren.

Wie oft sollten Schwachstellen-Scans laufen, und wer verantwortet den Prozess?

Rahmenwerke unterscheiden sich, nehmen Sie die Frequenz also aus dem, das für Sie gilt, statt aus einer allgemeinen Regel. ISO/IEC 27001:2022 Anhang A, Control 8.8, Umgang mit technischen Schwachstellen, verlangt, dass Informationen zu technischen Schwachstellen in genutzten Systemen eingeholt, die Gefährdung bewertet und geeignete Maßnahmen ergriffen werden – legt aber kein Intervall fest und überlässt die Kadenz Ihrer Risikobewertung. PCI DSS Version 4 ist für Umgebungen mit Karteninhaberdaten konkreter: interne Schwachstellen-Scans mindestens alle drei Monate und nach jeder wesentlichen Änderung, durchgeführt als authentifizierte Scans, mit externen Scans durch einen Approved Scanning Vendor. Viele Organisationen scannen weit häufiger als das Minimum, weil ein weiterer Scan wenig kostet. Bei der Zuständigkeit ist die übliche Aufteilung die hier gezeichnete: Sicherheit verantwortet Erkennung, Bewertung und Berichterstattung; der Systemverantwortliche verantwortet die Behebung; das Management verantwortet Ausnahmen und Eskalationen. Ein Programm, in dem Sicherheit auch die Behebung verantwortet, gerät tendenziell ins Stocken, weil der Analyst weder die Änderungsrechte noch das operative Risiko trägt.

Welche Aufzeichnungen sollte ein Prozess für Schwachstellenmanagement erzeugen?

Genug, um jedes einzelne Finding ein Jahr später zu rekonstruieren, ohne den Scanner zu öffnen. In der Praxis bedeutet das einen Registereintrag pro Finding mit dem betroffenen Asset, dem Erkennungsdatum, der Bewertung und deren Grundlage, dem zugewiesenen Verantwortlichen, der Frist, der gewählten Behandlung und dem Abschlussnachweis. Daneben stehen die Scan-Konfiguration und der Abdeckungsnachweis, damit ein Prüfer erkennen kann, was im Scope war und was authentifiziert wurde; die Unterdrückungsliste mit Grund und Überprüfungsdatum für jeden Fehlalarm; das Ausnahmeregister mit Begründung, kompensierender Kontrolle, Genehmiger und Ablaufdatum; sowie das Ergebnis des erneuten Scans, der jedes Finding geschlossen hat. Die Berichterstattung ist die letzte Aufzeichnung: Abdeckung, Alterung gegenüber den Fristbändern und Abschlussquote im Zeitverlauf, zusammen mit dem, was das Management entschieden hat, als sich der Trend änderte. Ein Prüfer testet meist das Register gegen den Scanner und nicht umgekehrt, sodass unerklärte Findings, die im Tool, aber nicht im Register existieren, der übliche Befund sind.