Vulnerability Assessment
Methodology
Validierte Schwachstellen- und Massnahmen-Workbench. Scanner-Findings werden validiert, priorisiert, mit Business-Kontext angereichert und in Massnahmen überführt.
Scan vs. Assessment vs. Pentest
| Kriterium | Vulnerability Scan | Vulnerability Assessment | Penetrationstest |
|---|---|---|---|
| Beschreibung | Automatisierte Suche nach potenziellen Schwachstellen. Produziert eine lange Liste möglicher Findings. | Validierung und Priorisierung der Scan-Ergebnisse. Erzeugt einen triagierten, priorisierten Backlog. | Menschlich geführte Angriffsketten mit Bericht und Sign-off. |
| Output | Lange Finding-Liste | Priorisierter Backlog | Narrativer Pentest-Bericht |
| Frequenz | Täglich | Wöchentlich | Jährlich / TLPT |
| Human Review | Automatisch | Erforderlich | Erforderlich |
| False Positives | Hoch (30-50%) | Niedrig (validiert) | Keine (manuell) |
| DORA-Testart | Art. 25: Schwachstellenbewertungen | Art. 25: Lückenanalysen | Art. 26-27: TLPT |
Tägliche Scans liefern Rohdaten. Keine Validierung, keine Priorisierung. False-Positive-Rate bis 50%. Scanner-Findings sind kein Massnahmenplan.
Wöchentliche Validierung der Scan-Ergebnisse: Exploitability-Prüfung, Business-Kontext, Risikobewertung. False Positives werden aussortiert. Findings werden priorisiert.
Jährliche menschliche Angriffssimulation mit Bericht. Deckt logische Fehler, Business-Logik-Lücken und komplexe Angriffsketten ab, die Scanner nicht finden.
DORA-Testarten — Art. 24-27
| DORA Artikel | Testart | Beschreibung | Frequenz | Abdeckung |
|---|---|---|---|---|
| Art. 24 | IKT-Testprogramm | Umfassendes Testprogramm für alle IKT-Systeme und -Anwendungen | Laufend | Alle kritischen Funktionen |
| Art. 25 | Schwachstellenbewertungen | Regelmässige Scans und Lückenanalysen — validiert, priorisiert, mit Massnahmenplan | Wöchentlich | Alle IKT-Systeme |
| Art. 26 | TLPT (Bedrohungsbasierter Pentest) | Threat-Led Penetration Testing — reale Angriffssimulation gegen kritische Funktionen | 3-Jahres-Zyklus | Kritische IKT-Funktionen |
| Art. 27 | TLPT-Durchführung | Testing-Threat-Intelligence-gesteuerter Pentest mit zertifizierten Testern | 3-Jahres-Zyklus | Kritische IKT-Funktionen |
Detaillierter Methodenvergleich
Klicken Sie auf eine Methode für Details. Das Vulnerability Assessment ist die empfohlene Basis für die wöchentliche Validierung.
Assessment Lifecycle (10 Schritte)
Scope definieren
CISO / Pentest-LeadTestart, Zielsysteme und Autorisierung festlegen
Findings importieren
Security EngineerScanner-, SBOM-, API-Ergebnisse einlesen
Exploitability validieren
PentesterNicht-destruktiv prüfen, ob Finding tatsächlich ausnutzbar ist
Business-Kontext
Security EngineerKritische Funktion, Datenklasse, regulatorischer Bezug
Priorisieren
Security EngineerResilience Priority Score und SLA zuweisen
Remediation Plan
DeveloperFix-Typ: Code, Konfiguration, Patch, Dependency-Upgrade
Human Gate
⚠ Human Gate CISO / Risk-OwnerCritical/High: Security-Review. Risikoakzeptanz: Risk-Owner
Fix umsetzen
DeveloperPR öffnen, Deployment planen
Re-Test
PentesterNach Fix erneut testen
Evidence Pack
Security EngineerFinding + Fix + Re-Test dokumentieren
Betriebsmodelle für das Vulnerability Assessment
Die Organisation des Vulnerability Assessments hängt vom Betriebsmodell ab. Drei typische Modelle für Finanzinstitute.
Empfohlen für Institute mit eigener Security-Organisation (≥ 3 FTE)
Vollständige Kontrolle über Tool-Auswahl, Scan-Frequenz und Assessment-Tiefe. Erfordert investiertes Personal für Tool-Betrieb, Finding-Triage und Reporting. Geeignet für Institute mit etablierter Security-Kultur und ausreichendem Budget für Tool-Lizenzen und Personal.
Empfohlen für Institute ohne eigene Security-Operation (0-1 FTE)
Der Provider betreibt Scanner, SIEM und Patch-Management. Die Bank konzentriert sich auf Governance: Report-Review, SLA-Überwachung, Exception-Handling und Evidence. Erfordert einen validierten Right-to-Test-Mechanismus und klare vertragliche SLAs. Die Herausforderung liegt in der Sicherstellung der Transparenz und der Ausübung der Letztverantwortung.
Empfohlen für Institute mit teilweiser Security-Organisation (1-2 FTE)
Scanner und Basis-Assessment werden vom Dienstleister betrieben. Die Bank übernimmt die Business-Kontext-Anreicherung, Priorisierung und das Management-Reporting. Ermöglicht eine schrittweise Skalierung der internen Security-Kompetenz und Flexibilität bei der Tool-Auswahl. Erfordert klare Schnittstellen und regelmäßige Abstimmungsgespräche.
Quality Gates — Prüfkriterien je Phase
Jede Phase hat definierte Qualitätskriterien. Erst wenn alle Kriterien erfüllt sind, wird die nächste Phase freigegeben. Der Fortschritt wird lokal gespeichert.
RACI — Verantwortlichkeiten
| Phase | CISO | SecEng | Pentester | Developer | Risk-Owner |
|---|---|---|---|---|---|
| Scope Definition | A | R | C | I | I |
| Findings Import | I | R | C | I | — |
| Exploitability Validation | I | C | R | — | — |
| Business Context | I | R | — | C | C |
| Priorisierung & SLA | A | R | C | I | I |
| Remediation Plan | I | C | — | R | I |
| Human Gate (Critical/High) | A | R | C | I | A |
| Fix Umsetzung | I | C | — | R | I |
| Re-Test | I | C | R | — | — |
| Evidence Pack | I | R | C | I | I |
R&R — Verantwortung nach Betriebsmodell
Die Verteilung der Verantwortlichkeiten unterscheidet sich je nach Betriebsmodell. Während im Eigenbetrieb alle Aufgaben intern liegen, verschiebt sich im Outsourcing-Modell die operative Verantwortung zum Provider — die Governance-Verantwortung bleibt bei der Bank.
| Aufgabe | Institut | Provider |
|---|---|---|
Letztverantwortung
Unabhängig vom Betriebsmodell bleibt die Bank für die ordnungsgemässe Durchführung des Vulnerability Assessments verantwortlich (DORA Art. 24, MaRisk AT 9). Im Outsourcing-Modell muss die Bank durch vertragliche Right-to-Test-Klauseln, regelmässige Report-Reviews und Stichprobenprüfungen sicherstellen, dass die Provider-Leistung den aufsichtlichen Anforderungen entspricht.
Tool-Kategorien & Capability-Mapping
Die Methodik ist tool-unabhängig. Nachfolgend sind Kategorien mit beispielhaften Open-Source- und kommerziellen Tools aufgeführt, die die jeweilige Phase unterstützen. Keine Tool-Empfehlung — die Auswahl hängt vom individuellen Risikoprofil, bestehender Infrastruktur und Budget ab.
Hinweis zur Tool-Auswahl
Die genannten Tools sind Beispiele und keine verbindliche Empfehlung. Die Auswahl der konkreten Tools hängt vom individuellen Risikoprofil, der bestehenden Tool-Landschaft, den verfügbaren Qualifikationen und dem Budget des Instituts ab. Die Resilience Platform ist kein Tool-Vergleichsportal.
Tool-Vergleich nach Anwendungsfall
Übersicht der empfohlenen Tool-Kategorien für die jeweilige Phase des Vulnerability Assessments. Die Bewertung dient der Orientierung — keine verbindliche Klassifikation.
| Phase | Tool-Kategorie | Open Source | Kommerziell | Empfohlen für |
|---|---|---|---|---|
| Scan | Infrastruktur-Scanner | Greenbone/OpenVAS | Nessus, Qualys, Rapid7 | Wöchentliche Infrastruktur-Scans |
| Scan | Web-Scanner | OWASP ZAP | Burp Suite, Acunetix | Monatliche Web-App-Scans |
| Scan | Cloud-Scanner | Checkov, Prowler | Wiz, Prisma Cloud | Kontinuierliche Cloud-Sicherheit |
| Scan | SBOM/Dependency | Trivy, Grype, DepTrack | Snyk | CI/CD-Integration |
| Assessment | Finding-Management | DefectDojo | Raven, ServiceNow | Triage & Workflow |
| Assessment | Priorisierungs-Engine | — | Kenna/VulnDB, Qualys TRU | Risk-Based Prioritization |
| Pentest | Pentest-Framework | Kali, Metasploit | Cobalt Strike | Manuelle Sicherheitstests |
| Pentest | AD-Assessment | BloodHound | — | Active-Directory-Sicherheit |
| Alle | SIEM/Log-Management | Wazuh, ELK | Splunk, Elastic | Zentrale Protokollierung |
Empfehlung für den Einstieg
Greenbone/OpenVAS (Scan) + DefectDojo (Assessment) + OWASP ZAP (Web) + Trivy (SBOM) + Wazuh (SIEM) — vollständig Open Source, keine Lizenzkosten, geeignet für Institute mit 1-2 FTE Security-Kapazität.
€ 5K-15K
Jährliche Lizenzkosten (pro Tool)
Setup: 1-2 Tage
Betrieb: 2-4 Std./Monat
Personal: 0,1 FTE
€ 20K-50K
Jährlich (intern/extern gemischt)
Setup: 1-2 Wochen
Betrieb: 1-2 Tage/Woche
Personal: 0,3-0,5 FTE
€ 30K-80K
Pro Test (extern, einmalig)
Setup: 2-4 Wochen Vorlauf
Dauer: 1-3 Wochen Test
Personal: extern + 0,1 FTE intern
Evidence-Anforderungen (DORA Art. 24-27)
Jede Testart erzeugt spezifische Nachweise für die aufsichtliche Prüfung. Die folgende Matrix zeigt die erforderlichen Evidence-Items, deren Qualitätskriterien und die zugehörigen DORA-Artikel.
| Evidence-Item | Testart | DORA | Qualitätskriterium | Aufbew. | Prüfbar |
|---|---|---|---|---|---|
| Scan-Konfiguration | Scan | Art. 25 | Tool-Name, Version, Plugin-Feed-Datum, Ziel-IPs/-Subnetze, Authentifizierungs-Level, Ausgeschlossene Targets mit Begründung | 1 J | IR, DORA |
| Scan-Ergebnis (Rohdaten) | Scan | Art. 25 | Vollständiger Export aller Findings mit CVSS, Host, Port, Plugin-ID, Plugin-Name, Plugin-Output, Plugin-Feed-Datum | 1 J | IR, DORA |
| Coverage-Nachweis | Scan | Art. 24-25 | Asset-Abgleich: gescannte vs. bekannte Assets. Nicht gescannte Assets mit Begründung. Coverage-Quote in %. | 1 J | IR, DORA |
| Validierte Findings-Liste | Assessment | Art. 25 | Jedes Finding mit Status: true/false_positive/exploitable/nicht_ausnutzbar. Validierungsdatum, Validator-Name, Validator-Methode | 3 J | IR, Audit |
| Business-Kontext-Anreicherung | Assessment | Art. 5, 25 | Kritische Funktion, Datenklasse, Exposure-Level, DORA-Criticality, regulatorischer Bezug pro Finding dokumentiert | 3 J | IR, Audit |
| Priorisierungsmatrix | Assessment | Art. 25 | Resilience-Priority-Score pro Finding, SLA-Zuweisung, Ranking, Behandlungspfad (fix/mitigate/accept/escalate) | 3 J | IR, Audit |
| Human-Gate-Protokoll | Assessment | Art. 6, 25 | Review-Datum, Reviewer-Name, Entscheidung (approved/rejected/escalated), Begründung bei Risikoakzeptanz, Risk-Owner-Signatur | 5 J | IR, Audit, Aufsicht |
| SLA-Compliance-Nachweis | Assessment | Art. 5, 30 | SLA-Einhaltungsquote pro Prioritässtufe, verletzte SLAs mit Grund, Eskalationsstatus, Nachbesserungsmassnahmen | 3 J | IR, Audit |
| Pentest-Bericht (narrativ) | Pentest | Art. 26-27 | Executive Summary, Methodik, Scoping, detaillierte Findings mit Proof-of-Concept, Screenshots, Risikobewertung, Handlungsempfehlung | 5 J | Aufsicht, Audit |
| Tester-Qualifikationsnachweis | Pentest | Art. 27 | CVs der Tester, Zertifikate (OSCP, CISSP, GIAC, etc.), Referenzprojekte, Unabhängigkeitserklärung | 5 J | Aufsicht |
| Abweichungsanalyse | Pentest | Art. 26-27 | Abweichungen vom Testplan mit Begründung, nicht getestete Bereiche mit Risikobewertung, Wiederholungstermin | 5 J | Aufsicht, Audit |
| Management-Summary | Alle | Art. 5, 24 | Kurzzusammenfassung für Vorstand/Risikokomitee: kritische Findings, SLA-Status, Eskalationen, Handlungsbedarf | 5 J | Vorstand, Aufsicht |
Evidence-Lifecycle
Erzeugung
Automatisch oder manuell
Validierung
Vollständigkeit + Korrektheit
Ablage
Revisionssicher + indexiert
Prüfung
Durch Revision/Aufsicht
Archivierung
Nach Aufbewahrungsfrist
Evidence-Prüfprotokoll
≤ 24h
Reaktionszeit
Sofortmassnahme
≤ 48h
Reaktionszeit
Massnahmenplan erforderlich
≤ 2 Wochen
Behebungsfrist
Nächster Sprint
≤ 90 Tage
Behebungsfrist
Nächster regulärer Zyklus
Scans vorhanden, kein Assessment
Ad-hoc-Assessments
Wöchentliches Assessment
Integriert + Priorisiert
Kontinuierlich + Evidence
Key Insight
Das Assessment ist die „missing middle" zwischen Scanner und Pentest — es validiert, priorisiert und erzeugt einen triagierten Backlog. Ohne Assessment bleiben Scanner-Findings eine Rauswolke. Ohne Assessment ist der Pentest zu teuer & zu selten.
🔗 Verwandte Module
Wichtiger Hinweis: Nur autorisierte Tests durchführen. Validierung erfolgt nicht-destruktiv. Jedes Finding mit Critical/High-Priorität oder Risikoakzeptanz erfordert eine menschliche Review (Human Gate).