IT-Grundschutz nach BSI

IT-Grundschutz ist das Vorgehensmodell des Bundesamts für Sicherheit in der Informationstechnik für Informationssicherheit. Es beantwortet die Frage, die ISO 27001 bewusst offen lässt: nicht nur, dass Risiken behandelt werden müssen, sondern welche Maßnahmen für einen Windows-Client, einen Serverraum oder einen Outsourcing-Vertrag konkret angemessen sind.

Gedacht ist die Methodik für die öffentliche Verwaltung. Für die Bundesbehörden ist sie über den Umsetzungsplan Bund gesetzt, viele Länder und Kommunen haben sie in eigenen Leitlinien übernommen. In Unternehmen kommt sie fast immer über einen Kunden an: über Ausschreibungen der öffentlichen Hand, über Anforderungen an IT-Dienstleister von Behörden oder über den Betrieb kritischer Infrastruktur.

Der entscheidende Punkt vorweg: Ein IT-Grundschutz-Zertifikat gibt es nicht. Was das BSI ausstellt, heißt „ISO 27001-Zertifikat auf der Basis von IT-Grundschutz”. Auf dem Dokument steht die ISO-Norm, IT-Grundschutz bezeichnet den Weg dorthin und den Prüfmaßstab.

Was statt eines IT-Grundschutz-Zertifikats nachweisbar ist

IT-Grundschutz besteht aus Standards und einem Maßnahmenkatalog. Standards und Kataloge kann man anwenden, aber nicht zertifizieren — es fehlt die Anforderungsnorm, gegen die eine Konformitätsbewertung läuft. Diese Rolle übernimmt ISO 27001. Der Unterschied zwischen Anforderungsnorm und Leitfaden ist im Eintrag zur zertifizierbaren Norm beschrieben.

Drei Nachweise sind in der Praxis erreichbar:

Das ISO-27001-Zertifikat auf Basis von IT-Grundschutz. Es entsteht in einem eigenen Verfahren beim BSI. Geprüft wird durch einen vom BSI zertifizierten IT-Grundschutz-Auditor, der Auditbericht geht an das BSI, und das BSI stellt das Zertifikat aus. Es gilt drei Jahre, in den beiden Zwischenjahren finden Überwachungsaudits statt.

Testate für Basis- und Kern-Absicherung. Sie bestätigen einen definierten Zwischenstand und sind keine Zertifikate. Als Etappenziel taugen sie, als Nachweis in einer Ausschreibung meist nicht — dort wird üblicherweise ein Zertifikat verlangt, und die Vergabestelle unterscheidet die beiden Papiere.

Die reguläre ISO-27001-Zertifizierung durch eine akkreditierte Stelle. Sie ist der übliche Weg für Unternehmen ohne Behördenbezug und international besser verstanden. IT-Grundschutz kann dabei trotzdem als interne Methode dienen, ohne dass er im Zertifikat erscheint.

Die vier BSI-Standards und das Kompendium

Der Aufbau ist zweiteilig: Die BSI-Standards beschreiben das Vorgehen, das IT-Grundschutz-Kompendium liefert die Anforderungen.

Das Kompendium wird jährlich in einer neuen Edition veröffentlicht. Seine Bausteine sind in zehn Schichten sortiert: fünf prozessorientierte (ISMS, Organisation und Personal, Konzepte und Vorgehensweisen, Betrieb, Detektion und Reaktion) und fünf systemorientierte (Anwendungen, IT-Systeme, industrielle IT, Netze und Kommunikation, Infrastruktur).

Jeder Baustein unterscheidet drei Anforderungsstufen. Basis-Anforderungen sind verbindlich umzusetzen. Standard-Anforderungen decken den normalen Schutzbedarf ab und dürfen nur mit dokumentierter Begründung entfallen. Anforderungen bei erhöhtem Schutzbedarf sind Vorschläge für die Risikoanalyse und keine Pflicht.

Die drei Vorgehensweisen — und welche zum Zertifikat führt

BSI-Standard 200-2 kennt drei Einstiege. Die Wahl ist eine Weichenstellung, keine Geschmacksfrage.

Wer die Zertifizierung als Ziel hat, sollte nicht mit der Basis-Absicherung anfangen. Deren Ergebnis ist strukturell anders: Sie erfasst zwar alle Zielobjekte, aber ohne Schutzbedarfsfeststellung und ohne Risikoanalyse. Beides muss später vollständig nachgeholt werden. Die Kern-Absicherung ist der bessere Zwischenschritt, wenn Kapazität für den ganzen Verbund fehlt.

Der Ablauf: sechs Schritte bis zum Realisierungsplan

Die Standard-Absicherung folgt einer festen Reihenfolge, und jeder Schritt erzeugt ein Dokument, das der Auditor sehen will.

1. Strukturanalyse. Alle Zielobjekte werden erfasst — Geschäftsprozesse, Anwendungen, IT-Systeme, Räume, Netze — samt ihren Abhängigkeiten. Ohne einen Netzplan, der mit der Realität übereinstimmt, ist alles Folgende Fiktion.
2. Schutzbedarfsfeststellung. Je Zielobjekt wird der Schutzbedarf für Vertraulichkeit, Integrität und Verfügbarkeit in drei Stufen eingeschätzt: normal, hoch, sehr hoch. Der Bedarf vererbt sich vom Prozess auf die Anwendung und von dort auf das System — nach dem Maximumprinzip, korrigiert um Kumulations- und Verteilungseffekte.
3. Modellierung. Den Zielobjekten werden die passenden Bausteine des Kompendiums zugeordnet. Ergebnis ist die Liste der Anforderungen, die tatsächlich gelten.
4. IT-Grundschutz-Check. Ein Soll-Ist-Abgleich: Zu jeder Anforderung wird der Umsetzungsstatus festgehalten — entbehrlich, ja, teilweise oder nein — mit Begründung und Verantwortlichem.
5. Risikoanalyse nach 200-3. Verpflichtend für alles mit hohem oder sehr hohem Schutzbedarf, für Zielobjekte ohne passenden Baustein und für Einsatzszenarien, die das Kompendium nicht vorsieht.
6. Realisierungsplan. Die offenen Punkte werden priorisiert, terminiert und mit Budget hinterlegt.

Für wen sich der Weg lohnt und wann nicht

Er lohnt sich, wenn der Kunde ihn verlangt. Bei Ausschreibungen von Bundes- und vielen Landesbehörden ist das ISO-27001-Zertifikat auf Basis von IT-Grundschutz eine Zuschlagsvoraussetzung oder wird deutlich höher bewertet als ein reguläres ISO-27001-Zertifikat. Gleiches gilt für Betreiber kritischer Infrastruktur, wo IT-Grundschutz eine anerkannte Grundlage für die Nachweise nach KRITIS und branchenspezifischen Sicherheitsstandards ist.

Er lohnt sich außerdem für Organisationen, die keine eigene Sicherheitsexpertise aufbauen können. Das Kompendium nimmt die inhaltliche Arbeit ab: Statt zu diskutieren, welche Maßnahme für einen Datenbankserver angemessen ist, steht sie im Baustein.

Er lohnt sich nicht bei international ausgerichteten Kunden. Außerhalb Deutschlands ist IT-Grundschutz weitgehend unbekannt, der Zusatz auf dem Zertifikat erzeugt eher Rückfragen als Vertrauen. Er lohnt sich auch nicht für stark cloudbasierte Geschäftsmodelle — dort ist BSI C5 für den Anbieter und ein regulär zertifiziertes ISMS für den Nutzer der passendere Zuschnitt.

Der Weg zum Zertifikat

Der grundsätzliche Ablauf einer Zertifizierung gilt auch hier, weicht aber an drei Stellen ab.

Der Auditor wird vom BSI zertifiziert, nicht die Zertifizierungsstelle akkreditiert. Sie beauftragen eine natürliche Person aus der BSI-Liste, nicht eine Prüforganisation. Das ändert die Auswahllogik: Sie prüfen Referenzen und Verfügbarkeit einer Person, und diese Person darf Sie nicht zugleich beraten haben.

Die Referenzdokumente werden vorab eingereicht. Statt eines Handbuchs verlangt das Verfahren eine nummerierte Serie von Referenzdokumenten — von der Sicherheitsleitlinie über Strukturanalyse, Schutzbedarfsfeststellung, Modellierung, Ergebnis des IT-Grundschutz-Checks und Risikoanalyse bis zum Realisierungsplan. Diese Sichtung entspricht dem Stufe-1-Audit und entscheidet über die Auditreife.

Das BSI stellt aus, nicht der Auditor. Der Auditbericht geht an das BSI, das ihn prüft und über die Zertifikatserteilung entscheidet. Diese Prüfung braucht Zeit, die in Projektplänen regelmäßig fehlt — wer den Termin an ein Vertragsdatum gekoppelt hat, sollte großzügig puffern.

Danach greift der übliche Zyklus: Überwachungsaudits in den Jahren eins und zwei, Rezertifizierung im dritten Jahr. Wechselt zwischenzeitlich die Edition des Kompendiums, muss die Modellierung nachgezogen werden.

Woran Projekte scheitern

Die Strukturanalyse bildet den Sollzustand ab. Im Netzplan stehen die Systeme, die es geben sollte. Der Auditor findet in der Praxis den ungepatchten Testserver unter dem Schreibtisch, der seit zwei Jahren produktiv läuft. Eine unvollständige Strukturanalyse entwertet Schutzbedarf, Modellierung und Check in einem Zug und ist der häufigste Grund für eine Hauptabweichung in diesem Verfahren.

„Entbehrlich” ohne Begründung. Im IT-Grundschutz-Check ist der Status entbehrlich zulässig, aber er verlangt eine sachliche Begründung — warum die Anforderung im konkreten Fall nicht greift. „Nicht relevant” oder „wird anders gelöst” reicht nicht. Auditoren ziehen genau diese Zeilen als Stichprobe.

Der Schutzbedarf ist überall normal. Wenn kein einziges Zielobjekt hohen Schutzbedarf hat, entfällt die Risikoanalyse nach 200-3 — bequem, aber selten glaubwürdig. Der Auditor prüft die Vererbung rückwärts: Ein Geschäftsprozess mit hoher Verfügbarkeitsanforderung und ein Server mit normalem Schutzbedarf passen nicht zusammen.

Die Rolle des Informationssicherheitsbeauftragten ist besetzt, aber nicht ausgestattet. Der Informationssicherheitsbeauftragte ist der Systemadministrator mit zehn Prozent Zeitanteil. Das erzeugt zwei Feststellungen auf einmal: fehlende Ressourcen und fehlende Unabhängigkeit, weil er seinen eigenen Betrieb prüft.

Das Kompendium wird als Checkliste abgearbeitet. Die Anforderungen werden abgehakt, ohne die zugehörigen Prozesse zu etablieren. Im Audit fällt das auf, sobald der Auditor eine Auditspur verfolgt: Die Maßnahme existiert als Dokument, aber es gibt keine Aufzeichnung, dass jemand sie jemals angewendet hat.

Abgrenzung zu verwandten Normen und Regelwerken

Die NIS-2-Richtlinie und ihre deutsche Umsetzung verlangen keine bestimmte Methodik. IT-Grundschutz ist dort eine mögliche Grundlage, aber weder vorgeschrieben noch allein ausreichend — die Melde- und Geschäftsleitungspflichten stehen im Gesetz, nicht im Kompendium.