Jedes Unternehmen führt Patches durch. Nur wenige tun dies konsequent. In der Kluft zwischen diesen beiden Realitäten kommt es zu Sicherheitsverletzungen, scheitern Audits und sehen sich IT-Teams gezwungen, hastig zu erklären, warum eine bekannte Schwachstelle monatelang unbeachtet blieb.
Eine Richtlinie zum Patch-Management ist ein dokumentiertes Rahmenwerk, das festlegt, wie ein Unternehmen Software-Updates identifiziert, priorisiert, testet und bereitstellt, um Sicherheitslücken zu verringern, die Einhaltung gesetzlicher Vorschriften zu unterstützen und Systemausfälle zu verhindern. Eine solide Richtlinie geht auf aktuelle Bedrohungen ein und versetzt Ihr Unternehmen in die Lage, sich anzupassen, wenn Ihre IT-Umgebung immer komplexer wird.
Ohne ein solches System wird das Patchen zu einem reaktiven Durcheinander – uneinheitlich über die Teams hinweg, schwer zu überprüfen und mit langsamer Reaktion, wenn eine kritische Sicherheitslücke auftritt. Eine Richtlinie zum Patch-Management macht den Unterschied zwischen der Hoffnung, dass Ihr Unternehmen abgesichert ist, und der Gewissheit, dass dies tatsächlich der Fall ist.
Dieser Leitfaden führt Sie durch die fünf Schritte zur Erstellung einer Richtlinie, erläutert, welche Inhalte das Dokument selbst enthalten sollte, und zeigt auf, wie Sie Ihren Ansatz an Compliance-Rahmenwerke wie ISO 27001 und NIST anpassen können.
Was ist eine Richtlinie zum Patch-Management?
Eine Richtlinie zum Patch-Management ist eine Sammlung dokumentierter Leitlinien und Verfahren, die festlegen, wie ein Unternehmen Software-Updates in seiner gesamten IT-Umgebung identifiziert, beschafft, testet und bereitstellt. Während sich das Patch-Management unter ( ) auf den praktischen Prozess der Installation von Updates bezieht, stellt die Richtlinie unter ( ) das Governance-Rahmenwerk dar, das festlegt, wie der Patch-Management-Prozess unter ( ) abläuft.
Stellen Sie es sich einmal so vor: Das Patch-Management für „ “ ist genau das, womit sich Ihr Team beschäftigt. Die Richtlinie „ “ ( ) ist das Regelwerk, das sicherstellt, dass dies einheitlich, verantwortungsbewusst und im Einklang mit der Risikotoleranz Ihrer Organisation erfolgt.
Eine umfassende Richtlinie deckt in der Regel Betriebssysteme, Anwendungen, Firmware und vernetzte Geräte in lokalen, Cloud- und Hybridumgebungen ab. Außerdem wird darin festgelegt, wer für die einzelnen Phasen des Patch-Lebenszyklus verantwortlich ist, von der Identifizierung bis zur Überprüfung.
Die Richtlinie selbst ersetzt weder Ihre Patch-Tools noch Ihre Arbeitsabläufe. Es bietet die Struktur und die Verantwortlichkeiten, die dafür sorgen, dass das Patchen in großem Maßstab effektiv ist.
In vielen Organisationen ist die Richtlinie zum Patch-Management formell in das übergeordnete Rahmenwerk für das Risikomanagement und die Sicherheitsrichtlinien integriert, wodurch sichergestellt wird, dass Patch-Verpflichtungen innerhalb der Organisation denselben Stellenwert erhalten wie Anforderungen an die Zugriffskontrolle, die Reaktion auf Vorfälle und den Datenschutz.
In der Definition wird festgelegt, worin die Richtlinie besteht. Im Folgenden wird erläutert, warum dies von Bedeutung ist.
Warum Ihr Unternehmen eine Richtlinie zum Patch-Management benötigt
Eine wirksame Richtlinie zum Patch-Management ist ein Eckpfeiler der modernen Cybersicherheit und des IT-Betriebs. Ohne eine formelle Richtlinie sind die Maßnahmen zur Installation von Patches in den verschiedenen IT-Umgebungen in der Regel uneinheitlich. Manche Teams reagieren schnell; andere hingegen nicht. Manche Systeme finden Beachtung; andere geraten in Vergessenheit. Die Folge ist ein uneinheitliches Sicherheitsniveau und ein potenzielles Problem hinsichtlich der Einhaltung von Vorschriften.
Eine schriftlich festgelegte Richtlinie beugt Uneinheitlichkeit vor, indem sie Struktur, Verantwortlichkeit und klare Erwartungen vorgibt:
- Verringerung von Sicherheitsrisiken: Systeme ohne Sicherheitspatches gehören nach wie vor zu den häufigsten Angriffspunkten für Cyberangriffe, darunter auch Ransomware-Kampagnen, die gezielt auf bekannte, ungepatchte Sicherheitslücken abzielen. Eine Richtlinie hilft Organisationen dabei, Sicherheitslücken einheitlich und zeitnah zu beheben und so das Risiko eines Sicherheitsvorfalls zu verringern.
- Compliance-Anforderungen: Vorschriften wie die DSGVO, HIPAA und PCI-DSS verpflichten Unternehmen dazu, sichere Systeme zu unterhalten, wozu auch die rechtzeitige Installation von Patches gehört. Eine Richtlinie liefert die Unterlagen, die Wirtschaftsprüfer erwarten.
- Betriebliche Konsistenz: Durch die Standardisierung der Vorgehensweise und des Zeitpunkts der Patch-Installation werden Ad-hoc-Updates vermieden, die zu unerwarteten Ausfallzeiten führen können.
- Verantwortlichkeiten: Die Richtlinie legt fest, wer für die einzelnen Phasen des Patch-Lebenszyklus verantwortlich ist, wodurch Unklarheiten vermieden werden und Teams dabei unterstützt werden, keine Schritte zu übersehen.
So bauen Sie eines.
So erstellen Sie eine Richtlinie zum Patch-Management in 5 Schritten
Die Erstellung einer Richtlinie zum Patch-Management bedeutet, bewährte Sicherheitsverfahren in ein dokumentiertes, durchsetzbares Rahmenwerk umzusetzen. Die folgenden fünf Schritte führen Sie durch die Erstellung einer Richtlinie, die auf das spezifische Umfeld Ihrer Organisation zugeschnitten ist.
1. Festlegung des Geltungsbereichs und der Ziele der Richtlinie
Legen Sie zunächst fest, welche Vermögenswerte durch die Police abgedeckt sind. Beziehen Sie alle Systeme, Anwendungen, Betriebssysteme und Gerätetypen in allen Umgebungen ein: vor Ort, in der Cloud und in Hybridumgebungen. Bitte beachten Sie auch die Drittanbieter-Software „ “ unter. Dies ist eine häufige Ursache für Sicherheitslücken.
Ziele sind am effektivsten, wenn sie konkret und messbar sind. Beispielsweise: „Reduzieren Sie die Gefährdung durch kritische Sicherheitslücken innerhalb von 48 Stunden nach Veröffentlichung des Patches“ oder „Erreichen Sie eine Patch-Compliance von 95 Prozent auf allen Produktionssystemen innerhalb der SLA-Fenster.“
2. Festlegung von Rollen und Zuständigkeiten
Legen Sie eindeutig fest, wer für die einzelnen Phasen des Patch-Management-Lebenszyklus verantwortlich ist, einschließlich der technischen Teams und der geschäftlichen Entscheidungsträger, die möglicherweise Bereitstellungen genehmigen müssen, die ihre Systeme betreffen. Ohne klare Zuständigkeit kommen die Patches nicht voran. Es gibt immer jemanden, der davon ausgeht, dass sich jemand anderes darum kümmert.
| Rolle | Verantwortung |
|---|---|
| IT-Betrieb | Bereitstellung und Überprüfung von Patches |
| Sicherheitsteam | Ermittlung und Priorisierung von Schwachstellen |
| Anwendungsverantwortliche | Prüfung und Zulassung ihrer Systeme |
| Führungskraft als Förderer | Überwachung, Ressourcenzuweisung und Eskalation |
Eine klare Definition dieser Rollen stellt sicher, dass die IT-Mitarbeiter auf allen Ebenen ihre Verantwortlichkeiten innerhalb des Patch-Lebenszyklus verstehen und bei zeitkritischen Bereitstellungen handeln können, ohne auf Ad-hoc-Anweisungen warten zu müssen.
3. Legen Sie risikobasierte Zeitpläne für die Installation von Patches sowie SLAs fest
Ordnen Sie die Patches nach Schweregrad und Auswirkungen auf den Geschäftsbetrieb ein und legen Sie anschließend Zielfristen für die Behebung fest. Ein gängiger Ansatz:
| Schweregrad des Patches | Beispiel für einen Trigger | Typische SLA |
|---|---|---|
| Kritisch | Aktiver Exploit im Umlauf | 24-48 Stunden |
| Hoch | Bekannte Sicherheitslücke, kein aktiver Exploit | 7 Tage |
| Mittel | Mäßiges Risiko, begrenztes Engagement | 14-30 Tage |
| Niedrig | Kleinere Fehlerbehebung | Nächstes Wartungsfenster |
SLAs dienen als Leitlinien, nicht als absolute Vorgaben. Wirksame Richtlinien ermöglichen eine dynamische Anpassung, wenn sich die Risiken in der Praxis ändern, insbesondere bei hochriskanten Sicherheitslücken, bei denen die Ausnutzungsaktivitäten zunehmen oder die Gefährdung des Systems unerwartet zugenommen hat.
4. Verfahren zur Prüfung und Bereitstellung von Dokumenten
Alle Patches müssen in einer speziellen Testumgebung getestet werden, bevor sie auf die Produktionssysteme übertragen werden. Diese Patch-Tests dienen dazu, die Kompatibilität mit bestehenden Softwarekonfigurationen zu prüfen und das Risiko zu verringern, dass ein Patch Betriebsstörungen oder unerwartete Konflikte mit abhängigen Systemen verursacht.
Legen Sie vor Beginn jeder Bereitstellung verbindliche Sicherungsprotokolle fest und dokumentieren Sie ein klares Rollback-Verfahren, damit jeder Patch, der zu unerwarteter Systeminstabilität führt, schnell und mit minimalen Beeinträchtigungen rückgängig gemacht werden kann. Dokumentieren Sie stufenweise oder ringförmige Bereitstellungsverfahren, bei denen ein Patch zunächst auf einer kleinen Gruppe von Systemen eingeführt und anschließend schrittweise ausgeweitet wird.
Ringbasierte Bereitstellungs n können dazu beitragen, Probleme zu erkennen, bevor diese zu weitreichenden Störungen führen. In der Richtlinie sollten zudem Benachrichtigungspflichten festgelegt werden, in denen genau angegeben wird, wann und wie betroffene Teams und Endnutzer vor geplanten Patch-Bereitstellungen informiert werden.
5. Schaffung von Verfahren zur Ausnahmebehandlung und Überprüfung
Nicht alle Systeme können sofort mit einem Patch versehen werden. Alte Software, kritische Systeme mit betrieblichen Einschränkungen oder komplexe Anwendungsabhängigkeiten machen eine sofortige Installation von Patches mitunter unmöglich.
Die Richtlinie sieht ein formelles Verfahren für die Beantragung, Genehmigung und Nachverfolgung von Ausnahmen vor. Für jedes System, bei dem die Installation eines Patches aufgeschoben wird, werden Ausgleichsmaßnahmen (wie beispielsweise Netzwerksegmentierung oder eine verstärkte Überwachung) dokumentiert. Schließlich wird die Richtlinie selbst regelmäßig überprüft – in der Regel einmal jährlich oder nach einem schwerwiegenden Sicherheitsvorfall –, um sicherzustellen, dass sie weiterhin relevant ist.
Durch die Befolgung des fünfstufigen Prozesses – Festlegung des Umfangs, Zuweisung von Rollen, Festlegung von Zeitplänen, Dokumentation von Abläufen und Umgang mit Ausnahmen – kann Ihr Unternehmen von einem reaktiven, uneinheitlichen Ansatz zu einem proaktiven, geregelten Vorgehen übergehen. Die nächste Herausforderung besteht darin, diese Struktur in einem Richtlinien-Dokument festzuhalten, das Ihre Teams tatsächlich nutzen können.
Was Ihr Dokument zur Patch-Management-Richtlinie enthalten sollte
Ein gut strukturiertes Grundsatzdokument dient sowohl als Rahmen für die Unternehmensführung als auch als operative Leitlinie. Hier sind die Abschnitte, die aufgenommen werden sollen:
- Geltungsbereich und Anwendbarkeit: Welche Ressourcen, Umgebungen, Betriebssysteme und Teams von dieser Richtlinie abgedeckt werden.
- Rollen und Verantwortlichkeiten: Klare Zuständigkeiten für die Überwachung, das Testen, die Freigabe, die Bereitstellung und die Überprüfung von Patches.
- Kriterien zur Einstufung von Patches: Das offizielle System zur Einstufung von Patches nach Risikostufe und geschäftlichen Auswirkungen.
- Anforderungen an Tests und Validierung: Vorgaben für Tests außerhalb der Produktionsumgebung und Erfolgskriterien für die Bereitstellung in der Produktionsumgebung.
- Bereitstellungszeitpläne und Wartungsfenster: Genehmigte Zeitrahmen für Produktivbereitstellungen, Kommunikationsanforderungen sowie die rechtzeitige Benachrichtigung von Endnutzern, die möglicherweise von Systemneustarts oder vorübergehenden Dienstunterbrechungen betroffen sind.
- Abstimmung im Rahmen des Änderungsmanagements: Die Bereitstellung von Patches, die sich auf Produktionssysteme auswirken, sollte über den Änderungsmanagementprozess Ihres Unternehmens koordiniert werden, um sicherzustellen, dass vor der Umsetzung der Änderungen die erforderlichen Genehmigungen eingeholt, die entsprechenden Unterlagen erstellt und die Beteiligten informiert werden.
- Verfahren zur Notfall-Patch-Installation: Ein beschleunigtes Verfahren für kritische Patches zur Behebung von Zero-Day-Sicherheitslücken oder aktiven Exploits.
- Verfahren für Ausnahmen und Aufschübe: Das formelle Verfahren zur Beantragung, Genehmigung und Nachverfolgung von Ausnahmen, einschließlich kompensierender Kontrollmaßnahmen.
- Berichterstattung und Compliance-Dokumentation: Welche Aufzeichnungen sind für Prüfpfade erforderlich, einschließlich Berichten zum Patch-Status und Ausnahmeprotokollen?
- Häufigkeit der Richtlinienüberprüfung: Wie oft die Richtlinie überprüft und aktualisiert wird.
Jeder Abschnitt ist konkret genug, um als Leitfaden für das Handeln zu dienen, und zugleich flexibel genug, um den Gegebenheiten Ihres Umfelds gerecht zu werden. Für Unternehmen, die ganz von vorne beginnen, kann es hilfreich sein, zunächst eine Vorlage für eine Patch-Management-Richtlinie zu verwenden, in der diese Abschnitte bereits vordefiniert sind, und diese anschließend an ihren spezifischen Bestandsbestand, ihre Risikotoleranz und ihre Compliance-Verpflichtungen anzupassen.
Über das Dokument selbst hinaus tragen bestimmte operative Vorgehensweisen dazu bei, dass Ihre Richtlinie auch tatsächlich funktioniert.
Bewährte Vorgehensweisen für Richtlinien zur Software-Patch-Verwaltung
Eine gut formulierte Richtlinie ist nur dann wirksam, wenn sie erfolgreich umgesetzt werden kann. Die folgenden Vorgehensweisen tragen dazu bei, die Kluft zwischen Strategie und Umsetzung zu überbrücken.
Automatisierung der Erkennung und Bereitstellung von Patches
Die Automatisierung reduziert den manuellen Aufwand, minimiert menschliche Fehler und gewährleistet eine einheitliche Durchsetzung der Richtlinien. Moderne Tools für das Patch-Management können automatisch nach fehlenden Patches suchen, diese anhand von Richtlinien priorisieren und einen einheitlichen Patch-Zeitplan ohne manuellen Eingriff durchsetzen.
Integration der Patch-Verwaltung in das Schwachstellenmanagement
Das Installieren von Patches ist eine zentrale Abhilfemaßnahme im Rahmen eines umfassenderen Programms zur Schwachstellenverwaltung unter dem Begriff „ “. Ihre Richtlinien zum Patch-Management sollten eng in Ihre Arbeitsabläufe zur Priorisierung von Sicherheitslücken eingebunden sein. Durch die Integration wird sichergestellt, dass Patches auf der Grundlage des tatsächlichen Risikos, das eine Sicherheitslücke für Ihr Unternehmen darstellt, und nicht nur anhand einer allgemeinen Schweregradbewertung des Anbieters installiert werden.
Nutzen Sie schrittweise Einführungen, um Risiken zu minimieren
Die gleichzeitige Bereitstellung eines Patches im gesamten Unternehmen ist mit Risiken verbunden. Ein besserer Ansatz: ringförmige oder stufenweise Einführung. Beginnen Sie mit einer kleinen Gruppe von Systemen, die nur geringe Auswirkungen haben, überwachen Sie diese auf mögliche Probleme und erweitern Sie den Umfang dann schrittweise. Durch schrittweise Einführungen lassen sich potenzielle Probleme erkennen, bevor sie zu einem großflächigen Ausfall führen.
Führen Sie ein genaues Bestandsverzeichnis der Vermögenswerte
Man kann nichts beheben, von dem man nicht weiß, dass es vorhanden ist. Ein vollständiges, kontinuierlich aktualisiertes Bestandsverzeichnis der „ “-Ressourcen bildet die Grundlage jedes effektiven Patch-Management-Programms. Ihre Richtlinie stützt sich auf eine genaue Bestandsaufnahme, um ihren Geltungsbereich festzulegen und die Einhaltung der Vorschriften zu überprüfen.
Führen Sie regelmäßige Prüfungen durch
Überprüfen Sie Ihre Systeme regelmäßig, um sicherzustellen, dass Patches korrekt installiert wurden und dass alle Endgeräte den Richtlinien entsprechen. Audits helfen dabei, Lücken in Ihren Prozessen, übersehene Systeme ohne Sicherheitspatches sowie fehlgeschlagene Bereitstellungen zu identifizieren, die behoben werden müssen.
Für viele Unternehmen ist das Patch-Management nicht nur eine bewährte Sicherheitsmaßnahme. Es handelt sich um eine Anforderung im Rahmen der „ “-Vorschriften ( ), die dokumentiert, durchgesetzt und überprüfbar sein muss.
Abstimmung Ihrer Richtlinien auf Compliance-Rahmenwerke
Zahlreiche regulatorische Rahmenbedingungen und Branchenstandards schreiben formelle Verfahren zum Patch-Management vor oder empfehlen diese nachdrücklich.
Anforderungen der ISO 27001 an Richtlinien zum Patch-Management
Die Norm ISO 27001 für das Informationssicherheitsmanagement schreibt vor, dass Organisationen Kontrollmaßnahmen für das Management technischer Schwachstellen umsetzen müssen. Eine dokumentierte und konsequent umgesetzte Richtlinie zum Patch-Management ist ein zentraler Bestandteil zur Gewährleistung der Übereinstimmung mit den Anforderungen der ISO 27001 und für jede Organisation, die eine Zertifizierung anstrebt, von entscheidender Bedeutung.
NIST-Leitlinien zum Patch-Management
Das National Institute of Standards and Technology (NIST) bietet in der Sonderveröffentlichung 800-40 „ : Leitfaden zum Patch-Management in Unternehmen“ () umfassende Leitlinien. Die Anpassung Ihrer Richtlinien an die NIST-Richtlinien „ “ ( ) gilt sowohl für Bundesbehörden als auch für Organisationen der Privatwirtschaft als allgemein anerkannte bewährte Vorgehensweise.
Überlegungen zum Patchen im Hinblick auf PCI DSS, HIPAA und DSGVO
Regulierungsrahmen wie PCI DSS, HIPAA und DSGVO verlangen von Unternehmen, sensible Daten zu schützen, indem sie bekannte Sicherheitslücken beheben. So schreibt beispielsweise der PCI DSS ausdrücklich vor, dass kritische Sicherheitspatches für „ “ innerhalb eines Monats nach ihrer Veröffentlichung installiert werden müssen. Eine formelle Richtlinie zum Patch-Management und die daraus resultierende Dokumentation können die Bemühungen zur Einhaltung von Vorschriften im Rahmen eines Audits unterstützen.
| Rahmenwerk | Anforderungen an die Fehlerbehebung |
|---|---|
| ISO 27001 | Technische Kontrollmaßnahmen zum Schwachstellenmanagement |
| NIST SP 800-40 | Bewährte Vorgehensweisen für den Lebenszyklus von Patches |
| PCI DSS | Kritische Patches innerhalb von 30 Tagen |
| HIPAA | Rechtzeitige Behebung von Systemschwachstellen |
| GDPR | Geeignete Sicherheitsmaßnahmen, einschließlich der Installation von Patches |
Eine Richtlinie, die auf dem Papier die Compliance-Anforderungen erfüllt, muss in der Praxis noch umgesetzt werden – und genau hier spielen die entsprechenden Tools eine entscheidende Rolle.
Tools und Automatisierung zur Durchsetzung von Richtlinien
Eine Richtlinie zum Patch-Management ist nur so gut wie Ihre Fähigkeit, sie durchzusetzen. Auf Unternehmensebene erfordert die Durchsetzung von Richtlinien eine Patch-Management-Software, die einen kontinuierlichen Überblick über den Status der Endgeräte bietet und eine konsistente Durchsetzung der Richtlinien unterstützt, wenn sich Risiken und Rahmenbedingungen ändern.
Funktionen einer Patch-Management-Plattform
Effektive Plattformen bieten in Echtzeit einen Überblick über den Patch-Status in der gesamten Umgebung und unterstützen eine richtliniengesteuerte Automatisierung, um Risiken auf kontrollierte und wiederholbare Weise zu beheben. Das Tool sollte die wichtigsten Betriebssysteme in Ihrer Umgebung unterstützen, darunter Microsoft Windows, Macs sowie Linux, und im Rahmen der automatisierten Durchsetzung von Richtlinien Update-Feeds von Anbietern wie die „Patch Tuesday“-Veröffentlichungen von Microsoft verarbeiten können.
Integration mit dem Endpunkt- und Schwachstellenmanagement
Die effektivsten Tools für das Patch-Management arbeiten nicht isoliert. Sie lassen sich in Ihre übergreifenden Lösungen für Endpunktmanagement und Schwachstellenmanagement von integrieren, um den Arbeitsablauf zur Risikoerkennung, zur Bereitstellung von Patches und zur Überprüfung der Behebung über eine einzige Konsole zu optimieren. Dadurch entfallen manuelle Übergaben, die die Behebung in großem Maßstab verlangsamen.
Anforderungen an die Berichterstattung und den Prüfpfad
Das von Ihnen gewählte Tool erstellt detaillierte Berichte, mit deren Hilfe Sie die Einhaltung der SLAs Ihrer Richtlinie überwachen können. Es bietet einen lückenlosen Nachverfolgungsverlauf darüber, welche Patches wann installiert wurden und welche Systeme weiterhin nicht den Anforderungen entsprechen, einschließlich aller dokumentierten Ausnahmen.
Die autonome IT-Plattform von Tanium wurde entwickelt, um diesen Anforderungen an die Durchsetzung gerecht zu werden.
Wie Tanium die Durchsetzung von Richtlinien im Patch-Management unterstützt
Die „ “ Tanium Autonomous IT Platform ermöglicht einen richtliniengesteuerten Ansatz für das Patch-Management, indem sie Echtzeit-Endpunktdaten mit kontrollierter Automatisierung kombiniert. Dadurch erhalten IT- und Sicherheitsteams eine gemeinsame Grundlage für die Durchsetzung von Patch-Richtlinien auf der Grundlage des aktuellen Risikos und des Endpunktstatus, anstatt die Koordination über fragmentierte Tools hinweg vornehmen zu müssen.
Über eine einzige Konsole können Teams den aktuellen Status von Patches auf lokalen, Remote- und cloudbasierten Geräten in Echtzeit einsehen, Patches anhand von Schwachstellen- und Risiko-Daten priorisieren und die Bereitstellung durch ringbasierte Rollouts automatisieren, wodurch Betriebsunterbrechungen auf ein Minimum reduziert werden. In der Richtlinie definierte SLAs und Ausnahmeprozesse können direkt auf aktuelle Endpunktdaten angewendet werden, ohne dass ein manueller Abgleich erforderlich ist.
Tanium vereint Endpunktmanagement und Sicherheitsoperationen ( ) auf einer einzigen Plattform, sodass die Lücke zwischen der Festlegung und der Umsetzung von Richtlinien geschlossen bleibt. Die Bereitstellung von Patches erfolgt im Rahmen von Genehmigungsabläufen und Wartungsfenstern. Nachweise zur Einhaltung der Vorschriften werden fortlaufend erstellt und nicht erst zum Zeitpunkt der Prüfung zusammengestellt.
Das Ergebnis ist ein Patching-Programm, das nach eigenen Regeln arbeitet: konsistent, nachvollziehbar und in großem Maßstab.
Häufig gestellte Fragen zu Richtlinien für das Patch-Management
Die Erstellung und Pflege einer Richtlinie zum Patch-Management wirft praktische Fragen auf, insbesondere für Unternehmen, die sich mit Compliance-Anforderungen oder komplexen IT-Umgebungen auseinandersetzen müssen. Nachfolgend finden Sie Antworten auf häufig gestellte Fragen.
Wie oft sollte eine Richtlinie zum Patch-Management überprüft werden?
Die meisten Organisationen überprüfen ihre Richtlinien zum Patch-Management jährlich oder nach einem bedeutenden Ereignis, wie beispielsweise einem schwerwiegenden Sicherheitsvorfall, einer umfassenden Änderung der Infrastruktur oder der Einführung neuer Compliance-Anforderungen.
Was ist der Unterschied zwischen einer Richtlinie zum Patch-Management und einem Plan zum Patch-Management?
Eine Richtlinie ist ein übergeordnetes Steuerungsdokument, in dem die Regeln, Rollen und Anforderungen festgelegt sind. Ein Plan ist das detaillierte operative Dokument, in dem die spezifischen Verfahren, Zeitpläne und Instrumente zur Umsetzung der Richtlinie dargelegt sind.
Wie setzen Sie eine Richtlinie zum Patch-Management in verteilten Teams durch?
Die Durchsetzung von Richtlinien bei einer verteilten Belegschaft erfordert ein zentralisiertes Tool zur Endpunktverwaltung, das in Echtzeit Transparenz und Kontrolle über jedes Gerät bietet, unabhängig von dessen physischem Standort oder seiner Netzwerkverbindung.
Anhand welcher KPIs lässt sich die Wirksamkeit von Richtlinien zum Patch-Management messen?
Zu den wichtigsten zu überwachenden Kennzahlen zählen die durchschnittliche Zeit bis zur Behebung (MTTP) bei kritischen Sicherheitslücken, der Prozentsatz der Endgeräte, die die in den Richtlinien festgelegten SLAs einhalten, sowie die Anzahl und das Alter offener Ausnahmeregelungen bei der Patch-Verwaltung.
Wie geht eine Richtlinie mit Altsystemen um, für die keine Patches verfügbar sind?
Die Richtlinie schreibt vor, dass Systeme, für die keine Patches verfügbar sind, im Rahmen eines Ausnahmeverfahrens dokumentiert und durch Ausgleichsmaßnahmen geschützt werden müssen, wie beispielsweise Netzwerksegmentierung, strengere Zugriffskontrollen oder eine verstärkte Überwachung auf Sicherheitsprobleme.
Eine gut durchdachte Richtlinie legt fest, wie ein ordnungsgemäßes Patch-Management theoretisch aussehen sollte. Die Lücke zwischen diesem Dokument und dem, was tatsächlich auf Tausenden von Endgeräten geschieht, zu schließen, ist der Punkt, an dem die meisten Unternehmen Schwierigkeiten haben – und an dem die hinter der Richtlinie stehenden Tools ebenso wichtig sind wie die Richtlinie selbst.
Die „Autonomous IT Platform“ von Tanium basiert auf der Art von Echtzeit-Transparenz der Endgeräte und der kontrollierten, ringbasierten Bereitstellung, die eine ausgereifte Patching-Richtlinie benötigt, um in großem Maßstab zu funktionieren.
Wenn Sie sehen möchten, wie dies in der Praxis in Ihrer eigenen Umgebung funktioniert, vereinbaren Sie unter einen Termin für eine individuelle Tanium-Demo unter.
