In der ersten Folge unserer STRIVE-Reihe zum Thema digitale Souveränität haben Alex Zinin von Commvault und Max Mortillaro von der Osmium Data Group eines der größten Missverständnisse der Branche hinterfragt: Digitale Souveränität ist keine Funktion, die man einfach kaufen kann – es handelt sich vielmehr um ein geschäftliches Problem, das man erst verstehen muss, bevor man es lösen kann.

Dieses Gespräch knüpft an das vorherige an. Dieses Mal habe ich mich mit Thomas Maurer, EMEA Global Black Belt für „Sovereign Cloud “ bei Microsoft, zusammengesetzt, um zu erörtern, was geschieht, wenn ein Unternehmen beschließt, dass Souveränität eine wichtige Rolle spielt. Wie setzen Führungsteams allgemeine Bedenken hinsichtlich Regulierung, Rechtshoheit oder geopolitischer Unsicherheiten in konkrete architektonische Entscheidungen um?

Wie sich herausstellt, ist die Antwort selten so einfach wie die Wahl eines Anbieters für „ cloud “ oder die Auswahl des richtigen Bereitstellungsmodells. Es geht vielmehr darum, vor technischen Entscheidungen die richtigen Fragen zu stellen. Die ganze Folge ansehen.

Die wichtigsten Erkenntnisse

• Jede Organisation definiert digitale Souveränität anders – und genau hier sollte die Diskussion ansetzen.
• Die Frage der Souveränität lässt sich nicht allein durch Technologie lösen. Rechtliche, operative, architektonische und geschäftliche Aspekte beeinflussen das Ergebnis gleichermaßen.
• Cloud „Cloud“ und „On-Premises“ sind keine konkurrierenden Strategien. Für viele Unternehmen liegt die Zukunft in einer sorgfältig durchdachten Kombination aus beidem.
• Risikomanagement – und nicht Angst – sollte die Grundlage für souveräne Entscheidungen bilden.
• Gute Architektur beginnt damit, die geschäftlichen Anforderungen zu verstehen – und nicht damit, eine Infrastruktur auszuwählen.

Der Begriff „Souveränität“ hat für verschiedene Organisationen unterschiedliche Bedeutungen

Eine der ersten Beobachtungen, die Thomas machte, war zugleich eine der wichtigsten. Es gibt keine allgemeingültige Definition für digitale Souveränität. Für ein Unternehmen kann dies einfach bedeuten, regulatorische Anforderungen zu erfüllen oder Daten innerhalb einer bestimmten geografischen Region zu halten. Für ein anderes kann es um operative Unabhängigkeit, Geschäftskontinuität oder die Vorbereitung auf geopolitische Störungen gehen. Dieser Unterschied ist von Bedeutung, da er die Diskussion grundlegend verändert.

Allzu oft gehen Unternehmen davon aus, dass es einen Standardplan für die Souveränität gibt, der nur noch umgesetzt werden muss. In Wirklichkeit besteht die erste Herausforderung nicht darin, eine Technologie auszuwählen, sondern zu verstehen, welches Problem das Unternehmen tatsächlich zu lösen versucht. Erst dann ergibt Architektur einen Sinn.

Technologie sollte der Strategie folgen

Ein Thema, das im Laufe unserer Diskussion immer wieder zur Sprache kam, war die Versuchung, sich direkt in die technische Planung zu stürzen. Das ist verständlich. Architekten beschäftigen sich naturgemäß mit Infrastruktur, Arbeitslasten, Konnektivität und Bereitstellungsmodellen. Thomas betonte jedoch, dass die erfolgreichsten Projekte an einer ganz anderen Stelle beginnen. Zunächst hören sie zu.

Welche Anliegen treiben die Initiative an? Ist das Ziel die Einhaltung gesetzlicher Vorschriften? Geschäftskontinuität? Datenstandort? Operative Kontrolle? Schutz vor geopolitischen Störungen? Unterschiedliche Antworten führen zu unterschiedlichen Architekturen. Das mag selbstverständlich klingen, doch es ist überraschend, wie oft Unternehmen mit der Bewertung von Lösungen beginnen, bevor sie sich über das angestrebte Geschäftsergebnis geeinigt haben.

Vorschau: Beginnen Sie mit Risiken, nicht mit Annahmen

Einer der praktischsten Momente in unserem Gespräch ist der, in dem Thomas und ich darüber sprechen, warum Initiativen zur Souveränität mit einer Risikobewertung beginnen sollten – und nicht mit einem Architekturdiagramm.

Jede Organisation hat eine andere Risikobereitschaft. Ein Formel-1-Team, eine Regierungsbehörde und ein global tätiger Hersteller werden nicht dieselben Entscheidungen treffen – und das sollten sie auch nicht. Entscheidend ist, zu verstehen, welche Risiken für Ihr Unternehmen am wichtigsten sind, welche Kompromisse Sie bereit sind einzugehen, und dann eine Architektur zu entwerfen, die diese Entscheidungen unterstützt.

Wie Thomas betont, gibt es keine perfekte Lösung – sondern nur fundierte Kompromisse. Je früher Organisationen diese Denkweise verinnerlichen, desto stärker wird ihre Souveränitätsstrategie sein.

„Cloud oder On-Premises?“ – Das ist die falsche Frage

Einer der interessanteren Aspekte des Gesprächs stellte eine weitere weit verbreitete Annahme in Frage – nämlich, dass Unternehmen sich zwischen einer öffentlichen cloud und einer privaten Infrastruktur entscheiden müssen. Thomas schilderte eine ganz andere Realität. Viele Unternehmen ersetzen nicht das eine durch das andere. Sie gestalten Umgebungen, in denen Workloads je nach geschäftlichem Bedarf, regulatorischen Anforderungen oder Überlegungen zur Ausfallsicherheit zwischen den beiden Umgebungen verschoben werden können.

Diese Flexibilität verändert die Art und Weise, wie wir über Architektur nachdenken sollten. Anstatt zu fragen, ob Cloud oder On-Premises besser ist, lautet die sinnvollere Frage: „Wo gehört diese Workload heute hin – und könnte sich diese Antwort morgen ändern?“ Wenn Souveränität Teil des Entwurfsprozesses wird, gewinnt die Mobilität von Workloads ebenso an Bedeutung wie deren Platzierung.

Architektur ist nur ein Teil des Ganzen

Ein weiterer Punkt, den ich sehr schätze, ist Thomas’ Hinweis darauf, dass Architektur allein die Frage der Souveränität nicht löst.

• Verträge sind wichtig.
• Rechtliche Rahmenbedingungen sind wichtig.
• Betriebliche Abläufe sind wichtig.
• Die Menschen, die für den Umgang mit der Umwelt verantwortlich sind, spielen eine wichtige Rolle.

Keine dieser Disziplinen kann isoliert agieren. Souveränität setzt voraus, dass die Teams aus den Bereichen Recht, Sicherheit, Compliance und Infrastruktur von Anfang an zusammenarbeiten – und nicht erst dann Projekte aneinander weiterreichen, wenn die Entscheidungen bereits getroffen wurden. Das ist ein bekanntes Muster für alle, die im Bereich Cyber-Resilienz tätig sind. Die besten Ergebnisse werden selten von einzelnen Teams erzielt. Sie entstehen durch koordiniertes Vorgehen.

Jede Entscheidung sollte vom Risiko geleitet sein

Gegen Ende unserer Diskussion verlagerte sich das Gespräch ganz natürlich auf das Thema Risk. Für mich wird das Konzept der Souveränität an dieser Stelle deutlich vertrauter. Jedes Resilienzprojekt beginnt mit der Frage, was die Organisation zu schützen versucht, welche Bedrohungen am wichtigsten sind und wie viel Risk sie bereit ist, in Kauf zu nehmen.

Bei der digitalen Souveränität verhält es sich nicht anders. Anstatt nach einer perfekten Lösung zu suchen, müssen Unternehmen die konkreten Szenarien im Bereich der Souveränität identifizieren, die ihnen Sorge bereiten, und anschließend ermitteln, welche architektonischen, betrieblichen oder vertraglichen Kontrollmaßnahmen diesen Risiken am besten begegnen. Dieser Wandel – vom Vergleich von Funktionen hin zum Risikomanagement – führt letztendlich zu besseren Entscheidungen.

Warum dieses Gespräch wichtig ist

Die digitale Souveränität entwickelt sich weiterhin rasant weiter. Es werden neue Vorschriften entstehen. Die Technologie wird sich verändern. Die geopolitischen Gegebenheiten werden sich weiter verschieben. Das bedeutet, dass das Thema Souveränität nicht etwas ist, das Unternehmen einmalig regeln. Es ist etwas, das sie regelmäßig neu bewerten, wenn sich geschäftliche Prioritäten und externe Risiken ändern.

Die Unternehmen, die erfolgreich sind, verfügen nicht unbedingt über die restriktivsten Architekturen. Sie zeichnen sich vielmehr durch ein klares Verständnis ihrer Geschäftsziele, die Disziplin zur sorgfältigen Risikobewertung und die Flexibilität aus, sich an veränderte Risiken anzupassen. Letztendlich ist digitale Souveränität nichts, was Unternehmen einfach von der Stange kaufen können. Es geht darum, Risiken zu verstehen, Abhängigkeiten zu steuern und fundierte Abwägungen zu treffen – und zwar lange bevor diese Entscheidungen auf die Probe gestellt werden.

Die ganze Folge ansehen

In dieser STRIVE-Folge sprechen Thomas und ich über:

• Warum der Begriff „Souveränität“ für verschiedene Organisationen unterschiedliche Bedeutungen hat.
• Wie Führungskräfte die Souveränitätsstrategie angehen sollten.
• Öffentliches cloud versus privates cloud – und warum es oft keine Entweder-oder-Entscheidung ist.
• Warum das Risikomanagement die architektonischen Entscheidungen leiten sollte.
• Die Rolle der Resilienz in der modernen Souveränitätsplanung.

Jetzt anschauen.

FAQs

Frage: Bedeutet digitale Souveränität, dass alles vor Ort gespeichert wird?

A: Nein. Viele Organisationen verfolgen hybride Ansätze, bei denen die Funktionen von „ cloud “ mit spezifischen Anforderungen an die Souveränität in Einklang gebracht werden.

Frage: Wo sollten Souveränitätsprojekte ansetzen?

A: Beginnen Sie damit, das geschäftliche Problem zu definieren und die Risiken zu erfassen, die Sie mindern möchten, bevor Sie die Technologie bewerten.

Frage: Ist Souveränität eine rein technische Frage?

A: Nein. Dies erfordert die Zusammenarbeit zwischen den Teams aus den Bereichen Recht, Compliance, Sicherheit, Betrieb und Architektur.

F: In welchem Zusammenhang stehen Souveränität und Resilienz?

A: Beide Disziplinen zielen darauf ab, die Geschäftskontinuität zu gewährleisten, indem sie die Risiken minimieren, die den Geschäftsbetrieb stören könnten.

Frage: Was ist ein großer Fehler, den Unternehmen im Hinblick auf die digitale Souveränität begehen?

A: Sich voreilig auf architektonische Entscheidungen festzulegen, bevor man sich darüber einig ist, was Souveränität für die eigene Organisation bedeutet.

F: Was sollten Führungskräfte bei der Planung im Hinblick auf die digitale Souveränität als Erstes fragen?

A: „Welches Problem wollen wir lösen?“ Alles andere ergibt sich aus dieser Antwort.

Darren Thomson ist Vizepräsident und Chief Technology Officer für die Region EMEA bei Commvault.

Seit Jahren wird Cyber-Resilienz durch Technologie definiert – Sicherheitsmaßnahmen, ausgefeilte Erkennungsfunktionen und immer robustere Backup-Strategien, die darauf ausgelegt sind, Angriffe zu verhindern oder eine schnellere Wiederherstellung zu ermöglichen. Diese Investitionen sind nach wie vor unverzichtbar, reichen aber nicht mehr aus. Künstliche Intelligenz (KI) hat die Natur von Cyberangriffen grundlegend verändert; diese vollziehen sich mittlerweile in einem Tempo, das selbst etablierte Unternehmen vor Herausforderungen stellt. Da sich das Zeitfenster zwischen einer Kompromittierung und einer Betriebsunterbrechung immer weiter verkürzt, geht es bei der Resilienz weniger darum, jeden Angriff zu verhindern, als vielmehr darum, den Geschäftsbetrieb aufrechtzuerhalten, wenn die Prävention unvermeidlich versagt.

Dieser Wandel steht im Mittelpunkt des neuen IDC-Berichts „Resilience Operations: The Discipline that Makes Readiness Provable“. Basierend auf einer Umfrage unter mehr als 500 nordamerikanischen Unternehmen kommt der Bericht zu dem Schluss, dass sich Resilienz zu einer funktionsübergreifenden Betriebsdisziplin entwickelt, die geschäftliche Prioritäten mit Cybersicherheit, ITOps und Notfallwiederherstellung verknüpft. Vor allem aber deckt er mehrere Lücken auf, die darauf hindeuten, dass sich viele Unternehmen immer noch auf eine Bedrohungslandschaft vorbereiten, die es gar nicht mehr gibt. Hier sind die wichtigsten Erkenntnisse. 

Die Wiederherstellung sollte bei den geschäftlichen Zielen ansetzen – nicht bei den technischen.

In der Vergangenheit lag der Schwerpunkt bei der Notfallplanung auf der schnellstmöglichen Wiederherstellung der Infrastruktur, wobei der Erfolg anhand von Wiederherstellungszeitzielen, Backup-Abschlussraten und der Verfügbarkeit von Anwendungen gemessen wurde. Diese Kennzahlen sind zwar nach wie vor wertvoll, geben jedoch nicht unbedingt Antwort auf die Frage, die Führungskräften am meisten am Herzen liegt: Wann können wir den Geschäftsbetrieb wieder aufnehmen? 

IDC vertritt die Ansicht, dass Resilienz eher an geschäftlichen Ergebnissen als an technischen Meilensteinen ausgerichtet sein sollte – nämlich an der Wiederherstellung der Fähigkeiten, die es dem Unternehmen ermöglichen, Kunden zu bedienen, Umsatz zu generieren und seinen Verpflichtungen nachzukommen. Das mag nach Semantik klingen, verändert jedoch die Art und Weise, wie Prioritäten bei der Wiederherstellung festgelegt werden. Technologie wird zum Mittel zum Zweck und nicht zum Selbstzweck. 

Die meisten Organisationen haben noch immer nicht definiert, was am wichtigsten ist.

Fast 6 von 10 Unternehmen haben ihr „Minimum Viable Business“ (MVB) noch nicht vollständig definiert. – also die kleinste Menge an Funktionen, Systemen, Prozessen und Daten, die erforderlich ist, um den Betrieb nach einer Störung aufrechtzuerhalten. 

Ohne ein gemeinsames Verständnis dafür, wovon das Unternehmen wirklich abhängt, wird jede Maßnahme während der Wiederherstellung zu einer reaktiven Reaktion. Indem Sie Ihren MVB bereits vor einer Krise definieren, ermöglichen Sie schnellere Entscheidungen, eine bessere Koordination während der Wiederherstellung und letztlich eine widerstandsfähigere Organisation. 

Die Automatisierung wird zunehmend zur Trennlinie zwischen Widerstandsfähigkeit und Sanierungsschulden.

Während Angreifer die Erkundung, die Ausnutzung von Schwachstellen und die laterale Bewegung zunehmend automatisieren, setzen viele Unternehmen nach wie vor auf manuelle Wiederherstellungsprozesse. Dieses Ungleichgewicht lässt sich immer schwerer ignorieren. KI verkürzt die Zeiträume von Angriffen, doch die Zeiträume für die Recovery haben damit nicht Schritt gehalten. Unternehmen, denen es nicht gelingt, diese Recovery-Aufgaben zu automatisieren, verbringen möglicherweise Tage damit, Pläne zu erstellen und umzusetzen, während der Schaden bereits angerichtet ist. Die automatisierte Koordination der Wiederherstellung, die eindeutige Identifizierung von Wiederherstellungspunkten und die koordinierte Validierung entwickeln sich zu grundlegenden Funktionen, um die Wiederherstellung mit der Geschwindigkeit durchzuführen, die moderne Angriffe erfordern. 

Nicht die Technologie stellt die größte Herausforderung für die Widerstandsfähigkeit dar – sondern die organisatorische Abstimmung.

Sicherheitsteams konzentrieren sich auf die Eindämmung, Infrastrukturteams auf die Wiederherstellung, Führungskräfte auf die Auswirkungen auf die Kunden und Compliance-Teams auf die gesetzlichen Verpflichtungen. Keine dieser Prioritäten ist an sich falsch, doch wenn sie sich unabhängig voneinander entwickeln, geraten Unternehmen ohne ein gemeinsames Betriebsmodell in eine Krise. 

Hier kommt ResOps ins Spiel. Anstatt Resilienz als Aufgabe der IT zu betrachten, stellt der Bericht sie als eine Disziplin dar, die Geschäftsabläufe, Sicherheit, Infrastruktur und Wiederherstellungsplanung gezielt miteinander verbindet. Die Botschaft ist klar: Resilienz hängt weniger von einzelnen Tools ab als vielmehr davon, gemeinsame Prioritäten festzulegen, bevor ein Vorfall Sie dazu zwingt, schwierige Entscheidungen zu treffen. 

Das Testen ist nach wie vor einer der aussagekräftigsten Indikatoren für die Widerstandsfähigkeit.

IDC stellte fest, dass relativ wenige Unternehmen regelmäßig Tabletop-Übungen oder Cyber-Range-Simulationen durchführen, obwohl seit Jahrzehnten bekannt ist, dass solche Übungen die Leistung bei tatsächlichen Vorfällen durchweg verbessern. 

Übungen decken verborgene Abhängigkeiten auf, machen Kommunikationslücken sichtbar und ermöglichen es Teams, Entscheidungen zu treffen, ohne dass dies reale Konsequenzen nach sich zieht. Unternehmen, die ihre Wiederherstellungsprozesse wiederholt überprüfen, entwickeln ein Maß an Zuversicht, das über die reine Planung hinausgeht. 

Die Herausforderungen der Zukunft im Bereich der Resilienz zeichnen sich bereits ab.

Ransomware beherrscht nach wie vor die Schlagzeilen, doch die nächsten Herausforderungen im Bereich der Resilienz zeichnen sich bereits ab – von agentenbasierter KI über maschinelle Identitäten bis hin zur Post-Quanten-Kryptografie. 

Diese Bedrohungen machen deutlich, dass sich die Resilienzplanung nicht ausschließlich auf die heutige Infrastruktur konzentrieren darf. Bei der Wiederherstellung spielen zunehmend „ cloud “-Dienste, „ SaaS “-Anwendungen, KI-Modelle, Maschinenidentitäten, Drittanbieter und verteilte digitale Ökosysteme eine Rolle, die es vor einem Jahrzehnt noch nicht gab. 

Resilienz lässt sich zunehmend messen.

Das ResOps-Reifegradmodell von IDC ist von unschätzbarem Wert für die Bewertung der aktuellen Situation Ihres Unternehmens. Anstatt Resilienz als etwas zu betrachten, das Unternehmen entweder besitzen oder nicht besitzen, beschreibt das Rahmenwerk einen Entwicklungsprozess von reaktiven, isolierten Abläufen hin zu einer ausgereiften, anpassungsfähigen Resilienz, die auf Governance, Automatisierung und kontinuierlicher Verbesserung basiert. Für mich bestätigt dieser Fortschritt eine wichtige Tatsache: Resilienz ist niemals abgeschlossen. Es geht nicht darum, eine Plattform zu kaufen oder ein Projekt abzuschließen. Unternehmen werden resilient, indem sie kontinuierlich verbessern, wie Technologie, Menschen und Geschäftsprozesse unter Druck zusammenwirken. Aus dieser Perspektive betrachtet gleicht Resilienz weniger einer Versicherung als vielmehr operativer Exzellenz – einer Fähigkeit, die im Laufe der Zeit bewertet, gestärkt und unter Beweis gestellt werden kann. 

Derzeit vollzieht sich ein umfassender Wandel in der Art und Weise, wie Organisationen das Thema Resilienz betrachten.

Bei Gesprächen zum Thema Resilienz verlagert sich der Fokus zunehmend vom Schutz der Infrastruktur hin zum Schutz des Unternehmens selbst. Das bedeutet, dass die Notfallplanung bei den Kunden und nicht bei den Servern ansetzt, dass Governance ebenso wichtig wird wie Technologie und dass Vertrauen eher durch den Nachweis von Fähigkeiten als durch die Dokumentation von Absichten entsteht. ResOps ist kein wirklich neues Rahmenwerk, sondern vielmehr die umfassendere Erkenntnis, dass Cyber-Resilienz zu einer operativen Disziplin geworden ist. Da Angriffe immer schneller und komplexer werden, wird Resilienz nicht mehr an der Abwesenheit von Vorfällen gemessen, sondern an der Fähigkeit eines Unternehmens, trotz Störungen weiterhin Kunden zu bedienen, Mitarbeiter zu unterstützen und Vertrauen aufrechtzuerhalten. Genau das soll ResOps letztendlich beweisen. Rajiv Kottomtharayil ist Chief Products Officer bei Commvault. 

Die wichtigsten Erkenntnisse

• Das Vertrauen im Zeitalter der KI verschwindet nicht – es entwickelt sich weiter.
• Unternehmen müssen KI kontinuierlich überprüfen, anstatt ihr standardmäßig zu vertrauen.
• Der Einsatz von KI sollte die Mitarbeiter stärken und nicht dazu führen, dass sie sich in die „Schatten-KI“ zurückziehen.
• Bei „Zero Trust“ geht es nicht darum, Menschen zu misstrauen. Es geht darum, Identitäten, Geräte und Aktionen kontinuierlich zu überprüfen.
• Eine verantwortungsvolle Einführung von KI erfordert die Zusammenarbeit von Technologie, Governance und Menschen.

Als wir „Ready. Or Not.“ ins Leben riefen, wollten wir eine Serie schaffen, die einige der aktuell wichtigsten Diskussionen rund um KI verständlicher macht. Indem wir den Komiker Nathan Macintosh mit Branchenexperten zusammenbringen, beleuchten wir Themen von agentischer KI über Cyber-Resilienz bis hin zum Datenmanagement – und würzen das Ganze dabei mit einer Prise Humor.

Wenn Sie unsere erste Folge über die Chancen und Risiken agentischer KI gesehen haben, wird Ihnen diese Folge sicher auch gefallen. Dieses Mal beschäftigen wir uns mit einem Thema, das im Mittelpunkt jeder Diskussion über KI steht: Vertrauen.

Nathan unterhält sich mit Diana Kelley, Chief Information Security Officer bei Protect AI, darüber, was es bedeutet, der Technologie zu vertrauen, wenn KI überzeugende gefälschte Inhalte erzeugen, Entscheidungen treffen und sogar Menschen imitieren kann. Von Deepfakes und Halluzinationen bis hin zu Zero-Trust und Shadow-AI erörtern sie, wie Unternehmen KI nutzen können, ohne das Vertrauen in ihre Mitarbeiter und Systeme zu verlieren.

Sehen Sie sich die gesamte Folge auf Readiverse an. Nach dieser Folge war ich optimistischer, als ich erwartet hatte. Nicht, weil KI plötzlich vertrauenswürdiger geworden wäre, sondern weil Diana uns zeigt, dass Vertrauen wächst, wenn Unternehmen die richtigen Richtlinien, Sicherheitsvorkehrungen und Technologien einführen. Hier sind einige Themen aus dem Gespräch, die KI in ein neues Licht rücken.

Vertrauen und Technologie können nebeneinander bestehen

Diana glaubt, dass Vertrauen im Zeitalter der KI möglich ist, aber anders aussehen wird. Wir haben Vertrauen schon immer durch Beziehungen zu Menschen aufgebaut. Jetzt lernen wir, wie wir dieses Vertrauen auf Systeme ausweiten können. Das bedeutet nicht, der Technologie blind zu vertrauen. Es bedeutet vielmehr, zu verstehen, wie KI funktioniert, ihre Grenzen zu erkennen und die richtigen Sicherheitsvorkehrungen zu treffen, damit Menschen und Technologie vertrauensvoll zusammenarbeiten können.

„Vertrauen muss sich an die neue Welt anpassen.“ – Diana Kelley

Was mich besonders angesprochen hat, war die Vorstellung, dass Vertrauen und Technologie nicht unbedingt im Widerspruch zueinander stehen müssen. Mit dem richtigen Ansatz können sie sich gegenseitig stärken.

Wir werden immer versierter im Umgang mit KI

Deepfakes sind zu einem der meistdiskutierten KI-Risiken geworden, und es ist leicht zu verstehen, warum. KI kann mittlerweile überzeugende Stimmen, Bilder und Videos erzeugen, die uns daran zweifeln lassen, was echt ist. Aber Diana wies darauf hin, dass KI zwar immer ausgefeilter wird, die Menschen aber auch klüger werden. Wir hinterfragen eher einen unerwarteten Anruf, schauen uns einen Social-Media-Beitrag genauer an oder halten inne, wenn uns etwas nicht ganz richtig erscheint.

Auch Unternehmen werden immer versierter. Da KI immer besser darin wird, sich als jemand anderes auszugeben, investieren Unternehmen in neue Methoden, um Identitäten kontinuierlich zu überprüfen und Informationen zu validieren. Meine Schlussfolgerung lautet: Die Technologie wird sich weiter verbessern, aber ebenso wird sich unsere Fähigkeit verbessern, sie zu erkennen und verantwortungsbewusst darauf zu reagieren.

„Ist heute ein guter Tag, um mit einem Deepfake anzufangen?“ – Nathan Macintosh

Verantwortungsbewusste KI ist gut fürs Geschäft

Diana nannte ein Beispiel, das vielen Unternehmen wahrscheinlich bekannt vorkommen wird. Eine Mitarbeiterin, die sie „Karen aus der Finanzabteilung“ nennt, beginnt, KI zu nutzen, weil sie ihr dabei hilft, eine Aufgabe in wenigen Minuten statt in mehreren Stunden zu erledigen. Karen versucht nicht, die Unternehmensrichtlinien zu umgehen – sie möchte lediglich produktiver arbeiten.

Mitarbeiter nutzen KI, weil sie darin einen echten Mehrwert sehen, und das ist eine Chance für Unternehmen. Wenn Mitarbeiter Zugang zu zugelassenen KI-Tools haben, die durch klare Richtlinien und praktische Anleitungen unterstützt werden, können sie effizienter arbeiten und gleichzeitig zum Schutz der Unternehmensdaten und -systeme beitragen.

Vorschau: Intelligentere Nutzung von KI

Das Ziel besteht nicht darin, Mitarbeiter davon abzuhalten, KI zu nutzen. Vielmehr soll sichergestellt werden, dass sie diese richtig einsetzen. Diana erläutert, wie Unternehmen den Einsatz von KI fördern können, ohne dabei unnötige Risiken einzugehen.

Zero Trust ist wichtiger denn je

„Wenn man versteht, wie die Dinge funktionieren, kann man anfangen zu verstehen, wie man sie steuert.“ – Diana Kelley

„Zero Trust“ ist eines jener Konzepte, die sich anhand einer Analogie viel leichter verstehen lassen. Diana hat ein großartiges Beispiel dafür. Sie beschreibt es als den Weg durch ein Gebäude. Nur weil man durch die Eingangstür gelassen wurde, heißt das noch lange nicht, dass sich jede weitere Tür automatisch für einen öffnet. Jedes Mal, wenn man einen neuen Raum betritt, gibt es eine weitere kurze Überprüfung, um sicherzustellen, dass man dort auch wirklich sein darf.

So funktioniert „Zero Trust“ im Wesentlichen. Anstatt davon auszugehen, dass eine Person oder ein Gerät nach einer einmaligen Anmeldung vertrauenswürdig ist, überprüfen Unternehmen Identitäten, Geräte und Aktionen kontinuierlich, da die Technologien immer stärker vernetzt sind. Die meisten dieser Überprüfungen finden unbemerkt im Hintergrund statt. Was mir an Dianas Erklärung besonders gefallen hat, ist, dass „Zero Trust“ nicht wie ein weiteres Sicherheits-Schlagwort wirkt. Es erscheint mir vielmehr als ein praktischer Ansatz, um über Vertrauen in einer Welt nachzudenken, in der KI und digitale Identitäten zunehmend Teil des Geschäftsalltags werden.

Bei Vertrauen geht es um Menschen

Letztendlich schafft nicht die Technologie Vertrauen – sondern die Menschen. Menschen legen die Richtlinien, Prozesse und ethischen Grenzen fest, die den Einsatz von KI regeln, während die Technologie dabei hilft, zu überprüfen, ob diese Schutzmechanismen wie vorgesehen funktionieren. Es ist diese Partnerschaft zwischen Menschen und Technologie, die eine verantwortungsvolle KI erst möglich macht.

Vertrauen geht über unsere eigenen Organisationen hinaus. Unternehmen müssen Vertrauen in die Partner haben, mit denen sie zusammenarbeiten, in die Systeme, mit denen sie sich vernetzen, und in die Technologien, die sie einsetzen. Deshalb gewinnen Transparenz, gemeinsame Standards und kontinuierliche Überprüfung zunehmend an Bedeutung – ebenso wie die Innovation selbst. Je mehr KI zum Alltag in der Geschäftswelt wird, desto mehr wird Vertrauen zur Verantwortung aller.

Ausblick

Die KI wird sich weiterentwickeln, ebenso wie die Art und Weise, wie wir mit ihr interagieren. Erfolgreich sein werden nicht jene Unternehmen, die der KI blind vertrauen oder sie gänzlich meiden. Erfolgreich sein werden vielmehr jene, die solide Richtlinien festlegen, die richtigen Technologien einsetzen und die Systeme, auf die sie sich verlassen, kontinuierlich überprüfen.

Vertrauen ist nichts, was wir mit dem technologischen Fortschritt verlieren. Es ist etwas, das wir bewusst aufbauen und weiterentwickeln. Genau diese Art von Diskussion möchten wir mit jeder Folge von „Ready. Or Not.“ fortsetzen. Sehen Sie sich die gesamte Folge auf Readiverse an.

FAQs

F: Was versteht man unter digitalem Vertrauen?

A: Digitales Vertrauen ist die Gewissheit, dass Personen, Systeme und Organisationen tatsächlich die sind, für die sie sich ausgeben, und dass sie sich wie erwartet und auf sichere Weise verhalten. Es verbindet Technologie, Governance und Verifizierung, um Organisationen dabei zu unterstützen, sicher miteinander zu interagieren.

F: Was sind Deepfakes?

A: Deepfakes sind durch künstliche Intelligenz erzeugte Bilder, Videos oder Tonaufnahmen, die darauf ausgelegt sind, echte Personen originalgetreu nachzuahmen. Zwar gibt es legitime Anwendungsbereiche dafür, doch können sie auch dazu missbraucht werden, sich als andere Personen auszugeben oder Betrug zu begehen.

F: Was ist „Zero Trust“?

A: „Zero Trust“ ist ein Sicherheitsmodell, das auf kontinuierlicher Überprüfung statt auf automatischem Vertrauen basiert. Anstatt davon auszugehen, dass ein Benutzer oder ein Gerät nach einer einzigen Anmeldung vertrauenswürdig ist, überprüfen Unternehmen Identitäten und Aktionen kontinuierlich.

F: Was ist „Shadow AI“?

A: Der Begriff „Shadow AI“ bezeichnet die Nutzung von KI-Tools durch Mitarbeiter, die von ihrem Unternehmen weder genehmigt noch reguliert wurden. Auch wenn dies oft in guter Absicht geschieht, kann dies zu Risiken in Bezug auf Sicherheit, Datenschutz und Compliance führen.

F: Warum sollten Unternehmen KI-Tools nicht einfach blockieren?

A: Mitarbeiter setzen KI in der Regel ein, weil sie ihnen hilft, effizienter zu arbeiten. Anstatt KI pauschal zu verbieten, sollten Unternehmen zugelassene Tools bereitstellen, klare Richtlinien festlegen und die Mitarbeiter im verantwortungsvollen Umgang damit schulen.

F: Was ist die wichtigste Erkenntnis aus dieser Folge?

A: Das Vertrauen verschwindet nicht wegen der KI – es entwickelt sich weiter. Unternehmen, die Menschen, Richtlinien und Technologie mit kontinuierlicher Überprüfung kombinieren, sind besser aufgestellt, um KI selbstbewusst und verantwortungsvoll einzusetzen.

Katherine Demacopoulos ist Senior Director für globale Inhaltsstrategie und Programme bei Commvault.

Unser Chief Products Officer, Rajiv Kottomtharayil, hat kürzlich über einen großen Wandel geschrieben, der sich branchenübergreifend vollzieht. Modernste KI-Modelle verkürzen die Zeitspanne zwischen der Entdeckung einer Sicherheitslücke und deren Ausnutzung. Dieser Wandel veranlasst Unternehmen weltweit dazu, ihre Prozesse zum Schwachstellenmanagement zu überdenken. Das tun wir bei Commvault ebenfalls. Aus diesem Grund ändern wir ab dem 11. August den Rhythmus, in dem wir Sicherheitslücken offenlegen. Was sich ändert Wir legen die Messlatte in Sachen Sicherheit, Transparenz und Kundenvertrauen höher. Am 11. August und danach jeweils am zweiten Dienstag jedes Monats führen wir die „Patch Tuesdays“ ein: eine monatlich stattfindende Veröffentlichung, bei der wir Sicherheitshinweise und Patches für Sicherheitslücken bereitstellen.  

„Patch Tuesdays“ sind ein Markenzeichen führender Technologieunternehmen, da sie den Kunden einen vorhersehbaren Sicherheitsrhythmus bieten. Dies gewinnt umso mehr an Bedeutung, je schneller Schwachstellen entdeckt werden. Sollte es natürlich eine dringende Schwachstelle geben, die außerhalb des regulären Zyklus gemeldet werden muss, werden wir nicht zögern, unsere bewährten Prozesse zu befolgen.  

Wo Sie aktuelle Ressourcen finden  

Am zweiten Dienstag jedes Monats finden Sie neue Informationen zu CVEs auf unserer Seite „Sicherheitshinweise“. Die offiziellen Veröffentlichungen finden Sie außerdem auf der CVE-Website. Im Commvault Security Center finden Sie unser Programm zum Schwachstellenmanagement sowie weitere Leitartikel zum Thema „Security-by-Design“.   

Compliance-Zertifizierungen, Auditberichte und Unterlagen dazu, wie Commvault Kundendaten schützt, finden Sie im Commvault Trust Center. Über den Link in der oberen rechten Ecke der Seite können Sie Updates aus dem Trust Center abonnieren. Bill O’Connell ist Chief Security Officer bei Commvault. 

Seit Jahrzehnten versuchen Technologieführer, Silos abzubauen. Ganze Modernisierungsprogramme wurden darauf ausgerichtet, Anwendungen miteinander zu vernetzen, Plattformen zu konsolidieren und Unternehmen einen umfassenderen Überblick über ihre Daten zu verschaffen. Diese Bemühungen haben einen enormen Mehrwert gebracht, aber sie haben auch unsere Sichtweise auf Resilienz geprägt. Wenn etwas schiefgeht, suchen wir instinktiv nach technischen Ursachen. Wir haben jedoch festgestellt, dass die größere Herausforderung woanders liegt.

Die größten Hindernisse für die Cyber-Resilienz sind heute nicht in Datenbanken oder Anwendungen zu finden, sondern in den Organisationsstrukturen. Sie bestehen zwischen Sicherheits- und Infrastrukturteams, zwischen der IT und dem Geschäft sowie zwischen den Mitarbeitern, die für die Reaktion auf einen Angriff zuständig sind, und denen, die für die Aufrechterhaltung des Betriebs des Unternehmens verantwortlich sind.

Die neueste Studie von IDC zum Thema „ResOps –Resilience Operations: Die Disziplin, die Bereitschaft nachweisbar macht“ legt nahe, dass diese organisatorischen Grenzen zu einem der entscheidenden Hindernisse für eine effektive Wiederherstellung geworden sind. Diese Feststellung kommt gerade zum richtigen Zeitpunkt, da sich Cyberangriffe so weiterentwickelt haben, dass es immer schwieriger wird, diese Grenzen aufrechtzuerhalten.

Moderne Angriffe richten sich nicht nach Ihrem Organigramm

Ein moderner Cyberangriff betrifft selten nur einen einzigen Technologiebereich. Ein Ransomware-Vorfall kann mit kompromittierten Identitäten beginnen, sich über die „ cloud “-Infrastruktur ausbreiten, kritische Workloads verschlüsseln, kundenorientierte Anwendungen stören, Dienste von Drittanbietern beeinträchtigen und Meldepflichten gegenüber Aufsichtsbehörden auslösen – und das alles innerhalb weniger Stunden. In jeder Phase sind unterschiedliche Teams, unterschiedliche Tools und unterschiedliche Prioritäten gefragt. Dennoch bereiten sich viele Organisationen nach wie vor auf die Wiederherstellung vor, als ob diese Aufgaben unabhängig voneinander bewältigt werden könnten.

Sicherheitsteams konzentrieren sich naturgemäß darauf, Bedrohungen einzudämmen und Beweismittel zu sichern. Infrastrukturteams legen den Schwerpunkt auf die Wiederherstellung von Systemen und die Minimierung von Ausfallzeiten. Führungskräfte konzentrieren sich auf Kunden, Umsatz und Betriebskontinuität. Kommunikationsteams denken an den Ruf des Unternehmens, während Rechts- und Compliance-Teams sich auf regulatorische Verpflichtungen konzentrieren. Jede Sichtweise ist durchaus nachvollziehbar. Das Problem entsteht, wenn diese Prioritäten vor dem Eintreten eines Vorfalls nie miteinander in Einklang gebracht wurden.

Mitten in einer Krise erfordert Recovery Entscheidungen unter Druck. Welche Anwendungen sollten zuerst wieder verfügbar sein? Welche Daten können sicher wiederhergestellt werden? Wie viel Risk ist akzeptabel, bevor der Kundenservice wieder aufgenommen wird? Wer hat die Befugnis, diese Entscheidungen zu treffen? Ohne eine entsprechende Abstimmung stellen Unternehmen oft fest, dass die größten Verzögerungen nicht durch die Technologie verursacht werden, sondern durch Unsicherheit – eine Unsicherheit, die durch eine bessere Vorbereitung gemindert werden könnte.

Resilienz beginnt mit einer gemeinsamen Definition dessen, was wirklich zählt

Der Bericht legt den Schwerpunkt auf den Aufbau Ihres „Minimum Viable Business“ (MVB). Auf den ersten Blick scheint es sich um eine weitere Übung zur Notfallplanung zu handeln, doch sein wahrer Wert liegt in den Gesprächen, zu denen er Unternehmen zwingt.

Um ein MVB zu definieren, müssen sich Führungskräfte, Sicherheitsteams, Infrastrukturspezialisten und Anwendungsverantwortliche auf eine Frage einigen, die auf den ersten Blick einfach erscheint: Was muss unbedingt weiterlaufen, wenn alles andere zum Stillstand kommt?

Diese Diskussion verändert den Charakter der Resilienzplanung. Die Prioritäten bei der Wiederherstellung werden nicht mehr davon bestimmt, welcher Anwendungsverantwortliche während eines Vorfalls am überzeugendsten argumentiert. Stattdessen werden sie im Voraus festgelegt, basieren auf geschäftlichen Zielen und stützen sich auf technische Abhängigkeiten, die allen klar sind.

Vielleicht noch wichtiger ist, dass der MVB eine gemeinsame Sprache schafft. Führungskräfte sprechen nun über kritische Funktionen statt über einzelne Systeme. Technologieteams beginnen, die Infrastruktur an Kundenergebnissen statt an technischen Architekturen auszurichten. Sicherheitsteams erhalten mehr Klarheit darüber, welche Ressourcen während der Recovery den höchsten Schutzgrad verdienen. Genau dieses gemeinsame Verständnis hat es vielen Organisationen bisher gefehlt.

Technologie kann die Wiederherstellung automatisieren – aber sie kann keine Abstimmung herbeiführen

Der Bericht argumentiert nicht, dass Unternehmen noch eine weitere Plattform benötigen. Er argumentiert, dass sie eine Arbeitsweise benötigen, die Menschen, Prozesse und Technologie auf ein einziges operatives Ziel ausrichtet. Hier beweist ResOps – eine funktionsübergreifende Disziplin – seinen Wert.

Technologie kann zwar dazu beitragen, die Recovery-Prozesse zu automatisieren, aber sie kann keine Meinungsverschiedenheiten über geschäftliche Prioritäten lösen. Sie kann nicht entscheiden, welche Kundendienste am wichtigsten sind. Und sie kann nicht die Steuerung ersetzen, die erforderlich ist, um mehrere Teams während eines Ereignisses unter hohem Druck zu koordinieren. Das sind Herausforderungen für Führungskräfte, und man begegnet ihnen am besten, indem man sich Zeit nimmt, die schwierigen Fragen gemeinsam zu klären – lange bevor ein Angriff einen zum Handeln zwingt.

Die stärksten Organisationen beseitigen Silos nicht – sie verbinden sie miteinander

Cyberangriffe werden sich weiterentwickeln. KI wird die Zeitfenster für Angriffe weiter verkürzen. Neue Technologien werden neue Abhängigkeiten mit sich bringen, und damit werden auch neue Bedrohungen entstehen. Nichts davon ändert etwas an der grundlegenden Anforderung an die Widerstandsfähigkeit. Unternehmen erholen sich nicht deshalb, weil einzelne Teams für sich genommen hervorragende Leistungen erbringen, sondern weil diese Teams bereits wissen, wie man zusammenarbeitet.

Das ist vielleicht letztlich die wichtigste Erkenntnis aus der IDC-Studie. Resilienz ist nicht einfach das Ergebnis besserer Technologie oder ausgefeilterer Sicherheitsmaßnahmen. Sie ist das Ergebnis gemeinsamer Prioritäten, einer klaren Governance und eines bewährten Betriebsmodells, das die richtigen Personen zusammenbringt, noch bevor ein Vorfall eintritt. Vidya Shankaran ist Field CTO bei Commvault.

Die wichtigsten Erkenntnisse

• Ein CVE ist eine weltweit eindeutige Kennung für eine öffentlich bekannt gegebene Software-Sicherheitslücke, die es Anbietern, Forschern und Sicherheitsfachleuten ermöglicht, sich einheitlich auf dieselbe Sicherheitslücke zu beziehen.
• Der Umgang eines Unternehmens mit der Offenlegung von Sicherheitslücken – einschließlich koordinierter Fehlerbehebungen, der Einbindung von Forschern und einer genauen Software-Bestandsaufnahme – ist ein aussagekräftiger Indikator für den allgemeinen Reifegrad der Sicherheitsmaßnahmen.
• Commvault schützt seine Kunden mit einem CVE-Programm, das sich durch Transparenz, Regelmäßigkeit und Klarheit auszeichnet. Die Offenlegung von CVEs sagt viel über die Reife eines Sicherheits- und Entwicklungsprogramms aus.

Warum das wichtig ist

Viele Sicherheitsvorfälle, die bis in die Führungsetage gelangen, lassen sich auf Schwachstellen in der Software zurückführen. Der Mechanismus, den die gesamte Branche zur Benennung und Beschreibung dieser Schwachstellen nutzt, ist das CVE-System(Common Vulnerabilities and Exposures). Wie ein Anbieter oder Ihr eigenes Unternehmen mit CVEs umgeht, ist eines der deutlichsten Anzeichen für die Reife im Bereich Sicherheit.

Ein Unternehmen, das Sicherheitslücken offenlegt und Forscher fair würdigt, ist in der Regel ein Unternehmen, das die zugrunde liegende Technik ernst nimmt. In diesem Blogbeitrag wird erläutert, wie ein CVE-Eintrag erstellt wird, wer das System betreibt und was eine vorbildliche Offenlegung von einer mangelhaften unterscheidet.

Über die CVE hinaus: Warum die Philosophie der Offenlegung wichtig ist

Die Veröffentlichung einer CVE ist das Mindeste, was man tun muss. Die entscheidenden Faktoren sind: Transparenz hinsichtlich der Sicherheitslücke und des Patches, regelmäßige Scans und die Installation von Patches sowie eine klare Kommunikation. Commvault betrachtet die Offenlegung als eine technische und sicherheitsrelevante Disziplin und nicht als reine Compliance-Maßnahme: Wir legen einen regelmäßigen Rhythmus für Code-Reviews und Fehlerbehebungen fest, kommunizieren die Korrektur in verständlicher Sprache und schützen unsere Kunden. Diese Konsequenz sagt mehr über die Sicherheitsreife aus als jede einzelne Bewertung im Rahmen der CVE-Offenlegung.

Was ein CVE eigentlich ist

Ein CVE ist weder ein Patch noch eine Punktzahl noch ein Stück Malware. Es handelt sich um einen Eintrag in einem Verzeichnis, der einer bestimmten, öffentlich bekannten Sicherheitslücke einen dauerhaften, eindeutigen Namen zuweist, damit jeder darauf Bezug nehmen kann. Die Kennung selbst folgt einem einfachen, beständigen Format: die Buchstaben „CVE“, das Jahr, in dem die Kennung vergeben wurde, und eine fortlaufende Nummer, zum Beispiel CVE-2021-44228.

Das Programm hat enorme Ausmaße und wächst weiter: Im Jahr 2025 wurden 48.000 CVEs veröffentlicht, was etwa 132 pro Tag entspricht – ein Anstieg von mehr als 260 % seit 2020.

Die Struktur eines einzelnen Datensatzes

CVE-Veröffentlichungen müssen bestimmte einheitliche Elemente enthalten. Das Lesen einer solchen Veröffentlichung ist unkompliziert, sobald man weiß, wozu die einzelnen Teile dienen:

• Identifikator, die eindeutige CVE-YYYY-NNNNN
• Beschreibung, eine kurze Erläuterung der Sicherheitslücke: Was sie ist und wie ein Angreifer sie ausnutzen könnte.
• Betroffene Produkte und Versionen, welche Software, Hardware oder Firmware (und welche Versionen) betroffen sind und welche Versionen die Korrektur enthalten.
• Schweregrad, die zugrunde liegende Schweregradkategorie.
• Quellenangaben, Links zum Herstellerhinweis, zum Patch und zu technischen Beschreibungen.

Die Nebendarsteller: CVSS, CWE, EPSS und KEV

Vier begleitende Systeme machen aus einem CVE ein Thema, dem ein Unternehmen Priorität einräumen kann. Da sie leicht zu verwechseln sind, lohnt es sich, die Unterscheidung im Auge zu behalten:

• CVSS (Common Vulnerability Scoring System) beantwortet die Frage „Wie schwerwiegend ist die Schwachstelle?“ CVSS ist die Schweregradbewertung (1–10, wobei 10 den höchsten Schweregrad darstellt) der Schwachstelle und kein Maß für Ihr konkretes Risiko.
• Das EPSS (Exploit Prediction Scoring System) beantwortet die Frage: „Wie wahrscheinlich ist es, dass diese Schwachstelle in Kürze ausgenutzt wird?“ Das EPSS ermittelt einen Wahrscheinlichkeitswert zwischen null und 100 Prozent, der die Wahrscheinlichkeit abschätzt, mit der eine Schwachstelle in den nächsten 30 Tagen ausgenutzt wird.
• CWE (Common Weakness Enumeration) beantwortet die Frage: „Welche Art von Fehler hat dazu geführt?“ Die CWE klassifiziert die zugrunde liegende Schwachstelle im Code.
• KEV (Known Exploited Vulnerabilities) beantwortet die Frage: „Wird diese Schwachstelle derzeit gegen Nutzer ausgenutzt?“ Der KEV-Katalog ist eine kuratierte Liste von CVEs, deren Ausnutzung in der Praxis bestätigt wurde.

Ein hoher CVSS-Wert gibt Aufschluss darüber, wie schwerwiegend eine Schwachstelle sein könnte, ein hoher EPSS-Wert zeigt an, wie schnell sie voraussichtlich ausgenutzt wird, und eine Aufnahme in den KEV-Katalog bestätigt, dass bereits Ausnutzungsversuche stattfinden. Die besten Programme zur Schwachstellenbekämpfung berücksichtigen alle drei Faktoren.

FAQs

F: Was ist ein CVE und warum ist er wichtig? A: Ein „Common Vulnerability and Exposure“ (CVE) ist eine standardisierte Kennung, die einer öffentlich bekannt gewordenen Software-Sicherheitslücke zugewiesen wird. Sie ermöglicht es allen – von Anbietern und Forschern bis hin zu Aufsichtsbehörden und Kunden –, sich eindeutig auf dieselbe Sicherheitslücke zu beziehen.

F: Welche Informationen sollte ein vollständig ausgefüllter CVE-Eintrag enthalten?
A: Ein vollständiger CVE-Eintrag erfordert eine eindeutige Kennung, eine Beschreibung der Sicherheitslücke, betroffene Produkte und Versionen, die Schwereklasse sowie Verweise auf Herstellerhinweise oder Patches. Diese Elemente ermöglichen es Unternehmen, ihr Risiko einzuschätzen und effizient zu reagieren.

F: Wie unterscheiden sich CVSS, CWE, EPSS und KEV von einer CVE? A: Eine CVE identifiziert eine bestimmte Sicherheitslücke, während CVSS deren Schweregrad misst, EPSS die Wahrscheinlichkeit einer kurzfristigen Ausnutzung einschätzt, CWE die zugrunde liegende Schwachstelle im Code klassifiziert und KEV Sicherheitslücken identifiziert, die in der Praxis aktiv ausgenutzt werden. Zusammen liefern diese Frameworks den notwendigen Kontext, um Prioritäten bei der Behebung zu setzen.

F: Worauf legt Commvault bei seinen eigenen Offenlegungspraktiken Wert? A: Commvault misst seine eigenen Offenlegungen an denselben Maßstäben, die es auch von anderen erwartet: Transparenz, Regelmäßigkeit und Klarheit. Auf diese Weise schützt Commvault seine Kunden.

F: Worauf sollten Führungskräfte achten, wenn sie die Verfahren von Anbietern zum Schwachstellenmanagement bewerten? A: Führungskräfte sollten auf koordinierte Zeitpläne für die Offenlegung, umfassende und genaue CVE-Einträge, klare Anleitungen zur Behebung, robuste Berichtsprogramme sowie die Fähigkeit achten, schnell festzustellen, ob Produkte von neu bekannt gewordenen Schwachstellen betroffen sind. Diese Merkmale spiegeln eine starke Sicherheitskultur wider und verbessern die Widerstandsfähigkeit des Unternehmens. Werner Nel ist Principal Product Experience Manager bei Commvault.

Die wichtigsten Erkenntnisse

• „JadePuffer“ ist der Name, den Sicherheitsforscher bei Sysdig einer Ransomware-Operation gegeben haben, die ihrer Einschätzung nach als erste dokumentierte Operation gilt, die durchgehend von einem autonomen KI-Agenten gesteuert wird – und nicht von einem Menschen, der ein Toolkit einsetzt.
• Die einzelnen Techniken waren nicht neu. Was sich geändert hatte, war die Geschwindigkeit der Abfolge: Der Agent verband Aufklärung, Diebstahl von Zugangsdaten, laterale Bewegung und zerstörerische Verschlüsselung miteinander und korrigierte einen fehlgeschlagenen Anmeldeversuch innerhalb von 31 Sekunden.
• Der Agent hat seinen eigenen Verschlüsselungsschlüssel generiert und diesen anschließend weder gespeichert noch übertragen. Die Zahlung des Lösegelds hätte nicht zur Wiederherstellung der Daten geführt.
• Der eigentliche Schaden betraf den Konfigurationsstatus und die Systeme der Steuerungsebene, nicht nur Dateien – und genau diese Ebene wird von den meisten Wiederherstellungsplänen nicht abgedeckt.
• Sich von einem solchen Angriff zu erholen bedeutet, nachzuweisen, dass das Unternehmen den Betrieb sicher wieder aufnehmen kann – es reicht nicht aus, lediglich ein Backup wiederherzustellen.

Was ist passiert?

Mitte 2026 dokumentierten Sicherheitsforscher bei Sysdig eine Erpressungskampagne, die ihrer Ansicht nach die erste ihrer Art ist: eine Ransomware-Aktion, die durchgehend von einem Agenten auf Basis eines großen Sprachmodells durchgeführt wurde, wobei der menschliche Eingriff über die Tastatur auf ein Minimum beschränkt war. Sie nannten sie „JadePuffer“.

Der Einstiegspunkt war bekannt. Der Angreifer nutzte CVE-2025-3248 aus, eine Schwachstelle in Langflow – einem Open-Source-Framework zur Erstellung von Workflows für KI-Agenten, das in einer Version vor 1.3.0 lief –, die die Ausführung von Code aus der Ferne ohne Authentifizierung ermöglichte. Von dort aus führte der Agent eine Bestandsaufnahme des Hosts durch, suchte bei Anbietern von „ cloud “, KI-Modellanbietern und Datenbanken nach Anmeldedaten und kopierte unbemerkt die eigene Hintergrunddatenbank der „ platform“.

Was als Nächstes geschah, ist besonders bemerkenswert. Der Agent scannte das interne Netzwerk, fand einen ungeschützten Objektspeicher und extrahierte Terraform-Zustands- und Konfigurationsdateien. Er richtete eine geplante Aufgabe ein, um alle 30 Minuten eine Verbindung zum Kommandozentrum herzustellen. Anschließend wechselte er zu einem separaten Produktionssystem, auf dem MySQL und Alibaba Nacos liefen – eine in Microservice-Architekturen gängige Plattform für Konfiguration und Service-Discovery.

Sobald es sich Zugang verschafft hatte, versuchte der Agent, ein Administratorkonto in Nacos anzulegen. Der Versuch schlug fehl. Einunddreißig Sekunden später hatte es den Fehler diagnostiziert und mit einem anderen Ansatz Erfolg gehabt. Anschließend nutzte es die Dateiverarbeitungsfunktionen von MySQL, um zu prüfen, ob es seine Zugriffsrechte weiter ausweiten konnte, bevor es mehr als 1.300 Konfigurationsdatensätze verschlüsselte, die ursprünglichen Tabellen löschte und eine Lösegeldforderung hinterließ.

Der Verschlüsselungsschlüssel wurde spontan generiert, einmal angezeigt und nirgendwo gespeichert, wo der Angreifer ihn wieder abrufen könnte. Ob dies nun beabsichtigt war oder nicht – für das Opfer ist das Ergebnis dasselbe: Es gab keinen Weg zurück über den Angreifer oder einen Entschlüsselungsschlüssel, unabhängig davon, ob Lösegeld gezahlt wurde oder nicht. Die Wiederherstellung würde von einwandfreien Backups, einer Neuinstallation oder validierten Wiederherstellungspunkten abhängen.

Warum Forscher dies als „agentisch“ bezeichnen

Keine der hier beschriebenen Techniken ist neu. Die Ausnutzung einer ungepatchten CVE, das Sammeln von Anmeldedaten, das Scannen nach lateraler Bewegung, die Verschlüsselung von Daten zu Erpressungszwecken: Sicherheitsteams haben all das schon einmal gesehen. Was Sysdig dazu veranlasste, den Angreifer als „agentisch“ und nicht als herkömmlichen Angreifer einzustufen, ist die Art und Weise, wie die einzelnen Schritte ineinandergreifen.

Der Agent arbeitete nicht nach einem festgelegten Skript. Er beobachtete die Ergebnisse und passte sich entsprechend an. Als er eine JSON-Antwort erwartete und stattdessen XML erhielt, änderte er seine Vorgehensweise und setzte den Vorgang fort. Als sein erster Versuch, ein Administratorkonto anzulegen, fehlschlug, ermittelte er die genaue Fehlerursache und probierte innerhalb von weniger als einer Minute eine andere Vorgehensweise aus.

Die Forscher fanden zudem in den Payloads eingebettete Kommentare, in denen Ziele und nächste Schritte in einfacher Sprache erläutert wurden – ein Muster, das eher auf die Schlussfolgerungen eines großen Sprachmodells (LLM) bei der Bearbeitung einer Aufgabe hindeutet als auf einen Menschen, der ein bekanntes Exploit-Kit kopiert und einfügt. In öffentlichen Berichten wurde bislang nicht bestätigt, welches Modell oder welche „ platform “ hinter dem Angriff steckte. Bestätigt ist jedoch das Verhalten: Etwas, das logisch überlegte, handelte, auf ein Hindernis stieß und seinen Kurs schneller korrigierte, als es die meisten von Menschen gesteuerten Reaktionsmaßnahmen auf Vorfälle schaffen.

Das Problem der Wiederherstellung, das zu viele Frameworks immer noch übersehen

Die meisten Vorgehensweisen bei Ransomware basieren auf einer bestimmten Annahme: Ihre Dateien wurden verschlüsselt, und die Frage ist, ob Sie ein einwandfreies Backup wiederherstellen können oder ob Sie um einen Entschlüsselungscode verhandeln müssen.

JadePuffer widerlegt diese Annahme in zweierlei Hinsicht. Erstens gab es keinen Entschlüsselungsschlüssel, über den verhandelt werden musste. Zweitens beschränkte sich der Schaden nicht nur auf die Daten. Er betraf auch die Konfigurations- und Steuerungsebene unterhalb der Daten: die Service-Discovery-Plattform, die darin gespeicherten Geheimnisse, den Terraform-Zustand, der beschreibt, wie die Infrastruktur zusammenpasst, sowie die Anmeldedaten, die über alle Systeme verstreut waren, mit denen der Agent auf seinem Weg in Berührung kam.

Das ist ein schwierigeres Problem bei der Wiederherstellung als die „Wiederherstellung der Datenbank“. Eine saubere Dateiwiederherstellung in einer Umgebung mit aktualisierten, aber nicht überprüften Anmeldedaten, ungeprüften Konfigurationsabweichungen und einer Identitätsschicht, die niemand erneut geprüft hat, ist keine wirklich saubere Wiederherstellung. Es handelt sich um eine neue Kopie der Daten in einem System, dem man nach wie vor nicht vertrauen kann.

Was dies für Ihre Resilienzstrategie bedeutet

JadePuffer gibt einen Vorgeschmack auf die Frage, die jeder Wiederherstellungsplan irgendwann beantworten muss: Können Sie den Betrieb wieder aufnehmen, wenn ein Angreifer nicht nur Ihre Daten, sondern auch die Identitäts-, Konfigurations- und Steuerungssysteme angegriffen hat, auf denen diese Daten beruhen?

Ein paar Ansatzpunkte:

Behandeln Sie Konfigurations- und Steuerungsebene-Systeme als für die Recovery kritisch, nicht nur Anwendungen. Service-Discovery-Plattformen, Speicherstellen für Geheimnisse und der Zustand von „Infrastructure-as-Code“ sind ebenso geschäftskritisch wie die Datenbanken, die sie konfigurieren. Wenn sie heute noch nicht in Ihrem Recovery-Plan enthalten sind, ist dies die erste Lücke, die geschlossen werden muss.

Integrieren Sie die Sicherheit von Anmeldedaten bereits in den Wiederherstellungsprozess ein – und nicht erst danach. Die Wiederherstellung einer Arbeitslast, durch die kompromittierte Geheimnisse erneut eingeführt werden, beendet den Vorfall nicht, sondern setzt die Uhr zurück. Genau diese Vorgehensweise wendet Commvault heute auf die Identitätsinfrastruktur an: Schwachstellenanalysen, um Sicherheitslücken zu erkennen, bevor ein Angreifer dies tut, Echtzeit-Audits, um Änderungen sofort zu erfassen, und Rollbacks, um unbefugte Änderungen rückgängig zu machen, ohne von Grund auf neu aufbauen zu müssen.

Überprüfen Sie die Daten vor der Wiederherstellung, nicht danach. Ein Wiederherstellungspunkt ist nur dann sinnvoll, wenn Sie sicher sind, dass er fehlerfrei ist. Das ist das Prinzip hinter Commvault® Cleanroom™: Daten werden in einer isolierten Umgebung getestet und überprüft, bevor sie wieder in die Produktionsumgebung gelangen – statt erst nach einer erneuten Infektion festzustellen, dass etwas nicht stimmt.

Planen Sie für einen Angriff auf die Steuerungsebene ein, nicht nur für einen Vorfall mit Dateiverschlüsselung. Ein Wiederherstellungsplan, der ausschließlich auf „verschlüsselte Dateien, Wiederherstellung aus dem Backup“ ausgelegt ist, wird bei einem Vorfall wie diesem nicht ausreichen. Die sinnvollere Frage – und die, die im Mittelpunkt von ResOps (Resilience Operations) als betrieblicher Disziplin steht – lautet: Was ist erforderlich, um einen minimal funktionsfähigen Betrieb zu erreichen, wenn die Systeme, auf denen Ihre Anwendungen basieren, selbst betroffen sind?

All dies bedeutet nicht, dass man agentische KI als eine beispiellose Bedrohung betrachten muss, die einen Neuanfang von Grund auf erfordert. Vielmehr gilt es, die gleichen Resilienzmaßnahmen, die bereits für Identität und Daten gelten, auf die Konfigurations- und Steuerungsebene auszuweiten, auf die agentische Angriffe mittlerweile direkt abzielen. Erfahren Sie mehr darüber, wie Commvault das Thema Identitätsresilienz und Validierung der fehlerfreien Wiederherstellung angeht.

FAQs

F: Was ist JadePuffer? A: „JadePuffer“ ist der Name, den Sysdig der nach seiner Einschätzung ersten dokumentierten Ransomware-Kampagne gegeben hat, die durchgehend von einem autonomen KI-Agenten gesteuert wurde und nicht von einem menschlichen Angreifer, der ein Toolkit manuell bediente.

F: Haben die Angreifer ein bestimmtes KI-Modell verwendet, wie beispielsweise ChatGPT oder Claude? A: In den öffentlichen Medienberichten wurde nicht bestätigt, welches Modell oder welche „ platform “ verwendet wurde. Der Agent suchte nach API-Schlüsseln verschiedener KI-Anbieter, was auf ein Interesse an dieser Art von Zugriff hindeutet, jedoch keinen Aufschluss darüber gibt, worauf der Angriff selbst beruhte. F: Wie hat der Angriff begonnen?

A: Über CVE-2025-3248: Eine Sicherheitslücke in Langflow, einem Open-Source-Framework für KI-Agenten, die eine nicht authentifizierte Remote-Codeausführung ermöglicht und Versionen vor 1.3.0 betrifft. Frage: Hätte das Opfer das Lösegeld zahlen können, um seine Daten zurückzubekommen? A: Nein. Der Verschlüsselungsschlüssel wurde spontan generiert und weder gespeichert noch übertragen, sodass unabhängig von einer etwaigen Zahlung kein Schlüssel zur Wiederherstellung zur Verfügung stand.

F: Worin unterscheidet sich diese Ransomware von herkömmlicher Ransomware? A: Die einzelnen Techniken waren nicht neu. Was auffiel, waren die Geschwindigkeit und die Anpassungsfähigkeit: Der Agent erkannte einen fehlgeschlagenen Anmeldeversuch und korrigierte ihn innerhalb von 31 Sekunden – ein Tempo, das eher der Geschwindigkeit einer Maschine entspricht als dem typischen, vom Menschen bestimmten Verhalten eines Angreifers. Frage: Was sollten Sicherheits- und Wiederherstellungsteams daraus mitnehmen?

A: Diese Wiederherstellungsplanung muss über Anwendungsdaten hinausgehen und auch Konfigurationsspeicher, Service-Discovery-Plattformen, Geheimnisse und Identitätssysteme umfassen – also genau jene Ebene, auf die JadePuffer abzielte, um maximalen Schaden anzurichten. Chris Bevil ist Principal Portfolio Marketing Manager bei Commvault.

Die wichtigsten Erkenntnisse

• Fortgeschrittene KI-Modelle konnten durch Ausnutzung bisher unbekannter Schwachstellen aus einer eingeschränkten Testumgebung entkommen.
• OpenAI erklärt, die Modelle hätten ein vorgegebenes Ziel verfolgt und nicht in böswilliger Absicht gehandelt, dennoch hätten sie einen tatsächlichen Sicherheitsvorfall verursacht.
• Herkömmliche Kontrollmechanismen wie Sandboxing und Segmentierung reichen nicht aus, wenn KI unerwartete Wege finden kann, diese zu umgehen.
• Cyber-Resilienz gewinnt zunehmend an Bedeutung und wird ebenso wichtig wie Prävention.

Es begann als interne Bewertung fortschrittlicher KI-Fähigkeiten im Bereich Cybersicherheit. Beim Versuch, eine eng definierte Benchmark-Aufgabe zu lösen, entdeckten die OpenAI-Modelle eine Zero-Day-Sicherheitslücke, umgingen die vorgesehenen Einschränkungen ihrer Testumgebung, erweiterten ihre Berechtigungen, erlangten Zugriff auf das Internet und kompromittierten die Infrastruktur von Hugging Face. Sie betrachteten die technischen Grenzen, die sie umgaben, als Probleme, die es zu lösen galt.

Dies war kein herkömmlicher Cyberangriff

Hugging Face berichtete als Erstes, dass ein Framework für autonome KI-Agenten einen Teil seiner Produktionsinfrastruktur kompromittiert hatte. Ein bösartiger Datensatz nutzte zwei Codeausführungspfade in der Pipeline zur Datensatzverarbeitung aus, erlangte Zugriff auf Knotenebene, sammelte Anmeldedaten und bewegte sich lateral über interne Cluster hinweg.

Die beteiligten Modelle, darunter GPT-5.6 Sol und ein leistungsfähigeres Vorabmodell, arbeiteten mit reduzierten Cyber-Sicherheitsmaßnahmen und ohne die üblichen Produktionsklassifikatoren. Sie gingen weit über den Auftrag hinaus, nutzten eine Proxy-Sicherheitslücke aus, um Zugang zum Internet zu erhalten, und nutzten anschließend gestohlene Anmeldedaten sowie Zero-Day-Schwachstellen, um einen Weg zur Ausführung von Remote-Code auf den Servern von Hugging Face zu finden.

Ein böswilliger Vorsatz war nicht erforderlich

Es gibt keine öffentlichen Hinweise darauf, dass die Modelle kriminelle Absichten entwickelten oder sich dafür entschieden, Hugging Face zu schaden. Das mussten sie auch gar nicht. Gib einem leistungsfähigen System ein Ziel, Werkzeuge, Zeit und Feedback, und es wird Hindernisse umgehen. Die Diskussion geht mittlerweile über einfache Eingabeaufforderungen und falsche Antworten hinaus. Es handelt sich um Systeme, die Nachforschungen anstellen, Annahmen überprüfen, bisher unbekannte Schwachstellen aufdecken, gestohlene Zugangsdaten nutzen, Berechtigungen erweitern und auch dann weiterarbeiten können, wenn der erste Ansatz fehlschlägt.

Eine Sandkiste ist kein Kraftfeld

Wir bezeichnen Umgebungen als isoliert, segmentiert und in einer Sandbox, als ob schon die Bezeichnung allein Sicherheit schaffen würde. Das tut sie nicht. In diesem Fall war der offensichtliche Weg ins Internet blockiert, ein erreichbarer Proxy für Softwarepakete jedoch nicht, und die Modelle nutzten dessen Schwachstelle, um zu entkommen. Richtlinien und erwartetes Verhalten reichen nicht aus. Die technische Umgebung selbst muss die Grenzen durchsetzen.

Warum dies eine Geschichte über Resilienz ist

Die Aktivität verlagerte sich von einer Evaluierungsumgebung über die Forschungsinfrastruktur von OpenAI ins Internet und schließlich in die Produktionsumgebung von Hugging Face. Das ist ein sich rasch ausweitender Schadensradius. Wenn KI mit Maschinen-Geschwindigkeit erkunden und agieren kann, dürfte die Zeitspanne zwischen dem ersten Zugriff und einer umfassenderen Kompromittierung weiter schrumpfen.

Hugging Face hat nicht einfach nur den ursprünglichen Zugriffspfad gesperrt und den Vorfall für beendet erklärt. Das Unternehmen hat die anfälligen Pfade zur Codeausführung geschlossen, kompromittierte Knoten neu aufgesetzt, Anmeldedaten und Tokens rotiert und die Cluster-Kontrollen verschärft. Das Ziel besteht nicht lediglich darin, ein System wiederherzustellen, sondern das Vertrauen wiederherzustellen.

Die Frage lautet nicht mehr nur: Sind unsere KI-Systeme sicher? Sie lautet vielmehr: Wenn ein leistungsfähiges KI-System einen Weg findet, von dessen Existenz wir nichts wussten, können wir dann den Schadensumfang begrenzen, kritische Abläufe aufrechterhalten, das wiederherstellen, wem wir nicht mehr vertrauen, und nachweisen, dass es sicher ist, weiterzumachen? Chris Bevil ist Principal Portfolio Marketing Manager bei Commvault.

Sicherheit endet nicht an der Grenze der unternehmenseigenen Systeme. Moderne Unternehmen verbinden ein immer größeres Netzwerk von Anwendungen von Drittanbietern mit ihren Kernplattformen, um Vertrieb, Service und Zusammenarbeit zu unterstützen. Jede dieser Verbindungen schafft einen Mehrwert. Jede einzelne birgt jedoch auch Risiken, die das Unternehmen nicht vollständig kontrollieren kann.

Dieses Risiko ist keineswegs hypothetisch. Im Juni 2026 gelang es einem Angreifer, OAuth-Token zu kompromittieren, die mit Klue verknüpft waren – einer Wettbewerbsanalyse- platform , die zur Synchronisierung von Vertriebs- und Marketingdaten mit Salesforce genutzt wird. Der Angreifer nutzte diese Token, um Zugriff auf die Salesforce-Umgebungen zahlreicher Unternehmen zu erlangen, die die Integration autorisiert hatten, darunter auch Commvault.

Sobald wir über mögliche Auswirkungen informiert wurden, hat unser Sicherheitsteam unseren Prozess zur Reaktion auf Vorfälle aktiviert, um festzustellen, was geschehen war, den Schaden einzudämmen und zu prüfen, ob Kundendaten oder Commvault-Dienste betroffen waren. Unsere Untersuchung ergab, dass sich der Vorfall auf bestimmte Geschäftsbeziehungs- und Vertriebsdaten beschränkte, die in unserer Salesforce-Umgebung gespeichert waren. Die Untersuchung ergab keine Hinweise darauf, dass Kundensicherungsdaten, Produktdaten, Produktmetadaten, Betriebsprotokolle oder Commvault-Dienste betroffen waren.

Schnell handeln, wenn es darauf ankommt

Unsere Reaktion erfolgte gemäß den festgelegten Verfahren zur Bewältigung von Sicherheitsvorfällen, die darauf ausgelegt sind, Risiken schnell einzudämmen und gleichzeitig eine gründliche Untersuchung zu ermöglichen. Sobald wir über den Vorfall informiert wurden, haben wir die Klue-Integration deaktiviert, die entsprechenden Zugriffsrechte widerrufen und gemeinsam mit den zuständigen Stellen eine umfassende Analyse des Vorfalls durchgeführt. Während der gesamten Untersuchung arbeiteten unsere Teams daran, festzustellen, auf welche Informationen zugegriffen worden war, die Integrität unserer Umgebung zu überprüfen und sicherzustellen, dass der Vorfall innerhalb des bereits eingedämmten Umfangs blieb.

Ein bemerkenswertes Muster

Dieser Vorfall ist ein aktuelles Beispiel für einen Trend, den Sicherheitsteams seit mehreren Jahren beobachten: Angreifer zielen auf Anwendungen von Drittanbietern ab, die mit zentralen Geschäftssystemen verbunden sind, anstatt diese Systeme direkt anzugreifen. Eine einzige kompromittierte Integration kann einen vertrauenswürdigen Zugang zu den Umgebungen vieler nachgelagerter Organisationen gleichzeitig bieten – oft mit weniger Widerstand als ein direkter Angriff auf eine einzelne dieser Organisationen.

Dadurch verschiebt sich der Schwerpunkt der Verteidigungsmaßnahmen eines Unternehmens. Strenge interne Kontrollen sind nach wie vor notwendig, reichen aber allein nicht mehr aus. Sie müssen mit einer aktiven Überwachung jeder Anwendung, die ein Unternehmen nutzt, sowie mit Reaktionskapazitäten einhergehen, die bereits vor einem Vorfall bereitstehen und nicht erst währenddessen aufgebaut werden.

Resilienz über unser eigenes Umfeld hinaus stärken

Bei Commvault umfasst unser Sicherheitsprogramm eine kontinuierliche Überprüfung der mit unserer Umgebung verbundenen Anwendungen von Drittanbietern. Wir überprüfen die verbundenen Anwendungen regelmäßig, bewerten die jeweiligen Zugriffsrechte, überwachen neu auftretende Risiken und überprüfen diese Integrationen erneut, sobald sich die geschäftlichen Anforderungen und die Bedrohungslage ändern. Wenn es die Umstände erfordern, ergreifen wir Maßnahmen, um Risiken zu minimieren und unsere Sicherheitslage zu stärken, einschließlich der Trennung von Integrationen, die unseren Standards nicht mehr entsprechen.

Unser Bekenntnis zur Transparenz

Vertrauen entsteht durch Offenheit und Verantwortungsbewusstsein. Wenn ein Vorfall unsere Stakeholder betrifft, halten wir es für wichtig, unsere Erkenntnisse mitzuteilen, unsere Maßnahmen zu erläutern und die Ergebnisse unserer Untersuchung offenzulegen – auch dann, wenn der Vorfall seinen Ursprung außerhalb unserer eigenen Systeme hatte. Im Rahmen unseres umfassenden Engagements für den Schutz unserer Kunden und Partner werden wir unsere Sicherheitsmaßnahmen weiterhin überprüfen, unsere Prozesse zur Reaktion auf Vorfälle optimieren und unseren Ansatz im Umgang mit Risiken durch Dritte weiter ausbauen.

Die offiziellen Einzelheiten zu diesem Vorfall, einschließlich des Umfangs der Untersuchung und der Hinweise für Kunden, finden Sie in den aktuellen Meldungen in unserem Trust Center. Will Galway ist stellvertretender CISO bei Commvault.