Craig Riddell, Globaler Field CISO bei Wallarm – Interview-Serie

Craig Riddell, Globaler Field CISO bei Wallarm, ist ein erfahrener Cyber-Sicherheitsexperte, der sich auf die Unterstützung von Unternehmen bei der Bewältigung der wachsenden Risiken im Zusammenhang mit APIs und künstlicher Intelligenz (KI) konzentriert. In seiner aktuellen Rolle arbeitet er eng mit CISOs, CIOs und Engineering-Führern zusammen, um reale Angriffsmuster und Missbrauchsszenarien in handhabbare Sicherheitsstrategien umzusetzen, mit einem starken Fokus auf Beobachtbarkeit – das Verständnis, wie APIs und KI-Systeme in der Produktion über Benutzer, Anwendungen und Integrationen hinweg funktionieren. Seine Karriere umfasst Führungsrollen in den Bereichen Identitäts- und Zugriffsmanagement, Zero-Trust-Architektur und Unternehmenssicherheit bei Unternehmen wie Netwrix, Kron und HP, wo er große IAM-Transformationen vorantrieb und Sicherheitsframeworks modernisierte. Riddells Expertise konzentriert sich auf neue Bedrohungen wie Business-Logic-Angriffe, API-Missbrauch, KI-Systemdrift und Betrug, mit einem konsequenten Fokus auf die Überbrückung der Lücke zwischen hoher Sicherheitsstrategie und operativer Umsetzung.

Wallarm ist ein Cyber-Sicherheitsunternehmen, das sich auf den Schutz von APIs, Anwendungen und KI-Systemen in modernen Cloud-Umgebungen spezialisiert hat. Seine Plattform bietet kontinuierliche Entdeckung, Tests und Echtzeit-Schutz gegen Bedrohungen wie API-Missbrauch, Business-Logic-Angriffe und automatisierte Exploits, während sie tiefere Einblicke in das Verhalten von Systemen über komplexe Infrastrukturen hinweg bietet. Für Multi-Cloud- und Cloud-native-Architekturen konzipiert, integriert Wallarm in bestehende DevOps- und Sicherheitsworkflows, sodass Unternehmen Angriffe erkennen und blockieren können, bevor sie passieren. Durch die Kombination von API-Inventar, KI-gesteuerter Bedrohungserkennung und automatisierter Reaktionsfähigkeit adressiert die Plattform eine wachsende Realität, in der APIs und KI-Systeme zur primären Angriffsfläche für moderne digitale Unternehmen geworden sind.

Sie haben Ihre Karriere damit begonnen, direkt mit Systemen und Infrastruktur zu arbeiten, und sind seitdem in Führungsrollen übergegangen, die sich auf Identität, Zugriff, API und KI-Sicherheit konzentrieren. Welche wichtigen Veränderungen auf diesem Weg haben Sie dazu geführt, zu dem Schluss zu kommen, dass das eigentliche Risiko sich von der Peripherie in APIs und maschinengesteuerte Systeme verlagert hat?

Früh in meiner Karriere lag der Fokus auf dem Schutz der Peripherie. Firewalls, Segmentierung, Infrastruktur-Härtung. Dieses Modell funktionierte, als Systeme statischer und Vertrauensgrenzen leichter zu definieren waren.

Was sich geändert hat, ist, wie Anwendungen gebaut und wie Systeme interagieren. APIs wurden zum Bindegewebe von allem, und KI beschleunigte dies weiter. Jetzt machen Systeme Entscheidungen, rufen andere Systeme auf und führen Aktionen in einem Maß und einer Geschwindigkeit aus, die nicht mehr von Menschen im Entscheidungsprozess abhängig sind.

An diesem Punkt wird die Peripherie weniger relevant. Das eigentliche Risiko verlagert sich dorthin, wo Entscheidungen getroffen und Aktionen ausgeführt werden, innerhalb von APIs und maschinengesteuerten Workflows.

Wenn Sie dort keine Sichtbarkeit und Kontrolle haben, vertrauen Sie auf Verhaltensweisen, die Sie nicht vollständig sehen können. Dort zeigt sich das Geschäftsrisiko, von finanzieller Exposition bis hin zu ungewollten Ergebnissen und operativer Störung.

Sie haben den Cyber-Handshake als gebrochen bezeichnet, in Bezug auf die Art und Weise, wie Systeme Vertrauen herstellen und Aktionen über zunehmend komplexe Ketten von APIs und automatisierten Prozessen austauschen. Wie sieht dieser Zusammenbruch in einer realen Unternehmensumgebung aus?

In den meisten Umgebungen vertrauen Systeme einander auf der Grundlage von Identität und Authentifizierung. Ein Token ist gültig, eine Anfrage ist wohlgeformt, und die Interaktion ist erlaubt.

Das Problem ist, dass dies annimmt, gültig sei gleichbedeutend mit sicher. Das ist nicht mehr wahr.

Wir authentifizieren Identität, aber wir validieren nicht die Absicht. Wir überprüfen den Zugriff, aber nicht das Verhalten über die Kette hinweg.

Ein Dienst kann autorisiert sein, einen anderen Dienst aufzurufen, der wiederum downstream-Aktionen über mehrere APIs auslöst. Jeder Schritt sieht in Isolation legitim aus, aber über die gesamte Kette hinweg beginnen Sie, ungewolltes Verhalten oder Missbrauch von Logik zu sehen.

In KI-gesteuerten Umgebungen wird dies verstärkt. Agenten können Aktionen ketten und Workflows ohne menschliche Überprüfung ausführen.

Der Handshake findet immer noch statt, aber niemand fragt, ob das Verhalten in Kontext sinnvoll ist. Vertrauen wird hergestellt, aber nicht kontinuierlich validiert.

Warum fällt das Risiko von KI und API so oft zwischen organisatorischen Grenzen, anstatt klar einem Eigentümer zugeordnet zu werden?

Weil die Systeme nicht mit der Art und Weise übereinstimmen, wie Organisationen strukturiert sind.

DevOps besitzt die Lieferung. Sicherheit besitzt die Richtlinie. Geschäftsteams besitzen die Ergebnisse. Datenteams besitzen die Modelle. Jede Gruppe besitzt ein Stück, aber niemand besitzt das System, wie es in der Produktion funktioniert.

APIs führen Geschäftslogik über Systeme hinweg aus. KI introduceiert nicht-deterministische Entscheidungsfindung darüber hinaus. Zusammen schneiden sie über jede Grenze hinweg.

Sie werden von einem Team gebaut, von einem anderen Team gesichert und von einem dritten Team genutzt, mit inkonsistenter Überwachung über alle hinweg.

Die Lücken, die dies schafft, sind nicht das Versagen von Teams. Sie sind das Versagen des Betriebsmodells, das tatsächliche Funktionieren moderner Systeme widerzuspiegeln.

In Ihrer Erfahrung, welche Teams nehmen normalerweise an, dass sie das Risiko von KI besitzen, und wo liegen die größten blinden Flecken zwischen Sicherheit, DevOps und Geschäftseinheiten?

Sicherheitsteams neigen dazu, das Risiko von KI aus Governance- und Compliance-Sicht zu besitzen. DevOps besitzt die Bereitstellung und Zuverlässigkeit. Geschäftseinheiten konzentrieren sich auf Ergebnisse.

Die blinden Flecken zeigen sich zwischen diesen Bereichen.

Sicherheit definiert, was passieren soll. DevOps stellt sicher, dass das System läuft. Das Geschäft konzentriert sich auf Ergebnisse. Aber sehr wenige Teams schauen konsistent darauf, was das System tatsächlich in Echtzeit tut.

Diese Lücke ist, wo das Risiko lebt, besonders wenn Verhalten technisch gültig, aber kontextuell falsch ist.

Viele moderne Angriffe erscheinen als gültiges und authentifiziertes Verhalten, anstatt offensichtlicher Intrusionen. Wie sollten Organisationen die Erkennung in dieser neuen Realität neu denken?

Wir müssen über das Identifizieren von “schlechten” Anfragen hinausgehen.

In vielen Fällen ist die Anfrage gültig. Die Anmeldeinformationen sind legitim. Der API-Aufruf ist erwartet. Was nicht erwartet wird, ist die Sequenz der Aktionen, das Volumen oder das Ergebnis.

Die Erkennung muss verhaltens- und kontextbezogen werden. Es geht weniger darum, eine einzelne Anfrage zu blockieren, und mehr darum, zu verstehen, wie Systeme über die Zeit miteinander interagieren.

Die Ansätze, die tatsächlich auf großen Skalen funktionieren, gehen über das Mustererkennen hinaus. Sie zerlegen Anfragen strukturell, indem sie jede Interaktion als eine Reihe von Verhaltens-Token behandeln, anstatt gegen bekannte schlechte Muster zu matchen.

Das ermöglicht es, zu verstehen, wie sich Verhalten entwickelt und wo es sich von dem abweicht, was erwartet wird, selbst wenn alles auf der Oberfläche gültig aussieht.

Wenn Sie sich auf statische Regeln oder Signaturen verlassen, werden Sie das meiste von dem verpassen, was wichtig ist.

Sie haben die Bedeutung von Beobachtbarkeit in die reale Welt hinein betont. Wie sieht sinnvolle Beobachtbarkeit für APIs und KI-Systeme in der Produktion aus?

Sinnvolle Beobachtbarkeit ist nicht nur Logs und Metriken. Es ist das Verständnis von Verhalten im Kontext.

Für APIs bedeutet das vollständige Sichtbarkeit von Anfragen und Antworten, wie Endpunkte genutzt werden und wie Interaktionen über die Zeit hinweg evolvieren.

Für KI-Systeme bedeutet es, Eingaben, Entscheidungen und resultierende Aktionen zu verstehen.

Am wichtigsten ist es, diese über Systeme hinweg in vollständige Workflows zu verbinden, anstatt isolierte Ereignisse zu betrachten.

Ohne das operieren Sie auf Annahmen über das Systemverhalten, anstatt auf Realität.

Warum werden traditionelle Modelle der menschlichen Überprüfung und Genehmigung in maschinengesteuerten Umgebungen weniger effektiv?

Weil sich die Geschwindigkeit und der Umfang geändert haben.

Systeme führen Tausende oder Millionen von Aufrufen pro Minute aus, und Angriffe oder ungewolltes Verhalten können sich in Minuten oder Sekunden entfalten. Sie können nicht realistisch einen Menschen in den Entscheidungsprozess einbeziehen, ohne die Leistung zu beeinträchtigen.

KI-Systeme sind auch nicht immer deterministisch, was Vorab-Genehmigungsmodelle weniger effektiv macht.

Menschliche Aufsicht ist immer noch wichtig, aber sie muss sich von der Genehmigung einzelner Aktionen zu der Festlegung von Sicherheitsvorkehrungen und der Überwachung von Ergebnissen verschieben.

Was sind die häufigsten operativen Lücken, die Sie sehen, wenn Unternehmen versuchen, KI-Systeme mithilfe von Legacy-Sicherheitsframeworks zu sichern?

Die größte Lücke ist die Überbetonung von Design-Zeit-Kontrollen.

Unternehmen konzentrieren sich auf die Sicherung von Modellen, die Überprüfung von Code und die Definition von Richtlinien vor der Bereitstellung. Das ist wichtig, aber es geht davon aus, dass Systeme sich wie erwartet verhalten, sobald sie live sind.

In Wirklichkeit entwickeln sich Systeme. APIs ändern sich. KI-Modelle interagieren mit neuen Daten und Workflows. Verhalten ändert sich über die Zeit.

Ohne kontinuierliche Validierung des Verhaltens in der Produktion sind Organisationen effektiv blind, nachdem sie bereitgestellt wurden.

Wie sieht ein praktisches Betriebsmodell aus, wenn mehrere Stakeholder die Verantwortung für KI- und API-Risiken teilen?

Es beginnt damit, anzuerkennen, dass kein einzelnes Team dies von Anfang bis Ende besitzen kann.

Ein praktisches Modell definiert geteilte Verantwortung, verankert in einer gemeinsamen Wahrheit: Laufzeitverhalten.

Sicherheit definiert Risiko und Richtlinie. Engineering baut und betreibt Systeme. Das Geschäft definiert akzeptable Ergebnisse.

Die Teams, die vorne liegen, operieren in einer geschlossenen Schleife. Kontinuierliche Entdeckung, Durchsetzung und Verfeinerung, getrieben von dem, was Systeme tatsächlich in der Produktion tun, und nicht von dem, was zur Design-Zeit angenommen wurde.

Alle Stakeholder benötigen Sichtbarkeit in das Verhalten von Systemen in der Produktion. Von dort aus können Teams auf das ausrichten, was “gut” aussieht, Abweichungen erkennen und reagieren.

Der Wechsel ist von isolierter Eigentümerschaft zu koordinierter Verantwortung, begründet in Laufzeit-Einblicken.

Blicken Sie in die Zukunft, erwarten Sie, dass die Sicherheitsverantwortung wieder zentralisiert wird oder weiter fragmentiert, da Systeme autonomer werden?

Die Verantwortung wird verteilt bleiben, weil das der Art und Weise entspricht, wie Systeme gebaut sind.

Was sich ändern wird, ist, wie diese Verantwortung koordiniert wird.

Wir werden mehr einheitliche Governance-Modelle sehen, in denen Teams ihre Domänen besitzen, aber mit gemeinsamer Sichtbarkeit und Kontext operieren.

Die Organisationen, die erfolgreich sind, werden nicht diejenigen sein, die versuchen, alles zu zentralisieren. Sie werden diejenigen sein, die Stakeholder um das Verhalten von Systemen in der realen Welt ausrichten.

Denn wenn niemand das Laufzeitverhalten versteht, besitzt niemand wirklich das Risiko.

Vielen Dank für das großartige Interview. Leser, die mehr erfahren möchten, sollten Wallarm besuchen.