Blog Warum Sie Ihre Patch-Management-Strategie jetzt ändern müssen | Insight

Exploits verbreiten sich heute in Stunden, nicht in Tagen. Die Frage ist nicht, ob es zu einer Unterbrechung kommt, sondern ob sie zu Ihren oder zu deren Bedingungen stattfindet.

Vor ein paar Wochen war ich mitten in einem Meeting, als mein Laptop beschloss, dass er nicht länger auf mich warten würde. Ich hatte dasselbe Patch-Update ein Mal zu oft aufgeschoben, und genau da, mitten im Satz, fuhr er herunter. Kein „Später erinnern“ mehr. Keine Möglichkeit zur Verzögerung.

Und die Sache ist die: Ich konnte nicht einmal wütend darüber sein. Ich schnappte mir mein Handy, wählte mich wieder ins Meeting ein und machte weiter. Denn diese Richtlinie (die gerade meinen Anruf unterbrochen hatte) ist genau dieselbe, von der ich Sicherheitsverantwortlichen immer sage, dass sie sie übernehmen müssen: Unterbrechungen zu den eigenen Bedingungen erzwingen, nicht zu denen von jemand anderem.

Patchen „nach der Uhr“ bedeutet, kritische Schwachstellen wie aktive Vorfälle zu behandeln – gemessen in Stunden für die Reaktion, nicht in vorgeschriebenen Tagen auf einem Kalender.

Und wenn ich unsere Kunden bitte, ihre Patch-Strategie zu überdenken, sollte ich das besser auch selbst vorleben.

Daher erkläre ich das Sicherheitsverantwortlichen in letzter Zeit so:

Der Schieberegler in meinem Kopf 

Dieses Bild kam mir während eines Mittagessens mit einem Sicherheitsverantwortlichen auf der Cisco Live in den Sinn, und seitdem lässt es mich nicht mehr los. Stellen Sie sich einen Schieberegler vor. An einem Ende steht die betriebliche Auswirkung: das Risiko, Ihr Geschäft zu unterbrechen. Am anderen Ende steht der Sicherheitsvorfall: das Risiko, gehackt zu werden. Jedes Unternehmen befindet sich irgendwo auf dieser Skala, ob es sich dessen bewusst ist oder nicht, und wo Sie stehen, verrät alles darüber, wie Sie über Risiken denken.

Hier ist, was die meisten Unternehmen seit Jahren signalisieren. Wenn man einen 90-tägigen Patch-Zyklus durchführt (und ich bin ehrlich, das war vor nicht allzu langer Zeit auch unser Rhythmus bei Insight), geht man eine Wette ein. Man sagt damit: „Ich gehe lieber das Risiko eines Cybersicherheitsvorfalls ein, als zu riskieren, die Produktion lahmzulegen, um einen Patch einzuspielen.“ Man hat seinen Schieberegler fest auf der Seite des Schutzes des laufenden Betriebs positioniert. Man hat das Gefühl, dass ein Sicherheitsvorfall das unwahrscheinlichere Ergebnis ist, also optimiert man gegen die Unterbrechung, die man kommen sieht.

Ich verstehe diesen Instinkt vollkommen. Wir lieben unsere Prozesse. Wir lieben unsere Change-Zeitfenster, unsere CAB-Reviews, unsere Kontrollen; sie existieren, um uns abzusichern und den IT-Betrieb vorhersehbar zu machen. Aber Mythos und andere fortschrittliche KI-Modelle haben die Quoten dieser Wette still und heimlich verschoben, und viele Führungskräfte haben noch nicht darauf reagiert und ihren Risiko-Schieberegler verschoben.

Der Teil, den alle übersehen 

Hier ist, was mein eigenes Denken verändert hat. Wenn das Zeitfenster zwischen der Offenlegung einer Schwachstelle und dem Auftauchen eines Exploits in freier Wildbahn von Tagen auf Stunden (und irgendwann in nicht allzu ferner Zukunft auf Minuten) schrumpft, ist der Sicherheitsvorfall nicht mehr das unwahrscheinliche Ergebnis. Er wird zum unmittelbar bevorstehenden.

Und – das ist der Punkt, den man wirklich auf sich wirken lassen muss – ein Sicherheitsvorfall ist ebenfalls ein Produktionsausfall. Man kann die Unterbrechung nicht vermeiden, indem man nicht patcht. Man tauscht nur die eine Art gegen die andere ein.

Wenn man zu seinen eigenen Bedingungen patcht, ist die Unterbrechung geplant und kontrolliert. Man hat sie terminiert. Man hat seine Leute in Bereitschaft. Man hat Rollback-Tools parat. Wenn etwas schiefgeht, behebt man es und macht weiter.

Wenn man gehackt wird, hat man immer noch einen Ausfall, aber jetzt ist er ungeplant. Er kommt unerwartet, er schlägt nachts um 2 Uhr zu, wenn man nicht das nötige Personal hat, und er ist böswillig. Die Person, die ihn verursacht hat, hat ein begründetes Interesse daran, dass man am Boden bleibt, und nicht daran, einem wieder aufzuhelfen. Das ist das komplette Umdenken: geplant und kontrolliert versus unerwartet und böswillig.

Man entscheidet nicht mehr darüber, ob man unterbrochen wird. Man entscheidet nur noch darüber, zu wessen Bedingungen es passiert.

Zwei Modi, dieselbe Schwachstelle 

Aus diesem Grund habe ich angefangen, über das Patchen als Vorfall und nicht als Wartungsaufgabe zu sprechen. Dieselbe CVE (Schwachstelle), eine völlig andere Herangehensweise.

Im Wartungsmodell lautet die Frage, die wir stellen: „Wird dieser Patch die Produktion lahmlegen?“ Wir messen den Erfolg am Prozentsatz der abgedeckten Systeme, und die Uhr tickt in Wochen oder Monaten. Im Vorfallsmodell (Incident-Modell) ändert sich die Frage zu: „Wie groß ist der Explosionsradius, wenn wir das nicht patchen?“ Wir messen den Erfolg an der mittleren Zeit bis zur Behebung (Mean Time to Remediation), und die Uhr tickt in Stunden. Wenn die Ausnutzung von Schwachstellen nur noch Stunden dauert, ist ein monatliches Wartungsfenster kein Prozess mehr, sondern ein Risiko, das Ihre operationelle Gefährdung erhöht.

Jetzt sprechen wir darüber, Patches über dieselbe Art von Workflow bereitzustellen, die man von einem traditionellen Cybersicherheitsvorfall erwarten würde: Erkennen, Einstufen (Triage), Eindämmen, Beheben, Validieren. Wir erfassen die Offenlegung durch kontinuierliches Threat Exposure Management, finden heraus, wo überall in der IT-Landschaft sie existiert, nutzen maschinelles Lernen, um zu bewerten, wie wahrscheinlich es ist, dass sie in ihrer spezifischen Umgebung tatsächlich ausgenutzt wird, und validieren das mit kontinuierlichen Penetrationstests. Wenn es sich um eine hohe bis kritische Schwachstelle handelt, startet eine SLA-Uhr und unsere Response-Teams setzen sich sofort in Bewegung.

Es geht nicht darum, alles in dem Moment zu patchen, in dem es offengelegt wird. Es geht darum, die kleine Teilmenge von Schwachstellen zu finden, die ein echtes, ausnutzbares Risiko in Ihrer Umgebung darstellen, und diese mit der Dringlichkeit eines Vorfalls zu behandeln.

Wie sieht das also an einem Dienstagmorgen aus? 

Anstatt auf den nächsten Patch-Zyklus zu warten, löst eine kritische, von außen zugängliche Schwachstelle einen sofortigen Workflow aus: Das Sicherheitsteam markiert sie, validiert die Gefährdung und leitet das Patchen innerhalb von Stunden ein – genau wie bei einem aktiven Vorfall.

Der kontraintuitive Gewinn 

Wenn Sie nun ein Operations-Leader sind, schrillen bei Ihnen die Alarmglocken: Häufigeres Patchen bedeutet mehr Unterbrechungen, richtig?

Tatsächlich ist das Gegenteil der Fall, und das ist das Argument, das CISOs ihren Operations- und Geschäftspartnern vorlegen sollten. Einer der Hauptgründe, warum Patch-Fenster platzen, ist, dass wir Patches in der Warteschlange sammeln und dann Dutzende davon gleichzeitig in Dutzende von Subsystemen pushen. Wenn man dazu übergeht, in Echtzeit zu reagieren, patcht man ein einzelnes betroffenes Modul für sich allein. Die Wahrscheinlichkeit einer bösen Überraschung im weiteren Verlauf sinkt drastisch. Man macht kleinere, kontrolliertere und gezieltere Schritte und reduziert dabei das operationelle Risiko.

Das ist eine Veränderung der Arbeitsweise 

Ich werde nicht so tun, als wäre die Technologie der schwierige Teil. Das ist sie nicht. Der schwierige Teil ist organisatorischer Natur. Man muss bereit sein, mit den alten Mustern zu brechen, wie man das Patchen bisher immer angegangen ist, und man muss echte Hochverfügbarkeit in seine Systeme einbauen, denn man kann unter diesem Modell keine großen monolithischen Anwendungen betreiben, ohne diese kritische Anwendung jeden einzelnen Tag zu riskieren. Das ist eine andere Art, über Architektur nachzudenken, und es ist ein Gespräch, das weit über das Sicherheitsteam hinausgehen muss.

Ich lasse Sie mit derselben Frage zurück, auf die ich immer wieder zurückkomme. Sie werden eine gewisse Unterbrechung in Kauf nehmen müssen; dieser Teil ist nicht mehr optional. Das Einzige, was Sie entscheiden können, ist, ob sie geplant und zu Ihren Bedingungen stattfindet, oder ungeplant und zu deren Bedingungen.

Bei Insight haben wir uns selbst zum „Client Zero“ für diesen radikalen Wandel in der Herangehensweise an das Patchen von IT-Systemen gemacht. Wir standen vor demselben existenziellen Wandel wie alle anderen, haben unseren Ansatz für Sicherheit und IT-Betrieb darum herum neu aufgebaut und ihn dann zu unseren Kunden gebracht. Denn es spielt eigentlich keine Rolle, wer Zugang zu Mythos hat. Es existiert. Und es existiert mit der Aussicht auf die Veröffentlichung ähnlich fähiger Modelle, von denen einige nicht von den „Guten“ entwickelt werden.

Was zählt, ist, ob Sie erkannt haben, dass sich die Art und Weise, wie Sie ihr Unternehmen verteidigen, grundlegend verändert hat – und dass Sie ihren Schieberegler bewegen, bevor ihn jemand für Sie bewegt.