Das Patching-Paradoxon: Die Realität der KI in der IT-Sicherheit

Eine Warnung von einem Hacker eines Blue-Team-Unternehmens

Hören wir auf, so zu tun, als würde die KI die IT-Sicherheit retten. Sicher, sie wird helfen – das tut sie bereits. Aber die Vorstellung, dass Sicherheitsteams irgendwie mit den Angreifern „mithalten“ können, nur weil sie beide Zugang zu generativer KI haben, ist ein Hirngespinst.

Ich komme aus einer Red-Team-Perspektive. Ich habe Jahre damit verbracht, wie ein Angreifer zu denken. Jetzt arbeite ich in einem Blue-Team-Unternehmen und versuche, echte Systeme zu verteidigen. Und Folgendes ist für mich offensichtlich:

Die KI lässt Angreifer schneller vorrücken. Und die Verteidiger können immer noch nicht patchen.

Das ist der Engpass. Das ist die Schwachstelle in diesem Plan. Mit KI-gestützten Patches lassen sich keine fragilen, 15 Jahre alten Codebasen reparieren, die über Tausende von Assets, Teams und Genehmigungsketten zusammengeklebt sind. Die gleichen Probleme, die uns 2015 ausgebremst haben, sind immer noch da. Und sie sind dabei, zur Waffe zu werden – für Angreifer.

KI wird Sie nicht von der Last alter Technologien retten

In der Welt der Sicherheit gibt es derzeit die glänzende Hoffnung, dass wir dem Schwachstellenmanagement etwas KI verpassen und standardmäßig sichere Software liefern werden.

Aber in Wirklichkeit ist dies der Zustand von realen Unternehmensumgebungen.

• End-of-Life-Systeme sind noch in Produktion.
  
• Fragile Integrationen, die bei jedem Betriebssystem-Update kaputt gehen.
  
• Eine Firmware, die seit sechs Jahren nicht mehr angerührt wurde.
  
• OT-Netzwerke, auf denen das nicht patchbare Windows XP läuft.
  

Man kann sich nicht durch KI aus den Tech-Altlasten herauswinden.

Sicherheit ist Beobachtbarkeit. Beobachtbarkeit ist Sicherheit. Wenn Sie es nicht sehen können, können Sie es nicht verteidigen. Und wenn Sie es nicht patchen können, dann ist es nicht sicher, egal wie viele Dashboards Sie haben.

Dies ist im Wesentlichen ein Architekturproblem. Besonders bei älteren Systemen. Es handelt sich um einen Designfehler, der nun in großem Umfang behoben werden muss, und die KI wird uns kein Zaubermittel für unzuverlässige Software aus der Prä-Cloud-Ära schreiben.

Infrastructure-as-Code (IaC) und Kubernetes: Keine Wunderwaffe

Sprechen wir nun über den modernen Stack, wie Infrastructure-as-Code, Kubernetes und Container. Hier sollten wir es richtig machen, nicht wahr?

Ich denke schon.

Ja, IaC und K8s bieten uns die Möglichkeit eines konsistenten, schnellen und sicheren Patchings. Aber nur, wenn wir sie auf diese Weise nutzen. Und wissen Sie was?

Die meisten Unternehmen tun das nicht.

Sie wären erstaunt, wie viele Kubernetes-Cluster immer noch manuell konfiguriert werden, mit YAML, das aus Blogbeiträgen von vor zwei Jahren kopiert wurde. IaC-Vorlagen verrotten wie jeder andere Code – und wenn sie das tun, werden sie zu einer weiteren Belastung.

• Cluster, die ohne RBAC-Kontrollen hochgefahren werden.
  
• Images, die auf nicht gepatchten Basisebenen basieren.
  
• In Helm-Charts eingebettete Secrets.
  
• Terraform-Statusdateien, die in Public Buckets liegen.
  

Wir haben das Versprechen einer flüchtigen, neu verteilbaren Infrastruktur genommen und sie wie ein weiteres statisches Rechenzentrum behandelt. Das ist eine verpasste Chance – und eine Sicherheitskatastrophe, die nur darauf wartet, zu passieren.

Wenn Sie möchten, dass KI Ihnen beim Patchen Ihrer Kubernetes-Umgebung hilft, brauchen Sie zunächst eine saubere, versionierte und gut gepflegte IaC-Basislinie. Und Sie brauchen Teams, die sie tatsächlich nutzen. Das ist keine Selbstverständlichkeit.

Moderne Tools werden Sie nicht vor alten Gewohnheiten bewahren. Sie verschlimmern nur die Auswirkungen, wenn etwas schief geht.

Der Teamwechsel hat die Architektur mitgenommen

Vergessen wir nicht eine weitere brutale Wahrheit: Entlassungen und Teamfluktuation nehmen zu.

IIn den letzten Jahren standen Teamwechsel und Entlassungen immer wieder in den Schlagzeilen. Ob durch Personalabbau oder Umstrukturierungen, Organisationen haben Menschen verloren, die die interne Architektur tatsächlich verstehen. Die, die wussten, warum diese Integration so funktioniert. Die sich an den maßgeschneiderten Patch für eine vergessene Library erinnerten. Die in der Lage waren, einen defekten Authentifizierungsprozess über vier Services hinweg nachzuvollziehen, ohne einen zweiwöchigen Ticketzyklus.

Sie sind weg.

Und mit ihnen? Das gesammelte Wissen? Auch weg. Es wurde nicht dokumentiert. Es war nicht ersetzbar. Es lebte in Slack-Nachrichten, War Rooms und im menschlichen Gedächtnis.

Jetzt versucht man, Systeme zu patchen, die niemand mehr richtig versteht – und fragt sich, warum das Wochen dauert. Das ist kein technisches Versagen. Das ist eine organisatorische Frage.

Die KI kann das nicht beheben. Man kann institutionelle Erinnerungen nicht einfach abfragen.

Der stille Kompromiss der Sicherheitsbranche

Und seien wir ehrlich: Ein Teil davon geht auf unser Konto.

Viele Sicherheitsunternehmen – insbesondere die großen – haben Produktisierung und Profit über den eigentlichen Auftrag gestellt: Systeme wirklich sicher zu machen. Wir haben Plattformen, Dashboards und Alerts gebaut. Aber das grundlegende Problem – Patchen und architektonische Fragilität – wurde nicht gelöst, weil es sich nicht gut vorführen lässt.

Es gibt keine auffällige, knallbunte Bedienoberfläche für „Wir haben ein Jahr lang technische Altlasten beseitigt.“

Sie bekommen keinen Stand auf der RSA für „Wir haben den Patching-Prozess für 4.000 Endpunkte um 20 % beschleunigt.“

Aber genau dort findet der Kampf statt.

Diese Kluft zwischen dem Wissen, dass ein System verwundbar ist, und der Möglichkeit, es zu reparieren, ist der wahre Krieg, und er ist nicht ruhmreich.

Kommen wir zum eigentlichen Handlungsbedarf

Wir müssen uns der unbequemen Wahrheit stellen: Unsere größte Schwäche ist operativ, nicht informativ.

Man kann alles wissen, alles sehen, auf alles achten – und trotzdem erwischt werden, weil man nicht schnell genug patchen konnte.

Was sollen wir also tun?

1. Beenden wir das Narrativ des „Unpatchbaren“. Wenn es kritisch ist und nicht aktualisiert werden kann, muss es ersetzt, isoliert oder abgeschaltet werden. Hören wir auf, Systeme zu bauen, in denen Patchen = Ausfallzeit = Geschäftsrisiko bedeutet.
   
2. Reparieren wir unser Organigramm, bevor wir unsere Tools reparieren. Silos zwischen Security, Ops, Development und Compliance verlangsamen Reaktionszeiten. KI wird das nicht lösen. Kommunikation schon.
   
3. Verlangen wir standardmäßig sichere Software. Setzen wir die Anbieter unter Druck, patchbare, modulare und automatisch aktualisierbare Komponenten zu liefern. Akzeptieren wir keine Ausreden mehr.
   
4. Automatisieren wir dort, wo es zählt. Nicht noch mehr Dashboards – automatisieren wir Patch-Validierung, Rollouts und Reboots. Wenn die KI Shell-Skripte schreibt, dann solche, die patchen.
   
5. Entwerfen wir Systeme mit Blick auf Fehler. Gehen wir davon aus, dass sich das Patchen verzögern wird. Bauen wir Eindämmung, Segmentierung und Rollback in die Architektur selbst ein.
   
6. Belohnen wir Teams für die Verringerung von Risiken, nicht nur für mehr Steuerungsmöglichkeiten. Das Patchen von 10.000 Endpunkten ohne Schlagzeilen ist ein größerer Gewinn als eine weitere glänzende KI-Funktion.
   

Schlusswort

Angreifer hatten schon immer den Geschwindigkeitsvorteil. KI hat das nur verschlimmert. Verteidiger stecken immer noch fest und versuchen, Patches durch Change-Management-Prozesse zu schieben, während Angreifer in Echtzeit polymorphe Exploits generieren.

Es geht nicht um Tools. Nicht um Threat Intelligence. Es geht darum, dass wir immer noch nicht das älteste Problem der Sicherheit gelöst haben: Wie man etwas repariert, nachdem man das Problem gefunden hat.

Wenn wir diese KI-Welle überleben wollen, müssen wir das Patchen als strategische Priorität behandeln – nicht als operative Belastung. Und wir müssen jetzt handeln.

Denn die Angreifer warten nicht. Das haben sie noch nie.

Was können wir also tun? Der erste Schritt ist die Implementierung eines effektiven Sicherheitsprogramms, eine gute Protokollierung und eine Cloud-SIEM-Lösung wie Sumo Logic. Aber um dieses Problem wirklich zu lösen, brauchen wir kluge Menschen wie Sie, die dieses Problem lösen und hoffentlich der Community helfen. Ich habe einige Antworten für einen weiteren Blog, aber sie werden Ihnen nicht gefallen.