Humanoide Roboter kommen mit unternehmensfreundlichen Komponenten — WLAN, Kameras, integrierter Rechenleistung und Over-the-Air-Softwareupdates — auf den Markt, verhalten sich jedoch weniger wie herkömmliche IT-Geräte und eher wie Betriebstechnologiesysteme (OT). Sie interagieren mit der physischen Welt, arbeiten unter strengen Latenzanforderungen und können bei Fehlfunktionen erheblichen Schaden anrichten.
Diese Konvergenz ist längst keine Theorie mehr. Moderne humanoide Roboter können Umgebungen navigieren, Objekte manipulieren und Aufgaben ausführen, nachdem sie von Softwareagenten oder menschlichen Bedienern Anweisungen auf hoher Ebene erhalten haben.
Für Sicherheitsteams bedeutet das, dass eine neue Klasse cyber-physischer Endpunkte in Unternehmensumgebungen Einzug hält.
Wenn diese Systeme ausfallen — sei es durch Fehler, Fehlkonfigurationen oder eine Kompromittierung — können die Folgen über Datenverlust hinausgehen und die physische Sicherheit sowie den Betriebsablauf beeinträchtigen.
Dieser Wandel macht einen entscheidenden Unterschied zwischen humanoiden Robotern und herkömmlichen Unternehmensendpunkten deutlich.
| Sicherheitsfaktor | Herkömmlicher Endpunkt | Humanoider Roboter |
|---|---|---|
| Umgebung | Digitale Systeme | Physische Umgebung |
| Sicherheitsmodell | IT-Endpunktsicherheit | OT- und KI-Sicherheit |
| Auswirkungen von Ausfällen | Datenverlust | Sicherheit und Betriebsunterbrechungen |
| Steuerungsebene | Benutzer / Anwendung | Agenten- und Autonomiesysteme |
| Angriffsfläche | Netzwerk und Software | Sensoren, Autonomie, KI-Agenten |
| Sicherheits-Frameworks | IT-Frameworks | OT- und KI-Governance |
- Schritt eins: Humanoide als OT-Systeme behandeln
- Schritt zwei: Die Agentenebene als neue Privilegiengrenze erkennen
- Risiken agentischer Robotik auf die OWASP LLM Top 10 abbilden
- Governance-Frameworks gelten weiterhin
- Cybervorfälle können zu Sicherheitsvorfällen werden
- Grundlegende Sicherheitskontrollen für Robotikbereitstellungen
- Was in Sicherheitsanforderungen für Robotik enthalten sein sollte
- Fazit
Schritt eins: Humanoide als OT-Systeme behandeln
Sicherheitsteams sollten zunächst humanoide Roboter als Betriebstechnologiegeräte und nicht als herkömmliche Endpunkte klassifizieren.
Die Leitlinien des NIST zur Sicherheit von Betriebstechnologie definieren OT als programmierbare Systeme, die mit der physischen Umgebung interagieren und dabei Anforderungen an Zuverlässigkeit, Sicherheit und Leistungsfähigkeit erfüllen müssen. Mobile Roboter entsprechen dieser Definition.
Ebenso befassen sich die ISA/IEC-62443-Standards mit Sicherheitsanforderungen für industrielle Automatisierungs- und Steuerungssysteme (IACS). Wenn Roboter beginnen, Aufgaben in Fabriken, Lagern und Logistikeinrichtungen auszuführen, werden sie faktisch zu mobilen Komponenten innerhalb dieser Steuerungsumgebungen.
Diese Unterscheidung ist wichtig, weil viele herkömmliche Endpoint-Sicherheitstools davon ausgehen, dass Systeme Scans, Patches oder Verzögerungen tolerieren können — Annahmen, die in Umgebungen mit kritischer Verfügbarkeit und physischer Sicherheit nicht gelten.
Schritt zwei: Die Agentenebene als neue Privilegiengrenze erkennen
Moderne Robotikarchitekturen stützen sich zunehmend auf geschichtete Autonomiesysteme.
Auf der untersten Ebene steuern Echtzeitkontrollsysteme Motoren, Gleichgewicht und physische Bewegungen. Darüber liegt eine „Skill“-Ebene, die für einzelne Fähigkeiten wie das Öffnen von Türen oder Aufheben von Objekten zuständig ist.
Eine dritte Ebene — häufig als Agenten- oder Planungsebene bezeichnet — koordiniert Aufgaben auf Grundlage von Anweisungen auf hoher Ebene oder Umgebungsdaten.
In einigen Bereitstellungen kann diese Agentenebene auf lokalen Servern innerhalb einer Einrichtung statt direkt auf dem Roboter ausgeführt werden.
Aus Sicherheitssicht führt dies eine neue Privilegiengrenze ein:
- Steuerungsebene: führt physische Bewegungen aus (hohe Auswirkungen)
- Skill-Ebene: stellt einzelne Fähigkeiten bereit
- Agentenebene: bestimmt, welche Aktionen ausgeführt werden sollen (großer Hebel)
Wenn Angreifer die Agentenebene — oder die von ihr genutzten Werkzeuge und Modelle — beeinflussen, können sie möglicherweise legitime Roboteraktionen aus böswilligen Gründen auslösen.
Mit anderen Worten: Der Roboter könnte sich genau wie vorgesehen verhalten, jedoch im falschen Kontext.
Diese geschichtete Architektur schafft mehrere sicherheitsrelevante Kontaktpunkte, an denen eine Kompromittierung das Verhalten des Roboters beeinflussen könnte.
| Ebene | Funktion | Sicherheitsrisiko |
|---|---|---|
| Steuerungsebene | Physische Bewegung und Gleichgewicht | Direkte Auswirkungen auf die Sicherheit |
| Skill-Ebene | Objektmanipulation und Navigation | Ausführung nicht autorisierter Aktionen |
| Agentenebene | Aufgabenplanung und Koordination | Prompt-Injection / Manipulation |
| Vernetzung | Kommunikation mit der Infrastruktur | Risiko lateraler Bewegungen |
| KI-Modelle | Interpretation von Befehlen und Umgebung | Ausnutzung von Modellen |
Risiken agentischer Robotik auf die OWASP LLM Top 10 abbilden
Wenn ein Roboter ein Sprach- oder Bildmodell verwendet, um Anweisungen, Umgebungsdaten oder Tool-Ausgaben zu interpretieren, werden mehrere Risiken aus den OWASP Top 10 für LLM-Anwendungen unmittelbar relevant.
Beispiele sind:
- LLM01: Prompt Injection — speziell erstellte Eingaben manipulieren das Modellverhalten
- LLM02: Unsichere Verarbeitung von Ausgaben — unsichere Verwendung von vom Modell erzeugten Ausgaben
- LLM08: Übermäßige Autonomie — Modellen wird ohne Leitplanken zu viel Autonomie gewährt
Diese Kategorien wurden ursprünglich für KI-Softwareanwendungen entwickelt, doch die Auswirkungen sind weitaus gravierender, wenn sich die „Anwendung“ durch den physischen Raum bewegen, Türen öffnen oder Geräte manipulieren kann.
Governance-Frameworks gelten weiterhin
Organisationen, die autonome Systeme einsetzen, sollten Robotikprogramme ebenfalls als KI-Governance-Initiativen behandeln.
Das NIST AI Risk Management Framework bietet eine praxisnahe Struktur zur Bewertung und Verwaltung dieser Risiken. Seine Kernfunktionen — Govern, Map, Measure und Manage — helfen Organisationen dabei, Richtlinien, technische Schutzmaßnahmen, Überwachung und kontinuierliche Verbesserung über den gesamten Lebenszyklus der KI hinweg zu integrieren.
Bei Robotikbereitstellungen hilft dieses Framework, Sicherheitspraktiken mit Sicherheits- und Betriebsaufsicht zu verknüpfen.
Cybervorfälle können zu Sicherheitsvorfällen werden
Im Gegensatz zu herkömmlichen Endpunkten bergen kompromittierte Roboter die Möglichkeit unmittelbarer physischer Folgen.
Ein manipulierter Roboter könnte potenziell:
- In gesperrte Bereiche eindringen oder Türen entriegeln
- Inventar oder Ausrüstung auf nicht autorisierte Weise bewegen
- Notausgänge blockieren oder Arbeitsabläufe stören
- Physische Vermögenswerte beschädigen
In Umgebungen wie Lagern, Fabriken und Logistikeinrichtungen könnten diese Aktionen schnell von einem Sicherheitsvorfall zu einem Sicherheitsereignis eskalieren.
Deshalb muss die Robotiksicherheit sowohl Cybersicherheits- als auch betriebliche Sicherheitspraktiken verbinden.
Grundlegende Sicherheitskontrollen für Robotikbereitstellungen
Sicherheitsteams, die Robotikbereitstellungen bewerten, sollten mehrere grundlegende Schutzmaßnahmen verlangen, bevor sie Roboter in Produktionsumgebungen zulassen.
Netzwerksegmentierung und ausschließlich interne Dienste
Roboter sollten in segmentierten Netzwerken mit streng kontrolliertem Ost-West-Verkehr betrieben werden. Ihre Agentendienste und Steuerungssysteme sollten auf interner Infrastruktur verbleiben, statt dem öffentlichen Internet ausgesetzt zu sein.
Dieser Ansatz folgt etablierten Best Practices für die Sicherheit von Operational Technology (OT), die darauf ausgelegt sind, laterale Bewegungen einzuschränken und externe Angriffsflächen zu reduzieren.
Starke Authentifizierung und Autorisierung für die Ausführung von Skills
Robotersysteme stellen häufig einzelne „Skills“ wie Navigation, Objektmanipulation oder die Interaktion mit der Umgebung bereit.
Das Auslösen dieser Skills sollte als Ausführung privilegierter Aktionen behandelt werden – mit Identitätskontrollen, Richtliniendurchsetzung und vollständiger Protokollierung.
Signierte Updates und Kontrollen der Software-Lieferkette
Moderne Roboter sind in hohem Maße softwaredefinierte Systeme. Updates für Autonomiestacks, Software-Lieferketten müssen strengen Vorgaben folgen, darunter signierte Artefakte, schrittweise Rollouts und Mechanismen zum Zurücksetzen.
Sicherheitsbeschränkungen auf Grundlage der Herstellerdokumentation
Einige Roboterhersteller warnen Nutzer ausdrücklich davor, aufgrund der Leistungsfähigkeit und Komplexität humanoider Maschinen bestimmte Sicherheitsabstände zu unterschreiten. Diese Warnungen sollten in formale Sicherheitskontrollen und Betriebsverfahren innerhalb der Bereitstellungen überführt werden.
Was in Sicherheitsanforderungen für Robotik enthalten sein sollte
Organisationen, die den Einsatz humanoider Roboter erwägen, sollten Sicherheitsanforderungen in die Beschaffungs- und Bereitstellungsplanung aufnehmen.
Zu den wichtigsten Anforderungen gehören:
- Klare Vertrauensgrenzen (On-Robot-, On-Premises- und Cloud-Komponenten)
- Vollständige Dokumentation von Ports und Protokollen
- Detaillierte Protokollierung von Befehlen, aufgerufenen Skills und Agentenaktionen
- Mechanismen zur Update-Validierung und zum Zurücksetzen
- Verfahren zur Reaktion auf Vorfälle einschließlich sicherem Herunterfahren und Isolierung
Fazit
Humanoide Roboter sollten nicht wie Gadgets bewertet werden – und auch nicht wie Laptops abgesichert werden.
Sie stellen eine neue Klasse cyberphysischer Endpunkte dar: OT-Geräte, die durch KI-Entscheidungsebenen erweitert werden.
Ihre Absicherung erfordert die Kombination traditioneller OT-Sicherheitspraktiken wie NIST SP 800-82 (Leitfaden zur OT-Sicherheit) und ISA/IEC 62443 mit modernen Ansätzen zur Modellierung von KI-Bedrohungen wie den OWASP LLM Top 10 sowie Governance-Frameworks wie dem NIST AI RMF.
Während Roboter von Demonstrationen in reale Bereitstellungen übergehen, werden Organisationen, die sie von Anfang an als kritische Infrastruktur behandeln, deutlich besser darauf vorbereitet sein, die von ihnen eingeführten Risiken zu bewältigen.
Diese Konvergenz von OT und Unternehmens-IT veranlasst Organisationen dazu, Zero-Trust-Lösungen einzusetzen, um neue Technologien und kritische Systeme besser abzusichern.