Informationssicherheits-Managementsysteme (ISMS) Praxis

Informationssicherheits-Managementsysteme (ISMS) Praxis

Werkzeuge

• Der Ablauf nach BSI-Standard 200-2 ist Verwaltungsarbeit: viele Objekte, viele Anforderungen, viele Statusangaben. Genau dafür gibt es Werkzeuge.

Verinice

• Das bekannteste Werkzeug im deutschsprachigen Raum, von der SerNet GmbH, Open Source und vom BSI lizenziert.
• Unterstützt IT-Grundschutz, ISO/IEC 27001, TISAX, NIS2, Notfallmanagement und Datenschutz.
• Die klassische Einzelplatzversion (Java-Anwendung für Windows, Linux, macOS, dazu der Server verinice.PRO) wird nur noch bis Ende 2026 verkauft und bis Ende 2027 unterstützt.
• Nachfolger ist die neue browserbasierte Generation verinice.veo, wahlweise als Cloud-Dienst oder als Installation im eigenen Rechenzentrum.
• Aufwand: Installation, Datenbank, Einarbeitung. Für eine Kursstunde zu viel.

Weitere kommerzielle Werkzeuge

• HiScout, SAVe, ibi systems iris und andere GRC-Werkzeuge.
• GRC (Governance, Risk and Compliance): Sammelbegriff für Werkzeuge, die Steuerung, Risiken und Regelkonformität gemeinsam verwalten.
• Unterschiede liegen in Berichtswesen, Mehrbenutzerbetrieb und Preis, nicht in der Methode.

Tabellenkalkulation

• Funktioniert und ist in kleinen Umgebungen der Normalfall.
• Vorteil: sofort verfügbar, jeder kann es bedienen.
• Nachteil: keine Verknüpfung zwischen Objekten und Bausteinen, keine Versionierung, keine Auswertung über mehrere Ebenen.
• Für einen einzelnen Dienst mit vier Objekten reicht es aus.

Unser Werkzeug für die Übung

• Wir nehmen keines der obigen Werkzeuge, sondern eine eigene Webseite, die genau den Ablauf abbildet — ohne Installation, ohne Datenbank, ohne Anmeldung.
• Aufruf: https://labs.xinux.net/it-grundschutz.html
• Alle Eingaben bleiben im Browser und sind nach dem Neuladen der Seite wieder weg. Am Ende steht ein CSV-Export.

Das Szenario

• Die kit GmbH betreibt eine kleine Online-Plattform mit 12 Mitarbeitern.
• Zur Plattform gehören vier Objekte:

Objekt	Typ	Was es ist
Webserver01	IT-System	Apache-Webserver mit Testanwendungen, öffentlich erreichbar
WAF	IT-System	NGINX mit ModSecurity und OWASP Core Rule Set, TLS-Endpunkt
Firewall	IT-System	OPNsense vor der Plattform, Admin-Zugriff nur intern
Webshop	Anwendung	die öffentliche Webanwendung für Bestellungen

• Ziel der Organisation: Verfügbarkeit und Sicherheit der Website sicherstellen.

Die Bedienung der Seite

• Oben stehen fünf Schaltflächen — das sind die fünf Schritte:
  • 1 Organisation
  • 2 Systeme & Anwendungen
  • 3 Bausteine zuordnen
  • 4 Maßnahmen bewerten
  • 5 Ergebnis
• Man kann jederzeit oben direkt auf einen Schritt klicken oder unten mit "Weiter →" und "← Zurück" blättern.
• "Beispiel laden" füllt alle fünf Schritte mit dem vollständig bearbeiteten Szenario.
• "Zurücksetzen" leert alles wieder.
• Empfehlung für den Ablauf: erst leer durchgehen und selbst ausfüllen, am Ende einmal "Beispiel laden" zum Vergleich.

Schritt 1 — Organisation

• Hier steht, für wen das Sicherheitskonzept gilt. Das ist der Geltungsbereich.
• Auszufüllende Felder:

Feld	Eintrag im Beispiel
Title	kit GmbH
Abbreviation	KIT
Organization	KIT
Tags	Demo, IT-Grundschutz
Number of employees	12
Bearbeiter	eigener Name
Scope	Kleine Online-Plattform mit einem Webdienst für Kunden. Ziel ist es, Verfügbarkeit und Sicherheit der Website sicherzustellen.

• Der Bearbeiter taucht später im Dateinamen der CSV-Datei auf.
• Das Feld "Scope" ist das wichtigste: es grenzt ab, was zum Konzept gehört und was nicht.
• In der Methode nach BSI-Standard 200-2 entspricht dieser Schritt der Festlegung des Informationsverbunds.

Schritt 2 — Systeme und Anwendungen

• Hier wird erfasst, was überhaupt betrieben wird. Das ist die Strukturanalyse.
• Die vier Objekte sind bereits angelegt. Jede Karte hat drei Felder:
  • Auswahlfeld für den Typ: IT-System oder Anwendung
  • Name
  • Beschreibung
• Alle drei Felder sind änderbar. Damit lässt sich statt des Beispiels auch eine eigene Umgebung bewerten.
• Die Unterscheidung IT-System und Anwendung ist keine Formsache: sie entscheidet, welche Bausteine im nächsten Schritt passen.
  • IT-System ist die Maschine — Server, Firewall.
  • Anwendung ist das, was darauf läuft und einen fachlichen Zweck hat — der Webshop.

Schritt 3 — Bausteine zuordnen

• Hier wird festgelegt, welche Anforderungen für welches Objekt gelten. Das ist die Modellierung.
• Links steht der Katalog mit fünf Bausteinen, rechts für jedes Objekt eine Ablagefläche.
• Bedienung: einen Baustein links mit der Maus anfassen, auf das Objekt rechts ziehen und loslassen. Ein zugeordneter Baustein lässt sich über das "×" wieder entfernen.
• Mehrere Bausteine pro Objekt sind ausdrücklich vorgesehen und der Normalfall.
• Die verfügbaren Bausteine:

Baustein	Wofür
SYS.1.1 Allgemeiner Server	Grundanforderungen an jeden Server: Patchen, Logging, Monitoring
SYS.1.3 Server unter Linux und Unix	Linux-Besonderheiten: Rechte, sudo, SSH
APP.3.2 Webserver	Apache, NGINX, IIS: TLS, Module, Protokollierung
APP.3.1 Webanwendungen	die Anwendung selbst: Eingaben, Sessions, Tests
NET.3.2 Firewall	Regelwerk, Administration, Protokollierung der Firewall

• Die Zuordnung im Beispiel:

Objekt	Bausteine
Webserver01	SYS.1.1, SYS.1.3, APP.3.2
WAF	SYS.1.1, SYS.1.3, APP.3.2
Firewall	NET.3.2
Webshop	APP.3.1

• Begründung der Zuordnung:
  • Webserver01 ist ein Server (SYS.1.1), er läuft unter Linux (SYS.1.3) und er ist ein Webserver (APP.3.2) — drei Bausteine, weil drei Eigenschaften zutreffen.
  • Die WAF bekommt dieselben drei: sie ist ebenfalls ein Linux-Server mit einem Webserver-Dienst, auch wenn sie keine eigenen Inhalte ausliefert.
  • Die Firewall ist eine Appliance und bekommt nur NET.3.2.
  • Der Webshop ist kein Server, sondern eine Anwendung — nur APP.3.1.
• Das ist der eigentliche Kern des IT-Grundschutzes: die Frage "was müssen wir hier tun" ist mit der Zuordnung beantwortet, ohne dass jemand selbst eine Risikoanalyse rechnen musste.

Schritt 4 — Maßnahmen bewerten

• Hier wird für jede einzelne Anforderung festgehalten, ob sie umgesetzt ist. Das ist der IT-Grundschutz-Check, ein Soll-Ist-Vergleich.
• Die Seite listet jedes Objekt mit seinen Bausteinen und je Baustein die Maßnahmen auf.
• Jede Maßnahme hat eine Stufe:
  • BASIC — Basis-Anforderung, muss in jedem Fall umgesetzt sein.
  • STANDARD — Standard-Anforderung, Regelfall bei normalem Schutzbedarf.
• Je Maßnahme wird eine Ampel gesetzt:
  • erfüllt
  • teilweise
  • nicht erfüllt
  • unbewertet (der Ausgangszustand)
• Darunter steht ein Notizfeld für die Begründung. Das Feld ist der wichtigste Teil der Übung: eine Ampel ohne Begründung ist im Audit wertlos.
• Beispiele für brauchbare Notizen aus dem Beispieldatensatz:
  • "nftables konfiguriert: nur Ports 22, 80, 443 offen."
  • "Nur SSH mit Schlüssel-Authentisierung, Root-Login deaktiviert."
  • "Ausgabe-Escaping vorhanden, Content-Security-Policy noch nicht konfiguriert."
• Die Maßnahmen je Baustein:

Baustein	Maßnahmen
SYS.1.1	Geeignete Aufstellung; Benutzerauthentisierung an Servern; Deaktivierung nicht benötigter Dienste; Einsatz von Virenschutz-Programmen; Protokollierung; Einrichtung lokaler Paketfilter
SYS.1.3	Sorgfältige Vergabe von IDs; kein automatisches Einbinden von Wechselaufwerken; Verwaltung von Benutzern und Gruppen; verschlüsselter Zugriff über Secure Shell
APP.3.2	Absicherung der Webserver-Software; Konfiguration der Protokolle; Trennung von Webinhalten und Betriebssystem; Protokollierung von Webserver-Ereignissen; Minimierung von Modulen und Erweiterungen; Schutz vor bekannten Schwachstellen
APP.3.1	Eingabevalidierung; Session-Management; Schutz vor Cross-Site-Scripting; Absicherung der Zahlungsabwicklung; regelmäßige Sicherheitstests
NET.3.2	Regelbasierte Filterung; geregelte Administration; Protokollierung; Patchmanagement; regelmäßige Konfigurationsprüfung

• Hier wird sichtbar, dass die Anforderungen nichts Fremdes sind: das ist die Liste dessen, was wir im Kurs ohnehin konfiguriert haben — nur mit einer Kennung davor.
• Die Schutzbedarfsfeststellung ist in der Übung nicht enthalten. Wir arbeiten durchgehend mit normalem Schutzbedarf, damit die Basis- und Standard-Anforderungen ausreichen.

Schritt 5 — Ergebnis

• Für jedes Objekt erscheint eine Karte mit einer Gesamtampel und der Zählung der Bewertungen.
• Die Gesamtampel eines Objekts ergibt sich so:
  • kritisch, sobald eine einzige Maßnahme auf "nicht erfüllt" steht
  • teilweise, wenn es "teilweise" oder noch unbewertete Maßnahmen gibt
  • erfüllt, wenn alle Maßnahmen erfüllt sind
• Ein einziger roter Punkt reißt also das ganze Objekt auf Rot. Das ist beabsichtigt und entspricht der Praxis.
• Darunter steht die Tabelle der offenen Punkte.
• Über "CSV exportieren" wird die Datei heruntergeladen.
  • Dateiname: grundschutz_<Bearbeiter>_<Datum>.csv
  • Spalten: Organisation; Objekt; Baustein; Massnahme; Level; Status; Notiz
  • Trennzeichen ist das Semikolon, die Datei lässt sich direkt in einer Tabellenkalkulation öffnen.

Die offenen Punkte im Beispiel

• Im vorbereiteten Beispiel bleiben genau diese Punkte offen:

Objekt	Maßnahme	Status	Grund
Firewall	Regelmäßige Konfigurationsprüfung	nicht erfüllt	Review der Firewall-Regeln ist nicht terminiert
Webshop	Regelmäßige Sicherheitstests	nicht erfüllt	letzter Penetrationstest liegt über 18 Monate zurück
Firewall	Protokollierung	teilweise	Logs werden gesammelt, aber nicht ausgewertet
WAF	Schutz vor bekannten Schwachstellen	teilweise	OWASP Core Rule Set wird unregelmäßig aktualisiert
Webshop	Schutz vor Cross-Site-Scripting	teilweise	keine Content-Security-Policy konfiguriert
Webserver01	Einsatz von Virenschutz-Programmen	teilweise	ClamAV vorhanden, ergänzt durch IDS auf Netzebene

• Keiner dieser Punkte ist exotisch. Es sind die Dinge, die im Tagesgeschäft liegen bleiben, weil sie niemandem zugeteilt sind.

Was mit der CSV-Datei passiert

• Die Datei ist keine Ablage, sondern eine Aufgabenliste.
• Aus der Bewertung wird ein Realisierungsplan, indem drei Spalten ergänzt werden:
  • Verantwortlicher
  • Termin
  • Aufwand
• Erst damit ist die Arbeit fertig. Eine Bewertung ohne Namen und Datum verändert nichts.

Wem man das Ergebnis vorlegt

• Der eigenen Geschäftsleitung: die Liste der roten Punkte ist die Begründung für Budget.
• Dem BSI: als Nachweis nach § 39 BSIG, sofern man Betreiber einer kritischen Anlage ist.
• Dem Auditor: als Grundlage der Zertifizierung.
• Kunden und Ausschreibungsstellen: als Antwort auf Lieferantenfragebögen.
• Der Versicherung: Cyber-Policen fragen den Umsetzungsstand ab, im Schadensfall wird geprüft, ob die Angaben zutrafen.
• Sich selbst nach einem Vorfall: eine dokumentierte, terminierte Schwachstelle ist etwas anderes als eine übersehene.

Aufgabe für die Teilnehmer

• Wir setzen die Seite zurück und legen eine eigene Organisation an.
• Wir ersetzen in Schritt 2 die Objekte durch die Systeme aus unserer eigenen Kursumgebung.
• Wir ordnen die passenden Bausteine zu und begründen die Zuordnung.
• Wir bewerten die Maßnahmen ehrlich — mit dem, was wir im Kurs tatsächlich konfiguriert haben.
• Wir exportieren die CSV-Datei und benennen zu jedem roten und gelben Punkt einen Verantwortlichen und einen Termin.