Zugriffsverwaltung nach NIS2: Was fünf Experten zuerst angehen würden

Von der Richtlinie zur Praxis: Wer hatte Zugriff worauf, mit wessen Genehmigung, wie lange – und können Sie es nachweisen?

Fünf Cybersicherheitsverantwortliche über die Zugriffskontrollen, die sich am schwersten in die Praxis umsetzen lassen, und über die Nachweise, die Organisationen brauchen, um ihre Wirksamkeit zu belegen.

Zusammenfassung

Was Organisationen bei der Zugriffsverwaltung nach NIS2 nachweisen müssen, hat sich verändert. Es reicht nicht mehr aus, Maßnahmen für die Cybersicherheit einzuführen. Organisationen brauchen auch Nachweise dafür, dass diese Maßnahmen wirken, wer für sie verantwortlich ist und was geschah, als jemand (oder etwas) auf ein kritisches System zugegriffen hat. Für Leitungsorgane kann die Verantwortung, nachzuweisen, dass Maßnahmen der Zugriffsverwaltung bestehen und wirken, inzwischen eine persönliche Haftung nach sich ziehen.

Diese Nachweise müssen außerdem mehr als nur Mitarbeiter abdecken. Dienstkonten, API-Schlüssel, Lieferanten und KI-Agenten können ebenfalls Zugriff auf kritische Systeme haben. Zu wissen, dass diese Identitäten existieren, worauf sie zugreifen können und ob dieser Zugriff noch gerechtfertigt ist, gehört inzwischen zum selben Problem.

Die fünf Cybersicherheitsverantwortlichen, die für diesen Bericht befragt wurden, haben sich diesem Problem aus unterschiedlichen Richtungen genähert. Sie diskutierten, welche Anforderung aus Artikel 21 der NIS2-Richtlinie sich am schwersten in die Praxis umsetzen lässt und wo Organisationen am stärksten exponiert bleiben. Am Ende kamen ihre Antworten immer wieder auf den Unterschied zurück, ob eine Organisation eine Maßnahme der Zugriffsverwaltung (oder eine andere Sicherheitsmaßnahme) nur hat oder nachweisen kann, dass sie wirkt.

Mitwirkende

Gabriel Dinu

Deputy Director, National Cyber Security Directorate of Romania
ENISA Management Board representative

Jane Frankland MBE

CEO and Founder of KnewStart

Ioannis Ntokos

IT Governance Risk & Compliance Expert (former FedEx, PwC, and Randstad)

Dr. Yiannis Pavlosoglou

Vice Governor, National Cybersecurity Authority of Greece

Alex Muntyan

CEO of Passwork

Hinweis: Die vier externen Mitwirkenden dieses Berichts haben als unabhängige Experten teilgenommen. Keiner von ihnen steht in einer geschäftlichen Beziehung zu Passwork oder empfiehlt dessen Produkte. Sie geben ihre eigene Meinung wieder, nicht die Positionen ihrer aktuellen oder früheren Arbeitgeber.

Der Test, an dem sich NIS2 in der Praxis misst

Zugriffsverwaltung unter NIS2 lässt sich auf eine grundlegende Frage zurückführen: 

Der Rest dieses Berichts wendet diese Frage auf die Personen, Lieferanten, Dienstkonten, API-Schlüssel und KI-Agenten an, die kritische Systeme erreichen können. Er fragt außerdem, ob die zurückbleibenden Nachweise ausreichen, um zu zeigen, was geschehen ist.

Artikel 21 verpflichtet wesentliche und wichtige Einrichtungen, Cybersicherheitsrisiken mit Maßnahmen zu steuern, die den Risiken entsprechen, denen sie ausgesetzt sind. Artikel 23 legt strenge, verbindliche Meldepflichten für wesentliche und wichtige Einrichtungen fest, die von einem erheblichen Cybersicherheitsvorfall betroffen sind. Diese Anforderungen gelten sowohl für wesentliche als auch für wichtige Einrichtungen, auch wenn die Aufsicht über diese Organisationen unterschiedlich ausgestaltet ist.

Leitungsorgane müssen die Maßnahmen zum Management von Cybersicherheitsrisiken genehmigen und ihre Umsetzung überwachen. Jeder Mitgliedstaat muss eine zuständige Behörde benennen, die die Richtlinie beaufsichtigt und durchsetzt.

NIS2 legt diese Verantwortung aus einem praktischen Grund auf das Leitungsorgan. Ganz gleich, wie ein Angreifer eindringt: Gestohlene oder missbrauchte Zugangsdaten tauchen meist irgendwo auf dem Weg auf. 

• Der Verizon 2026 Data Breach Investigations Report stellte in 39 % der analysierten Sicherheitsverletzungen einen Missbrauch von Zugangsdaten fest – ein größerer Anteil als bei jeder anderen Technik. 
• Der ENISA Threat Landscape 2026 analysierte 8.257 im Jahr 2025 erfasste Vorfälle. Demnach entfielen 77,8 % der Social-Engineering-Aktivitäten auf Phishing, das meist auf ein Passwort oder eine aktive Sitzung abzielte, während hinter sechs von zehn Vorfällen mit unbefugtem Zugriff die Ausnutzung von Schwachstellen stand. Bei 72,9 % der erfassten Vorfälle waren wesentliche Einrichtungen im Sinne von NIS2 das Ziel.

Ein Vorstand, der Cybersicherheitsmaßnahmen genehmigt, ohne zu fragen, wie der Zugriff kontrolliert wird, genehmigt einen Plan, in dem die am häufigsten ausgenutzte Schwachstelle fehlt.

Diese Entscheidung, ob beabsichtigt oder nicht, hat Konsequenzen. Bei wesentlichen Einrichtungen können Verstöße gegen Artikel 21 und Artikel 23 zu Geldbußen mit einem Höchstbetrag von mindestens 10 Millionen Euro oder 2 % des weltweiten Jahresumsatzes führen, je nachdem, welcher Betrag höher ist. 

Auch die Durchsetzung kommt in Bewegung. Die ursprüngliche Frist lief im Oktober 2024 ab, doch nur sehr wenige Länder haben sie eingehalten. Im Juli 2026 verklagte die Europäische Kommission Irland, Spanien, Frankreich und die Niederlande vor dem Gerichtshof der Europäischen Union, weil sie keine Maßnahmen zur vollständigen Umsetzung von NIS2 in nationales Recht mitgeteilt hatten.

Artikel 21 umfasst ein breites Spektrum an Cybersicherheitsmaßnahmen, und die praktischen Herausforderungen unterscheiden sich von Maßnahme zu Maßnahme. Auf die Frage, welche sich am schwersten in die Praxis umsetzen lässt, nannte jeder Experte einen anderen Punkt. 

• Pavlosoglou nannte MFA und verwies auf Altsysteme, die sie nicht unterstützen, technische Konten, die beim Einschalten nicht mehr funktionieren, und die Ausnahmen, die fast sofort beantragt werden.
• Für Dinu ist es die Sicherheit der Lieferkette, die seiner Ansicht nach sowohl für Organisationen schwer umzusetzen als auch für Aufsichtsbehörden schwer zu bewerten ist.
• Frankland nannte die Bewertung der Wirksamkeit von Cybersicherheitsmaßnahmen: Eine Maßnahme zu haben sei das eine, nachzuweisen, dass sie wirkt, etwas völlig anderes.
• Muntyan konzentrierte sich auf Zugriffskontrolle und die Verwaltung von Zugangsdaten, insbesondere darauf, ob eine Organisation zeigen kann, wer Zugriff hatte und was er damit getan hat.
• Ntokos wählte die Bewältigung von Sicherheitsvorfällen, weil nach einem Vorfall so viele Prozesse und Personen beteiligt sind.

Die Einhaltung dieser Maßnahmen erfordert zudem mehr als technische Kontrollen. Oft hängt sie von der Unternehmenskultur und den Menschen ab, die die Maßnahmen anwenden.

Dinu vergleicht Regulierung mit der Gurtpflicht. Menschen sollten sich anschnallen, weil der Gurt sie schützt, und nicht nur, weil das Gesetz es vorschreibt. Mit der Cybersicherheit sollte es sich seiner Ansicht nach genauso verhalten. In der Praxis betrachten Organisationen Sicherheit allzu oft als Kostenfaktor, bis eine Regulierung oder ein Vorfall sie zum Handeln zwingt.

Pavlosoglou nähert sich dem Kulturproblem aus einer anderen Richtung. Auf die Frage nach den Hindernissen für die Compliance verweist er darauf, ob Organisationen bereit sind offenzulegen, was bei einem Vorfall geschehen ist. 

Das CSIRTs-Netzwerk bietet nationalen Behörden in der gesamten EU die Möglichkeit, Informationen über Angriffe auszutauschen. So wird die Zusammenarbeit mit den Behörden Teil der Reaktion, statt eines Gesprächs, das erst beginnt, wenn die Durchsetzung kommt.

Kultur lässt sich schwerer ändern als eine Richtlinie. NIS2 schafft einen weiteren Hebel, indem die Richtlinie die Verantwortung für diese Cybersicherheitsmaßnahmen auf der Leitungsebene verankert.

Die Haftung hat die Gespräche im Vorstand verändert

Da das Leitungsorgan für die Genehmigung und Überwachung der NIS2-Umsetzung verantwortlich ist, stärkt das die Position des CISO – insbesondere dann, wenn Schwächen in der Zugriffsverwaltung zusätzliches Budget oder Änderungen in anderen Unternehmensbereichen erfordern.

Dinu hat die Wirkung aus erster Hand erlebt. Berater, mit denen er gesprochen hat, berichteten, dass die Geschäftsleitung wenig Interesse an Präsentationen zur Cybersicherheit zeigte, bis die Haftung zur Sprache kam. Dann, so sagte er, „hat sich die ganze Atmosphäre im Raum verändert“. Sobald Vorstandsmitglieder haftbar gemacht werden können, lässt sich ein Sicherheitsproblem viel schwerer als Angelegenheit des CISO abtun.

Muntyan sieht eine ähnliche Veränderung auf der Anbieterseite. Früher kam Sicherheit vielleicht einmal im Jahr auf die Tagesordnung des Vorstands. In den Gesprächen von Passwork mit Organisationen beobachtet er heute, dass sich die C-Level-Führungskräfte stärker einbringen, während solche Diskussionen früher bei IT-Managern und Architekten blieben.

Auch Ntokos sieht die Rechenschaftspflicht der Unternehmensleitung als positive Veränderung. Sobald das Cybersicherheitsrisiko zu einer geschäftlichen und finanziellen Verantwortung wird, so argumentiert er, kann die Führung es kaum noch vollständig dem Sicherheitsteam überlassen.

Pavlosoglou verweist auf die Umsetzung der NIS2-Richtlinie der EU in griechisches Recht, nach der der Chief Information Security Officer (CISO) ein interner Mitarbeiter sein muss, der an den Vorstand berichtet. Damit liegt die Aufgabe, Sachverhalte in die Sprache des Vorstands zu übersetzen, beim CISO. Als Beispiel nennt er eine Organisation, bei der nicht genügend Benutzeridentitäten mit aktivierter Multi-Faktor-Authentifizierung (MFA) abgedeckt sind. Dies, so argumentiert er, muss beim Vorstand als geschäftliches Risiko ankommen, mit Kosten und einem Plan, sonst wird nicht gehandelt.

Sanktionen und Haftung der Leitung

Verantwortlich, aber ohne Entscheidungsbefugnis

Jane Frankland MBE vertritt seit Jahren die Auffassung, dass CISOs die Verantwortung für Cyberrisiken tragen, ohne die Befugnis zu haben, sie zu verringern. Die Verantwortung für Sicherheit und Resilienz liegt beim CISO, das Patchen bei IT und Infrastruktur, und das Budget, um beides zu beheben, wiederum an anderer Stelle. Besteht das Risiko fort, muss sich trotzdem der CISO dafür verantworten.

Der Vorstand stand bisher auf der anderen Seite dieser Aufteilung, und dort zeigt sich dieselbe Gewohnheit.

Diese Veränderung hält Frankland für die wichtigste, und gleichzeitig ist sie ihr gegenüber am vorsichtigsten. Die Haftung besteht auf dem Papier. Ob sie dazu führt, dass Vorstandsmitglieder kritischere Fragen stellen, hängt von der Durchsetzung ab, und dafür sei es ihrer Aussage nach noch zu früh.

Frankland beschreibt das übergeordnete Ziel als „Cyber Survivability“ (Überlebensfähigkeit bei Cyberangriffen). Es geht darum, die Auswirkungen eines Vorfalls zu verringern, kritische Abläufe aufrechtzuerhalten und einen Weg zur Wiederherstellung offenzuhalten.

Für den Vorstand müssen die Nachweise mehr zeigen, als dass ihm ein Sicherheitsbericht übergeben wurde. Er muss das wesentliche Risiko verstehen, die Maßnahmen zu seiner Steuerung genehmigen und die nächsten Schritte überwachen.

MFA wird schwierig, sobald sie auf die Organisation trifft

Artikel 21 verpflichtet Organisationen, MFA einzusetzen, wo dies angemessen ist. Schwieriger ist es jedoch, sie in der gesamten Organisation zum Funktionieren zu bringen.

Pavlosoglou beschreibt, wie schnell sich die Ausnahmen häufen, sobald verpflichtende MFA eingeschaltet wird. In einem Beispiel aktiviert das IT-Team MFA am Montagmorgen. Um 10 Uhr desselben Tages beantragt das Büro des Direktors, ausgenommen zu werden. Gegen Nachmittag geht der erste Antrag ein, nicht personenbezogene technische Konten (Non-Personal Technical Accounts, NPTAs) auszunehmen. Da Benutzerkonten für Dienstidentitäten verwendet wurden (zum Beispiel für die Anbindung an Zahlungssysteme), bringt die Aktivierung von MFA den Dienst zum Erliegen.

Dinu sieht denselben Widerstand der Benutzer als Teil des Umsetzungsproblems. MFA verändert die Arbeitsweise der Menschen. Wer sie einführt, muss sich deshalb auch mit dem Gegenwind auseinandersetzen, der entsteht, wenn eine Sicherheitsmaßnahme einem vertrauten Ablauf einen weiteren Schritt hinzufügt.

Frankland warnt davor, die Formulierung „wo angemessen“ in der Richtlinie als Hintertür zu nutzen. Sie sollte ihrer Ansicht nach nicht als „wenn es passt“ ausgelegt werden. Die Stärke der Authentifizierung sollte sich an der Sensibilität des Assets und dem mit dem Zugriff verbundenen Risiko orientieren. Dass MFA eingesetzt wird, bedeutet nicht, dass jede Authentifizierungsmethode das gleiche Schutzniveau bietet. Für Zugriffe mit höherem Risiko plädiert sie für phishingresistente MFA wie FIDO2.

Ntokos argumentiert aus betrieblicher Sicht ähnlich. Organisationen brauchen zunächst eine Bestandsaufnahme ihrer Infrastruktur und ein Verständnis davon, wo kritische Daten liegen. Anschließend müssen sie unterschiedliche Arbeitsumgebungen berücksichtigen. Ein Mitarbeiter in der Fertigungshalle darf unter Umständen kein Mobiltelefon bei sich tragen. Ein Büromitarbeiter und ein Administrator haben unterschiedliche Anforderungen an den Zugriff.

Veraltete Technologie macht das noch schwieriger. Eine alte Anwendung unterstützt moderne MFA möglicherweise nicht nativ. Pavlosoglou warnt, dass Organisationen in ihren Richtlinien Grauzonen lassen können, um solche Systeme zu berücksichtigen, die Richtlinie genehmigen lassen und regelkonform erscheinen, ohne die zugrunde liegende Schwachstelle zu beheben.

Frankland kommt von der Designseite her zum gleichen Schluss. Die Frage lautet dann nicht mehr, wie man MFA an ein altes System anflanscht, sondern wie man verhindert, dass dieses System überhaupt allein mit einem einzigen Satz Zugangsdaten erreichbar ist.

Eine Möglichkeit besteht darin, die Authentifizierungskontrolle nach außen zu verlagern. Muntyan beschreibt, wie MFA auf der Ebene der Zugangsdatenverwaltung angesiedelt und genutzt wird, um den Zugriff auf Altanwendungen zu vermitteln. Die Anwendung selbst erhält dadurch nicht plötzlich eine moderne Authentifizierung, aber für den Weg zu ihren Zugangsdaten können strengere Kontrollen gelten.

Eine einzige Authentifizierungsmethode lässt sich nicht allen Benutzern und Systemen aufzwingen. Besser ist es zu wissen, wo eine stärkere Authentifizierung nötig ist, und einen vertretbaren Umgang mit Systemen zu haben, die diese nicht selbst bereitstellen können.

Nicht-menschliche Identitäten werden Teil des Zugriffsproblems

Zugriffsinventare beginnen traditionell bei den Mitarbeitern, doch das reicht nicht mehr aus. API-Schlüssel, Dienstkonten, Skripte und KI-Agenten können ebenfalls Berechtigungen in kritische Systeme hineintragen. Manche bleiben noch lange aktiv, nachdem der Grund für ihre Erstellung weggefallen ist.

Muntyan sieht ein weiteres Problem in der Art, wie Secrets gespeichert werden. Ist das freigegebene System umständlich, suchen sich Teams andere Orte für API-Schlüssel, Token und andere Zugangsdaten. Diese „Verstecke“ führen zu Secrets Sprawl (unkontrollierter Verbreitung von Secrets) und machen es schwerer zu wissen, welche Zugangsdaten existieren und wer sie verwenden kann.

Diese Asymmetrie bereitet Muntyan heute Sorgen. Passwörter sind von Kontrollen umgeben, die existieren, weil man davon ausgeht, dass Menschen Fehler machen, während Maschinenzugangsdaten kaum eine davon übernommen haben. Mit Blick auf die Zukunft erwartet er, dass KI-Agenten das Problem verschärfen, weil sie Zugangsdaten automatisch und ohne menschliches Zutun erstellen und verwenden können, während Prozesse zur Zugriffsüberprüfung auf Menschen ausgelegt wurden.

Pavlosoglou hält es für möglich, dass die Kosten des Token-Verbrauchs die unkontrollierte Nutzung von KI-Agenten letztlich bremsen. Er berichtet von Fällen aus dem Sommer, in denen CISOs in Organisationen mit strengen regulatorischen Vorgaben Mitarbeiter ausfindig machen mussten, die Agenten starteten, um Tipps zu Spielen der Fußball-Weltmeisterschaft zu bekommen.

Wenn diese Nutzung teurer wird, haben Organisationen einen weiteren Grund, nachzuverfolgen, welche Agenten laufen und wofür. Die Kosten sind allerdings ein grobes Instrument. Sie erfassen die Agenten, deren Rechnung jemand im Blick hat, nicht diejenigen, an deren Erstellung sich niemand mehr erinnert.

Frankland geht über die Authentifizierung hinaus. „Die Authentifizierung sagt uns, wer oder was handelt, aber sie sagt uns nicht, ob die Handlung vernünftig ist.“

Ein Agent könnte sich korrekt authentifizieren und innerhalb der ihm rechtmäßig erteilten Berechtigungen arbeiten und trotzdem eine Aktion ausführen, die die Organisation nicht wollen würde.

Ntokos sieht darin ein Problem des Identitätsmanagements, an das sich bestehende Systeme anpassen müssen. Organisationen müssen in der Lage sein, Agenten zu identifizieren, ihre Aktionen zu überwachen, ihren Handlungsspielraum einzuschränken und ihren Zugriff zu entziehen oder ablaufen zu lassen.

Die Verantwortung verschwindet nicht, nur weil der Akteur eine Software ist. Dinu argumentiert, dass der Einsatz eines Agenten die Verantwortung nicht auf die Software überträgt und dass sie bei der Person oder Organisation bleibt, der das System gehört oder die es verwaltet.

Zugriffsteams sollten aufhören, nicht-menschliche Identitäten als Ausnahmen zu behandeln. Sie gehören neben Mitarbeitern, Administratoren und Lieferanten ins Inventar.

Lieferantenzugriff braucht einen eigenen Lifecycle

Der Zugriff durch Dritte verschärft ein ähnliches Verantwortungsproblem. Pavlosoglou hat auf der Sicherheitsseite lange Vertragsverhandlungen geführt und entschuldigt sich nicht für die Zeit, die sie in Anspruch nehmen können. „Die Verhandlung hat zehn Monate gedauert“, sagte er. „Die Fachabteilung wollte wissen, wo der Vertrag bleibt. Aber solange wir uns nicht darauf geeinigt hatten, wie wir die Lieferanten in Bezug auf Freistellungsklauseln, Haftung und die weicheren, aber ebenso wichtigen KPIs behandeln, hatte es keinen Sinn, mit dem Return on Security Investment (ROSI) weiterzumachen, den der Dritte liefern würde.“

Dazu gehörte, ob und wann der Lieferant einen Sicherheitsvorfall melden muss, ob der Kunde das Recht hat, ihn zu auditieren, und wer das Audit bezahlt. Manche dieser Details können sich tief in Freistellungsklauseln oder den Bedingungen von Cyberversicherungen verbergen. Pavlosoglou bringt es so auf den Punkt: „Selbst einzelne Wörter und Kommas können einen großen Unterschied machen.“

Sein Rat: mit den Lieferanten beginnen, die Zugriff auf kritische Systeme haben, und prüfen, was bereits schriftlich festgehalten ist. NIS2 gibt Sicherheitsteams einen Grund, sich erneut an die Rechtsabteilung zu wenden und sicherzustellen, dass die Verträge den Zugriff dieser Lieferanten abdecken.

Dinu sieht dieselbe Schwierigkeit von der anderen Seite des Tisches. Die Sicherheit der Lieferkette ist die Maßnahme aus Artikel 21, nach der sich die Stakeholder des DNSC am häufigsten erkundigen, und die Fragen können grundlegend wirken: welche Lieferanten, welche Maßnahmen, von wem auferlegt. Er sieht darin ein Zeichen dafür, wie schwer sich die Anforderung bewerten lässt. Die Behörde steht vor ihrer eigenen Variante dieses Problems, wenn sie Regeln formuliert, die für mehr als ein Dutzend Sektoren und Einrichtungen jeder Größe passen müssen.

Frankland argumentiert, dass der Zugriff von Lieferanten zurechenbar, begrenzt und widerrufbar sein sollte. Sie ist außerdem skeptisch, wenn man sich zu stark auf Fragebögen verlässt. Ein ausgefüllter Fragebogen beweist nicht, dass die angegebenen Kontrollen tatsächlich greifen. Organisationen müssen außerdem über ihre direkten Lieferanten hinausblicken und verstehen, wo Viertparteien weiter unten in der Kette Zugriffe oder Abhängigkeiten einführen könnten.

Ntokos sagt, dass der Zugriff von Lieferanten während der gesamten Geschäftsbeziehung gesteuert werden muss, vom Onboarding bis zum Ausstieg. Der Umfang des Zugriffs sollte von der Arbeit abhängen, die der Lieferant erledigt, bei Bedarf mit getrenntem oder zeitlich begrenztem Zugriff.

Muntyan empfiehlt, Lieferanten keine dauerhaften Passwörter zu geben, ihre Aktivitäten zu protokollieren und die Zugangsdaten zu rotieren, wenn der Auftrag endet. Diese Kontrollen erzeugen außerdem etwas, das die Organisation später möglicherweise vorlegen muss: Nachweise dafür, dass der Zugriff des Lieferanten begrenzt war und entzogen wurde, als er nicht mehr benötigt wurde.

Nachweise müssen den Vorfall überstehen

NIS2 schreibt keine einheitliche Aufbewahrungsfrist für Zugriffsprotokolle vor. Die Experten räumten ein, dass das weit verbreitete Missverständnis besteht, Zugriffsprotokolle müssten 10 Monate lang aufbewahrt werden. Sie argumentierten jedoch, dass die Organisationen selbst eine angemessene Frist festlegen müssen, und zwar auf Grundlage der geltenden rechtlichen Anforderungen, der geschäftlichen Erfordernisse und ihrer Risikobewertung. Die technischen Umsetzungsleitlinien der ENISA sehen ebenfalls vor, die Aufbewahrungsfristen auf dieser Grundlage festzulegen.

Die Aufbewahrung ist nur ein Teil des Problems. Organisationen müssen außerdem entscheiden, welche Zugriffsaufzeichnungen relevant sind, diese schützen und sicherstellen, dass sie vorgelegt werden können, wenn ein Auditor oder ein Incident-Response-Team sie benötigt.

Zugriffsprotokolle werden in diesem Zusammenhang häufig diskutiert, doch Fachleute halten eine andere Frage für relevanter: ob man diesen Aufzeichnungen vertrauen und sie nutzen kann.

Pavlosoglou beschreibt den Fehlerfall aus Sicht der Aufsichtsbehörde. Nach NIS2 überwachen die zuständigen nationalen Behörden die Einhaltung der Vorgaben und sind in Griechenland verpflichtet, mitzuwirken, wenn eine betroffene Einrichtung während eines Vorfalls um Hilfe bittet. Der Zustand der Informationssysteme, den sie bei ihrer Ankunft vorfinden, entscheidet darüber, wie viel sie tun können.

Die Antwort sollte beim kritischen Dienst ansetzen, argumentiert er. Organisationen müssen festlegen, welche Aufzeichnungen nötig sind, um die Aktivitäten rund um diesen Dienst nachzuvollziehen, statt NIS2 als Anweisung zu verstehen, wahllos alles zu protokollieren.

Aus dieser Lage gibt es im Nachhinein kein Zurück. Wenn die Behörde vor Ort ist, hat die Organisation die Aufzeichnungen entweder oder nicht, und das Geld, das durch die ausgeschaltete Protokollierung gespart wurde, ist bereits um ein Vielfaches wieder ausgegeben.

Für Frankland gibt es ein weiteres Problem. Logs aufzubewahren nützt wenig, wenn sie verändert werden können oder wenn sich Aktivitäten nicht systemübergreifend rekonstruieren lassen.

Ntokos konzentriert sich darauf, wie diese Nachweise verwaltet werden. Organisationen brauchen Richtlinien zur Aufbewahrung und Protokollierung, geeignete Speicherorte, Zeitstempel, Synchronisierung und eine lückenlose Beweiskette (Chain of Custody). Bevor sie sich darum kümmern, wie schnell sich Nachweise abrufen lassen, müssen sie sicherstellen, dass diese ordnungsgemäß aufbewahrt wurden.

Auch Muntyan betont den Abruf. Wenn eine Aufsichtsbehörde oder ein Incident-Response-Team Nachweise anfordert, sollten Teams sie seiner Ansicht nach innerhalb von Minuten oder einer Stunde vorlegen können, statt tagelang Aufzeichnungen aus verschiedenen Systemen zusammenzutragen.

Compliance sollte Schwächen aufdecken, nicht verbergen

Eine perfekte Compliance-Bewertung kann weniger beruhigend sein, als sie aussieht.

Dinu verweist auf Cyber Fundamentals, den Selbstbewertungsansatz CyFun der belgischen Cybersicherheitsbehörde, bei dem sich Organisationen jedes Jahr selbst bewerten und wesentliche Einrichtungen einen Plan vorlegen, wie sie Abweichungen beheben wollen. Es wird nicht erwartet, dass jede Kontrolle die volle Punktzahl erreicht. Wäre das der Fall, wären die Aufsichtsbehörden nach seinen Worten „ziemlich besorgt“.

Dass Dinu unvollkommene Ergebnisse toleriert, hat damit zu tun, dass er beobachtet hat, was passiert, wenn Aufsichtsbehörden makellose verlangen.

Dinu zufolge kann ein Vorfall diese Haltung schnell ändern. Er hat erlebt, wie Organisationen Cybersicherheit nicht mehr als Compliance-Übung betrachteten, sondern das Risiko ernst nahmen, nachdem sie selbst angegriffen worden waren.

Muntyan sagt, Vorfälle seien in der Vergangenheit der Auslöser gewesen, damit Organisationen ihre Zugriffsverwaltung verbessern, doch das ändere sich. Unternehmenskunden fragen Lieferanten zunehmend, wie sie Zugangsdaten verwalten, bevor sie einen Vertrag unterschreiben. Für einen Lieferanten kommt diese Frage noch vor jeder Aufsichtsbehörde, und wer sie stellt, ist der Kunde.

Für Pavlosoglou können offengelegte Zugangsdaten einen persönlicheren Auslöser bilden. Er verweist auf den bekannten „Name and Shame“-Effekt: Ein Nachweis, dass jemand Ihre digitale Identität übernehmen kann, macht es viel schwerer, das Risiko abzutun.

Ntokos argumentiert, dass sich Verbesserungen am Risiko orientieren sollten, statt auf eine Compliance-Frist oder einen Vorfall zu warten. Auch Frankland würde früher ansetzen. Ihr Auslöser ist der Punkt, an dem die Zahl der Identitätssysteme und Zugangsdaten zu groß wird, um sie zuverlässig manuell zu verwalten. Wer auf einen Vorfall, ein Audit oder eine Compliance-Frist wartet, wartet, bis die Schwachstelle bereits zum Problem geworden ist.

Checkliste für die Zugriffsverwaltung nach NIS2

Was die fünf Experten zuerst angehen würden

Passwork, entwickelt für die Frage nach den Nachweisen

Passwork ist ein in der EU entwickelter Passwort- und Secrets-Manager für Organisationen, die nicht nur behaupten, sondern zeigen müssen, wie Zugangsdaten kontrolliert werden. 

Die Funktionen für die NIS2-Compliance umfassen rollenbasierte Zugriffskontrolle, anpassbare Tresortypen, systemweit erzwungene MFA, Integration mit AD/LDAP/SSO sowie Audit-Logs, die in ein SIEM exportiert werden können.

Passwork entscheidet nicht, welche Dienste kritisch sind oder wer Zugriff auf sie haben sollte. Diese Entscheidungen bleiben bei der Organisation. Passwork kann jedoch helfen, diese Entscheidungen in die Praxis umzusetzen und die Aufzeichnungen aufzubewahren, die nötig sind, um zu zeigen, was geschehen ist.

Häufig gestellte Fragen