Technische Unterstützung
Dokumentation
Anmeldung
Kontakt
Überlegungen zur Patch-Implementierungszeit
Joao Correia
Februar 10, 2023 - Technischer Evangelist
Unternehmen versuchen oft, ihre Systeme "rechtzeitig" zu patchen, um vor neuen Bedrohungen sicher zu sein. In diesem Zusammenhang bedeutet "rechtzeitig" für jede Organisation etwas anderes - manche bemühen sich, innerhalb eines Monats nach Bekanntwerden einer Schwachstelle zu patchen, andere tun es, sobald ein Patch verfügbar ist (wie es mit Live-Patchingmöglich ist), während andere es tun werden, sobald die Geschäftsanforderungen die erforderliche Ausfallzeit zulassen.
Aber zählen wir hier überhaupt die Zeit richtig? Was bedeutet "pünktlich" wirklich, wenn es um Patching geht?
Pünktlich
Schauen wir uns ein Beispiel für eine eher harmlose Sicherheitslücke an, die gerade bekannt gegeben wurde: CVE-2023-25136 - eine OpenSSH-Schwachstelle im Vorauthentifizierungsprozess, die durch den Versuch verursacht wird, eine bereits freigegebene Variable "freizugeben", was zu Problemen führen kann. Sie wurde am 3. Februar öffentlich bekannt gegeben, und einigen CVE-Registrierstellen fehlen immer noch Details dazu.
Wenn man das (scheinbare) Fehlen eines Risikos außer Acht lässt und hypothetisch annimmt, dass es sich um eine Sicherheitslücke mit hohem Risiko handelt, was würde ein "rechtzeitiges" Patchen für diese Schwachstelle bedeuten? Wenn Sie heute patchen würden (zum Zeitpunkt der Erstellung dieses Artikels), dann würden Sie innerhalb einer Woche nach der öffentlichen Ankündigung patchen, und das wäre ziemlich gut, und Sie könnten Ihre Infrastruktur wieder als sicher betrachten - was ein solider Zeitplan ist, wenn man bedenkt, dass eine Studie aus dem letzten Jahr zeigt, dass die Mehrheit der Unternehmen mehr als einen Monat brauchten mehr als einen Monat brauchten, um hochgefährliche Schwachstellen zu beheben. Damit wären alle Kriterien erfüllt, Ihr Compliance-Beauftragter wäre sehr zufrieden, und Sie könnten sich wieder Ihren normalen Tätigkeiten widmen.
Bedenken Sie nun, dass die Schwachstelle tatsächlich im Januar dem OpenSSH-Team gemeldet wurde und dass es Nachrichten in der öffentlichen Mailingliste um den 15. Januar herum ausgetauscht wurden. Dies fügt weitere zwei Wochen an öffentlichen Informationen über einen potenziell absturzverursachenden Fehler hinzu, bevor die tatsächliche CVE-Enthüllung stattfand. Und das ist nur der sichtbare Aspekt eines Bug-that-spawns-a-CVE. Der Zeitrahmen kann ganz anders aussehen, wenn der Fehler nicht von Anfang an an das richtige Team gemeldet wurde. Zum Beispiel, wenn er als Zero-Day-Exploit irgendwo in einem zwielichtigen Forum verkauft wurde. Im Falle dieser speziellen Schwachstelle wären Sie, selbst wenn Sie sie an dem Tag, an dem die CVE bekannt gegeben wurde, gepatcht hätten, möglicherweise bereits zwei Wochen lang gefährdet gewesen.
Überbewertete CVEs
Also bedeutet "rechtzeitig" eigentlich "seit er offiziell veröffentlicht wurde" oder "seit er mit einer CVE-Nummer versehen wurde", nicht wirklich "seit er bekannt ist". Es gibt Situationen, in denen die ersten Informationen über einen Fehler schon Monate vor dem Erscheinen eines CVEs bekannt werden. Haben Sie sich jemals gefragt, warum einige CVEs einen Jahresindikator aus dem Jahr davor haben? Das liegt daran, dass sie im Vorjahr gefunden wurden und der gesamte Prozess von der Analyse über die Erstellung von Patches bis zur Veröffentlichung mehrere Monate dauerte. Und dieser Prozess findet oft in der Öffentlichkeit unter dem Deckmantel von Fehlerberichten und Diskussionen auf Github oder Mailinglisten statt.
Und hier kann das Gespräch entgleisen - man kann kein unsicheres System haben, wenn es nicht einmal ein CVE gibt, damit Sie davon wissen, richtig? Das ist leider die falsche Frage.
Nicht allen Sicherheitslücken sind CVEs zugeordnet. So stellt das Kernel-Sicherheitsteam beispielsweise jede Woche Korrekturen für neue Schwachstellen vor, ohne dass diesen jemals (öffentlich bekannte) CVEs zugewiesen wurden - zum Teil, weil dies böswilligen Akteuren einen Vektor für ungepatchte Systeme bieten würde, und zum Teil, weil das CVE-System selbst eine Reihe von Ineffizienzen aufweist. Mehr darüber erfahren Sie hier.
Die Cybersicherheitsbranche ist auf CVEs fokussiert. Wir erstellen, verfolgen, priorisieren, patchen und entwickeln Strategien, um diejenigen zu umgehen, die wir nicht patchen können - aber CVEs sind nur die Spitze des sprichwörtlichen Eisbergs.
Minimierung des Risikofensters
Wenn Ihr einziger Maßstab für die Sicherheit die Anzahl der CVEs ist, die Sie innerhalb eines bestimmten Zeitrahmens patchen, um z. B. die Compliance-Anforderungen zu erfüllen, dann sind Sie wahrscheinlich weniger "sicher" als Sie denken. Das Risikofenster beginnt nicht, wenn ein CVE bekannt gegeben wird, sondern irgendwann vorher, und wie lange das ist, ist ungewiss, so dass Sie am besten versuchen, das Risikofenster so weit wie möglich zu verkürzen. Sie haben nur die Kontrolle über die Schließzeit des Risikofensters. Dieses implizite Risiko spricht Bände, wenn Unternehmen einen Monat oder länger brauchen, um Patches zu installieren - und das zusätzlich zu allem anderen, was vorher passiert.
Natürlich ist es nicht möglich, etwas zu patchen, bevor der Patch herauskommt, aber es sollten alle Schritte unternommen werden, um sicherzustellen, dass Sie so schnell wie möglich patchen, anstatt Wochen zu brauchen, um eine neue Sicherheitslücke zu schließen.
Die (manchmal lange) Zeitspanne, bis eine Schwachstelle tatsächlich bekannt wird, sollte der beste Grund für ein schnelleres Vorgehen beim Patchen sein. Bedrohungsakteure überwachen aktiv Bug-Meldungen auf der Suche nach neuen Gelegenheiten und verfügen über die erforderlichen Fähigkeiten, um Bugs schnell als "Waffe" einzusetzen.
Helfen Sie den Hackern nicht - sie brauchen es nicht. Jetzt patchen.
