NIS2 und Unternehmensarchitektur: Systeme, Abhängigkeiten und Anbieter dokumentieren

Was NIS2 von wesentlichen und wichtigen Einrichtungen verlangt

Die Richtlinie (EU) 2022/2555, kurz NIS2, erfasst weit mehr Einrichtungen als die Richtlinie, die sie abgelöst hat. Sie gilt für wesentliche und wichtige Einrichtungen in Sektoren wie Energie, Verkehr, Bankwesen, Finanzmarktinfrastrukturen, Gesundheit, digitale Infrastruktur und öffentliche Verwaltung. Die Mitgliedstaaten mussten sie bis zum 17. Oktober 2024 umsetzen.

Die betroffenen Einrichtungen ergreifen geeignete und verhältnismäßige technische, operative und organisatorische Maßnahmen, um die Risiken für ihre Netz- und Informationssysteme zu beherrschen. Sie behandeln die Sicherheit ihrer Lieferkette und melden erhebliche Sicherheitsvorfälle innerhalb festgelegter Fristen. Ob eine Einrichtung erfasst ist und welche Pflichten genau gelten, klären Sie mit qualifizierter Rechtsberatung.

Für ein Finanzunternehmen, das als wesentliche oder wichtige Einrichtung eingestuft ist, gilt DORA als sektorspezifischer Rechtsakt im Sinne von Artikel 4 NIS2, wie Artikel 1 Absatz 2 DORA es vorsieht. IKT-Risikomanagement und Meldung von Vorfällen folgen dann DORA, in dem von diesem Artikel vorgesehenen Umfang.

Eine Vorfrage: die eigenen Systeme und ihre Abhängigkeiten kennen

Risikomanagement, Sicherheit der Lieferkette und Behandlung von Vorfällen haben eine gemeinsame Voraussetzung. Das Risiko eines Systems, das im Inventar fehlt, lässt sich nicht bewerten. Ein Dienstleister lässt sich nur dann bis zu den Diensten verfolgen, die er unterstützt, wenn diese Verbindung dokumentiert ist. Der Umfang eines Vorfalls hängt davon ab, was auf der betroffenen Komponente aufbaut.

Dieses Wissen ist oft vorhanden, aber verstreut: eine CMDB, die abgedriftet ist, Netzpläne in einem Wiki, Anbieterlisten im Einkauf, eine Kritikalitätsbewertung in einer Präsentation. Das Architektur-Repository verbindet diese Elemente: Geschäftsdienste, Anwendungen, Technologien, Abhängigkeiten und Anbieter, jeweils mit ihrer verantwortlichen Person.

• Risikomanagement setzt ein Inventar der Netz- und Informationssysteme voraus.
• Die Sicherheit der Lieferkette setzt voraus, dass jeder Dienst mit seinen Dienstleistern verbunden ist.
• Die Behandlung eines Vorfalls setzt voraus, dass bekannt ist, was von der betroffenen Komponente abhängt.

Systeme, Dienste und Ausbreitung

Ob Maßnahmen verhältnismäßig sind, bemisst sich daran, was jedes System unterstützt. Eine Liste von Assets zeigt nicht, welcher Dienst ausfällt, wenn ein System ausfällt; ein Abhängigkeitsmodell zeigt es.

In ArchiLU trägt jede Anwendung ihre verantwortliche Person, ihre Kritikalität, ihren Lebenszyklus und ihren Anbieter. Sie ist mit Fähigkeiten, Prozessen, Schnittstellen und Technologien verbunden. Die 360-Ansicht einer Anwendung zeigt ihre Datenflüsse, ihre Schnittstellen, die Prozesse, denen sie dient, und die Fähigkeiten, die sie realisiert. Entscheidungen zur Risikobehandlung bleiben bei Sicherheit und Risikomanagement.

• Jede Anwendung mit ihrer verantwortlichen Person, ihrer Kritikalität und ihren Technologien.
• Die Prozesse und Fähigkeiten, denen sie dient.
• Die Schnittstellen, ihr Protokoll und die übertragenen Daten.
• Die Technologien und ihr Supportende, bekannt oder unbekannt.

Anbieter und Lieferkette

NIS2 verlangt, die Sicherheit der Lieferkette zu berücksichtigen, einschließlich der Beziehungen zu unmittelbaren Anbietern und Diensteanbietern. Diese Exposition wächst Vertrag für Vertrag, und jeder Vertrag war bei seiner Unterzeichnung vernünftig.

In ArchiLU verbindet die Kette Funktionen mit Anwendungen, dann mit IKT-Diensten, Anbietern und Verträgen. Die Expositionsanalyse beginnt bei einem Dienstleister, führt zu den Funktionen, die von ihm abhängen, und weist auf Konzentration hin. Es ist dieselbe Kette, die für DORA gepflegt wird. Die Sicherheitsbewertung eines Anbieters und die Vertragsposition bleiben Sache der Einrichtung.

Behandlung von Vorfällen: den Umfang eingrenzen

Nach einem Vorfall muss schnell feststehen, welche Dienste betroffen sind, wovon sie abhängen und wer informiert werden muss. Diese Eingrenzung dauert oft länger als die technische Behebung, besonders wenn die Pläne verstreut sind.

Eine aktuelle Architektur beschleunigt sie: von der betroffenen Komponente zu den Prozessen und Funktionen, die sie unterstützt, dann zu den Technologien und Anbietern, von denen sie abhängt. Jedes Objekt nennt seine verantwortliche Person. ArchiLU erkennt keine Vorfälle und übernimmt nicht die Reaktion darauf; diese Aufgaben liegen bei den Sicherheitswerkzeugen und -teams, denen die Abhängigkeitskarte Informationen liefert.

Hosting und Zugriffe

Eine Karte der Systeme, die wesentliche Dienste unterstützen, zeigt, wo die Organisation am stärksten exponiert ist. In ArchiLU hat jede Organisation ihre eigene Instanz, gehostet in der Europäischen Union; eine Bereitstellung bei Ihnen ist optional nach Angebot möglich.

Die Zugriffe folgen den Berechtigungen jeder Person. Ein Prüfer kommt über seinen Auftrag herein und liest die Kette nur lesend, begrenzt auf seinen Umfang und seinen Zeitraum. Der Prüfpfad ist verkettet, überprüfbar und vom Administrator exportierbar.