Wenn eine kleinere Kommune, Einrichtung oder ein Unternehmen erstmals mit den Anforderungen der ungarischen MK-Verordnung 7/2024 (VI. 24.) in Berührung kommt, entsteht leicht der Eindruck, für die Einhaltung müsse eine vollständige Informationssicherheitsorganisation wie in einem Großunternehmen aufgebaut werden.
Schon die erste Anforderungsfamilie, das Programmmanagement, umfasst 23 Anforderungspunkte.
Damit stellt sich die Frage: Benötigt eine Organisation mit acht bis zehn Beschäftigten zwanzig getrennte Richtlinien und ebenso viele IT-Systeme?
Zum Glück nicht.
Die Verordnung bestimmt, was funktionieren muss – nicht, dass für jede einzelne Anforderung ein eigenes Dokument, eine eigene Software oder eine eigene Organisationseinheit geschaffen werden muss.
Das ist eines der wichtigsten Grundprinzipien unserer Reihe „NIS2 für kleine Organisationen“.
Was bedeutet Programmmanagement?
Der Begriff klingt zunächst nach Großunternehmen, doch der Gedanke dahinter ist einfach.
Eine Organisation muss wissen, was sie schützt, wovor sie es schützt, wer dafür verantwortlich ist, welche Probleme bestehen, was sie zu deren Behebung unternimmt und woran sie erkennt, dass ihre Maßnahmen tatsächlich wirken.
Die Anforderungen des Programmmanagements betreffen daher unter anderem die Informationssicherheitsrichtlinie, die Rolle des Informationssicherheitsbeauftragten (IBF), erforderliche Ressourcen, die Erfassung elektronischer Informationssysteme, Risiken, die Messung der Sicherheitsleistung, Kontrollen, Dienstleister sowie die kontinuierliche Überwachung. Der Risikomanagementrahmen der Verordnung verlangt außerdem die Dokumentation der Sicherheitsrollen, der Risikomanagementstrategie und der laufenden Wirksamkeitsprüfung von Schutzmaßnahmen. Rechtsquelle (Jogtár)
Es geht also in erster Linie um Steuerung und erst in zweiter Linie um Technologie.
Betrachten wir eine Organisation mit acht Beschäftigten
Nehmen wir ein einfaches Beispiel.
Es gibt acht Mitarbeitende, acht bis zehn Computer, ein NAS, einen Router oder eine Firewall, einen Internetanschluss, einen Cloud-E-Mail-Dienst, einige externe Dienste und einen externen Systemadministrator. Eine eigene IT-Abteilung oder ein Informationssicherheitsteam gibt es nicht. Auch die IBF-Aufgabe kann durch einen externen Dienstleister übernommen werden.
Für eine solche Umgebung ist es nicht realistisch, ein GRC-System auf Großunternehmensniveau aufzubauen. Die Sicherheit muss dennoch gesteuert werden.
Wir würden die Anforderungen des Programmmanagements in einer solchen Organisation zunächst um die folgenden sieben funktionsfähigen Elemente herum organisieren:
| Einfacher organisatorischer Baustein | Wofür nutzen wir ihn? |
|---|---|
| 1. Informationssicherheitsrichtlinie | Rollen, Verantwortlichkeiten und grundlegende Betriebsregeln |
| 2. Verzeichnis der EIR und Dienstleister | Überblick über Systeme und kritische Dienstleister |
| 3. Risikomanagement und Risikoverzeichnis | Überblick über die zu berücksichtigenden Bedrohungen |
| 4. Maßnahmenplan | festhalten, was bis wann durch wen behoben wird |
| 5. System- und Notfallvorsorgedokumentation | verstehen, wie die Umgebung arbeitet und was bei Ausfällen geschieht |
| 6. Jährlicher Sicherheits- und Prüfplan | Prüfungen, Schulungen und Tests im Voraus planen |
| 7. Regelmäßiger IBF-Bericht | der Leitung die Sicherheitslage transparent machen |
Das bedeutet selbstverständlich nicht, dass damit automatisch sämtliche Anforderungen der Verordnung „abgehakt“ sind. Vielmehr ordnen wir die vielen Einzelanforderungen zu einem System, das auch eine kleine Organisation betreiben kann.
Es braucht nicht für alles eine eigene Richtlinie
Das ist eines der häufigsten Missverständnisse.
Abschnitt 1.1 der MK-Verordnung 7/2024 formuliert beispielsweise detaillierte Anforderungen an die Informationssicherheitsrichtlinie: Sie muss Sicherheitsanforderungen und Schutzmaßnahmen umfassen, unter anderem Ziele, Rollen und Verantwortlichkeiten festlegen und von der Leitung genehmigt werden. Daraus folgt jedoch nicht, dass für jede weitere Anforderung eine neue zwanzigseitige Richtlinie verfasst werden muss. Bei einer kleinen Organisation kann eine gut strukturierte, einheitliche Informationssicherheitsrichtlinie (IBSZ), ergänzt durch einige kurze Verfahrensregeln und Verzeichnisse, wesentlich sinnvoller sein. Ziel ist nicht, die Anzahl der Dokumente zu erhöhen.
Ziel ist, dass das, was dokumentiert wurde, tatsächlich funktioniert.
Wissen wir überhaupt, was wir schützen?
Das ist eine der wichtigsten Fragen.
Die Informationssicherheit einer Organisation lässt sich nur schwer angemessen steuern, wenn kein klares Bild von den verwendeten elektronischen Informationssystemen besteht. Bei einer kleinen Kommune ist beispielsweise schon die Abgrenzung einzelner EIR nicht immer eindeutig.
Was gehört zusammen? Ist der Dateiserver ein eigenes System? Das NAS? E-Mail? Das Finanzsystem? Die Zutrittskontrolle? Der Cloud-Dienst?
Der Risikomanagementrahmen der Verordnung verlangt unter anderem die Dokumentation der geschäftlichen Zwecke, Funktionen, Vermögenswerte, technischen Grenzen, verarbeiteten Daten und Risiken der betroffenen Systeme.
Die erste praktische Aufgabe ist daher nicht unbedingt die Installation neuer Software.
Vielmehr sollten wir ein nutzbares Verzeichnis elektronischer Informationssysteme (EIR) erstellen.
In einer kleinen Organisation kann dafür bereits eine gut aufgebaute Tabelle vollkommen ausreichend sein.
Auch Probleme müssen erfasst werden
Im Zuge der Compliance-Arbeit werden wir fast sicher Lücken entdecken.
Das kann ein veraltetes Betriebssystem sein, eine unzureichende Datensicherung, zu viele Administratorrechte, fehlende Mehrfaktorauthentifizierung (MFA) oder ein nicht dokumentierter Zugriff durch Dienstleister. Das eigentliche Problem ist nicht, dass wir Schwachstellen finden. Es ist, dass niemand weiß, was anschließend mit ihnen geschieht.
Deshalb brauchen wir einen Maßnahmenplan.
Schon in einer einfachen Tabelle können wir festhalten:
Feststellung → erforderliche Maßnahme → Verantwortlicher → Frist → Status.
Damit wird Sicherheit von einer einmal jährlich hervorgeholten Richtlinie zu einem gesteuerten Prozess.
Wie messen wir Sicherheit in einer kleinen Organisation?
Eine interessante Anforderung des Programmmanagements betrifft die Messung der Sicherheitsleistung.
Gemäß der Verordnung muss die Organisation ein System zur Messung der Sicherheit ihrer elektronischen Informationssysteme schaffen, Leistungskennzahlen beobachten und regelmäßig darüber berichten.
Auf den ersten Blick erinnert das wieder an ein Dashboard eines Großunternehmens.
In einer Organisation mit acht Beschäftigten kann man aber schon mit fünf einfachen Kennzahlen beginnen.
Zum Beispiel:
Umsetzung kritischer Updates · fehlgeschlagene Datensicherungen · offene Sicherheitsmaßnahmen · überfällige Maßnahmen · Teilnahmequote bei Sicherheitsschulungen
Daraus kann vierteljährlich ein einseitiger IBF-Bericht erstellt werden.
Kontinuierliche Überwachung ≠ ständig auf einen Monitor schauen
Die Anforderung 1.23 sieht vor, dass die Organisation eine Strategie und ein Programm zur kontinuierlichen Überwachung entwickelt. Darin sind Kennzahlen, Prüfintervalle, Auswertungen, Reaktionsmaßnahmen und regelmäßige Berichte festzulegen.
Auch das muss eine kleine Organisation nicht übermäßig kompliziert gestalten.
„Kontinuierlich“ bedeutet in diesem Zusammenhang nicht zwangsläufig, dass rund um die Uhr jemand in einem Security Operations Center (SOC) vor einem Bildschirm sitzt.
Es kann auch einen im Voraus festgelegten Prüfzyklus bedeuten: bestimmte technische Prüfungen jeden Monat, vierteljährliche Bewertungen des Sicherheitsstatus, eine jährliche Gesamtüberprüfung und zusätzliche Prüfungen nach wesentlichen Änderungen oder Sicherheitsvorfällen.
Entscheidend sind Regelmäßigkeit und Nachweisbarkeit.
Und welche Software müssen wir dafür kaufen?
Die vielleicht wichtigste Antwort in diesem ersten Teil lautet:
keine – jedenfalls nicht allein deshalb, um diese Anforderungsfamilie zu erfüllen.
Wir können dafür auch Tabellen in LibreOffice Calc verwenden.
Wenn die Organisation dieser Lösung später entwächst, kann sie auf ein umfangreicheres System umsteigen.
Nicht umgekehrt.
Wir sollten kein komplexes System einführen, nur weil es existiert. Erst dann, wenn die tatsächlichen Abläufe der Organisation es rechtfertigen.
Was sieht der Auditor oder Prüfer des NKI?
Eine der wichtigsten Fragen der Compliance lautet:
Können wir nachweisen, dass das, was in unseren Richtlinien steht, tatsächlich umgesetzt wird?
Beim Programmmanagement kann eine gut organisierte Einrichtung dies unter anderem mit einer gültigen Informationssicherheitsrichtlinie (IBSZ), einer dokumentierten IBF-Funktion, einem EIR-Verzeichnis, einer Risikoanalyse, einem Maßnahmenplan, Prüfprotokollen, Schulungsnachweisen, Dienstleisterinformationen und regelmäßigen Sicherheitsberichten belegen.
Auch hier kommt es nicht auf die Menge der Dokumente an.
Entscheidend ist ihre Übereinstimmung.
Wird in einer Risikoanalyse ein Problem mit der Datensicherung festgestellt, muss es im Maßnahmenplan auftauchen. Wenn der Maßnahmenplan die Behebung als abgeschlossen ausweist, muss ein Nachweis vorliegen.
Behauptet die Organisation, ihre Datensicherungen vierteljährlich zu prüfen, sollte dokumentiert sein, dass diese Prüfungen tatsächlich stattgefunden haben. Dadurch wird ein Regelungssystem auditierbar.
Das Prinzip von NIS2 für kleine Organisationen: zunächst einfach
Die MK-Verordnung 7/2024 sieht keinen eigenen Anforderungskatalog für kleine Organisationen vor. Auch sie müssen die für sie geltenden Sicherheitsanforderungen ernst nehmen. Das bedeutet jedoch nicht, dass sie dieselben technischen und organisatorischen Lösungen einsetzen müssen wie ein Unternehmen mit mehreren Tausend Beschäftigten. Die Verordnung selbst baut auf Risikomanagement auf: Eine Organisation muss Risiken für ihre Systeme bewerten und behandeln sowie geeignete Schutzmaßnahmen festlegen. Rechtsquelle (Jogtár)
Eine kleine Organisation braucht nicht weniger Sicherheit. Sie braucht eine Sicherheit, die ihrer Größe und ihren Risiken entspricht.
Das ist ein großer Unterschied.
Jetzt seid Ihr dran
Die Reihe „NIS2 für kleine Organisationen“ soll keine einseitige Fachkommunikation sein.
Wir interessieren uns auch für die praktischen Erfahrungen von Systemadministratoren, Informationssicherheitsbeauftragten, Auditoren, IT-Fachkräften und betroffenen Organisationen.
Wie funktioniert das Programmmanagement bei Euch? Excel, LibreOffice, SharePoint, NAS, eine Eigenentwicklung oder ein spezielles System?
Gibt es eine einfache Lösung, die sich besonders bewährt hat?
Schreibt es in die Kommentare zum Social-Media-Beitrag über diesen Artikel. Nützliche Ideen und Erfahrungen werden wir auch in den nächsten Teilen aufgreifen. Am Ende der Reihe möchten wir auf dieser Grundlage den zusammenfassenden Leitfaden „NIS2 für kleine Organisationen – ein Praxisleitfaden“ erstellen.
Und warum beschäftigen wir uns bei CyberTeam damit?
Weil wir in der Praxis immer wieder feststellen, dass eine gute Informationssicherheitslösung nicht unbedingt die teuerste oder die komplizierteste ist.
Zuerst muss man verstehen, wie eine Organisation arbeitet, von welchen Systemen sie abhängt, welche Risiken sie hat und was sie tatsächlich braucht.
Erst danach sollte man über Technologie, neue Systeme oder zusätzliche Kosten sprechen.
Diesen Ansatz verfolgen wir auch bei der CyberTeam Kft.
Denn Cybersicherheit ist nur dann gut, wenn sie nicht bloß am Tag des Audits funktioniert.