Artificial Intelligence
Neben der DSGVO und dem Bundesdatenschutzgesetz sind je nach Sektor weitere regulatorische Vorgaben relevant – etwa Anforderungen an die Verarbeitung weiterer schützenswerter oder eingestufter Daten oder die Einhaltung branchenspezifischer Compliance-Standards. In der Praxis bedeutet dies, eine klare Data-Governance zu etablieren, die bindende Regeln und Kontrollmechanismen festlegt, auf welche Daten das KI-System zugreifen darf und wie diese verarbeitet, gespeichert und weitergegeben werden dürfen. Diese Anforderungen sollten vor dem ersten Pilotprojekt geklärt sein, nicht danach.
KI-Governance schafft klare Verantwortlichkeiten, Prozesse und Kontrollmechanismen, um Risiken beim Einsatz von KI systematisch zu identifizieren, zu bewerten und zu begrenzen. Der EU AI Act bildet hierfür faktisch den regulatorischen Governance-Rahmen: Je höher das potenzielle Risiko eines KI-Systems für Sicherheit, Grundrechte oder Gesellschaft, desto umfassender sind die Anforderungen an Risikomanagement, Transparenz, menschliche Aufsicht und technische Absicherung. Governance übersetzt diese Anforderungen in konkrete Strukturen und Prozesse für den sicheren und regelkonformen KI-Einsatz. Eine frühzeitige Governance ist damit zwingend erforderlich und verhindert, dass vielversprechende KI-Projekte später an Compliance-Hürden scheitern.
KI-Systeme können über verschiedene Angriffsvektoren manipuliert werden, darunter Data-Poisoning, Adversarial-Attacks oder Supply-Chain-Angriffe. Bei generativer und insbesondere agentischer KI kommen Prompt-Injections hinzu, die direkt über Nutzereingaben oder indirekt über verarbeitete Inhalte wie Dokumente oder Webseiten eingeschleust werden können. Die Folgen reichen von manipuliertem Systemverhalten und dem Abfluss sensibler Informationen bis hin zu unerlaubten Aktionen über angebundene Tools und Systeme. Wirksamer Schutz erfordert daher eine durchgängige Absicherung über den gesamten Lebenszyklus – von sicheren Daten-, Modell- und Softwarepipelines über konsequente Zugriffskontrollen bis hin zu kontinuierlichem Monitoring und Sicherheitstests im Betrieb.
Der Einsatz von KI-Technologie in sicherheitskritischen Umgebungen erfordert mehr als ein leistungsfähiges Modell. Das Stichwort hierzu lautet: Vertrauenswürdige KI (engl. Trustworthy AI). In Abhängigkeit vom Anwendungsfall gehören dazu u. a. die Interpretierbarkeit und die Nachvollziehbarkeit von generierten Ergebnissen sowie Verarbeitungspipelines, welche sensible Daten inhärent schützen und bereits im Entwicklungsprozess berücksichtigt werden. Gleichermaßen sind Zuverlässigkeit und Robustheit zu nennen, welche mit steigendem Autonomiegrad der KI-Systeme entscheidend sind und die Voraussetzung für einen nachhaltigen Betrieb bei Verteidigung, öffentlichem Sektor und Betreibern Kritischer Infrastrukturen bilden.
Der Schlüssel liegt darin, Datenanalyse und Sicherheitsarchitektur zusammenzudenken: Durch den Einsatz von Privacy-Enhancing-Technologies (PETs) wie beispielsweise Anonymisierung oder Differential-Privacy lassen sich gezielt Rückschlüsse auf sensible Einzelinformationen reduzieren, ohne den analytischen Wert der Daten vollständig zu verlieren, während Federated-Learning es ermöglicht, schützenswerte Daten innerhalb ihrer jeweiligen Schutzdomäne auszuwerten und dennoch gemeinsam Erkenntnisse bzw. Modelle zu gewinnen. So lassen sich auch bislang schwer zugängliche Datenbestände für KI-Anwendungen erschließen, ohne Datensouveränität und Schutzanforderungen aufzugeben. Expertise aus dem Bereich Data-Science und Cybersecurity ist dabei unerlässlich.
Enterprise Architecture
Beide sind Rahmenwerke zur strukturierten Beschreibung sowie Erfassung bzw. Modellierung komplexer Gesamtsysteme über Fähigkeiten, Anwendungsfälle, Services und Ressourcen hinweg. NAF ist das NATO-weite Rahmenwerk und vor allem in multinationalen Vorhaben relevant, während das ADMBw die nationale Ausprägung für Vorhaben der Bundeswehr ist und deren spezifische Vorgaben sowie Leitfäden abbildet. In der Praxis bestimmt der Auftraggeber bzw. das Vorhaben, welches Rahmenwerk gilt; die Modellierung folgt dann konsistent dessen Sichten und Namens- sowie Modellierungskonventionen.
Eine konsistente Architektur macht Wechselwirkungen zwischen Fähigkeiten, Anwendungsfällen, Services und Ressourcen explizit. Dadurch lassen sich Anforderungen früh mit vorhandenen Fähigkeiten verknüpfen, Redundanzen vermeiden und Entscheidungen auf einer belastbaren Modellbasis treffen. Das verkürzt Abstimmungsschleifen und reduziert das Risiko teurer Fehlentscheidungen in späten Projektphasen – ein wesentlicher Hebel für einen beschleunigten Beschaffungsprozess.
Sicherheitsaspekte sind keine nachgelagerte Disziplin, sie werden in verschiedenen Sichten der Zielarchitektur berücksichtigt und modelliert. Eine durchdachte Enterprise IT Security beschreibt, wie Schutzbedarfe, Zugriffsmodelle und Sicherheitsdomänen über alle Ebenen hinweg konsistent verankert werden. So lassen sich Sicherheitsanforderungen systematisch mit Fähigkeiten, Anwendungsfällen, Services und Ressourcen verknüpfen, statt sie später aufzusetzen – das erhöht sowohl Resilienz als auch Nachvollziehbarkeit.
Sparx Enterprise Architect ist ein etabliertes Werkzeug, das die Modellierung nach ADMBw und NAF unterstützt und alle Elemente in einem zentralen, wiederverwendbaren Modellelementekatalog verwaltet. Eindeutige Benennung und gepflegte Attribute sorgen für Konsistenz über Modelle hinweg, ermöglichen Auswertungen sowie Filterung und vermeiden Redundanzen. Das Ergebnis ist eine nachvollziehbare, langfristig pflegbare Modellbasis.
Im Rahmen der Anforderungserhebung werden Ziele und Rahmenbedingungen mit dem Auftraggeber strukturiert abgestimmt und die Ausgangslage (bestehende Architekturen, Systeme, organisatorische Gegebenheiten) erfasst. Diese Anforderungen werden anschließend systematisch mit den modellierten Fähigkeiten, Anwendungsfällen, Services und Ressourcen in Beziehung gesetzt, sodass Abhängigkeiten und Lücken sichtbar werden.
Konsistenz entsteht durch verbindliche Namens- sowie Modellierungskonventionen, einen gepflegten Modellelementekatalog und die Orientierung an den gültigen Leitfäden (ADMBw/NAF). Werden Elemente zentral verwaltet und mit Attributen versehen, lassen sie sich projektübergreifend wiederverwenden und auswerten. Wichtig ist eine kontinuierliche Pflege – eine Architektur, die nicht aktuell gehalten wird, verliert schnell ihren Mehrwert.
Kritische Infrastrukturen
KRITIS-Betreiber müssen angemessene technische und organisatorische Maßnahmen zum Schutz ihrer kritischen Dienstleistung umsetzen, diese regelmäßig nachweisen und erhebliche Sicherheitsvorfälle melden. Mit NIS2 weitet sich der Kreis der betroffenen Unternehmen aus und die Anforderungen an Risikomanagement, Meldewege und Verantwortlichkeit der Leitungsebene steigen. Ein erster Schritt ist daher die Klärung, ob und in welchem Umfang ein Unternehmen überhaupt betroffen ist.
Beim KRITIS-Audit weisen Betreiber gegenüber der Aufsicht nach, dass ihre Sicherheitsmaßnahmen dem Stand der Technik entsprechen. Typischerweise umfasst das eine Prüfung der umgesetzten Maßnahmen, der Dokumentation und der Prozesse durch qualifizierte Prüfer, mündend in einen Nachweis mit etwaigen Mängeln und Fristen zur Behebung. Eine gute Vorbereitung – inklusive eines gepflegten ISMS – entscheidet maßgeblich über den Aufwand des Audits.
Krankenhäuser verbinden klassische IT mit Medizintechnik und sensiblen Patientendaten – bei gleichzeitig hoher Verfügbarkeitsanforderung. Neben den allgemeinen KRITIS-Pflichten greifen sektorspezifische Vorgaben für das Gesundheitswesen. In der Praxis bedeutet das: Schutz von Patientendaten, Absicherung vernetzter Medizingeräte und belastbare Notfallkonzepte, damit die Versorgung auch im Angriffsfall sichergestellt bleibt.
Ein praxistauglicher Umsetzungsplan für KRITIS beginnt mit der Betroffenheits- und Schutzbedarfsanalyse, gefolgt von einer Gap-Analyse gegen die gesetzlichen Anforderungen. Daraus werden priorisierte Maßnahmen mit Verantwortlichkeiten und Fristen abgeleitet und in einem ISMS verankert. Der Plan sollte realistische Etappen und Nachweispunkte enthalten, damit Fortschritt und Auditfähigkeit jederzeit belegbar sind.
Ein Informationssicherheitsmanagementsystem (ISMS) ist das organisatorische Rückgrat: Es bündelt Risikobewertung, Maßnahmen, Verantwortlichkeiten und Nachweise in einem gesteuerten, kontinuierlich verbesserten Prozess. Für KRITIS-Betreiber ist ein ISMS faktisch die Voraussetzung, um die geforderten Nachweise effizient zu erbringen – statt Einzelmaßnahmen führt es zu einer prüffähigen Gesamtstruktur. Das erklärt, warum ein KRITIS-ISMS so stark nachgefragt wird.
Incident Management für KRITIS umfasst klare Meldewege, definierte Rollen, vorbereitete Reaktionsabläufe und regelmäßige Übungen. Wichtig ist die Verzahnung mit den gesetzlichen Meldepflichten: Erhebliche Vorfälle müssen fristgerecht an die Aufsicht gemeldet werden. Ein eingespielter, getesteter Prozess entscheidet im Ernstfall darüber, ob ein Vorfall beherrschbar bleibt oder zur Krise eskaliert.
Pentesting
Ein Security Test prüft einen definierten Scope (z. B. eine Anwendung oder ein Netzsegment) systematisch auf Schwachstellen und liefert eine priorisierte Mängelliste. Red-Teaming geht weiter: Es simuliert einen realistischen Angriff über mehrere Wege hinweg – inklusive Social Engineering und physischer Zugänge – um zu prüfen, ob und wie ein Angreifer ein konkretes Ziel erreichen könnte. Security Testing beantwortet „Wo sind Lücken?“, Red-Teaming „Hält unsere Verteidigung einem echten Angriff stand?“.
Das BSI gibt einen strukturierten Rahmen vor: Zunächst werden Ziele, Scope und Testtiefe festgelegt und rechtlich abgesichert. Es folgen Informationsbeschaffung, aktive Tests der definierten Systeme und die Bewertung der gefundenen Schwachstellen nach Risiko. Den Abschluss bildet ein nachvollziehbarer Bericht mit konkreten, priorisierten Handlungsempfehlungen. Diese standardisierte Vorgehensweise macht Ergebnisse vergleichbar und auditfest.
In industriellen und kritischen Umgebungen steht die Verfügbarkeit an erster Stelle – ein klassischer, aggressiver Test kann Anlagen stören. Daher werden Tests eng abgestimmt: passive Analysen, Tests in Abbild- oder Wartungsumgebungen und sorgfältig dosierte aktive Prüfungen. Entscheidend sind OT-spezifisches Know-how und ein abgestimmter Zeitplan, damit Sicherheitsgewinn und Betriebssicherheit in Balance bleiben.
Application Security Testing prüft Anwendungen gezielt auf Schwachstellen – von Eingabevalidierung über Authentifizierung bis zu Schnittstellen. Es ist besonders dann nötig, wenn Anwendungen sensible Daten verarbeiten, extern erreichbar sind oder regelmäßig weiterentwickelt werden. Im Rahmen von Security Testing wird es idealerweise wiederkehrend in den Entwicklungs- und Releaseprozess integriert, statt nur einmalig vor dem Go-live.
Bei der Wahl eines Penetrationstest-Anbieters bzw. -Unternehmens zählen nachweisbare Qualifikationen der Tester, ein strukturiertes und dokumentiertes Vorgehen (idealerweise BSI-konform), Erfahrung in der jeweiligen Branche sowie ein verständlicher, handlungsorientierter Ergebnisbericht. Bei sicherheitskritischen Auftraggebern kommen sicherheitsüberprüftes Personal und entsprechende Geheimhaltungsfähigkeit hinzu.
Ein fester Rhythmus (z. B. jährlich) ist ein sinnvoller Mindeststandard, sollte aber durch anlassbezogene Tests ergänzt werden: nach wesentlichen Änderungen an Systemen, vor dem Go-live neuer Anwendungen oder bei veränderter Bedrohungslage. Sicherheit ist kein einmaliges Projekt – regelmäßige Tests stellen sicher, dass neue Schwachstellen früh erkannt werden.
Cloud-Tests berücksichtigen die geteilte Verantwortung zwischen Anbieter und Nutzer: Geprüft werden vor allem Konfiguration, Identitäts- und Zugriffsmanagement, Schnittstellen und die Absicherung der eigenen Workloads. Wichtig ist die Abstimmung mit dem Cloud-Anbieter und die Einhaltung von dessen Testrichtlinien, damit die Prüfung zulässig und aussagekräftig bleibt.
Requirements Engineering
Klassisches Requirements Engineering erhebt, spezifiziert und verwaltet alle Anforderungen an ein System. Security Requirements Engineering ist die sicherheitsbezogene Ausprägung davon und beschreibt, wie das System vor äußeren Bedrohungen geschützt werden kann: Es identifiziert Schutzbedarfe, leitet konkrete Sicherheitsanforderungen ab und stellt sicher, dass diese von Beginn an Teil der Spezifikation sind. Der Vorteil: Sicherheit wird nicht nachträglich „aufgesetzt“, sondern ist von der ersten Anforderung an nachvollziehbar verankert.
Indem Schutzbedarf und Bedrohungslage bereits in der Anforderungserhebung betrachtet werden – nicht erst in der Umsetzung. Dazu gehören die Einbindung der relevanten Vorgaben (regulatorisch und organisatorisch), die Analyse potenzieller Risiken, eine strukturierte Ableitung von Sicherheitsanforderungen und deren Verknüpfung mit den funktionalen Anforderungen. So entstehen Leistungsbeschreibungen, die Sicherheit von Anfang an mitdenken.
Ein IT-Sicherheitskonzept übersetzt die erhobenen Schutzbedarfe und Sicherheitsanforderungen in konkrete technische und organisatorische Maßnahmen. Aus klaren Anforderungen lassen sich Schutzziele, Maßnahmen und Nachweise nachvollziehbar ableiten und gegen die übergeordnete Architektur prüfen. Je präziser die Anforderungen, desto belastbarer und auditfester wird das resultierende Sicherheitskonzept.
Anforderungen müssen mit der Zielarchitektur in Einklang stehen, sonst entstehen Brüche zwischen Planung und Umsetzung. Requirements Engineering stellt sicher, dass Anforderungen klar definiert und mit den modellierten Fähigkeiten und Systemen der Enterprise Architecture verknüpft sind. So bleiben Einzelvorhaben anschlussfähig an das Gesamtbild – gerade in langlaufenden, komplexen Projekten.
Über durchgängige Dokumentation und Nachverfolgbarkeit (Traceability): Jede Anforderung wird von der Erhebung über Spezifikation und Leistungsbeschreibung bis zu Test und Betrieb verfolgt. Werkzeuggestützt – etwa mit etablierten Anforderungsmanagement-Tools – lässt sich jederzeit nachweisen, ob eine Anforderung umgesetzt und getestet wurde. Das ist die Grundlage für Abnahmen und für den Nachweis gegenüber Auftraggebern.
Strukturiertes (klassisches) Vorgehen passt zu stabil definierten, stark regulierten Vorhaben mit festen Abnahmekriterien. Agiles Requirements Engineering eignet sich, wenn Anforderungen sich iterativ schärfen. In regulierten Projekten ist oft eine Kombination sinnvoll: ein stabiler Rahmen aus verbindlichen Anforderungen, regulatorischen Vorgaben und Dokumentation, innerhalb dessen einzelne Bestandteile iterativ verfeinert werden.
Security Gateway
Eine Datendiode erlaubt den Datenfluss physikalisch nur in eine Richtung und eignet sich, wenn Informationen ausschließlich von einer Domäne in eine andere fließen dürfen (z. B. aus einem hochsicheren Netz heraus). Ein Security Gateway hingegen ermöglicht einen kontrollierten, regelbasierten – auch bidirektionalen – Datenaustausch zwischen Netzen unterschiedlicher Schutzbedarfe, inklusive inhaltlicher Prüfung und Filterung. Die Wahl hängt davon ab, ob Sie nur eine Richtung absichern oder einen geprüften beidseitigen Austausch benötigen.
Entscheidend ist die formale Zulassung durch die zuständigen Stellen (z. B. BSI national, NATO bzw. EU für internationale Einstufungen). SDoT-Produkte sind für den Einsatz in hochklassifizierten Umgebungen entwickelt und entsprechend zugelassen. Welche konkrete Einstufung (z. B. bis NATO SECRET) abgedeckt ist, hängt vom jeweiligen Produkt und der aktuellen Zulassung ab – diese sollten Sie projektbezogen bestätigen lassen, da Zulassungen turnusmäßig erneuert werden.
Ein Security Gateway prüft den Datenverkehr regelbasiert auf Protokoll- und Inhaltsebene, bevor er eine Domänengrenze passiert. Über Labelling (Kennzeichnung von Daten nach Schutzbedarf) und definierte Filterregeln wird sichergestellt, dass nur freigegebene Informationen in der korrekten Richtung übertragen werden. So lässt sich ein kontrollierter Austausch realisieren, ohne die Trennung der Sicherheitsdomänen aufzugeben.
Zentrale Kriterien sind die formale Zulassung für den benötigten Geheimhaltungsgrad, die Herkunft und Vertrauenswürdigkeit des Herstellers (Stichwort digitale Souveränität, „made in Germany“), die Integrierbarkeit in bestehende Architekturen sowie nachgewiesene Referenzen in vergleichbaren Umgebungen. Ebenso wichtig sind Durchsatz und Latenz, damit die Sicherheitsfunktion den operativen Betrieb nicht ausbremst.
Security by Design heißt, dass Sicherheitsanforderungen von der ersten Entwurfsentscheidung an Teil der Produktarchitektur sind und nicht nachträglich ergänzt werden. „Made in Germany“ adressiert die digitale Souveränität: Entwicklung und Fertigung in Deutschland reduzieren Abhängigkeiten von ausländischen Lieferketten und erleichtern Zulassungen für besonders schützenswerte Einsatzbereiche in Verteidigung und Kritischen Infrastrukturen.
SDoT-Komponenten sind darauf ausgelegt, als Teil einer größeren Sicherheitsarchitektur zu funktionieren – etwa im Zusammenspiel mit Datendioden, der Secure Network Card oder Lösungen zur Datenverteilung. Die Integration orientiert sich an den vorhandenen Netzdomänen und Schutzbedarfen; in Vergleichsszenarien (z. B. für militärische Einrichtungen) werden Durchsatz, Zulassung und Betriebsmodell gegen die konkreten Anforderungen abgewogen.
Gerade in operativen und missionskritischen Szenarien muss die Sicherheitsprüfung mit hoher Geschwindigkeit bei niedriger Latenz erfolgen, damit Anwendungen nicht spürbar verzögert werden. Bei der Produktauswahl sollten die benötigte Bandbreite, die Art der Daten (z. B. Streaming vs. Dokumente) und die maximal tolerierbare Latenz definiert und gegen die Leistungswerte der Lösung geprüft werden.