Vulnerability
Management.
Täglich erscheinen mehr Schwachstellenhinweise, als ein Betrieb ungeprüft behandeln kann. Vulnerability Management verbindet diese Hinweise mit der eigenen technischen Realität und führt die relevanten Fälle bis zur verifizierten Behandlung.
Eine CVE ist Rohmaterial, kein Arbeitsauftrag.
Eine Common Vulnerabilities and Exposures (CVE)-Kennung identifiziert eine öffentlich bekannte Schwachstelle. Erst weitere Daten zeigen, ob daraus für die eigene Umgebung Arbeit entsteht: Ist die betroffene Version vorhanden? Ist die verwundbare Funktion aktiv? Ist das System erreichbar? Gibt es aktive Ausnutzung? Welcher Dienst hängt davon ab, und wer kann die Änderung freigeben?
Diese Antworten liegen selten in einem einzigen Produkt. Scanner erkennen Zustände auf Assets, Software Composition Analysis (SCA) ordnet Bibliotheken einem Build zu, eine Software Bill of Materials (SBOM) beschreibt Komponenten eines Releases, Asset- und Exposure-Systeme liefern Ownership und Erreichbarkeit. Threat-Signale wie EPSS oder KEV verändern die Dringlichkeit. Das Vulnerability-Management-System muss diese Spuren zusammenführen, ohne ihre Aussage zu vermischen.
Technischer Zustand
Netzwerk-Scanner, Agenten, Cloud-Connectoren und SCA erkennen Assets, Software, Konfigurationen und Komponenten.
Blindstelle: fehlende Credentials, nicht angebundene Tenants, kurzlebige Cloud-Ressourcen.
Betroffenheit
Produkt, Version, Release und verwundbare Funktion werden mit Herstellerhinweis, SBOM oder VEX abgeglichen.
Blindstelle: Produktnamen und Versionen passen nicht zuverlässig zu CPE- oder PURL-Daten.
Bedrohung
CVSS, EPSS, KEV, Exploit-Informationen und interne Telemetrie ergänzen den technischen Befund.
Blindstelle: ein Gesamtscore verdeckt, welches Signal die Priorität ausgelöst hat.
Exposition
Asset-Kritikalität, Internet-Erreichbarkeit, Identitäten, Netzwerkpfade und vorhandene Kontrollen bestimmen das reale Szenario.
Blindstelle: CMDB, Cloud und Security-Tools führen unterschiedliche Asset-Identitäten.
Technische Änderung
Patch, Upgrade, Konfigurationsänderung, Isolation, virtuelle Abschirmung oder befristete Ausnahme werden verbindlich zugeordnet.
Blindstelle: das VM-Tool kennt Wartungsfenster, Abhängigkeiten und Rollback-Fähigkeit nicht automatisch.
Neuer Zustand
Rescan, Konfigurationsprüfung oder kontrollierte Security Validation bestätigt den definierten Umfang.
Blindstelle: ein Rescan kann einen Befund schliessen, aber nicht jede alternative Angriffskette ausschliessen.
Die Architektur besteht aus mehreren Werkzeugklassen.
Die richtige Kombination hängt davon ab, was geschützt wird. Ein klassischer Infrastruktur-Scanner, ein SCA-Werkzeug und eine Exposure-Plattform überschneiden sich, ersetzen einander aber nicht.
| Werkzeugklasse | Geeignet für | Benötigte Daten oder Zugriff | Liefert | Typische Grenze |
|---|---|---|---|---|
| Infrastruktur-Scanner | Server, Netzwerkgeräte, Datenbanken und Dienste | Scanner-Platzierung, Netzwerkzugang, Credentials | Asset-bezogene Befunde, Konfigurationen und Versionen | Ohne authentisierte Prüfung bleibt die Erkennung oberflächlich. |
| Endpoint Vulnerability Management | Verwaltete Endgeräte und Server mit Agent | Endpoint-Agent, Softwareinventar, Gerätegruppen | Kontinuierliche Software- und Gerätesicht | Nicht verwaltete, selten aktive oder spezialisierte Systeme fehlen. |
| SCA und SBOM-Analyse | Anwendungen, Images, Firmware und Herstellerprodukte | Repository, Build, Artefakt oder SBOM | Komponenten-, Lizenz- und CVE-Zuordnung zum Release | Komponentenfund bedeutet nicht automatisch, dass die verwundbare Funktion erreichbar ist. |
| Cloud-native Security | Cloud-Ressourcen, Workloads, Identitäten und Container | Cloud-APIs, Laufzeitdaten, IaC und Identitätsbeziehungen | Cloud-Kontext und priorisierte Angriffspfade | Die Aussage hängt vollständig von Connector-Abdeckung und Berechtigungen ab. |
| Asset Intelligence / CAASM | Abdeckung, Ownership und Datenqualität über mehrere Tools | APIs zu EDR, Scanner, CMDB, Cloud und IAM | Konsolidiertes Assetbild und Kontrolllücken | Normalisiert fremde Befunde, erzeugt aber keine eigene technische Prüfung. |
| Exposure Management | Externe Angriffsfläche, Identitäts- und Netzwerkpfade | Discovery, Graph- und Konfigurationsdaten | Erreichbare Kombinationen aus Fehlkonfiguration, Privileg und Schwachstelle | Ein modellierter Pfad ist eine Hypothese, bis er technisch bestätigt wurde. |
| Security Validation | Priorisierte Expositionen und Kontrollwirkung | Freigegebener Testumfang, sichere Ausführung, Zieldefinition | Technischer Nachweis für das getestete Szenario | Ersetzt weder das Inventar noch die kontinuierliche Schwachstellenerkennung. |
Die Bearbeitung braucht zwei Pfade.
STOP.LI-Umsetzungsprofil: Für aktiv ausgenutzte oder öffentlich exponierte kritische Schwachstellen sollte die Organisation eine Expositionsprüfung am selben Arbeitstag und eine dokumentierte Behandlungsentscheidung innerhalb von 24 Stunden ermöglichen. Das ist eine betriebliche Empfehlung, keine allgemeine gesetzliche Patchfrist. Konkrete Remediation-Ziele müssen zur Kritikalität, Verfügbarkeit, Testbarkeit und zum eigenen Risikomodell passen.
Das Werkzeug muss prüfbare Daten liefern.
DORA, NIS2 und FINMA werden auf STOP.LI separat behandelt. Für den Werkzeugvergleich sind hier nur die Folgen für Architektur und Betrieb relevant.
| Vorgabe | Konsequenz für das Werkzeug | Im PoC nachweisen |
|---|---|---|
| DORA | Automatisierte, mindestens wöchentliche Prüfung der IKT-Assets kritischer oder wichtiger Funktionen; Drittkomponenten, Behandlung und Abschluss müssen nachvollziehbar bleiben. | Funktionskritikalität steuert den Scanplan. Ausgefallene Scanner und Connectoren werden erkannt. Verlauf und Rescan sind exportierbar. |
| NIS2 / BSIG | Vulnerability Handling, Disclosure und Wirksamkeitsprüfung brauchen eine Verbindung zu Lieferanten, Incident Management und technischer Validierung. | Kenntniszeitpunkt, Betroffenheit, Behandlung und Wirksamkeitsprüfung lassen sich ohne Medienbruch rekonstruieren. |
| FINMA | Der Prüfbereich umfasst internet-erreichbare Komponenten sowie interne Systeme kritischer Prozesse oder mit kritischen Daten. | Inventar und Kritikalität bestimmen den Scope. Ein Befund kann bei Bedarf mit Zeitstempel und Auswirkung an den Incident-Prozess übergeben werden. |
Fristenfähigkeit: Bei einem meldepflichtigen Vorfall müssen die Werkzeuge Kenntniszeitpunkt, Klassifikation, betroffene Funktionen und laufende Massnahmen schnell bereitstellen. Die bekannten 24- und 72-Stunden-Uhren sind Incident-Meldefristen, keine allgemeinen Patch-SLAs.
Stärken, Grenzen und Betriebsmodell zählen gemeinsam.
Die Einordnung basiert auf den öffentlich beschriebenen Produkteigenschaften und dem daraus ableitbaren Einsatzmodell. Eine belastbare Auswahl braucht einen Proof of Concept mit eigenen Assets, Credentials, Cloud-Konten, SBOMs und Arbeitsabläufen.
| Produkt | Einsatzgebiet | Stärken | Grenzen | Integration und Betrieb |
|---|---|---|---|---|
| CommercialTenable One | Hybrid-Infrastruktur und Exposure-Konsolidierung | Breite Scannerbasis, Asset- und Exposure-Sicht über mehrere Tenable-Komponenten. | Ergebnisqualität hängt von Scanner-Platzierung, Credentials, Asset-Zuordnung und lizenzierten Komponenten ab. | Scanner/Agenten, Cloud- und Ticketing-Integrationen; eignet sich für grössere verteilte Scan-Architekturen. |
| CommercialQualys VMDR | Cloud-basierter Enterprise-Betrieb | Asset Discovery, Cloud-Agenten, Schwachstellenbewertung und Response-Funktionen in einer Plattformfamilie. | Module und Datenflüsse müssen klar abgegrenzt werden; Plattformbreite ersetzt keine saubere Ownership. | Cloud-Agenten, Scanner Appliances, APIs und ITSM-Anbindung; Betriebsmodell stark plattformzentriert. |
| CommercialRapid7 InsightVM | Infrastruktur-VM mit Remediation-Workflow | Verteilte Scan Engines, Asset-Gruppen, risikobasierte Priorisierung und Remediation Projects mit Jira-/ServiceNow-Anbindung. | Produktionsbetrieb benötigt geplante Scan-Engine-Architektur; der proprietäre Risikoscore muss intern nachvollzogen werden. | Security Console, verteilte Engines und Ticketing. Gut geeignet, wenn VM und IT-Betrieb gemeinsam in Projekten arbeiten. |
| CommercialMicrosoft Defender Vulnerability Management | Endpunkte und Microsoft-Sicherheitsökosystem | Kontinuierliche Gerätesicht, Softwareinventar, Threat-Kontext und direkte Remediation-Verbindung zu Intune. | Der höchste Integrationsnutzen entsteht im Microsoft-Stack; Spezialgeräte, isolierte Netze und nicht verwaltete Assets benötigen Ergänzungen. | Defender for Endpoint, Entra und optional Intune; APIs für Maschinen, Software und Schwachstellen. |
| Open Source / CommercialGreenbone / OpenVAS | Netzwerkbasierte Schwachstellenprüfung | Offene Community-Variante und etablierter Feed-basierter Scanner; geeignet für kontrollierte Scan-Segmente und Labore. | Organisation trägt bei Open Source mehr Verantwortung für Feed-Aktualität, Scanner-Betrieb, Tuning, Skalierung und Support. | Scanner-Appliance oder eigener Betrieb; Integration und Reporting müssen häufig stärker selbst gebaut werden. |
| Open SourceOWASP Dependency-Track | SBOM-basierte Product Security | Komponenten- und Portfolioanalyse, CycloneDX-Verarbeitung, Richtlinien und kontinuierliche Schwachstellenzuordnung. | Keine Host- oder Netzwerkprüfung. Qualität hängt von vollständigen, aktuellen und releasebezogenen SBOMs ab. | CI/CD- und SBOM-Integration; braucht Product Owner, Versionierung und Prozess für Analyse und VEX. |
| CommercialWiz | Cloud-native Exposure und Workloads | Cloud-Connectoren verbinden Konfiguration, Identität, Workloads, Daten und Schwachstellen zu priorisierten Pfaden. | Kein vollständiger Ersatz für klassische On-Premises-Scanner oder Product-Security-Prozesse. | Cloud-API-Berechtigungen und vollständige Tenant-Abdeckung sind entscheidend; IaC- und Ticketing-Integration möglich. |
| CommercialAxonius Cybersecurity Asset Management | Asset-Kontext, Abdeckung und Ownership | Verbindet vorhandene Security- und IT-Daten, normalisiert Assets und zeigt Lücken zwischen Tools. | Erzeugt keine eigene tiefgehende Schwachstellenprüfung; schlechte Quelldaten bleiben schlechte Quelldaten. | Nutzen wächst mit Anzahl und Qualität der Connectoren. Identitätsauflösung und Datenkonflikte müssen betrieben werden. |
| CommercialPentera | Automatisierte Security Validation | Prüft kontrolliert Ausnutzbarkeit und Angriffspfade über interne, externe und Cloud-Angriffsflächen. | Kein Inventar-, Scanner- oder Triage-System. Ergebnis gilt für den freigegebenen Testumfang und Zeitpunkt. | Benötigt sichere Freigabe, abgestimmten Scope und Rückführung der Evidenz in VM-, Ticket- und Risikoprozesse. |
Mit bekannten Wahrheiten testen.
Ein PoC sollte nicht danach bewertet werden, welches Produkt die meisten Findings erzeugt. Er muss zeigen, wie zuverlässig die Organisation relevante Fälle erkennt und durch den eigenen Betrieb bewegt.
Eine bekannte Asset-Liste mit internet-erreichbaren, internen, Cloud-, Endpoint- und kurzlebigen Systemen gegen die tatsächliche Erkennung prüfen.
Credential-Erfolg, Agentenabdeckung und Cloud-Connector-Berechtigungen separat messen; fehlgeschlagene Prüfungen dürfen nicht als sauber gelten.
Bekannte positive und negative Fälle verwenden: verwundbare Version, nicht verwundbare Version, nicht aktive Funktion und dokumentiertes VEX.
Prüfen, ob CVSS, EPSS, KEV, Exploit-Information, Asset-Kritikalität und Exposition getrennt sichtbar bleiben.
Owner-Zuordnung, Ticketing, Ausnahme, Eskalation und Rückmeldung aus Patch- oder Change-Systemen mit realen Teams durchspielen.
Rescan und Reopen-Fall testen. Das Produkt muss zeigen, wann geprüft wurde, mit welcher Methode und warum der Befund als geschlossen gilt.
Einen simulierten Major-Incident-Fall nutzen: Kenntniszeitpunkt, Klassifikation, betroffene kritische Funktion und Meldedaten müssen fristgerecht verfügbar sein.
Feed-Pflege, Tuning, Scanner- und Connector-Ausfälle, Datenkonflikte, API-Limits sowie Rollenbedarf über mehrere Wochen beobachten.
Vom öffentlichen Modell zur eigenen Umsetzung.
4T2 Solutions unterstützt Finanzinstitute und Hersteller bei Einordnung, Anpassung und operativer Einführung. Ausgangspunkt ist eine konkrete Entscheidung oder ein kontrollierter Pilot, nicht ein neues Grossprogramm.