Schwachstellenscan oder Penetrationstest: was ein Scanner findet und wo er aufhört

Fast jede Anfrage zur Schwachstellenanalyse beginnt gleich: Jemand hat einen Scan laufen lassen, hat jetzt 340 Befunde auf dem Tisch, davon 28 als „kritisch“ markiert, und weiß nicht, wo er anfangen soll. Die richtige Reaktion ist selten, alle 28 abzuarbeiten - meistens ist es, herauszufinden, welche davon in Ihrer Umgebung überhaupt etwas bedeuten.

Dieser Artikel geht durch, wie ein Schwachstellenscan technisch funktioniert, was er zuverlässig findet, was er strukturell nicht finden kann, warum so viele Meldungen Fehlalarme sind, wie ein CVSS-Wert zu lesen ist und wie Scan, Analyse und Penetrationstest zusammen ein Programm ergeben.

Wie ein Schwachstellenscan funktioniert

Der Ablauf ist in jedem Werkzeug - Nessus, OpenVAS, Nuclei und die übrigen - im Kern derselbe:

1. Erkennung. Welche Hosts antworten, welche Ports sind offen, welche Dienste laufen darauf.
2. Fingerprinting. Welche Software und welche Version steckt hinter jedem Dienst. Das ist der Schritt, auf dem alles Weitere aufbaut - und der Schritt, der am häufigsten danebenliegt.
3. Abgleich. Die erkannte Version wird gegen eine Datenbank veröffentlichter Schwachstellen gehalten, üblicherweise identifiziert über ihre CVE-Nummer.
4. Bewertung. Jeder Treffer bekommt einen Schweregrad, meist den CVSS-Basiswert aus dem CVE-Eintrag.

Der entscheidende Punkt: Bei den meisten Prüfungen wird die Verwundbarkeit abgeleitet, nicht belegt. Der Scanner sieht „nginx 1.18.0“, findet dazu einen CVE-Eintrag und meldet ihn. Ob die Lücke in Ihrer konkreten Konfiguration tatsächlich erreichbar ist, hat er nicht geprüft.

Was ein Scanner zuverlässig findet

Trotz dieser Einschränkung ist ein Scanner in seinem Bereich ausgezeichnet - und dieser Bereich ist keineswegs klein:

• Veraltete Komponenten mit bekannten CVEs, quer über hunderte Systeme in Stunden.
• Fehlkonfigurationen mit klaren Signaturen: offene Verwaltungsschnittstellen, Standardzugangsdaten, Verzeichnislisten, aktivierte Debug-Endpunkte.
• Schwache TLS-Konfiguration, abgelaufene Zertifikate, unterstützte veraltete Protokollversionen.
• Fehlende Sicherheits-Header und offensichtlich zu weit gefasste Freigaben.
• Abweichungen gegen eine Basislinie - was hat sich seit dem letzten Durchlauf verändert.

Bei Geräten mit eigener Firmware endet die Reichweite eines Netzscanners allerdings an der Geräteoberfläche: was darunter liegt, prüfen IoT- und Embedded-Penetrationstests.

Das ist genau die Arbeit, die ein Mensch nicht machen sollte: viel, gleichförmig und fehleranfällig, wenn sie von Hand gemacht wird. Deshalb beginnt auch unsere Schwachstellenanalyse mit automatisierten Durchläufen - sie hört dort nur nicht auf.

Was ein Scanner nicht finden kann

Die folgenden Befundklassen sind für ein automatisiertes Werkzeug nicht nur schwierig, sondern strukturell unerreichbar - weil das Werkzeug nicht weiß, was in Ihrer Anwendung erlaubt sein soll:

• Fehlerhafte Autorisierung. Nutzer A sieht die Bestellungen von Nutzer B. Für den Scanner ist das eine erfolgreiche HTTP-Antwort mit Status 200. Er hat keine Vorstellung davon, wem welcher Datensatz gehören sollte.
• Fehler in der Geschäftslogik. Ein Rabattcode, der sich mehrfach einlösen lässt. Ein Bestellschritt, der sich überspringen lässt. Ein negativer Betrag, der als Gutschrift verbucht wird.
• Verkettete Befunde. Eine harmlose Informationspreisgabe plus eine schwache Passwort-Richtlinie plus ein vergessener Testzugang ergeben zusammen eine vollständige Übernahme. Der Scanner meldet drei Befunde mit niedrigem Schweregrad und sieht die Kette nicht.
• Umgehung von Mehrfaktor-Authentifizierung über einen Nebenpfad, etwa eine API, die den zweiten Faktor nicht erzwingt.
• Fachliche Datenlecks. Eine Schnittstelle, die mehr Felder zurückgibt als die Oberfläche anzeigt - technisch korrekt, fachlich ein Datenschutzvorfall.

Alle diese Klassen stehen in den OWASP-Methodiken an prominenter Stelle, und keine davon lässt sich mit einem Versionsabgleich erkennen.

Fehlalarme und warum es so viele sind

Der häufigste Fall in der Praxis: zurückportierte Sicherheitspatches. Debian, Red Hat und andere Distributionen übernehmen den Sicherheitsfix in ihre eigene Paketversion, ohne die von der Anwendung gemeldete Versionsnummer anzuheben. Die Lücke ist geschlossen, der Scanner meldet sie trotzdem - er kennt nur die Nummer.

Dazu kommen:

• Nicht erreichbarer Code. Die verwundbare Funktion ist in der Bibliothek vorhanden, wird von Ihrer Anwendung aber nie aufgerufen.
• Kompensationsmaßnahmen. Eine Web Application Firewall, eine Netzsegmentierung oder eine Authentifizierung davor macht den Angriffsweg praktisch unbenutzbar.
• Falsches Fingerprinting. Ein Reverse Proxy oder ein absichtlich verändertes Banner führt zu einer komplett falschen Zuordnung.

Deshalb ist der Arbeitsschritt, der aus einer Werkzeugausgabe eine Analyse macht, immer derselbe: jeden ernsthaften Befund von Hand verifizieren, den Rest als Rauschen markieren und begründen, warum. Eine Liste ohne diesen Schritt beschäftigt Ihr Team wochenlang mit Dingen, die keine Rolle spielen.

Wie Sie CVSS richtig lesen

Der CVSS-Wert wird routinemäßig als Risiko gelesen. Das ist er nicht. Er beschreibt die Schwachstelle an sich, unter Standardannahmen, ohne Ihre Umgebung zu kennen.

Ein Basiswert von 9.8 bedeutet: aus dem Netz ausnutzbar, ohne Zugangsdaten, mit vollständiger Auswirkung auf Vertraulichkeit, Integrität und Verfügbarkeit - wenn das System so erreichbar ist, wie die Bewertung annimmt. Vier Fragen übersetzen den Wert in Ihre tatsächliche Priorität:

In der Praxis ist eine Schwachstelle mit CVSS 6.5 auf dem Kundenportal fast immer dringender als eine mit 9.8 auf einem abgeschotteten Testsystem. Das ist die Priorisierung von Schwachstellen - und sie ist der Teil der Arbeit, der die Reihenfolge Ihrer nächsten drei Monate bestimmt.

Scan, Schwachstellenanalyse, Penetrationstest

Drei Begriffe, die in Angeboten durcheinandergehen, obwohl sie unterschiedliche Fragen beantworten.

Die Reihenfolge ist aufsteigend, nicht alternativ. Wer nur scannt, hat eine lange Liste ohne Prioritäten. Wer nur einmal jährlich testet, übersieht die CVEs, die in den elf Monaten dazwischen veröffentlicht wurden.

Wie Sie es zusammensetzen

Ein Programm, das in mittelgroßen Organisationen funktioniert:

1. Laufend scannen - extern erreichbare Systeme wöchentlich, interne monatlich, plus nach jeder wesentlichen Änderung.
2. Quartalsweise verifizieren - ein Mensch geht die ernsthaften Befunde durch, entfernt Fehlalarme und ordnet die Liste nach tatsächlicher Priorität. Das ist die eigentliche Schwachstellenanalyse.
3. Jährlich testen - ein Penetrationstest deckt die Klassen ab, die kein Werkzeug findet, und liefert den Nachweis, den ein Auditor sehen will.
4. Nach der Behebung erneut prüfen. Ohne Retest haben Sie ein dokumentiertes Problem statt einer dokumentierten Lösung.

Für die regulierte Variante: ISO 27001 verlangt in Anhang A 8.8 das Management technischer Schwachstellen und in A 8.29 zusätzlich Sicherheitstests; NIS2 verlangt in Artikel 21 Absatz 2 lit. f) Verfahren zur Bewertung der Wirksamkeit der Maßnahmen. Wie sich das konkret nachweisen lässt, steht auf den Seiten zu ISO 27001 und NIS2.

Schwachstellenscan - häufige Fragen

Passende Haxoris-Leistungen: Schwachstellenanalyse von Systemen und Anwendungen · Penetrationstests für Webanwendungen und Infrastruktur · Penetrationstests für die NIS2-Umsetzung