Schwachstellen-Scans: Was sie leisten und wo ihre Grenzen liegen

Schwachstellen-Scans schaffen Sichtbarkeit

Unternehmen setzen heute eine Vielzahl von Systemen, Anwendungen, Cloud-Diensten und Netzwerkkomponenten ein. Viele davon verändern sich laufend: Updates werden eingespielt, Konfigurationen angepasst, neue Dienste ergänzt oder Benutzerrechte geändert.

Dadurch können Schwachstellen entstehen, ohne dass sie sofort auffallen.

Automatisierte Schwachstellen-Scans helfen dabei, bekannte Sicherheitslücken, unsichere Konfigurationen und veraltete Softwarestände systematisch zu erkennen. Das BSI betont, dass kontinuierliches Schwachstellenmanagement dazu beiträgt, bekannte Sicherheitslücken frühzeitig zu identifizieren, zu bewerten und zu beheben.

Ein Scan ist deshalb ein wichtiges Werkzeug. Er ist aber nur ein Teil eines vollständigen Schwachstellenmanagements.

1. Was ein Schwachstellen-Scan untersucht

Ein Schwachstellen-Scanner prüft technische Systeme automatisiert auf bekannte Auffälligkeiten.

Je nach Werkzeug und Umfang können unter anderem untersucht werden:

• Betriebssysteme,
• Server,
• Netzwerkgeräte,
• Webanwendungen,
• Datenbanken,
• Cloud-Dienste,
• Endgeräte,
• offene Ports,
• aktive Dienste,
• Softwareversionen,
• Zertifikate,
• Verschlüsselungsverfahren,
• Konfigurationen,
• fehlende Sicherheitsupdates.

Webanwendungs-Scanner untersuchen Anwendungen beispielsweise auf bekannte Fehlerklassen wie Cross-Site Scripting, SQL-Injection, unsichere Serverkonfigurationen oder fehlerhafte Zugriffskontrollen. OWASP beschreibt solche Werkzeuge als automatisierte Scanner, die Webanwendungen meist von außen auf erkennbare Schwachstellen prüfen.

Ein Scan kann jedoch nur das erkennen, wonach das jeweilige Werkzeug sucht und was aus seiner Perspektive sichtbar ist.

2. Externe und interne Scans unterscheiden

Schwachstellen-Scans können aus unterschiedlichen Blickwinkeln durchgeführt werden.

Externe Scans

Ein externer Scan betrachtet öffentlich erreichbare Systeme aus Sicht eines potenziellen Angreifers.

Typische Prüfziele sind:

• Webseiten,
• Webserver,
• VPN-Zugänge,
• Remote-Desktop-Dienste,
• E-Mail-Systeme,
• öffentlich erreichbare APIs,
• DNS- und Domain-Konfigurationen,
• TLS-Zertifikate,
• offene Netzwerkports.

Ein solcher Scan zeigt, welche Angriffsfläche nach außen sichtbar ist.

Interne Scans

Ein interner Scan betrachtet Systeme innerhalb des Unternehmensnetzes.

Dabei können beispielsweise geprüft werden:

• Arbeitsplatzrechner,
• interne Server,
• Netzwerkgeräte,
• Drucker,
• Datenbanken,
• interne Anwendungen,
• nicht öffentlich erreichbare Dienste.

Interne Scans sind wichtig, weil viele Schwachstellen von außen nicht sichtbar sind. Sie können dennoch relevant werden, wenn ein Angreifer bereits Zugriff auf das Netzwerk erlangt hat.

Beide Perspektiven ergänzen sich.

3. Authentifizierte und nicht authentifizierte Scans

Ein weiterer wichtiger Unterschied besteht darin, ob der Scanner Zugangsdaten erhält.

Nicht authentifizierter Scan

Der Scanner prüft das System wie ein externer Benutzer ohne besondere Berechtigungen.

Er kann typischerweise erkennen:

• offene Dienste,
• erreichbare Anwendungen,
• sichtbare Softwareversionen,
• bestimmte Fehlkonfigurationen,
• bekannte Schwachstellen öffentlich erreichbarer Komponenten.

Authentifizierter Scan

Der Scanner erhält kontrollierte Zugangsdaten und kann das System detaillierter untersuchen.

Dadurch lassen sich häufig zusätzlich erkennen:

• installierte Software,
• fehlende Updates,
• lokale Konfigurationen,
• unsichere Dienste,
• Berechtigungsprobleme,
• veraltete Bibliotheken,
• Richtlinienabweichungen.

Authentifizierte Scans liefern meist genauere Ergebnisse, benötigen aber eine sorgfältige Vorbereitung. Zugangsdaten müssen geschützt, Berechtigungen begrenzt und die Auswirkungen auf den Betrieb geprüft werden.

4. Typische Ergebnisse richtig verstehen

Ein Schwachstellenbericht enthält häufig eine große Anzahl von Feststellungen.

Dazu gehören beispielsweise:

• kritische Sicherheitslücken,
• veraltete Softwareversionen,
• unsichere Verschlüsselung,
• abgelaufene Zertifikate,
• unnötig offene Ports,
• Standardkonfigurationen,
• fehlende Sicherheitsheader,
• öffentlich zugängliche Administrationsbereiche,
• unsichere Netzwerkdienste,
• schwache Protokolle.

Viele Scanner ordnen Ergebnisse nach Schweregrad ein.

Dabei werden häufig Kriterien wie folgende berücksichtigt:

• technische Ausnutzbarkeit,
• mögliche Auswirkungen,
• erforderliche Zugriffsrechte,
• Verfügbarkeit öffentlicher Exploits,
• Reichweite der Schwachstelle.

Die National Vulnerability Database stellt standardisierte Informationen über bekannte Schwachstellen, betroffene Produkte und technische Bewertungsmerkmale bereit. Diese Daten unterstützen die Automatisierung im Schwachstellenmanagement.

Die technische Bewertung allein reicht jedoch nicht aus.

Eine als „kritisch“ eingestufte Schwachstelle kann in einer isolierten Testumgebung weniger dringlich sein als eine formal niedriger bewertete Fehlkonfiguration in einem geschäftskritischen System.

5. Technische Schwere und tatsächliches Risiko unterscheiden

Ein Scanner kennt den Geschäftskontext meist nicht.

Er weiß beispielsweise nicht:

• ob das System geschäftskritisch ist,
• welche Daten verarbeitet werden,
• ob das System aus dem Internet erreichbar ist,
• welche Schutzmaßnahmen bereits bestehen,
• ob ein Angriff zusätzliche Zugriffsrechte erfordert,
• ob ein Dienst tatsächlich genutzt wird,
• welche betrieblichen Folgen eine Änderung hätte.

Deshalb sollte jede Feststellung fachlich bewertet werden.

Eine belastbare Priorisierung berücksichtigt mindestens:

• technische Kritikalität,
• tatsächliche Erreichbarkeit,
• Bedeutung des betroffenen Systems,
• Art der verarbeiteten Daten,
• vorhandene Schutzmaßnahmen,
• bekannte Ausnutzung,
• mögliche Auswirkungen auf den Betrieb,
• Aufwand und Risiko der Behebung.

Erst aus dieser Kombination entsteht eine sinnvolle Reihenfolge.

6. Fehlalarme und unvollständige Ergebnisse einplanen

Automatisierte Scans sind nicht fehlerfrei.

Sie können:

• eine Schwachstelle melden, die tatsächlich nicht ausnutzbar ist,
• eine Softwareversion falsch erkennen,
• eine kompensierende Maßnahme nicht berücksichtigen,
• eine Schwachstelle übersehen,
• nur einen Teil der Anwendung erfassen,
• individuelle Geschäftslogik nicht verstehen.

Ein gemeldeter Fund sollte deshalb überprüft werden, bevor weitreichende Maßnahmen ausgelöst werden.

Gleichzeitig darf ein unauffälliger Scanbericht nicht als Beweis vollständiger Sicherheit verstanden werden.

Ein Scanner kann nur bekannte Muster und erreichbare Prüfziele untersuchen. Unbekannte Schwachstellen, individuelle Entwicklungsfehler oder organisatorische Risiken bleiben möglicherweise unentdeckt.

7. Schwachstellen-Scan und Penetrationstest unterscheiden

Schwachstellen-Scan und Penetrationstest werden häufig gleichgesetzt. Sie verfolgen jedoch unterschiedliche Ansätze.

Schwachstellen-Scan

Ein Scan ist:

• weitgehend automatisiert,
• wiederholbar,
• vergleichsweise schnell,
• gut für regelmäßige Prüfungen geeignet,
• auf bekannte Schwachstellen und Konfigurationen ausgerichtet.

Penetrationstest

Ein Penetrationstest umfasst zusätzlich eine gezielte manuelle Prüfung aus Sicht eines Angreifers.

Dabei werden beispielsweise:

• Schwachstellen verifiziert,
• Angriffspfade kombiniert,
• Berechtigungen ausgeweitet,
• Geschäftslogik geprüft,
• Sicherheitskontrollen umgangen,
• tatsächliche Auswirkungen bewertet.

OWASP beschreibt Penetrationstests als gezielte Prüfung laufender Anwendungen, bei der Tester wie reale Benutzer oder Angreifer vorgehen.

OWASP weist außerdem darauf hin, dass ein Penetrationstest eine genauere Risikobewertung ermöglichen kann als automatisierte Scans allein, weil Schwachstellen praktisch verifiziert und in einen Angriffszusammenhang gesetzt werden.

Ein Scan ersetzt deshalb keinen Penetrationstest. Umgekehrt ersetzt ein punktueller Penetrationstest auch kein regelmäßiges Schwachstellenmanagement.

8. Den Prüfbereich eindeutig festlegen

Vor einem Scan muss geklärt werden, was geprüft werden darf.

Der sogenannte Scope sollte festhalten:

• IP-Adressen,
• Domains,
• Anwendungen,
• Systeme,
• Standorte,
• Cloud-Umgebungen,
• ausgeschlossene Bereiche,
• Zeitfenster,
• Ansprechpartner,
• technische Einschränkungen.

Unklare Scopes können zu Problemen führen.

Ein Scanner könnte versehentlich:

• fremde Systeme prüfen,
• produktive Dienste belasten,
• Sicherheitsmechanismen auslösen,
• Konten sperren,
• Protokolle mit großen Datenmengen füllen,
• externe Dienstleister beeinträchtigen.

Bei extern betriebenen Systemen sollte vorab geprüft werden, ob der Anbieter Scans erlaubt oder eine Freigabe verlangt.

9. Auswirkungen auf den Betrieb berücksichtigen

Schwachstellen-Scans sind grundsätzlich auf Prüfung und nicht auf Ausnutzung ausgelegt. Dennoch können sie Systeme belasten.

Besonders empfindlich können sein:

• ältere Server,
• Produktionssysteme,
• Steuerungstechnik,
• medizinische Geräte,
• Drucker,
• eingebettete Systeme,
• schlecht gepflegte Netzwerkgeräte,
• individuelle Anwendungen.

Vor einem Scan sollten deshalb folgende Fragen geklärt werden:

• Kann das System produktiv gescannt werden?
• Gibt es ein Wartungsfenster?
• Müssen bestimmte Tests deaktiviert werden?
• Wer überwacht den Betrieb?
• Wie wird bei Störungen reagiert?
• Existiert ein aktuelles Backup?
• Muss der Dienstleister informiert werden?

Bei kritischen Systemen kann zunächst ein vorsichtiger, eingeschränkter Scan sinnvoll sein.

10. Ergebnisse in einen Maßnahmenprozess überführen

Ein Scanbericht hat nur dann einen Sicherheitswert, wenn die Ergebnisse bearbeitet werden.

Für jede relevante Feststellung sollte dokumentiert werden:

• betroffenes System,
• beschriebene Schwachstelle,
• technische Einstufung,
• fachliche Risikobewertung,
• verantwortliche Person,
• geplante Maßnahme,
• Zieltermin,
• Umsetzungsstatus,
• Restrisiko,
• Nachweis der Behebung.

Mögliche Maßnahmen sind:

• Sicherheitsupdate installieren,
• Software aktualisieren,
• Dienst deaktivieren,
• Port schließen,
• Konfiguration härten,
• Berechtigungen reduzieren,
• System segmentieren,
• Zugriff einschränken,
• Produkt ersetzen,
• Risiko vorübergehend akzeptieren.

Entscheidungen zur Risikoakzeptanz sollten begründet, freigegeben und zeitlich überprüfbar sein.

11. Behebung anschließend verifizieren

Eine als erledigt markierte Maßnahme ist nicht automatisch wirksam.

Nach der Behebung sollte geprüft werden:

• Ist die Schwachstelle tatsächlich geschlossen?
• Wurde die Änderung auf allen betroffenen Systemen umgesetzt?
• Sind neue Probleme entstanden?
• Ist das System weiterhin funktionsfähig?
• Besteht ein Restrisiko?
• Ist der Nachweis dokumentiert?

Dazu eignet sich häufig ein erneuter Scan.

Dieser sogenannte Re-Scan zeigt, ob der ursprüngliche Fund weiterhin erkannt wird.

Bei komplexeren oder besonders kritischen Schwachstellen kann zusätzlich eine manuelle Prüfung erforderlich sein.

12. Scans regelmäßig wiederholen

Ein einmaliger Scan bildet nur einen bestimmten Zeitpunkt ab.

Schon kurz danach können neue Risiken entstehen durch:

• neue Schwachstellen,
• Softwareupdates,
• geänderte Konfigurationen,
• zusätzliche Systeme,
• neue Benutzer,
• neue Cloud-Dienste,
• veränderte Freigaben,
• organisatorische Änderungen.

Schwachstellen-Scans sollten deshalb regelmäßig wiederholt werden.

Die Häufigkeit hängt unter anderem ab von:

• Kritikalität der Systeme,
• Internet-Erreichbarkeit,
• Änderungsfrequenz,
• regulatorischen Anforderungen,
• Kundenanforderungen,
• Sicherheitslage,
• verfügbaren Ressourcen.

Typische Intervalle können sein:

• monatlich,
• quartalsweise,
• nach wesentlichen Änderungen,
• nach Sicherheitsvorfällen,
• vor Audits,
• nach größeren Updates.

Besonders exponierte Systeme sollten häufiger geprüft werden als interne Systeme mit geringem Risiko.

13. Schwachstellenmanagement und Patchmanagement verbinden

Schwachstellenmanagement und Patchmanagement gehören eng zusammen.

Ein Scan erkennt Probleme. Das Patchmanagement sorgt dafür, dass verfügbare Sicherheitsupdates kontrolliert umgesetzt werden.

Ein funktionierender Prozess sollte enthalten:

1. Schwachstelle erfassen
2. Betroffenheit prüfen
3. Risiko bewerten
4. Maßnahme auswählen
5. Änderung testen
6. Update einspielen
7. Funktion kontrollieren
8. Behebung verifizieren
9. Vorgang dokumentieren

NIST beschreibt Patch- und Schwachstellenmanagement als geregeltes Programm, mit dem Sicherheitsupdates und andere Gegenmaßnahmen geplant, umgesetzt und auf ihre Wirksamkeit geprüft werden.

Ohne einen solchen Prozess wächst die Zahl offener Feststellungen von Scan zu Scan.

14. Ausnahmen und nicht patchbare Systeme behandeln

Nicht jede Schwachstelle lässt sich sofort durch ein Update beheben.

Gründe können sein:

• kein Patch verfügbar,
• Software wird nicht mehr unterstützt,
• Update verursacht Kompatibilitätsprobleme,
• Produktionssystem darf nicht kurzfristig verändert werden,
• Herstellerfreigabe fehlt,
• System muss erst ersetzt werden.

In solchen Fällen sind kompensierende Maßnahmen erforderlich.

Beispiele sind:

• Netzwerksegmentierung,
• Einschränkung der Erreichbarkeit,
• zusätzliche Authentifizierung,
• Deaktivierung gefährdeter Funktionen,
• verstärkte Protokollierung,
• Anwendungskontrolle,
• zeitlich begrenzte Ausnahme,
• Ersatzplanung.

Die Ausnahme sollte dokumentiert und regelmäßig überprüft werden.

Ein dauerhaft ungepatchtes System ohne zusätzliche Schutzmaßnahmen stellt ein erhebliches Risiko dar.

15. Cloud-Dienste und externe Anbieter einbeziehen

Auch Cloud-Umgebungen benötigen Schwachstellenmanagement.

Dabei ist zu unterscheiden, wer für welche Ebene verantwortlich ist.

Je nach Betriebsmodell kann der Anbieter verantwortlich sein für:

• physische Infrastruktur,
• Plattform,
• Basisbetrieb,
• bestimmte Updates.

Das Unternehmen bleibt häufig verantwortlich für:

• Benutzerkonten,
• Berechtigungen,
• Konfigurationen,
• eigene Anwendungen,
• virtuelle Systeme,
• Daten,
• Schnittstellen,
• externe Freigaben.

Bei externen Anbietern sollte geklärt werden:

• Welche Prüfberichte liegen vor?
• Welche Sicherheitsupdates werden umgesetzt?
• Wie werden Schwachstellen gemeldet?
• Welche eigenen Scans sind erlaubt?
• Welche Fristen gelten für kritische Lücken?
• Welche Nachweise können angefordert werden?

Eine Zertifizierung des Anbieters ersetzt nicht automatisch die Bewertung der eigenen Konfiguration.

16. Webseiten und Webanwendungen gezielt prüfen

Webseiten und Webanwendungen besitzen eine eigene Angriffsfläche.

Typische Risiken sind:

• veraltete CMS-Versionen,
• unsichere Plugins,
• fehlerhafte Berechtigungen,
• unsichere Formulare,
• fehlende Sicherheitsheader,
• öffentlich erreichbare Administrationsbereiche,
• unsichere Dateiuploads,
• Schwächen in Authentifizierung und Sitzungsverwaltung,
• Fehlkonfiguration des Webservers.

Automatisierte Webscanner können viele technische Auffälligkeiten erkennen. Individuelle Geschäftslogik, komplexe Berechtigungskonzepte und mehrstufige Abläufe benötigen jedoch häufig eine manuelle Prüfung.

Bei produktiven Webseiten sollte der Scan so konfiguriert werden, dass keine unerwünschten Daten, Benutzerkonten oder Bestellungen erzeugt werden.

17. Kennzahlen sinnvoll nutzen

Kennzahlen können helfen, die Entwicklung des Schwachstellenmanagements zu steuern.

Geeignete Kennzahlen sind beispielsweise:

• Anzahl offener kritischer Schwachstellen,
• durchschnittliche Behebungszeit,
• Anteil überfälliger Maßnahmen,
• Zahl wiederkehrender Feststellungen,
• Abdeckung der gescannten Systeme,
• Zahl nicht unterstützter Systeme,
• Anteil erfolgreich verifizierter Behebungen.

Kennzahlen sollten Entscheidungen unterstützen.

Eine hohe Zahl gefundener Schwachstellen bedeutet nicht zwingend, dass sich die Sicherheit verschlechtert hat. Sie kann auch zeigen, dass erstmals umfassender geprüft wurde.

Wichtig ist die Entwicklung über einen längeren Zeitraum.

Schwachstellen-Scans sind ein Frühwarnsystem

Ein Scan liefert keine Garantie, dass ein System sicher ist.

Er schafft jedoch Sichtbarkeit über bekannte technische Risiken und unterstützt Unternehmen dabei, Maßnahmen nachvollziehbar zu priorisieren.

Ein wirksamer Prozess verbindet:

regelmäßige Scans
→ fachliche Bewertung
→ priorisierte Maßnahmen
→ kontrollierte Behebung
→ erneute Prüfung

Erst durch diesen Kreislauf wird aus einem technischen Bericht ein dauerhaftes Schwachstellenmanagement.

Kennen Sie die öffentlich sichtbaren Schwachstellen Ihrer Systeme?

ProtectYourIT prüft externe Systeme, Webseiten und ausgewählte technische Konfigurationen, bewertet die Ergebnisse fachlich und zeigt verständlich auf, welche Maßnahmen tatsächlich Priorität haben.

Schwachstellen prüfen lassen –>/kontakt/

Hinweis: Dieser Beitrag dient der allgemeinen Orientierung. Schwachstellen-Scans sollten nur mit klarer Berechtigung, definiertem Prüfbereich und unter Berücksichtigung möglicher Auswirkungen auf den Betrieb durchgeführt werden.