Schwachstellenscan

Was ist ein Schwachstellenscan?

Ein Schwachstellenscan ist ein automatisierter Test: Ein Tool verbindet sich mit Hosts, Diensten, Containern oder Webanwendungen, erkennt Software und Versionen und gleicht sie mit einer Datenbank bekannter Schwachstellen (CVEs) und unsicherer Konfigurationen ab. Das Ergebnis ist eine Liste von Findings mit CVSS-Score, beim ersten Lauf meist Hunderte oder Tausende. NIST SP 800-115 beschreibt Schwachstellenscans als Technik zur Zielerkennung und -analyse: Der Scan sagt dir, was da ist und was daran öffentlich als fehlerhaft bekannt ist.

Scans gibt es in mehreren Formen. Unauthentifizierte Netzwerkscans sehen, was ein Außenstehender sieht. Authentifizierte Scans melden sich am Host an und lesen installierte Pakete, was deutlich genauer ist. Webanwendungsscanner crawlen und fuzzen HTTP-Parameter auf Injection- und Konfigurationsfehler. Container- und Dependency-Scanner lesen Manifeste und SBOMs statt laufender Systeme.

Wo ist es definiert?

Scannen ist eine Technik, kein Standard, aber mehrere Rahmenwerke verlangen es. NIST SP 800-115 (Abschnitt 4.3) beschreibt Methode und Grenzen. NIST SP 800-40 Revision 4 ordnet den Scan in das Patch-Management eines Unternehmens ein. NIS2 verlangt in Artikel 21 Absatz 2 Buchstabe e “Sicherheit bei Erwerb, Entwicklung und Wartung von Netz- und Informationssystemen, einschließlich Management und Offenlegung von Schwachstellen”, was in der Praxis heißt, die eigenen Schwachstellen laufend zu kennen. Der Cyber Resilience Act verpflichtet Hersteller, Schwachstellen und Komponenten ihrer Produkte zu ermitteln und zu dokumentieren (Anhang I Teil II Nummer 1), und ein Dependency-Scan gegen die SBOM ist der übliche Weg dorthin. Der Katalog der Known Exploited Vulnerabilities (KEV) der CISA ist der gängige Filter dafür, was zuerst behoben wird.

Was es in der Praxis bedeutet

Ein Scan ist die Grundlage, nicht der Test. Was wir sehen, wenn Kunden uns vor einem Penetrationstest ihre Scan-Ergebnisse geben:

• Die Menge versteckt die Priorität. Ein erster Scan eines mittelgroßen Netzes liefert Tausende Findings. Die meisten sind Duplikate, informativ oder nicht erreichbar. Sortiere nach Exponierung und nach aktiver Ausnutzung (KEV), bevor du nach CVSS sortierst.
• False Positives und False Negatives gibt es beide. Versionsbasierte Erkennung meldet einen zurückportierten Fix als verwundbar und übersieht einen verwundbaren Dienst auf einem ungewöhnlichen Port. Authentifizierte Scans lösen das erste Problem weitgehend und das zweite gar nicht.
• Scanner verstehen deine Anwendung nicht. Eine IDOR, die die Rechnung eines anderen Kunden preisgibt, eine fehlende Autorisierungsprüfung auf einem Admin-Endpunkt, ein schwacher Passwort-Reset: Nichts davon steht in einer Datenbank. Dasselbe gilt für Embedded-Geräte. Ein Scanner sieht einen offenen Port 502; er weiß nicht, dass die SPS dahinter unauthentifizierte Schreibzugriffe annimmt.

Richtig eingesetzt läuft der Scan wöchentlich oder bei jedem Build, speist einen Schwachstellenmanagement-Prozess mit Verantwortlichen und Fristen und sagt dir, wann ein bekannter Bug in deiner Umgebung auftaucht. Der Penetrationstest sucht dann das, was der Scanner nicht sehen kann.

Häufige Missverständnisse

Ein Scan-Bericht ist kein Penetrationstest, auch nicht mit dem Deckblatt eines Beraters. Der Unterschied liegt nicht im Tool, sondern im Menschen, der die Antworten liest, Findings verkettet und ausnutzt. Ein sauberer Scan bedeutet auch kein sicheres System; er bedeutet, dass dieser Scanner an diesem Tag keine bekannte Schwachstelle erkannt hat. Und “Vulnerability Assessment” verwenden Anbieter sowohl für einen reinen Scan als auch für einen Scan mit manueller Verifikation, also frag, was du kaufst.