Beobachtung statt Exploit: Entwickler testet eigenen KI-Observability-Hub

Beobachtung statt Exploit: Entwickler testet eigenen KI-Observability-Hub

In der vergangenen Woche führte ein Entwickler einen Penetrationstest an seiner eigenen Infrastruktur durch. Dabei kamen keine Tools wie Burp Suite, keine Exploits gegen die Produktion und keine Ausnutzung von CVEs zum Einsatz. Stattdessen beruhte der Test auf einem Grundsatz: Einer Sicherheitskontrolle wird erst geglaubt, wenn ihre Funktion tatsächlich beobachtet wurde. Der Autor beschreibt, dass er sich weigerte, einer Kontrolle zu vertrauen, bis er gesehen hatte, dass sie funktioniert. Er nutzte die Observability-Fähigkeiten des Hubs, um zu beobachten, ob die Sicherheitskontrollen tatsächlich griffen. Es scheint, dass der Autor nur die Methode veröffentlicht hat, nicht die konkreten Ergebnisse.

Sechs Dienste, drei öffentliche Zahlen: Der Aufbau des Testobjekts

Das Testobjekt war ein selbstgebauter Observability-Hub für KI-unterstütztes Coding. Er besteht aus sechs Diensten in einer Compose-Datei: einem Tunnel, einem OpenTelemetry Collector, der Metriken und Logs von Claude Code aufnimmt, Prometheus, Grafana, Loki und einer Status-API. Die öffentliche Angriffsfläche beschränkt sich auf drei aggregierte Zahlen; alles andere bleibt privat. Der Autor nennt diese drei Zahlen nicht im Detail. Da nur diese drei aggregierten Zahlen öffentlich zugänglich sind, ist die Angriffsfläche auf einen einzigen, lesenden Endpunkt beschränkt. Angreifer können keine Befehle ausführen, keine Daten abrufen oder in das interne Netzwerk eindringen, weil keine anderen Dienste von außen erreichbar sind. Die drei Zahlen sind vermutlich einfache Statuswerte ohne sensible Informationen. Dadurch entfallen typische Angriffsvektoren wie Injection, Authentifizierungsumgehung oder Datenexfiltration über exponierte Schnittstellen. Die internen Dienste (Tunnel, Collector, Prometheus, Grafana, Loki) sind nicht direkt aus dem Internet erreichbar und bleiben durch die Netzwerkarchitektur geschützt.

Traditionelle KI-Pentests setzen auf Simulation und Schwachstellensuche

Traditionelle KI-Penetrationstests integrieren KI und maschinelles Lernen, um Angriffe zu simulieren oder Schwachstellen zu finden. Anbieter wie FireCompass, Orca Security, Coesecurity und Trava Security beschreiben, dass Penetrationstests als simulierte Cyberangriffe verstanden werden, die Schwachstellen identifizieren und bewerten. Einige Anbieter erwähnen, dass KI-gestützte Plattformen autonom Angriffspfade erkunden oder Angriffsvektoren speziell für KI-Modelle simulieren. Andere betonen, dass KI Routineaufgaben bei der Schwachstellensuche automatisiert und die Analyse großer Systeme beschleunigt. Der neue Ansatz unterscheidet sich davon grundlegend: Er prüft die Wirksamkeit von Sicherheitskontrollen durch Beobachtung, statt aktiv Exploits einzusetzen. Während herkömmliche Methoden versuchen, in das System einzudringen, beobachtet der Entwickler, ob die vorhandenen Kontrollen tatsächlich greifen. Das ist ein Paradigmenwechsel von der Angriffssimulation zur Funktionsprüfung.

Methode veröffentlicht, Ergebnisse offen: Grenzen des neuen Ansatzes

Der Autor hat nur die Methode beschrieben, keine konkreten Ergebnisse, keine betroffenen Produkte und keine unabhängige Prüfung. Es fehlen Peer-Reviews durch unabhängige Sicherheitsforscher, die die Methodik auf Fehler oder blinde Flecken prüfen könnten. Es fehlen Red-Team-Tests, bei denen externe Angreifer versuchen, die beobachteten Kontrollen zu umgehen, um zu zeigen, ob die Beobachtung auch ausgefeilte Angriffe erkennt. Es fehlen reproduzierbare Experimente mit veröffentlichten Ergebnissen, die anderen Forschern erlauben würden, die Wirksamkeit der Methode zu bestätigen. Ohne solche Validierungsverfahren bleibt unklar, ob die Beobachtung tatsächlich alle relevanten Sicherheitskontrollen erfasst und ob die Methode zuverlässig funktioniert. Die Aussagekraft ist daher begrenzt: Der Ansatz ist konzeptionell interessant, aber sein praktischer Nutzen ist nicht belegt. Zudem fehlt eine Einordnung, ob die Methode auf andere KI-Observability-Hubs übertragbar ist. Die Übertragbarkeit hängt von Eigenschaften des beobachtungsbasierten Ansatzes ab: Er setzt voraus, dass das System über ausreichende Telemetrie verfügt, um Kontrollen sichtbar zu machen. Bei Systemen ohne umfassende Observability oder mit stark verteilten Komponenten könnte die Beobachtung lückenhaft sein. Zudem ist die Methode stark abhängig von der Definition der zu beobachtenden Kontrollen – was in einem Hub klar definiert ist, muss in anderen Umgebungen erst spezifiziert werden.