Cyber-Kriminelle können sich ziemlich schnell auf neue Situationen einstellen. Es gibt unzählige Gegner, die im Schatten nach der nächsten Schwachstelle suchen, die sie ausnutzen können. Manchmal finden sie eine Schwachstelle, die weder von White-Hat-Forschern noch von den Anbietern identifiziert wurde, was zu einem Zero-Day-Exploit führt. Aber zumeist halten sie Ausschau nach öffentlichen Bekanntmachungen und Aktualisierungen von Anbietern, um Änderungen im Code zu identifizieren. An diesem Punkt beginnt ein Wettlauf - der Wettlauf darum, ob sie einen funktionierenden Exploit erstellen können, bevor Organisationen auf der ganzen Welt die Schwachstellen schließen können.

Mehrere Beispiele aus jüngster Zeit zeigen, wie schnell Cyber-Kriminelle agieren können:

  • BlueKeep (CVE-2019-0708): Die Schwachstelle, die als nächstes potenzielles WannaCry gepriesen wurde, wurde am 14. Mai 2019 behoben. Aufgrund ihrer Berühmtheit hatten wir die Gelegenheit, die Entwicklung von Exploits in Aktion zu sehen, da mehrere unabhängige Forschungsteams innerhalb von nur 14 Tagen funktionierende Exploits verwirklichten. (Mehrere POC-Videos (Proof-of-Concept) vom 28. Mai 2019 zeigten die vollständige Ausnutzung der Schwachstelle.) Es dauerte eine Weile, bis Cyber-Kriminelle begannen, die Exploits auszunutzen, aber im Crypto-Mining hat es eine rege Nutzung gegeben.
  • ZeroLogon (CVE-2020-1472): Die Schwachstelle in NetLogon wurde mit einer Aktualisierung am 11. August 2020 behoben. Die Lösung erforderte einige Änderungen an der Funktionsweise von NetLogon. Daher veröffentlichte Microsoft die Aktualisierung, wobei die Sicherheitsanfälligkeit behoben, die Änderung jedoch zunächst in den Überwachungsmodus versetzt wurde. Microsoft teilte mit, dass es die Durchsetzung als Teil der Patch Tuesday-Veröffentlichung im Februar 2021 aktivieren würde. Unternehmen konnten die Durchsetzung jedoch früher aktivieren, indem sie eine Registrierungseinstellung änderten. Am 15. September 2020 kam die Nachricht über die POCs, und am 18 September gab das US-amerikanische Department of Homeland Security die Notfallrichtlinie 20-04 heraus. Darin wurde den Regierungsbehörden geraten, die Aktualisierung bis zum darauf folgenden Montag, den 21. September 2020, bereitzustellen und die Durchsetzung zu ermöglichen. Wie sich herausstellte, war ihre Dringlichkeit durchaus berechtigt, da die ersten Exploits in freier Wildbahn vor Ende September entdeckt wurden.
  • .Net\SharePoint RCE-Fehler (CVE-2020-1147): Ursprünglich gelöst mit der Juli-Veröffentlichung zum Patch Tuesday am 14 Juli. Am 21. Juli war POC-Angriffscode im Umlauf. Dieses Update wurde im Rahmen der Veröffentlichung zum Patch Tuesday im Oktober erneut veröffentlicht.

In allen drei Fällen liegt die Zeitspanne von der Veröffentlichung bis zur Verfügbarkeit des Exploit-Codes zwischen 14 und 28 Tagen. Dies deckt sich mit den Ergebnissen des 2016 Verizon Data Breach Investigations Report, der besagt, dass 50 % der Exploits innerhalb von zwei bis vier Wochen nach der Veröffentlichung durch den Anbieter auftreten werden. Die Ergebnisse von „Zero Days, Thousands of Nights“, einem von der RAND Corporation veröffentlichten Bericht, ergaben, dass die mittlere Zeit für die Ausnutzung einer Schwachstelle 22 Tage beträgt. Basierend auf diesen Erkenntnissen wird empfohlen, ein SLA für die Schwachstellenbehebung von 14 Tagen oder weniger anzustreben, was uns zu den nächsten Herausforderungen bringt.

Warum ist ein SLA von 14 Tagen schwer zu erreichen?

Lösungen für das Schwachstellen- und Patch-Management gibt es seit mehr als einem Jahrzehnt auf dem Markt. Es handelt sich dabei um ziemlich ausgereifte Lösungen. Die rasche Identifizierung, Bereitstellung, Installation und Berichterstattung über den Zustand von Schwachstellen stellen damit keine große Herausforderung mehr dar.

Zu den größeren Herausforderungen zählt die Tatsache, dass sich der Prozess zur Behebung von Schwachstellen über mehrere Teams und Technologiepakete erstreckt. Der Prozess ist voll von manuellen Schritten, Tests und betrieblichen Auswirkungen sowie einigen grundlegenden Kommunikationsproblemen, die zu Verzögerungen führen. Ich kann aus dem Stegreif zahlreiche Unternehmen nennen, die 14-tägige oder kürzere SLAs zur Schwachstellenbehebung erreicht haben. Einige von ihnen sind Großunternehmen in der verarbeitenden Industrie, im Einzelhandel und anderen Bereichen. Was haben sie getan, um dies zu erreichen, wenn sie doch die gleiche Technologie einsetzen wie Unternehmen, die noch im 30-Tage-Zyklus arbeiten?

Die vier größten Herausforderungen bei der Schwachstellenbehebung:

  • Schließen der Lücke zwischen IT-Sicherheit und Betrieb: Seien wir ehrlich. Es ist eher die Ausnahme als die Regel, dass IT-Sicherheit und Betrieb wirklich „miteinander auskommen“. Die Security-Abteilung spricht die Sprache des Risikos und der CVEs (Common Vulnerabilities and Exposures), während der IT-Betrieb die Sprache von Einsatzfähigkeit und Patches spricht. Das Auflösen einer CVE kann betriebliche Auswirkungen haben, wenn der Patch etwas beschädigt. Das Operations-Team ist das ein riesiges Problem. Wenn der Alltagsbetrieb die Geschwindigkeit begrenzt, mit der die Sicherheitsprobleme gelöst werden können, und ein Incident eintritt, ist das für das Sicherheitsteam sehr beschwerlich.
  • Eine risikobasierte Priorisierung ist entscheidend, damit die richtigen Schwachstellen zuerst behoben werden: In vielen Fällen spiegeln der Vendor Severity-Wert (Schweregradwert laut Anbieter) und CVSS-Wert (Common Vulnerability Scoring System) nicht wieder, was am dringendsten ist. Es gibt viele Beispiele dafür, dass ein Zero-Day überwunden wurde, wobei jedoch der Vendor Severity-Wert nur „wichtig“ lautete und der CVSS-Wert bei 7,0 oder sogar darunter lag. Zusätzliche Metriken und Metadaten sind nötig, um sicherzustellen, dass es gelingt, die Elemente mit dem höchsten Risiko in den Griff zu bekommen. Zum Beispiel: Was wird aktiv ausgenutzt?
  • Das Wissen um die Zuverlässigkeit von Aktualisierungen: Zurück zu den SLAs zur Schwachstellenbehebung und dem Zeitaufwand für das Patching. Eines der größten Hindernisse für schnelle Fortschritte ist die Unfähigkeit, effektiv zu testen. Administratoren haben zwei Möglichkeiten: 1) versuchen, ihre Tests zu skalieren, um sicherzustellen, dass sie keine operativen Auswirkungen haben, oder 2) mehr Zeit in den Testprozess investieren und darauf warten, dass Probleme sich von selbst regeln. Die Sache ist die: Bedrohungsakteure mögen es, wenn man wartet. Hatte ich erwähnt, dass im gleichen RAND-Bericht auch die durchschnittliche Haltbarkeit eines Exploits mit sieben Jahren angegeben wurde? Allem Anschein nach blieben einige Fragen wirklich lange Zeit ungelöst, was den Bedrohungsakteuren reichlich Chancen für leichte Beute bescherte.
  • Patch-Compliance: Es gibt eine große Vielfalt an Compliance-Reports. Die meisten beziehen sich aber auf den Zeitpunkt, zu dem Ihr Wartungsfenster beginnt, und nicht auf den Zeitpunkt, zu dem die Aktualisierung erstmals zur Verfügung gestellt wurde. Microsoft, Adobe und Oracle veröffentlichen möglicherweise die meisten Sicherheits-Updates zu einem einheitlichen und vorhersehbaren Datum, Google, Apple, Mozilla und viele andere Unternehmen jedoch nicht. Will man Compliance im Hinblick auf eine Schwachstelle verfolgen, ist eine Neuausrichtung auf einer detaillierteren Ebene erforderlich, um der kontinuierlichen Bereitstellung der heutigen Software Rechnung zu tragen.

Wenn Patch-Zuverlässigkeit, risikobasierte Priorisierung und Patch-Compliance Herausforderungen sind, die Sie daran hindern, ein 14-tägiges SLA zur Schwachstellenbehebung zu erreichen, benötigen Sie unter Umständen erweiterte Unterstützung, die über Ihre aktuelle Patching-Lösung hinausgeht. Ivanti® Neurons for Patch Intelligence wurde im Hinblick auf eben diese Herausforderungen entwickelt. Sehen Sie es sich jetzt an.