Skip to content

Herstellerneutral · CVSS v4 · EPSS · KEV · SSVC

Schwachstellenmanagement betreiben wie ein Operations Center.

Ein herstellerneutraler Praxisleitfaden für den Aufbau eines VOC: jedes Asset kennen, gezielt scannen, mit CVSS v4, EPSS und KEV priorisieren, Verantwortliche an risikobasierte SLAs binden und so berichten, dass die Führung handeln kann.

Bereiche
8
ausführliche Leitfäden
12
Glossarbegriffe
12
triage / entscheidung● example

Bedrohungssignale

  • CVSS-BTE
  • EPSS
  • KEV
  • SSVC

Asset-Kontext

  • tier-1 asset
  • internet-facing
  • owner: payments

Entscheidung

P1Act

Prioritätsstufe + SLA + Verantwortlicher

Illustrativer Ablauf, keine Live-Daten.

Lebenszyklus

Ein Kreislauf, Ende zu Ende verantwortet

Ein VOC betreibt den Schwachstellen-Lebenszyklus als kontinuierlichen Prozess mit klaren Übergaben — nicht als quartalsweisen Scan mit Tabellenkalkulation.

  1. 01

    Inventarisieren

    Jedes Asset mit Verantwortlichem, Kritikalitätsstufe und Exposition abgleichen.

  2. 02

    Erkennen

    Authentifizierte Scans, Agenten, Cloud- und Code-Scans — mit gemessener Abdeckung.

  3. 03

    Priorisieren

    CVSS, EPSS, KEV und Asset-Kontext zu wenigen Stufen verdichten.

  4. 04

    Beheben

    Nach Fix bündeln, an Verantwortliche routen, gegen ein risikobasiertes SLA verfolgen.

  5. 05

    Verifizieren

    Auf Basis von Scan-Belegen schließen; Ausnahmen mit Ablaufdatum führen.

  6. 06

    Berichten

    Behebungszeit, SLA-Einhaltung und Exposition als Trend für die Führung.

VOC-Bereich

Die VOC-Karte

Acht Bereiche, die zusammen ein funktionierendes Vulnerability Operations Center ergeben. Beginnen Sie dort, wo es am meisten schmerzt — jeder Bereich führt zu fokussierten, praxisnahen Leitfäden.

Prinzipien

Was ein VOC von einem Scan-Team unterscheidet

  • 01

    Risiko statt Schweregrad

    Ein CVSS-Basiswert beschreibt eine Schwachstelle. Für die Priorität braucht es außerdem Belege für Ausnutzung und die Bedeutung des Assets für das Geschäft.

  • 02

    Nach Verantwortlichem beheben, nicht nach CVE

    Bündeln Sie Findings in die Änderung, die sie beseitigt — ein Patch, ein Upgrade, eine Konfiguration — und geben Sie sie dem Team, das sie ausrollen kann.

  • 03

    Verifizieren statt Tickets glauben

    Ein geschlossenes Ticket ist eine Behauptung. Ein sauberer Rescan oder aktuelle Agent-Daten sind ein Beleg. Nur Belege schließen ein Finding.

  • 04

    Fluss messen, nicht Berge

    Die reine Anzahl an Findings steigt, sobald sich die Abdeckung verbessert. Behebungszeit, SLA-Einhaltung und Expositionsfenster zeigen, ob das Risiko tatsächlich sinkt.

Leitfäden

Neueste Leitfäden

Die Leitfäden erscheinen zuerst auf Englisch; Übersetzungen folgen.

Alle Leitfäden ansehen
08 · Tool-LandschaftEN
A vendor-neutral map of VOC tool categories — inventory, scanners, cloud, containers, SCA, EASM, aggregation, ticketing — and how to choose and connect them.
07 · Kennzahlen & ReportingEN
How a VOC reports to executives and the board: audiences, a one-page structure, KRIs vs KPIs, trends over snapshots, and what to leave out.
07 · Kennzahlen & ReportingEN
Define and compute the metrics a VOC needs: time to remediate with percentiles, SLA compliance, coverage, backlog age, KEV exposure windows and reopen rate.
06 · Ausnahmen & RisikoakzeptanzEN
Run a vulnerability exception process that stays honest: exception types, approval by risk level, compensating controls, expiry and an auditable register.
05 · Remediation-WorkflowEN
An end-to-end remediation workflow: deduplicate findings, group them by fix, route to owners, integrate with ITSM, and close only on rescan evidence.
05 · Remediation-WorkflowEN
Design risk-based vulnerability remediation SLAs: tiers instead of raw CVSS, when the clock starts and pauses, escalation, and measuring compliance.

Dieselbe Sprache sprechen

Kurze, präzise Definitionen der Bewertungssysteme, Kataloge und Kennzahlen, die in den Leitfäden verwendet werden.

Glossar öffnen