Zero-Day – Praxis

Zero-Days sind im Audit weniger ein Pruefpunkt fuer die Schwachstelle selbst, sondern fuer den Prozess: Wie reagiert die Organisation, wenn ein Zero-Day in verwendeter Software bekannt wird? Was Auditoren pruefen und welche Evidence benoetigt wird, zeigt dieser Abschnitt.

Was Auditoren konkret pruefen

Bei einer Pruefung des Zero-Day-Managements prueft der Auditor den vorhandenen Prozess fuer den Umgang mit neu bekannten Schwachstellen und die Evidence aus vergangenen Zero-Day-Vorfaellen. Das BAM-Objekt CROSS-ZD-01 definiert, was konkret vorgelegt werden muss.

Haeufige Fehler

• Kein dokumentierter Zero-Day-Response-Prozess – ad-hoc-Reaktion im Ernstfall
• Keine Threat-Intelligence-Quelle fuer Zero-Day-Warnungen
• Workaround-Verfahren nicht vorbereitet – bis zum Patch schutzlos
• Zero-Day-Ausnutzung nicht als IKT-Vorfall behandelt und dokumentiert

Umsetzung: Zero-Day-Response-Prozess

Erster Schritt: Threat-Intelligence-Feeds einrichten (CERT-Bund, NVD, BSI-Warnmeldungen). Zweiter Schritt: Software-Inventar aufbauen – um zu wissen, welche Software beim naechsten Zero-Day betroffen sein koennte. Dritter Schritt: Zero-Day-Response-Verfahrensanweisung erstellen (Eskalation, Bewertung, Workaround, Patching). Vierter Schritt: Workaround-Katalog fuer kritische Systeme vorbereiten. Fuenfter Schritt: Vergangene Zero-Days als Uebungsszenarien verwenden.

Evidence-Anforderungen im Audit

Der Auditor erwartet: datierte Zero-Day-Response-Verfahrensanweisung, Nachweis der Threat-Intelligence-Feeds, vollstaendiges Software-Inventar (Grundlage fuer Betroffenheitspruefung), und – bei tatsaechlichen Zero-Days – die Reaktionsdokumentation mit Zeitstempeln.

Die strategische Einordnung – warum Zero-Day-Management langfristig mehr als ein Patch-Prozess ist – findet sich auf Ebene 3.