Warum automatisierte Scanner kritische Schwachstellen übersehen

Automatisierte Schwachstellenscanner sind wirklich nützlich. Sie sind schnell, günstig auszuführen und erkennen zuverlässig bekannte CVEs, fehlende Patches und häufige Fehlkonfigurationen. Genau deshalb behandeln so viele Teams einen sauberen Scan-Bericht als Beweis dafür, dass ihre Systeme sicher sind. Das sind sie nicht, und genau in der Lücke zwischen „gescannt“ und „getestet“ passieren echte Sicherheitsvorfälle.

Ein Scanner funktioniert, indem er Signaturen und bekannte Muster mit Ihren Systemen abgleicht. Er beantwortet hervorragend die Frage „ist diese Software veraltet“ oder „ist dieser Port offen, der es nicht sein sollte“. Deutlich schwächer ist er bei der Frage, die für einen Angreifer wirklich zählt: „Kann ich mehrere, für sich genommen niedrig eingestufte Probleme zu etwas verknüpfen, das mir Zugang verschafft?“

Logikfehler in der Anwendung selbst sind das klarste Beispiel. Ein Scanner hat kein Verständnis dafür, was Ihre Anwendung eigentlich tun soll: er erkennt nicht, dass ein Nutzer eine versteckte Bestell-ID ändern und die Rechnung eines anderen Kunden einsehen kann, oder dass ein Passwort-Reset-Vorgang gerade genug Informationen offenlegt, um eine Kontoübernahme trivial zu machen. Solche Probleme sehen in einer Signaturdatenbank nicht wie eine „Schwachstelle“ aus. Sie sehen aus, als würde Ihre Anwendung genau so funktionieren, wie sie programmiert wurde, nur eben nicht wie beabsichtigt.

Authentifizierungs- und Autorisierungslücken verhalten sich ähnlich. Ein Scan markiert vielleicht, dass ein API-Endpunkt existiert; er bemerkt nicht, dass der Endpunkt nicht prüft, ob der anfragende Nutzer die angeforderte Ressource überhaupt besitzt. Genau diese eine fehlende Prüfung ist eine der häufigsten Grundursachen, die wir in realen Projekten finden, und sie ist für signaturbasierte Tools per Definition unsichtbar.

Das andere, was manuelle Tests bringen und Automatisierung nicht kann: Einschätzungsvermögen dafür, was in Ihrer spezifischen Umgebung tatsächlich ausnutzbar ist. Zwei Organisationen können identische Scan-Ergebnisse und dennoch völlig unterschiedliche reale Risiken haben, abhängig von Netzwerksegmentierung, kompensierenden Kontrollen und dem, was von außen tatsächlich erreichbar ist. Ein Tester verbringt den Auftrag damit, herauszufinden, welche Befunde sich zu einem echten Weg zu sensiblen Daten verknüpfen lassen, nicht nur damit, alles aufzulisten, was ein Tool markiert hat.

Das alles ist kein Argument gegen Scanning. Es ist eine schnelle, wertvolle erste Schicht, und wir nutzen sie auch, als Ausgangspunkt. Das Argument richtet sich dagegen, dabei stehen zu bleiben. Wenn Ihre Systeme seit mehr als einem Jahr (oder noch nie) von einem Menschen überprüft wurden, der aktiv versucht einzudringen, sagt ein Scan-Bericht, der Ihnen sagt, alles sei in Ordnung, weniger aus, als er klingt.