Muster-Vorlage für eine Patch-Management-Richtlinie

So verwenden Sie diese Vorlage:

Kommentare, die das Verständnis und die Verwendung dieser Vorlage für eine Patch-Management-Richtlinie erleichtern sollen, stehen in eckigen Klammern „[…]“. Im gesamten Dokument wird das „Unternehmen“ als [eSecurity Planet] bezeichnet. Wenn Sie diese Vorlage in eine tatsächlich anzuwendende Richtlinie umwandeln, entfernen Sie die Abschnitte in eckigen Klammern und ersetzen Sie „[eSecurity Planet]“ durch „YourCompanyName“.

Diese Richtlinie bezieht sich auf 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 untenstehende Microsoft-Word-Vorlage herunter.

Dieser Artikel wird von Automox gesponsert. Automox bietet automatisiertes Patchen und Konfigurationsmanagement für Windows-, MacOS- und Linux-Geräte sowie Drittanbieteranwendungen wie Chrome, Adobe und Slack. Lesen Sie den

’

Bericht zum Stand der IT-Operations 2023 und erfahren Sie, was

’

funktioniert und was nicht

’

für ITOPs-Teams überall.

Patch-Management-Richtlinie von [eSecurity Planet (oder dem Namen Ihres Unternehmens hier)]

1. Überblick

Anbieter stellen regelmäßig Funktionsupdates bereit, beheben Fehlfunktionen und veröffentlichen Sicherheits-Patches, um die Leistung ihrer Produkte zu verbessern und Sicherheitslücken zu beseitigen. Die zeitnahe Installation dieser Updates schützt vor Bedrohungen, kann die Benutzererfahrung verbessern und die Produktivität der Organisation steigern.

Nicht gepatchte Ressourcen setzen Benutzer, Daten und andere Unternehmensressourcen einem inakzeptablen Risiko aus. Diese Patch-Management-Richtlinie:

• legt Erwartungen, Anforderungen und grundlegende Verfahren für die Wartung der Systeme und Software von [eSecurity Planet] fest
• definiert Berichte zur Überprüfung der Einhaltung dieser Richtlinie
• legt Sanktionen für die Nichteinhaltung dieser Richtlinie fest.

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

Mehr über Patch-Management-Richtlinien erfahren

2. Geltungsbereich

Diese Richtlinie gilt für alle Ressourcen von [eSecurity Planet], die mit dem Netzwerk der Organisation verbunden sind, die Erfüllung des Organisationsauftrags ermöglichen oder Daten der Organisation hosten. Die Organisation führt eine formelle Liste der Ressourcen innerhalb des Geltungsbereichs dieser Richtlinie und verfolgt diese. Sie ist in Anhang I: IT-Ressourcenbestandsliste unserer herunterladbaren Vorlage definiert.

Das Patch-Management ist für Updates auf genaue Listen der vorhandenen Systeme und Software angewiesen. Der Geltungsbereich sollte [gemäß der Richtlinie für das Asset-Management / monatlich / vierteljährlich] überprüft werden, damit alle Assets für das Patchen und Aktualisieren präzise bewertet werden können.

[Dies ist die weitestgehende Version des Geltungsbereichs. Einige Organisationen versuchen nicht, die mit dem Netzwerk verbundenen Geräte ihrer Mitarbeiter zu aktualisieren oder zu überwachen, oder sie ignorieren Geräte des Internets der Dinge (IoT). Das ist zwar riskant, doch manche Organisationen akzeptieren diese Risiken stillschweigend – aus Gründen der Einfachheit oder aufgrund begrenzter Ressourcen (Budget, IT-Personal, Zeit usw.).

Der Geltungsbereich sollte festlegen, was auf Updates und Patches überwacht wird. Wenn die IT-Abteilung nur die Betriebssysteme von Servern und Endgeräten patcht, bearbeiten Sie den Geltungsbereich entsprechend – und akzeptieren Sie die Risiken für die nicht überwachten Systeme.]

3. Patch-Management-Richtlinie und -Verfahren

A. Zuständigkeit für das Patch-Management

[Der Chief Information Officer (CIO) von eSecurity Planet] wird als für das Patch-Management zuständige Stelle benannt. Diese trägt die letztendliche Verantwortung und Befugnis, alle Abschnitte dieser Patch-Management-Richtlinie und der zugehörigen Verfahren zu planen, auszuführen, zu genehmigen oder an interne Ressourcen beziehungsweise Drittanbieter-Tools oder -Dienstleister zu delegieren.

Obwohl die für das Patch-Management zuständige Stelle die letztendliche Verantwortung trägt, wird anerkannt, dass die [IT-Abteilung] die Pläne dieser Stelle zur Einhaltung der Patch-Management-Richtlinie im Allgemeinen umsetzen wird. Die an anderer Stelle in dieser Richtlinie verwendete Bezeichnung IT-Abteilung bezieht sich auf die für das Patch-Management zuständige Stelle, die [IT-Abteilung] und delegierte Vertreter.

Die für das Patch-Management zuständige Stelle überprüft und genehmigt außerdem:

• den Geltungsbereich der Patch-Management-Richtlinie
• die Priorität des Patchens
• das Testen und die Genehmigung von Patches
• jede für die Installation von Patches und Updates erforderliche Wartungsunterbrechung
• alle erforderlichen Risikominderungen oder Ausnahmen
• Berichte zum Patch-Management
• die Durchsetzung

[Dieser Abschnitt legt fest, wer das Budget genehmigen und den Patch-Management-Prozess verwalten muss. Verwenden Sie am besten eine Funktionsbezeichnung, da Personen gelegentlich wechseln und die Richtlinie nicht bei jedem Personalwechsel überarbeitet werden sollte.]

B. Beschaffung von Patches und Updates

Die IT-Abteilung überwacht und scannt kontinuierlich verschiedene Quellen, um Informationen über die Veröffentlichung von Updates und Patches für alle Ressourcen innerhalb des Geltungsbereichs dieser Richtlinie zu erhalten. Zu den Quellen können unter anderem Sicherheits-Mailinglisten, Benachrichtigungen von Anbietern und Websites gehören.

Sobald ein Patch oder Update verfügbar ist, ermittelt und überprüft die IT-Abteilung vor dem Herunterladen des Updates die Gültigkeit der Quelle. Bevorzugt werden Patches direkt vom Quellanbieter bezogen – also von dem Unternehmen oder der Organisation, das beziehungsweise die die Ressource entwickelt hat, für die das Update veröffentlicht wurde – oder von einem Dienstleister, der Updates direkt vom Quellanbieter bezieht.

Patches und Updates aus anderen Quellen müssen vor ihrer Einführung in die Umgebung der Organisation sorgfältig geprüft und getestet werden.

[Dieser Abschnitt soll Wachsamkeit und die zeitnahe Erkennung verfügbarer Updates und Patches gewährleisten. Best Practices empfehlen, bestimmten Personen die Aufgabe zu übertragen, Updates und Patches zu recherchieren, zu finden und die Quelle zu überprüfen.]

C. Patch-Priorität

Mehrere Patches und Updates können gleichzeitig verfügbar werden. Falls erforderlich, bestimmt die IT-Abteilung die Priorität für Patches und Updates und erstellt anhand der folgenden Kriterien eine Rangfolge:

• der Common Vulnerability Scoring System (CVSS)-Bewertung der geschlossenen Sicherheitslücke
• der Risikowert des Assets
• der Wahrscheinlichkeit einer Ausnutzung

Das CVSS weist Sicherheitslücken eine Bewertung 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 Bewertungen geben keinen Aufschluss über die Wahrscheinlichkeit einer Ausnutzung, wohl aber darüber, wie stark ein Angreifer ein System beeinträchtigen kann oder welcher Aufwand dafür erforderlich sein könnte. Die U.S. Cybersecurity and Infrastructure Security Agency (CISA) führt eine Liste der bekanntermaßen ausgenutzten Sicherheitslücken, die zur Prüfung auf aktive Ausnutzung herangezogen werden kann.

[eSecurity Planet] verwendet eine Risikoanalyse, um eine Risikobewertung interner Systeme zu erstellen, die in einem Risikoregister auf einer Skala von 1 (geringe Auswirkung bzw. geringer Wert) bis 10 (höchste Auswirkung bzw. höchster Wert) erfasst und aktualisiert wird. Ebenso muss die IT-Abteilung die aktuelle Umgebung, die aktuelle IT-Architektur und die Art der Sicherheitslücke 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 Addition dieser drei Faktoren ergibt einen Wert zwischen 2 (niedrige Priorität oder keine Maßnahme erforderlich) und 30 (dringende Maßnahme zur Installation des Patches erforderlich).

Bei der Auslagerung an einen Dienstleister oder der Verwendung eines Patch-Tools werden einige Patches automatisch installiert, sodass möglicherweise keine Patch-Priorität erforderlich ist. Eine Patch-Priorität ist für Updates und Patches erforderlich, die:

• das Herunterfahren einer Ressource zu Wartungszwecken erfordern
• mit anderen Patches und Updates in Konflikt stehen
• Probleme mit anderen Systemen oder Geschäftsprozessen verursachen

Die manuelle Patch-Warteschlange kann ältere, weniger dringende Patches enthalten. Neu veröffentlichte Patches sollten veraltete Patches in der Warteschlange ersetzen. Der Ersatz-Patch kann dieselbe Priorität wie der alte Patch erhalten oder nach Ermessen der IT-Abteilung neu priorisiert werden.

[Dieser Abschnitt weist eine Priorität zu, anhand derer bestimmt werden kann, welche Patches im Patch-Management-Prozess zuerst installiert werden sollten. Die Gewichtung der Patch-Priorität nach CVSS ist die gängigste Priorisierungsmethode, und einige Organisationen verwenden ausschließlich diese Methode.

Der Wert für das Unternehmen und die Wahrscheinlichkeit einer Ausnutzung sollten bei der Prioritätsbestimmung ebenfalls berücksichtigt werden. Achten Sie jedoch darauf, dass niemand das Ausnutzungsrisiko und den Wert des Assets aus Bequemlichkeit manipuliert, um sich nicht mit dem Update befassen zu müssen.

Verwaltete Patch-Dienste und -Tools verwenden wahrscheinlich CVSS-Werte, da diese greifbar sind und der Dienst beziehungsweise das Tool im Allgemeinen keinen Einblick in den Wert von Assets für die Organisation hat.

Dieser Abschnitt verweist auf Risikobewertungen und ein Risikoregister. Organisationen jeder Größe können und sollten ein Risikoregister erstellen. Das Risikoregister bewertet den Wert einer Ressource und die Größe der Auswirkungen auf die Organisation, wenn diese Ressource beeinträchtigt, kompromittiert oder unbrauchbar wird. Falls kein Risikoregister vorhanden ist, muss eine Organisation den Wert der Ressource für die Organisation qualitativ schätzen.]

D. Zeitplan für Patches und Updates

Auf Grundlage der Patch-Prioritätsbewertung von 2 bis 30 muss die IT-Abteilung den Patch innerhalb des folgenden Zeitraums installieren:

• 24,0–30: innerhalb von [7] Tagen nach Veröffentlichung des Patches
• 18,0–23,9: innerhalb von [14] Tagen nach Veröffentlichung des Patches
• Sicherheits-Patches unter 18,0: innerhalb von [30] Tagen nach der Veröffentlichung

Nicht sicherheitsrelevante Patches (Upgrades und Fehlerbehebungen) werden nach einem normalen Wartungsplan installiert, wie er in den üblichen Betriebsverfahren für Systemwartung und -support festgelegt ist, jedoch spätestens nach [90] Tagen. Patches und Updates mit niedrigerer Bewertung können nach Ermessen der IT-Abteilung zusammen mit Patches oder Updates höherer Priorität installiert werden.

Beispiel:

• Eine nicht kritische Fehlerbehebung mit der Bewertung 8,4 kann gleichzeitig mit anderen Behebungen von Sicherheitslücken mit den Bewertungen 25,3 und 28,0 installiert werden.
• Ein nicht kritisches Funktionsupgrade für einen Router mit der Bewertung 15,4 kann später installiert werden, da die IT-Abteilung möglicherweise zunächst 50 oder mehr Router manuell aktualisieren muss, um eine Sicherheitslücke mit der Bewertung 13,0 zu beheben, und die Upgrades nicht gleichzeitig durchgeführt werden können.

In der Praxis werden Server und Endgeräte monatlich gepatcht; bei kritischen Sicherheitslücken erfolgt das Patchen beschleunigt, insbesondere wenn eine Angriffsmethode öffentlich bekannt ist. Sicherheitsupdates für alle Systeme müssen innerhalb der vorgeschriebenen Fristen installiert und die Systeme (falls erforderlich) neu gestartet werden.

[Das genaue Bewertungssystem und die Dringlichkeit legt die Organisation fest. Der auf der Priorität basierende Zeitplan sollte eine schnelle Reaktion auf die kritischsten Patches und Updates für die kritischsten Ressourcen gewährleisten. Die Höchstfrist von 90 Tagen für die Installation von Upgrades und Patches sollte verhindern, dass ein System oder eine Software vollständig übersehen oder ignoriert wird oder sich Updates anhäufen.]

E. Richtlinien für das Patchen

Sobald ein Patch beschafft und priorisiert wurde, sollten die folgenden Schritte befolgt werden.

i. Patch-Tests

Bei hochwertigen Ressourcen kann die IT-Abteilung beschließen, den Patch in einer Testumgebung zu testen, um mögliche Beeinträchtigungen des Geschäftsbetriebs oder andere Probleme zu erkennen. Patches, die den Test nicht bestehen, können vom Patch-Prozess ausgeschlossen werden, sofern die IT-Abteilung das Verfahren für Ausnahmen und Risikominderungen befolgt (siehe unten, Abschnitt 3.F).

[Drittanbieter und Patch-Management-Dienste oder -Tools testen Patches in generischen Umgebungen. Bei bestimmten IT-Architekturen oder abhängigen Systemen kann es jedoch zu unbeabsichtigten Folgen kommen.

Durch das Testen von Patches in einer Testumgebung kann die IT-Abteilung solche Probleme in einer Umgebung erkennen, die keine Geschäftsprozesse beeinträchtigt. Nicht alle Organisationen verfügen über die Ressourcen für Patch-Tests, und Patch-Tests für Ressourcen mit geringem Wert sind möglicherweise keine kosteneffiziente Nutzung von Zeit oder Ressourcen.]

ii. Vorbereitung des Patch-Managements

Nicht alle Patches werden erfolgreich oder problemlos installiert. In manchen Fällen kann ein Patch ein Gerät 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 Beginn des Patch-Management-Prozesses umgesetzt wurde.

Mindestens]:

• vor der Installation des Updates eine vollständige Systemsicherung durchgeführt wurde
• vor der Installation des Updates eine vollständige Datensicherung durchgeführt wurde

Für Firmware-Updates kritischer Systeme (Router, Server usw.) muss möglicherweise ein Ersatzsystem bereitstehen, falls das Firmware-Update das ursprüngliche Gerät funktionsunfähig macht.

Bei fehlgeschlagenen Updates versucht die IT-Abteilung, das System oder die Software auf eine frühere Version zurückzusetzen, um die Funktionsfähigkeit wiederherzustellen. Systeme, die nicht zurückgesetzt werden können, müssen zeitnah aus einer Sicherung wiederhergestellt oder ersetzt werden.

Die IT-Abteilung kann mehrfach versuchen, Patches und Updates zu installieren. Für Patches oder Updates, die nicht erfolgreich installiert werden können, muss die IT-Abteilung das nachfolgende Verfahren für Ausnahmen und Risikominderungen befolgen.

[Dieser Abschnitt trägt der Tatsache Rechnung, dass nicht alle Patches wie vorgesehen funktionieren und die IT-Abteilung sich vor der Installation von Patches jeglicher Art darauf vorbereiten muss. Wir empfehlen, auf eine bestehende Richtlinie zur Notfallwiederherstellung zu verweisen, die Sicherungen und Wiederherstellungssysteme detailliert behandeln sollte. Organisationen ohne eine solche Richtlinie können diesen Text löschen und einfach Sicherungen vorschreiben.]

iii. Automatisiertes Patch- und Update-Management

Viele Anbieter ermöglichen automatisierte Patch-Verfahren für ihre einzelnen Anwendungen. Darüber hinaus gibt es zahlreiche Drittanbieter-Tools und Dienstleister, die den Patch-Management-Prozess unterstützen.

Wenn es praktikabel und möglich ist, sollte die IT-Abteilung geeignete Optionen zur Automatisierung des Patch-Management-Prozesses nutzen. Automatisierte Dienste können die potenzielle Belastung der IT-Abteilung verringern und die zeitnahe Installation von Patches in der gesamten IT-Umgebung ohne Verzögerung ermöglichen.

Die IT-Abteilung muss sicherstellen, dass alle Vorbereitungen für das Patch-Management (siehe oben, Abschnitt 3.E.ii) erfolgreich abgeschlossen wurden, bevor automatisierte Prozesse zugelassen werden.

Es wird anerkannt, dass Firmware-, IT-Appliance- (Router usw.) und Softwareanbieter möglicherweise manuelles Patchen und Aktualisieren erfordern. Für das automatisierte Patchen eingesetzte Anbieter und Tools sollten ausdrücklich aufführen, was sie beim Patchen und Aktualisieren abdecken und was nicht. Die Asset-Liste sollte widerspiegeln, welche Elemente manuelle Updates erfordern.

iv. Manuelles Patch-Management

Einige Patches und Updates (insbesondere Firmware) erfordern ein manuelles Verfahren. Bei Updates, die Geschäftsprozesse nicht beeinträchtigen, kann die IT-Abteilung den Patch nach eigenem Ermessen innerhalb des zugewiesenen Zeitraums installieren, abhängig von der Dringlichkeit des Patches beziehungsweise Updates.

Einige Patches erfordern möglicherweise das Herunterfahren kritischer Geschäftssysteme. Um übermäßige Beeinträchtigungen zu vermeiden, müssen diese Wartungsfenster im Voraus geplant und von der für das Patch-Management zuständigen Stelle genehmigt werden, vorzugsweise mit Zustimmung der zuständigen betroffenen Geschäftsverantwortlichen.

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

• Details zu den betroffenen Systemen
• Details zur Dringlichkeit des Patches und zum Risiko
• bevorzugtes Wartungsfenster und mindestens ein alternatives Wartungsfenster
• Details zu den Zurücksetzungsverfahren für den Fall, dass der Patch fehlschlägt

Bei Notfall-Patches, die in Abwesenheit der für das Patch-Management zuständigen Stelle erforderlich sind, kann die nächste verfügbare Führungskraft im Organigramm das Wartungsfenster genehmigen.

Muss ein Notfall-Patch installiert werden und kann oder will keine Führungskraft den Patch angesichts seiner Dringlichkeit innerhalb eines angemessenen Zeitraums genehmigen, darf die IT-Abteilung ihre Bemühungen zur Einholung der Genehmigung dokumentieren und den Patch beziehungsweise das Update ohne formelle Genehmigung installieren. Es wird anerkannt, dass Notfall-Patches und Wartungsunterbrechungen gelegentlich erforderlich sein können; die IT-Abteilung sollte die Beeinträchtigungen jedoch stets minimieren.

[Dieser formell formulierte Teil des Patch-Prozesses verpflichtet die für die Implementierung des Patches Verantwortlichen, ein Wartungsfenster zu beantragen, wenn das Software-Update zu Ausfallzeiten für Benutzer oder aktiv genutzte Systeme führt.]

v. Überprüfung und Testen von Patches

Nach Abschluss des Patch- und Update-Prozesses sollte die IT-Abteilung überprüfen, ob die Patches erfolgreich installiert wurden, oder fehlgeschlagene Patches melden und beheben. Außerdem sollte sie überprüfen, ob die durch den Patch behobenen Sicherheitslücken tatsächlich durch den Patch entschärft oder beseitigt wurden.

Sicherheitslücken, die weiterhin offen sind, müssen gemäß den Anforderungen für Ausnahmen und Risikominderungen behandelt werden (siehe unten, Abschnitt 3.F).

F. Ausnahmen und Risikominderungen

Im Patch- und Update-Prozess können Ausnahmen auftreten. Diese Ausnahmen werden wie folgt kategorisiert:

1. Fehlgeschlagene Patches: Patches und Updates, die nicht ordnungsgemäß installiert werden können
2. Beeinträchtigende Patches: Patches und Updates, deren Installation zu einer inakzeptablen Beeinträchtigung des Geschäftsbetriebs führen würde
3. Nicht benötigte Patches: Nicht sicherheitsrelevante Patches oder Updates, die nicht benötigte oder unerwünschte Funktionen aktivieren oder beheben
4. Ungepatchte Sicherheitslücke: Einige Assets können auch Sicherheitslücken aufweisen, die aus verschiedenen Gründen von den Anbietern ungepatcht bleiben (Ende des Produktlebenszyklus, Anbieter nicht mehr geschäftstätig usw.)

Alle Kategorien müssen in einer Ausnahmenliste erfasst werden. Nicht benötigte Patches werden lediglich erfasst und [vierteljährlich] überprüft, um sicherzustellen, dass sie weiterhin nicht benötigt werden.

Fehlgeschlagene, beeinträchtigende und ungepatchte Sicherheitslücken erfordern eine Risikominderung. Die IT-Abteilung entwickelt geeignete Maßnahmen zur Risikominderung und schlägt diese vor, um das Risiko und den potenziellen Schaden der ungepatchten Sicherheitslücke für die Organisation zu begrenzen. Jeder Plan zur Risikominderung muss von der für das Patch-Management zuständigen Stelle genehmigt werden und Folgendes enthalten:

• Details zu den betroffenen Systemen
• Details zur Dringlichkeit der ungepatchten Sicherheitslücke
• Details zur Risikominderung und dazu, wie sie die ungepatchte Sicherheitslücke behebt
• Bevorzugtes Bereitstellungsfenster und mindestens ein alternatives Fenster. Es ist anzugeben, ob Geschäftssysteme zur Umsetzung der Risikominderung heruntergefahren werden müssen.

Die Liste der Risikominderungsmaßnahmen und Ausnahmen wird [vierteljährlich] überprüft, um festzustellen:

• Ob Patches veröffentlicht wurden, sodass die Risikominderung beendet werden kann
• Ob Assets ausgemustert oder ersetzt werden sollten oder wurden, sodass die Risikominderung beendet werden kann
• Ob Risikominderungsmaßnahmen in irgendeiner Weise verbessert werden können

Die für das Patch-Management zuständige Stelle muss die [vierteljährliche] Überprüfung der Liste der Risikominderungsmaßnahmen und Ausnahmen genehmigen.

[Wenn ein Patch nicht angewendet werden kann, muss stattdessen ein anderer Ansatz zur Risikominderung entwickelt und schriftlich genehmigt werden. Die meisten Organisationen können eine vierteljährliche Überprüfung wie in diesem Dokument beschrieben durchführen. Kleineren Organisationen stehen möglicherweise nur Ressourcen für halbjährliche oder jährliche Überprüfungen zur Verfügung, während größere Organisationen möglicherweise aggressiver vorgehen und monatliche oder wöchentliche Überprüfungen wünschen.]

G. Berichte zu Patches und Updates

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

• Datum des letzten Asset-Scans und Anzahl der erfassten Assets
• Prozentsatz der Systeme, die durch automatisiertes Patch-Management abgedeckt sind
• Prozentsatz der Systeme, die auf das Patchen überwacht werden
• Anzahl der Patches, die Anbieter im betreffenden Zeitraum veröffentlicht oder die von der Organisation beschafft wurden
• Anzahl der Patches im betreffenden Zeitraum, die Qualitätsprüfungen nicht bestanden haben
• Anzahl der Patches, die nicht ordnungsgemäß installiert werden konnten
• Anzahl der Patches, die zu Incident-Tickets geführt haben
• Anzahl erfolgreicher Patch-Implementierungen gegenüber der Anzahl nicht erfolgreicher Patches
• Durchschnittliche Zeit zwischen der Verfügbarkeit und der Bereitstellung eines Patches, aufgeschlüsselt nach CVSS-Bewertung sowie nach Risiko- oder Wertkategorie des Assets
• Anzahl der in den Ausnahmebericht aufgenommenen Ausnahmen
• Gesamtzahl der im Ausnahmebericht enthaltenen Ausnahmen

[Die IT-Abteilung muss Berichte erstellen, damit die Organisation überprüfen kann, ob die Patch-Management-Verfahren ordnungsgemäß befolgt und Patches und Updates zeitnah durchgeführt werden. Regelmäßige Berichte können den Bedarf an speziellen Compliance-Berichten beseitigen.

Die Daten im Bericht sollten außerdem dazu verwendet werden, den Patch-Management-Prozess zu verbessern. So kann beispielsweise anhand der Anzahl der Patches, die zu Tickets führen, festgestellt werden, ob zusätzliche Patch-Tests erforderlich sind oder die aktuellen Tests verbessert werden müssen.

Reifere Organisationen können außerdem regelmäßige Tests auf Sicherheitslücken und Penetrationstests nutzen, um zu überprüfen, ob Patches ordnungsgemäß installiert wurden. Diese Testberichte können den regelmäßigen Berichten zu Patches und Updates hinzugefügt werden.]

4. Audit-Kontrollen und Management

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

• Genehmigte Anträge auf Wartungsfenster
• Genehmigte Ausnahmenlisten
• System-Updates und Patch-Protokolle für alle wichtigen System- und Dienstprogrammkategorien
• Protokolle sollten die System-ID, das Patch-Datum, den Patch-Status, die Ausnahme und den Grund für die Ausnahme enthalten
• Nachgewiesene Infrastruktur zur Unterstützung des unternehmensweiten Patch-Managements über Systeme, Anwendungen und Geräte hinweg
• Patch-Management-Berichte

[Dieser Abschnitt berücksichtigt den gelegentlichen Bedarf von Führungskräften und Auditoren an Berichten zu den Patch-Management-Prozessen außerhalb des regulären Zeitplans. Zur Überprüfung der Patch-Management-Berichte können einige Auditoren außerdem Systemprotokolle verlangen, die erfolgreiche System- oder Software-Updates bestätigen.]

5. Durchsetzung

Mitarbeiter, bei denen ein vorsätzlicher Verstoß gegen diese Richtlinie festgestellt wird, können disziplinarischen Maßnahmen bis hin zur Kündigung unterliegen. Die Arbeitsleistung der für die Umsetzung dieser Richtlinie verantwortlichen Mitarbeiter der IT-Abteilung wird teilweise oder vollständig danach beurteilt, inwieweit sie die Anforderungen dieser Richtlinie erfüllen.

Die regelmäßige Unfähigkeit der IT-Abteilung, die Anforderungen dieser Patch-Management-Richtlinie 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 einen Grund für die sofortige Kündigung oder disziplinarische Maßnahmen darstellen.

Geräte mit Betriebssystemen, Software und Firmware, die die Patch-Anforderungen nicht erfüllen, sollten vom Zugriff auf Ressourcen ausgeschlossen werden, die hinsichtlich ihres Werts oder ihrer Funktion kritisch sind, und auf die DMZ oder getrennte Netzwerkabschnitte beschränkt werden.

[Damit Richtlinien wirksam sind, sollte es Sanktionen für die Nichteinhaltung geben. Obwohl dies hier nur kurz erwähnt wird, sollte eine Richtlinie zur Netzwerksicherheit ausdrücklich festlegen, auf welche Ressourcen nicht konforme Geräte innerhalb der Organisation zugreifen dürfen und wie dieser Zugriff geregelt wird.

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 mit unangemessenen Erwartungen werden wahrscheinlich eine hohe Fluktuation in der IT-Abteilung und Schwierigkeiten bei der Bindung erfahrener oder qualifizierter Mitarbeiter erleben.]

6. Verteilung

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

[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 förmlich bestätigen.]

7. Richtlinienversion

Version 1.0

Genehmigungsdatum: 15.11.2022

Beschreibung: Erster Entwurf der Richtlinie

[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]

[Mit der Unterschrift bestätigt die für das Patch-Management zuständige Stelle die Anforderungen der Richtlinie und verpflichtet sich de facto, diese Anforderungen zu erfüllen. Mit der Unterschrift bestätigt der CEO oder eine andere Führungskraft, dass die Richtlinie den Anforderungen der Organisation entspricht. Die unterzeichnende Führungskraft sollte eine ausreichend hohe Position innehaben, damit ihre Unterschrift andere Abteilungen zur Einhaltung der Richtlinie bewegt.]

Anhang

I. Liste der IT-Ressourcen und -Assets

[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, geleaste Geräte mit Zugriff, Geräte von Auftragnehmern usw.

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

• Netzwerkgeräte
• • Firewalls (einschließlich installierter Software, Firmware und Sicherheitsfunktionen, die Updates erfordern)
  • Netzwerk-Switches (einschließlich installierter Software und Firmware)
  • Router (einschließlich installierter Software und Firmware)
• Server (Websites, Anwendungs-Hosts, Virtualisierungsplattformen usw.) und installiertes Betriebssystem
• Installiertes Betriebssystem, installierte Software, Firmware)
• • Arbeitsstationen
  • Tablets
  • Laptops
  • Mobilgeräte
• Internet-of-Things-Geräte (IoT) sowie installierte Software und Firmware
• • Voice-over-IP-Telefone (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]
  • Solarpanel-Systeme
  • Türsicherheitsausweis-Lesegeräte
• Betriebstechnik (OT), vernetzte Infrastruktur sowie installierte Software oder Firmware
• • Mit 5G verbundene Förderbänder
  • Vernetzte HLK-Anlagen

Die Asset-Liste sollte Folgendes enthalten:

• Asset-Typ (Server, PC, Software, Router usw.)
• Zugewiesener Eigentümer des Geräts (bei einer gemeinsam genutzten Ressource ist die Leitung der zuständigen Abteilung der de facto zugewiesene Eigentümer)
• Version des zentralen Betriebssystems, der Firmware oder der Software
  [Hinweis: Die Erfassung und Pflege bestimmter Versionen kann nützlich sein, für Organisationen mit einem manuellen Erfassungssystem jedoch einen hohen Aufwand bedeuten.]
• Manuelles oder automatisches Update?
• Aktualisierung durch die IT-Abteilung, ein automatisches Software-Update, ein Drittanbieter-Tool oder einen externen Dienstleister?
• Zuletzt aktualisiert
• Update erfolgreich (J/N)
• Zugehörige Geräte (z. B. bei Adobe-Acrobat-Software: installiert auf dem zugehörigen Gerät: 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 [kontinuierliche/monatliche/tägliche/vierteljährliche] Scans der IT-Umgebung durch, um zu überprüfen, ob 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, die Excel-Tabelle und das Asset-Management-Tool hier auf.
Hinweis: Die Verwendung einer Excel-Tabelle kann sie anfällig für versehentliche oder vorsätzliche Beschädigungen oder Änderungen machen. 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 Beispiel-Asset-Liste geht über den Umfang dieses Beispieldokuments hinaus.

BYOD-Geräte sollten nicht in einer Asset-Liste erfasst werden. Die Pflege von BYOD-Geräten sollte mithilfe von Netzwerkzugangskontrolle-Funktionen oder Tools durchgesetzt werden, die Geräte auf minimal akzeptierte Sicherheitsprofile überprüfen.]