Modulare Sicherheitskonzepte : Best Practices zur standardkonformen Modularisierung von IT-Sicherheitskonzepten auf der Basis von IT-Grundschutz

Von Julius Rakow, Hussein Baydoun und Tobias Goldschmidt, Berlin

Viele Unternehmen und Behörden gestalten und dokumentieren ihre Informationssicherheit mit dem IT-Grundschutz im Rahmen eines Informationssicherheitsmanagementsystems (ISMS). Die Absicherung wird für einen Geltungsbereich (Informationsverbund) in einem IT-Sicherheitskonzept dokumentiert. Zusätzlich werden relevante Zielobjekte (Prozesse, Anwendungen, IT-Systeme, Netze, Räume und Gebäude) aufgelistet und jeweils mit einem Schutzbedarf hinsichtlich Vertraulichkeit, Integrität und Verfügbarkeit versehen. Zur Absicherung bildet man die Zielobjekte in der Modellierung mit standardisierten IT-Grundschutz-Bausteinen ab – die Umsetzung der darin enthaltenen IT-Sicherheitsanforderungen wird im Rahmen eines IT-Grundschutz-Checks erfasst. Abschließend werden weitere Risiken identifiziert, eingeschätzt, bewertet und behandelt.

Unabhängig von der Größe von Informationsverbünden benötigt man dazu Ansprechpartner aus verschiedenen Bereichen, wie IT-Betrieb, Fachabteilungen, Personalwesen und Gebäudemanagement. Für die Aktualisierung des IT-Sicherheitskonzepts, zum Beispiel im Rahmen einer ISO-27001-Zertifizierung auf der Basis von IT-Grundschutz, ist die aufwendige Koordination und Synchronisation aller Ansprechpartner erforderlich.

Bei großen Informationsverbünden ist diese zentrale Pflege komplex und aufwendig – eine Aufteilung des IT-Sicherheitskonzepts in einzelne Teilinformationsverbünde ist zielführender. Dieser Artikel stellt eine Methodik vor, welche die Autoren für einen sehr großen Informationsverbund seit mehreren Jahren erfolgreich umsetzen.

Praxisbeispiel:

Zur Erläuterung der Modularisierung möge ein beispielhafter Informationsverbund für ein Buchungssystem dienen (Abb. 1): Es besteht aus einem Backend, das auf einem virtuellen Server läuft und auf eine Datenbank zugreift. Der Server ist in einem Hypervisor virtualisiert, der auf einem Host läuft. Die Datenbank ist Teil eines Clusters und läuft auf einem weiteren virtuellen Server, der mit dem ersten gruppiert ist. Somit werden die folgenden Zielobjekte erfasst:

• A01 Backend (Anwendung)
• A02 Datenbank (Anwendung)
• A03 DB-Cluster (Anwendung)
• A04 Hypervisor (Anwendung)
• S01 Virt-Server (IT-System)
• S02 Host-Server (IT-System)

Die Verantwortlichkeiten für den Betrieb sind dabei getrennt: Der Anwendungsverantwortliche administriert das Buchungssystem, der IT-Betrieb die Datenbanken – die Server werden jeweils von einem Team administriert.

Schrittweise Modularisierung

Das vormals gemeinsame IT-Sicherheitskonzept für den Beispielverbund (Abb. 2a) wird nach und nach aufgeteilt: Als erstes werden einzelne Fachanwendungen, im Beispiel das Buchungssystem (BU), aus dem zentralen IT-Sicherheitskonzept herausgelöst. Fachunabhängige Anwendungen und zentrale Themen der IT-Landschaft verbleiben beim IT-Betrieb im zentralen IT-Sicherheitskonzept. Es ergibt sich eine sternförmige Struktur (Abb. 2b).

Mit zunehmender Größe des Informationsverbunds wird jedoch auch dieses IT-Konzept unhandlich, sodass man es weiter aufteilen sollte: zum Beispiel in ein IT-Sicherheitskonzept für die Datenbankbereitstellung (DB) und eines für die Serverbereitstellung (SB – vgl. Abb. 2c). Jedes Team kann dabei seine IT-Sicherheitskonzepte weitestgehend unabhängig voneinander pflegen und der Synchronisationsbedarf entfällt größtenteils.

Die Abgrenzung der Konzepte ist hierfür ein kritischer Schritt: Überschneidungen führen zu einer doppelten Betrachtung von Zielobjekten – mit entsprechend erhöhtem Aufwand. Lücken in der Betrachtung führen zu einer unvollständigen Absicherung – es ist essenziell, dass jedes Zielobjekt in einem IT-Sicherheitskonzept betrachtet wird. Bei der Modularisierung sollte man weitgehend der bestehenden organisatorischen Struktur folgen.

Beziehungen zwischen IT-Sicherheitskonzepten

Die Teilinformationsverbünde werden stringent durch die eindeutige Betrachtung relevanter und nicht-relevanter Bereiche abgegrenzt, sind aber nicht unabhängig voneinander: Im Beispiel benötigt das Buchungssystem eine Datenbank aus der Datenbankbereitstellung und beide benötigen zentral administrierte Server.

In jedem IT-Sicherheitskonzept werden nur die selbst administrierten Zielobjekte vollständig betrachtet. Genutzte Zielobjekte aus anderen IT-Sicherheitskonzepten lassen sich zum besseren Verständnis zusätzlich aufnehmen: Für sie muss eindeutig sein, welches Zielobjekt man in einem anderen IT-Sicherheitskonzept referenziert. Das verweisende Zielobjekt wird „Nutzer“ genannt, das referenzierte „Anbieter“.

Im Praxisbeispiel nutzt das Buchungssystem eine zentral bereitgestellte Datenbank – Daher wird ein Zielobjekt BU A02 Datenbank erstellt, das auf die Anwendung DB A01 Datenbank verweist. Die Beziehungen beim Beispielsystem zeigt Abbildung 3.

Als zusätzliche Zielobjekte sollten nur direkt genutzte Zielobjekte angelegt werden – dahinterliegende, indirekt genutzte Zielobjekte sollte man nicht aufführen, um Redundanzen zu vermeiden.

Im Praxisbeispiel wird daher nur der virtuelle Server BU S01 Anwendungsserver betrachtet, der auf das analoge Zielobjekt SB S02 Virt-Server verweist – Hypervisor und Host nutzt das Buchungssystem nur indirekt, weswegen sie nicht referenziert werden. Benötigt man, beispielsweise in einem Audit, weiterführende Informationen, sind diese im IT-Sicherheitskonzept der Serverbereitstellung einzusehen; somit entsteht keine Lücke in der Betrachtung.

Schutzbedarf und Schutzniveau

Werden IT-Sicherheitskonzepte unabhängig voneinander erstellt, dann ist auch der Schutzbedarf für jedes IT-Sicherheitskonzept separat festzulegen. Allerdings kann es hierbei zu Lücken in der Betrachtung kommen: Weist im Beispiel das Buchungssystem einen hohen Schutzbedarf auf, während der Datenbankcluster im entsprechenden IT-Sicherheitskonzept nur mit normalem Schutzbedarf abgesichert wird, entsteht eine Lücke.

Um solche Lücken zu vermeiden, ist bei jedem Verweis auf den Schutzbedarf zu achten: Ein Zielobjekt darf nicht auf Zielobjekte mit höherem Schutzbedarf verweisen! Im Zweifel gilt der höhere Schutzbedarf und dieser muss dann auch im anbietenden IT-Sicherheitskonzept umgesetzt, also etwa der Datenbankcluster für hohen Schutzbedarf ausgelegt werden. Falls das nicht möglich ist, ist die Lücke in der Absicherung beim nutzenden IT-Sicherheitskonzept in einer Risikoanalyse zu betrachten.

Absicherung mit Modellierung, IT-Grundschutz-Check und Risikoanalyse

Die Modularisierung führt nur dann zu weniger Aufwand, wenn man Zielobjekte aus anderen Bereichen nicht doppelt behandelt: Nur Zielobjekte, die man selbst administriert, müssen im eigenen IT-Sicherheitskonzept abgesichert werden. Für Verweise auf andere Konzepte genügt die Betrachtung von relevanten IT-Grundschutz-Bausteinen und Risiken im referenzierten IT-Sicherheitskonzept – der Nutzer muss diese nicht erneut betrachten.

Für die Datenbank werden etwa der IT-Grundschutz-Baustein APP.4.3 Relationale Datenbanken sowie die Risiken bei der Datenbankbereitstellung betrachtet, nicht aber beim Buchungssystem. Dadurch sind diese nicht für jedes nutzende IT-Sicherheitskonzept erneut zu behandeln. Eine erneute Modellierung des Bausteins auf Nutzerseite würde nicht nur erhöhten Aufwand durch die doppelte Betrachtung von IT-Sicherheitsanforderungen bedeuten, oft liegen entsprechende Informationen zur Dokumentation oder Umsetzung der IT-Sicherheitsanforderungen dort auch gar nicht vor.

Je nach Organisation kann es allerdings vorkommen, dass Teile von IT-Grundschutz-Bausteinen von anderen Organisationseinheiten umgesetzt werden: Beispielsweise wird die IT-Sicherheitsanforderung APP.4.3.A19 Schutz vor schädlichen Datenbank-Skripten aus dem Baustein APP.4.3 Relationale Datenbanken im Regelfall auf Anwendungsseite umgesetzt, nicht auf Datenbankseite – auch APP.4.3.A11 Ausreichende Dimensionierung der Hardware ist eher auf der Serverseite zu verorten. IT-Sicherheitsanforderungen müssen daher bei Verweisen zwischen IT-Sicherheitskonzepten zwischen Nutzer und Anbieter koordiniert werden.

Abbildung mit benutzerdefinierten Bausteinen

Die hier beschriebenen Verweise lassen sich etwa darstellen, indem ein benutzerdefinierter Baustein für das anbietende Zielobjekt erstellt und damit anschließend das nutzende Zielobjekt modelliert wird. Erstellt man beispielsweise für SB S01 Virt-Server einen gleichnamigen Baustein, ist hierdurch eindeutig, welches Zielobjekt referenziert wird. Dieser Baustein wird an den Zielobjekten BU S01 Anwendungsserver und DB S01 Datenbankserver modelliert.

Um Lücken beim Schutzbedarf zu vermeiden, wird für den Baustein ein Schutzniveau definiert, das dem Schutzbedarf des Zielobjekts entspricht. Werden die Datenbanken mit IT-Sicherheitsanforderungen aus einer entsprechenden Risikoanalyse bis zu einem hohen Schutzbedarf geschützt, ist für den dazugehörigen angebotenen Baustein ein hohes Schutzniveau festzulegen. Das verweisende Zielobjekt modelliert den Baustein und muss nur dann eine Risikoanalyse durchführen, wenn der Schutzbedarf höher als das Schutzniveau dieses Bausteins ist. Bausteine aus dem IT-Grundschutz-Kompendium haben dabei das Schutzniveau „normal“, decken also einen normalen Schutzbedarf ab – für erhöhten Schutzbedarf sind Risikoanalysen notwendig.

In einen benutzerdefinierten Baustein lassen sich auch IT-Sicherheitsanforderungen für verweisende Zielobjekte aufnehmen, die vom Nutzer im IT-Grundschutz-Check bearbeitet und umgesetzt werden müssen. Damit kann beispielsweise die oben erwähnte IT-Sicherheitsanforderung APP.4.3.A19 Schutz vor schädlichen Datenbank-Skripten an Anwendungen weitergegeben werden, welche die Datenbank nutzen. Weitere organisationsspezifische IT-Sicherheitsanforderungen sind ebenso möglich.

Abb. 4 zeigt beispielhaft einen benutzerdefinierten Baustein für das Zielobjekt DB A01 Datenbank. Dieser Baustein wird mit hohem Schutzniveau zur Verfügung gestellt; er enthält eine IT-Sicherheitsanforderung aus einem IT-Grundschutz-Baustein und eine organisationsspezifische IT-Sicherheitsanforderung aus dem Datenschutz.

Fazit

Ab einer gewissen Größe sollten Informationsverbünde in mehrere Teilinformationsverbünde (bzw. IT-Sicherheitskonzepte) aufgeteilt werden. Ohne eine solche Aufteilung ist der Koordinationsaufwand aller Ansprechpartner deutlich höher.

Jedes IT-Sicherheitskonzept betrachtet Zielobjekte, die dort administriert werden – somit sind nur direkt genutzte Zielobjekte aufzuführen. Wenn auf Zielobjekte in anderen IT-Sicherheitskonzepten verwiesen wird, muss eindeutig sein, welches Zielobjekt in welchem IT-Sicherheitskonzept man referenziert. Ist der Schutzbedarf beim nutzenden IT-Sicherheitskonzept höher als beim administrierenden, kommt es zu Lücken in der Betrachtung – dies gilt es unter allen Umständen zu vermeiden!

Verweise lassen sich mit benutzerdefinierten Bausteinen darstellen: Für jedes angebotene Zielobjekt wird ein benutzerdefinierter Baustein erstellt, der von allen Nutzern zu modellieren ist. Er definiert das Schutzniveau und die weiterzugebenden IT-Sicherheitsanforderungen.

Die Verwaltung mehrerer Teilinformationsverbünde und benutzerdefinierter Bausteine wird durch Software-Tools zur Abbildung von Informationsverbünden bereits unterstützt, sodass sich die vorgestellte Methode zur Aufteilung ohne weitere Anpassung solcher Tools umsetzen lässt.

Die beschriebene Methode der Modularisierung setzen die Autoren in einem Informationsverbund mit mehreren hundert IT-Sicherheitskonzepten seit mehreren Jahren erfolgreich um – diese werden unabhängig voneinander erstellt, geprüft und freigegeben.

Julius Rakow, Hussein Baydoun und Tobias Goldschmidt sind Berater der HiSolutions AG im Bereich Security Consulting.