Patch erledigt, Risiko geblieben: Warum Behebung selten verifiziert wird

Lavi unterscheidet zwischen Fixes, deren Wirkung sich bestätigen lässt, und solchen, bei denen das offenbleibt. Wird ein Patch eingespielt, gibt es eine Rückmeldung. Wird dagegen eine Berechtigung gesetzt oder eine EDR- beziehungsweise SIEM-Konfiguration angepasst, braucht es einen Test, der prüft, ob die Änderung tatsächlich greift. Sein Beispiel: Eine schwache Firewall-Regel lässt die Tür offen; die Richtlinie wurde umgeschrieben und angeblich angewendet – aber ob das stimmt, bleibt ohne Verifikation ungewiss.

Ein zweites Problem sei organisatorischer Natur. Wer ein Risiko findet, besitzt selten den Fix. Die zuständigen Teams arbeiten nach eigenen Zeitplänen und Prioritäten, und Sicherheitsbefunde konkurrieren mit dem, was ohnehin schon ansteht – meist verlieren sie. In Cloud-nativen und hybriden Umgebungen verschwimmt die Zuständigkeit zusätzlich: Eine Schwachstelle kann in der Anwendungsschicht, der Infrastruktur oder einer Drittanbieter-Abhängigkeit liegen. Die Behebung läuft dann durch die jeweiligen Prozesse – Change-Fenster bei IT und DevOps, Sprint-Zusagen im Engineering. KI-beschleunigte Angreifer warten weder auf das nächste Change-Fenster noch auf den nächsten Sprint.

Gegen diesen organisatorischen Reibungsverlust nennt Lavi konkrete Hebel: zusammengehörige Befunde bündeln, sodass mehrere validierte Probleme, die auf denselben falsch konfigurierten Load Balancer zurückgehen, zu einem Ticket mit einem Verantwortlichen werden. Routing, Zuweisung, SLA-Durchsetzung und Eskalationswege ließen sich automatisieren – heraus aus Tabellen und Chat-Nachrichten.

Doch Durchsatz und Geschwindigkeit sagten nur, wie schnell ein System arbeitet, nicht, ob es funktioniert. Man könne ein gebündeltes Ticket binnen Minuten einem Verantwortlichen zuweisen, das SLA durchsetzen, planmäßig eskalieren – und trotzdem ein Ticket schließen, das die Angriffsfläche nicht beseitigt hat. Vielleicht übersteht die Behelfslösung die nächste Konfigurationsänderung nicht, vielleicht erreichte der Fix nur drei von vier betroffenen Systemen, oder der Patch ließ eine umgebende Fehlkonfiguration unangetastet. Das Ticket meldet „gelöst“, der Angriffspfad bleibt offen.

Daraus leitet Lavi seine Kernforderung ab: Eine erneute Prüfung dürfe nicht nur bestätigen, dass der ursprüngliche Angriff nicht mehr funktioniert, sondern dass das Risiko selbst nicht mehr existiert. Werde jeder Fix erneut getestet und das Ergebnis sowohl der Sicherheits- als auch der Engineering-Leitung sichtbar gemacht, fielen Teillösungen und Behelfsmaßnahmen sofort auf, statt in einem Dashboard zu versanden – ein Rückkopplungseffekt, der das System selbstkorrigierend mache.

Den tragfähigen Ablauf beschreibt er so: validierte Befunde zu Fix-Maßnahmen bündeln, an bestätigte Verantwortliche routen, bis zum Abschluss verfolgen und anschließend revalidieren, um zu bestätigen, dass das zugrunde liegende Risiko verschwunden ist – nicht nur der ursprüngliche Angriffspfad. Pentera bewirbt seine Plattform als auf genau dieses Modell ausgelegt, indem sie den Behebungs-Workflow mit der Validierung nach dem Fix verbindet. In einer Zeit, in der KI Exploit-Ketten autonom ableiten und neu ableiten könne – wie es Mythos gezeigt habe –, sei falsches Vertrauen das teuerste Element eines Sicherheitsprogramms.