Die Meldungen der vergangenen 48 Stunden haben einen gemeinsamen Kern: Angegriffen werden nicht mehr nur einzelne Endgeräte, sondern zunehmend die Systeme, die andere Systeme steuern. Öffentlich erreichbare speicherprogrammierbare Steuerungen beeinflussen Wasseranlagen, ein kompromittierter TeamCity-Server kann Softwareartefakte und nachgelagerte Pipelines verändern, und eine offen erreichbare MCP Bridge kann KI-Agenten samt Shell-, Datenbank- und Speicherzugriff kontrollieren. Solche Komponenten wirken als Multiplikatoren. Management- und Steuerungsebenen müssen deshalb in eigenständigen Vertrauenszonen betrieben, mit kurzlebigen Identitäten abgesichert und lückenlos protokolliert werden. Entscheidend ist nicht nur, ob ein Angreifer eindringen kann, sondern wie viele kritische Funktionen von diesem Ausgangspunkt aus erreichbar sind.

Das Ende der deutschen Übergangsphase für die NIS-2-Registrierung macht eine erhebliche Umsetzungslücke sichtbar. Noch wichtiger ist jedoch, was hinter dieser formalen Lücke liegt: Eine Organisation, die ihre Betroffenheit, Rechtseinheiten und Meldekontakte nicht sicher bestimmen kann, hat häufig auch Schwierigkeiten mit Asset-Inventar, Risikobewertung und Incident-Eskalation. Die Registrierung muss daher mit dem operativen Sicherheitsmodell verbunden werden. Unternehmen müssen wissen,welche Dienste wesentlich sind, welche Lieferanten und Systeme diese tragen,welche Ereignisse die gesetzlichen Meldeschwellen erreichen und wer innerhalb weniger Stunden Entscheidungen treffen darf. Eine Portalregistrierung ohne belastbare Prozesse schützt weder den Betrieb noch die verantwortlichen Leitungsorgane.

Das neue Secure-by-Design-and-Default-Playbook der ENISA ,aktualisierte Mindestanforderungen für Software Bills of Materials und mehrere aktuelle Schwachstellen in industriellen Protokollkomponenten zeigen, wie sich Secure by Design praktisch konkretisiert. Gefordert sind keine abstrakten Bekenntnisse, sondern nachvollziehbare Tätigkeiten: Komponenten identifizieren, Abhängigkeiten versionieren, sichere Voreinstellungen wählen, Missbrauchsfälle testen und Schwachstellen über den gesamten Produktlebenszyklus behandeln. Mit den ab 11. September 2026 einsetzenden Meldepflichten des Cyber Resilience Act wird dieser Prozess zusätzlich zeitkritisch. Ohne Produktinventar, SBOM, eindeutige Zuständigkeiten und reproduzierbare Builds lassen sich aktiv ausgenutzte Schwachstellen kaum fristgerecht bewerten und melden. Secure by Design wird damit zugleich Architektur-, Rechts- und Kostenrechnungsthema.

Für Finanzunternehmen wachsen bislang getrennt behandelte Risikofelder zusammen. Die BaFin richtet ihre Aufsicht stärker auf KI-Anwendungen aus, eine Schwachstelle in Azure Cosmos DB illustriert die Abhängigkeit von zentralen Cloud-Diensten, und die geplante Übernahme von Permiso durch Okta zeigt, wie menschliche, technische und agentische Identitäten in einer gemeinsamen Laufzeitüberwachung zusammengeführt werden. DORA liefert dafür den organisatorischen Rahmen: ICT-Risiken, Drittparteien, Resilienztests und Sicherheitsvorfälle müssen in einem konsistenten Governance-Modell zusammenlaufen. Praktisch reicht es nicht, einen Cloud-Vertrag, ein KI-Register und ein IAM-System getrennt zu pflegen. Entscheidend ist die durchgängige Abhängigkeit: Welches Modell greift mit welcher Identität über welchen Dienst auf welche Daten zu – und wie kann dieser Zugriff kontrolliert beendet werden?

Splunk und Check Point positionieren sich an unterschiedlichen Übergängen derselben KI-Architektur. Splunk betont einen portablen Kontext aus Daten, Workflows, Richtlinien und Entscheidungshistorien; Check Point verlagert die Überwachung von Prompts, Modellaufrufen undAgentenaktionen in die Netzwerkebene. Beide Ansätze adressieren ein reales Problem: Unternehmen können KI nicht wirksam kontrollieren, wenn Modelle, Identitäten, Daten und Werkzeuge jeweils in getrennten Sicherheitsdomänen liegen. Gleichzeitig entsteht ein neues Konzentrationsrisiko. Wer Kontext,Telemetrie und Policy Enforcement in einer Plattform bündelt, vereinfacht zwar Governance, macht sich aber stärker von deren Datenmodell, Lizenzierung und Integrationen abhängig. Beschaffungsentscheidungen sollten daher Exportfähigkeit, offene Schnittstellen, unabhängige Protokolle und praktikable Wechselverfahren ausdrücklich berücksichtigen.

Die Vorfälle bei britischen Behörden, KT, Analog Devices sowie bei KI-Sicherheitstests zeigen schließlich, dass ein Incident nichts auber in technische, rechtliche und kommunikative Phasen zerfällt. Bereits während der Eindämmung müssen Organisationen klären, welche Daten betroffen sind, welche Meldefristen laufen und ob öffentliche Aussagen forensisch belastbar sind. Bei agentischen KI-Systemen kommt hinzu, dass das System selbstständig handeln, reale Ziele erreichen und Spuren über mehrere Dienstleister verteilen kann. Belastbare Incident Response verbindet deshalb unveränderbare Telemetrie, juristische Entscheidungsbäume, Kommunikationsfreigaben und Wiederanlaufverfahren von Beginn an. Erfolg bemisst sich nicht allein daran, einen Angreifer zu entfernen, sondern daran, wie schnell belastbare Entscheidungen getroffen, kritische Dienste stabilisiert und Betroffene geschützt werden.

Quellen

Weiterlesen