Was ist ein Schwachstellenscan?
Ein Schwachstellenscan ist eine automatisierte oder toolgestützte technische Prüfung, die erreichbare, einbezogene IT-Assets mit bekannten Schwachstelleninformationen abgleicht und potenzielle Schwachstellen aufzeigt.
Scanner ermitteln dazu beispielsweise Hosts, Betriebssysteme, Anwendungen, Dienste, offene Ports oder Konfigurationen und vergleichen die Merkmale mit bekannten Schwachstelleninformationen. Ein Treffer ist ein Hinweis für die weitere fachliche Prüfung, kein Beweis für eine praktisch ausnutzbare Schwachstelle.
Welche technische Grundlage beschreibt den Scan?
Technische Einordnung: NIST beschreibt Vulnerability Scanning in SP 800-115, Abschnitt 4.3, als Technik zur Identifizierung von Hosts, Hostmerkmalen und zugehörigen bekannten Schwachstellen. Das NIST-CSRC-Glossar fasst den Begriff ebenfalls als Technik zur Erkennung von Hosts, Hostattributen und damit verbundenen Schwachstellen.
Autoritative Empfehlung: CIS ordnet das Scannen in den aktuellen Controls v8.1 in eine aktuelle Asset-Grundlage und ein kontinuierliches Schwachstellenmanagement ein. Das ist eine technische Handlungsempfehlung; aus diesen Quellen folgt keine allgemeine Pflicht oder ein für jede Organisation identisches Verfahren.
Welche Systeme deckt ein Schwachstellenscan ab?
Die Aussage eines Scans ist auf die zuvor festgelegten und technisch erreichbaren beziehungsweise ausdrücklich einbezogenen Assets begrenzt. Je nach Auftrag und Prüflogik können das Hosts, Betriebssysteme, Anwendungen, Dienste, Netzschnittstellen und Konfigurationen sein.
Nicht erfasste, nicht erreichbare oder von den eingesetzten Prüfmodulen nicht abgedeckte Systeme werden nicht beurteilt. Deshalb gibt es keinen universellen Scanbereich, der ohne Anpassung für alle Organisationen gilt.
Welche Voraussetzungen müssen vor dem Scan feststehen?
Ziele, Reichweite, Methode und Autorisierung müssen vor der Durchführung festgelegt sein. Der Prüfauftrag sollte eindeutig bestimmen, welche Systeme und Prüfverfahren freigegeben sind und welche betrieblichen Grenzen einzuhalten sind.
Die Qualität und Aussagekraft hängen insbesondere von der Asset-Sichtbarkeit, den erreichbaren Netzpfaden, der gewählten Reichweite, den verfügbaren Berechtigungen sowie der Aktualität der Prüfdaten und Prüfmodule ab.
Wie unterscheiden sich authentisierte und nicht authentisierte Scans?
Ein nicht authentisierter Scan beurteilt Ziele aus der Perspektive der ohne Anmeldung erreichbaren Schnittstellen. Ein authentisierter Scan kann darüber hinaus lokale Konfigurations-, Software- und Patchinformationen erfassen.
Diese zusätzliche Prüftiefe setzt geeignete und ausdrücklich freigegebene Zugangsdaten, lokal eingesetzte Agenten oder einen entsprechend berechtigten Fernzugriff voraus. Fehlen diese Voraussetzungen oder unterstützt das Zielsystem das Verfahren nicht, ist die Aussagekraft eines authentisierten Scans entsprechend begrenzt.
Wie unterscheidet sich der Scan vom Penetrationstest?
Der Scanner sucht automatisiert nach bekannten, von seiner Prüflogik abgedeckten Schwachstellen und Fehlkonfigurationen. Ein Penetrationstest geht darüber hinaus und untersucht kontrolliert, ob und wie sich eine vermutete Schwäche unter den konkreten Bedingungen tatsächlich ausnutzen lässt.
Scanergebnisse können einen Penetrationstest vorbereiten und fokussieren. Sie ersetzen aber weder den Exploit-Nachweis noch den Penetrationstest oder eine vollständige Risikobewertung.
Wie sind Scanergebnisse zu bewerten?
Positive Treffer müssen fachlich validiert, in ihrem technischen und betrieblichen Kontext bewertet und risikobasiert priorisiert werden. Erst diese Prüfung zeigt, ob ein Befund tatsächlich zutrifft, wie relevant er ist und welche Abhilfe angemessen ist.
Auch ein negatives Ergebnis ist begrenzt: Es beweist keine Schwachstellenfreiheit. Unbekannte Schwachstellen sowie Schwächen außerhalb der Reichweite oder Prüflogik können unentdeckt bleiben.
Welche Fristen und Schwellenwerte gelten?
Für den technischen Begriff bestehen keine universelle Frist, kein allgemeiner Startpunkt und kein numerischer Schwellenwert. Scanintervalle können sich aus der eigenen Risikosteuerung, internen Regeln, Verträgen oder anwendbaren Spezialvorgaben ergeben.
Technische Änderungen und neue Schwachstelleninformationen können eine Wiederholung veranlassen. Daraus folgt jedoch keine für alle Organisationen gleiche Frequenz. Die frühere wöchentliche Empfehlung aus CIS Controls v7.1 ist kein aktueller allgemeiner Maßstab und wird hier nicht übernommen.
Welche Betriebsrisiken hat ein aktiver Scan?
Aktive Prüfungen können abhängig von Verfahren und Umgebung Bandbreite beanspruchen, Reaktionszeiten verschlechtern oder den Betrieb beeinträchtigen. Deshalb benötigen sie einen autorisierten und abgegrenzten Prüfauftrag, der Ziele, zulässige Methoden und betriebliche Grenzen berücksichtigt.
Häufige Fehlannahmen
- „Jeder Treffer ist ausnutzbar.“ Nein. Ein Treffer bezeichnet zunächst eine potenzielle Schwachstelle und muss fachlich validiert werden.
- „Kein Treffer bedeutet Schwachstellenfreiheit.“ Nein. Unbekannte, nicht erreichbare oder von der Prüflogik nicht abgedeckte Schwachstellen können unentdeckt bleiben.
- „Ein Scan ist ein Penetrationstest.“ Nein. Der Scan gleicht Merkmale mit bekanntem Schwachstellenwissen ab; der Penetrationstest untersucht zusätzlich die tatsächliche Ausnutzbarkeit.
- „Ein Scan deckt automatisch die gesamte IT ab.“ Nein. Seine Aussage reicht nur über die festgelegten, erreichbaren und technisch einbezogenen Assets.
- „Ein nicht authentisierter Scan bietet dieselbe Prüftiefe.“ Nein. Lokale Konfigurations- und Patchinformationen setzen geeignete authentisierte Zugriffe oder Agenten voraus.
- „Für jeden Scan gilt dieselbe feste Frequenz.“ Nein. Die ausgewerteten technischen Quellen bestimmen weder eine universelle Frist noch einen allgemeinen Schwellenwert.
Was die Geschäftsleitung tun sollte
Die folgenden Schritte sind technische Handlungsempfehlungen und keine aus den genannten Quellen abgeleitete allgemeine Pflicht:
- einen dokumentierten Schwachstellenmanagementprozess mit eindeutigen Zuständigkeiten veranlassen;
- eine aktuelle Asset-Grundlage schaffen und für jeden Scan Ziele, Reichweite, Methode und Autorisierung festlegen;
- eine dem Risiko angemessene Scanabdeckung und bei Bedarf ausdrücklich freigegebene authentisierte Prüfungen vorsehen;
- Treffer fachlich validieren und nach Risiko sowie Systembedeutung priorisieren lassen;
- Behebungsmaßnahmen mit Verantwortlichen nachverfolgen und ihre Wirksamkeit durch erneute Prüfung verifizieren;
- Intervalle anhand von Risiko, Änderungen, neuen Schwachstelleninformationen und einschlägigen internen, vertraglichen oder speziellen Vorgaben festlegen.
Ein Scan bleibt dabei ein Erkenntnismittel. Er ersetzt weder die Risikobewertung noch die Abhilfe oder deren Verifikation.
Für die Geschäftsleitung
Die Reichweite eines Schwachstellenscans endet an der dokumentierten Zielmenge und der technischen Prüflogik. Die zentrale Entscheidung betrifft daher nicht nur die Beschaffung eines Scanners, sondern einen belastbaren Gesamtprozess aus Asset-Sicht, autorisiertem Prüfauftrag, angemessener Prüftiefe, Validierung, risikobasierter Behebung und Wirksamkeitsprüfung.
Als Nachweis eignen sich insbesondere die dokumentierte Zielmenge und Autorisierung, nachvollziehbare Scanergebnisse, fachliche Validierungs- und Priorisierungsentscheidungen, nachverfolgte Abhilfen sowie Ergebnisse der erneuten Prüfung.
Quellen
- NIST Special Publication 800-115, Technical Guide to Information Security Testing and Assessment, insbesondere Abschnitt 4.3 „Vulnerability Scanning“.
- NIST CSRC Glossary: Vulnerability Scanning.
- CIS Critical Security Controls Version 8.1, insbesondere Controls 1 und 7.
