Modellierung und IT-Grundschutz-Check: Vom Kompendium zum belastbaren Soll-Ist-Bild

Problem in der Praxis

In vielen Programmen wird die Modellierung als reine Zuordnungsübung missverstanden: Es entsteht eine lange Bausteinliste, die niemand mehr hinterfragt. Im Check werden Anforderungen dann ohne dokumentierte Begründung als nicht zutreffend abgetan, oder es wird pauschal "umgesetzt" vermerkt, ohne dass der wahre Stand erhoben wurde.

Ein zweites Muster ist der Check ohne belastbare Evidenz: Interviews werden geführt und Aussagen übernommen, aber keine Stichproben gezogen. Das Ergebnis sieht vollständig aus, hält aber keiner externen Prüfung stand. Beide Muster haben dieselbe Wurzel: Modellierung und Check werden als Formalie behandelt, nicht als Steuerungsinstrument. Der CISO trägt am Ende ein Sicherheitskonzept, dessen Aussagekraft er selbst nicht verteidigen kann.

CISO-Einordnung

Modellierung und Check stehen in der Mitte der Sicherheitskonzeption. Davor liegen der definierte Informationsverbund, die Strukturanalyse mit ihrer Gruppenbildung und die Schutzbedarfsfeststellung. Ein ungenauer Verbund oder eine zu grobe Gruppenbildung verzerrt jede spätere Aussage.

Die Modellierung ordnet die Bausteine des Kompendiums den Zielobjekten zu. Das Kompendium unterscheidet dabei prozessorientierte Schichten (etwa Management, Organisation, Konzeption und Betrieb) und systemorientierte Schichten (etwa Infrastruktur, Netze, IT-Systeme und Anwendungen). Diese Trennung zeigt, dass Sicherheit an Prozessen und Governance ebenso hängt wie an Geräten. Eine Modellierung, die fast nur Technik-Bausteine zuordnet, ist ein Warnsignal.

Der IT-Grundschutz-Check ist ein Soll-Ist-Vergleich: "Soll" sind die Anforderungen der modellierten Bausteine, "Ist" die gelebte Umsetzung. Die Methodik unterscheidet drei Anforderungsarten - Basis, Standard und Anforderungen bei erhöhtem Schutzbedarf -, wobei Basis und Standard zusammen den Stand der Technik abbilden und Grundlage einer Zertifizierung nach ISO 27001 auf Basis von IT-Grundschutz sind. Diese Abstufung ist eine Priorisierungshilfe.

Umsetzungsperspektive

Der Check arbeitet mit vier Umsetzungsstatus; deren saubere Anwendung entscheidet über die Aussagekraft des Konzepts:

• entbehrlich: Die Anforderung ist im konkreten Verbund nicht relevant. Bei Basis-Anforderungen ist dieser Status nicht zulässig, und jeder Eintrag braucht eine nachvollziehbare Begründung.
• ja: Die Anforderung ist vollständig, wirksam und angemessen umgesetzt - ein belegbarer Zustand, kein Wille.
• teilweise: Es existiert eine Umsetzung, die aber unvollständig oder noch nicht durchgängig wirksam ist - in reifenden Organisationen der häufigste Status.
• nein: Die Anforderung ist größtenteils nicht umgesetzt - kein Makel, sondern ein Auftrag für die Maßnahmenplanung.

Methodisch läuft der Check in drei Schritten ab: organisatorische Vorbereitung, der Soll-Ist-Vergleich aus Interviews und Stichproben sowie die Dokumentation mit Begründungen. Die Stichprobe wird am häufigsten ausgelassen und im Audit am härtesten geprüft; erst die Verbindung aus Aussage und Beleg macht ein "ja" verteidigungsfähig. Sinnvoll ist, Modellierung und Check tabellarisch zu führen.

Typische Fehler

1. Die Modellierung wird einmalig erstellt und bei Verbundänderungen nicht nachgezogen, sodass Check und Realität auseinanderlaufen.
2. "Entbehrlich" wird als bequeme Abkürzung genutzt, ohne Begründung und teils unzulässig bei Basis-Anforderungen.
3. Der Check stützt sich allein auf Interviews ohne Stichproben, sodass das Soll-Ist-Bild scheinbar gut, aber nicht belegbar ist.
4. "Teilweise" wird vermieden, weil es nach Schwäche aussieht, obwohl es die steuerungsrelevanteste Aussage wäre.
5. Prozess- und Governance-Schichten werden vernachlässigt, weil die Aufmerksamkeit auf technischen Zielobjekten liegt.

Risiken und Trade-offs

Eine zu feingranulare Modellierung erzeugt eine kaum pflegbare Menge an Zielobjekten; eine zu grobe Gruppenbildung verschleiert relevante Unterschiede im Schutzbedarf. Der CISO muss diese Granularität bewusst steuern. Beim Check besteht der Trade-off zwischen Geschwindigkeit und Tiefe; praktikabel ist ein risikoorientierter Mittelweg mit höherer Prüftiefe dort, wo Schutzbedarf und Kritikalität hoch sind.

Modellierung und Standard-Check decken den normalen Schutzbedarf gut ab. Bei hohem oder sehr hohem Schutzbedarf, nicht abbildbaren Komponenten oder ungewöhnlichen Einsatzszenarien ist ergänzend eine Risikoanalyse erforderlich; wer diesen Übergang ignoriert, erzeugt ein trügerisches Sicherheitsgefühl.

Entscheidungspunkte

• Welche Granularität der Zielobjekte ist fachlich nötig und organisatorisch noch pflegbar?
• Welche Prüftiefe und welcher Stichprobenumfang gelten je nach Schutzbedarf und Kritikalität?
• Ab welchem Befund löst der Check eine ergänzende Risikoanalyse aus?
• In welcher Taktung werden Modellierung und Check nach Verbundänderungen aktualisiert?

Praktische Empfehlungen

1. Behandeln Sie die Modellierung als lebendes Abbild des Verbunds und koppeln Sie ihre Pflege an das Änderungsmanagement.
2. Verlangen Sie zu jedem "entbehrlich" eine Begründung und prüfen Sie, dass kein Basis-Punkt so markiert ist.
3. Hinterlegen Sie zu jedem "ja" eine Evidenzquelle und nutzen Sie "teilweise" als Steuerungssignal mit terminierten Maßnahmen.
4. Definieren Sie vorab, wann ein Check-Ergebnis in eine Risikoanalyse überführt wird, und priorisieren Sie Basis- vor Standardanforderungen.

Relevante Normreferenzen

• BSI-Standard 200-2 (IT-Grundschutz-Methodik): Referenz für Modellierung und IT-Grundschutz-Check.
• BSI-Standard 200-3 (Risikoanalyse auf Basis von IT-Grundschutz): Referenz für den Übergang zur Risikoanalyse.
• IT-Grundschutz-Kompendium: Referenz für Bausteine, Anforderungsarten und Schichtenstruktur.
• ISO/IEC 27001:2022: Referenz für ISMS-Anforderungen und Zertifizierungskontext (löst die Fassung 2013 ab).