Sicherheit neu gedacht: Warum Österreich ein KI-gestütztes Supervisory Tool braucht

Regulierung ohne Wirkung?

Die EU-Datenschutzgrundverordnung (DSGVO) und die neue NIS2-Richtlinie sollen eigentlich ein hohes Maß an Datenschutz und Cybersicherheit garantieren. In der Praxis kämpfen jedoch sowohl Unternehmen als auch Behörden mit der effizienten Umsetzung dieser Vorgaben. Fünf Jahre nach Geltung der DSGVO haben noch immer nur rund 20 % der Unternehmen die Vorschriften vollständig umgesetztlto.de – ein ernüchternder Wert. Bei der Cybersicherheits-Richtlinie NIS2 deutet sich ein ähnliches Bild an: Nur etwa 29 % der betroffenen deutschen Unternehmen fühlten sich Ende 2024 bereits vollständig konformap-verlag.de. Österreich hinkt bei der Umsetzung der NIS2 sogar hinterher und sah sich Ende 2024 mit einem EU-Vertragsverletzungsverfahren konfrontiertpit.at. Diese Diskrepanz zwischen politischem Anspruch und Realität wirft eine kritische Frage auf: Woran scheitern die aktuellen Prüfprozesse und Regulierungsansätze – und wie können wir es besser machen?

In diesem Fachartikel beleuchten wir die politischen, regulatorischen und wirtschaftlichen Probleme herkömmlicher Compliance-Prüfprozesse. Wir analysieren, warum die Umsetzung von DSGVO und NIS2 bisher unzureichend geblieben ist, und skizzieren eine zukunftsweisende Lösung: Ein staatlich betriebenes, lokal laufendes KI-gestütztes Analyse- und Bewertungstool („Supervisory Tool“) für die Sicherheit von Unternehmen. Dieses Tool soll sämtliche Sicherheitsdaten – von Dokumentationen über technische Scan-Ergebnisse bis hin zu Reifegradbewertungen – zusammenführen, vor Ort verarbeiten und mittels Künstlicher Intelligenz (insbesondere Large Language Models, LLMs) auswerten. Wir zeigen auf, welche Rollen zentrale Behörden in Österreich (Innenministerium, Bundeskanzleramt, CERT.at, Datenschutzbehörde, Bundesrechenzentrum u.a.) bei Entwicklung und Einsatz eines solchen Tools spielen sollten. Zudem erläutern wir die technische Machbarkeit: von modularer Architektur über erklärbare KI und strukturierte Score-Modelle bis zur sicheren Protokollierung aller Analyseschritte. Schließlich machen wir konkrete Handlungsempfehlungen und appellieren an die politischen Entscheidungsträger, jetzt mutige Schritte zu setzen – im Interesse der Sicherheit, aber auch als Chance für technologische Innovation und wirtschaftliche Wertschöpfung in Österreich und der EU.

Probleme aktueller Prüfprozesse: Politisch, regulatorisch, wirtschaftlich

Die derzeitigen Prozesse zur Prüfung und Zertifizierung von Informationssicherheit (etwa Audits nach ISO 27001 oder behördliche Kontrollen gemäß NIS-Richtlinie) stoßen an vielfältige Grenzen. Aus politischer und regulatorischer Sicht fehlen häufig einheitliche Leitlinien und wirksame Durchsetzung, während auf wirtschaftlicher Ebene hohe Kosten und personelle Engpässe die Umsetzung belasten.

Politische und regulatorische Defizite

Eine der größten Hürden ist die Uneinheitlichkeit und Unsicherheit der Vorgaben. Unternehmen beklagen, dass die Vorschriften oft unklar und in jedem EU-Land unterschiedlich ausgelegt sindlto.de. So führte bereits die erste NIS-Richtlinie zu divergierenden Ansätzen in den Mitgliedstaaten – ein Defizit, das NIS2 eigentlich beheben sollnis.gv.at. Doch noch immer wird die Richtlinie national unterschiedlich umgesetzt; international tätige Firmen stehen dadurch vor zusätzlichem Aufwand und komplexen Mehrfachanforderungenpit.atpit.at. Auch die DSGVO brachte eine anhaltende Rechtsunsicherheit: Fast drei Viertel (74 %) der Firmen nannten unklare Regeln und ständige Anpassungen als größte Herausforderunglto.de. Zudem fehlt es an praktischer Unterstützung durch die Aufsichtsbehörden – 59 % der Unternehmen bemängelten unzureichende Umsetzungshilfen seitens der Behördenlto.de. In Österreich etwa veröffentlichte die Datenschutzbehörde zwar Leitfäden, konnte aber aufgrund begrenzter Ressourcen nur wenige proaktive Prüfungen durchführen. Die Folge: Viele Verantwortliche fühlen sich bei der Compliance allein gelassen und agieren zögerlich, was die politischen Ziele der Regulierung unterläuft.

Hinzu kommt, dass Transparenz und Konsistenz bei der Aufsicht fehlen. Sowohl beim Datenschutz als auch bei der Cybersicherheit gibt es in der EU kein zentrales, kontinuierliches Monitoring: Überprüfungen erfolgen punktuell (z.B. anlassbezogen oder im Rahmen einer Zertifizierung) und die Ergebnisse werden selten geteilt. Behörden haben dadurch keinen laufenden Überblick über den Sicherheitsstatus der Unternehmen im Land – ein Problem, das bei der wachsenden Bedrohungslage politisch brisant ist. NIS2 verpflichtet die Mitgliedstaaten zwar zu Aufsichts- und Durchsetzungspflichtennis.gv.at, doch ohne digitale Hilfsmittel drohen die Behörden von der Datenflut überrollt zu werden, sobald tausende Meldungen und Berichte eingehen. Die europäische Wertpapieraufsicht ESMA warnte analog im Finanzbereich: Nur ein digitalisierter, datengetriebener Aufsichtsprozess ermöglicht es den Regulatoren, die bald eintreffende Datenmenge zu bewältigenesma.europa.eu. Übertragen auf Cybersecurity bedeutet das: Ohne Automatisierung werden Innenministerien und zuständige Stellen Schwierigkeiten haben, die Einhaltung der NIS2-Vorgaben flächendeckend sicherzustellen.

Wirtschaftliche Hürden und praktische Probleme

Für Unternehmen – insbesondere mittelständische und erstmals regulierte – sind die Compliance-Anforderungen mit erheblichem Aufwand und Kosten verbunden. Mittlere Unternehmen haben laut einer Analyse der European Cyber Security Organisation oft nicht die personellen und finanziellen Ressourcen, um NIS2 umzusetzenpit.at. 75 % der Firmen hatten 2023 kein Budget für die NIS2-Implementierung vorgesehenpit.at, viele unterschätzten den Aufwand völlig. Ähnliches gilt für die DSGVO: Noch 2019 gaben über ein Viertel der Firmen (26 %) an, es fehle ihnen an Fachpersonal für Datenschutzlto.de. Dieser Fachkräftemangel in IT-Sicherheit und Compliance verschärft sich weiter – 41 % der NIS2-pflichtigen Unternehmen sehen den Mangel an qualifizierten IT-Experten als größte Herausforderungap-verlag.de. Externe Beratungen und Audit-Dienstleistungen (z.B. ISO 27001-Zertifizierungen) sind kostspielig, was sich viele kleinere Unternehmen kaum leisten können. Dadurch entsteht ein Ungleichgewicht: Große Konzerne stemmen die Zertifizierungskosten, während KMU oftmals ungeschützt bleiben oder erst nach einem Sicherheitsvorfall Aufmerksamkeit erhalten.

Aktuelle Prüfprozesse sind zudem zeitaufwendig und wenig dynamisch. Typischerweise werden Sicherheits-Audits jährlich oder alle paar Jahre durchgeführt – ein Rhythmus, der in der heutigen Bedrohungslandschaft viel zu langsam ist. Risiken ändern sich in Monaten oder Wochen, doch ein Audit-Zertifikat gilt dann oft trotz veralteter Lageeinschätzung. Unternehmen neigen dazu, für den Audit-Termin zu „polieren“, anstatt kontinuierlich ihre Sicherheitsmaßnahmen zu verbessern. Nach bestandenem Audit verfällt die Aufmerksamkeit häufig wieder. Diese Momentaufnahme-Mentalität verhindert einen nachhaltigen Sicherheitszyklus.

Auch die Dokumentationsflut ist ein praktisches Problem: Für ISO 27001 oder interne Compliance müssen unzählige Richtlinien, Protokolle, Risk-Assessments und technische Reports erstellt und gepflegt werden. Viele Betriebe ersticken in Word-Dokumenten und Excel-Listen, ohne daraus echten Sicherheitsmehrwert zu ziehen. Prüfende Stellen wiederum müssen sich durch Aktenordner oder PDF-Berichte wühlen – eine mühsame Tätigkeit, die fehleranfällig ist und wichtiges Detailwissen übersehen kann. Kurz: Der manuelle Charakter der bisherigen Prüfverfahren ist der Komplexität moderner IT-Umgebungen nicht mehr gewachsenalgomox.comalgomox.com. Es braucht Automatisierung, um die Menge und Vielfalt der Sicherheitsdaten zuverlässig zu bewältigen.

Nicht zuletzt entstehen volkswirtschaftliche Schäden durch unzureichende Sicherheit: Cyberangriffe haben in Europa stark zugenommenap-verlag.de. Drei von vier Unternehmen in einer Umfrage erlitten in den vergangenen 12 Monaten einen Cyberangriffap-verlag.de. Jeder erfolgreiche Angriff – ob Datendiebstahl, Ransomware oder IT-Ausfall – kostet die Wirtschaft beträchtliche Summen und untergräbt das Vertrauen in die Digitalisierung. Wenn Compliance-Aufwand und mangelnde Unterstützung dazu führen, dass viele Firmen nur das Nötigste tun oder resignieren, ist die Konsequenz ein höheres Gesamtrisiko. Die aktuellen Prozesse schaffen also weder aus politischer Sicht ein befriedigendes Schutzniveau, noch bieten sie Unternehmen einen praktikablen, effizienten Weg zur Sicherheit. Ein Umdenken drängt sich auf.

DSGVO und NIS2 – Große Ziele, magere Bilanz

Die Diskrepanz zwischen den ambitionierten Regelwerken und der Realität in den Organisationen könnte größer kaum sein. Warum sind DSGVO und NIS2 bisher gescheitert oder unzureichend? Ein genauerer Blick auf beide Fälle zeigt strukturelle Probleme und Lernchancen.

Lehren aus fünf Jahren DSGVO

Als die DSGVO 2018 in Kraft trat, war die Hoffnung groß: Endlich ein einheitlicher Datenschutzstandard in Europa, der Bürgerrechte stärkt und für klare Spielregeln sorgt. Heute müssen wir ernüchtert feststellen, dass die Umsetzung vielfach unvollständig blieb. Zwei Jahre nach Geltung der Verordnung hatten lediglich 20 % der deutschen Firmen die DSGVO vollständig umgesetztlto.de. Fast 90 % gaben gar an, die DSGVO sei in der Praxis nicht vollständig umsetzbarlto.de. In Österreich dürfte die Quote ähnlich aussehen – zu viele Unternehmen verharren bei halbgaren Lösungen.

Woran liegt das? Ein Faktor ist sicherlich die anhaltende Rechtsunsicherheit: Drei von vier Firmen klagten über unklare oder uneinheitliche Auslegung der DSGVO-Regelnlto.de. Unterschiedliche Schwerpunkte der nationalen Datenschutzbehörden führten dazu, dass etwa in manchen Ländern strenger gegen Cookie-Banner vorgegangen wurde, während anderswo Fokus auf internationalen Datenfluss (Stichwort Privacy Shield/Schrems II) lag. Die Unternehmen fühlten sich dadurch verunsichert und investierten eher in juristische Gutachten als in praxisnahe Datenschutzmaßnahmen.

Hinzu kam die unzureichende Unterstützung: Die Aufsichtsbehörden – oft selbst personell dünn besetzt – konnten den enormen Beratungsbedarf kaum decken. 59 % der Unternehmen bemängelten fehlende Umsetzungshilfenlto.de. In der Praxis äußerte sich das z.B. in spät kommenden Leitlinien des Europäischen Datenschutzausschusses oder darin, dass Muster für Verarbeitungsverzeichnisse und Folgenabschätzungen vielfach erst nach dem Stichtag zur Verfügung standen. Gerade KMU hätten jedoch klare, einfache Tools gebraucht, um die DSGVO-Anforderungen umzusetzen. Stattdessen sahen sie sich einem „Fass ohne Boden“ gegenüberlto.de: Immer neue Nachbesserungen und Forderungen der Behörden ließen den Eindruck entstehen, Compliance sei ein endloses, kaum zu gewinnendes Spiel.

Auch bei der Durchsetzung gibt es Schwächen: Zwar wurden europaweit teils empfindliche Bußgelder gegen Großkonzerne verhängt, doch flächendeckende Prüfungen blieben die Ausnahme. Kleine und mittlere Betriebe fühlten sich selten kontrolliert und wähnten sich dadurch in falscher Sicherheit – bis ein Datenschutzvorfall eintrat. Die DSGVO kennt zwar das Instrument der Datenschutz-Folgenabschätzung und verlangt „geeignete technische und organisatorische Maßnahmen“ (Art. 32 DSGVO), aber es fehlte ein Mechanismus, diese präventiv zu evaluieren. Hier wäre eine engere Verzahnung mit der IT-Sicherheit sinnvoll gewesen: Viele Datenschutzverletzungen sind letztlich Folge unzureichender Security (Datenlecks, Hacks etc.). Doch Datenschutz- und IT-Sicherheitsaudits liefen bisher getrennt ab. Genau diese Lücke könnte ein integriertes Tool schließen, das Sicherheitsbewertungen liefert und damit auch die DSGVO-Vorgaben (Vertraulichkeit, Integrität) untermauert.

NIS2: Anspruchsvolle Richtlinie, zögerliche Umsetzung

Die NIS2-Richtlinie, seit Jänner 2023 in Kraft, soll aus den Lehren der Vorgängerin (NIS1) schöpfen und deutlich mehr Unternehmen zu besseren Cybermaßnahmen verpflichtennis.gv.atnis.gv.at. Das Spektrum der erfassten Branchen wurde erweitert und durch die Size-Cap-Regel fallen auch mittlere Unternehmen in kritischen Sektoren unter die Regelungnis.gv.at. Doch gerade diese Breitenwirkung stellt die Umsetzung vor Herausforderungen: Viele Betriebe wissen noch gar nicht, dass sie bald NIS2-pflichtig sind, oder haben erst spät davon erfahren. In Österreich ist die erforderliche nationale Gesetzesanpassung (das neue NIS-Gesetz) Ende 2024 immer noch nicht verabschiedet gewesenpit.at. Die Folge war Rechtsunsicherheit – und einige Unternehmen nutzten dies als Vorwand, erst einmal abzuwarten. Dabei läuft die Zeit: Eine Übergangsfrist sieht NIS2 nicht vorpit.at, sodass nach Nachholung der Umsetzung sofort Pflichten wirksam werden.

Erste Erhebungen zeigen, dass zwei Drittel der betroffenen Unternehmen noch nicht am Ziel sindap-verlag.de. Nur 29 % hatten die geforderten Sicherheitsmaßnahmen Ende 2024 vollständig umgesetzt, weitere 32 % teilweiseap-verlag.de. Besonders schwach zeigte sich der Bereich Vorfall- und Krisenmanagement: 22 % der Firmen hatten noch gar keine Mechanismen zur Erkennung und Meldung von Sicherheitsvorfällen etabliertap-verlag.de – und das, obwohl gerade hier schnelle Reaktionsfähigkeit essenziell ist. Mehr als die Hälfte der Unternehmen zweifelte, die Anforderungen bis Mitte Oktober 2024 erfüllen zu könnenap-verlag.de. Diese Zahlen sind alarmierend, denn sie bedeuten, dass viele Organisationen Stand heute nicht ausreichend auf Cyberangriffe vorbereitet sind, obwohl die Bedrohungslage es dringend erfordert.

Warum stockt die NIS2-Umsetzung? Ein Hauptgrund ist wiederum der Mangel an Ressourcen und Know-how. 41 % der Unternehmen nennen den Fachkräftemangel als größte Hürdeap-verlag.de. Qualifizierte Security-Experten sind rar und teuer. Ohne sie aber lassen sich z.B. Risikomanagement-Prozesse oder die technischen Sicherheitsmaßnahmen kaum aufbauen. Eng damit verknüpft ist der fehlende Rückhalt im Management: In 34 % der Unternehmen fehlt eine aktive Einbindung der Geschäftsleitung bei NIS2pit.at – obwohl die Richtlinie genau diese Managementverantwortung ausdrücklich vorschreibt. Cybersecurity wird also in vielen Chefetagen weiterhin als rein technische Angelegenheit abgetan, anstatt als Chefsache begriffen. Dieses kulturelle Problem erschwert Investitionen und strategische Maßnahmen.

Des Weiteren kämpfen besonders neu in den Regulierungsrahmen einbezogene Firmen mit hohen Initialkosten. Wer zum ersten Mal eine strukturierte Sicherheitsorganisation aufbauen muss, sieht sich vor einem Berg an Investitionen – von Security-Infrastruktur (Endpoint Protection, Monitoring-Systeme) über externe Beratungsleistungen bis hin zu Schulungen für Mitarbeiter. Diese finanzielle Belastung empfinden viele Mittelständler als erheblichpit.atpit.at. Dennoch ist sie unumgänglich, um das geforderte Schutzniveau zu erreichen. In einer Umfrage planten daher 84 % der betroffenen Unternehmen, ihr IT-Sicherheitsbudget zu erhöhen (im Schnitt +10 %)ap-verlag.de. Das zeigt: Die Bereitschaft ist da, aber es fehlt oft an Orientierung, wo am effektivsten investiert werden soll.

Insgesamt droht NIS2 in der Praxis sein Ziel zu verfehlen, wenn nicht gegengesteuert wird. Mehr Vorschriften allein verbessern die Sicherheit nicht – sie können im Gegenteil Unternehmen überfordern, wenn keine pragmatischen Umsetzungswerkzeuge bereitstehen. Es braucht also einen neuen Ansatz, der sowohl die Regulierer entlastet als auch die Unternehmen befähigt, die Anforderungen effizient und sinnvoll zu erfüllen. Hier setzt die Idee eines KI-gestützten Supervisory Tools an.

Ein neuer Ansatz: KI-gestütztes Supervisory Tool für Sicherheitsbewertungen

Statt auf reine Papier-Compliance und sporadische Audits zu setzen, sollten Behörden und Unternehmen die Möglichkeiten moderner Technologie nutzen. Die Vision ist ein staatlich angebotenes Software-Tool, das vor Ort beim Unternehmen alle relevanten Sicherheitsinformationen einsammelt und automatisiert auswertet. Dieses „Supervisory Tool“ (Aufsichtswerkzeug) wäre eine Art digitaler Prüfhelfer, der kontinuierlich den Sicherheitsstatus eines Unternehmens bewertet – unter Einsatz von Künstlicher Intelligenz (KI), um die Komplexität zu meistern.

Wichtig ist: Das Tool läuft lokal beim Unternehmen oder in einer souveränen nationalen Infrastruktur und nicht in einer fremden Cloud. So bleiben sensible Daten – von Netzplänen über Schwachstellenberichte bis zu internen Policies – unter der Kontrolle des Unternehmens (und im Rechtsraum der EU). Die staatliche Stelle stellt die Software bereit, aktualisiert sie regelmäßig (z.B. neue Bedrohungsindikatoren, veränderte Regulierungspunkte) und wertet die Ergebnisse in aggregierter Form aus, ohne einzelne Firmengeheimnisse einsehen zu müssen. Dieses Modell vereint Datenschutz und Sicherheit: Die Analyse findet direkt am Datenursprung statt, wodurch keine vertraulichen Informationen an Dritte abfließen – ein zentraler Aspekt gerade mit Blick auf die DSGVO-Konformität des Tools selbst.

Was das Tool analysiert und wie es arbeitet

Das Supervisory Tool soll alle Sicherheits-relevanten Datenquellen integrieren, um ein ganzheitliches Bild zu erzeugen. Dazu gehören unter anderem:

• Organisatorische Dokumentation: Sicherheitsrichtlinien, Prozessbeschreibungen (z.B. Incident-Response-Pläne), Rollen- und Berechtigungskonzepte, Risikoanalysen nach ISO 27001, Berichte früherer Audits etc. Diese oftmals in Prosa verfassten Dokumente kann ein KI-Modell (LLM) einlesen und mit den Soll-Vorgaben abgleichen – z.B. prüfen, ob ein Incident-Response-Plan alle geforderten Elemente enthält.
• Technische Scan-Daten: Ergebnisse von Schwachstellen-Scans (Netzwerk- und Application-Scanner), Penetrationstests, Konfigurationsprüfungen (z.B. Sicherheitsbaseline-Checks auf Servern) und ggf. Security-Monitoring-Logs. Solche Daten liefert in der Regel bereits ein bestehendes Toolset (z.B. Nessus-Reports, SIEM-Alerts). Das Supervisory Tool sammelt diese Outputs ein, normalisiert sie und bewertet den technischen Sicherheitsstatus (z.B. Anzahl kritischer ungepatchter Schwachstellen, Backup-Status, Anomalien in Logs).
• Maturity-Self-Assessments: Fragebögen oder Reifegrad-Modelle, mit denen das Unternehmen den Umsetzungsstand bestimmter Controls einschätzt (ähnlich einem internen Audit-Fragebogen). Das Tool könnte solche Selbsteinschätzungen aufnehmen, aber auch mittels KI gegenprüfen, ob sie plausibel sind – etwa indem es Widersprüche zwischen hoch angegebenem Reifegrad und festgestellten Befunden aus den Scans/Dokumenten erkennt.
• Branchen- und Bedrohungsinformationen: Hier kommt insbesondere CERT.at ins Spiel (dazu später mehr). Das Tool könnte aktuelle Warnungen zu spezifischen Schwachstellen, branchenspezifische Bedrohungsszenarien oder Mindeststandards (z.B. vom BSI in Deutschland oder ENISA in der EU) einspielen. So ließe sich die Unternehmenssituation im Kontext betrachten: Ist eine gerade akute Schwachstelle (z.B. Log4Shell) vorhanden? Entspricht die Passwort-Policy dem Stand der Technik? Solche Fragen könnte das System anhand hinterlegter Regelwerke und Threat Intelligence beantworten.

Mithilfe eines Large Language Models (LLM) oder vergleichbarer KI lässt sich die Vielfalt dieser Inputs intelligent auswerten. Ein LLM kann beispielsweise die Textdokumente „verstehen“ und in Relation zu den Anforderungen setzen: Findet es im ISMS-Handbuch des Unternehmens Hinweise auf ein Business Continuity Management, wie es NIS2 fordert? Werden in der Risikoanalyse alle kritischen Assets erfasst? Gleichzeitig kann die KI die technischen Daten interpretieren: Zum Beispiel Beschreibungen von Schwachstellen mit den getroffenen Gegenmaßnahmen abgleichen, um das Restrisiko einzuschätzen. Generative KI hat hier enorme Vorteile, da sie Muster in unstrukturierten Daten erkennen und Zusammenhänge herstellen kann, die ein rein regelbasiertes Tool schwer erfassen würdealgomox.comalgomox.com.

Am Ende der Analyse steht eine Bewertung mit einem strukturierten Score sowie einem ausführlichen Befundbericht. Dieser Bericht sollte alle wesentlichen Aspekte abdecken – analog zu einem Audit-Report, aber kontinuierlich aktualisierbar. Denkbar ist z.B. ein Secure Score in Prozent, ähnlich dem Ansatz von Microsoft Secure Score (der als Maß für die Sicherheitslage in Office-365-Umgebungen dient)learn.microsoft.com, nur umfassender. Ein hoher Prozentsatz würde anzeigen, dass das Unternehmen die meisten empfohlenen Maßnahmen umgesetzt hat, ein niedriger Score entlarvt Handlungsbedarf. Wichtig dabei: Der Score wird in Teilbereiche gegliedert, etwa Governance (Policies, Management-Engagement), technische Schutzmaßnahmen (Patch-Management, Netzsicherheit), Detektion & Response (Monitoring, Notfallübungen) etc. So können Unternehmen gezielt sehen, wo ihre Schwächen liegen.

Neben der nackten Zahl liefert das Tool erklärende Texte und Empfehlungen. Hier spielt die KI ihre Stärke aus: Sie kann zu jedem identifizierten Mangel eine kurze Beschreibung generieren, warum dies relevant ist und wie es behoben werden könnte – basierend auf Best Practices und dem gesetzlichen Rahmen. Beispielsweise: „Es existiert kein dokumentierter Prozess für regelmäßige Backup-Tests. Dies gefährdet die Wiederherstellungsfähigkeit (vgl. Art. 11 NIS2, Anhang I). Wir empfehlen, vierteljährliche Notfallwiederherstellungsübungen durchzuführen und die Ergebnisse in einem Protokoll festzuhalten.“ Solche konkreten Hinweise gehen über heutige Auditberichte oft hinaus, die Mängel zwar listen, aber selten detaillierte Umsetzungsratschläge geben.

Das Supervisory Tool wäre damit Prüfer und Berater in einem – es bewertet nicht nur, sondern unterstützt die Unternehmen aktiv bei der Verbesserung. Idealerweise lernt das System auch aus der Praxis: Wenn etwa ein empfohlener Maßnahmenkatalog besonders gut funktioniert (gemessen an später verbesserten Scores oder reduzierten Vorfällen), kann die KI diese Empfehlung verfeinern und zukünftig verstärkt ausspielen.

Vorteile für Unternehmen und Aufsicht

Die Einführung eines solchen Tools würde die bisherigen Schwächen der Prüfprozesse gezielt adressieren:

• Kontinuierliche statt punktuelle Prüfung: Unternehmen könnten das Tool jederzeit – etwa quartalsweise oder vor wichtigen Änderungen – laufen lassen und erhalten unmittelbares Feedback. Sicherheitsniveau wird so zu einer kontinuierlichen Kenngröße (KPI) im Unternehmen, nicht zu einem jährlichen Ritual.
• Ressourceneffizienz und Kostenersparnis: Ein großer Teil des manuellen Prüfaufwands wird automatisiert. Unternehmen sparen Beraterkosten und internen Aufwand, da das Tool die Dokumentendurchsicht und Erstbewertung übernimmt. Auditteams können ihre knappe Zeit auf die Nachprüfung kritischer Punkte und die Umsetzung von Verbesserungen fokussieren.
• Verbesserte Genauigkeit und Objektivität: KI-Auswertungen können weniger voreingenommen sein als menschliche Prüfer und übersehen seltener etwas, da sie rund um die Uhr große Datenmengen verarbeiten können. Jedes Detail aus einem 100-seitigen Sicherheitskonzept kann einbezogen werden. Zudem sorgt ein zentrales Tool für einheitliche Maßstäbe: Alle Unternehmen werden nach dem gleichen Kriterienkatalog beurteilt, was die Vergleichbarkeit erhöht.
• Schnelle Warnungen bei Risiken: Falls z.B. ein Scan kritische Schwachstellen findet oder das Fehlen einer essentiellen Maßnahme (z.B. kein Intrusion Detection bei einem Netzbetreiber), kann das Tool sofort Alarm schlagen – noch bevor ein echter Angreifer die Lücke ausnutzt. Im Idealfall koppelt man es mit CERT.at, sodass beim Auftauchen bestimmter Findings automatisch Meldung an das nationale CERT geht (ggf. anonymisiert oder in vorher vereinbarter Form), um sofort Unterstützung zu leisten.
• Synergie zwischen Datenschutz und Security: Ein integratives Tool kann auch DSGVO-Aspekte mit bewerten. So hat Frankreichs ANSSI kürzlich in seinem Tool „MonServiceSécurisé“ DSGVO-Compliance-Maßnahmen integriertcnil.frcnil.fr. Ähnlich könnte unser Supervisory Tool z.B. prüfen, ob Verarbeitungsregister geführt werden oder Datenminimierung praktiziert wird – und dies in die Bewertung einfließen lassen. Die CNIL und ANSSI zeigten damit erfolgreich, dass Datenschutz und IT-Sicherheit gemeinsam überprüft werden können, was zu einer ganzheitlichen Compliance führtcnil.fr. Ein österreichisches Tool könnte hier Maßstäbe setzen, indem es sowohl NIS2 als auch DSGVO-relevante Security-Anforderungen (Art. 32 DSGVO) abdeckt.

Kurzum: Ein KI-gestütztes Supervisory Tool verspricht, die Lücke zwischen Regelsetzung und Umsetzung zu schließen. Es macht aus toten Buchstaben (Gesetze, Standards) lebendige, greifbare Hinweise für die Praxis – und liefert Behörden zugleich ein Instrument, um ihre Aufsicht effizienter und datenbasierter auszuüben.

Architektur und Funktion: Modularität, erklärbare KI, Score-Modelle, Protokollierung

Damit ein derartiges Tool Akzeptanz findet, muss es technisch durchdacht und vertrauenswürdig sein. Im Folgenden skizzieren wir die Grundprinzipien der Architektur und Funktionsweise.

Schematische Darstellung eines staatlichen, lokal laufenden Supervisory Tools für Cybersicherheit. Unternehmensdaten werden vor Ort per KI analysiert; Behörden liefern Rahmenwerke und erhalten bedarfsweise Ergebnisse.

Modulare Architektur und lokale Ausführung

Das Tool sollte modular aufgebaut sein, um flexibel erweiterbar und anpassbar zu bleiben. Geplante Module könnten sein:

• Datenaufnahme-Modul: Schnittstellen zu gängigen Datenquellen. Etwa Import von PDF/DOCX-Dokumenten (Policies etc.), APIs/Connectoren zu Security-Tools (Vulnerability Scanner, SIEM), Eingabemasken für manuelle Selbstauskünfte. Dieses Modul sorgt für Normalisierung und Vorverarbeitung (z.B. Textaufbereitung, Entfernen von Duplikaten, Zuordnung zu Themenbereichen).
• Analyse-Engine (KI-Modul): Hier arbeitet das Herzstück – ein KI-Modell, kombiniert mit regelbasierten Checks. Das Modul könnte zweigeteilt sein: (a) Knowledge Base & Regeln – ein maschinenlesbarer Katalog der Anforderungen (z.B. Controls der ISO 27001, Vorgaben aus NIS2, Best Practices wie CIS Controls). Diese werden als „Prüfregeln“ hinterlegt, ähnlich einer Checkliste, aber formalisiert. (b) LLM-Komponente – ein vortrainiertes Sprachmodell, spezialisiert auf Sicherheitsdomäne, das die unstrukturierten Eingaben interpretieren kann. Es wird mit den Regeln verknüpft, d.h. die KI versucht zu jedem Control die relevanten Informationen aus den Daten zu extrahieren und abzuleiten, ob das Control erfüllt, teilweise erfüllt oder nicht erfüllt ist. Die LLM-Komponente kann dabei in natürlicher Sprache formulierte Evidenz in strukturierte Bewertungen umwandeln.
• Scoring- und Bewertungsmodul: Auf Basis der Analyse-Engine werden Punkte vergeben. Hier fließt ein konfigurierbares Score-Modell ein: Beispielsweise könnte jedes Control der ISO 27001 einen bestimmten Gewichtungsfaktor bekommen. Das Modul berechnet pro Bereich (Governance, Technik, Prozesse etc.) Teilscores und aggregiert sie zu einem Gesamtscore. Die Strukturierung nach Score-Modell ist wichtig, um die Nachvollziehbarkeit zu gewährleisten – sie bildet quasi das Bewertungsgerüst, an dem sich die KI-Ergebnisse ausrichten.
• Erklärungs- und Reporting-Modul: Dieses Modul generiert die Ausgabe für den Benutzer. Es übersetzt die KI-Befunde in erklärbare Berichte. Hier können Templates eingesetzt werden: Zum Beispiel ein Berichtsteil „Physische Sicherheit“: Das Template erwartet Angaben zu Türsicherungen, Alarmanlagen etc., und die KI füllt anhand der Datenlage aus, ob diese vorhanden sind oder nicht. Wichtig: Explainable AI bedeutet, dass für jede Bewertung eine Begründung oder Referenz angegeben wird. Im Bericht könnte das so aussehen: „Control 5.1: Sicherheitsrichtlinie – erfüllt. Begründung: Das Dokument ‚Sicherheitskonzept 2024‘ enthält eine vom Management freigegebene Sicherheitsrichtlinie (Abschnitt 1.2)lto.de.“ Idealerweise verweist das Tool auf die Quelle im gelieferten Input, sodass ein Prüfer oder das Unternehmen die Aussage nachvollziehen kann. Die KI muss also nicht nur Ja/Nein ausgeben, sondern Textbausteine mit Evidenz generieren. Dies erhöht das Vertrauen enorm, da Entscheidungen transparent werden.
• Protokollierungs- und Audit-Trail-Modul: Jede Analyse, jede Änderung an den Daten und jede Empfehlung wird hier revisionssicher protokolliert. Um die Integrität zu gewährleisten, kann mit kryptographischen Verfahren gearbeitet werden – z.B. jede Ergebnisausgabe wird digital signiert, sodass nachträgliche Manipulation erkennbar ist. Dieser Audit-Trail dient mehreren Zwecken: Das Unternehmen kann nachweisen, wann es was geprüft hat (wichtig im Falle von Aufsichtsgesprächen oder nach einem Sicherheitsvorfall). Die Behörde kann stichprobenartig die Protokolle einsehen, um Missbrauch (z.B. Manipulation der Inputdaten vor dem Lauf) zu erkennen. Und im Entwicklungsprozess des Tools dient das Logging auch zur Erklärbarkeit der KI: Man könnte interne Entscheidungswege der KI (sofern extrahierbar) oder zumindest die Input-Stellen, die zu einem Urteil führten, mitprotokollieren.

Essentiell ist zudem die Trennung von sensiblen Daten und zentralen Komponenten. Lokal laufend heißt: Die heavy-lifting-Analyse durch KI passiert innerhalb der Infrastruktur des Unternehmens. Denkbar wäre, dass das Bundesrechenzentrum (BRZ) ein Virtual Appliance Package bereitstellt – z.B. eine vorkonfigurierte VM oder Container, die das Unternehmen on-premises installiert. Darin laufen die oben genannten Module, ggf. mit beschränkter Netzwerkanbindung nur für Updates. Die KI-Modelle selbst könnten ebenfalls lokal gehalten werden (etwa ein feinjustiertes Open-Source-LLM, das offline betrieben wird). Sollte aus Performance-Gründen doch eine stärkere Recheninstanz nötig sein, müsste diese zumindest in einem staatlichen Rechenzentrum in Österreich betrieben werden und die Daten dorthin verschlüsselt übertragen werden. Allerdings ist angesichts heutiger Fortschritte auch On-Prem-KI realistisch – aktuelle LLMs können, falls nötig, auf unternehmensinternen Servern oder spezialisierten Appliances laufen, ohne Cloud-Zwang.

Die Modularität ermöglicht zudem, das Tool schrittweise auszubauen. Man könnte z.B. in einer ersten Version den Fokus auf NIS2-Kernanforderungen legen (Incident-Handling, Basismaßnahmen laut Anhang der Richtlinie). Weitere Module könnten dann ISO 27001 umfassen, später vielleicht branchenspezifische Standards (z.B. für Energie, Gesundheit) oder auch internationale Rahmen wie NIST Cybersecurity Framework. Durch eine Plugin-Architektur könnte Drittfirmen oder Forschungsinstituten ermöglicht werden, zusätzliche Analyse-Plugins beizusteuern. Das erhält die Innovationsfähigkeit – ein starrer Monolith wäre demgegenüber schnell veraltet.

Erklärbare KI und strukturierte Score-Modelle

Wie bereits angedeutet, ist Erklärbarkeit ein zentrales Akzeptanzkriterium. Weder die Unternehmen noch die Behörden würden einem rein „magischen“ KI-Urteil vertrauen, wenn nicht klar ist, wie es zustande kam. Daher muss das System so gestaltet sein, dass die KI-Ausgaben immer auf nachvollziehbare Weise mit den Eingangsdaten verknüpft sind. Technisch kann man dies durch Retrieval-Augmented Generation umsetzen: Das LLM bekommt bei jeder Frage (z.B. „Wie ist der Umsetzungsgrad von Control XY?“) die relevanten Datenauszüge aus Dokumenten/Logs mitgeliefert und zitiert diese in seiner Antwort. Dadurch hat man automatisch Referenzen.

Zugleich benötigt man ein strenges Score- und Regelmodell als Leitplanke der KI. Das verhindert Willkür und sorgt für Konsistenz. Beispielsweise kann festgelegt sein: „Wenn in der Dokumentation keine formale Sicherheitsrichtlinie gefunden wird, gebe 0 Punkte für Governance-Teilbereich ‚Policy Management‘.“ Solche Regeln können im System hinterlegt werden und die KI-Erkenntnisse werden daran gespiegelt. Die KI mag ausführen „Kein Hinweis auf vorhandene Richtlinie gefunden“ – das Regelwerk zieht daraus die Konsequenz für den Score. Dieses Zusammenwirken von festem Modell und KI-Freiheiten entspricht dem Prinzip der teil-automatisierten Auditierung: Routinechecks streng formal, komplexe Bewertungen durch KI, und am Ende ein standardisiertes Bewertungsschema.

International gibt es dazu bereits Vorbilder: Der Secure Score in Microsofts Cloud-Produkten etwa aggregiert diverse Security-Maßnahmen in einen einzigen Prozentsatz und liefert damit ein leicht verständliches Gesamtbildlearn.microsoft.com. Ähnlich hat ANSSI mit „MonServiceSécurisé“ einen Score eingeführt, der Sicherheits- und Datenschutzmaßnahmen kombiniertcnil.fr. NIST verwendet in seinem Cybersecurity Framework keine Prozentwerte, aber Einstufungen (Tiers) und Reifegrade, die letztlich ebenfalls quantifizieren, wie weit eine Organisation ist. Unser vorgeschlagenes Tool kann auf diesen Erfahrungen aufbauen. Insbesondere sollte es klar zwischen Mindestanforderungen und Best Practices unterscheiden: NIS2 verlangt bestimmte Maßnahmen zwingend – ihr Fehlen würde z.B. automatisch zu einem „non-compliant“ Status führen. Darüber hinaus kann es aber noch freiwillige Maßnahmen geben, die den Score weiter steigern (z.B. Einsatz von KI-basierter Threat Detection, was über das Mindestmaß hinausgeht). So wird das Tool Anreizsystem und nicht nur Erfüllungskontrolle: Wer mehr tut als vorgeschrieben, sieht das positiv im Score.

Eine Herausforderung bleibt: Kann KI irren oder täuschen? Natürlich – keine Automatik wird 100 % perfekt sein. Daher sollte das Tool idealerweise einen Experten-Review-Modus haben: Ein Auditor (z.B. vom Regulator oder ein externer Revisor) kann sich die Inputs und KI-Outputs anzeigen lassen und manuell adjustieren. Wenn die KI etwa einen Passus falsch versteht, kann der Prüfer eingreifen und korrigieren. Diese Korrektur fließt dann ins Protokoll ein und könnte wiederum zum Training der KI genutzt werden, um künftig solche Missinterpretationen zu vermeiden. Somit bleibt der Mensch im Loop, vor allem bei strittigen Fällen – das erhöht das Vertrauen der Behörden in die Ergebnisse.

Sichere Protokollierung und Datenschutz by Design

Die Vertrauenswürdigkeit des Tools hängt nicht zuletzt davon ab, wie es mit sensiblen Daten umgeht und wie manipulationssicher es ist. Hier kommen Prinzipien aus der IT-Sicherheit selbst zur Anwendung:

• Logging und Versionierung: Jedes Mal, wenn das Unternehmen das Tool ausführt, erzeugt es ein Ergebnis, das intern versioniert und gespeichert wird. So kann man im Zeitverlauf Verbesserungen oder Verschlechterungen nachvollziehen. Veränderungen an relevanten Einstellungen (z.B. Score-Model-Gewichtung, Kriterienkatalog) werden mit historisiert. Falls eine Behörde also prüfen will, ob ein Unternehmen eventuell „Ergebniskosmetik“ betreibt (z.B. vor einer angekündigten Prüfung plötzlich das Tool manipuliert einsetzt), kann ein Blick in die Logs Klarheit schaffen. Optimal wäre ein WORM-Speicher (Write Once, Read Many) für Logs, um Löschung/Änderung praktisch auszuschließen.
• Signaturen und Prüfwerte: Das Tool könnte am Ende jeder Analyse einen kryptographischen Hash-Wert des Berichts und der wichtigsten Rohdaten erzeugen. Dieser „Prüfwert“ kann ans Aufsichtsorgan übermittelt werden (ohne den Bericht selbst preiszugeben). Im Falle einer Überprüfung könnte das Unternehmen dann den Originalbericht vorzeigen, und die Behörde vergleicht den Hash, um sicher zu sein, dass es der unveränderte Output ist. So lässt sich Integrität und Echtheit der Ergebnisse gewährleisten.
• Zugriffsschutz und Rollen: Intern muss das Unternehmen definieren, wer das Tool bedienen und die Ergebnisse sehen darf. Es handelt sich um hochsensible Informationen (z.B. genaue Schwachstellen). Ein Missbrauchszenario wäre, dass Angreifer oder illoyale Mitarbeiter Einblick in diese Reports erhalten. Daher sollte das Tool in die bestehende Access-Control des Unternehmens eingebunden werden (z.B. Authentifizierung via Unternehmens-SSO, rollenbasiert). Möglicherweise gibt es auch Daten, die nicht einmal die Geschäftsführung ungefiltert sehen sollte, weil zu technisch – hier könnte man auch Abstraktionsstufen anbieten (Management-Dashboard vs. Detailreport).
• Datenschutz und Datensparsamkeit: Das Tool muss DSGVO-konform designt sein. Das heißt, es verarbeitet zwar personenbezogene Daten (z.B. wenn Logfiles Personennamen enthalten oder Dokumente Mitarbeiterinfos), aber nur im Auftrag und unter Kontrolle des Unternehmens selbst – es erfolgt keine Weiterleitung an Dritte außer vereinbart (Behörde bekommt Ergebnisse nur in dem Umfang, der gesetzlich notwendig ist). Die Datenschutzbehörde (DSB) sollte hier früh eingebunden werden, um sicherzustellen, dass etwaige rechtliche Grauzonen (z.B. dürfen Betriebsräteinspektionen automatisiert ausgewertet werden?) geklärt sind. Privacy by Design kann etwa bedeuten, dass standardmäßig alle Personennamen in den Inputdaten vom Tool anonymisiert werden, sofern sie für die Sicherheitsbewertung nicht relevant sind. So würde das System gar nicht mehr persönliche Daten als nötig verarbeiten.

Mit all diesen technischen Vorkehrungen soll erreicht werden, dass das Supervisory Tool selbst kein Sicherheits- oder Datenschutzhazard darstellt, sondern im Gegenteil Vertrauen schafft. Es wäre paradox, eine Sicherheitsbewertungssoftware zu haben, die Angriffsfläche bietet – daher muss deren Entwicklung nach höchsten Standards erfolgen (Stichwort: Security Development Lifecycle, Pentests des Tools etc., idealerweise begleitet von CERT.at und externen Experten).

Zusammengefasst liefert eine solche Architektur die nötige Robustheit und Flexibilität: Modularer Aufbau erlaubt Anpassungen, erklärbare KI und Score-Modelle schaffen Transparenz, und Protokollierung sorgt für Verantwortlichkeit. Nun stellt sich die Frage: Wer soll all das umsetzen und betreiben? Hier kommen die österreichischen Behörden und Institutionen ins Spiel, deren Rollen wir im nächsten Abschnitt betrachten.

Rollen der Behörden: Gemeinsam zum Erfolg

Ein staatliches Supervisory Tool kann nur in enger Zusammenarbeit verschiedener Akteure gelingen. In Österreich gibt es mehrere Behörden und Einrichtungen, die jeweils Teilkompetenzen und gesetzliche Zuständigkeiten mitbringen. Ein solches Projekt erfordert interdisziplinäre Kooperation – von Cybersicherheitsexperten über Juristen bis hin zu IT-Architekten. Im Folgenden wird skizziert, welche Rolle die wichtigsten Stellen übernehmen sollten:

Bundesministerium für Inneres (BMI)

Das Innenministerium ist federführend für die innere Sicherheit – und damit auch für die nationale Cybersicherheitsstrategie. Im Kontext der NIS-Richtlinie ist zu erwarten, dass das BMI (bzw. ein untergeordnetes Amt) die Funktion der zuständigen nationalen Behörde für bestimmte Sektoren wahrnimmtnis.gv.at. Das BMI sollte bei diesem Projekt die Federführung auf Regierungsseite übernehmen. Konkret bedeutet das: Koordination zwischen den Ministerien, Einbindung der Länder (etwa wenn kritische Infrastruktur auf Landesebene betroffen ist) und Bereitstellung von Ressourcen. Politisch müsste das BMI den Stellenwert der Idee klar kommunizieren – idealerweise verankert man in der nationalen Cybersicherheitsstrategie das Ziel, Aufsicht durch solche technischen Lösungen zu verbessern. Zudem hat das Innenministerium (etwa über das Cybercrime-Competence-Center) auch Einblick in aktuelle Bedrohungen und könnte Anforderungen definieren, welche Funktionalitäten prioritäre Bedeutung haben (z.B. Fokus auf Ransomware-Schutz, weil das eine der größten Gefahren ist). Nicht zuletzt obliegt dem BMI die Kommunikation mit der EU-Kommission im Rahmen der NIS2-Umsetzung – hier kann es das Projekt als Best Practice einbringen und eventuell EU-Kofinanzierung anregen.

Bundeskanzleramt (BKA)

Das Bundeskanzleramt, insbesondere die Sektion für Digitalisierung und E-Government, sollte die politische Schirmherrschaft und strategische Steuerung beisteuern. Viele Fragen rund um DSGVO, Digitalisierungsförderung und Verwaltungsmodernisierung fallen in den Einflussbereich des BKA. Diese Stelle kann sicherstellen, dass das Supervisory Tool auf höchster Ebene unterstützt wird – bis hin zum Bundeskanzler, der das Thema als Chefsache behandeln könnte. Das BKA sollte zudem auf die EU-weite Perspektive achten: Wenn Österreich hier vorangeht, ließen sich durch koordinierte Initiativen auf EU-Ebene Synergien erzielen. Beispielsweise könnte man das Projekt im Rahmen des EU-Programms „Digital Europe“ oder ähnlicher Förderinstrumente präsentieren, um Mittel und Know-how aus anderen Ländern einzubinden. Im BKA läuft auch die Koordination der österreichischen Digitalisierungsagentur (DIA) und der Plattform Digitales Österreich – diese könnten helfen, das Tool als Teil der digitalen Verwaltungsoffensive zu etablieren. Eine mögliche Aufgabe wäre etwa, das Tool in Zukunft nicht nur Unternehmen, sondern auch öffentlichen Institutionen zur Verfügung zu stellen, um die Sicherheit im Behördenbereich selbst zu prüfen. Hier hat das BKA Hebel, das projektübergreifend zu denken (Stichwort: GovCERT und GovSys-Sicherheit).

CERT.at (Computer Emergency Response Team Austria)

CERT.at ist Österreichs nationales Computer-Notfallteam und verfügt über exzellentes technisches Know-how zu aktuellen Cyberbedrohungen. Im Projekt sollte CERT.at die technische Expertise und inhaltliche Pflege der Sicherheitsaspekte liefern. Konkret könnte CERT.at:

• Threat Intelligence Feeds bereitstellen, die ins Tool einfließen. Z.B. Informationen über neue Schwachstellen, Exploits in Umlauf, sektor-spezifische Warnungen. Diese können als ständige Updates die Wissensbasis des Tools anreichern.
• Mitarbeit bei Modul-Entwicklung: Insbesondere bei den technischen Scoring-Modulen (Netzwerksicherheit, Systemsicherheit) kann CERT.at mitgestalten, welche Prüfungen sinnvoll sind. Auch bei der Entwicklung von Playbooks für Empfehlungen (z.B. was zu tun ist, wenn Schwachstelle X entdeckt wird) kann die Erfahrung des CERT maßgeblich helfen.
• Unterstützung im Ernstfall: Wenn das Tool bei einem Unternehmen eine gravierende Sicherheitslücke identifiziert (etwa offene kritische Ports in einem Stromnetzsteuerungssystem) und das Unternehmen überfordert ist, könnte CERT.at auf dem kurzen Dienstweg Hilfestellung leisten oder einen Incident Response veranlassen. Durch die Kopplung ans Tool (wenn das Unternehmen einverstanden ist) ließen sich solche Fälle rasch kommunizieren. Das erhöht unmittelbar die Sicherheit – das Tool wäre nicht nur Prüfer, sondern Auslöser schneller Reaktionen.
• Training und Awareness: CERT.at könnte Schulungen für Firmen anbieten, wie sie mit dem Tool arbeiten, wie sie Befunde interpretieren und Maßnahmen umsetzen. Eventuell können Lessons Learned aus Incidents anonymisiert ins Tool rückfließen (z.B. häufige Fehler, die zu Vorfällen führten, als spezielle Checkpunkte im Kriterienkatalog).

Zusammenfassend wäre CERT.at der technische Content-Partner des Tools, um es stets auf dem neuesten Stand der Bedrohungslage zu halten und qualitativ hochwertige Analysen sicherzustellen.

Datenschutzbehörde (DSB)

Die DSB hat primär die Aufgabe, die Einhaltung der DSGVO zu überwachen, doch Sicherheit und Datenschutz überschneiden sich – beides sind essenzielle Säulen für vertrauenswürdige digitale Prozesse. Die DSB sollte von Anfang an in die Konzeption des Supervisory Tools eingebunden werden, um datenschutzrechtliche Leitplanken zu setzen. Ihre Rolle umfasst:

• Privacy by Design sicherstellen: Die DSB prüft das technische Konzept dahingehend, dass keine unnötigen personenbezogenen Daten verarbeitet werden. Sie könnte empfehlen, welche Datenkategorien gefiltert oder pseudonymisiert werden sollen. So wird gewährleistet, dass das Tool selbst nicht zum „Datenstaubsauger“ wird, den es nachher zu beaufsichtigen gilt.
• Integration von DSGVO-Checks: Wie erwähnt, kann das Tool gleich auch Grundanforderungen der DSGVO prüfen (z.B. Vorhandensein eines Datenschutzkonzepts, technisch-organisatorische Maßnahmen gem. Art. 32 DSGVO). Die DSB kann hierzu einen Katalog definieren, der dann als Modul ins Tool eingeht. So werden z.B. die oben aus Frankreich genannten sechs Prioritätsmaßnahmen (Verarbeitungsverzeichnis, Datenminimierung etc.)cnil.fr ebenfalls abgedeckt. Die DSB würde damit einen aktiven Beitrag zur Tool-Policy leisten.
• Nutzung der Ergebnisse für Datenschutz-Aufsicht: Möglicherweise könnte die DSB in Zukunft bei ihren Kontrollen – die oft auch Sicherheitsaspekte betreffen – auf das Tool zurückgreifen. Wenn ein Unternehmen freiwillig seine Tool-Reports bereitstellt, ließe sich ein Datenschutzaudit beschleunigen. So wird Doppelarbeit vermieden: Schließlich überschneiden sich z.B. die Anforderungen an Zugangskontrollen, Verschlüsselung, Backup in DSGVO und NIS2.
• Vermittlerrolle zu Unternehmen: Als Aufsichtsstelle hat die DSB viel Erfahrung, wie Unternehmen auf Regularien reagieren. Diese Erfahrung sollte genutzt werden, um die Akzeptanz des Tools zu fördern. Die DSB könnte z.B. eine wohlwollende Empfehlung aussprechen, dieses Tool zu nutzen, um Art. 32 DSGVO („Stand der Technik“) nachweisbar umzusetzen. Das würde vielen Verantwortlichen die Angst nehmen, im Nebel zu stochern, und ein positives Signal senden, dass proaktive Sicherheitsprüfungen auch von Datenschutzseite honoriert werden.

Kurz gesagt, die DSB bringt die Bürgerrechte und Datenschutzperspektive in das Projekt ein. So wird aus dem reinen Security-Tool ein integriertes Compliance-Werkzeug, das den europäischen ganzheitlichen Schutzgedanken widerspiegelt.

Bundesrechenzentrum (BRZ)

Das BRZ als IT-Dienstleister des Bundes prädestiniert sich, die operative Umsetzung und den Betrieb der Plattform zu schultern. Seine Aufgaben wären:

• Softwareentwicklung und -beschaffung: Je nach Ansatz entwickelt das BRZ das Tool inhouse (ggf. gemeinsam mit Partnern aus Wissenschaft oder Industrie) oder beschafft Module extern. Es muss ein agiles Projektteam aufgestellt werden, das die Anforderungen der Fachstakeholder (BMI, CERT, DSB, etc.) aufnimmt und technisch umsetzt. Das BRZ hat Erfahrung mit sensiblen Regierungsprojekten und könnte sicherstellen, dass das Tool robust, sicher und interoperabel mit bestehender Infrastruktur ist.
• Betrieb und Updates: Das BRZ könnte eine zentrale Update- und Vertriebsplattform einrichten. Beispielsweise ein Portal, über das Unternehmen die aktuelle Version der Tool-Appliance herunterladen oder Updates einspielen können. Denkbar ist auch ein zentrales Management für bestimmte Komponenten – etwa wenn eine KI-Modellaktualisierung ansteht, könnte das vom BRZ zentral ausgerollt werden (soweit das mit der lokalen Datenhoheit vereinbar ist). Eventuell betreibt das BRZ auch eine sichere Cloud-Instanz des Tools für jene Unternehmen, die keine eigene Infrastruktur wollen – natürlich nur unter strengen Auflagen und in österreichischen Rechenzentren.
• Support und Beratung: Als Betreiber stünde das BRZ auch für den 2nd-Level-Support zur Verfügung. Unternehmen könnten sich bei technischen Problemen oder Fragen zur Bedienung an eine vom BRZ bereitgestellte Hotline wenden. In Kooperation mit CERT.at könnte ein umfassender Support entstehen, der sowohl technische als auch inhaltliche Fragen abdeckt.
• Schnittstelle zu E-Government: Das BRZ kann überlegen, wie die Ergebnisse ggf. in Verwaltungsprozesse einfließen. Beispiel: Bei der Meldung eines Sicherheitsvorfalls nach NIS2 könnte das Unternehmen optional seinen letzten Sicherheitsscore mitschicken. Oder bei Förderprogrammen (z.B. Förderung von Security-Initiativen in KMU) könnte ein vorher/nachher-Vergleich via Tool-Report als Erfolgsmessung dienen. Hier hat das BRZ Überblick und könnte solche Integrationen ermöglichen.

Weitere Akteure und ihre Einbindung

Neben den genannten Hauptakteuren sollte man auch Wirtschaft und Forschung nicht vergessen. Branchenverbände (wie die Wirtschaftskammer, Verband der Industriellen) könnten in Pilotphasen das Tool testen und Feedback aus Unternehmenssicht geben. Die akademische Forschung – etwa die TU Wien, Fachbereiche für IT-Security und AI – könnte beratend hinzukommen, insbesondere um die KI-Aspekte zu verfeinern (Stichwort: Explainable AI, formale Modellierung von Security Controls). Auch Standardisierungsinstitutionen (ASI in Österreich oder Kooperation mit ENISA) wären wünschenswert, um Kompatibilität mit internationalen Normen sicherzustellen.

Die Erfahrung lehrt: Cybersicherheit ist Teamarbeit. Nur wenn alle relevanten Stellen zusammenspielen, kann ein so ambitioniertes Vorhaben wie ein nationales Supervisory Tool gelingen. Österreich hat hier die Chance, als Musterbeispiel für Europa voranzugehen – mit einem Schulterschluss von Politik, Verwaltung, Technik und Wissenschaft.

Von der Vision zum Produkt: Chancen für Innovation und Wirtschaft

Ein staatlich initiiertes Supervisory Tool wäre nicht nur ein Mittel zur Gefahrenabwehr und Compliance-Steigerung, sondern auch eine Innovation mit Marktpotential. Gerade für Österreich – mit seiner lebendigen IT-Szene, vielen Security-Startups und einem Fokus auf digitale Souveränität – eröffnet sich hier eine doppelte Chance: die heimische Cybersicherheit zu stärken und zugleich ein zukunftsträchtiges Produkt zu entwickeln, das über die Landesgrenzen hinaus Erfolg haben kann.

Europäische Digital-Souveränität stärken

Derzeit dominieren bei Compliance- und Security-Tools oft außereuropäische Anbieter den Markt. Beispielsweise im Bereich Datenschutz-Management oder GRC (Governance, Risk, Compliance) sind US-Firmen wie OneTrust, Microsoft (mit Secure Score und Compliance Center) oder AuditBoard tonangebend3rdrisk.com3rdrisk.com. Diese Lösungen sind meist cloudbasiert, was bei sensiblen Daten aus hiesiger Sicht datenschutzrechtlich problematisch sein kann (Stichwort Schrems II und Datenübermittlung in die USAlto.de). Ein in Österreich bzw. Europa entwickeltes Tool, das lokal betrieben wird, bietet einen klaren Vorteil: Die Daten verbleiben im europäischen Rechtsraum, und Unternehmen müssen keine aufwändigen Zusatzvereinbarungen (Standardvertragsklauseln etc.) treffen, um das Tool zu nutzen. Dies senkt die Hemmschwelle für viele, so ein Werkzeug überhaupt einzusetzen.

Zudem würde ein Erfolg in Österreich sicherlich Beachtung in der EU finden. Möglicherweise könnten andere Länder die Lösung adaptieren – was wiederum Effizienz bringt, weil man gemeinsame Standards in der Sicherheitsprüfung etabliert. Denkbar wäre langfristig ein europäisches Gütesiegel oder Benchmarking: Wenn viele EU-Länder ähnliche Tools nutzen, könnten Unternehmen grenzüberschreitend ihre Sicherheitslevels vergleichbar machen. Dies käme besonders den multinationalen Unternehmen zugute, die bislang unter uneinheitlichen Anforderungen leidenpit.atpit.at. Österreich könnte hier Pionier sein und gleichzeitig davon wirtschaftlich profitieren: Als Exporteur einer Aufsichtstechnologie.

Marktperspektive und Unternehmensgründung

Auch jenseits der öffentlichen Hand existiert ein Markt für solch ein Produkt. IT-Sicherheitsberatung und Auditierung ist ein wachsendes Geschäftsfeld, und Tools, die diesen Prozess automatisieren, sind gefragt. Ein Beispiel: Im Finanzsektor haben sich sogenannte RegTech-Lösungen etabliert, die Banken bei der Erfüllung regulatorischer Auflagen unterstützen. Unser Tool könnte als SecTech (Security Technology) oder SupTech-Lösung dienen, die Aufsichtsbehörden und Unternehmen zusammenbringt. Es ließe sich ein Spin-off oder eine Kooperation mit einem bestehenden IT-Unternehmen gründen, um das Tool weiterzuentwickeln und kommerziell zu vertreiben – an Unternehmen, die vielleicht nicht unter NIS2 fallen, aber dennoch ihre Sicherheit messen wollen (z.B. große Industriebetriebe, die in der Lieferkette von kritischen Betreibern sind, oder Firmen, die sich auf Ausschreibungen durch gute Security-Noten Vorteile erhoffen).

Ein solcher Transfer in die Privatwirtschaft könnte folgendermaßen aussehen: Der Staat entwickelt den Prototyp und setzt ihn für die Pflichtbereiche ein. Die dabei gewonnene Erfahrung fließt in eine verbesserte Version 2.0. Diese könnte dann unter einer dualen Lizenz veröffentlicht werden – als Open-Source-Kern (um Vertrauen zu schaffen und Community-Beiträge zu ermöglichen) und mit zusätzlichen Enterprise-Komponenten für kommerzielle Nutzer. Eine Startup-Firma (ggf. initiiert vom BRZ oder in Public-Private-Partnership) könnte Support, Customizing und zusätzliche Module anbieten. So entstünde ein neues Produkt „Made in Austria“, das einen technologischen und wirtschaftlichen Impuls setzt.

Die Nachfrage nach Lösungen, die Cyber Risk quantifizieren und verständlich machen, steigt stetig. Man denke an Versicherungen, die Cyberpolicen anbieten – sie tun sich oft schwer, das Risiko eines Kunden einzuschätzen. Ein standardisierter Security-Score könnte hier ein Anhaltspunkt sein (vergleichbar zu einer Bonitätsauskunft in der Finanzwelt). Solche Nebennutzungen erhöhen die kommerzielle Attraktivität. Wichtig ist freilich, nicht den Eindruck einer „Privatisierung“ zu erwecken: Das staatliche Interesse (Aufsicht, Sicherheit) steht im Vordergrund. Aber ein unternehmerischer side effect wäre absolut begrüßenswert, da er Arbeitsplätze schafft und Know-how in Österreich bindet.

Vorbild für andere Domänen

Das Konzept eines KI-gestützten Bewertungstools ließe sich perspektivisch auch auf andere Compliance-Bereiche übertragen. Man denke an den Umweltschutz (ESG-Reporting), an die Finanzprüfung oder an Qualitätsstandards. Gerade mit fortschreitender KI werden in fast allen Bereichen automatisierte Compliance-Prüfungen an Bedeutung gewinnenalgomox.comalgomox.com. Wenn Österreich hier früh Expertise aufbaut, kann es diese auf weitere Felder anwenden. In einer digitalen Verwaltung könnten solche Tools den Umgang mit Vorschriften revolutionieren – weg von handbearbeiteten Formularen hin zu intelligenten Assistenten, die Unternehmen helfen, ihre Pflichten zu erfüllen und Verwaltungen helfen, den Überblick zu behalten.

In Summe steht nicht weniger als ein Paradigmenwechsel an: Regulatorik wird digital, dynamisch und präskriptiv (d.h. sie sagt konkret, was zu tun ist, anstatt nur abstrakte Normen vorzugeben)esma.europa.euesma.europa.eu. Das hier vorgeschlagene Supervisory Tool verkörpert diesen Wandel im Bereich Cybersecurity exemplarisch. Gelingt die Umsetzung, positioniert sich Österreich als Innovationsmotor in der EU. Das stärkt nicht nur die Sicherheit, sondern auch die digitale Souveränität und Wettbewerbsfähigkeit.

Handlungsempfehlungen und Appell

Angesichts der dargelegten Probleme und Möglichkeiten sollten die verantwortlichen Entscheidungsträger jetzt entschlossen handeln. Hier sind konkrete Schritte und Empfehlungen, um die Vision Realität werden zu lassen:

1. Initiative auf höchster Ebene starten: Die Bundesregierung – idealerweise im Schulterschluss zwischen Innenministerium und Kanzleramt – sollte ein Programm „Digitales Aufsichts-Tool Cybersicherheit“ ins Leben rufen. Dieses muss klar als prioritäres Digitalisierungs- und Sicherheitsprojekt kommuniziert werden, um die nötige politische Sichtbarkeit zu erhalten. Ein Beschluss im Ministerrat oder eine öffentliche Ankündigung durch die Bundeskanzleramtsspitze könnten den Startschuss geben.
2. Task-Force einrichten: Unmittelbar sollte eine interdisziplinäre Task-Force gebildet werden, die binnen weniger Monate ein Pflichtenheft und einen Fahrplan erstellt. Darin vertreten sein müssen Experten der genannten Behörden (BMI, BKA/Digitalisierung, CERT.at, DSB, BRZ), Vertreter der Wirtschaft (etwa WKO für KMU-Perspektive, vielleicht kritische Infrastruktur-Betreiber) und Fachleute für KI und Security Audits aus Forschung und Praxis. Dieses Gremium definiert Anforderungen, wählt ggf. schon Technologiepartner aus und begleitet das Projekt kontinuierlich.
3. Proof-of-Concept (PoC) mit Pilotunternehmen durchführen: Um schnell greifbare Ergebnisse zu erzielen, sollte ein PoC entwickelt werden. Beispielsweise könnte man mit einem Sektor starten – etwa dem Energiesektor, der unter NIS2 fällt. Ein paar freiwillige Pilotunternehmen (z.B. ein großer Energieversorger und ein regionaler Netzbetreiber) nutzen ein prototypisches Tool und liefern Feedback. Dieser PoC sollte innerhalb von 6–9 Monaten lauffähig sein und die Grundidee validieren. Erkenntnisse daraus fließen in die breite Umsetzung.
4. Rechtliche Grundlage klären und schaffen: Das NIS2-Umsetzungsgesetz (NISG neu) sollte nach Möglichkeit Klauseln enthalten, die den Einsatz solcher Tools fördern. Etwa könnte es heißen, dass die Vorlage eines durch ein anerkanntes Tool generierten Sicherheitsreports als Erfüllung bestimmter Berichtspflichten gilt. Oder dass Aufsichtsbehörden ermächtigt sind, solche Analysen bei Unternehmen einzufordern bzw. selbst durchzuführen. Wichtig: Freiwilligkeit belohnen – z.B. kann man festlegen, dass ein guter Score im Supervisory Tool bei der Bemessung von Aufsichtsschwerpunkten berücksichtigt wird (risk-based approach: wer gut dasteht, wird weniger häufig geprüft). Dadurch entsteht ein Anreiz zur Nutzung, ohne Zwang.
5. Budget und Ressourcen bereitstellen: Ohne ausreichende Finanzierung wird es nicht gehen. Es sollte ein mehrjähriges Budget für Entwicklung und Betrieb eingeplant werden – das ist eine Investition in die Zukunft. Mittel könnten aus dem Cyber-Sicherheitsfonds, aus allgemeinen Digitalisierungsbudgets oder EU-Fördertöpfen (Digital Europe, Resilienzfazilität etc.) kommen. Ebenso wichtig: Personal bereitstellen. Das BRZ braucht zusätzliche Entwicklerkapazitäten, CERT.at evtl. extra Stellen für Threat Intel im Tool-Kontext, die DSB vielleicht einen Referenten für die Integration ihrer Anforderungen. Dieses Projekt muss sich in den Stellenplänen und Finanzierungsentscheidungen niederschlagen.
6. Europäische Kooperation suchen: Parallel zur nationalen Umsetzung sollte Österreich das Thema in EU-Gremien (etwa im NIS-Kooperationsforum, bei ENISA und der Kommission) voranbringen. Ziel: Erfahrungsaustausch und möglicherweise Standardisierung. Wenn mehrere Länder ähnliche Tools entwickeln, könnte man interoperable Formate vereinbaren (z.B. ein EU-weit einheitliches Sicherheits-Score-Format). Eventuell kann Österreich eine Leading Role in einem EU-Pilotprojekt übernehmen. Die Einbindung internationaler Beispiele (NIST, ANSSI etc.) im Artikel zeigt: Wir können von anderen lernen, aber auch eigene Akzente setzen und zum Exporteur von Lösungen werden.
7. Sensibilisierungskampagne und Training: Schon während der Entwicklung muss die zukünftige Nutzerschaft – Unternehmen und Prüfer – vorbereitet werden. Geplant werden sollten Workshops, Webinare und Info-Materialien, die erklären, wie das Tool funktioniert, welchen Nutzen es bringt und wie Datenschutz gewährleistet wird. Die oft skeptische Haltung („KI bewertet uns – können wir dem trauen?“) muss durch Aufklärung in Richtung Chancen gelenkt werden. Auch interne Auditoren und Sicherheitsbeauftragte sollen früh eingebunden werden, damit sie das Tool als Hilfe und nicht als Bedrohung ihres Arbeitsplatzes sehen. Möglicherweise entstehen sogar neue Rollen, wie „Compliance Data Analyst“, die das Zusammenspiel von KI-Tool und Organisation managen – hier kann Weiterbildung ansetzen.
8. Open-Source-Komponente und Community: Soweit möglich, sollte ein großer Teil des Tools quelloffen gestaltet werden. Dadurch können externe Experten Code begutachten (wichtig für Vertrauen in die Sicherheit), und die Entwickler-Community kann Beiträge leisten (z.B. neue Parser für exotische Dateiformate schreiben, zusätzliche Check-Regeln ausarbeiten). Open-Source sorgt zudem für Nachhaltigkeit: Selbst wenn ein kommerzieller Anbieter involviert ist, verhindert Offenheit proprietäre Abhängigkeiten. Einige Teile (etwa das LLM-Modell) mögen aus Schutzgründen oder Lizenzgründen geschlossen bleiben, aber Transparenz sollte wo immer unkritisch gegeben, hergestellt werden.
9. Kontinuierliche Verbesserung und Feedback-Schleifen: Nach Roll-out darf nicht Schluss sein. Es sollte Mechanismen geben, um Feedback von Nutzern (Unternehmen wie Aufsehern) systematisch einzusammeln und regelmäßig Updates abzuleiten. Vielleicht etabliert man ein Beirat-Gremium aus Anwendern, das halbjährlich zusammentritt. Das Thema KI-Ethik ist ebenso zu beobachten – falls das Tool etwa falsche Schlüsse zieht, muss das rasch korrigiert werden. Die Verantwortlichen sollten einen Prozess definieren, wie mit „False Positives/Negatives“ umgegangen wird und wie das System daraus lernt.

Diese Empfehlungen sind ehrgeizig, aber realisierbar, wenn der politische Wille vorhanden ist.

Fazit: Mit KI und Mut zu besserer Sicherheit

Österreich und Europa stehen am Scheideweg: Entweder verharren wir in klassischen, schwerfälligen Methoden der Sicherheitsüberprüfung – und riskieren damit, dass gute Gesetze wie DSGVO und NIS2 ins Leere laufen. Oder wir nutzen die digitalen Technologien des 21. Jahrhunderts, um Aufsicht smarter, schneller und wirksamer zu gestalten. Ein staatlich betriebenes, lokal ausgeführtes KI-Tool für Unternehmenssicherheit ist kein Science-Fiction mehr, sondern eine greifbare Option. Die Bausteine – von leistungsfähiger KI über Erfahrungen mit Sicherheitsbewertungen bis hin zu politischem Problembewusstsein – sind vorhanden. Jetzt gilt es, sie mutig zusammenzufügen.

Der vorgestellte Ansatz würde die Compliance-Welt auf den Kopf stellen: Weg von PDF-Berichten und sporadischen Auditor-Besuchen, hin zu einem kontinuierlichen, datengetriebenen und kooperativen Sicherheits-Ökosystem. Unternehmen würden nicht länger im Dunkeln tappen, ob sie genug für die Sicherheit tun – ein objektiver Score würde ihnen den Spiegel vorhalten. Behörden könnten ihrer Schutzverantwortung proaktiv nachkommen, ohne jedes Mal händisch Akten zu wälzen. Und letztlich profitieren wir alle davon: Weniger erfolgreiche Cyberangriffe bedeuten Schutz von Privatsphäre, von kritischer Infrastruktur und von wirtschaftlichen Werten.

Natürlich, ein solches Transformationsprojekt ist kein Selbstläufer. Es verlangt initiale Investitionen, ein Umdenken bei allen Beteiligten und internationales Abstimmen. Aber die Alternative – weiterwursteln im Status Quo – ist langfristig teurer und gefährlicher. Die Kosten von Sicherheitsvorfällen, die wir durch präventive Analysen vermeiden können, sind um ein Vielfaches höher als die eines KI-gestützten Tools. Die politischen Entscheidungsträger müssen diese präventive Logik verinnerlichen: Genau wie Feuerwehren und Sirenennetze selbstverständlich finanziert werden, obwohl man hofft, sie nie zu benötigen, muss auch in digitale Präventionsinfrastruktur investiert werden, bevor der Schaden entsteht.

Wir appellieren daher an die Verantwortlichen in Regierung, Verwaltung und Wirtschaft: Machen wir Österreich zum Vorreiter einer neuen Ära der Cyber-Compliance! Bündeln wir die Kräfte von Innenministerium, Kanzleramt, CERT.at, Datenschutzbehörde, BRZ und vielen anderen, um dieses Supervisory Tool zu entwickeln. Es ist eine Investition in die Sicherheit unserer Unternehmen und Bürger. Es ist aber auch ein Signal an Europa, dass wir nicht nur Regulierung produzieren, sondern auch die Werkzeuge, um sie erfolgreich umzusetzen. Die Zeit drängt – NIS2 tritt in Kraft, Cyberangriffe schlafen nicht. Nutzen wir die vorhandene Technologie und unser Know-how, um den digitalen Raum sicherer zu machen, mit Innovation „made in Austria“. Jetzt ist der Moment, diesen Schritt zu wagen. Wir sind es den Bürgerinnen und Bürgern, der Wirtschaft und letztlich uns selbst schuldig, aus klugen Konzepten entschlossene Taten folgen zu lassen. In diesem Sinne: Packen wir es an – für ein sicheres digitales Österreich in einem starken digitalen Europa.

Quellen: Die in diesem Artikel gemachten Aussagen basieren auf öffentlichen Studien, Umfragen und Berichten, u.a. von Bitkom, techconsult, ECSO, ESMA, CNIL/ANSSI sowie technischen Fachbeiträgen. Wichtige Fakten und Zitate sind den referenzierten Quellen entnommen, um die Argumentation zu untermauern.lto.delto.deap-verlag.deap-verlag.depit.atpit.atesma.europa.eucnil.frlearn.microsoft.com

Unternehmen stehen vor der Herausforderung, sowohl technische Schwachstellen (wie Software-Sicherheitslücken) als auch organisatorische IT-Governance-Risiken zu erkennen und zu bewerten. Ein umfassendes Analyse- und Bewertungstool kann diese Aufgabe unterstützen, indem es automatisiert Best Practices abgleicht und Sicherheitsbewertungen (Security Scores) generiert. Im Folgenden wird skizziert, wie ein solches System aufgebaut sein könnte – von der technischen Architektur über Datenquellen und Scoring-Modelle bis hin zum Einsatz von KI. Dabei werden auch Beispiele bestehender Lösungen betrachtet und besondere Anforderungen für ein staatlich betriebenes, vertrauenswürdiges System diskutiert.

Technische Architektur und modularer Aufbau

Ein modernes Bewertungstool sollte modular und skalierbar aufgebaut sein, um verschiedene Funktionen getrennt und flexibel bereitstellen zu können. Typische Architekturkomponenten sind:

• Datenerfassungskomponenten: Module oder Scanner zur Sammlung von sicherheitsrelevanten Informationen. Diese können lokal (z.B. als Agent auf Servern/Endgeräten oder virtuelle Appliance in einem Netzsegment) oder Cloud-basiert agieren. Viele kommerzielle Vulnerability-Scanner nutzen z.B. lokale Scanner-Appliances, die Ergebnisse an eine Cloud-Plattform senden (Qualys etwa betreibt eine Cloud-Plattform mit verteilten Scanning Appliances).
• Zentrale Analyse-Plattform: Eine Kernkomponente (on-premises oder in der Cloud) aggregiert alle gesammelten Daten in einer Datenbank und führt die Bewertung und Korrelation durch. Dieser Kern kann als Cloud-Service bereitgestellt werden – was schnelle Updates und zentrale Sicht ermöglicht – oder in einem lokalen Rechenzentrum betrieben werden, falls Datenschutz oder Souveränität dies erfordern (für staatliche Anwendungen eventuell relevant). Ein hybrider Ansatz ist denkbar: sensible Rohdaten bleiben lokal, nur abstrahierte Scores oder Berichte werden in eine zentrale Instanz übertragen.
• Modulare Analyse-Engines: Innerhalb der Plattform können spezialisierte Engines für unterschiedliche Bewertungsaufgaben zuständig sein – z.B. eine Schwachstellen-Engine (importiert CVE-Informationen, berechnet CVSS-Scores), eine Konfigurations-/Compliance-Engine (prüft Konfigurationen gegen Benchmarks), und eine Governance-Engine (wertet Antworten aus Selbstbewertungs-Fragebögen oder Dokumente aus). Diese Trennung erlaubt es, das System je nach Sektor oder Fokus anzupassen.
• API- und Integrationsschicht: Die Architektur sollte offene API-Schnittstellen bieten, um Daten ein- und auszuliefern. Über sichere APIs können externe Tools eingebunden werden (z.B. Import von Scannergebnissen) und Ergebnisse in andere Systeme (SIEM, GRC-Tools etc.) exportiert werden. Beispielsweise bieten gängige Scanner wie Tenable.io APIs an, um Asset- und Schwachstellendaten abzurufendeveloper.tenable.com, was die Einbindung in ein zentrales Bewertungsdashboard erleichtert.
• Frontend und Reporting: Ein Dashboard/Web-Frontend ermöglicht Nutzern die Interaktion – z.B. zum Ausfüllen von Self-Assessment-Forms, zur Ansicht der aktuellen Sicherheitskennzahlen und Berichte. Die Architektur sollte Mehrmandantenfähigkeit unterstützen (mehrere Organisationen können ihre Daten isoliert verwalten), mit rollenbasiertem Zugriff (z.B. technische Administratoren sehen Detaildaten, Manager erhalten zusammengefasste Berichte).

Diese modularen Komponenten kommunizieren idealerweise über standardisierte Protokolle, und es bietet sich an, Container oder Microservices einzusetzen, um Skalierbarkeit und Wartbarkeit zu erhöhen. Für ein staatliches System könnte z.B. ein zentrales Cloud-Backend betrieben werden, während Organisationen nur einen leichten lokalen Collector installieren, der benötigte Daten sammelt und über gesicherte Kanäle an das Backend übermittelt – so bleiben sensible Details vor Ort, die zentrale Instanz sieht primär die aggregierten Ergebnisse.

Datenquellen und Importmöglichkeiten

Damit das Bewertungstool ein möglichst vollständiges Bild der Sicherheitslage zeichnen kann, müssen unterschiedliche Datenquellen berücksichtigt werden:

• Automatisierte Schwachstellenscans: Klassische Vulnerability-Scanner (Nessus, OpenVAS, Qualys etc.) liefern Listen von gefundenen Schwachstellen (CVE-basiert) inkl. Schweregraden. Diese Daten können per API oder Dateiimport ins Tool eingespeist werden. Moderne Lösungen erlauben z.B. die Integration mehrerer Scanner parallel, um verschiedene Umgebungen abzudecken (Netzwerk, Webapps, Container etc.).
• Konfigurations- und Inventardaten: Informationen über die IT-Umgebung – z.B. Systemkonfigurationen, eingesetzte Software-Versionen, Netzwerkdiagramme – können per Konfigurationsdatei-Upload oder automatisiert via Schnittstellen importiert werden. Beispiele: Exportierte Firewall-Regeln, Azure AD Sicherheits-Einstellungen, Endpoint-Konfigurationsdaten. Ein Tool wie Wazuh bietet z.B. Security Configuration Assessment durch Auswertung von Konfigurationsdateienfedramp.gov.
• API-Integration in Cloud- und SaaS-Dienste: Viele Unternehmen nutzen Cloud-Dienste, daher sollte das Tool Cloud-Sicherheitszustand abfragen können. Beispielsweise könnte eine Anbindung an Microsoft Graph API genutzt werden, um Einstellungen aus Microsoft 365 (für Microsoft Secure Score relevante Daten) oder an AWS/Azure APIs, um Cloud-Konfigurationen gegen Best Practices (CIS Benchmarks, AWS Well-Architected Framework etc.) zu prüfen. Microsoft Secure Score selbst wertet Systemkonfigurationen, Benutzerverhalten und andere Messungen aus der Microsoft-Cloud auslearn.microsoft.com.
• Threat Intelligence Feeds: Zum Erkennen von IT-Governance-Risiken gehört auch der Blick nach außen. Eine Integration von Threat Feeds kann z.B. kompromittierte Accounts (aufgetauchte Zugangsdaten im Darknet), bekannte Indikatoren oder Warnlisten (z.B. die CISA KEV-Liste exploitierten Schwachstellen) importieren. Diese Informationen fließen in die Bewertung der Dringlichkeit ein. Moderne Risiko-Tools wie Rapid7 InsightVM ziehen bereits Feeds (ExploitDB, AttackerKB, CISA KEV usw.) heran, um die Priorität von Schwachstellen zu erhöhen, die aktiv ausgenutzt werdenrapid7.comrapid7.com.
• Selbstbewertungsformulare und Fragebögen: Aspekte wie IT-Governance, Policies und organisatorische Kontrollen sind schwer automatisiert scannbar. Hier kommen Selbstbewertungen ins Spiel: Verantwortliche füllen strukturierte Fragebögen aus (z.B. nach ISO 27001-Kontrollen, CIS Controls, NIS2-Anforderungen), evtl. mit Möglichkeit, Dokumente als Nachweise hochzuladen. Ein Beispiel dafür ist das CIS Controls Self Assessment Tool (CIS CSAT), ein kostenloses Werkzeug, mit dem Unternehmen den Umsetzungsgrad der CIS Controls erfassen können. Es erlaubt, pro Control anzugeben, ob und wie gut die Anforderung erfüllt ist, und Dokumente als Evidenz beizufügencisecurity.org. Solche Fragebogen-Daten werden vom Bewertungstool in Scores bzw. Reifegrade umgewandelt.
• Schnittstellen zu GRC/Asset-Datenbanken: Falls bereits ein Asset-Management oder Governance-Risk-Compliance (GRC) System vorhanden ist, kann das Tool daraus Informationen übernehmen (z.B. eine Asset-Liste mit Einstufung der Schutzklassen, vorhandene Risk Register, frühere Audit-Ergebnisse). Die nahtlose Integration reduziert Doppelaufwand und stellt Kontext bereit (etwa Asset-Kritikalität, die für Risikoberechnungen wichtig ist). Tenable’s Plattform berücksichtigt bspw. eine Asset Criticality Rating (ACR), die aus Faktoren wie Exposition, Typ und Fähigkeiten des Assets berechnet wird, um die Risikobewertung eines Fundes an die Bedeutung des betroffenen Systems anzupassendocs.tenable.comdocs.tenable.com.

Die Herausforderung bei der Datenintegration ist zum einen die Standardisierung (unterschiedliche Tools liefern unterschiedliche Formate und Metriken) und zum anderen der Datenschutz. Ein staatliches System müsste klar regeln, welche Daten hochgeladen werden (z.B. keine personenbezogenen Daten, sofern nicht nötig) und wie sie geschützt werden.

Bewertungslogiken und Risikomodelle

Kernstück des Tools ist die Bewertungslogik, welche die eingehenden Rohdaten in verständliche Kennzahlen (Scores, Ratings) und Einstufungen umwandelt. Hier kommen etablierte Scoring-Modelle und Risikoanalyse-Frameworks zum Einsatz, meist kombiniert:

• Schwachstellen-Scoring (CVSS): Für technische Sicherheitslücken ist der de-facto Standard das Common Vulnerability Scoring System (CVSS). Jede bekannte Schwachstelle (CVE) erhält einen CVSS-Basiswert von 0–10, berechnet aus Eigenschaften wie Ausnutzbarkeit, Auswirkung, erforderliche Zugriffsrechte etc. Das Bewertungstool kann CVSS-Werte aus der NVD-Datenbank übernehmendocs.tenable.com. Allerdings ist CVSS ein statisches Schweregradmaß („Welches Schadpotenzial hat diese Lücke generell?“) und kein direktes Risikomaß, da Kontext fehlt. Daher ergänzen viele Hersteller CVSS durch eigene Risikopriorisierung:
• • Tenable z.B. nutzt neben CVSS eine dynamische Vulnerability Priority Rating (VPR), die weitere Faktoren einbezieht, um Dringlichkeit zu quantifizierendocs.tenable.com. Diese kann z.B. höher sein, wenn ein Exploit verfügbar ist oder die Schwachstelle aktiv ausgenutzt wird.
  • Rapid7 InsightVM berechnet ein Risikoscore 0–1000 je Asset und Schwachstelle, der CVSS-Basiswerte + Threat Intelligence kombiniert. Ihr neues Modell Active Risk integriert Bedrohungsdaten (Metasploit, ExploitDB, CISA KEV etc.) direkt in die Score-Berechnungrapid7.com. So werden z.B. Schwachstellen mit bekannten aktiven Exploits wesentlich höher bewertet als reine theoretische Lücken. Dieses Modell ist zudem CVSS 3.1 kompatibel und vorbereitet auf künftige Standards wie CVSS v4rapid7.com.
• Reifegradmodelle (Maturity Models): Für Prozesse und Kontrollen (IT-Governance) werden oft Reifegrade vergeben. Ein einfaches Modell wären z.B. Stufen 0–5 (0 = nicht vorhanden, 5 = optimiert/Kontinuierliche Verbesserung). ISO 27001 verlangt z.B. eine regelmäßige Bewertung und Verbesserung der Sicherheitsmaßnahmen – ein Reifegradmodell nach ISO 27001 könnte jeder Kontrollmaßnahme einen Umsetzungsgrad zuordnenresearchgate.net. Auch der BSI IT-Grundschutz oder andere Standards kennen Reifegrade. Das Tool könnte also Antworten aus einem Governance-Fragebogen automatisch in Reife-Stufen mappen. Beispiel: Eine Frage „Existiert ein Incident Response Plan und wird er getestet?“ könnte Scoring-Regeln haben: Nein = Reifegrad 0, Plan vorhanden aber nicht getestet = 2, regelmäßig getestet und verbessert = 4. Am Ende lässt sich pro Domain (z.B. nach den 14 ISO 27001-Kapiteln oder NIST CSF Kategorien) ein Durchschnitts-Reifegrad darstellen.
• Gap-Analyse gegenüber Normen: Wenn eine Organisation sich an Normen wie ISO/IEC 27001 oder der EU NIS2-Richtlinie messen muss, kann das Tool den Erfüllungsgrad in Prozent oder Punkten ausdrücken. Dies erfordert, dass die einzelnen Anforderungen der Norm im System hinterlegt sind (als Fragen oder Kontrollpunkte) und mit dem jeweiligen Umsetzungsstatus verknüpft werden. Beispiel: Viele NIS2-Anforderungen decken sich mit ISO-Kontrollen – es gibt Mapping-Tabellen, die das korrelierenbsigroup.com. Ein Tool könnte z.B. aus den Antworten der ISO-Checkliste ableiten, dass 80% der NIS2-Pflichten erfüllt sind, und die fehlenden Punkte auflisten (Gap-Liste mit Handlungsempfehlungen). Diese Art der Gap-Analyse bietet konkrete Verbesserungsziele: Unternehmen sehen, wo Lücken zu Standards bestehen, und können priorisieren.
• Aggregierte Risiko-Bewertungen: Letztlich möchte man einen Security Score oder mehrere Kennzahlen erhalten, die das Risiko auf hoher Abstraktionsebene zusammenfassen. Verschiedene Ansätze sind möglich:
• • Score nach Bereichen: z.B. getrennte Scores für Technische Sicherheit (Netzwerk, Systeme), Anwendungs-/Softwaresicherheit, Identity & Access Management, organisatorische Maßnahmen etc., die dann ggf. in einen Gesamtscore einfließen. Microsoft Secure Score teilt z.B. in Kategorien wie Identität, Gerät, Apps, Daten, Infrastruktur auf und gibt pro Bereich Punkteapexdigital.com.
  • Gewichtete Gesamtpunktezahl: Das System kann alle Bewertungen auf einen einheitlichen Score (z.B. 0–100 oder 0–1000) normieren. Wichtig ist dabei eine sinnvolle Gewichtung: Z.B. könnte man technische Schwachstellen (die zu unmittelbaren Sicherheitsvorfällen führen können) höher gewichten als Formaldefizite. Einige Frameworks nutzen auch Risikomatrizen (Eintrittswahrscheinlichkeit x Auswirkungsgrad). Einfache Modelle multiplizieren qualitative Werte (Hoch/Mittel/Niedrig); fortgeschrittene quantitative Modelle wie FAIR berechnen monetäre Risikowerte. Für ein breites Bewertungstool eignet sich oft eine Punkteskala kombiniert mit Farbcodierung (z.B. 0–33 rot, 34–66 gelb, 67–100 grün), um den Status visuell klarzumachen.
  • Benchmarking und Peer-Vergleich: Insbesondere wenn das System sektorübergreifend viele Teilnehmer hat (z.B. alle kritischen Infrastrukturen eines Landes), können Scores im Vergleich wertvollen Kontext liefern. Ein Unternehmen möchte wissen, wo es im Vergleich zum Branchendurchschnitt steht. Das Tool könnte anonymisierte Vergleichswerte je Sektor bieten – etwa ein „Score 75 – über dem Branchenschnitt von 65“ als Motivation oder Rechtfertigung von Investitionen.

Wichtig ist, dass die Bewertungslogik transparent dokumentiert ist. Wenn ein Score berechnet wird, sollte nachvollziehbar sein, welche Faktoren (und mit welchem Gewicht) eingeflossen sind – nur so wird die Bewertung akzeptiert. Beispielsweise erklärt Microsoft, dass Secure Score keine absolute Wahrscheinlichkeit eines Breachs angibt, sondern misst, in welchem Maße empfohlene Sicherheitsmaßnahmen umgesetzt wurdenlearn.microsoft.com. Solche Erläuterungen helfen den Nutzern, die Bedeutung des Scores richtig einzuordnen.

Rolle von KI-Komponenten (LLMs) bei Analyse und Bewertung

Künstliche Intelligenz, insbesondere Large Language Models (LLMs) wie GPT-4, kann in einem solchen Tool verschiedene Mehrwerte bieten. Gleichzeitig müssen Aspekte wie Erklärbarkeit und Verlässlichkeit beachtet werden (dazu später mehr). Mögliche Einsatzfelder für KI/LLM-Komponenten:

• Automatisierte Auswertung von Freitexten und Dokumenten: In der IT-Governance fallen oft Freitext-Dokumente an (Sicherheitsrichtlinien, Prozessbeschreibungen, Audit-Berichte). Ein LLM könnte helfen, solche Texte zu analysieren – z.B. herauszulesen, ob bestimmte Richtlinien vorhanden sind oder ob ein Dokument alle geforderten Inhalte abdeckt. Es könnte Antworten aus einem unstrukturierten Bericht extrahieren und strukturieren, um sie ins Bewertungsschema einzuspeisen.
• Assistent für Selbstbewertung: Anstatt statischer Fragebögen könnte ein Chatbot-Interface (basierend auf einem LLM) Firmen interaktiv befragen. Ein KI-Assistent könnte z.B. Dialoge führen à la „Beschreiben Sie, wie Ihr Backup-Konzept umgesetzt ist“ und dann die Antwort bewerten/einsortieren. NEC hat etwa eine Technologie vorgestellt, die LLM-Dialoge nutzt, um die Risiken eines Systems zu diagnostizieren und dem Nutzer in einfachen Worten zu erklärennec.com. Damit können auch Nicht-Sicherheits-Experten die Risikoanalyse nachvollziehen.
• Analyse von Angriffspfaden: Fortgeschrittene Tools modellieren mögliche Angriffspfade in der Infrastruktur (wie kommt ein Angreifer von einem Einstiegspunkt zu kritischen Systemen?). LLMs können genutzt werden, um solche Pfade zu beschreiben und die Risiken daraus abzuleiten. NEC kombinierte sein vorhandenes Tool zur automatischen Angriffspfad-Analyse mit einem LLM, um die Ergebnisse dem Kunden quasi in Form eines Experten-Berichts darzustellennec.comnec.com. Dadurch wurde der Erstellungsaufwand für Berichte um ~60% reduziert – das LLM generiert in Minuten einen umfassenden Report, was zuvor Tage an manueller Expertenarbeit warennec.com.
• Empfehlung und Best-Practice-Vorschläge: KI kann auf Basis der identifizierten Schwachstellen maßgeschneiderte Maßnahmenempfehlungen formulieren. LLMs, trainiert auf Cybersecurity-Wissen, könnten ausgeben: „Aktivieren Sie MFA für alle Administratorkonten, um Score X zu verbessern, dies entspricht auch Maßnahme Y aus ISO27001“. Wichtig dabei: Die Empfehlungen müssen fachlich korrekt und kontextbezogen sein – eine KI sollte idealerweise an die internen Wissensbanken/Regelwerke gekoppelt werden, um verlässliche Ratschläge zu geben.
• Anomalieerkennung in Security-Logs: Zwar liegt Fokus des Tools auf Bewertung, aber man könnte KI auch nutzen, um aus eingehenden Telemetriedaten (Logfiles, Netzwerktraffic) auffällige Muster zu erkennen, die auf Risiken hindeuten (z.B. Konfigurationsdrift, fehlgeschlagene Login-Wellen). Klassische ML-Modelle oder neue KI-Ansätze könnten hier unterstützen.

Ein wesentliches Kriterium bei KI-Einsatz ist die Erklärbarkeit. In sicherheitskritischen Bereichen darf die KI kein undurchschaubarer „Orakel-Kasten“ sein. Das heißt, das System muss die Gründe hinter den KI-Ergebnissen darlegen: Warum schlägt die KI eine bestimmte Bewertung oder Maßnahme vor? NEC betont etwa, dass Standard-LLMs Antworten geben, „ohne die Gründe klar zu erklären“, was zu Zweifel an der Korrektheit führtnec.com. In ihrem LLM-basierten Tool wurde daher großer Wert darauf gelegt, zuverlässige, überzeugende Begründungen mitzuliefernnec.com. Man erreicht dies durch spezielle Prompt-Techniken, Trainingsdaten (die z.B. erklärende Reports beinhalten) und gegebenenfalls Einschränkungen des Modells auf klare Antwortschemas. Ein Vorteil von erklärbarer KI: Sie schafft Vertrauen und Transparenz. Im Kontext Vulnerability und Risk Assessment zeigen XAI-Ansätze bereits, dass sie helfen können, verständlich zu machen, warum bestimmte Schwachstellen priorisiert wurden, was die Nachvollziehbarkeit der Priorisierung erhöhttripwire.com.

Zusätzlich sollten KI-Module Grenzen kennen – d.h. wenn Unsicherheit besteht, lieber nachfragen oder auf menschliche Prüfung verweisen (Prinzip der Knowledge Limits in XAItripwire.com). Bei einem staatlichen Bewertungssystem könnte man KI vor allem als unterstützendes Werkzeug einsetzen, das finalen Entscheidungen einen „KI geprüften“ Kontext gibt, aber nicht völlig autonom urteilt.

Visualisierungen und Berichtsformate

Die Ergebnisse der Analysen müssen für verschiedene Zielgruppen aufbereitet werden – vom IT-Administrator bis zur Geschäftsleitung oder Aufsichtsbehörde. Entsprechend sollte das Tool mehrere Ausgabeformate und Visualisierungen bieten:

• Dashboard-Ansicht: Ein interaktives Web-Dashboard ermöglicht die aktuelle Sicherheitslage auf einen Blick zu erfassen. Typische Widgets sind:
• • Gesamt-Security Score als Kennzahl, oft begleitet von einer Ampelfarbe oder einem Tacho/Gauge-Diagramm.
  • Trendverlauf über die Zeit (Linien- oder Balkendiagramm), um zu sehen, ob sich die Sicherheitspostur verbessert oder verschlechtert.
  • Kategorie-Aufschlüsselung: z.B. ein Balkendiagramm oder Ringdiagramm, das zeigt, wie der Score sich aus Teilbereichen zusammensetzt (Netzwerk, Endpunkte, Cloud, Prozesse etc.).
  • Top-Risiken oder Lücken: ein Panel, das z.B. die wichtigsten offenen Schwachstellen (nach Risk Score) auflistet, oder die größten Compliance-Lücken im Überblick.
• Berichte für Management/Audits: Das Tool sollte per Knopfdruck Berichte als PDF oder Präsentation erzeugen, die man intern oder an Prüfer weitergeben kann. Inhalt: Zusammenfassung der Bewertung, Detailtabellen, Maßnahme-Empfehlungen. Ein gutes Berichtswesen bietet verschiedene Detailstufen – vom Executive Summary (nichttechnisch, geschäftsorientiert: „Unser Score ist 78 von 100, besser als Branchenschnitt, größte Schwäche: fehlendes Patch-Management.“) bis zum technischen Anhang (detaillierte Listen aller gefundenen Schwachstellen mit CVEs, aller mit Nicht erfüllt bewerteten Kontrollfragen etc.). Ein LLM kann hier helfen, Berichte in natürlichsprachlichem Fließtext zu erstellen. NEC zeigte, dass ihr LLM Berichte in Qualität vergleichbar zu Expertendokumenten schreiben kannnec.comnec.com. Solche Berichte fokussieren auf die Kernbotschaften und filtern unwichtige Details heraus, um den Leser nicht zu erschlagennec.com.
• Visualisierung von Angriffspfaden und Risiken: Komplexere technische Ergebnisse (z.B. Netzwerk-Topologie mit markierten Schwachstellen, oder ein Diagramm eines simulierten Cyberangriffs) könnten grafisch dargestellt werden. Etwa ein Netzplandiagramm, wo kritische Knoten rot markiert sind. Für Management ist auch eine Heatmap beliebt – z.B. eine 2D-Matrix mit Impact vs. Likelihood, in der Risiken einsortiert sind.
• Vergleich und Benchmark-Charts: Wenn das System Organisationen vergleicht, könnten anonymisierte Boxplots oder Perzentil-Diagramme gezeigt werden: „Ihr Score liegt im oberen Quartil aller teilnehmenden Krankenhäuser“ etc. Auch interne Vergleiche (mehrere Abteilungen, Geschäftsbereiche oder Tochtergesellschaften) wären nützlich, sofern die Architektur Mandanten oder Untereinheiten unterscheidet.
• Ad-hoc-Abfragen und Drill-down: Wichtig für Experten ist die Möglichkeit, vom hohen Level ins Detail zu zoomen. Klickt man z.B. auf einen Score-Bereich Netzwerksicherheit 70/100, sollte man die Einzelbewertungen dahinter sehen (z.B. „Firewall-Konfiguration = gut (90), Patch-Level Server = mittel (60) ...“). Bis hinunter zum einzelnen Befund (ein bestimmter Server hat Schwachstelle XYZ mit CVSS 9.8, daher Punkteabzug). Diese Auditierbarkeit der Visualisierung steigert die Akzeptanz, da alles prüfbar ist.

Visuell ansprechend und zugleich informativ zu gestalten, ist ein Balanceakt. Insbesondere ein staatliches Tool sollte auf Sachlichkeit und Klarheit setzen (keine reißerischen Grafiken). Es empfiehlt sich, Nutzer in Usability-Tests einzubinden, um die Berichte praxisgerecht zu gestalten.

Beispiele bestehender Lösungen und Modelle

Zur Orientierung dienen einige bereits existierende Lösungen, die Teile der geforderten Funktionalität bieten. Die folgende Tabelle gibt einen Überblick:

Lösung / ToolFokus & DatenquellenScoring-Ansatz

Microsoft Secure Score

Bewertet die Nutzung von Sicherheitsfeatures in Microsoft-Cloud-Diensten (M365, Azure). Datenquellen sind Systemkonfigurationen, Nutzerverhalten und Aktivitäten in der Microsoft-Umgebunglearn.microsoft.com. Integration vornehmlich über die Microsoft-Cloud (Entra ID, Defender etc.).

Punktestand (Secure Score) als numerische Zusammenfassung der Sicherheits-Postur im Microsoft-Umfeldlearn.microsoft.com. Jede empfohlene Aktion (z.B. MFA aktivieren) gibt Punkte; max. Score je nach Umgebungsumfang. Ergebnis als Prozentsatz der möglichen Punkte. Empfehlungen kategorisiert nach Bereichen (Identität, Geräte, Apps, Daten, Infrastruktur).

Tenable (Nessus/Tenable.io)

Technischer Schwachstellenscan (Netzwerk, Systeme, Webapps). Daten via Scanner (CVE-Liste, Konfigurationen) + Asset-Kritikalität. Ergänzend Compliance-Checks gegen Policy (Tenable.sc, Tenable.io haben Policy/Benchmark-SCANs).

CVSS-basierte Bewertung jeder Lückedocs.tenable.com; zusätzliche Vulnerability Priority Rating (VPR), die Kontext (z.B. Exploit verfügbar, Trend) einbeziehtdocs.tenable.com. Gesamt-Risikolevel für Assets und ganze Organisation über Cyber Exposure Score (0–1000). Höhere Werte = höheres Risikodocs.tenable.com.

Rapid7 InsightVM

Technischer Vulnerability-Scan ähnlich Tenable. Integration von Threat Feeds (ExploitDB, CISA KEV etc.) direkt in der Plattformrapid7.com. Kann über Agents kontinuierlich sammeln; Asset-Kritikalität manuell oder automatisch (Tags).

Proprietärer Risk Score 0–1000 je Schwachstelle/Asset, der CVSS-Schwere mit Wahrscheinlichkeit (Exploits, Malware-Aktivität) multipliziert. Neues Modell Active Risk betont aktiv ausnutzbare Lücken besondersrapid7.com. Bietet verschiedene Risikostrategien (z.B. nur CVSS, CVSS+Malware, etc.).

CIS Controls Assessment (CSAT)

Selbstbewertungs-Plattform für Best-Practice Kontrollen (CIS Critical Security Controls v8). Daten durch Fragebogen, manuelle Eingabe und Dokumentenuploadcisecurity.org. Fokus auf organisatorische und technische Prozesse gemäß CIS Framework.

Kein einzelner Score, sondern Erfüllungsgrad in % pro Control und Safeguard. Zeigt an, wie viele der CIS Controls umgesetzt sind, und erlaubt Mappings zu anderen Frameworks (z.B. NIST CSF)cisecurity.org. Ampelanzeigen für implementiert/teilweise/nicht implementiert. CSAT Pro ermöglicht Scoring über mehrere Teams und Reifegradbewertung.

SecurityScorecard / BitSight (externes Rating)

Externe Analyse der Angriffsfläche eines Unternehmens (Outside-in Sicht). Datenquellen: öffentlich auffindbare Infos – z.B. offene Ports, Zertifikate, Leaks, Dark-Web-Daten. Voll automatisiert (kein internes Scanning).

Security Rating als Zahl oder Note (z.B. 0–1000 oder Einstufung A–F). Bewertet verschiedene Kategorien (Netzwerksicherheit, Patch-Status, DNS, Leaks etc.). Eignet sich für Vergleich von Unternehmen und Lieferantenrisiko. (Hinweis: Diese Ratings betrachten nur öffentlich sichtbare Indikatoren; für interne Bewertung wie hier gefordert sind sie allein nicht ausreichend.)

Diese Beispiele zeigen, dass kombinierte Ansätze möglich und sinnvoll sind: Ein staatliches Bewertungstool könnte etwa die technische Tiefe von Tenable/Rapid7 (Schwachstellenscoring) verbinden mit der prozessorientierten Bewertung à la CIS CSAT. Microsofts Secure Score dient als Vorbild, wie ein Score in einer definierten Umgebung (Cloud-Dienste) automatisch berechnet werden kann – ein ähnliches Prinzip ließe sich auf generelle IT-Umgebungen übertragen (Punkte für implementierte Sicherheitsmaßnahmen).

Anforderungen: Datenschutz, Protokollierung und Nachvollziehbarkeit

Für ein staatlich betriebenes, nicht-kommerzielles System gelten besonders hohe Anforderungen an Vertrauenswürdigkeit und Transparenz. Folgende Aspekte sind entscheidend:

• Datenschutz und Datensparsamkeit: Unternehmen müssen darauf vertrauen können, dass ihre sensitiven Informationen sicher gehandhabt werden. Es sollten so wenig Rohdaten wie möglich die eigene Hoheit verlassen. Beispielsweise könnten nur aggregierte Scores oder anonymisierte Befunde an eine zentrale Plattform gemeldet werden, nicht jedoch vollständige Schwachstellenlisten mit IP-Adressen. Falls Cloud-Komponenten im Spiel sind, ist auf Datenhaltung in entsprechenden Jurisdiktionen (z.B. EU-Cloud) zu achten sowie auf Compliance mit DSGVO. Eine Möglichkeit ist auch, dem Teilnehmer die Wahl zu lassen: voll lokaler Betrieb (Self-Hosted) vs. Nutzung eines Gov-Cloud-Dienstes.
• Logging und Audit-Trail: Jede Bewertung und Änderung im System sollte lückenlos protokolliert werden. Audit-Trails sind unverzichtbar für Compliance und fördern Vertraueninscopehq.com. Die Protokolle sollten z.B. festhalten, wann welcher Scanner-Datensatz importiert wurde, welche Score-Änderungen vorgenommen wurden, und auch KI-Entscheidungen (inkl. Input/Output) dokumentieren. Bei einer späteren Überprüfung (intern oder durch Revision) muss nachvollziehbar sein, warum ein Unternehmen am Stichtag X einen bestimmten Score hatte. Audit-Logs schützen auch vor Manipulationsvorwürfen, da jede Änderung historisiert ist. Im Kontext staatlicher Aufsicht könnten Audit-Daten beweisen, dass Bewertungen fair und konsistent erfolgten.
• Transparenz der Methode: Die Bewertungsmetriken, Gewichtungen und Algorithmik sollten offen kommuniziert und möglichst auf anerkannten Standards basieren. Die Teilnehmer sollen das System als gerecht empfinden und nicht als Black Box. Denkbar ist ein öffentlich einsehbares Framework-Dokument oder sogar Open-Source-Komponenten, damit Experten die Mechanik prüfen können. Gerade weil KI-Komponenten involviert sein könnten, ist es ratsam, erklärbare Modelle einzusetzen und z.B. Beispielentscheidungen zu erläutern (X wird als kritisch eingestuft weil Bedrohungsaktivität Y detektiert wurde und Asset Wert Z hat).
• Erklärbare KI und menschliche Überwachung: Wie oben diskutiert, muss KI-Ausgabe überprüfbar sein. Ein Weg ist, dass KI-generierte Empfehlungen immer mit Referenzen auf Fakten einhergehen (z.B. Verweis auf bestimmte Datenpunkte oder Regelwerke). Eventuell sollte das System Freigabestufen haben, wo ein menschlicher Analyst KI-Ergebnisse absegnet, bevor sie ins finale Score-Ergebnis einfließen – insbesondere bei Grenzfällen. Diese Human-in-the-Loop Strategie erhöht die Akzeptanz.
• Sektorübergreifende Skalierbarkeit: Ein staatliches System soll idealerweise für verschiedene Branchen und Organisationsgrößen funktionieren – von kritischen Infrastrukturen (Energie, Gesundheit, Verwaltung) bis zu kleineren Mittelständlern. Das bedeutet:
• • Flexibles Modell: Das Scoring-Modell muss anpassbar oder allgemein genug sein, um unterschiedliche Umfeldrisiken abzubilden. Beispielsweise haben Branchen spezifische Compliance-Anforderungen (Energie: NIS2, Banken: BAIT, Gesundheit: HIPAA usw.). Das Tool sollte solche Profile berücksichtigen können. NEC beschreibt z.B., dass in ihrem LLM-basierten Diagnose-Tool „die Aspekte je nach Branche variieren und Berichte an die Leitlinien der zuständigen Behörden angepasst werden“nec.com. Ähnlich müsste ein staatliches Tool verschiedene Regulatorik-Module besitzen, die je nach Sektor zugeschaltet werden.
  • Last und Performance: Bei landesweiter Ausrollung muss die Architektur Lastspitzen aushalten können (etwa wenn alle Teilnehmer quartalsweise Berichte liefern). Eine Cloud-native, containerbasierte Architektur erleichtert das horizontale Skalieren.
  • Mehrsprachigkeit und Lokalisierung: In einem Staat oder erst recht EU-weit sollten Berichte in der jeweiligen Sprache verfügbar sein. Ggf. kann ein LLM hier sogar Übersetzungsdienste leisten, solange die Fachterminologie konsistent bleibt.
• Unabhängigkeit und Neutralität: Als nicht-kommerzielle Lösung sollte das Tool neutral gegenüber Herstellern sein (z.B. nicht nur Microsoft-Umgebungen bewerten können) und keine versteckte Agenda verfolgen. Die Vertrauenswürdigkeit steigert man, indem man Beiräte oder die Community einbindet bei der Weiterentwicklung, regelmäßige Updates der Bedrohungsmodelle (transparent dokumentiert) bereitstellt und durch Zertifizierungen die Korrektheit belegen lässt. Beispielsweise könnte der Algorithmus durch unabhängige Stellen geprüft werden.

Zusammenfassend soll ein solches Bewertungssystem Unternehmen einen ganzheitlichen Überblick über ihre IT-Sicherheitslage geben – von technischen Schwachstellen bis Governance – und das in verständlicher, quantifizierter Form. Moderne Technologien wie LLMs können die Bedienung und Auswertung erleichtern, müssen aber so eingesetzt werden, dass Ergebnisse nachvollziehbar und vertrauenswürdig bleiben. Durch modulare Architektur, breite Datenintegration und anerkannte Bewertungsmodelle kann ein staatliches Security-Score-System geschaffen werden, das Transparenz schafft, zum Best-Practice-Nachziehen motiviert und letztlich die Cyber-Resilienz auf breiter Front erhöht.

Quellen: Viele der hier diskutierten Konzepte stützen sich auf aktuelle Best Practices und veröffentlichte Informationen führender Sicherheitsplattformen, u.a. Microsoft Secure Scorelearn.microsoft.com, Tenabledocs.tenable.com, Rapid7rapid7.com, CIS CSATcisecurity.org sowie Forschungsergebnisse zum Einsatz von LLMs in der Security-Analysenec.comnec.com und zur Explainable AI im Cyber-Risikomanagementtripwire.com. Diese Referenzen unterstreichen die Bedeutung von standardisierten Scores, Threat Intelligence und erklärbarer KI für ein effektives Bewertungstool.

Zusammenfassend soll ein solches Bewertungssystem Unternehmen einen ganzheitlichen Überblick über ihre IT-Sicherheitslage geben – von technischen Schwachstellen bis Governance – und das in verständlicher, quantifizierter Form. Moderne Technologien wie LLMs können die Bedienung und Auswertung erleichtern, müssen aber so eingesetzt werden, dass Ergebnisse nachvollziehbar und vertrauenswürdig bleiben. Durch modulare Architektur, breite Datenintegration und anerkannte Bewertungsmodelle kann ein staatliches Security-Score-System geschaffen werden, das Transparenz schafft, zum Best-Practice-Nachziehen motiviert und letztlich die Cyber-Resilienz auf breiter Front erhöht.

Quellen: Viele der hier diskutierten Konzepte stützen sich auf aktuelle Best Practices und veröffentlichte Informationen führender Sicherheitsplattformen, u.a. Microsoft Secure Scorelearn.microsoft.com, Tenabledocs.tenable.com, Rapid7rapid7.com, CIS CSATcisecurity.org sowie Forschungsergebnisse zum Einsatz von LLMs in der Security-Analysenec.comnec.com und zur Explainable AI im Cyber-Risikomanagementtripwire.com. Diese Referenzen unterstreichen die Bedeutung von standardisierten Scores, Threat Intelligence und erklärbarer KI für ein effektives Bewertungstool.