Vorlage für eine Richtlinie zum Schwachstellenmanagement

So verwenden Sie diese Vorlage:

Kommentare, die zum Verständnis und zur Verwendung dieser Vorlage dienen, stehen in eckigen Klammern „[…]“; im gesamten Dokument wird als „Unternehmen“ [eSecurity Planet] angegeben. Wenn Sie diese Vorlage in eine einsatzbereite Richtlinie umwandeln, entfernen Sie die Abschnitte in eckigen Klammern und ersetzen Sie „[eSecurity Planet]“ durch den Namen Ihrer Organisation.

Diese Richtlinie beschreibt eine allgemeine IT-Infrastruktur und allgemeine Anforderungen. Sie kann bei Bedarf an die IT-Infrastruktur und Anforderungen eines bestimmten Unternehmens angepasst werden.

Um diese Vorlage zu verwenden, kopieren Sie den Website-Text und fügen Sie ihn ein oder laden Sie die Microsoft-Word-Vorlage unten herunter.

1. Überblick

Sicherheitsschwachstellen ermöglichen es Angreifern, eine Ressource oder Daten zu kompromittieren. Schwachstellen entstehen durch Produktfehler, Fehlkonfigurationen oder Lücken in Sicherheits- und IT-Systemen.

Schwachstellen lassen sich in zwei Kategorien einteilen: ungeplante und geplante. Zu den ungeplanten Schwachstellen gehören Zero-Day-Schwachstellen, Fehlkonfigurationen und andere Sicherheitsfehler. Geplante Schwachstellen sind bekannte Schwachstellen, die nicht behoben werden können oder nicht behoben werden sollen.

Diese Richtlinie zum Schwachstellenmanagement definiert die Anforderungen an die IT- und Sicherheitsteams von [eSecurity Planet], um Unternehmensressourcen vor einem unvertretbaren Risiko durch unbekannte und bekannte Schwachstellen zu schützen. Diese Richtlinie zum Schwachstellenmanagement:

• Legt Erwartungen, Anforderungen und grundlegende Verfahren fest für:
• • Identifizierung von Schwachstellen
  • Bewertung von Schwachstellen
  • Behebung von Schwachstellen
  • Nachverfolgung von Schwachstellen
• Definiert Berichte zur Überprüfung der Einhaltung dieser Richtlinie
• Sieht Sanktionen für Verstöße gegen diese Richtlinie vor

[Dieser Abschnitt soll den Leser mit dem Zweck der Richtlinie und den späteren Inhalten des Dokuments vertraut machen. Eine Richtlinie legt fest, WAS getan werden MUSS, nicht WIE es getan werden muss. IT- und Sicherheitsverantwortliche benötigen die Flexibilität, die Ziele mit den ihnen zur Verfügung stehenden Ressourcen nach eigenem Ermessen zu erreichen.]

2. Geltungsbereich

Diese Richtlinie gilt für alle Ressourcen von [eSecurity Planet], die mit dem Netzwerk der Organisation verbunden sind, Verbindungen zwischen Ressourcen bereitstellen, Ressourcen absichern, die Aufgaben der Organisation ermöglichen oder die Daten der Organisation hosten. Die Organisation führt eine formelle Liste der Ressourcen innerhalb des Geltungsbereichs dieser Richtlinie und verfolgt diese gemäß der Definition in Anhang I: Liste der IT-Ressourcen.

Das Schwachstellenmanagement ist auf genaue Listen vorhandener Systeme, Software, Verbindungen und Sicherheitsvorkehrungen angewiesen. Der Geltungsbereich sollte [gemäß der Richtlinie zum Asset-Management / monatlich / vierteljährlich] überprüft werden, um sicherzustellen, dass alle Assets zur Identifizierung von Schwachstellen genau bewertet und getestet werden können.

Schwachstellenscans müssen möglicherweise auch für Websites und Anwendungen durchgeführt werden, die nicht im Besitz anderer Abteilungen sind und von diesen verwaltet werden. Die IT-Abteilung muss die Zuständigkeit für jede Anwendung und Website überprüfen, um Lücken im Schwachstellenmanagement zu vermeiden.

Obwohl Patch-Management und Change-Management wichtige Bestandteile des Schwachstellenmanagements sind, werden sie in eigenen Richtlinien separat behandelt.

[Dies ist eine allgemeine Fassung des Geltungsbereichs. Darin sollte festgelegt werden, welche Bereiche zur Identifizierung von Schwachstellen überwacht und getestet werden. Organisationen können den Geltungsbereich im Anhang so weit oder eng fassen wie erforderlich. Ein umfassenderer Geltungsbereich ist zur Risikokontrolle grundsätzlich besser, kann jedoch höhere Kosten verursachen.]

3. Richtlinie und Verfahren zum Schwachstellenmanagement

A. Verantwortliche Stelle für das Schwachstellenmanagement

[Der Chief Information Security Officer (CISO) von eSecurity Planet] wird als verantwortliche Stelle für das Schwachstellenmanagement benannt. Sie trägt die letztendliche Verantwortung und Befugnis, sämtliche Abschnitte dieser Richtlinie und dieses Verfahrens zum Patch-Management zu planen, auszuführen, zu genehmigen oder an interne Ressourcen bzw. Tools oder Anbieter von Drittanbietern zu delegieren.

Obwohl die verantwortliche Stelle für das Schwachstellenmanagement die letztendliche Verantwortung trägt, wird anerkannt, dass die [IT-Sicherheitsabteilung] die Pläne der verantwortlichen Stelle im Allgemeinen umsetzt, um die Richtlinie zum Schwachstellenmanagement einzuhalten. Die an anderer Stelle dieser Richtlinie verwendete Bezeichnung „IT-Abteilung“ bezieht sich auf die verantwortliche Stelle für das Schwachstellenmanagement, die [IT-Sicherheitsabteilung] und delegierte Vertreter.

Die verantwortliche Stelle für das Schwachstellenmanagement überprüft und genehmigt außerdem:

• Geltungsbereich der Richtlinie zum Schwachstellenmanagement
• Priorität der Schwachstelle
• Schwachstellen- und Penetrationstests
• Erforderliche Wartungsausfallzeiten für Änderungen oder Behebungsmaßnahmen
• Erforderliche Ausnahmen
• Berichte zum Schwachstellenmanagement
• Durchsetzung

[Dieser Abschnitt legt fest, wer das Budget genehmigen und den Prozess des Schwachstellenmanagements verwalten muss. Am besten wird eine Funktionsbezeichnung verwendet, da Mitarbeiter wechseln können und die Richtlinie nicht bei jedem Personalwechsel überarbeitet werden sollte.]

B. Identifizierung von Schwachstellen

Die IT-Abteilung darf nicht davon ausgehen, dass die Sicherheit unangreifbar ist. Es müssen Tests durchgeführt werden, um zu überprüfen, dass Ressourcen fehler- und lückenlos installiert, konfiguriert, integriert und abgesichert wurden.

i. Aktive Erkennung von Schwachstellen

Schwachstellenscans und Penetrationstests werden [vierteljährlich] sowie nach wesentlichen Änderungen an Ressourcen durchgeführt, um unbekannte Schwachstellen zu erkennen. Für Hochrisikosysteme mit besonders wertvollen Daten oder großer Bedeutung für den Betrieb sind [monatliche] Scans erforderlich.

Schwachstellenscans können automatisiert und mit kommerziellen Tools durchgeführt werden, sofern diese die konkreten potenziellen Schwachstellen der jeweiligen Ressource testen können. Nicht authentifizierte Schwachstellenscans sollten durchgeführt werden, um die Systeme aus der Perspektive eines externen Hackers zu betrachten. Authentifizierte Schwachstellenscans sollten die Systeme aus der Perspektive eines Hackers mit gestohlenen Zugangsdaten abbilden.

Spezifische Schwachstellenscans können bei der Entdeckung bestimmter Schwachstellen oder Zero-Day-Bedrohungen ad hoc erforderlich werden. Diese Scans sollten nach Bedarf und nicht nur nach dem üblichen Scan-Zeitplan durchgeführt werden.

ii. Informations- und Bedrohungsüberwachung

Zusätzlich zu den Tests überwacht und scannt die IT-Abteilung fortlaufend verschiedene Quellen, um Informationen über die Veröffentlichung neuer Angriffsmethoden und Ressourcenschwachstellen zu erhalten. Aktualisierungen und Patches für Ressourcen fallen in den Geltungsbereich der Richtlinie zum Patch-Management, ungepatchte Schwachstellen müssen jedoch im Rahmen dieser Richtlinie zum Schwachstellenmanagement behandelt werden. Zu den Quellen können unter anderem Sicherheits-Mailinglisten, Benachrichtigungen von Anbietern und Websites gehören.

iii. Systeme von Drittanbietern

Die Organisation muss wahrscheinlich einige Integrationen mit Endpunkten und Systemen von Drittanbietern vornehmen, etwa:

• Gemietete industrielle Steuerungssysteme (Aufzugsanlagen, Brandschutzsysteme usw.)
• Gemietete Betriebsausrüstung
• Von Mitarbeitern, Beratern, Kunden und Gästen mitgebrachte Geräte im Rahmen von Bring Your Own Device (BYOD)
• Cloud-Infrastruktur, die gemeinsam vom Cloud-Anbieter und der Organisation überwacht und verwaltet wird

Schwachstellenscans sollten alle zugänglichen, mit der Organisation verbundenen Systeme einschließen und können auch diese Systeme von Drittanbietern umfassen. Die erkannten Schwachstellen können jedoch außerhalb des Zuständigkeitsbereichs interner Ressourcen liegen. Formelle Vereinbarungen mit Geschäftspartnern können die Verantwortlichkeiten der Parteien für verschiedene Arten von Schwachstellen festlegen.

Unabhängig von der offiziellen Zuständigkeit muss die IT-Abteilung möglicherweise kompensierende Kontrollen vorbereiten, um Schwachstellen zu mindern. Die Organisation sollte beispielsweise mithilfe einer Netzwerkzugangskontrolle oder gleichwertiger Lösungen kontinuierliche Scans durchführen, um Endpunkte mit Schwachstellen zu erkennen, sobald sie versuchen, eine Verbindung zum Netzwerk der Organisation herzustellen, und diese in Quarantäne zu verschieben.

iv. Dokumentation

Die IT-Abteilung muss das Programm zur Identifizierung von Schwachstellen konzipieren und dokumentieren, indem sie alle Scans, Tests und zur Informationsgewinnung überwachten Quellen auflistet. Diese Informationen sollten als Anhang zu dieser Richtlinie verfügbar gemacht und bei Bedarf aktualisiert werden. Die risikoreichsten Assets der Organisation müssen ausdrücklich aufgeführt werden; außerdem ist anzugeben, welche Tests zur Überprüfung ihres Status durchgeführt werden.

[Die Auflistung der Arten von Scan-Tools, Penetrationstests und Quellen für Bedrohungsinformationen ist zwar oft ausreichend, eine Tabelle der wichtigsten Assets bietet jedoch zusätzlichen Schutz. Manche Organisationen führen oberflächliche Scans mit kostengünstigen Tools durch, ohne zu prüfen, ob diese Tools tatsächlich ihre kritischsten Systeme testen.]

Wenn eine Schwachstelle identifiziert wird, stellt die IT-Abteilung ein Ticket aus und erfasst die Schwachstelle in einer Liste zur Nachverfolgung des Schwachstellenmanagements.

[Dieser Abschnitt soll Wachsamkeit und die schnelle Erkennung verfügbarer Aktualisierungen und Patches fördern. Best Practices empfehlen, bestimmten Personen die Recherche, Suche und Überprüfung der Quelle von Aktualisierungen und Patches zu übertragen.]

C. Bewertung von Schwachstellen

Sobald Schwachstellen identifiziert wurden, müssen sie im Hinblick auf ihr potenzielles Risiko für die Organisation verifiziert und bewertet werden. Die Schwachstelle sollte mit unabhängigen Tools und durch Mitarbeiter verifiziert werden, die nicht der erkennenden Stelle angehören. In einigen Fällen kann ein aktiver Versuch erforderlich sein, die Schwachstelle auszunutzen, um sie zu verifizieren oder ihr Risiko zu bewerten.

Die Schwachstelle wird anhand der folgenden Kriterien bewertet:

• Der Common Vulnerability Scoring System (CVSS)-Score der Schwachstelle (falls verfügbar)
• Die Wahrscheinlichkeit, dass die Schwachstelle ausgenutzt wird
• Verbundene oder sich kaskadenartig auswirkende Schwachstellen

CVSS weist Schwachstellen einen Wert zwischen 1 und 10 zu. Die Bewertungen nach CVSS Version 3.0 entsprechen:

• 9,0 – 10,0 = Kritischer Schweregrad
• 7,0 – 8,9 = Hoher Schweregrad
• 4,0 – 6,9 = Mittlerer Schweregrad
• 0,1 – 3,9 = Niedriger Schweregrad
• 0,0 = Kein Schweregrad (informativ)

Diese Werte geben keine Auskunft über die Wahrscheinlichkeit einer Ausnutzung, wohl aber über das Ausmaß, in dem ein Angreifer ein System beeinträchtigen kann, oder über den erforderlichen Aufwand. Die U.S. Cybersecurity and Infrastructure Security Agency (CISA) führt eine Liste der bekanntermaßen ausgenutzten Schwachstellen, anhand derer eine aktive Ausnutzung geprüft werden kann.

Ebenso muss die IT-Abteilung die aktuelle Umgebung, die aktuelle IT-Architektur und die Art der Schwachstelle bewerten, um die Wahrscheinlichkeit einer Ausnutzung zu bestimmen. Diese sollte ebenfalls auf einer Skala von 1 (geringe Wahrscheinlichkeit) bis 10 (hohe Wahrscheinlichkeit) bewertet werden. Die Wahrscheinlichkeit einer Ausnutzung sollte, sofern möglich, Informationen aus der Bedrohungsanalyse über die Ausnutzung ähnlicher Schwachstellen einbeziehen. Die Addition dieser drei Faktoren ergibt für die zu behebende Schwachstelle einen Wert zwischen 1 (niedrige Priorität oder keine Maßnahme erforderlich) und 20 (dringende Maßnahme erforderlich).

[Viele Organisationen bevorzugen in ihren Prozessen keine numerischen Einstufungen. Die Vergabe von Werten kann zeitaufwendig sein, insbesondere in der Anfangsphase der Einführung. Numerische Werte helfen jedoch dabei, Risiken und Dringlichkeit außerhalb der IT-Abteilung zu kommunizieren, und erleichtern Berichterstattung und Compliance.]

Wenn die Schwachstelle weitere bestehende oder neue Schwachstellen offenlegt, sollten diese verwandten Schwachstellen vermerkt werden. Auch verbundene Systeme, Software und Prozesse sollten für die Schwachstelle dokumentiert werden.

Allgemeine Angaben sind zulässig, wenn die Liste der betroffenen Systeme unübersichtlich wäre; nach Möglichkeit sollten jedoch konkrete Angaben verwendet werden. Zum Beispiel:

• Eine Schwachstelle im Firewall-Modell, das in allen Niederlassungen verwendet wird, sollte als für „alle Niederlassungen, Systeme und Prozesse innerhalb der Organisation“ geltend verallgemeinert werden.
• Bei einer Schwachstelle auf einem bestimmten Router in einem bestimmten Netzwerksegment sind ausdrücklich aufzuführen:
• • Betroffener IP-Adressbereich
  • Betroffene Personen (z. B. Benutzer in der Finanzabteilung in Porto)
  • Betroffene Geräte (z. B. Finanzserver, Buchhaltung, PCs in der Finanzabteilung, lokale Drucker)
  • Bemerkenswerte oder besonders wertvolle betroffene Prozesse oder Systeme (z. B. Buchhaltungssysteme, Kreditorenbuchhaltung, Debitorenbuchhaltung usw.)

[Dieser Abschnitt beschreibt die Bewertungskriterien zur Einschätzung des potenziellen Risikos für die Organisation. Auch wenn eine bestimmte Schwachstelle ein bestimmtes System betrifft, muss sie im Kontext der anderen betroffenen Systeme und Prozesse betrachtet werden, um ihre potenziellen Auswirkungen auf die Organisation zu bestimmen.]

D. Priorisierung von Schwachstellen

Bei Tests oder bei der Bekanntgabe von Zero-Day-Schwachstellen können mehrere Schwachstellen identifiziert werden. Falls erforderlich, legt die IT-Abteilung die Priorität für die Behebung dieser Schwachstellen im Kontext anderer bestehender Schwachstellen anhand einer Hierarchie fest, die auf Folgendem basiert:

• Bewerteter Schwachstellenwert aus der oben beschriebenen Schwachstellenbewertung
• Risikobewertungswert der von der Schwachstelle betroffenen Ressourcen (Daten, Systeme, Prozesse usw.) für die Organisation

Risikobewertungswert: [eSecurity Planet] verwendet eine Risikoanalyse, um eine Risikobewertung interner Systeme zu erstellen, die in einem Risikoregister auf einer Skala von 1 (geringe Auswirkung/Wert) bis 10 (höchste Auswirkung/Wert) erfasst und aktualisiert wird. Eine Schwachstelle kann jedoch mehrere Systeme, Softwarekomponenten oder Prozesse betreffen. Daher sollte der Risikowert dem Gesamtwert aller exponierten Ressourcen oder dem höchsten exponierten Risikowert entsprechen – je nachdem, welcher Wert höher ist.

Wird der Risikobewertungswert von 1 bis 10 mit der Schwachstellenbewertung zwischen 1 und 20 kombiniert, ergibt sich für die Schwachstelle ein Prioritätswert zwischen 2 (keine Maßnahme erforderlich) und 30 (sofortige Maßnahme erforderlich). Diese Priorisierung führt im Allgemeinen zu Schwachstellenstufen, die von der IT-Abteilung bearbeitet werden müssen.

[Dieser Abschnitt weist eine Priorität zu, um zu bestimmen, welche Schwachstellen im Schwachstellenmanagement zuerst behandelt werden sollten. Achten Sie darauf, dass niemand das Ausnutzungsrisiko und den Wert des Assets aus Bequemlichkeit manipuliert, um die Behandlung der Schwachstelle zu vermeiden oder weniger riskante Behebungsmaßnahmen zu verfolgen, die weniger störend oder leichter umzusetzen sind.

In diesem Abschnitt wird auf Risikobewertungen und ein Risikoregister verwiesen. Organisationen jeder Größe können und sollten ein Risikoregister führen. Das Risikoregister bewertet den Wert einer Ressource und die mögliche Größe der Auswirkungen auf die Organisation, wenn diese Ressource beeinträchtigt, kompromittiert oder funktionsunfähig wird.

Sowohl direkte als auch indirekte Risiken sollten berücksichtigt werden. Eine Schwachstelle in der Firewall-Konfiguration eines WLAN-Routers könnte beispielsweise Windows-95-Rechner gefährden, die zum Betrieb von Fertigungsanlagen erforderlich sind. Das Risiko des exponierten Routers umfasst daher auch das Risiko der exponierten Windows-95-Rechner sowie das daraus entstehende Betriebsrisiko kompromittierter Fertigungsanlagen.

Wenn kein Risikoregister vorhanden ist, muss die Organisation den Wert der Ressource für die Organisation qualitativ einschätzen.]

E. Richtlinien zur Behebung von Schwachstellen

Sobald eine Schwachstelle identifiziert, bewertet und priorisiert wurde, muss die Maßnahme zu ihrer Behebung konzipiert, getestet, vorbereitet, geplant, angewendet, verifiziert und getestet werden.

i. Konzeption der Schwachstellenbehebung

Die Unterkategorie Patch-Management beruht auf der Anwendung kommerziell bereitgestellter Behebungsmaßnahmen bzw. Patches auf kommerzielle Produkte und wird umfassend in der Richtlinie zum Patch-Management behandelt. Ein umfassenderes Schwachstellenmanagement erfordert weitere Anpassungen von Einstellungen und der IT-Architektur sowie die Installation zusätzlicher Sicherheitstools oder Kontrollen.

Häufig gibt es mehrere Möglichkeiten, eine Schwachstelle direkt oder indirekt zu beheben. In vielen Fällen ist eine vollständige Beseitigung der Schwachstelle aufgrund der erforderlichen Kosten oder der Komplexität der notwendigen Maßnahme nicht möglich.

Kosten und Aufwand dürfen jedoch nicht als Entschuldigung dafür dienen, Schwachstellen zu ignorieren. Temporäre und partielle Behebungsmaßnahmen (oder kompensierende Kontrollen) müssen innerhalb eines dem Risikoniveau angemessenen Zeitraums konzipiert, getestet und angewendet werden.

Zu den üblichen Behebungsmaßnahmen gehören unter anderem:

• Eine kompensierende Sicherheitskontrolle wie ein neues Sicherheitstool (Firewall usw.) bereitstellen
• Patches bereitstellen
• Sicherheitskontrollen um eine Multi-Faktor-Authentifizierung ergänzen
• Verwundbare IT-Ressource aktualisieren oder ersetzen
• Verwundbare IT-Ressource isolieren und schützen (Netzwerksegmentierung, drahtlosen Zugriff trennen usw.)
• Die IT-Ressource außer Betrieb nehmen oder ihre Nutzung einstellen
• Konfigurationsänderungen bereitstellen

Komplexe Behebungsmaßnahmen können mehrere kompensierende Kontrollen oder mehrere Schritte erfordern. Für komplexere Behebungsmaßnahmen sollten Meilensteine festgelegt werden, um den Fortschritt der Umsetzung zu überprüfen.

In einigen Fällen erfordert die Behebung die Implementierung technischer Kontrollen, die sich auf Benutzer auswirken, beispielsweise eine Multi-Faktor-Authentifizierung (MFA). Schulungen zu diesen Tools sollten als Teil der Konzeption der Behebungsmaßnahme betrachtet werden, müssen jedoch im Allgemeinen nicht innerhalb des unten genannten Mindestzeitraums für die Behebung von Schwachstellen abgeschlossen werden.

ii. Testen der Schwachstellenbehebung

Bei besonders wertvollen Ressourcen kann die IT-Abteilung beschließen, die Behebungsmaßnahme in einer Testumgebung zu testen, um mögliche Beeinträchtigungen des Geschäftsbetriebs oder andere Probleme zu ermitteln. Behebungsmaßnahmen, die den Testprozess nicht bestehen, müssen neu konzipiert und erneut getestet werden.

[Das Testen von Behebungsmaßnahmen in einer Testumgebung ermöglicht es der IT-Abteilung, solche Probleme in einer Umgebung zu erkennen, die sich nicht auf Geschäftsprozesse auswirkt. Nicht alle Organisationen verfügen über die Ressourcen, um Tests für weniger wertvolle Ressourcen durchzuführen.]

iii. Vorbereitung der Schwachstellenbehebung

Nicht alle Behebungsmaßnahmen werden erfolgreich oder problemlos angewendet. In einigen Fällen kann eine Behebungsmaßnahme ein System unbrauchbar machen oder Kaskadenprobleme bei anderen IT-Systemen oder anderer Software verursachen. Um sich auf diese Möglichkeit vorzubereiten, muss die IT-Abteilung sicherstellen, dass [die Richtlinie zur Notfallwiederherstellung vor dem Patch-Management-Prozess ausgeführt wurde.

Mindestens]:

• Vor der Anwendung des Updates wurde eine vollständige Systemsicherung durchgeführt
• Vor der Anwendung des Updates wurde eine vollständige Datensicherung durchgeführt

Bei erfolglosen Behebungsmaßnahmen, die den Betrieb beeinträchtigen, versucht die IT-Abteilung, das System oder die Software auf eine vorherige Version zurückzusetzen, um die Funktionsfähigkeit wiederherzustellen. Systeme, die nicht zurückgesetzt werden können, müssen umgehend aus einer Sicherung wiederhergestellt oder ersetzt werden. In einigen Fällen kann die Beeinträchtigung das System intakt lassen und Änderungen am Plan zur Behebung erfordern, um den Betrieb wiederherzustellen. Solche Änderungen sollten so schnell wie möglich umgesetzt werden, um die Beeinträchtigung zu begrenzen.

Die IT-Abteilung kann versuchen, Behebungsmaßnahmen mehrfach umzusetzen. Bei Behebungsmaßnahmen, die nicht erfolgreich angewendet werden können, muss die IT-Abteilung den unten beschriebenen Prozess für Ausnahmen und Behebungsmaßnahmen befolgen.

[Dieser Abschnitt erkennt an, dass nicht alle Behebungsmaßnahmen wie vorgesehen funktionieren und die IT-Abteilung sich vor der Anwendung von Patches jeder Art auf diese Möglichkeit vorbereiten muss. Wir empfehlen, auf eine etablierte Richtlinie zur Notfallwiederherstellung zu verweisen, die Sicherungen und Wiederherstellungssysteme ausführlich behandeln sollte. Organisationen ohne eine solche Richtlinie können diesen Text jedoch löschen und lediglich die Durchführung von Sicherungen vorschreiben.]

iv. Zeitplan für die Schwachstellenbehebung

Auf Grundlage der Einstufung in der Schwachstellenmanagementliste muss die IT-Abteilung die Behebung innerhalb folgender Fristen verfolgen:

• 20+: innerhalb von [5] Arbeitstagen
• 14,0–20: innerhalb von [10] Arbeitstagen
• 8,0–13,9: innerhalb von [30] Arbeitstagen
• Schwachstellen mit einer Einstufung unter 8,0: innerhalb von [90] Tagen

[Die Bearbeitungszeit für Schwachstellen hängt vom potenziellen Risiko ab. Banken, Krankenhäuser und andere Organisationen mit einem potenziell hohen Risiko und hohen Auswirkungen auf die Organisation können für die höchsten Stufen Stunden (z. B. 72 Stunden) statt Tage festlegen.]

Die Behebung von Schwachstellen umfasst Sicherheitstools, Anpassungen von Einstellungen, Änderungen an der IT-Architektur und andere Schritte, die erforderlich sind, um das Risiko einer entdeckten Schwachstelle zu senken. 

Weitere Faktoren, die die Priorität einer Schwachstelle beeinflussen, sind:

• Zur Behebung der Schwachstelle erforderliche Behebungsmaßnahmen
• Die Fähigkeit einer potenziellen Behebungsmaßnahme oder Sicherheitskontrolle, mehrere Schwachstellen zu beheben
• Mögliche Beeinträchtigungen des Geschäftsbetriebs durch erforderliche Behebungsmaßnahmen

Zur Behebung der Schwachstelle erforderliche Behebungsmaßnahmen können von einfachen Anpassungen an Firewall-Ports bis hin zu komplexen Installationen mehrerer neuer Sicherheitstools und Kontrollen reichen. Im Allgemeinen werden einfache Lösungen aufgrund der Kosten für Umsetzung und Tests bevorzugt. Die Behebungsmaßnahme muss das Risiko der exponierten Schwachstelle jedoch ausreichend reduzieren.

Die Komplexität der Lösung verringert nicht die Dringlichkeit der Behebung der Schwachstelle. Können jedoch vorübergehende Maßnahmen angewendet werden, um das ursprüngliche Risiko zu senken, können die Gesamtpriorität und die Einstufung der Schwachstelle neu bewertet werden.

Eine potenzielle Behebungsmaßnahme oder Sicherheitskontrolle, die mehrere Schwachstellen behebt kann nach Ermessen der IT-Abteilung priorisiert werden, solange die Behebungsmaßnahme die Umsetzung dringenderer Behebungen von Schwachstellen nicht beeinträchtigt. Effizienz ist wichtig, wiegt jedoch die potenziellen Schäden durch exponierte Risiken nicht auf.

Mögliche Beeinträchtigungen des Geschäftsbetriebs können durch erforderliche Behebungsmaßnahmen entstehen. Wo möglich, sollten Beeinträchtigungen des Geschäftsbetriebs vermieden und minimiert werden.

Um übermäßige Beeinträchtigungen zu vermeiden, müssen für diese störenden Behebungsmaßnahmen Wartungsfenster geplant und vorab von der für das Schwachstellenmanagement zuständigen Stelle genehmigt werden, vorzugsweise mit Zustimmung der zuständigen Geschäftsverantwortlichen, die von der Beeinträchtigung betroffen sind.

Um die Genehmigung zu erhalten, muss die IT-Abteilung bei der für das Patch-Management zuständigen Stelle ein [Ticket ausstellen / ein Formular ausfüllen / eine E-Mail senden]. Der Antrag auf ein Wartungsfenster muss folgende Informationen enthalten:

• Angaben zu den betroffenen Systemen
• Angaben zur Dringlichkeit und zum Risiko der Schwachstelle 
• Bevorzugtes Wartungsfenster und mindestens ein alternatives Wartungsfenster
• Angaben zu den Verfahren für ein Zurücksetzen, falls die Behebungsmaßnahme fehlschlägt

Bei Behebungsmaßnahmen, die in Abwesenheit der für das Schwachstellenmanagement zuständigen Stelle erforderlich sind, kann die nächste verfügbare Führungskraft im Organigramm das Wartungsfenster genehmigen.

Muss eine Notfallmaßnahme zur Behebung angewendet werden und kann keine Führungskraft innerhalb des aufgrund der Dringlichkeit der Schwachstelle erforderlichen Zeitrahmens eine angemessene alternative Wartungszeit genehmigen oder vorschlagen, kann die IT-Abteilung unter folgenden Bedingungen fortfahren:

• Dokumentierte Bemühungen, eine Genehmigung einzuholen
• Nicht leitende betroffene Stakeholder (Kunden, Mitarbeiter usw.) über das Wartungsfenster informieren
• Die Behebungsmaßnahme ohne formelle Genehmigung umsetzen

Es wird anerkannt, dass Notfallmaßnahmen und Beeinträchtigungen durch Wartungsarbeiten gelegentlich erforderlich sein können. Die IT-Abteilung sollte Beeinträchtigungen jedoch stets minimieren.

[Dieser formal formulierte Teil des Patch-Prozesses verlangt von den für die Umsetzung der Behebungsmaßnahme Verantwortlichen, ein Wartungsfenster für den Zeitpunkt zu beantragen, an dem das Softwareupdate zu Ausfallzeiten für Benutzer oder aktiv genutzte Systeme führt. Er räumt der Sicherheit jedoch auch Vorrang vor dem Betrieb ein, wenn die für den Betrieb verantwortlichen Führungskräfte Ausfallzeiten nicht in angemessener Weise genehmigen können oder wollen.

Das genaue Einstufungssystem und die Dringlichkeit legt die Organisation fest. Der auf der Priorität basierende Zeitplan sollte eine schnelle Bearbeitung der kritischsten Patches und Updates für die kritischsten Ressourcen sicherstellen. Die maximale Frist von 30 Tagen für die Umsetzung von Behebungsmaßnahmen sollte verhindern, dass Systeme oder Software vollständig übersehen oder ignoriert werden oder sich Updates ansammeln.]

v. Umsetzung der Schwachstellenbehebung

Die Behebung von Schwachstellen erfordert typischerweise einen manuellen Prozess. Von der IT-Abteilung wird erwartet, dass sie ausreichende Ressourcen beschafft und einsetzt, um die Behebungsmaßnahme innerhalb des vorgesehenen Zeitrahmens ordnungsgemäß umzusetzen. Bei Bedarf kann externes Fachwissen hinzugezogen werden, um Behebungsmaßnahmen für umfangreiche oder risikoreiche Assets umzusetzen.

[Dieser formal formulierte Teil des Patch-Prozesses verlangt von den für die Umsetzung der Behebungsmaßnahme Verantwortlichen, die Behebungsmaßnahme rechtzeitig bereitzustellen, selbst wenn dafür zusätzliche Ressourcen für die Umsetzung eingestellt werden müssen. Diese Formulierung räumt der Sicherheit höhere Priorität als der Budgetkontrolle ein und muss möglicherweise an die Anforderungen der Organisation angepasst werden.]

vi. Verifizierung und Testen der Schwachstellenbehebung

Nach Abschluss der Umsetzung der Behebungsmaßnahme sollte die IT-Abteilung prüfen, ob die Maßnahme erwartungsgemäß funktioniert und das Risiko wie vorgesehen reduziert. Penetrationstests und Schwachstellenscans sollten wiederholt werden, um den Erfolg zu überprüfen oder erfolglose Behebungsmaßnahmen zu identifizieren und zu dokumentieren. Noch exponierte Schwachstellen müssen gemäß dem Abschnitt „Nachverfolgung von Behebungsmaßnahmen und Ausnahmen“ (Absatz 3.F weiter unten) behandelt werden.

F. Nachverfolgung von Behebungsmaßnahmen und Ausnahmen

Behebungsmaßnahmen beseitigen Schwachstellen nicht immer. In vielen Fällen schirmen die zur Behebung einer Schwachstelle eingeführten kompensierenden Kontrollen die Schwachstelle durch zusätzliche Sicherheitsebenen ab, ohne die Schwachstelle direkt zu beheben.

Alle ungelösten Schwachstellen und die zugehörigen kompensierenden Kontrollen werden innerhalb der Nachverfolgungsliste des Schwachstellenmanagements weiterhin im Hinblick auf potenzielle künftige Schwachstellen erfasst und überwacht. Behobene Schwachstellen sollten [vierteljährlich] überprüft werden, um festzustellen, ob effizientere Behebungsmaßnahmen umgesetzt werden können, die Zeit und Wartungskosten sparen oder das Risiko weiter reduzieren.

Beim Patchen oder bei Wartungsarbeiten werden alle fehlgeschlagenen, störenden oder nicht gepatchten Systeme zu Ausnahmen, die gemäß dieser Richtlinie als Schwachstellen behandelt werden. Die meisten fehlgeschlagenen oder störenden Behebungsmaßnahmen bleiben jedoch keine Ausnahmen. Fehlgeschlagene oder störende Behebungsmaßnahmen werden überarbeitet und zur Lösung wieder in den Schwachstellenmanagementprozess aufgenommen. In seltenen Fällen kann die Kombination aus einer Schwachstelle mit geringem Risiko und hohen Kosten für kompensierende Kontrollen dazu führen, dass die Organisation das Risiko der betreffenden Schwachstelle akzeptiert. Diese Ausnahmen müssen innerhalb der Schwachstellenliste nachverfolgt und gemeldet werden.

[Die meisten Organisationen können eine vierteljährliche Überprüfung gemäß den Ausführungen in diesem Dokument durchführen. Kleinere Organisationen verfügen jedoch möglicherweise nur über Ressourcen für halbjährliche oder jährliche Überprüfungen, während größere Organisationen bei Systemen mit hohem Risiko oder hohem Wert möglicherweise aggressiver vorgehen und monatliche oder wöchentliche Überprüfungen wünschen.]

G. Berichterstattung zum Schwachstellenmanagement

Die IT-Abteilung erstellt [monatlich] Berichte zum Patchen und Aktualisieren. Die Berichte müssen Folgendes enthalten:

• Datum(e) der letzten Asset-Scans und Anzahl der erfassten Assets
• Prozentsatz der Systeme, die aktiv auf Schwachstellen getestet wurden, sowie die Arten der bei den aktiven Tests verwendeten Schwachstellenscans und Penetrationstests
• Anzahl der beim Scannen erkannten Schwachstellen
• Anzahl der durch Behebungsmaßnahmen behobenen Schwachstellen, aufgeschlüsselt nach:
• • Schwachstellenrisiko
  • Gesamtpriorität
  • Zeit bis zur Behebung (zusammengefasst und im Detail)
• Der für jede Behebungsmaßnahme durchgeführte Schwachstellenscan oder Penetrationstest zur Überprüfung der ordnungsgemäßen Umsetzung (als ausstehend kennzeichnen, wenn der Test noch läuft)
• Anzahl der verbleibenden, nicht behobenen Schwachstellen
• Durchschnittliche Zeit zwischen der Erkennung und der Behebung von Schwachstellen, aufgeschlüsselt nach Risikostufe und Wertkategorie des Assets
• Anzahl der in den Ausnahmebericht aufgenommenen Ausnahmen von Schwachstellen
• Gesamtzahl der Schwachstellen und Behebungsmaßnahmen in der Nachverfolgungsliste für Schwachstellen

[Die IT-Abteilung muss Berichte erstellen, damit die Organisation überprüfen kann, ob die Verfahren zum Schwachstellenmanagement ordnungsgemäß befolgt und Behebungsmaßnahmen rechtzeitig umgesetzt werden. Regelmäßige Berichte können die Notwendigkeit spezieller Compliance-Berichte beseitigen.

Die Daten im Bericht sollten außerdem dazu verwendet werden, den Prozess des Schwachstellenmanagements zu verbessern. Beispielsweise kann die Anzahl der Behebungsmaßnahmen für Schwachstellen, die zu Support-Tickets führen, dazu dienen festzustellen, ob vor der Bereitstellung zusätzliche Tests erforderlich sind.]

4. Auditkontrollen und Management

Führungskräfte und Auditoren von [eSecurity Planet] können jederzeit dokumentierte Verfahren und Nachweise für die Praxis des Schwachstellenmanagements anfordern. Beispiele für dokumentierte Verfahren und Nachweise sind:

• Genehmigte Anträge auf Wartungsfenster
• Genehmigte Ausnahmelisten
• Vollständige oder teilweise Exporte der Nachverfolgungsliste oder des Systems für das Schwachstellenmanagement
• Vollständige oder teilweise Kopien der durchgeführten Schwachstellenscans und Penetrationstests zur Erkennung von Schwachstellen oder zur Überprüfung von Behebungsmaßnahmen
• Berichte zum Schwachstellenmanagement

[Dieser Abschnitt erkennt den gelegentlichen Bedarf von Führungskräften und Auditoren an einer außerplanmäßigen Berichterstattung über die Prozesse des Schwachstellenmanagements an. Zur Überprüfung der Berichte zum Schwachstellenmanagement können einige Auditoren außerdem Systemprotokolle verlangen, die erfolgreiche System- oder Softwareupdates bestätigen.]

5. Durchsetzung

Mitarbeiter, bei denen ein vorsätzlicher Verstoß gegen die Richtlinie festgestellt wird, können disziplinarischen Maßnahmen bis hin zur Kündigung unterliegen. Die Arbeitsleistung der Mitarbeiter der IT-Abteilung, die für die Umsetzung dieser Richtlinie verantwortlich sind, wird teilweise oder vollständig anhand ihrer Fähigkeit bewertet, die Erwartungen dieser Richtlinie zu erfüllen.

Die wiederholte Unfähigkeit der IT-Abteilung, die Anforderungen dieser Richtlinie zum Schwachstellenmanagement zu erfüllen, kann als Fahrlässigkeit betrachtet werden und disziplinarische Maßnahmen nach sich ziehen. Gefälschte Berichte oder grobe Fahrlässigkeit bei der Umsetzung können eine sofortige Kündigung oder disziplinarische Maßnahmen rechtfertigen.

[Damit Richtlinien wirksam sind, sollte es Sanktionen für deren Nichteinhaltung geben. Dieses Dokument geht davon aus, dass Organisationen, die den Update-Standard aufgrund fehlender Ressourcen nicht erfüllen, ihre IT-Abteilung nicht zur Verantwortung ziehen, wenn diese überarbeitet oder überlastet ist. Organisationen, die unangemessene Erwartungen stellen, werden wahrscheinlich eine hohe Fluktuation in der IT-Abteilung und Schwierigkeiten bei der Bindung erfahrener oder kompetenter Mitarbeiter erleben.]

6. Verteilung

Diese Richtlinie ist an alle Führungskräfte von [eSecurity Planet] sowie an die Mitarbeiter der IT-Abteilung zu verteilen, die für die Unterstützung und Verwaltung der Richtlinie zum Patch-Management verantwortlich sind.

[Alle Personen, die am Patch-Management arbeiten müssen (Mitarbeiter der IT-Abteilung) oder von der Richtlinie betroffen sind (mindestens Führungskräfte, möglicherweise aber auch andere relevante Mitarbeiter), sollten diese Richtlinie erhalten. Für die Umsetzung verantwortliche Mitarbeiter müssen den Erhalt möglicherweise formell bestätigen.]

7. Richtlinienversion

Version 1.0
Genehmigungsdatum: 12.05.2023
Beschreibung: Erster Richtlinienentwurf

[Dieser Abschnitt kann auch in eine Versionshistorie der Richtlinie mit einer Tabelle früherer Versionen und Genehmigungen umgewandelt werden.]

8. Unterschriften

Genehmigt durch: ____________________________________________
[Unterschrift der für das Patch-Management zuständigen Stelle]

Genehmigt durch: ____________________________________________
[CEO oder andere zuständige Führungskraft]

[Eine Unterschrift der für das Patch-Management zuständigen Stelle bestätigt die Anforderungen der Richtlinie und wird de facto zu einer Verpflichtung, diese Anforderungen zu erfüllen. Eine Unterschrift des CEO oder einer anderen Führungskraft bestätigt, dass die Richtlinie den Anforderungen der Organisation entspricht. Die unterzeichnende Führungskraft sollte so hochrangig sein, dass ihre Unterschrift andere Abteilungen zur Einhaltung der Richtlinie veranlasst.]

Anhang

I. Liste der IT-Ressourcen

[Gemäß der Richtlinie zum Asset-Management] sollte die Asset-Liste der Organisation alle Systeme, Software, Firmware und Geräte der Organisation umfassen. Die Asset-Liste kann auch Geräte außerhalb der Kontrolle der Organisation enthalten, die mit dem Netzwerk verbunden sind, beispielsweise BYOD-Geräte, gemietete Geräte mit Zugriff, Geräte von Auftragnehmern usw.

Beispiele für Ressourcen in der Asset-Liste sind unter anderem:

• Netzwerkgeräte
• • Firewalls (sowie installierte Software, Firmware und Sicherheitsfunktionen, die Updates erfordern)
  • Netzwerk-Switches (sowie installierte Software und Firmware)
  • Router (sowie installierte Software und Firmware)
• Server (Websites, Anwendungshosts, Virtualisierungsplattformen usw.) und installiertes Betriebssystem
• Installiertes Betriebssystem, installierte Software, Firmware
• • Arbeitsstationen
  • Tablets
  • Laptops
  • Mobilfunkgeräte
• Internet der Dinge (IoT) sowie installierte Software und Firmware
• • Voice over Internet Protocol (VoIP)
  • Überwachungskameras
  • Mit WLAN verbundene Fernseher
  • WLAN-Drucker
  • Netzwerkdrucker
  • Storage Area Networks (SAN)
  • Sprachgesteuerte Geräte (Amazon Alexa usw.)
  • [Herzmonitore und andere medizinische Geräte]
  • Solaranlagensysteme
  • Türsicherheits-Badge-Lesegeräte
• Betriebstechnologie (OT), vernetzte Infrastruktur sowie installierte Software oder Firmware
• • Mit 5G verbundenes Förderband
  • Vernetzte HLK-Anlagen

Die Asset-Liste sollte Folgendes enthalten:

• Asset-Typ (Server, PC, Software, Router usw.)
• Zugewiesener Geräteverantwortlicher (bei einer gemeinsam genutzten Ressource ist der Leiter der zugehörigen Abteilung de facto der zugewiesene Verantwortliche)
• Version des Kernbetriebssystems, der Firmware oder der Software
  [Hinweis: Die Nachverfolgung und Pflege bestimmter Versionen kann sinnvoll sein, für Organisationen, die ein manuelles Nachverfolgungssystem verwenden, jedoch mit erheblichem Aufwand verbunden sein.]
• Manuelles oder automatisches Update?
• Aktualisierung durch die IT-Abteilung, automatisches Software-Update, ein Drittanbieter-Tool oder einen Drittanbieter-Dienstleister?
• Zuletzt aktualisiert
• Update erfolgreich (J/N)
• Zugehörige Geräte (d. h. bei der Adobe-Acrobat-Software: auf folgendem zugehörigen Gerät installiert: PC4362)

Während die [IT-Abteilung] für die Pflege der Asset-Liste verantwortlich ist, müssen Abteilungsleiter die IT-Abteilung über neu eingesetzte Assets (Geräte, installierte Software usw.) informieren. Geräte oder Software, die ohne Information der IT-Abteilung eingesetzt werden, gelten als nicht autorisierte Geräte und können gesperrt und entfernt werden.

Die [IT-Abteilung] führt [kontinuierlich/monatlich/täglich/vierteljährlich] Scans der IT-Umgebung durch, um zu überprüfen, dass die Asset-Liste aktuell bleibt, und nicht autorisierte Geräte oder Software zu erkennen.

Die aktuelle Asset-Liste ist hier gespeichert:

[Führen Sie die Asset-Datenbank, Excel-Tabelle, Asset-Management-Tool hier auf.
Hinweis: Die Verwendung einer Excel-Tabelle kann dazu führen, dass diese versehentlich oder absichtlich beschädigt oder verändert wird. Eine versionierte Google-Tabelle oder eine in OneDrive oder SharePoint gespeicherte Excel-Datei wären bessere Optionen.

Organisationen sollten eine Richtlinie zum Asset-Management entwickeln und pflegen. Die Entwicklung der Richtlinie und einer beispielhaften Asset-Liste liegt außerhalb des Umfangs dieses Beispieldokuments. BYOD-Geräte sollten nicht in einer Asset-Liste erfasst werden. Die Pflege von BYOD-Geräten sollte mithilfe von Funktionen zur Netzwerkzugriffskontrolle oder Tools durchgesetzt werden, die Geräte auf mindestens akzeptable Sicherheitsprofile prüfen.]