Was ist Schwachstellenmanagement?
Ein Schwachstellenscan liefert eine Liste von Funden. Schwachstellenmanagement macht daraus für jeden Fund eine Entscheidung: beheben, anders absichern oder das Risiko bewusst tragen, jeweils mit verantwortlicher Person und Datum. Erledigt ist ein Fund erst, wenn eine erneute Prüfung zeigt, dass die Schwachstelle nicht mehr besteht. Ein geschlossenes Ticket belegt nur, dass jemand gehandelt hat.
Geprüft wird nur, was im Scanner konfiguriert ist. Gleichen Sie den Scanumfang deshalb mit dem Asset-Inventar ab, bevor Sie Ergebnisse berichten; ein System, das im Inventar steht und in keinem Scan auftaucht, ist ein eigener Fund. Im ISMS gehört der Prozess zum Betrieb der technischen Maßnahmen.
Wie läuft der Prozess ab?
| Schritt | Was geschieht |
|---|---|
| Erfassen | Geltungsbereich festlegen: Server, Clients, Netzkomponenten, Cloud-Dienste, Container, Bibliotheken Dritter |
| Erkennen | authentifizierte und nicht authentifizierte Scans, Hersteller- und CERT-Meldungen, Testergebnisse, Hinweise von außen |
| Bewerten | technische Schwere und Bedeutung in der eigenen Umgebung getrennt beurteilen |
| Behandeln | Patch, Konfigurationsänderung, ausgleichende Maßnahme oder befristete Risikoübernahme |
| Verifizieren | erneut scannen oder testen und das Ergebnis mit Datum ablegen |
| Berichten | offene Funde, Fristüberschreitungen und Altbestand an die Leitung |
Warum ist der CVSS-Wert nicht die Priorität?
Das Common Vulnerability Scoring System (CVSS) beziffert die technische Schwere einer Schwachstelle aus ihren Eigenschaften. Wie dringend sie in Ihrer Umgebung ist, hängt zusätzlich davon ab, ob das System aus dem Internet erreichbar ist, ob eine Ausnutzung bekannt ist, wie schutzbedürftig die verarbeiteten Informationen sind und welche Maßnahmen bereits wirken.
Feste Schwellenwerte oder Fristen schreiben weder ISO/IEC 27002 noch das BSIG vor. Die Organisation legt sie selbst fest und begründet sie. Für Finanzunternehmen verlangt Art. 10 Abs. 2 der Delegierten Verordnung (EU) 2024/1774, bei der Priorisierung von Patches die Kritikalität der Schwachstelle, die Klassifizierung und das Risikoprofil der betroffenen IKT-Assets zu berücksichtigen.
Beispiel (fiktiv): drei Funde, eine Reihenfolge
Die Werte und Fristen in diesem Beispiel sind frei gewählt und dienen nur der Veranschaulichung; die Fristen stammen aus einer angenommenen internen Richtlinie.
| Fund | CVSS-Basiswert | System | Aus dem Internet erreichbar | Ausnutzung bekannt | Entscheidung |
|---|---|---|---|---|---|
| A | 9,8 | Testserver im abgeschotteten Netz | nein | nein | Behebung im nächsten Wartungsfenster, spätestens in 30 Tagen |
| B | 7,5 | Kundenportal | ja | ja | Behebung binnen 72 Stunden, bis dahin betroffene Funktion abschalten |
| C | 6,5 | Lohnabrechnung mit Personaldaten | nein | nein | Behebung binnen 14 Tagen |
Die Regel dahinter: Erreichbarkeit und bekannte Ausnutzung bestimmen die Frist, der Schutzbedarf verkürzt sie, der CVSS-Wert entscheidet bei Gleichstand. Nach jeder Behebung scannen Sie das System erneut; als Nachweis legen Sie beide Scanergebnisse mit Datum und das Änderungsticket ab. Lässt sich B nicht fristgerecht beheben, entscheidet der Risikoeigentümer über eine Risikoübernahme mit Ablaufdatum.
Was verlangen BSIG, NIS2-Durchführungsverordnung und DORA?
§ 30 Abs. 2 Satz 2 Nr. 5 BSIG verlangt Sicherheitsmaßnahmen bei Erwerb, Entwicklung und Wartung informationstechnischer Systeme einschließlich Management und Offenlegung von Schwachstellen; eine Scanfrequenz nennt die Vorschrift nicht. Für Telekommunikations- und Energieunternehmen nach § 28 Abs. 5 BSIG gilt § 30 grundsätzlich nicht, für Finanzunternehmen nach DORA nicht (§ 28 Abs. 6 Nr. 1 BSIG).
Für Cloud-Anbieter, Rechenzentren, Managed Service Provider und die weiteren Einrichtungsarten des § 30 Abs. 3 BSIG ist Anhang Nr. 6.10 der Durchführungsverordnung (EU) 2024/2690 maßgeblich. Danach führen sie, soweit angemessen, Schwachstellenscans durch und zeichnen die Ergebnisse in geplanten Abständen auf. Schwachstellen, die sie als kritisch für ihren Betrieb einstufen, beheben sie unverzüglich. Erfordert eine Schwachstelle keine Abhilfe, dokumentieren und begründen sie das (Nr. 6.10.3).
Finanzunternehmen scannen IKT-Assets, die kritische oder wichtige Funktionen unterstützen, nach Art. 10 Abs. 2 der Delegierten Verordnung (EU) 2024/1774 mindestens einmal wöchentlich automatisiert. Die Fristen für Patches setzen sie selbst und legen eine Eskalation für Überschreitungen fest (Art. 10 Abs. 4 Buchst. d). Im vereinfachten Rahmen nach Art. 34 Buchst. d richtet sich die Häufigkeit nach Klassifizierung und Risikoprofil des Assets. In ISO/IEC 27002 behandelt Maßnahme 8.8 den Umgang mit technischen Schwachstellen.
Wie grenzt es sich von Patch-Management und Penetrationstest ab?
Das Schwachstellenmanagement entscheidet, was mit welcher Dringlichkeit behandelt wird. Das Patch-Management ist einer der Wege, auf denen die Behebung in den Betrieb gelangt. Ein Penetrationstest prüft zu einem Zeitpunkt und in einem abgegrenzten Bereich, ob Erkennung und Behebung tragen, und findet Schwächen, die ein automatisierter Scan nicht erkennt. Wird eine Schwachstelle bereits ausgenutzt, ist es ein Fall für die Incident Response.
Unbehobene Schwachstellen als Risiko in Rizzqo
Eine Schwachstelle, die nicht sofort behoben wird, lässt sich in Rizzqo als Risikobewertung führen: Eintrittswahrscheinlichkeit in Prozent und Schadenshöhe in Euro, eingestuft über eine konfigurierbare Risikomatrix. Die Behebung läuft als Aufgabe mit geplanter Minderung und lässt sich in beide Richtungen mit Jira synchronisieren, wo die Tickets der IT liegen. Solange die Aufgabe geplant ist, ist ihre Minderung reserviert und senkt nur das Restrisiko; mit dem Abschluss wird sie auf das aktuelle Risiko angerechnet. Die Schwachstelle selbst wird in Rizzqo am betroffenen Asset erfasst.