Was ist eine Schwachstellenanalyse? Durchführung, bewährte Verfahren und Beispiele

Wichtigste Erkenntnisse

• Eine Schwachstellenanalyse identifiziert, klassifiziert und priorisiert systematisch Sicherheitslücken in Ihren Netzwerken, auf Ihren Hosts, in Ihren Anwendungen und bei Ihren Cloud-Workloads – noch bevor Angreifer sie entdecken.
• Im Gegensatz zu einem Penetrationstest werden dabei keine Schwachstellen ausgenutzt; stattdessen wird Ihr Risikoprofil erfasst, damit Sie wissen, welche Probleme Sie in welcher Reihenfolge beheben müssen.
• Der Kernprozess: Erfassen Sie Ihre Ressourcen, scannen Sie diese mit den richtigen Tools, sortieren Sie sie nach ihrer tatsächlichen Ausnutzbarkeit (nicht nur nach dem CVSS-Wert) und installieren Sie kontinuierlich Patches.
• Die meisten Programme scheitern nicht wegen schlechter Instrumente, sondern weil sie die Leistungsbeurteilung als vierteljährliches Ereignis und nicht als fortlaufenden Prozess betrachten.

Ein durchschnittliches Unternehmen hat zu jedem Zeitpunkt Tausende bekannter Sicherheitslücken – und die Lücke zwischen der Entdeckung und der Behebung wird immer größer, statt kleiner. Der „Verizon Data Breach Investigations Report 2026“ ergab, dass die Ausnutzung von Schwachstellen mittlerweile der häufigste Erstzugangsweg ist und bei 31 % der Sicherheitsvorfälle eine Rolle spielt – ein Anstieg gegenüber 20 % im Vorjahr. Die meisten Teams erfahren erst auf die harte Tour von ihrer Anfälligkeit: nachdem ein Auditor, ein Sicherheitsfragebogen eines Kunden oder ein tatsächlicher Vorfall sie dazu zwingt, sich damit auseinanderzusetzen.

Bei einer Schwachstellenanalyse geht es darum, Probleme zu erkennen, bevor es jemand anderes tut. Wenn sie richtig durchgeführt wird, zeigt sie auf, wo Fehler vorliegen, wie gravierend diese sind und was zuerst behoben werden sollte. Wird sie falsch durchgeführt – und das ist oft der Fall –, entsteht ein 400-seitiges PDF, das niemand liest.

Was ist eine Schwachstellenanalyse?

Eine Schwachstellenanalyse ist ein systematischer Prozess zur Identifizierung, Klassifizierung und Priorisierung von Sicherheitslücken in Ihrer gesamten IT-Umgebung und Ihren Informationssystemen. Das Ergebnis ist eine nach Schweregrad geordnete Liste von Problemen – CVEs, Fehlkonfigurationen, schwache Anmeldedaten, exponierte Dienste –, die den betroffenen Systemkomponenten und den damit verbundenen Risiken zugeordnet sind.

Es ist beschreibend, nicht konfrontativ. Bei einem Sicherheitsaudit wird möglicherweise geprüft, ob Ihre Kontrollmaßnahmen einem Referenzrahmen entsprechen. Eine Zero-Trust-Prüfung hinterfragt Ihr Zugriffsmodell. Eine Schwachstellenanalyse beantwortet eine enger gefasste Frage: Wo befinden sich derzeit die Lücken – seien es unsichere Standardeinstellungen, leicht zu erratende Administratorpasswörter, fehlende Patches oder schwache Authentifizierungsmechanismen, die noch niemand verschärft hat.

So funktioniert die Schwachstellenanalyse

Die Funktionsweise ist einfacher, als es die Marketingbotschaften vermuten lassen. Die meisten Bewertungen folgen diesem Ablauf:

• Bestandserfassung: Ermitteln Sie, was sich tatsächlich in Ihrem Netzwerk befindet, einschließlich der Dinge, die niemand dokumentiert hat.
• Scannen: Führen Sie authentifizierte und nicht authentifizierte Scans dieser Ressourcen durch, um bekannte Probleme zu erkennen.
• Korrelation: Ergebnisse mit Schwachstellendatenbanken (NVD, Herstellerhinweise, KEV) abgleichen, um Schweregrad und Kontext zu ermitteln.
• Berichterstellung: Erstellen Sie etwas, worauf ein Mensch reagieren kann, nicht nur eine CSV-Datei mit 12.000 Zeilen.
• Übergabe der Fehlerbehebung: Leiten Sie die Ergebnisse an das Team weiter, das die Fehler tatsächlich beheben wird – mit ausreichend Kontext, damit es nicht erst selbst herausfinden muss, was der Scanner gemeint hat.

Verschiedene Arten von Schwachstellenanalysen

Die verschiedenen Schichten Ihres Stacks erfordern unterschiedliche Betrachtungsweisen. Einen Netzwerkscan durchzuführen und Ihre Anwendung daraufhin als sicher zu bezeichnen, ist ein Kategorienfehler. Die meisten ausgereiften Programme kombinieren mehrere dieser Aspekte:

• Netzwerkbasierte Überprüfungen: Scannen von IP-Bereichen auf exponierte Dienste, falsch konfigurierte Firewalls, schwache SSL/TLS-Verschlüsselung und nicht authentifizierte Dienste. Der klassische externe Scan.
• Hostbasierte Überprüfungen: authentifizierte Scans von Servern und Arbeitsstationen, um fehlende Patches, unsichere Konfigurationen und risikobehaftete lokale Software zu erkennen. Deckt Probleme auf, die bei Netzwerkscans übersehen werden.
• Anwendungsprüfungen: SAST, DAST und SCA für Ihre Codebasen, um Probleme wie SQL-Injection (SQLi), XSS und unsichere Abhängigkeiten zu erkennen, bevor sie in die Produktion gelangen. Moderne Projekte beziehen Dutzende bis Hunderte von transitiven Abhängigkeiten ein – also die Abhängigkeiten Ihrer Abhängigkeiten –, wodurch Schwachstellen in der Lieferkette einen wesentlichen Teil der Angriffsfläche der Anwendung ausmachen.
• Datenbanküberprüfungen: Überprüfung auf Standardkonten, schwache Verschlüsselung, übermäßige Berechtigungen und nicht gepatchte Datenbankversionen.
• Cloud-Bewertungen: Bewerten Sie IAM-Richtlinien, exponierte Speicher-Buckets, Container-Images und Laufzeitkonfigurationen in AWS, GCP und Azure.
• WLAN-Analysen: Erkennen Sie unberechtigte Zugangspunkte, schwache Protokolle und falsch konfigurierte Gastnetzwerke.

Profi-Tipp: Authentifizierte Scans decken um ein Vielfaches mehr Probleme auf als nicht authentifizierte, sind jedoch schwieriger einzurichten und aus politischer Sicht lästig durchzuführen. Wenn Sie nur das Budget für eine Art von Host-Scan haben, entscheiden Sie sich für einen authentifizierten Scan. Nicht authentifizierte Scans zeigen Ihnen, was ein Außenstehender sieht; authentifizierte Scans zeigen Ihnen, was ein Angreifer sieht, nachdem er sich einen ersten Zugang verschafft hat.

Vor- und Nachteile der Schwachstellenanalyse

Eine Schwachstellenanalyse gehört zu den Sicherheitsmaßnahmen mit dem höchsten ROI, die Sie durchführen können, ist jedoch kein Allheilmittel. Wenn Sie von vornherein wissen, was sie leistet und was nicht, ersparen Sie sich später viel Enttäuschung.

So führen Sie eine Schwachstellenanalyse durch: 4 Schritte, auf die es wirklich ankommt

Die meisten veröffentlichten Schrittlisten sind überladen. Im Kern lässt sich die Arbeit in vier Phasen unterteilen. Jede einzelne scheitert auf vorhersehbare Weise, und wenn man eine davon überspringt, führen Programme letztendlich zu Berichten, auf die niemand reagiert.

Schritt 1: Umfang festlegen und Bestandsaufnahme der Vermögenswerte erstellen

Man kann nicht bewerten, was man nicht sieht. Bevor Sie einen Scanner auf irgendetwas richten, benötigen Sie eine aktuelle Bestandsaufnahme der Hosts, Dienste, Anwendungen und Cloud-Ressourcen – sowie eine klare Abgrenzung dessen, was dazu gehört und was nicht. Das klingt langweilig. Es ist jedoch der wichtigste Faktor dafür, ob der Rest der Bewertung überhaupt sinnvoll ist.

Ein 40-köpfiges SaaS-Team, das auf AWS arbeitet, entdeckt bei seiner ersten umfassenden Bestandsaufnahme in der Regel 20–30 % mehr Ressourcen als erwartet: vergessene Staging-Umgebungen, Laptops von Auftragnehmern, die noch im Verzeichnis aufgeführt sind, eine alte EC2-Instanz, die jemand im Jahr 2021 eingerichtet und nie außer Betrieb genommen hat. Bei der Schatten-IT – Cloud-Konten, SaaS-Tools und Entwicklungsumgebungen, die außerhalb des Sichtfelds der IT-Abteilung eingerichtet wurden – ist die Lücke in der Regel am größten.

Legen Sie den Umfang schriftlich fest. Geben Sie IP-Bereiche, Domänen, Konten und Ausschlüsse an. Vermerken Sie alle Systeme, bei denen authentifizierte Scans nicht zulässig sind, und geben Sie die Gründe dafür an. Wenn Sie diesen Schritt überspringen, werden Sie wochenlang Scans wiederholen müssen, weil niemand dem Sicherheitsteam mitgeteilt hat, dass sich der Entwickler-Cluster in einer anderen VPC befindet.

Schritt 2: Scannen Sie mit den richtigen Tools und den richtigen Anmeldedaten

Wählen Sie einen für die zu prüfende Ebene – Netzwerk, Host, Anwendung, Cloud – geeigneten Scanner aus und führen Sie ihn mit den entsprechenden Anmeldedaten aus. Bei hostbasierten Prüfungen bedeutet dies einen SSH- oder WinRM-Zugriff mit ausreichenden Berechtigungen, um Paketversionen und Konfigurationsdateien lesen zu können.

Der Zeitplan ist wichtiger als die Wahl des Tools. Ein Scanner, der wöchentlich mit dem richtigen Umfang ausgeführt wird, ist leistungsfähiger als ein „branchenführender“ Scanner, der nur einmal pro Quartal läuft. Speziell bei Linux-Systemen sollten Sie die Überprüfung anhand von Herstellerhinweisen und Schwachstellendatenbanken durchführen und nicht anhand von reinen NVD-Einträgen – Red Hat, Canonical und SUSE portieren Korrekturen rückwärts, ohne die Versionsnummern zu ändern, sodass eine generische CVE-Prüfung auf gepatchten Systemen eine Flut von Fehlalarmen erzeugt.

Achtung: Authentifizierte Scans von Produktionsdatenbanken oder Finanzsystemen können IDS-Warnmeldungen auslösen, Dienstkonten sperren oder Hunderte von Audit-Log-Ereignissen pro Host generieren. Stimmen Sie sich mit den für diese Systeme zuständigen Teams ab, legen Sie Zeitfenster fest und verwenden Sie ein dediziertes Dienstkonto mit Lesezugriffsrechten. Ein Scanner, der Ihr Dienstkonto um 3 Uhr morgens sperrt, ist ein Scanner, dessen Ausführung Sie unterbinden sollten.

Schritt 3: Triage und Priorisierung – nicht nur anhand des CVSS

Die Rohdaten des Scanners sind unsortiertes Rauschen. Im Triage-Schritt wandeln Sicherheitsanalysten die Daten aus der Schwachstellenanalyse in tatsächlich nutzbare Informationen um – und genau hier scheitern die meisten Programme an der Datenflut. Der CISA-Katalog „Known Exploited Vulnerabilities“ (KEV) listet die CVEs auf, die Angreifer derzeit aktiv ausnutzen. Dies ist nur ein kleiner Bruchteil aller veröffentlichten CVEs, und diese Liste sollte unabhängig vom CVSS-Wert als Erstes mit Patches versorgt werden.

Ein praktischer Triage-Stapel:

1. Beginnen Sie mit den in der KEV-Liste aufgeführten CVEs auf Systemen mit Internetanbindung. Das sind die dringlichsten Probleme.
2. Fügen Sie CVEs mit dem Schweregrad „kritisch“ (CVSS 9.0+) für Ressourcen hinzu, die sensible Daten verarbeiten oder Teil des Authentifizierungspfads sind.
3. EPSS-Werte einbeziehen, um die Ausbeutungswahrscheinlichkeit in der Praxis abzuschätzen.
4. Probleme bei der Herabstufung von isolierten, nicht routbaren oder durch Ausgleichssteuerung geschützten Anlagen.

Auch hier zahlen sich gute Tools aus. TuxCare Radar beispielsweise berücksichtigt gleichzeitig Daten zur Ausnutzbarkeit, CVSS-Werte und den Status bestätigter Patches – sodass Ihr Team nicht nur auf einen rohen CVSS-Wert starrt und raten muss, was dringend ist.

Schritt 4: Beheben, Überprüfen und erneut scannen – kontinuierlich

Befundungen ohne Abhilfemaßnahmen sind reine Show – und die Zahlen belegen dies. Der „2026 Open Source Landscape Report“ von TuxCare ergab, dass 61,4 % der Cybersicherheitsvorfälle auftraten, obwohl bereits ein Patch verfügbar war, und dass 92,6 % der betroffenen Unternehmen bereits im Vorfeld wussten, dass sie anfällig waren. Das Problem liegt nicht in der Erkennung. Es geht darum, die Lücke zwischen dem Wissen und der Behebung zu schließen.

Schaffen Sie einen kontinuierlichen Kreislauf. Tägliche oder wöchentliche Überprüfungen, bei denen neue Befunde direkt in dasselbe Ticket-System einfließen, das auch für die Behebung von Fehlern zuständig ist, sind in jeder Hinsicht besser als vierteljährliche Bewertungen.

Das größte Einzelhindernis sind weder die Tools noch das Budget – 43 % der Unternehmen geben an, dass die Unmöglichkeit, kritische Systeme offline zu nehmen, ihr größtes Hindernis bei der Patch-Installation darstellt. Genau aus diesem Grund gibt es Live-Patching-Tools wie KernelCare: Kernel-CVEs werden behoben, ohne dass ein Neustartfenster eingeplant werden muss. Für Teams, die Linux-Distributionen am Ende ihres Lebenszyklus einsetzen, für die keine Upstream-Patches mehr bereitgestellt werden, schließt der „Endless Lifecycle Support“ (ELS) von TuxCare diese Lücke, ohne eine sofortige Migration zu erzwingen.

Was gehört in einen Bericht zur Schwachstellenanalyse?

Ein Scan, der mit einem CSV-Export endet, den niemand öffnet, ist keine abgeschlossene Schwachstellenanalyse – sondern lediglich ein abgeschlossener Scan. Erst der Bericht verwandelt die Ergebnisse in Entscheidungen. Ein guter Bericht zur Schwachstellenanalyse sollte mindestens folgende Elemente enthalten:

• Name der Sicherheitslücke und CVE-ID: damit jeder, der dies liest, die Informationen selbstständig nachschlagen kann
• Betroffene Ressource: Hostname, IP-Adresse, Dienst oder Anwendung
• CVSS-Wert: die grundlegende Schweregradbewertung des NVD
• Kontext der Ausnutzbarkeit: Steht die Schwachstelle auf der CISA-KEV-Liste? Wie hoch ist der EPSS-Wert? Gibt es öffentlich zugänglichen Exploit-Code?
• Patch-Status: gepatcht, ungepatcht, gemindert oder akzeptiertes Risiko
• Empfohlene Maßnahme: Patch, Konfigurationsänderung, Ausgleichsregelung oder dokumentierte Ausnahme
• Eigentümer und Frist: die beiden Felder, die in den meisten Berichten leer gelassen werden – und genau deshalb werden die Ergebnisse nicht abgeschlossen

In der Praxis benötigt der Bericht zwei Versionen: eine technische für die Ingenieure, die die Arbeit ausführen, und eine Zusammenfassung für die Führungskräfte, in der Schwachstellen nicht anhand von CVSS-Werten, sondern in Bezug auf Geschäftsrisiken dargestellt werden. Ein CVSS-Wert von 9,8 für ein internes System ohne externe Anbindung erfordert eine andere Formulierung als ein CVSS-Wert von 7,5 für Ihren öffentlichen Authentifizierungsdienst.

Häufige Herausforderungen und wie man sie bewältigt

Die Arbeit wird selten durch den Scanner behindert. Meistens sind es Störfaktoren, Koordinationslücken und architektonische Komplexität, die echte Programme zum Scheitern bringen.

Falsch-positive Ergebnisse (und Falsch-negative Ergebnisse)

Scanner melden Dinge, die nicht echt sind, und übersehen Dinge, die es tatsächlich sind. Fehlalarme untergraben mit der Zeit das Vertrauen in das Programm – sobald ein übermüdeter Entwickler beginnt, die Warnmeldungen des Scanners zu ignorieren, verliert das ganze Vorhaben an Wert. Falsch-negative Ergebnisse sind noch schlimmer: Sie lassen echte Sicherheitslücken unentdeckt.

Die Lösung liegt in der Kalibrierung, nicht in einem besseren Scanner:

• Passen Sie die Scan-Profile je nach Anlageklasse an. Ein Webserver und ein Datenbankserver erfordern unterschiedliche Prüfungen.
• Verwenden Sie nach Möglichkeit authentifizierte Scans, um Versionsdaten zu bestätigen, anstatt diese aus Service-Bannern abzuleiten.
• Vergleichen Sie die Ergebnisse eher mit Herstellerhinweisen als mit rohen CVE-Daten, insbesondere bei Linux-Distributionen für Unternehmen, die Korrekturen rückportieren. Dies ist eine überraschend häufige Ursache für Fehlalarme, die wertvolle Entwicklungszeit verschwendet.
• Führen Sie eine Ausblendungsliste für bekannte Fehlalarme, die mit Ablaufdaten versehen ist, damit die Ausblendungen nicht unbemerkt länger bestehen bleiben als die zugrunde liegende Tatsache.

TuxCare Radar wurde speziell zur Lösung dieses Problems entwickelt. Es erkennt den Unterschied zwischen einer CVE, für die tatsächlich noch kein Patch verfügbar ist, und einer, die im Speicher über einen Live-Kernel-Patch behoben wurde – etwas, das generische Scanner regelmäßig übersehen und dadurch Warnmeldungen für Schwachstellen ausgeben, die Ihr Team bereits behoben hat.

Über neue Sicherheitslücken auf dem Laufenden bleiben

Das NIST veröffentlicht jeden Monat Tausende neuer CVEs, und die Zahl steigt weiter an. Kein Mensch kann da mithalten, indem er die Sicherheitshinweise manuell durchliest. Die praktische Lösung:

• Abonnieren Sie die Mailinglisten der Anbieter und die CISA-KEV-Updates und leiten Sie diese in dasselbe Ticket-System weiter wie die Scan-Ergebnisse.
• Integrieren Sie Threat-Intelligence-Feeds automatisch in Ihren Scanner, damit neue Signaturen bereits innerhalb weniger Tage – und nicht erst nach Wochen – bei den Scans berücksichtigt werden.
• Verfolgen Sie Sicherheitslücken bei der Authentifizierung separat – Fehler im Authentifizierungsbereich werden nach ihrer Offenlegung in der Regel am schnellsten ausgenutzt.

Sie können auch den CVE-Tracker von TuxCare nutzen, um den Status von Sicherheitslücken und deren Behebung bei unterstützten Linux-Distributionen und Open-Source-Produkten, deren Support ausgelaufen ist, zu überwachen.

Scannen komplexer hybrider Umgebungen

Ein Scanner, der für ein flaches On-Premise-Netzwerk entwickelt wurde, versagt in dem Moment, in dem Sie VPC-Peering, Kubernetes, kurzlebige Container und die SaaS-Umgebung eines Partners hinzufügen. Hybrid-Scanning ist eine eigenständige Disziplin:

• Verwenden Sie Scanner-Agenten auf langlebigen Hosts und Registry-/Image-Scans für kurzlebige Container.
• Integrieren Sie Cloud-native APIs (AWS Inspector, Azure Defender, GCP Security Command Center), anstatt zu versuchen, Cloud-Workloads von einer einzigen lokalen Appliance aus zu scannen.
• Versehen Sie Assets in allen Umgebungen einheitlich mit Tags, damit die Ergebnisse nach Anwendung und Verantwortlichem zugeordnet werden können.
• Man muss akzeptieren, dass bestimmte Ressourcen – wie serverlose Funktionen und Managed Services – ein anderes Schwachstellenmodell aufweisen und eine völlig andere Bewertungsstrategie erfordern.

Das Ziel besteht nicht darin, jede CVE zu erfassen – vielmehr soll sichergestellt werden, dass diejenigen, die aktiv ausgenutzt werden, niemals länger als ein paar Tage unbehandelt bleiben.

Schwachstellenanalyse vs. Penetrationstests

In Ausschreibungen werden diese Begriffe ständig miteinander verwechselt. Es handelt sich jedoch nicht um dieselbe Tätigkeit, und das eine ersetzt das andere nicht.

Einfach ausgedrückt: Bei einer Schwachstellenanalyse wird alles oberflächlich überprüft; bei einem Penetrationstest werden einige wenige Ziele eingehend angegriffen. Schwachstellenanalysen decken bekannte CVEs auf; Penetrationstester finden Angriffsketten, Logikfehler und gelegentlich Zero-Day-Schwachstellen. Führen Sie Schwachstellenanalysen kontinuierlich als Basismaßnahme durch. Führen Sie jährlich, vor größeren Produkteinführungen oder bei wesentlichen Änderungen des Anwendungsbereichs einen Penetrationstest durch.

Tools und Software zur Schwachstellenanalyse

Der Markt für entsprechende Tools ist überfüllt und reicht von speziellen Schwachstellenscannern über Tools zum Angriffsflächenmanagement bis hin zu cloud-nativen Scan-Diensten. Die richtige Wahl hängt von Ihrem Technologie-Stack ab. Bei Linux-dominierten Systemlandschaften, cloud-nativen Umgebungen und Windows-dominierten Unternehmen liegen die jeweiligen Vorteile jeweils an anderer Stelle.

TuxCare Radar

Radar ist der auf Linux spezialisierte Schwachstellenscanner von TuxCare und wurde speziell für ein Problem entwickelt, mit dem die meisten allgemeinen Scanner nur schlecht zurechtkommen: Enterprise-Linux-Distributionen portieren Sicherheitspatches zurück, ohne die Versionsnummern zu erhöhen. Allgemeine CVE-Prüfungen erkennen eine „alte“ Versionsangabe und melden eine Schwachstelle, die bereits vor Wochen behoben wurde.

Radar gleicht die Ergebnisse mit den aktuellen Daten aus den Sicherheitshinweisen der Hersteller ab. Außerdem erkennt es Live-Patches (ohne Neustart) – wenn KernelCare also bereits einen In-Memory-Kernel-Patch angewendet hat, weiß Radar, dass die CVE geschlossen ist, und meldet sie nicht als offen. Das ist kein nebensächliches Detail: Es ist der Unterschied zwischen einem Scanner, der Ihnen Ihre tatsächliche Sicherheitslücke aufzeigt, und einem, der Störsignale erzeugt, die Ihr Team irgendwann zu ignorieren lernt.

Weitere wissenswerte Informationen zu Radar: KI-gestützte Risikobewertung, kein dauerhaft installierter Agent sowie native Integrationen mit Qualys, Nessus und OpenSCAP für Teams, die bereits über eine Scan-Plattform verfügen und lediglich präzise Linux-Daten einbinden möchten.

Möchten Sie sehen, wie Radar in der Praxis funktioniert?

Tenable Nessus

Ein seit Langem etablierter Allzweckscanner mit umfassender Plugin-Unterstützung für verschiedene Betriebssysteme, Netzwerkgeräte und Cloud-Ressourcen. Gut geeignet für Unternehmen, die einen „One-Tool-fits-most“-Ansatz verfolgen und über das entsprechende Lizenzbudget verfügen. Weniger spezialisiert auf die Feinheiten des Linux-Backportings, die auf gepatchten Unternehmenssystemen zu Fehlalarmen führen können.

Qualys VMDR

Cloud-basiertes Schwachstellenmanagement mit umfassender Abdeckung der IT-Ressourcen, Optionen mit und ohne Agenten sowie enger Integration in die umfassendere Compliance-Suite von Qualys. Geeignet für Unternehmen, die für Schwachstellen-, Konfigurations- und Compliance-Scans einen einzigen Anbieter nutzen möchten. Die Preise richten sich nach der Anzahl der IT-Ressourcen, was in Cloud-nativen Umgebungen schnell teuer werden kann.

OpenSCAP

Ein Open-Source-Framework für die automatisierte Überprüfung der Compliance und das Scannen nach Schwachstellen, das auf den SCAP-Standards (Security Content Automation Protocol) basiert. Es wird häufig in Behörden, regulierten Branchen und Umgebungen mit hohem Linux-Anteil eingesetzt, in denen die Einhaltung der NIST- und CIS-Benchmarks vorgeschrieben ist. Um aussagekräftige Ergebnisse zu erhalten, sind zwar umfangreichere Kenntnisse in den Bereichen Konfiguration und Skripterstellung erforderlich, doch das Tool ist kostenlos, überprüfbar und lässt sich gut in bestehende Linux-Automatisierungspipelines integrieren.

Bewährte Praktiken der Schwachstellenbewertung

Der Unterschied zwischen einem Programm, das funktioniert, und einem, das nur als „Regalware“ endet, liegt selten am Scanner. Es kommt vielmehr auf eine Handvoll Arbeitsgewohnheiten an.

Anpassen der Scanprofile

Standard-Scan-Profile sind ein Ausgangspunkt, kein Endziel. Ein Profil, das für einen Webserver sicher ist, überlastet eine Datenbank; ein für Windows-Endgeräte optimiertes Profil übersieht Probleme auf einer Linux-Umgebung. Erstellen Sie Profile für jede Asset-Klasse, dokumentieren Sie diese und überprüfen Sie sie vierteljährlich. Distro-spezifische Tools – also solche, die verstehen, wie Red Hat oder Ubuntu Backports handhaben – liefern deutlich sauberere Ergebnisse als ein generischer Scanner, der mit Standardeinstellungen läuft.

Zusammenarbeit mit funktionsübergreifenden Teams

Die Schwachstellenanalyse befindet sich an der Schnittstelle zwischen Sicherheits-, Infrastruktur- und Anwendungsteams. Ergebnisse ohne Verantwortliche führen zu nichts. Richten Sie einen Workflow ein, bei dem die Sicherheitsabteilung den Umfang festlegt und die Ergebnisse priorisiert, die Infrastrukturabteilung für die Behebung von Problemen im Betriebssystem und im Netzwerk zuständig ist, die Anwendungsteams für die Behebung von Fehlern im Code und bei den Abhängigkeiten verantwortlich sind und die Compliance-Abteilung die benötigten Berichte erhält, ohne dass die Sicherheitsteams diese manuell aufbereiten müssen.

Halten Sie Ihr Anlagenverzeichnis auf dem neuesten Stand

Veraltete Bestandsdaten sind der stille Killer. Ein Scanner, der davon ausgeht, dass Sie 400 Hosts haben, obwohl es tatsächlich 530 sind, wird Feststellungen zu 130 Systemen übersehen und Sie niemals darüber informieren. Binden Sie die Bestandserfassung in die Bereitstellung ein – jede neue VM, jedes neue Container-Image und jedes neue Cloud-Konto sollte automatisch in den Bestand aufgenommen werden. Kombinieren Sie dies mit regelmäßigen Konfigurationsprüfungen, um Abweichungen zwischen dem, was bereitgestellt wurde, und dem, was tatsächlich läuft, zu erkennen.

Das Scannen automatisieren, aber einen Menschen in den Triage-Prozess einbeziehen

Die Automatisierung übernimmt das Volumen. Der Mensch übernimmt die Beurteilung. Scans sollten automatisch geplant und die Ergebnisse automatisch in ein Ticket-System übernommen werden, doch kritische oder in der KEV-Liste aufgeführte Fälle müssen weiterhin von einem Menschen überprüft werden. Reine Automatisierung ohne Überwachung führt zu Alarmmüdigkeit; eine rein manuelle Überprüfung lässt sich nicht über einige hundert Hosts hinaus skalieren.

Beispiele aus der Praxis für Schwachstellenanalysen

Wie das in der Praxis aussieht, hängt stark vom jeweiligen Umfeld ab. Hier einige realistische Szenarien:

Beispiel 1: SaaS-Plattform auf AWS

Ein 20-köpfiges SaaS-Team führt wöchentliche authentifizierte Scans seiner EC2-Flotte, tägliche Image-Scans seiner ECR-Registerstellen sowie kontinuierliche IAM-Richtlinienprüfungen über AWS Inspector durch. Die Ergebnisse werden in Jira erfasst und automatisch dem jeweiligen Service-Verantwortlichen zugewiesen. Für kritische, in der KEV-Liste aufgeführte CVEs gilt eine 7-Tage-SLA; für alle anderen Fälle eine 30-Tage-SLA. Die mediane Zeit bis zur Behebung sank innerhalb von sechs Monaten von 45 Tagen auf 9 Tage.

Beispiel 2: Beaufsichtigtes Finanzdienstleistungsunternehmen

Eine mittelgroße Bank führt vierteljährlich interne Schwachstellenanalysen auf rund 8.000 Hosts, monatliche externe Scans sowie kontinuierliche PCI-Scans durch. Allein für die Compliance-Berichterstattung ist ein eigener GRC-Analyst erforderlich. Für kritische Linux-Server nutzt die Bank die rebootless Patching-Lösung von KernelCare, da die Planung von Patch-Fenstern den Betrieb stört und kostspielig ist – KernelCare schließt die Lücke zwischen Scan und Behebung, ohne den Wartungskalender zu beeinträchtigen.

Beispiel 3: Fertigung mit veralteten OT-Systemen

In einer Fabrikumgebung kommen moderne Linux-Server zusammen mit 15 Jahre alten Windows-Rechnern zum Einsatz, auf denen SPSen laufen. Ein aktives Scannen des OT-Netzwerks ist tabu – ein fehlgeleiteter Scan kann eine Produktionslinie zum Stillstand bringen. Die Bewertung stützt sich auf eine passive Netzwerküberwachung für OT-Ressourcen, authentifizierte Scans für den IT-Bereich und eine dokumentierte Ausnahmeliste für Systeme, die nicht gepatcht werden können, aber durch Netzwerksegmentierung geschützt sind. Die interessanteste Erkenntnis: Ein Windows-2008-Rechner, den jemand vergessen hatte, war vom Unternehmens-LAN aus erreichbar.

Von der Bestandsaufnahme bis zur tatsächlichen Sanierung mit TuxCare

Eine Erkennung ohne Behebung ist nichts weiter als teurer Papierkram. Der eigentliche Gewinn liegt darin, den Kreislauf – Scannen, Priorisieren, Patchen, Überprüfen – in einem Tempo zu schließen, das schnell genug ist, um dem CVE-Rückstand immer einen Schritt voraus zu sein.

TuxCare Radar übernimmt das Scannen und die Priorisierung mit Linux-spezifischer Präzision. KernelCare kümmert sich um die Behebung von CVE-Schwachstellen im Kernel, ohne dass ein Neustart erforderlich ist. LibCare erweitert dies auf gemeinsam genutzte Bibliotheken wie OpenSSL und glibc. Und für Teams, die Systeme betreiben, deren Lebensdauer bereits abgelaufen ist – CentOS 7, ältere Ubuntu-LTS-Versionen oder Laufzeitumgebungen für Sprachen, deren Lebensdauer abgelaufen ist –, sorgt Endless Lifecycle Support dafür, dass auch nach dem Ende des Herstellersupports weiterhin Patches bereitgestellt werden.

Wenn Ihr derzeitiger Prozess mehr Berichte als Korrekturen hervorbringt, ist das die Lücke, die es zu schließen gilt. Erfahren Sie, wie sich TuxCare in einen kontinuierlichen Workflow zum Schwachstellenmanagement und in ein umfassenderes IT-Risikomanagementprogramm einfügt.

Zusammenfassung

Artikel Name

Was ist eine Schwachstellenanalyse? Durchführung, bewährte Verfahren und Beispiele

Beschreibung

Möchten Sie Ihre IT-Systeme absichern? Lesen Sie unseren Leitfaden zu Schwachstellenanalysen, deren Funktionsweise und bewährten Vorgehensweisen von Experten.

Autor

Rohan Timalsina

Name des Herausgebers

TuxCare

Logo des Herausgebers