Ivanti Blog: Beiträge von

Effektive moderne Patch-Management-Prozesse und bewährte Verfahren für Patch-Vorgänge

Thu, 01 Aug 2024 06:01:00 Z

Die Durchführung eines risikobasierten Programms zur Verwaltung von Sicherheitslücken ist essenziell für die Aufrechterhaltung einer sicheren IT-Umgebung im Unternehmen. In einem früheren Blog-Beitrag mit dem Titel „Wie die Implementierung eines risikobasierten Patch-Managements aktive Exploits priorisiert“ habe ich einen Überblick darüber gegeben, wie Sicherheitslücken priorisiert werden können. Die Optimierung des operativen Aspekts der Sicherung Ihrer Systeme ist für diesen Prozess essenziell.

Die Durchführung von Patch-Prozessen in Ihrem Unternehmen kann kompliziert sein. Auch wenn Sie die Priorität von Sicherheitslücken im Blick haben, müssen Sie Folgendes berücksichtigen:

Die Veröffentlichungsfrequenz von Patches.
Unterstützung von Richtlinien, um diesen Prozess effektiv zu gestalten.
Kampagnen zur Bereitstellung der Updates.
Service-Level-Vereinbarungen (SLA) und Überwachung der Compliance.

Das mag nach viel Aufwand klingen – aber ein flexibles System, das geplante Veranstaltungen verwaltet und auch ungeplante Ereignisse berücksichtigen kann, gibt Ihnen die vollständige Kontrolle.

Haben Sie alles unter Kontrolle?

Es gibt einige Aspekte von Patch-Veröffentlichungen, die Sie planen können, und andere, bei denen dies nicht möglich ist.

Nehmen Sie etwa die Veröffentlichungsfrequenz von Sicherheits-Patches. Am Patch Tuesday, dem zweiten Dienstag jedes Monats, versucht Microsoft, alle seine neuesten Updates zu veröffentlichen. Dazu gehören Updates für Betriebssysteme, Office und andere Benutzeranwendungen, Entwicklungstools wie Visual Studio und Cloud-Komponenten in Azure, um nur einige zu nennen.

Der Patch Tuesday, der im Oktober 2023 sein 20-jähriges Jubiläum feierte, ist die Grundlage für viele Patch-Programme und bietet einen Zeitpunkt, an dem alle neuesten Microsoft-Updates und verfügbaren Updates von Drittanbietern verteilt werden. Kein anderer Anbieter hat einen so großen Einfluss auf die Förderung von Patch-Programmen für Unternehmen gehabt – und bis heute ist der monatliche Patch-Zyklus, der auf dem Patch Tuesday basiert, ein Standard in der Branche.

Andere Anbieter haben versucht, diesem Beispiel zu folgen und ihre Updates nach einem bestimmten Zeitplan zu veröffentlichen:

Oracle veröffentlicht ein Critical Patch Update einmal pro Quartal.
Adobe veröffentlicht seine Updates in der Regel einmal im Monat, oft synchron mit dem Patch Tuesday.
Google hat kürzlich damit begonnen, jede Woche ein neues Update zu veröffentlichen.

Die meisten Anbieter veröffentlichen jedoch so schnell und so oft wie möglich Sicherheitsupdates, um sicherzustellen, dass sie Sicherheitslücken so schnell wie möglich beheben. Dies führt zu einem zufälligen und endlosen Strom von Aktualisierungen, die ständig priorisiert und innerhalb eines Unternehmens verteilt werden müssen.

Prozess zur Patch-Verwaltung für Richtlinien und Kampagnen

Um das Chaos der Patch-Veröffentlichungen in den Griff zu bekommen, sind klar definierte Regeln und eine Infrastruktur zu deren Durchsetzung erforderlich. Im Patch-Bereich werden diese in Richtlinien und Kampagnen umgesetzt.

Eine Patch-Richtlinie erfordert eine Vielzahl von Überlegungen, die über die Priorisierung von Sicherheitslücken hinausgehen, darunter die Auswirkungen von Updates auf den Geschäftsbetrieb, die Anwendbarkeit auf verschiedene Systemtypen, der Grad der Kontrolle über die Updates und andere Faktoren.

Die Patch-Richtlinien können dabei je nach Unternehmen völlig unterschiedlich ausfallen. Für einen Server, auf dem kritische Geschäftsanwendungen gehostet werden, umfasst seine Richtlinie eine klar definierte Reihe von Updates unter strenger Konfigurationskontrolle, die nur während eines festgelegten Wartungsfensters durchgeführt werden, und erzwingt nach Abschluss immer einen Neustart, um sicherzustellen, dass das System vollständig aktualisiert ist. Die Patch-Richtlinie für den Laptop eines Marketingspezialisten identifiziert eine Reihe von Anwendungen mit genehmigten Updates, die vorhanden sein können oder auch nicht, und ermöglicht es dem User, Updates zu verschieben und den Laptop dann neu zu starten, wenn es ihm passt.

Kampagnen berücksichtigen diese Richtlinien, bringen aber auch Kontrollmechanism in die unzähligen Patches, die ständig veröffentlicht werden.

Moderne Best Practices für das Patch-Management erfordern häufigere Patches als nur einmal im Monat. Google-Chrome-Patches werden wöchentlich veröffentlicht, und Zero-Day-Patches können jederzeit veröffentlicht werden. Eine monatliche Kampagne führt dazu, dass viele Systeme über längere Zeiträume hinweg Sicherheitslücken aufweisen.

Etablieren Sie drei Arten von Kampagnen

Eine bewährte Vorgehensweise besteht darin, drei Arten von Kampagnen zu erstellen: regelmäßige Wartung, Priority-Updates und kritische Bereitstellungen.

Kampagne zur regelmäßigen Wartung

Kampagnen zur regelmäßigen Wartung erzwingen die standardmäßige monatliche Einführung von Patches, die die meisten Unternehmen heute verwenden. Diese Kampagne umfasst:

Erste Tests in einer kontrollierten Umgebung, um sicherzustellen, dass die Patches wie geplant installiert werden.
Einführung bei einer größeren Pilotgruppe von Early Adopters, die auf der Suche nach Problemen sind.
Einführung in die vordefinierten Gruppen von Produktionssystemen, um die Gesamtverteilung abzuschließen.

Die Patches in einer Wartungskampagne enthalten Sicherheitsupdates, die weniger häufig veröffentlicht werden, wie z. B. die Veröffentlichungen am Microsoft Patch Tuesday, sowie Leistungs- oder Anwendungs-Upgrades. Die Zielsysteme in dieser Kampagne können auch solche sein, die nur über begrenzte Wartungsfenster verfügen und nicht unterbrochen werden können, ohne dass dies erhebliche Auswirkungen auf den Geschäftsbetrieb hat. Die meisten Patches werden höchstwahrscheinlich in die Kampagne für Priority-Updates fallen.

Kampagne für Priority-Updates

Die Kampagne für Priority-Updates zielt darauf ab, Systeme, die ständig neuen Sicherheitslücken ausgesetzt sind, aber häufiger aktualisiert werden können, schnell zu aktualisieren. Benutzersysteme, auf denen Produktivitätsanwendungen und Browser ausgeführt werden, fallen unter diese Kampagne und sind oft dem höchsten Risiko ausgesetzt, da sie Phishing, Malware und Ransomware ausgeliefert sind.

Die mit dieser Kampagne verbundenen Patches haben aufgrund von Sicherheitslücken, die bekanntermaßen ausgenutzt werden, oft höchste Priorität, können aber auch relativ geringe Auswirkungen auf das Geschäft haben und einen Neustart des Browsers oder der Anwendung erfordern. Daher werden die Richtlinien möglicherweise vor ihrer Veröffentlichung einem kürzeren Testzyklus unterzogen und können schneller an größere Gruppen von Systemen verteilt werden, die nicht geschäftskritisch sind, z. B. wenn auf Servern kein Browser installiert ist, auf Laptops im Vertrieb aber schon.

Zero-Day-Response-Kampagne

Die Zero-Day-Response-Kampagne ist für die Notfall-Patch-Bereitstellung vom Typ „Feuerwehreinsatz“ reserviert, die von Unternehmen oder Branchen vorgeschrieben wird und innerhalb kurzer Zeit erfolgen muss. Diese Kampagne hat Vorrang vor allen anderen.

Die Richtlinie für diese Kampagne könnte die Zeit verkürzen oder die Standards zwischen den Gated Rollouts senken – oder sie könnte sie ganz ignorieren, je nachdem, welche Service-Level-Vereinbarung erfüllt werden muss. Das Wichtigste bei Zero-Day-Response-Kampagnen: Es handelt sich immer noch um eine kontrollierte Verteilung von Patches, und alle Aktivitäten werden weiterhin gemeldet, um die Ereignisse der Kampagne bis zum Abschluss genau zu verfolgen.

Die Exposure-Zeit bestimmt die Compliance

Wenn die Compliance anhand vollständig gepatchter Maschinen gemessen wird, sind die meisten Systeme nach dieser Metrik nur für eine begrenzte Anzahl von Stunden pro Monat konform. Obwohl dies technisch korrekt ist, ist dies ein schlechter Indikator, um die Sicherheit des Systems im Laufe der Zeit im Rahmen eines risikobasierten Programms zu zeigen. Die „Exposure-Zeit“ gegenüber einer bestimmten Sicherheitslücke oder einer Gruppe von Sicherheitslücken zu ermitteln, liefert einen besseren Risikoindikator.

Hier ein Beispiel: CVE-2024-4761 wurde in einem Google-Chrome-Update vom 14. Mai als behoben gemeldet, was zufällig der Patch Tuesday im Mai war. Am nächsten Tag wurde dieser Chrome-Patch zu einer Priority-Update-Kampagne hinzugefügt, die eine zweiwöchige Verteilungsperiode auf 500 Systemen in Gruppe 1 und 1.000 Systemen in Gruppe 2 umfasste. Angenommen, die meisten Systeme wurden innerhalb dieses Zeitfensters von zwei Wochen erfolgreich aktualisiert, würde ein Report zeigen, wann jedes System aktualisiert wurde, aber noch wichtiger, wie lange jedes dieser 1.500 Systeme ungepatcht blieb – und somit der Sicherheitslücke ausgesetzt und gefährdet war.

Dies ist ein einfaches Beispiel für eine Sicherheitslücke und einen Patch. Wenn es jedoch mehrere Patches in der Kampagne mit mehreren Sicherheitslücken gäbe, könnten die Informationen aggregiert werden, um eine umfassendere Ansicht der Kampagne zu erhalten. Wenn mehrere Kampagnen im selben Zeitraum durchgeführt wurden, könnte das Ergebnis überlagert oder kombiniert werden, um eine noch genauere Risikobewertung zu erhalten.

Mit diesen Daten können Sie einem externen Prüfer den tatsächlichen Sicherheitsstatus Ihrer Systeme zeigen. Noch wichtiger ist vermutlich, dass Sie die Möglichkeiten haben, die Ergebnisse zu bewerten und die Effektivität Ihres modernen Patch-Managements zu verbessern. An diesem Punkt haben Sie die Kontrolle über das Geschehen – und nicht das Geschehen über Sie.

Wie die Implementierung eines risikobasierten Patch-Managements aktiven Sicherheitslücken Vorrang einräumt

Tue, 20 Jun 2023 15:01:46 Z

Widerstand gegen Veränderungen gibt es immer, vor allem, wenn man glaubt, dass die bestehenden Prozesse effizient und effektiv sind. Viele Unternehmen denken so über ihre Verfahren zur Softwareverwaltung, bis es zu einer Sicherheitsverletzung oder einem Zwischenfall kommt und sie sich fragen müssen, was sie falsch gemacht haben.

Die Realität ist, dass die meisten Patch-Management-Programme auf Annahmen und Empfehlungen beruhen und nicht auf Fakten über aktiv ausgenutzte Schwachstellen. Risikobasiertes Patch-Management ist die Antwort auf dieses Problem.

In diesem Artikel finden Sie:

Was falsch ist an der Beibehaltung der typischen Prioritäten.
Was risikobasiertes Patch-Management ist.
Warum es der perfekte Zeitpunkt für die Einführung eines risikobasierten Patch-Managements ist.

Die Probleme mit der typischen Prioritätensetzung

Aktualisierungen von Softwarefunktionen, Sicherheitskorrekturen, Fehlerbehebungen, Leistungsverbesserungen und viele andere Arten von Softwareversionen gibt es seit den Anfängen der Softwareindustrie. Die Anbieter ordnen jedem dieser Punkte einen Schweregrad oder eine andere Bewertung zu, um den Kunden mitzuteilen, was ihrer Meinung nach am wichtigsten ist.

Leider gibt es keinen Industriestandard für diese Einstufungen, so dass wir auf der Grundlage von Empfehlungen die Versionen für den Einsatz auf unseren Systemen vergleichen und priorisieren müssen. Hinzu kommt, dass solche Bewertungen nur selten aktualisiert werden, um dem aktiven Bedrohungskontext Rechnung zu tragen, selbst wenn sich die Schwachstellen ändern.

Übersehen einer aktiv ausgenutzten Sicherheitslücke

Das ist zwar besser als gar nichts, aber die Schweregrade der Sicherheitslücken werden von den Anbietern oft zu niedrig angesetzt. Nehmen wir die Sicherheitslücke Follina (CVE-2022-30190), die im Mai 2022 veröffentlicht wurde. Diese Sicherheitslücke im Microsoft Windows Support Diagnostic Tool (MSDT) ermöglicht die Ausführung von Remotecode.

Follina wurde mehrere Monate lang angegriffen, bevor Microsoft schließlich mit mehreren Updates reagierte. Erschreckenderweise stufte Microsoft diese Sicherheitslücke nur mit dem CVSS v3-Rating 7.8 und dem Schweregrad Wichtig ein. Wenn Sie nur nach dem Schweregrad „kritisch“ patchen, haben Sie diese Schwachstelle übersehen und eine große Lücke in Ihrer Angriffsfläche hinterlassen.

Schlimmer noch: Der CVSS-Wert von Follina blieb bei 7,8, selbst nachdem bekannt wurde, dass die Sicherheitslücke aktiv ausgenutzt wurde, um Bisamware Ransomware zu verbreiten, wodurch Unternehmen, die die Sicherheitslücke übersehen hatten, einem noch größeren Risiko ausgesetzt waren.

Informationen über die Ransomware-Bedrohung im Zusammenhang mit CVE-2022-30190, angezeigt in Ivanti Neurons for VULN KB

CVSS-Mängel

Die Schweregrade werden mit CVSS-Scores von FIRST „ergänzt“. Jedem CVE wird eine CVSS-Nummer zugewiesen, wie zum Beispiel die 7.8 für CVE-2022-30190 im obigen Beispiel.

Eines der Hauptziele bei der Berechnung der CVSS-Nummer ist die Standardisierung, damit alle CVEs einheitlich bewertet werden und genau verglichen werden können. Je höher der CVSS-Score für eine Schwachstelle und den zugehörigen Patch ist, desto kritischer ist sie in den meisten Umgebungen zu implementieren.

Bei Software-Updates, die mehrere CVEs abdecken, wird normalerweise der höchste CVSS-Wert für die Priorisierung herangezogen. Aber ist dieser Wert überhaupt richtig?

Die Ergebnisse einer Analyse der CVSS-Scores in einem kürzlich erschienenen Artikel zeigen, dass es bei fast 20 % der CVSS-Scores (25.000) eine Diskrepanz gibt. Diese Analyse basierte auf einem Vergleich der in der NIST National Vulnerability Database (NVD) gemeldeten Werte mit den von den Anbietern selbst gemeldeten Werten.

Unstimmigkeiten beim Anbieter-Schweregrad

Ein wichtiger Punkt ist, dass die Hersteller in der Vergangenheit ihre eigene Terminologie für den Schweregrad verwendet haben (z. B. kritisch, wichtig). Die Einstufung des Schweregrads durch den Hersteller als Prioritätsmechanismus kann gut funktionieren, wenn alle Patches eines bestimmten Herstellers verglichen werden, bietet aber nicht immer einen genauen Vergleich von Patches verschiedener Hersteller. Viele verwenden sogar eine völlig andere Terminologie.

Ebenso ist die Schwere des Problems bei den Anbietern nicht immer ein positiver Indikator. Viele Zero-Day-Schwachstellen werden von Microsoft nur als wichtig eingestuft, haben aber hohe CVSS-Werte. Sie sehen, dass das Patchen nach Schweregrad und CVSS für die Priorisierung auf Annahmen und Empfehlungen beruht und zu einer anfälligen Umgebung führen kann.

Warum sollten aktive Exploits Vorrang vor anderen Priorisierungsmethoden haben?

Nach Angaben der US-Behörde für Cybersicherheit und Infrastruktursicherheit (CISA) ist eine aktiv ausgenutzte Schwachstelle „eine Schwachstelle, für die es verlässliche Beweise gibt, dass ein Akteur ohne Erlaubnis des Systembesitzers bösartigen Code auf einem System ausgeführt hat“. Für den Laien ist eine aktiv ausgenutzte Sicherheitslücke eine Schwachstelle, die von einem Angreifer genutzt wurde, um einen Cyberangriff zu starten. Übersetzt mit www.DeepL.com/Translator (kostenlose Version)

Um das Risiko eines Angriffs auf Ihr Unternehmen zu minimieren, müssen Sie daher aktiv ausgenutzten Sicherheitslücken Vorrang vor allen anderen einräumen. Das ist eine gute Nachricht, denn die meisten Sicherheitslücken werden nicht aktiv ausgenutzt und stellen daher ein geringes bis gar kein Risiko für Ihr Unternehmen dar. Diejenigen, die ausgenutzt wurden, können Sie durch risikobasiertes Patch-Management identifizieren.

Was ist risikobasiertes Patch-Management?

Laut dem Ultimate Guide to Risk-Based Patch Management:

„Die risikobasierte Verwaltung von Patches geht über den Schweregrad des Herstellers und die grundlegenden CVSS-Scores hinaus, um die spezifischen Sicherheitslücken zu identifizieren und zu qualifizieren, die das größte Risiko für ein Unternehmen darstellen.

Als Erweiterung der risikobasierten Verwaltung von Sicherheitslücken bringt es einen realen Risikokontext in den Patch-Management-Prozess ein, indem es Updates mit bekannten Sicherheitslücken einbezieht, die für die Sicherheitslage eines Unternehmens am wichtigsten sind.“

Wie kann mein Unternehmen ein risikobasiertes Patch-Management einführen?

Für Unternehmen, die bereit sind, einen risikobasierten Ansatz für die Patch-Verwaltung zu wählen, ist der CISA Known Exploited Vulnerabilities (KEV)-Katalog ein guter Ausgangspunkt. Die CISA hat mit der Einführung der Binding Operational Directive 22-01 zusammen mit ihrem KEV-Katalog einen großen Schritt nach vorn gemacht, um die Priorisierung von Sicherheitslücken zu unterstützen. Als der Katalog ursprünglich veröffentlicht wurde, enthielt er etwa 200 aktiv ausgenutzte Sicherheitslücken. Inzwischen ist die Zahl auf fast 900 gestiegen.

Die CISA erstellt die Liste mit dem Wissen, dass die darin enthaltenen Sicherheitslücken von aktiven Bedrohungen ausgenutzt werden. Allerdings hat die Liste auch ihre Schwächen, da sie derzeit 131 Sicherheitslücken im Zusammenhang mit Ransomware nicht enthält.

Ist der CISA KEV-Katalog die einzige verfügbare Ressource für risikobasiertes Patch-Management?

Unternehmen mit einer ausgereifteren risikobasierten Patch-Verwaltung nutzen fortschrittliche Methoden zur Risikobewertung anstelle von CVSS oder zusätzlich zu CVSS. Diese Methoden weisen jeder Sicherheitslücke, die in der Umgebung eines Unternehmens identifiziert wird, eine Punktzahl zu und ermöglichen es den Unternehmen, ihren risikobasierten Ansatz über die CISA KEV hinaus zu erweitern.

Viele Anbieter im Bereich der risikobasierten Verwaltung von Sicherheitslücken haben eigene Scoring-Methoden entwickelt, die das tatsächliche Risiko einer Sicherheitslücke darstellen. Sie tun dies, indem sie dynamische Risikobewertungen liefern, die aktiv ausgenutzte Sicherheitslücken extra gewichten.

Das Vulnerability Risk Rating (VRR) von Ivanti hat Follina beispielsweise eine Punktzahl von 10 zugewiesen, eine Punktzahl, die das von dieser Sicherheitslücke ausgehende Risiko genauer darstellt als die CVSS-Punktzahl von 7,8.

Der Unterschied zwischen den VRR- und CVSS v3-Scores und den Schweregraden für CVE-2022-30190, wie in Ivanti Neurons for VULN KB gezeigt.

Warum es der perfekte Zeitpunkt für die Einführung eines risikobasierten Patch-Managements ist.

Wenn Sie das Gefühl haben, dass Sie mit Systemaktualisierungen in Verzug geraten sind oder von neuen Systemen und Anwendungen in Ihrem Unternehmen überfordert sind, ist jetzt der perfekte Zeitpunkt, um ein risikobasiertes Patch-Management einzuführen.

Selbst wenn Sie das Gefühl haben, dass Sie über ein solides Programm auf der Grundlage von Schweregradbewertungen und CVSS-Scores verfügen, ist es an der Zeit, den Widerstand gegen Veränderungen zu beseitigen und einen neuen Prozess zu starten, bevor Ihr Unternehmen durch eine Datenverletzung aufgrund einer ausgenutzten Sicherheitslücke geschädigt wird.

Beginnen Sie mit dem CISA KEV, um Ihre Updates zu priorisieren und ein Budget für eine risikobasierte Verwaltung von Sicherheitslücken und Patches vorzusehen. Mit den richtigen Tools können Sie schnell die Systeme mit dem höchsten Risiko identifizieren, die zuerst gepatcht werden müssen, und dann die Liste abarbeiten, um sicherzustellen, dass Ihre Systeme sicher sind.

Möchten Sie den ersten Schritt tun? In diesem eBook finden Sie einen Leitfaden für die Implementierung eines modernen risikobasierten Patch-Management-Programms.