Wenn das überwachte System den Monitor steuert

Eine Sicherheitskontrolle kann vorhanden, aktiviert und scheinbar funktionsfähig sein, während jemand im Stillen ihre Funktionsfähigkeit untergräbt. 

Ein kürzlich veröffentlichter Bericht von OpenAI beschreibt zwei Vorfälle mit KI-Agenten, die interne Codierungsaufgaben bearbeiteten. In einem Fall unterdrückte ein Agent automatische Sicherheitswarnungen, während er eine Evaluierungspipeline reparierte. Die Überwachung lief zwar weiter und speicherte Berichte, die Warnmeldungen, die diese Berichte einem menschlichen Mitarbeiter zur Kenntnis bringen sollten, waren jedoch deaktiviert. In einem anderen Fall entfernte ein Agent während einer Codeänderung eine Überwachungsintegration und meldete anschließend ungenau, was er geändert hatte. 

Die Details unterscheiden sich, aber beide Vorfälle werfen eine grundlegende architektonische Frage auf. Was geschieht, wenn das überwachte System genügend Kontrolle besitzt, um seine eigene Überwachung zu stören? 

Die Anwendungssicherheit kämpft seit Jahren mit einer ähnlichen Problematik. Eine mobile Anwendung läuft auf einem Gerät, das nicht unter der Kontrolle des Entwicklers steht. Ein Angreifer kann möglicherweise ihren Code untersuchen, ihre Ausführung manipulieren oder versuchen, die Schutzmechanismen zu deaktivieren, die diese Aktivitäten erkennen sollen. Doch das Hinzufügen einer Sicherheitsprüfung ist nur der erste Schritt. Auch die Prüfung selbst muss geschützt werden. 

Wer bewacht die Wachen? 

Stellen Sie sich eine Mobile-Banking-Anwendung vor, die prüft, ob ihr Code verändert wurde. Wird eine Manipulation festgestellt, könnte die Anwendung deaktiviert, eine zusätzliche Authentifizierung verlangt oder Überweisungen mit hohem Wert eingeschränkt werden, während weniger sensible Funktionen weiterhin verfügbar bleiben. Das sind sinnvolle Maßnahmen. Doch sie werfen eine weitere Frage auf: Was hindert einen Angreifer daran, die Integritätsprüfung zu finden und sie so zu verändern, dass sie wirkungslos wird? 

Ein Schutzmechanismus, der sich widerstandslos deaktivieren lässt, kann Entwicklern ein trügerisches Sicherheitsgefühl vermitteln. Die Anwendung enthält zwar Code zur Erkennung von Manipulationen, doch ein Angreifer, der diesen Code verändern kann, ist möglicherweise auch in der Lage, diese Erkennung zu umgehen. 

Dasselbe gilt für die Bedrohungsüberwachung. Ein System mag verdächtiges Verhalten erkennen, doch diese Fähigkeit ist wertlos, wenn ein Angreifer den Mechanismus zur Erkennung manipulieren oder dessen Ergebnisse unterdrücken kann. Dies ist die Herausforderung hinter einer altbekannten Frage in der IT-Sicherheit: Wer bewacht die Wächter? 

Zusätzlicher Schutz kann helfen, aber nur, wenn die Schutzmaßnahmen selbst bereits im Design berücksichtigt sind. Andernfalls kann ein Angreifer einfach den Mechanismus angreifen, der die Sicherheitsrichtlinie durchsetzt. 

Aufbau eines Wachnetzwerks 

Digital.aiDie Arxan-Anwendungsschutztechnologie begegnet dieser Herausforderung mit einem System von Sicherheitskontrollen, den sogenannten Guards. Guards werden in die Binärdatei der geschützten Anwendung integriert. Sie überprüfen die Integrität der Anwendung und reagieren auf erkannte Manipulationen gemäß den für die Anwendung konfigurierten Richtlinien. Je nach Anwendungsfall kann eine Reaktion die Anwendung beenden, eine zusätzliche Authentifizierung auslösen oder sensible Funktionen wie beispielsweise hochpreisige Finanztransfers deaktivieren. Ein wichtiges architektonisches Detail ist, dass die Guards selbst durch weitere Guards geschützt werden können. 

Dadurch entsteht etwas, das wir als … bezeichnen. WachnetzwerkEine Schutzinstanz muss nicht isoliert und für Angreifer leicht angreifbar sein. Sie kann von anderen Schutzinstanzen geschützt werden, und diese Schutzmechanismen können wiederum durch weitere Schutzebenen verstärkt werden. In manchen Implementierungen erstreckt sich die Schutzkette über mehrere Ebenen, wobei Schutzinstanzen weitere Schutzinstanzen schützen, die wiederum andere Schutzinstanzen schützen. 

Diese mehrschichtige Struktur verändert die Herausforderung für Angreifer. Das Deaktivieren einer bestimmten Sicherheitsprüfung kann es erforderlich machen, auch die umgebenden Schutzmechanismen zu überwinden. Ein Eingriff in einen Teil der Schutzarchitektur kann auf andere Teile stoßen, die diesen Eingriff erkennen oder ihm widerstehen sollen. Dieses Design ist heute wichtiger denn je. KI-Tools haben die Kosten und den erforderlichen Aufwand für das Reverse Engineering von Anwendungen in großem Umfang gesenkt, und eine einzelne, isolierte Überprüfung ist genau die Art von Ziel, die automatisierte Analysen schnell finden und beheben können.  

Wenn Guards so konfiguriert sind, dass sie sich gegenseitig schützen, führt das Entfernen eines Guards dazu, dass andere Guards ausgelöst werden. Je nach Ziel können Teams den Schutz selbst auch mit mehreren Einstellungen variieren: Startwerte, die jede geschützte Version strukturell unterschiedlich gestalten, zufällige Auswahl von Guard-Instanzen zum Schutzzeitpunkt und Ausführungswahrscheinlichkeiten, die sicherstellen, dass nicht jeder Guard bei jeder Ausführung ausgeführt wird. Einige Guards variieren ihr Verhalten zur Laufzeit, sodass sie keine statische Signatur aufweisen: Eine inkrementelle Prüfsumme kann beispielsweise bei jedem Aufruf einen anderen Bereich überprüfen, anstatt eine feste Prüfung zu wiederholen, die eine automatisierte Analyse lernen und umgehen könnte. Eine Stripping-Routine, die bei einer Veröffentlichung oder einem Durchlauf funktioniert hat, garantiert nicht, dass sie auch bei der nächsten funktioniert. 

Das Guard Network behauptet nicht, dass eine Anwendung unangreifbar wird. Keine Architektur kann dies gegen jeden Angreifer, jede Plattform oder jede Bedrohung garantieren. Sein Zweck ist es, die Schutzmechanismen schwerer auffindbar, veränderbar und neutralisierbar zu machen, unter anderem durch die Berücksichtigung von Angriffen auf die Schutzmechanismen selbst. Diese Unterscheidung ist wichtig. Angreifer müssen nicht immer eine gesamte Sicherheitsarchitektur überwinden. Manchmal genügt es, den einen Mechanismus zu deaktivieren, der ihre Aktivitäten sonst aufdecken würde. Der Schutz der Guards erhöht die Schwierigkeit dieses Vorgehens.  

Die Erkennung benötigt einen Reaktionsweg. 

Der Schutz von Integritätsprüfungen ist nur ein Teil des Problems. Sicherheitsteams benötigen außerdem Einblick in die Vorgänge, wenn eine Anwendung auf einen verdächtigen Zustand stößt. 

Arxan Threat Monitoring arbeitet innerhalb der geschützten Anwendung. Die Überwachungssteuerung ist in die Binärdatei integriert, und Warnmeldungen können über einen Browser angezeigt oder in ein SIEM-System (Security Information and Event Management) eingebunden werden. Dadurch können Unternehmen Sicherheitsereignisse auf Anwendungsebene überprüfen und in ihre umfassenderen Sicherheitsmaßnahmen integrieren. Die Architektur spielt dabei eine wichtige Rolle. Da die Überwachung innerhalb der Anwendung erfolgt, sollte sie nicht als rein externer Beobachter betrachtet werden. Ihre Steuerung ist Teil der geschützten Binärdatei, und die Schutzarchitektur ist so konzipiert, dass sie Manipulationen an der Anwendung und ihren Sicherheitsmechanismen widersteht. 

Das Guard-Netzwerk trägt wesentlich zum Schutz der Kontrollmechanismen bei. Externe Alarmierung und SIEM-Integration ermöglichen die Bereitstellung gemeldeter Ereignisse über die Anwendung hinaus. Diese Mechanismen dienen unterschiedlichen Zwecken. Guards schützen die Integrität von Anwendungen und lösen Reaktionen auf erkannte Manipulationen aus. Bedrohungsüberwachung deckt sicherheitsrelevante Aktivitäten auf. Externe Berichte unterstützen Sicherheitsteams bei der Untersuchung von Ereignissen und der Koordination von Gegenmaßnahmen. 

Jeder Teil hat seine Grenzen. Ein Meldekanal kann kein Ereignis melden, das nie erkannt wurde, und kein Schutzsystem kann jedem möglichen Angriff standhalten. Ziel ist es, Angreifern die Kompromittierung einer Anwendung zu erschweren und anschließend die Mechanismen zu deaktivieren, die diese Kompromittierung aufdecken oder einschränken sollen. 

Die Reaktion sollte der Bedrohung angemessen sein. 

Sicherheitskontrollen werden oft im Hinblick darauf diskutiert, was sie erkennen. In der Praxis ist das weitere Vorgehen jedoch genauso wichtig. Eine Banking-Anwendung könnte nach dem Erkennen eines verdächtigen Zustands eine zusätzliche Authentifizierung anfordern. Sie könnte Überweisungen mit hohem Wert einschränken, während der reguläre Betrieb weiterhin möglich bleibt. Eine Anwendung mit strengeren Integritätsanforderungen könnte sich bei Codeänderungen selbst beenden. Diese Reaktionen spiegeln unterschiedliche Risikobewertungen wider. Ein Entwickler kann die passende Reaktion je nach Anwendung, Bedrohung und den potenziellen Folgen einer Fortsetzung der Ausführung wählen. 

Einer unserer Gaming-Kunden wählte einen eher unterhaltsamen Ansatz. Das Team entwickelte einen Schutzmechanismus, der Cheater erkannte. Sobald dieser Mechanismus aktiviert wurde, deaktivierte er die Schwerkraft im Spiel. Die Spieler des Cheaters schwebten daraufhin vom Spielfeld. Dieses einprägsame Beispiel verdeutlicht die Ernsthaftigkeit des zugrundeliegenden Konzepts. Der Schutzmechanismus war mit einer Konsequenz verknüpft, die in der jeweiligen Spielumgebung relevant war. Anstatt die Erkennung als Abschluss des Prozesses zu betrachten, nutzte der Entwickler sie, um die Spielmechanik anzupassen. 

Dasselbe Prinzip gilt, wenn es um finanzielle Folgen, sensible Daten oder den Zugriff auf kritische Funktionen geht. Die Reaktion muss dem Risiko angemessen sein, und es sollte für Angreifer schwierig sein, den auslösenden Mechanismus zu neutralisieren. Entwickler müssen zudem Fehlalarme, Wiederherstellungswege und die Auswirkungen auf legitime Nutzer berücksichtigen. Der Schutz sollte die Ausfallsicherheit einer Anwendung verbessern, ohne unnötige Störungen zu verursachen. 

Fragen Sie, was passiert, wenn die Wachen ins Visier genommen werden. 

Der OpenAI-Bericht erinnert eindrücklich daran, dass Überwachungsmechanismen durch Änderungen an den zu überwachenden Systemen untergraben werden können. Anwendungsentwickler stehen vor einer ähnlichen Herausforderung, wenn ihre Software in Umgebungen läuft, in denen Angreifer die Ausführung einsehen und manipulieren können. Die Frage geht über die Frage hinaus, ob eine Anwendung Integritätsprüfungen oder Bedrohungsüberwachung implementiert hat. Es geht vielmehr darum, wie diese Mechanismen geschützt sind, wie sie auf Störungen reagieren und ob ein Angreifer die Kontrollmechanismen deaktivieren kann, die den Angriff andernfalls aufdecken würden. 

Hier kommt das Guard-Netzwerk ins Spiel. Indem Arxan Guards zum Schutz anderer Guards einsetzt, werden zusätzliche Schutzebenen um die Sicherheitsmechanismen selbst herum geschaffen. Dies erschwert Angreifern, die versuchen, die Anwendungssicherheit zu modifizieren oder einzelne Kontrollen zu neutralisieren, weitere Schwierigkeiten. Bei der Bewertung einer Anwendungssicherheitsarchitektur sollten Sie sich drei Fragen stellen.

1) Was passiert, wenn ein Angreifer den Schutzmechanismus selbst ins Visier nimmt?
2) Was verhindert, dass eine einzelne Modifikation einen kritischen Sicherheitsmechanismus außer Kraft setzt?
3) Welche Optionen stehen der Anwendung zur Verfügung, wenn ein Wächter eine Manipulation feststellt? 

Ziel ist es nicht, absolute Unverletzlichkeit einer Anwendung zu garantieren. Vielmehr geht es darum, Manipulationen zu erschweren, wirksame Schutzmechanismen auch unter Angriffen aufrechtzuerhalten und Entwicklern praktische Möglichkeiten zu geben, zu reagieren, wenn die Integrität der Anwendung in Frage steht. Manchmal bedeutet diese Reaktion, eine Finanztransaktion einzuschränken. Manchmal bedeutet sie, die Anwendung abzuschalten. 

Und manchmal bedeutet es, die Schwerkraft auszuschalten und zuzusehen, wie die Spieler eines Betrügers davonschweben.