„Ein KI-Agent sollte nur für Mikrosekunden Zugriff bekommen“

John Aisien, Senior Vice President und General Manager, Central Product Management and Security and Risk bei ServiceNow, erklärt im Exklusiv-Interview mit it&d business, warum KI-Agenten die Spielregeln der Cybersecurity grundlegend verändern und permanente Zugriffsrechte zum Risiko werden. Er spricht über den Weg von „Zero Trust“ zu „Zero Permission“, ServiceNows wachsende Security-Ambitionen – und darüber, warum ausgerechnet Cyberkriminelle vormachen, wie erfolgreiche Zusammenarbeit funktioniert.

Foto: ServiceNow

Security könnte für ServiceNow zu einem der wichtigsten Geschäftsfelder der kommenden Jahre werden. CEO Bill McDermott stellte bei der Knowledge-Konferenz sogar in den Raum, dass es bis 2030 zum größten Business des Unternehmens werden könnte.

Im Gespräch mit it&d business erklärt John Aisien, warum ServiceNow im Security-Markt so große Chancen sieht – und weshalb dafür aus seiner Sicht eine neue Sicherheitsarchitektur notwendig wird. Denn in einer Welt autonom agierender KI-Agenten reicht selbst Zero Trust womöglich nicht mehr aus. Aisiens Zielbild heißt „Zero Permission“: Zugriffsrechte entstehen nur dann, wenn sie für eine konkrete Aktion benötigt werden – und verschwinden unmittelbar danach wieder.

Bill McDermott hat gesagt, es würde ihn nicht überraschen, wenn Security bis 2030 zum größten Geschäft von ServiceNow wird. Teilen Sie diese Einschätzung?

Ich stimme ihm zu. Es gibt mehrere Entwicklungen, die nicht ServiceNow-spezifisch sind und von denen der gesamte Security-Markt profitiert. Eine davon ist schlicht die Größe des Cybercrime-Marktes. Bill hat mehrfach darauf hingewiesen: Wäre Cybercrime ein Land, wäre seine Wirtschaftskraft etwas kleiner als jene Chinas und der USA – es wäre also die drittgrößte Volkswirtschaft der Welt. Wir sprechen damit über eine gewaltige Marktchance, von der natürlich auch alle anderen Security- und Risk-Anbieter profitieren.

Der zweite große Treiber ist KI. Es ist derzeit leicht, überall AI draufzuschreiben, aber hier trifft es tatsächlich zu: KI vergrößert die Angriffsfläche. Die Möglichkeiten, unberechtigt auf Unternehmensdaten zuzugreifen, nehmen sowohl hinsichtlich ihres Umfangs als auch ihrer Geschwindigkeit exponentiell zu.

Das erklärt den wachsenden Security-Markt. Aber warum sollte gerade ServiceNow davon überproportional profitieren?

Wenn man betrachtet, was ServiceNow seit 20 Jahren macht, dann sind wir bei unseren Kunden eine primäre Quelle für Informationen über deren Assets. Und was ist die Grundlage von Security und Risk? Es geht um die Dinge, die geschützt werden müssen und die letztlich Zugang zu Daten ermöglichen.

Unsere Kunden nutzen ServiceNow als Datenbasis für ihre IT-Assets – also für Dinge, die sie besitzen, die mit ihrem Netzwerk verbunden sind und Zugriff auf ihre Daten haben. Wenn wir keinen Schutz für diese Assets bereitstellen, würden wir unserer Verantwortung fast nicht gerecht.

Hinzu kommen die Workflows. Die beiden häufigsten Objekte auf der ServiceNow-Plattform sind vereinfacht gesagt Assets und Tasks. Wenn man diese beiden Dinge zusammenführt, wäre es seltsam, einem CIO, CTO oder CISO zu sagen: Ihr habt all diese Asset-Daten und Workflow-Fähigkeiten bei uns, aber um Security-Ergebnisse zu erzielen, müsst ihr sie woanders hinbringen.

Ein weiterer Vorteil lautet: Alle Daten sind Security-Daten. Ob CRM, Backoffice, ERP, Gebäudemanagement oder HR – wir haben Workflows quer durch die Organisation. Daraus können Signale entstehen, die für Security und Risk relevant sind.

Gleichzeitig schaffen KI-Agenten eine neue Qualität des Problems. Sie sprechen deshalb nicht mehr nur von „Zero Trust“, sondern von „Zero Permission“. Was verstehen Sie darunter?

Im Kern geht es darum, eine Security-Architektur der nächsten Generation für die Welt der KI-Agenten zu schaffen. Wenn man sich ansieht, welche Rolle beispielsweise Active Directory in der Client-Server-, Web- und Cloud-Welt gespielt hat, dann war es der dominante Ansatz für Authentifizierung, Autorisierung und Identity Administration. Das ist großartige Technologie, daran ist nichts falsch.

Für die agentische Ära ist diese Architektur meiner Ansicht nach aber nicht die richtige. Agentische Workloads können zusätzliche Berechtigungen benötigen, um die Ergebnisse zu erzielen, für die sie entwickelt wurden. Wenn Systeme wie SAP, ServiceNow oder Azure über permanente Berechtigungen verfügen, die ständig verwaltet werden müssen, läuft man diesen Berechtigungen permanent hinterher.

Stellen Sie sich Ihr Haus vor: Sie können sehr viele Alarmanlagen installieren. Wenn aber gleichzeitig 85 Personen, 100 Systeme und wer weiß wie viele Agenten permanent Zutritt haben, hilft das nur bedingt. Ich möchte nicht, dass Sie grundsätzlich Zugang zu meinem Haus haben. Wenn ich Sie einlade, lasse ich Sie hinein. Sie bleiben drei Stunden, wir essen Sauerkraut, trinken ein Bier – und dann gehen Sie wieder.

Genau dieses Konzept müssen wir auf die Technologiewelt übertragen.

„Ich möchte nicht, dass Sie grundsätzlich Zugang zu meinem Haus haben. Wenn ich Sie einlade, lasse ich Sie hinein – und wenn Sie wieder gehen, ist der Zugang weg.“

Was bedeutet das technisch für einen KI-Agenten?

Es geht um Just-in-Time Permissions. Berechtigungen werden nur dann vergeben, wenn sie benötigt werden, und nur so lange aufrechterhalten, wie die jeweilige Aktion dauert.

Wenn ein Agent eine HR-Datenbank aktualisieren muss, geben Sie ihm beispielsweise für zehn Mikrosekunden den dafür notwendigen Zugriff. Muss er eine Datenbank nur abfragen, erhält er genau die dafür notwendige Query-Berechtigung. Danach wird der Zugriff wieder entzogen.

„Wenn ein Agent Zugriff benötigt, geben wir ihm diesen nur für die konkrete Aktion – und danach nehmen wir ihn wieder weg.“

Das klingt nach einem radikalen Gegenentwurf zu permanent vergebenen Berechtigungen. Kann ServiceNow diese Zero-Permission-Architektur heute bereits umsetzen?

Ich sage ganz offen: Die Technologie, die ein solches Just-in-Time Provisioning und Deprovisioning ermöglicht, existiert heute noch nicht.

Aber durch den Access Graph, den wir haben, unsere Forschungs- und Entwicklungsarbeit und die Bereitschaft, mit anderen Anbietern zusammenzuarbeiten – Palo Alto Networks ist ein Beispiel – glauben wir, dass wir dieses Ziel voranbringen können.

Und selbst wenn wir niemals eine vollständig reine Zero-Permission-Architektur erreichen: Wenn wir uns vom heutigen Zustand deutlich in Richtung dieser Utopie bewegen, haben wir die Sicherheit unserer Kunden bereits erheblich verbessert. Genau das wollen wir erreichen.

Damit sind Sie auf andere Security-Anbieter angewiesen. Gerade diese Branche ist aber von einem harten Wettbewerb um Plattformen, Daten und Budgets geprägt. Wie realistisch ist echte Zusammenarbeit?

Sie ist unglaublich wichtig. Ich kann mir kaum einen Markt vorstellen, in dem echte Partnerschaften wichtiger wären. Und mit echten Partnerschaften meine ich ausdrücklich nicht Pressemitteilungen, die veröffentlicht werden und nach denen nichts mehr passiert. Es geht um Kooperationen, bei denen wir das, was unsere Kernkompetenz ist, mit den Kernkompetenzen anderer verbinden, um für Kunden einen besseren Schutz zu schaffen.

Ich arbeite seit 26 Jahren in Cybersecurity und fand eine Sache immer seltsam: Die Angreifer arbeiten sehr, sehr gut zusammen. Sie verkaufen einander im Deep Web und Dark Web Tools, Techniken und Verfahren für Angriffe und Cybercrime. Es gibt ein ökonomisches Modell und Technologien, mit denen sie Tools und Methoden bis hin zu Command-and-Control-Servern teilen.

Die Verteidiger hingegen konkurrieren um Umsatz. Ich sage nicht, dass Wettbewerb um Umsatz schlecht ist. Aber wir brauchen ein wirtschaftliches Modell, das auch technische Zusammenarbeit fördert.

„Die Angreifer arbeiten sehr, sehr gut zusammen. Die Verteidiger hingegen konkurrieren um Umsatz.“

Wie soll diese Zusammenarbeit konkret funktionieren?

Ein Beispiel ist das von uns angekündigte Action Fabric. Nehmen Sie den HR-Bereich: Aus einem Human Resources Service Desk können Signale für Insider-Risiken entstehen, die anschließend Security- und Risk-Maßnahmen auslösen.

Aber stellen Sie sich einen Kunden vor, der für HR SAP, Workday oder Oracle verwendet. Als Kunde möchte ich nicht gezwungen sein, ServiceNow für HR einzusetzen, nur um dieses Security-Ergebnis zu erreichen. Wenn andere HR-Anwendungen ihre Signale mit ServiceNow teilen, können wir über Action Fabric trotzdem dasselbe Ergebnis erzielen.

Unsere Verantwortung besteht jetzt darin, es nicht bei einem generischen Plattformkonstrukt zu belassen, sondern darauf konkrete Anwendungen aufzubauen – beispielsweise für sichere M&A-Prozesse, Insider Threat Management oder Segregation of Duties. Andere ISVs können wiederum darauf aufbauen und ihre Anwendungen verbessern. Sie verdienen daran, wir verdienen daran und der Kunde wird sicherer.

Trotzdem stellt sich bei einem Security-Ökosystem die Frage, wer am Ende führt. Muss es nicht einen Anbieter geben, bei dem die Fäden zusammenlaufen?

Das sehe ich nicht so. Es wird Anwendungen geben, bei denen beispielsweise CrowdStrike führt und wir Signale liefern. Bei anderen Anwendungen führen wir und CrowdStrike liefert uns Informationen. Es muss nicht in jedem Kontext einen einzigen Anbieter geben, der der zentrale Aggregator der Lösung ist.

Wir verfügen bereits über den umfassendsten Asset Graph der Welt. Das ist Fakt. Es ergibt keinen Sinn, diese Rolle an jemand anderen abzugeben. Andere Anbieter, die beispielsweise am Endpoint zusätzliche Asset-Informationen haben, können diese an uns liefern.

Umgekehrt haben wir keinen vergleichbaren Marktanteil bei Endpoint Detection and Response. Wir erhalten zwar EDR-Signale, aber in diesem Fall kann es sinnvoll sein, diese Informationen beispielsweise CrowdStrike zur Verfügung zu stellen, weil das Unternehmen dort größere Fähigkeiten und wesentlich mehr Kunden hat.

„Es muss nicht immer ein Anbieter der zentrale Aggregator einer Security-Lösung sein.“

Das ist für einen Plattformanbieter eine durchaus bemerkenswerte Aussage. ServiceNow muss also nicht zwangsläufig das führende System sein?

Nein. Es hängt vom jeweiligen Kontext ab. Bei manchen Anwendungen ist ein anderer Anbieter in der Führung und wir liefern die Signale. Bei anderen Anwendungen ist es umgekehrt. Ich sehe Security-Partnerschaften als echte Zusammenarbeit.

Beim Kunden treffen Sie ohnehin selten auf eine grüne Wiese. Bedeutet diese Strategie auch, dass Unternehmen ihre bestehenden Security- und IT-Systeme nicht durch ServiceNow ersetzen müssen?

Es hängt davon ab, welches Problem der Kunde lösen möchte. Genau deshalb gefällt mir Action Fabric so gut: Wir können den Kunden dort abholen, wo er steht. Wir zwingen ihn nicht dazu, seine vorhandenen Lösungen auszutauschen. Stattdessen geben wir ihm die Möglichkeit, das weiterzuverwenden, was er bereits einsetzt, und diese Anwendungen zu verbessern.

Nehmen wir beispielsweise ein Unternehmen, das IBM Maximo für Asset Management verwendet. Dann sagen wir nicht: Ersetzt Maximo. Maximo ist für Asset Management für seinen Zweck eine hervorragende Lösung. Es wurde aber nicht für Cyber Asset Management entwickelt.

Unsere Aufgabe wäre in diesem Fall, Armis als Cyber-Asset-Management-Lösung einzusetzen und mit Maximo bidirektional zu integrieren. Anschließend nutzen wir die Kombination der Daten aus beiden Systemen, um das Security-Ergebnis zu verbessern.

Wo sehen Sie dabei die Bereiche, in denen ServiceNow selbst die Führungsrolle beansprucht?

Wir haben Klarheit darüber, wo wir besonders stark sind: bei Assets, beim Zugriff und beim organisationsspezifischen Enterprise-Wissen. Wenn beim Kunden andere Systeme vorhanden sind, können wir diese integrieren und die jeweiligen Daten gemeinsam nutzen, um bessere Security-Ergebnisse zu erzielen.

Es geht darum, den Kunden dort abzuholen, wo er steht. Wir zwingen ihn nicht dazu, das auszutauschen, was er heute verwendet.

it&d business Redaktion