/

Wer oder was ist Informationssicherheit?

Informationssicherheit steht im Fokus des BSI IT-Grundschutzes. Dieser Begriff wird oft unterschiedlich interpretiert.

Laut Definition hat Informationssicherheit das Ziel, Informationen jeglicher Art und Herkunft zu schützen. Dabei können Informationen auf Papier, in IT-Systemen oder auch in den Köpfen der Benutzer gespeichert sein. IT-Sicherheit als Teilmenge der Informationssicherheit konzentriert sich auf den Schutz elektronisch gespeicherter Informationen und deren Verarbeitung.

Erstellung einer Sicherheitskonzeption nach der Vorgehens­
weise der Standard-Absicherung
Eines der Ziele der Standard-Absicherung des IT-Grundschutzes ist es, eine pragmatische und effektive
Vorgehensweise zur Erzielung eines normalen Sicherheitsniveaus anzubieten, das auch als Basis für
ein höheres Sicherheitsniveau dienen kann.
Nachdem ein Informationssicherheitsprozess initiiert, die Sicherheitsleitlinie und Informationssicher­
heitsorganisation definiert wurden, wird die Sicherheitskonzeption für die Institution erstellt. Als
Grundlage hierfür finden sich in den Bausteinen des IT-Grundschutz-Kompendiums Sicherheitsanfor­
derungen nach dem jeweiligen Stand der Technik für typische Komponenten von Geschäftsprozes­
sen, Anwendungen, IT-Systemen usw. Diese sind in Bausteinen strukturiert, sodass sie modular auf­
einander aufsetzen.
Abbildung 11: Erstellung der Sicherheitskonzeption bei der Standard-Absicherung
Die Durchführung einer Standard-Absicherung nach IT-Grundschutz gliedert sich in die nachfolgen­
den Aktionsfelder:
Festlegung des Geltungsbereichs
Bei der Entscheidung für die weitere Vorgehensweise (siehe Kapitel 3.3) wurde auch der Geltungsbe­
reich festgelegt, für den die Sicherheitskonzeption erstellt und umgesetzt werden soll. Dies können
beispielsweise bestimmte Organisationseinheiten einer Institution sein. Es könnten aber auch Berei­
che sein, die definierte Geschäftsprozesse oder Fachaufgaben bearbeiten, inklusive der dafür notwen­
digen Infrastruktur. Im IT-Grundschutz wird der Geltungsbereich für die Sicherheitskonzeption auch
als „Informationsverbund“ bezeichnet. Die Bestandteile des betrachteten Informationsverbunds sind
768 Erstellung einer Sicherheitskonzeption nach Standard-Absicherung
die mit den passenden Bausteinen des IT-Grundschutz-Kompendiums abzusichernden Komponen­
ten.
Strukturanalyse
Für die Erstellung eines Sicherheitskonzepts nach der Vorgehensweise Standard-Absicherung und
insbesondere für die Anwendung des IT-Grundschutz-Kompendiums ist es erforderlich, das Zusam­
menspiel der Geschäftsprozesse, der Anwendungen und der vorliegenden Informationstechnik zu
analysieren und zu dokumentieren. Aufgrund der heute üblichen starken Vernetzung von IT-Syste­
men, die sich auch auf die Bereiche ICS und IoT erstreckt, bietet sich ein Netztopologieplan als Aus­
gangsbasis für die weitere technische Analyse an. Die folgenden Aspekte müssen berücksichtigt wer­
den:
• die organisatorischen und personellen Rahmenbedingungen für den Informationsverbund,
• im Informationsverbund eingesetzte vernetzte und nicht vernetzte IT-Systeme, ICS- und IoT-Kom­
ponenten,
• die Kommunikationsverbindungen dazwischen und nach außen,
• die vorhandene Infrastruktur.
Die einzelnen Schritte der Strukturanalyse werden im Detail in Kapitel 8.1 dieses Dokuments in Form
einer Handlungsanweisung beschrieben.
Schutzbedarfsfeststellung
Zweck der Schutzbedarfsfeststellung ist es, zu ermitteln, welcher Schutz für die Geschäftsprozesse,
die dabei verarbeiteten Informationen und die eingesetzte Informationstechnik ausreichend und an­
gemessen ist. Hierzu werden für jede Anwendung und die verarbeiteten Informationen die zu erwar­
tenden Schäden betrachtet, die bei einer Beeinträchtigung von Vertraulichkeit, Integrität oder Ver­
fügbarkeit entstehen können. Wichtig ist es dabei auch, die möglichen Folgeschäden realistisch ein­
zuschätzen. Hierfür hat sich eine Einteilung in die drei Schutzbedarfskategorien „normal“, „hoch“
und „sehr hoch“ bewährt.
Die einzelnen Schritte der Schutzbedarfsfeststellung werden in Kapitel 8.2 ausführlicher verhandelt.
Auswahl von Anforderungen und Anpassung von Maßnahmen (Modellierung)
Die Voraussetzung für die Anwendung des IT-Grundschutz-Kompendiums auf einen Informationsver­
bund sind detaillierte Unterlagen über seine Struktur und den Schutzbedarf der darin enthaltenen
Zielobjekte. Diese Informationen sollten über die zuvor beschriebenen Arbeitsschritte ermittelt wer­
den. Um geeignete Sicherheitsanforderungen und darüber umzusetzende Maßnahmen für den vor­
liegenden Informationsverbund identifizieren zu können, müssen anschließend die Bausteine des
IT-Grundschutz-Kompendiums auf die Zielobjekte und Teilbereiche abgebildet werden.
Dieser Vorgang der Modellierung wird in Kapitel 8.3 detailliert besprochen.
IT-Grundschutz-Check
Der IT-Grundschutz-Check ist ein Organisationsinstrument, das einen schnellen Überblick über das
vorhandene Sicherheitsniveau bietet. Mithilfe von Interviews wird der Status quo eines bestehenden
(nach IT-Grundschutz modellierten) Informationsverbunds in Bezug auf den Umsetzungsgrad der Si­
cherheitsanforderungen des IT-Grundschutz-Kompendiums ermittelt. Als Ergebnis liegt ein Katalog
77
• im Informationsverbund betriebene Anwendungen und die dadurch gestützten Geschäftsprozes­
se,8.1 Strukturanalyse
vor, in dem für jede relevante Anforderung der Umsetzungsstatus „entbehrlich“, „ja“, „teilweise“
oder „nein“ erfasst ist. Durch die Identifizierung von noch nicht oder nur teilweise erfüllten Anforde­
rungen werden Verbesserungsmöglichkeiten für die Sicherheit der betrachteten Geschäftsprozesse
und der Informationstechnik aufgezeigt.
Kapitel 8.4 beschreibt einen Aktionsplan für die Durchführung eines IT-Grundschutz-Checks. Dabei
wird sowohl den organisatorischen Aspekten als auch den fachlichen Anforderungen bei der Projekt­
durchführung Rechnung getragen.
Risikoanalyse
Durch die Umsetzung der Sicherheitsanforderungen der Standard-Absicherung wird im Normalfall für
einen Informationsverbund ein angemessener und ausreichender Schutz erzielt. Bei einem hohen
oder sehr hohen Schutzbedarf kann es jedoch sinnvoll sein, zu prüfen, ob zusätzlich oder ersatzweise
höherwertige Sicherheitsmaßnahmen erforderlich sind. Dies gilt auch, wenn besondere Einsatzbedin­
gungen vorliegen oder wenn Komponenten verwendet werden, die nicht mit den existierenden Bau­
steinen des IT-Grundschutz-Kompendiums abgebildet werden können. In diesen Fällen ist eine Risi­
koanalyse durchzuführen. Sie sollte in regelmäßigen Abständen aktualisiert werden, damit auch ge­
änderte Gefährdungslagen schnell erkannt werden können.
Eine Methode für Risikoanalysen ist die im BSI-Standard 200-3 Risikoanalyse auf der Basis von
IT-Grundschutz beschriebene Vorgehensweise. In Kapitel 8.5 wird diese Methode überblicksartig dar­
gestellt. Die erfolgreiche Durchführung einer Risikoanalyse hängt entscheidend von den Fachkennt­
nissen des Projektteams ab. Daher ist es häufig sinnvoll, fachkundiges externes Personal hinzuzuzie­
hen.
Reihenfolge der Bearbeitung
Die verschiedenen Aktivitäten, die zur Erstellung einer Sicherheitskonzeption erforderlich sind, also
Strukturanalyse, Schutzbedarfsfeststellung, Modellierung eines Informationsverbunds, IT-Grund­
schutz-Check, Risikoanalyse, müssen nicht zwingend nacheinander abgearbeitet werden. Diese Ak­
tionsfelder können, soweit dies je nach vorhandenen Rahmenbedingungen und Größe des Sicher­
heitsteams möglich ist, auch unabhängig und zeitgleich durchgeführt werden.
8.1
Strukturanalyse
Die Strukturanalyse dient der Vorerhebung von Informationen, die für die weitere Vorgehensweise in
der Erstellung eines Sicherheitskonzepts nach IT-Grundschutz benötigt werden. Dabei geht es um die
Erfassung der Bestandteile (Geschäftsprozesse, Informationen, Anwendungen, IT- und ICS-Systeme,
Räume, Kommunikationsnetze), die zur Betrachtung des Geltungsbereichs benötigt werden.
Hinweis:
Häufig sind die Geschäftsprozesse noch nicht, nicht durchgängig oder nicht aktuell erfasst. Dann
mfssen zuerst die relevanten Geschäftsprozesse identifiziert werden, z. B. durch eine Auswer­
tung von Geschäftsverteilungsplänen, Aufgabenbeschreibungen oder anderen organisationsbe­
schreibenden Papieren.
Dazu müssen die für die Institution wesentlichen Geschäftsprozesse sowie die geschäftskritischen Infor­
mationen und Anwendungen ermittelt und die betroffenen IT-, ICS- oder IoT-Systeme, Räume und Netze
erfasst werden. Die klassische Vorgehensweise ist, zuerst die Anwendungen und ausgehend davon die
weiteren betroffenen Objekte zu ermitteln. Dieser Ansatz hat den Nachteil, dass es häufig schwierig ist,
788 Erstellung einer Sicherheitskonzeption nach Standard-Absicherung
abstrakte Anwendungen losgelöst von konkreten technischen Komponenten zu erfassen. Daher kann
es in einigen Fällen zweckmäßig sein, abweichend von der hier dargestellten Reihenfolge zunächst die
IT- und ICS-Systeme zu erheben, da sich die Anwendungen häufig anhand der betrachteten Systeme
leichter ermitteln lassen.
Zu beachten ist, dass die Objekte und Daten, die im Rahmen einer Strukturanalyse erfasst werden,
meist nicht nur für den Sicherheitsprozess, sondern auch für betriebliche Aspekte und die Verwaltung
erforderlich sind. Es sollte daher geprüft werden, ob bereits Datenbanken oder Übersichten gepflegt
werden, die im Rahmen der Strukturanalyse als Datenquellen genutzt werden könnten. In vielen In­
stitutionen werden beispielsweise Datenbanken für die Inventarisierung, das Konfigurationsmanage­
ment oder die Gestaltung von Geschäftsprozessen betrieben. Dadurch können sich Synergien erge­
ben.
• Erfassung der zum Geltungsbereich zugehörigen Geschäftsprozesse, Anwendungen und Informa­
tionen
• Netzplanerhebung
• Erhebung von IT-, ICS- und IoT-Systemen und ähnlichen Objekten
• Erfassung der Räume und Gebäude (für den ICS-Bereich sind auch die produzierenden Räumlich­
keiten zu berücksichtigen)
Bei allen Teilaufgaben ist zu beachten, dass es häufig nicht zweckmäßig ist, jedes Objekt einzeln zu
erfassen. Stattdessen sollten ähnliche Objekte zu Gruppen zusammengefasst werden.
8.1.1 Komplexitätsreduktion durch Gruppenbildung
Die Strukturanalyse liefert wichtige Grunddaten für den gesamten Sicherheitsprozess. Der Informati­
onsverbund setzt sich meist aus vielen Einzelobjekten zusammen, die bei der Konzeption berücksich­
tigt werden müssen. Wenn alle logischen und technischen Objekte einzeln erfasst werden, besteht
jedoch die Gefahr, dass die Ergebnisse der Strukturanalyse aufgrund der Datenmenge und der Kom­
plexität nicht handhabbar sind. Ähnliche Objekte sollten deshalb sinnvoll zu Gruppen zusammenge­
fasst werden.
Bei technischen Komponenten hat eine konsequente Gruppenbildung zudem den Vorteil, dass die
Administration wesentlich vereinfacht wird, wenn es nur wenige Grundkonfigurationen gibt. Durch
eine möglichst hohe Standardisierung innerhalb eines Informationsverbunds wird außerdem die Zahl
potenzieller Sicherheitslücken reduziert und die Sicherheitsmaßnahmen für diesen Bereich können
ohne Unterscheidung verschiedenster Schwachstellen umgesetzt werden. Dies kommt nicht nur
der Informationssicherheit zugute, sondern spart auch Kosten.
Objekte können dann ein und derselben Gruppe zugeordnet werden, wenn die Objekte alle
• vom gleichen Typ sind,
• ähnliche Aufgaben haben,
• ähnlichen Rahmenbedingungen unterliegen und
• den gleichen Schutzbedarf aufweisen.
Bei technischen Objekten bietet sich eine Gruppenbildung außerdem immer dann an, wenn sie
• ähnlich konfiguriert sind,
79
Die Strukturanalyse gliedert sich in folgende Teilaufgaben:8.1 Strukturanalyse
• ähnlich in das Netz eingebunden sind (z. B. im gleichen Netzsegment) und
• ähnlichen administrativen und infrastrukturellen Rahmenbedingungen unterliegen,
• ähnliche Anwendungen bedienen und
• den gleichen Schutzbedarf aufweisen.
Aufgrund der genannten Voraussetzungen für die Gruppenbildung kann bezüglich der Informations­
sicherheit davon ausgegangen werden, dass eine Stichprobe aus einer Gruppe in der Regel den Si­
cherheitszustand der Gruppe repräsentiert.
Wichtigstes Beispiel für die Gruppierung von Objekten ist sicherlich die Zusammenfassung von Clients.
In der Regel gibt es in einer Institution eine große Anzahl von Clients, die sich jedoch gemäß obigem
Schema in eine überschaubare Anzahl von Gruppen aufteilen lassen. Auch in produzierenden und ge­
werblichen Bereichen ist es empfehlenswert, Objekte zu gruppieren, wenn diese vergleichbar konfigu­
riert und eingesetzt werden (z. B. Handscanner, Arbeitsplatz-PCs). Dies gilt analog auch für Räume und
andere Objekte. In großen Informationsverbünden, wo aus Gründen der Redundanz oder des Durch­
satzes viele Server die gleiche Aufgabe wahrnehmen, können durchaus auch Server zu Gruppen zusam­
mengefasst werden.
Zunehmend werden IT-Systeme virtualisiert. Da hierbei typischerweise viele virtuelle Maschinen (VMs)
auf einem Virtualisierungsserver betrieben werden, ist eine sinnvolle Strukturanalyse bei virtualisierten
Infrastrukturen oder Cloud Computing nur durch geeignete Gruppenbildung möglich. Für die Grup­
penbildung gelten bei Virtualisierung dieselben Regeln wie für physische Zielobjekte. Prinzipiell kön­
nen auch solche VMs zu einer Gruppe zusammengefasst werden, die auf verschiedenen physischen
IT-Systemen laufen, wenn sie ähnliche Aufgaben erfüllen, gleichartig konfiguriert sind und denselben
Schutzbedarf aufweisen.
In der Regel bestehen Cloud Computing-Plattformen aus homogenen Hard- und Software-Kompo­
nenten. Aufgrund der Homogenität kann eine Vielzahl von Aufgaben automatisiert und zentral
durchgeführt werden. Eine Gruppenbildung, beispielsweise anhand des Schutzbedarfs, ist beim
Cloud Computing zwingend erforderlich.
Die Teilaufgaben der Strukturanalyse werden nachfolgend beschrieben und durch ein begleitendes
Beispiel erläutert. Eine ausführliche Version des Beispiels findet sich in den Hilfsmitteln zum IT-Grund­
schutz auf den einzelnen Webseiten bzw. auf der BSI-Website. Bei allen Teilaufgaben sollten jeweils
Objekte zu Gruppen zusammengefasst werden, wenn dies sinnvoll und zulässig ist.
Aktionspunkte zu 8.1.1 Komplexitätsreduktion durch Gruppenbildung
• Bei allen Teilaufgaben der Strukturanalyse gleichartige Objekte zu Gruppen zusammenfassen
• Typ und Anzahl der jeweils zusammengefassten Objekte vermerken
8.1.2 Erfassung der Geschäftsprozesse und der zugehörigen Informationen
Eine der Hauptaufgaben des Sicherheitsmanagements ist es, der Leitungsebene die Informationssicher­
heitsrisiken aufzuzeigen und damit Transparenz zu schaffen, wo Entscheidungs- oder Handlungsbedarf
erforderlich ist. Hierzu muss sich der ISB einen Überblick über die für die Institution wesentlichen Ge­
schäftsprozesse bzw. Fachaufgaben verschaffen und darstellen, was Informationssicherheitsrisiken
bzw. IT-Risiken für diese Geschäftsprozesse bedeuten.
808 Erstellung einer Sicherheitskonzeption nach Standard-Absicherung
Auf Basis des definierten Informationsverbunds sind in einem ersten Schritt die dort enthaltenen zen­
tralen Geschäftsprozesse oder Fachaufgaben zu erfassen und zu dokumentieren. Hierbei ist darauf zu
achten, dass eine sinnvolle Granularität gewählt wird. Dies bedeutet, dass nicht nur ein einzelner
Hauptprozess, wie z. B. das Personalmanagement, sondern auch die zugehörigen wichtigsten Sub­
prozesse, wie z. B. Personalgewinnung, Mitarbeiterverwaltung, Personalentwicklung usw. erfasst
werden, sofern diese Bestandteil des Informationsverbunds sind. Eine zu detaillierte Dokumentation
z. B. durch eine Auflistung von nachgelagerten Prozessen sollte jedoch vermieden werden. Auch im
ICS-Bereich müssen für die Strukturanalyse die Geschäftsprozesse mit den zugehörigen Informatio­
nen erfasst werden. Hier ist insbesondere darauf zu achten, dass neben dem Kernprozess der Produk­
tion auch weitere Nebenprozesse, wie z. B. die logistischen Prozesse für den Warenfluss und die In­
standhaltung, berücksichtigt werden.
Die einzelnen Prozesse sind wie folgt zu erfassen:
• eindeutiger Bezeichner
• Name
• Prozessverantwortlicher/Fachabteilung
• kurze Beschreibungen des Prozesses oder der Fachaufgabe und der dort verarbeiteten Informatio­
nen
• wichtige, für den Prozess benötigte Anwendung(en)
Um die wesentlichen Geschäftsprozesse zu identifizieren, kann in vielen Institutionen auf bestehende
Prozesslandkarten zurückgegriffen werden. Wenn die Geschäftsprozesse noch nicht, nicht durchgän­
gig oder nicht aktuell erfasst wurden, sollten zunächst Geschäftsverteilungspläne, Aufgabenbeschrei­
bungen oder andere organisationsbeschreibende Papiere ausgewertet werden, um die relevanten
Geschäftsprozesse zu identifizieren. Daneben kann das Verfahrensverzeichnis des Datenschutzbeauf­
tragten ein weiterer Startpunkt für die Erfassung der Prozesse, Fachaufgaben und nachfolgenden
Anwendungen sein, auch wenn dies lediglich die Verfahren und Anwendungen abbildet, die perso­
nenbezogene Daten verarbeiten. Sollten noch keine Prozessbeschreibungen vorliegen, sind kurze
Workshops oder Interviews mit den Fachverantwortlichen zu empfehlen.
Es kann durchaus sinnvoll sein, die Erhebung der Prozesse und Fachaufgaben mit der Erhebung der
Anwendungen zu koppeln, um damit redundante Fragen insbesondere in den Fachabteilungen zu ver­
meiden.
Aktionspunkte zu 8.1.2 Erfassung der Geschäftsprozesse und der zugehörigen Informatio­
nen
• Überblick über die Geschäftsprozesse erstellen
• Geschäftsprozesse mit eindeutigen Nummern oder Kürzeln kennzeichnen
• Zusammenhang zwischen Geschäftsprozessen und Anwendungen darstellen
81
Somit erscheint es sinnvoll, einen Bezug zwischen den Geschäftsprozessen und der Wertschöpfung
einer Institution und den zu schützenden Informationen sowie der verwendeten IT bzw. den verwen­
deten Anwendungen herzustellen. Hierfür müssen die Geschäftsprozesse und deren Abhängigkeit
von den wichtigsten Anwendungen dokumentiert werden.8.1 Strukturanalyse
8.1.3 Erfassung der Anwendungen und der zugehörigen Informationen
Ausgehend von jedem Geschäftsprozess bzw. jeder Fachaufgabe, die im Informationsverbund ent­
halten ist, müssen in dieser Phase die damit zusammenhängenden Anwendungen und die damit
verarbeiteten Informationen identifiziert werden. Anwendungen dienen der IT-technischen Unter­
stützung von Geschäftsprozessen und Fachaufgaben in Behörden und Unternehmen.
Die geeignete Granularität für die betrachteten Anwendungen muss in jeder Institution individuell
gewählt werden. Ziel sollte dabei sein, eine optimale Transparenz und Effizienz bei der Strukturanalyse
und der Schutzbedarfsfeststellung zu erreichen. Auch die im IT-Grundschutz-Kompendium betrach­
teten Bausteine aus der Schicht der Anwendungen können für diesen Schritt Aufschluss geben.
Zur weiteren Reduzierung des Aufwands kann die Strukturanalyse des Informationsverbunds auf die
Anwendungen und Informationen beschränkt werden, die für die betrachteten Geschäftsprozesse
oder Fachaufgaben erforderlich sind. Dabei sollte darauf geachtet werden, dass zumindest diejenigen
Anwendungen und Informationen berücksichtigt werden, die aufgrund der Anforderungen der be­
trachteten Geschäftsprozesse oder Fachaufgaben ein Mindestniveau an
• Geheimhaltung (Vertraulichkeit) oder
• Korrektheit und Unverfälschtheit (Integrität) oder
• Verfügbarkeit
erfordern.
Bei der Erfassung der Anwendungen sollten auch die Benutzer bzw. die für die Anwendung Verant­
wortlichen sowie die für den Geschäftsprozess Verantwortlichen befragt werden, wie sie das erfor­
derliche Sicherheitsniveau einschätzen.
Aufgrund der steigenden Komplexität von Anwendungen ist es jedoch oft für die Fachverantwortli­
chen nicht klar, welche Abhängigkeiten zwischen einem Geschäftsprozess oder einer Fachaufgabe zu
einer konkreten Anwendung bestehen. Es sollte also für jede einzelne Fachaufgabe festgestellt wer­
den, welche Anwendungen für ihre Abwicklung notwendig sind und auf welche Daten dabei zuge­
griffen wird. In einer gemeinsamen Sitzung der Fachabteilung, der Verantwortlichen der einzelnen
Anwendungen und der unterstützenden IT-Abteilung können diese Abhängigkeiten erfasst werden.
Beispielsweise können Bestellungen nicht abschließend bearbeitet werden, wenn keine Informatio­
nen über den Lagerbestand zur Verfügung stehen.
Falls abweichend von der hier vorgeschlagenen Reihenfolge zuerst die IT-Systeme erfasst wurden, ist
es häufig hilfreich, die Anwendungen an erster Stelle orientiert an den IT-Systemen zusammenzutra­
gen. Aufgrund ihrer Breitenwirkung sollte dabei mit den Servern begonnen werden. Um ein möglichst
ausgewogenes Bild zu bekommen, kann anschließend diese Erhebung aufseiten der Clients und Ein­
zelplatz-Systeme vervollständigt werden. Abschließend sollte noch festgestellt werden, welche Netz­
koppelelemente welche Anwendungen unterstützen. Für die Erfassung der Anwendungen auf einem
Standard-Client hat sich in der Praxis bewährt, seitens der unterstützenden IT-Abteilung die Stan­
dard-Software der Clients als Paket zu betrachten. So wird die Standard-Software nicht vergessen.
Oftmals wird diese als selbstverständlich angesehen und deren Anwendung wird in Interviews nicht
mehr explizit genannt (z. B. die E-Mail-Anwendung oder Bürokommunikation).
Ausgehend von den Anwendungen können die zugehörigen Geschäftsprozesse auch im Nachgang
erfasst werden (siehe Kapitel 8.1.2). Der Verantwortliche und die Benutzer der Anwendung sollten
ebenfalls erfasst werden, um Ansprechpartner für Sicherheitsfragen leichter identifizieren bzw. be­
troffene Benutzergruppen schnell erreichen zu können.
828 Erstellung einer Sicherheitskonzeption nach Standard-Absicherung
Bei der Erfassung der Anwendungen ist es empfehlenswert, auch Datenträger und Dokumente zu
betrachten und diese ähnlich wie Anwendungen zu behandeln. Sofern sie nicht fest mit einer An­
wendung oder einem IT-System verknüpft sind, müssen Datenträger und Dokumente gesondert in die
Strukturanalyse integriert werden. Natürlich ist es dabei nicht zweckmäßig, alle Datenträger einzeln
zu erfassen. Zum einen sollten nur Datenträger und Dokumente mit einem Mindestschutzbedarf be­
trachtet und zum anderen sollten möglichst Gruppen gebildet werden. Beispiele für Datenträger und
Dokumente, die im Rahmen der Strukturanalyse gesondert erfasst werden sollten, sind
• Archiv- und Back-up-Datenträger,
• Datenträger für den Austausch mit externen Kommunikationspartnern,
• Massenspeicher für den mobilen Einsatz (z. B. USB-Sticks oder externe Festplatten),
• Mikrofilme,
• wichtige Verträge mit Partnern und Kunden.
Es darf nicht vergessen werden, virtualisierte Anwendungen im Rahmen der Strukturanalyse mit zu
erfassen.
Zur Dokumentation der Ergebnisse bietet sich die Darstellung in tabellarischer Form oder die Nutzung
entsprechender Software-Produkte an.
Beispiel: RECPLAST GmbH
Im Folgenden wird anhand einer fiktiven Institution, der RECPLAST GmbH, beispielhaft dargestellt,
wie die erfassten Anwendungen dokumentiert werden können. Zu beachten ist, dass die Struktur der
RECPLAST GmbH im Hinblick auf die Informationssicherheit keineswegs optimal ist. Sie dient lediglich
dazu, die Vorgehensweise bei der Anwendung des IT-Grundschutzes zu illustrieren. In diesem Doku­
ment werden anhand der RECPLAST GmbH die einzelnen Aktivitäten zur Erstellung einer Sicherheits­
konzeption erläutert. Das komplette Beispiel findet sich unter den Hilfsmitteln zum IT-Grundschutz.
Die RECPLAST GmbH ist eine fiktive Institution mit ca. 500 Mitarbeitern, von denen 130 an Bildschirm­
arbeitsplätzen arbeiten. Räumlich ist die RECPLAST GmbH aufgeteilt in zwei Standorte innerhalb
Bonns, wo unter anderem die administrativen und produzierenden Aufgaben wahrgenommen wer­
den, und drei Vertriebsstandorte in Deutschland.
Um die Geschäftsprozesse zu optimieren, sind alle Arbeitsplätze vernetzt worden. Die Außenstelle in
Bonn ist über eine angemietete Standleitung an die Zentrale angebunden. Die Vertriebsstandorte sind
mit abgesicherten Verbindungen über das Internet an die Zentrale angebunden. Alle für die Aufga­
benerfüllung und die Informationssicherheit wesentlichen Richtlinien und Vorschriften sowie Formu­
lare und Textbausteine sind ständig für jeden Mitarbeiter über das Intranet abrufbar. Alle relevanten
Arbeitsergebnisse werden in eine zentrale Datenbank eingestellt. Entwürfe werden ausschließlich
elektronisch erstellt, weitergeleitet und unterschrieben. Die Realisierung und Betreuung aller benö­
tigten Funktionalitäten übernimmt eine IT-Abteilung in Bonn.
Die Geschäftsprozesse der RECPLAST werden elektronisch gepflegt und sind nach einem zweistufigen
Schema benannt. Hinter dem Kürzel GP wird die Nummer des Hauptprozesses angegeben, zum Bei­
spiel GP002. Ein Geschäftsprozess sollte immer beschrieben werden, damit ein einheitliches Verständ­
nis für die Abgrenzung eines Prozesses vorhanden ist. Optional kann eine Prozessart erfasst werden.
Diese dient lediglich zur Übersicht, welche Prozesse für eine Institution hauptsächlich zum Fortbe­
stand beitragen. Die Unterstützungsprozesse sind jedoch ebenso wichtig, diese sind jedoch eher für
den allgemeinen Betrieb einer Institution erforderlich.
83
• Notfallhandbücher, die in ausgedruckter Form vorgehalten werden,8.1 Strukturanalyse
Nachfolgend ist ein Auszug aus der Erfassung der Geschäftsprozesse und der dazugehörigen Infor­
mationen für die RECPLAST GmbH abgebildet:
A.1 Geschäftsprozesse der RECPLAST GmbH
Beschreibung des Prozesses Prozess-Art Prozessverant­
wortlicher Mitarbeiter
GP001 Produktion: Die Produktion der
Kunststoffartikel umfasst alle Pha­
sen von der Materialbereitstellung
bis hin zur Einlagerung des produ­
zierten Materials. Hierzu gehören
innerhalb der Produktion die inter­
nen Transportwege, die Produkti­
on und Fertigung der verschiede­
nen Komponenten und das Verpa­
cken der Teile. Kerngeschäft Leiter Produktion Alle Mitarbeiter
GP002 Angebotswesen: In der Ange­
botsabwicklung werden die Kun­
denanfragen für Produkte verar­
beitet. Im Regelfall werden Kun­
denanfragen formlos per E-Mail
oder Fax geschickt. Die Angebote
werden elektronisch erfasst und
ein schriftliches Angebot per Post Unterstützender
an den Kunden versendet.
Prozess
Leiter Angebotswesen Vertrieb
GP003 Auftragsabwicklung: Kunden
schicken die Bestellungen im Re­
gelfall per Fax oder E-Mail. Alle Be­
lege müssen ausgedruckt und
elektronisch erfasst werden. Eine
Auftragsbestätigung erhält der
Kunde nur, wenn er dies ausdrück­
lich wünscht oder der Produktions­
prozess von der üblichen Produkti­
onszeit abweicht. Leiter Auftrags­
abwicklung Vertrieb
GP004 Einkaufsabteilung: In der Ein­
kaufsabteilung werden alle erfor­
derlichen Artikel bestellt, die nicht
für den Produktionsprozess erfor­
derlich sind. In dieser Abteilung wer­
den externe Projekte verhandelt,
IT-Verträge gestaltet und Ver­
brauchsmaterial im organisatori­
schen Umfeld (Papier, Toner, etc.) Unterstützender
Prozess
beschafft. Leiter Einkaufsabtei­
lung Einkauf
Bezeichnung
84
Kerngeschäft8 Erstellung einer Sicherheitskonzeption nach Standard-Absicherung
A.1 Geschäftsprozesse der RECPLAST GmbH
Bezeichnung
GP005
Beschreibung des Prozesses Prozess-Art Prozessverant­
wortlicher Mitarbeiter
Disposition: In der Disposition
werden alle für die Produktion be­
nötigten Materialien (Kunststoffe,
Schrauben, Tüten, etc.) beschafft.
Hierzu liegen normalerweise Rah­
menverträge vor. Geplant wird in
diesem Umfeld anhand von Jahres­
planmengen und verschiedenen
Bestellwerten. Kerngeschäft Leiter Disposition Disposition, Pro­
duktion
Strukturanalyse der Anwendungen
Der zuständige Informationssicherheitsbeauftragte der RECPLAST GmbH erfasst in der Strukturana­
lyse neben den Geschäftsprozessen auch alle weiteren Objekte, die zur Institution selbst gehören.
Dazu zählen auch die Anwendungen, die zur Aufrechterhaltung der bereits erfassten Geschäftspro­
zesse benötigt werden.
Nachfolgend wird ein Auszug aus der Erfassung der Anwendungen und der zugehörigen Informatio­
nen für das fiktive Beispiel RECPLAST dargestellt:
85
Abbildung 12: Auszug aus den Geschäftsprozessen der RECPLAST GmbH86
Bonn
(Anwendungen)
Alle
Verantwortlich
Administrator
8.1 Strukturanalyse8 Erstellung einer Sicherheitskonzeption nach Standard-Absicherung
Der Zusammenhang zwischen den Geschäftsprozessen und den Anwendungen muss immer darge­
stellt werden. Diese Zuordnung sollte idealerweise mit Tools durchgeführt werden, um bei der übli­
chen Vielzahl von Prozessen und Anwendungen die Übersichtlichkeit und Aktualität zu gewährleis­
ten.
Abbildung 14: Zuordnung der Geschäftsprozesse zu den Anwendungen der RECPLAST GmbH
Aktionspunkte zu 8.1.3 Erfassung der Anwendungen und der zugehörigen Informationen
• Unter Einbeziehung der Verantwortlichen bzw. der Nutzer der Anwendungen herausfinden, wel­
che Anwendungen für die betrachteten Geschäftsprozesse erforderlich sind
• Übersicht über die Anwendungen erstellen und mit eindeutigen Nummern oder Kürzeln kenn­
zeichnen
8.1.4 Netzplanerhebung
Einen geeigneten Ausgangspunkt für die weitere technische Analyse stellt ein Netzplan (beispielswei­
se in Form eines Netztopologieplans) dar. Ein Netzplan ist eine grafische Übersicht über die im be­
trachteten Bereich der Informations- und Kommunikationstechnik eingesetzten Komponenten und
deren Vernetzung. Netzpläne oder ähnliche grafische Übersichten sind auch aus betrieblichen Grün­
den in den meisten Institutionen vorhanden. Im Einzelnen sollte der Plan in Bezug auf die Informati­
onssicherheit mindestens folgende Objekte darstellen:
• IT-Systeme, d.h. Client- und Server-Computer, aktive Netzkomponenten (wie Switches, Router,
WLAN Access Points), Netzdrucker usw.
• ICS- und IoT-Komponenten mit Netzanschluss, d. h. Clients, Handscanner, Industriedrucker, Gerä­
te mit speicherprogrammierbarer Steuerung (SPS), Schaltschränke usw.
• Netzverbindungen zwischen diesen Systemen, d. h. LAN-Verbindungen (wie Ethernet), WLAN,
Backbone-Techniken (wie ATM) usw.
• Verbindungen des betrachteten Bereichs nach außen, d. h. Einwahlzugänge über ISDN oder Mo­
dem, Internetanbindungen über analoge Techniken oder Router, Funkstrecken oder Mietleitungen
zu entfernten Gebäuden oder Liegenschaften usw.
87
Am Beispiel der RECPLAST GmbH wird nachfolgend dargestellt, dass für einen Prozess normalerweise
mehrere Anwendungen eingesetzt werden:8.1 Strukturanalyse
Zu jedem der dargestellten Objekte gehört weiterhin ein Minimalsatz von Informationen, die einem
zugeordneten Katalog zu entnehmen sind. Für jedes IT-System und sonstige Geräte sollten zumindest
• eine eindeutige Bezeichnung (beispielsweise der vollständige Hostname oder eine Identifikations­
nummer),
• Typ und Funktion (beispielsweise Datenbank-Server für Anwendung X),
• die zugrunde liegende Plattform (d. h. Hardware-Plattform und Betriebssystem),
• der Standort (beispielsweise Gebäude- und Raumnummer),
• der zuständige Administrator,
• die vorhandenen Kommunikationsschnittstellen (z. B. Internetanschluss, Bluetooth, WLAN Adap­
ter) sowie
• die Art der Netzanbindung und die Netzadresse
vermerkt sein. Bei Außenanbindungen oder drahtlosen Kommunikationsverbindungen (WLAN,
UMTS, LTE,...) sollten zusätzlich Details zum externen Netz (z. B. Internet, Geschäftspartner, Name
des Providers für die Datenübertragung sowie die Art der Leitung, z. B. MPLS, Leased Line, VPN) auf­
genommen werden.
Virtuelle IT-Systeme (virtuelle Switches, virtuelle Server usw.) und virtuelle Netzverbindungen, bei­
spielsweise virtuelle LANs (VLANs) oder virtuelle private Netze (VPNs), sollten ebenfalls in einem Netz­
plan dargestellt werden. Hierbei sind virtuelle IT-Systeme gemäß ihrem Typ und Einsatzzweck genauso
wie physische IT-Systeme zu behandeln. Darüber hinaus muss die Zuordnung von virtuellen IT-Syste­
men zu physischen Host-Systemen nachvollziehbar sein. Um die Übersichtlichkeit zu verbessern, ist es
bei zunehmender Größe eines Netzes sinnvoll, den Netzplan in mehrere Teilnetzpläne aufzuteilen.
Eine Cloud-Infrastruktur setzt sich aus einer Vielzahl von Elementen zusammen. Neben den physi­
schen (mit CPU, Arbeitsspeicher und anderer Hardware) und gegebenenfalls virtuellen Servern zählen
noch Netze und Speicherlösungen dazu. Die aufgezählten Bereiche verfügen in der Regel über eine
Verwaltungssoftware.
Für den Bereich „Netze“ sollten die eingesetzten Netzmanagement-Tools eine automatische Erzeu­
gung von Netzplänen unterstützen. Neben physischen sollten auch virtuelle IT-Systeme (z. B. virtuelle
Switches, virtuelle Router, virtuelle Sicherheitsgateways) automatisch abgebildet werden können.
Der ICS-Bereich kann als eigenständiges Netz betrieben werden. Bei der Erfassung der Netzverbin­
dungen sollten dabei auch die Schnittstellen erfasst werden (Auflistung der erlaubten und gesperrten
Schnittstellen). Auch die Internetanbindung aus dem ICS-Bereich heraus sollte erfasst werden. Die
Trennung der Netze zwischen dem Office-Bereich und dem ICS-Bereich sollte im Netzplan dargestellt
werden.
Es empfiehlt sich, Bereiche mit unterschiedlichem Schutzbedarf zu kennzeichnen. Der Netzplan sollte
möglichst in elektronischer Form erstellt und gepflegt werden. Hat die Informationstechnik in der
Institution einen gewissen Umfang überschritten, bietet es sich an, bei der Erfassung und Pflege des
Netzplans auf geeignete Hilfsprogramme zurückzugreifen, da die Unterlagen eine erhebliche Kom­
plexität aufweisen können und einem ständigen Wandel unterzogen sind.
Aktualisierung des Netzplans
Da die IT-Struktur in der Regel ständig an die Anforderungen der Institution angepasst wird und die
Pflege des Netzplans entsprechende Ressourcen bindet, ist der Netzplan der Institution nicht immer
888 Erstellung einer Sicherheitskonzeption nach Standard-Absicherung
Im Hinblick auf die Verwendung des Netzplans für die Strukturanalyse besteht demnach der nächste
Schritt darin, den vorliegenden Netzplan (bzw. die Teilpläne, wenn der Gesamtplan aus Gründen der
Übersichtlichkeit aufgeteilt wurde) mit der tatsächlich vorhandenen IT-Struktur abzugleichen und ge­
gebenenfalls auf den neuesten Stand zu bringen. Hierzu sind die IT-Verantwortlichen und Adminis­
tratoren der einzelnen Anwendungen und Netze zu konsultieren. Falls Programme für ein zentralisier­
tes Netz- und Systemmanagement eingesetzt werden, sollte auf jeden Fall geprüft werden, ob diese
Programme bei der Erstellung eines Netzplans Unterstützung anbieten. Zu beachten ist jedoch, dass
Funktionen zur automatischen oder halbautomatischen Erkennung von Komponenten temporär zu­
sätzlichen Netzverkehr erzeugen. Es muss sichergestellt sein, dass dieser Netzverkehr nicht zu Beein­
trächtigungen des IT-Betriebs führt. Ebenso sollte das Ergebnis von automatischen bzw. halbautoma­
tischen Erkennungen stets dahingehend geprüft werden, ob wirklich alle relevanten Komponenten
ermittelt wurden.
Der Bereich der industriellen Steuerung sollte ebenfalls in den Netzplan integriert werden. Ansprech­
partner sind neben den IT-Verantwortlichen und Administratoren auch die Mitarbeiter der Haustech­
nik.
Ein bereinigter Netzplan ist auch an anderen Stellen hilfreich. So kann dieser genutzt werden, um
Dritten schnell die Geschäftsprozess- und IT-Strukturen innerhalb der Institution darzustellen, da in
einem bereinigten Netzplan der Detaillierungsgrad auf das notwendige Maß reduziert wird. Auch für
eine Zertifizierung ist ein bereinigter Netzplan eine sinnvolle Grundlage.
Beispiel: RECPLAST GmbH
Die Netzpläne in der RECPLAST GmbH werden in der IT-Abteilung mit einem Tool verwaltet. Die Dar­
stellung aller Netzpläne ist sehr detailliert und oftmals für Dritte sehr unübersichtlich. Die RECPLAST
GmbH nutzt deshalb für die Darstellung der erfassten Zielobjekte einen bereinigten Netzplan.
89
auf dem aktuellen Stand. Vielmehr werden in der Praxis oftmals nur größere Änderungen an der
IT-Struktur einzelner Bereiche zum Anlass genommen, den Plan zu aktualisieren.(Teilausschnitt)
8.1 Strukturanalyse
908 Erstellung einer Sicherheitskonzeption nach Standard-Absicherung
Aktionspunkte zu 8.1.4 Netzplanerhebung
• Existierende grafische Darstellungen des Netzes, beispielsweise Netztopologiepläne, sichten
• Netzpläne gegebenenfalls aktualisieren oder neu erstellen
• Existierende Zusatzinformationen über die enthaltenen IT-, ICS- und IoT-Systeme sichten und ge­
gebenenfalls aktualisieren und vervollständigen
• Existierende Zusatzinformationen über die enthaltenen Kommunikationsverbindungen sichten
und gegebenenfalls aktualisieren und vervollständigen
Im Hinblick auf die später durchzuführende Schutzbedarfsfeststellung und Modellierung des Informa­
tionsverbunds sollte eine Liste der vorhandenen und geplanten IT-Systeme in tabellarischer Form auf­
gestellt werden. Der Begriff IT-System umfasst dabei nicht nur Computer im engeren Sinn, sondern
auch die IoT- und ICS-Geräte, aktive Netzkomponenten, Netzdrucker, TK-Anlagen, Smartphones, vir­
tuelle IT-Systeme usw. Die technische Realisierung eines IT-Systems steht im Vordergrund, beispiels­
weise Apple MacBook, Client unter Windows, Linux-Server, TK-Anlage usw. An dieser Stelle sollen nur
die Systeme als solche erfasst werden (z. B. Linux-Server), nicht die einzelnen Bestandteile, aus denen
die IT-Systeme zusammengesetzt sind (also nicht Rechner, Tastatur, Bildschirm usw.).
Hinweis:
Ffr einen ordnungsmäßigen IT-Betrieb ist eine vollständige und korrekte Erfassung der vorhan­
denen und geplanten IT-Systeme notwendig, beispielsweise ffr die Uberprffung, Wartung, Feh­
lersuche und Instandsetzung von IT-Systemen. Ffr die Erstellung eines Sicherheitskonzepts reicht
es, sich einen Uberblick fber die gruppierten IT-Systeme zu verschaffen.
Zu erfassen sind sowohl die vernetzten als auch die nicht vernetzten IT-Systeme, insbesondere also
auch solche, die nicht im zuvor betrachteten Netzplan aufgeführt sind. IT-Systeme, die im Netzplan zu
einer Gruppe zusammengefasst worden sind, können weiterhin als ein Objekt behandelt werden.
Auch bei den IT-Systemen, die nicht im Netzplan aufgeführt sind, ist zu prüfen, ob sie sinnvoll zusam­
mengefasst werden können. Möglich ist dies beispielsweise bei einer größeren Anzahl von nicht ver­
netzten Einzelplatz-PCs, die die im Kapitel 8.1.1 Komplexitätsreduktion durch Gruppenbildung ge­
nannten Bedingungen für eine Gruppierung erfüllen.
Bei dieser Erfassung sollten folgende Informationen vermerkt werden, die für die nachfolgende Arbeit
nützlich sind:
• eine eindeutige Bezeichnung der IT-Systeme bzw. der jeweiligen Gruppe (bei Gruppen sollte auch
die Anzahl der zusammengefassten IT-Systeme vermerkt sein),
• Beschreibung (z. B. Funktion, Typ),
• Plattform (z. B. Hardware-Architektur/Betriebssystem),
• Aufstellungsort der IT-Systeme (z. B. Ort, Gebäude, Raum),
• Status der IT-Systeme (in Betrieb, im Test, in Planung) und
• Benutzer bzw. Administratoren der IT-Systeme.
91
8.1.5 Erhebung der IT-Systeme8.1 Strukturanalyse
Anschließend werden die Anwendungen jeweils denjenigen IT-Systemen zugeordnet, die für deren
Ausführung benötigt werden. Dies können die IT-Systeme sein, auf denen die Anwendungen verar­
beitet werden, oder auch diejenigen, die Daten dieser Anwendungen transferieren. Das Ergebnis ist
eine Übersicht, in der die Zusammenhänge zwischen den wichtigen Anwendungen und den entspre­
chenden IT-Systemen dargestellt werden.
92Betrieb
Administratoren
Verantwortlich
8 Erstellung einer Sicherheitskonzeption nach Standard-Absicherung
9394
Betrieb
Administratoren
Verantwortlich
Administrator
8.1 Strukturanalyse8 Erstellung einer Sicherheitskonzeption nach Standard-Absicherung
Für die Zuordnung der Anwendungen zu den IT-Systemen setzt die RECPLAST GmbH ein Tool ein, da
die Pflege in Form einer Tabelle aufwendig ist. Jede Änderung, sei es ein IT-System oder eine Anwen­
dung, muss immer dokumentiert werden. Diese Zuordnung ist für die später folgende Schutzbedarfs­
feststellung erforderlich.
8.1.6 Erhebung der ICS-Systeme
In Institutionen mit Produktion und Fertigung müssen auch die industriellen Steuerungssysteme (ICS),
die von der Institution eingesetzt werden, erhoben werden.
Im ICS-Bereich gibt es Arbeitsplatz-PCs, die auch hier zu Gruppen zusammengefasst werden sollten.
Oftmals sind diese PCs mit den gleichen Anwendungen wie die der Büroumgebung ausgestattet.
Darüber hinaus sind auf einigen PCs spezielle Anwendungen installiert. Zu vielen PC-Arbeitsplätzen
gehört ein Drucker und neben der Standardperipherie (Maus, Tastatur) werden weitere periphere
Endgeräte (z. B. Handscanner) eingesetzt, die mit den Arbeitsplatz-PCs direkt verbunden sind. Bei
allen peripheren Endgeräten müssen die Kommunikationsverbindungen (z. B. Bluetooth) ebenfalls
berücksichtigt werden.
Im Bereich der Produktion und Fertigung werden weitere Endgeräte eingesetzt. Für die industrielle
Steuerung gibt es spezielle Endgeräte, z. B. Geräte mit speicherprogrammierbaren Steuerungen
(SPSen), WLAN-Module für Industriemaschinen, selbstfahrende Gabelstapler (Flurfahrzeuge).
Bei der Erfassung der ICS-Systeme sollten folgende Informationen vermerkt werden, die für die nach­
folgenden Schritte erforderlich sind:
• eine eindeutige Bezeichnung der ICS-Systeme bzw. der jeweiligen Gerätegruppe (die Anzahl der
Geräte in den Gruppen sollte ebenfalls vermerkt sein),
• Beschreibung (Typ und Funktion),
• Plattform (z. B. Betriebssystem, Art der (Netz-)Anbindung),
• Aufstellungsort der Geräte (z. B. Gebäude, Halle, Raum)
• Status der ICS-Systeme (in Betrieb, im Test, in Planung) und
• Verantwortliche für den Betrieb der ICS-Systeme.
95
Oftmals werden in der Produktion und Fertigung neben IT-Systemen noch eine Reihe weiterer Geräte
eingesetzt. Alle ICS-Geräte sollten entsprechend erfasst werden.96
Betrieb
Haustechnik
Verantwortlich
Administrator
8.1 Strukturanalyse8 Erstellung einer Sicherheitskonzeption nach Standard-Absicherung
8.1.7 Erhebung sonstiger Geräte
In Institutionen werden je nach Branche unterschiedlichste Geräte eingesetzt, um die Geschäftspro­
zesse zu unterstützen. Neben IT-Systemen, die unmittelbar als solche zu identifizieren sind, können
auch viele andere Arten von Geräten Einfluss auf die Informationssicherheit haben. Zu solchen Gerä­
ten gehören beispielsweise Geräte mit Funktionalitäten aus dem Bereich IoT.
Daher sollte die Institution einen Überblick darüber haben, welche Geräte wo eingesetzt werden und
welche Anforderungen an die Informationssicherheit sich hieraus ergeben könnten, wie regelmäßige
Überprüfung der Betriebssicherheit, Wartung oder das Einspielen von Patches.
Für die IT-Grundschutz-Modellierung sollten die Geräte mit IoT-Funktionalität erfasst werden, die ver­
netzt sind, insbesondere auch solche, die nicht im zuvor betrachteten Netzplan aufgeführt sind. Sol­
che Geräte sollten möglichst zu Gruppen zusammengefasst und als ein Objekt behandelt werden.
Bei dieser Erfassung sollten folgende Informationen vermerkt werden, die für die nachfolgende Arbeit
nützlich sind:
• eine eindeutige Bezeichnung der Geräte bzw. der jeweiligen Gruppe (bei Gruppen sollte auch die
Anzahl der zusammengefassten Geräte vermerkt sein),
• Beschreibung (Typ und Funktion),
• Plattform (z. B. Betriebssystem, Art der Netzanbindung),
• Aufstellungsort der Geräte,
• Status der IT-Systeme (in Betrieb, im Test, in Planung) und
• Verantwortliche für den Betrieb der Geräte.
Internet of Things (IoT)
IoT-Geräte sind häufig dadurch gekennzeichnet, dass sie überschaubare, begrenzte Außenmaße ha­
ben, oftmals preislich unterhalb von Grenzen liegen, die einen aufwendigen Beschaffungsvorgang in
Institutionen nach sich ziehen, und/oder bei denen die Internetfunktionalität nicht hervorsticht. Daher
ist es wahrscheinlich, dass bei jeder Art von Übersicht oder Bestandserhebung IoT-Geräte übersehen
werden. Es ist wichtig, sich darüber einen Überblick zu verschaffen,
• welche IoT-Geräte in der Institution derzeit oder demnächst eingesetzt werden und
• wer die Akteure in der Institution sind, die typischerweise IoT-Geräte nutzen, und mit diesen ins
Gespräch zu kommen.
Dafür kann es ein sinnvoller Ansatz für den ISB sein, in verschiedene Räumlichkeiten der Institution zu
gehen und zu überlegen, welche der dort vorhandenen Komponenten Strom benötigen und ob diese
über IT-Netze vernetzt sein könnten. Der ISB sollte insbesondere mit den Kollegen der Haustechnik,
aber auch mit den anderen Geräteverantwortlichen sprechen und sich die Funktionalitäten der ver­
schiedenen Geräte erläutern lassen. Die Vernetzung könnte beispielsweise über IT-Verkabelung oder
WLAN mit dem LAN erfolgen, über Mobilfunk mit dem Internet, aber auch über freie WLANs in der
97
Auch Geräte, wie beispielsweise Klimaanlagen, Gefahrenmeldeanlagen oder Kaffeemaschinen, die
nicht der direkten Unterstützung der Informationsverarbeitung oder anderer Geschäftsprozesse die­
nen, können die Informationssicherheit beeinträchtigen, wenn z. B. ein Kabelbrand Folgeschäden
nach sich zieht, aber auch, wenn Geräte dieser Art zur besseren Ressourcensteuerung ins IT-Netz
integriert werden.8.1 Strukturanalyse
Umgebung oder andere Funkschnittstellen wie Bluetooth erfolgen. Zusätzlich sollten regelmäßig
Netzscans durchgeführt werden und dabei nach nicht zuzuordnenden Geräten gesucht werden.
Geräte mit IoT-Funktionalitäten können in Institutionen beispielsweise folgende sein:
• Durch Mitarbeiter oder Externe mitgebrachte private Geräte, z. B. Smartwatches, digitale Bilder­
rahmen, Wetterstationen, Fitnessarmbänder und andere Gadgets.
• Durch die Institution beschaffte und betriebene Geräte wie Brand-, Gas- und andere Warnmelder,
Kaffeemaschinen oder Elemente der Gebäudesteuerung. Die Übergänge zu ICS-Systemen sind
hier fließend.
Dabei sind IoT-Geräte nicht immer direkt auf den ersten Blick als solche zu erkennen, beispielsweise
wenn die IoT-Funktionalität kein kaufentscheidendes Merkmal ist, aber für den Hersteller dadurch
eine für ihn gewinnbringende Datensammlung möglich wird, z. B. über die Art und Menge der Ver­
brauchsmaterialien.
Ein Beispiel für Geräte, in denen sich IoT-Funktionalitäten verstecken könnten, sind Komfortmöbel, die
sich automatisch an die jeweiligen Benutzer anpassen und nicht nur lokal die Einstellungen speichern,
sondern diese über IT-Netze mit anderen Arbeitsplätzen austauschen, sodass Mitarbeiter an beliebi­
gen Arbeitsplätzen arbeiten können („Smart Workplaces“).
98und
Server­
Pförtner,
sicherheitsfach­
8 Erstellung einer Sicherheitskonzeption nach Standard-Absicherung
998.1 Strukturanalyse
Aktionspunkte zu 8.1.5, 8.1.6 und 8.1.7 Erhebung der IT-, ICS-Systeme und
sonstiger Geräte
• Prüfen, ob existierende Datenbanken oder Übersichten über die vorhandenen oder geplanten IT-,
ICS-Systeme sowie die sonstigen Geräte als Ausgangsbasis für die weitere Vorgehensweise ge­
eignet sind
• Liste der vernetzten und nicht vernetzten IT-Systeme, IoT- und ICS-Geräte erstellen beziehungs­
weise aktualisieren und vervollständigen
• IT-, ICS-, IoT-Systeme beziehungsweise Systemgruppen mit eindeutigen Nummern oder Kürzeln
kennzeichnen
• Die Anwendungen den IT-, ICS-, IoT-Systemen (Servern, Clients, Netzkoppelelementen usw.) zu­
ordnen, die für ihre Ausführung benötigt werden
8.1.8 Erfassung der Räume
Die betrachteten Geschäftsprozesse und Fachaufgaben werden nicht nur auf definierten IT-Systemen
betrieben, sondern auch innerhalb der Grenzen der räumlichen Infrastruktur einer Institution. Je nach
Größe der Institution und abhängig von vielen anderen Faktoren kann sich eine Institution in einem
allein genutzten Gebäude oder auch nur auf einer Etage befinden. Viele Institutionen nutzen Liegen­
schaften, die weit verstreut sind oder mit anderen Nutzern geteilt werden müssen. Häufig sind Ge­
schäftsprozesse und Fachaufgaben auch in fremden Räumlichkeiten angesiedelt, zum Beispiel im
Rahmen von Dienstleistungsverträgen.
In ein Sicherheitskonzept müssen alle Liegenschaften, innerhalb derer die betrachteten Geschäftspro­
zesse und Fachaufgaben betrieben werden, einbezogen werden. Dazu gehören Betriebsgelände, Ge­
bäude, Etagen, Räume sowie die Wegstrecke zwischen diesen. Alle Kommunikationsverbindungen,
die über für Dritte zugängliche Gelände verlaufen, müssen als Außenverbindungen behandelt wer­
den. Dies gilt auch für drahtlose Kommunikationsverbindungen, wenn nicht ausgeschlossen werden
kann, dass Dritte darauf zugreifen können. Nicht vergessen werden sollten auch Räumlichkeiten, die
außerhalb der offiziellen Liegenschaften liegen, die aber auch sporadisch oder regelmäßig genutzt
werden, um dort Geschäftsprozesse und Fachaufgaben zu bearbeiten. Dazu gehören beispielsweise
Telearbeitsplätze oder temporär angemietete Arbeitsplätze und Lagerflächen.
Für die weitere Vorgehensweise der Modellierung nach IT-Grundschutz und für die Planung des
Soll-Ist-Vergleichs ist es hilfreich, eine Übersicht über die Liegenschaften, vor allem die Räume, zu
erstellen, in denen IT-, ICS- oder IoT-Systeme aufgestellt oder die für deren Betrieb genutzt werden.
Dazu gehören Räume, die ausschließlich dem IT-Betrieb dienen (wie Serverräume, Datenträgerarchi­
ve), solche, in denen unter anderem IT-, ICS- oder IoT-Systeme betrieben werden (wie Büroräume oder
Werkhallen), aber auch die Wegstrecken, über die Kommunikationsverbindungen laufen. Wenn
IT-Systeme statt in einem speziellen Technikraum in einem Schutzschrank untergebracht sind, ist der
Schutzschrank ebenfalls wie ein Raum zu erfassen.
1008 Erstellung einer Sicherheitskonzeption nach Standard-Absicherung
Hinweis:
Bei der Erhebung der IT-, ICS- und IoT-Systeme sind schon die Aufstellungsorte aufgelistet worden.
Zusätzlich muss untersucht werden, ob schutzbedürftige Informationen in weiteren Räumen aufbe­
wahrt werden. Diese Räume müssen dann ebenfalls benannt werden. Hierbei müssen auch Räume
hinzugezählt werden, in denen nicht elektronische schutzbedürftige Informationen aufbewahrt wer­
den, also beispielsweise Aktenordner oder Mikrofilme. Die Art der verarbeiteten Informationen muss
anhand dieser Dokumentation nachvollziehbar sein.
101102
27
Benutzer
aussehen
vergleichbare
8.1 StrukturanalyseBetrieb
Verantwortlich
Administrator
8 Erstellung einer Sicherheitskonzeption nach Standard-Absicherung
1038.2 Schutzbedarfsfeststellung
Aktionspunkte zu 8.1.8 Erfassung der Räume
• Liste aller bei der Erfassung der IT-, ICS- und IoT-Systeme notierten Liegenschaften, Gebäude und
Räume erstellen
• Weitere Räume ergänzen, in denen schutzbedürftige Informationen aufbewahrt oder auf andere
Weise verarbeitet werden
8.2
Schutzbedarfsfeststellung
Ziel der Schutzbedarfsfeststellung ist es, für die erfassten Objekte im Informationsverbund zu ent­
scheiden, welchen Schutzbedarf sie bezüglich Vertraulichkeit, Integrität und Verfügbarkeit besitzen.
Dieser Schutzbedarf orientiert sich an den möglichen Schäden, die mit einer Beeinträchtigung der
betroffenen Anwendungen und damit der jeweiligen Geschäftsprozesse verbunden sind.
Die Schutzbedarfsfeststellung für den Informationsverbund gliedert sich in mehrere Schritte:
• Definition der Schutzbedarfskategorien
• Schutzbedarfsfeststellung für Geschäftsprozesse und Anwendungen
• Schutzbedarfsfeststellung für IT-Systeme, IoT- und ICS-Geräte
• Schutzbedarfsfeststellung für Gebäude, Räume, Werkhallen usw.
• Schutzbedarfsfeststellung für Kommunikationsverbindungen
• Schlussfolgerungen aus den Ergebnissen der Schutzbedarfsfeststellung
Nach der Definition der Schutzbedarfskategorien wird anhand von typischen Schadensszenarien zu­
nächst der Schutzbedarf der Geschäftsprozesse und Anwendungen bestimmt. Anschließend wird dar­
aus der Schutzbedarf der einzelnen IT-Systeme, Räume und Kommunikationsverbindungen abgeleitet.
Die Vorgehensweise hierfür wird in den folgenden Abschnitten detailliert dargestellt.
8.2.1 Definition der Schutzbedarfskategorien
Da der Schutzbedarf meist nicht quantifizierbar ist, beschränkt sich der IT-Grundschutz somit auf eine
qualitative Aussage, indem der Schutzbedarf in drei Kategorien unterteilt wird:
Schutzbedarfskategorien
„normal“ Die Schadensauswirkungen sind begrenzt und überschaubar.
„hoch“ Die Schadensauswirkungen können beträchtlich sein.
„sehr hoch“ Die Schadensauswirkungen können ein existenziell bedrohliches, katastrophales
Ausmaß erreichen.
Hinweis:
Es kann ffr eine Institution auch sinnvoll sein, weitere Kategorien zu definieren. Beispielsweise
kann eine Abstufung nach unten, z. B. „unkritisch“, eingeffhrt werden. (Diese könnte wie folgt
definiert sein: „Schäden an Ressourcen der Schutzbedarfskategorie ,unkritisch‘ haben keine oder
nur minimale Beeinträchtigungen der Institution zur Folge.“)
1048 Erstellung einer Sicherheitskonzeption nach Standard-Absicherung
Werden nur ein oder zwei Kategorien genutzt, ist die damit erreichbare Abstufung meist nicht gra­
nular genug. Werden dagegen fünf oder mehr Schutzbedarfskategorien verwendet, ist eine klare
Unterscheidung zwischen den einzelnen Stufen schwieriger. Zudem ist die Zuordnung von Ressourcen
zu einer der möglichen Schutzbedarfskategorien schwer nachvollziehbar und es steigt dadurch auch
der Aufwand sowohl bei der Zuordnung als auch bei Revisionen.
Wenn mehr als drei Schutzbedarfskategorien definiert werden, so ist zu überlegen, welche der neu
definierten Kategorien den Schutzbedarfskategorien „hoch“ bzw. „sehr hoch“ entsprechen, denn
diese Information wird zur Überprüfung der Entscheidung benötigt, welche Objekte in die Risikoana­
lyse aufgenommen werden.
Die nachfolgenden Schritte erläutern, wie für Geschäftsprozesse und die mit diesen verbundenen
Anwendungen jeweils die adäquate Schutzbedarfskategorie ermittelt werden kann.
Die Schäden, die bei dem Verlust der Vertraulichkeit, Integrität oder Verfügbarkeit für einen Ge­
schäftsprozess bzw. eine Anwendung einschließlich ihrer Daten entstehen können, lassen sich typi­
scherweise folgenden Schadensszenarien zuordnen:
• Verstoß gegen Gesetze/Vorschriften/Verträge,
• Beeinträchtigung des informationellen Selbstbestimmungsrechts,
• Beeinträchtigung der persönlichen Unversehrtheit,
• Beeinträchtigung der Aufgabenerfüllung,
• negative Innen- oder Außenwirkung und
• finanzielle Auswirkungen.
Häufig treffen dabei für einen Schaden mehrere Schadensszenarien zu. So kann beispielsweise der
Ausfall einer Anwendung die Aufgabenerfüllung beeinträchtigen, was direkte finanzielle Einbußen
nach sich zieht und gleichzeitig auch zu einem Imageverlust führt.
Hinweis:
Auch die Art und Anzahl der betrachteten Szenarien können individuell angepasst werden. Je
nach Institution gibt es unterschiedliche Schwerpunkte, auf die sich das Sicherheitsmanagement
konzentrieren kann. So könnte das Szenario „Beeinträchtigung des informationellen Selbstbe­
stimmungsrechts“ entfallen, wenn beispielsweise in der Institution das Datenschutzmanagement
dieses Szenario bereits ausreichend betrachtet hat. In vielen Institutionen kann das Szenario „Be­
einträchtigung der persönlichen Unversehrtheit“ weggelassen werden, es sei denn, es handelt
sich um ein Unternehmen, bei dem Fehlfunktionen von IT-Systemen unmittelbar Personenschä­
den nach sich ziehen können. Dies könnte beispielsweise im Gesundheitswesen oder in Produk­
tionsbereichen der Fall sein.
Es könnten auch zusätzliche Szenarien betrachtet werden, wie beispielsweise
• Einschränkung der Dienstleistungen für Dritte oder
105
Eine andere Möglichkeit ist es, für Vertraulichkeit andere Kategorien als für Integrität oder Verfügbar­
keit zu nutzen. Einige Institutionen unterteilen beispielsweise Vertraulichkeit in die Kategorien „of­
fen“, „intern“, „vertraulich“ und „geheim“, aber die Kategorien Integrität oder Verfügbarkeit nur in
zwei Stufen „normal“ und „kritisch“.8.2 Schutzbedarfsfeststellung
• Auswirkungen auf weitere Infrastrukturen außerhalb des eigenen Informationsverbunds (z. B. Re­
chenzentren, IT-Betrieb von Kunden oder Dienstleistern).
Um die Schutzbedarfskategorien „normal“, „hoch“ und „sehr hoch“ voneinander abgrenzen zu
können, bietet es sich an, die Grenzen für die einzelnen Schadensszenarien zu bestimmen. Zur Ori­
entierung, welchen Schutzbedarf ein potenzieller Schaden und seine Folgen erzeugen, dienen die
folgenden Tabellen. Die Tabellen sollten von der jeweiligen Institution auf ihre eigenen Gegebenheiten
angepasst werden.
Schutzbedarfskategorie „normal“
1. Verstoß gegen Gesetze/
Vorschriften/Verträge
• Verstöße gegen Vorschriften und Gesetze mit geringfügigen
Konsequenzen
• Geringfügige Vertragsverletzungen mit maximal geringen Kon­
ventionalstrafen
2. Beeinträchtigung des infor­ • Es handelt sich um personenbezogene Daten, durch deren Ver­
mationellen Selbstbestim­
arbeitung der Betroffene in seiner gesellschaftlichen Stellung
mungsrechts
oder in seinen wirtschaftlichen Verhältnissen beeinträchtigt wer­
den kann.
3. Beeinträchtigung der per­
sönlichen Unversehrtheit • Eine Beeinträchtigung erscheint nicht möglich.
4. Beeinträchtigung der Auf­
gabenerfüllung • Die Beeinträchtigung würde von den Betroffenen als tolerabel
eingeschätzt werden.
• Die maximal tolerierbare Ausfallzeit liegt zwischen 24 und 72
Stunden.
5. Negative Innen- oder Au­
ßenwirkung • Eine geringe bzw. nur interne Ansehens- oder Vertrauensbeein­
trächtigung ist zu erwarten.
6. Finanzielle Auswirkungen • Der finanzielle Schaden bleibt für die Institution tolerabel.
Tabelle 2: Schutzbedarfskategorie „normal“
Schutzbedarfskategorie „hoch“
1. Verstoß gegen Geset­
ze/Vorschriften/Verträge
• Verstöße gegen Vorschriften und Gesetze mit erheblichen Kon­
sequenzen
• Vertragsverletzungen mit hohen Konventionalstrafen
2. Beeinträchtigung des infor­ • Es handelt sich um personenbezogene Daten, bei deren Verar­
mationellen Selbstbestim­
beitung der Betroffene in seiner gesellschaftlichen Stellung oder
mungsrechts
in seinen wirtschaftlichen Verhältnissen erheblich beeinträchtigt
werden kann.
3. Beeinträchtigung der per­
sönlichen Unversehrtheit
106
• Eine Beeinträchtigung der persönlichen Unversehrtheit kann
nicht absolut ausgeschlossen werden.8 Erstellung einer Sicherheitskonzeption nach Standard-Absicherung
Schutzbedarfskategorie „hoch“
• Die Beeinträchtigung würde von einzelnen Betroffenen als nicht
tolerabel eingeschätzt.
4. Beeinträchtigung der Auf­
gabenerfüllung
• Die maximal tolerierbare Ausfallzeit liegt zwischen einer und 24
Stunden.
5. Negative Innen- oder Au­
ßenwirkung • Eine breite Ansehens- oder Vertrauensbeeinträchtigung ist zu er­
warten.
6. Finanzielle Auswirkungen • Der Schaden bewirkt beachtliche finanzielle Verluste, ist jedoch
nicht existenzbedrohend.
Schutzbedarfskategorie „sehr hoch“
1. Verstoß gegen Gesetze/
Vorschriften/Verträge
• Fundamentaler Verstoß gegen Vorschriften und Gesetze
• Vertragsverletzungen, deren Haftungsschäden ruinös sind
2. Beeinträchtigung des infor­ • Es handelt sich um personenbezogene Daten, bei deren Verar­
mationellen Selbstbestim­
beitung eine Gefahr für Leib und Leben oder die persönliche Frei­
mungsrechts
heit des Betroffenen gegeben ist.
3. Beeinträchtigung der per­
sönlichen Unversehrtheit
• Gravierende Beeinträchtigungen der persönlichen Unversehrt­
heit sind möglich.
• Gefahr für Leib und Leben
4. Beeinträchtigung der Auf­
gabenerfüllung
• Die Beeinträchtigung würde von allen Betroffenen als nicht tole­
rabel eingeschätzt werden.
• Die maximal tolerierbare Ausfallzeit ist kleiner als eine Stunde.
5. Negative Innen- oder Au­
ßenwirkung • Eine landesweite Ansehens- oder Vertrauensbeeinträchtigung,
eventuell sogar existenzgefährdender Art, ist denkbar.
6. Finanzielle Auswirkungen • Der finanzielle Schaden ist für die Institution existenzbedrohend.
Tabelle 4: Schutzbedarfskategorie „sehr hoch“
Wenn bei individuellen Betrachtungen festgestellt wird, dass über diese sechs Schadensszenarien hi­
naus weitere infrage kommen, sollten diese entsprechend ergänzt werden. Für alle Schäden, die sich
nicht in diese Szenarien abbilden lassen, muss ebenfalls eine Aussage getroffen werden, wo die Gren­
zen zwischen „normal“, „hoch“ oder „sehr hoch“ zu ziehen sind.
Darüber hinaus sollten die individuellen Gegebenheiten der Institution berücksichtigt werden: Bedeu­
tet in einem Großunternehmen ein Schaden in Höhe von 200.000,- E gemessen am Umsatz noch
einen geringen Schaden, so kann für ein Kleinunternehmen schon ein Schaden in Höhe von 10.000,- E
existenziell bedrohlich sein. Daher kann es sinnvoll sein, eine prozentuale Größe als Grenzwert zu
definieren, der sich am Gesamtumsatz, am Gesamtgewinn oder an einer ähnlichen Bezugsgröße ori­
entiert.
Ähnliche Überlegungen können bezüglich der Verfügbarkeitsanforderungen angestellt werden. So
kann beispielsweise ein Ausfall von 24 Stunden Dauer in der Schutzbedarfskategorie „normal“ als
107
Tabelle 3: Schutzbedarfskategorie „hoch“8.2 Schutzbedarfsfeststellung
noch tolerabel eingeschätzt werden. Tritt jedoch eine Häufung dieser Ausfälle ein, z. B. mehr als ein­
mal wöchentlich, so kann dies in der Summe nicht tolerierbar sein. Die anhand der Schutzbedarfska­
tegorien festgelegten Verfügbarkeitsanforderungen sollten daher bei Bedarf konkretisiert werden.
Es kann erforderlich sein, für den Bereich ICS die Schutzbedarfskategorien separat festzulegen, aber
diese auf die des restlichen Informationsverbunds abzustimmen. In produzierenden Bereichen ist es
beispielsweise oftmals erforderlich, für die jeweiligen Kategorien kürzere Ausfallzeiten festzulegen als
im Bereich der Büro-IT. Zeitliche Vorgaben können z. B. aus Wartungsverträgen abgeleitet werden.
Unter Umständen müssen auch andere Punkte angepasst werden. Auch im Datenschutz muss der
Schutzbedarf festgelegt werden, um angemessen technische und organisatorische Schutzmaßnah­
men bestimmen und konfigurieren zu können. Das Standard-Datenschutzmodell (SDM) bietet eine
ganze Reihe an Kriterien, um das Risiko eines Grundrechtseingriffs, und daraus folgend des Schutz­
bedarfs, anhand von drei Stufen zu bestimmen. Das SDM bietet zudem Hilfestellungen, sollten die
Schutzbedarfe aus Sicht der Informationssicherheit und des Datenschutzes nicht übereinstimmen.
Bei der Festlegung der Grenze zwischen „normal“ und „hoch“ sollte berücksichtigt werden, dass für
den normalen Schutzbedarf die Basis- und Standardsicherheitsanforderungen des IT-Grundschutzes
ausreichen sollten. Die getroffenen Festlegungen sind in geeigneter Weise im Sicherheitskonzept zu
dokumentieren, da hiervon die Auswahl von Sicherheitsmaßnahmen und damit meist Folgekosten
abhängen.
Aktionspunkte zu 8.2.1 Definition der Schutzbedarfskategorien
• Typische Schadensszenarien für die Definition von Schutzbedarfskategorien betrachten
• Schutzbedarfskategorien „normal“, „hoch“ und „sehr hoch“ definieren beziehungsweise an die
eigene Institution anpassen
8.2.2 Vorgehen bei der Schutzbedarfsfeststellung
Zunächst wird der Schutzbedarf der Geschäftsprozesse und Anwendungen bestimmt. Anschließend
wird daraus der Schutzbedarf der einzelnen Objekte (z. B. IT-Systeme, Räume und Kommunikations­
verbindungen) abgeleitet.
Die Grundlage zur Bestimmung des Schutzbedarfs verschiedener Objekte ist der Schutzbedarf der
Geschäftsprozesse und der zugehörigen Informationen. Der für diese Elemente ermittelte Schutzbe­
darf vererbt sich auf die für deren Verarbeitung genutzten Objekte, also Anwendungen, IT-Systeme,
ICS- und sonstige Geräte, Räume und Kommunikationsverbindungen (Vererbung).
Zur Ermittlung des Schutzbedarfs eines Objektes müssen die möglichen Schäden der relevanten Teil­
objekte in ihrer Gesamtheit betrachtet werden. Beispielsweise müsste bei einem IT-System beleuchtet
werden, welche Auswirkungen Schäden bei den darauf betriebenen Anwendungen und den damit
verarbeiteten Informationen haben. Im Wesentlichen bestimmt der Schaden bzw. die Summe der
Schäden mit den schwerwiegendsten Auswirkungen den Schutzbedarf eines Objektes (Maximum­
prinzip).
Bei der Betrachtung der möglichen Schäden und ihrer Folgen muss auch beachtet werden, dass die
verschiedenen betrachteten Objekte eines Informationsverbunds natürlich eng miteinander verzahnt
sind. So kann z. B. eine IT-Anwendung Arbeitsergebnisse anderer Anwendungen als Input nutzen.
Eine, für sich betrachtet, weniger bedeutende Anwendung A kann wesentlich an Wert gewinnen,
wenn eine andere wichtige Anwendung B auf ihre Ergebnisse angewiesen ist. In diesem Fall muss der
ermittelte Schutzbedarf der Anwendung B auch auf die Anwendung A übertragen werden. Handelt
1088 Erstellung einer Sicherheitskonzeption nach Standard-Absicherung
es sich dabei um Anwendungen verschiedener IT-Systeme, dann müssen Schutzbedarfsanforderun­
gen des einen IT-Systems auch auf das andere übertragen werden (Beachtung von Abhängigkeiten).
Werden mehrere Anwendungen bzw. Informationen auf einem IT-System (oder in einem Raum oder
über eine Kommunikationsverbindung) verarbeitet, so ist zu überlegen, ob durch Kumulation meh­
rerer (z. B. kleinerer) Schäden auf einem IT-System ein insgesamt höherer Gesamtschaden entstehen
kann. Dann erhöht sich der Schutzbedarf des Objektes, also hier des IT-Systems, entsprechend (Ku­
mulationseffekt).
Auf einem Netzserver befinden sich sämtliche ffr die Kundendatenerfassung benötigten Anwen­
dungen einer Institution. Der Schaden bei Ausfall einer dieser Anwendungen wurde als gering
eingeschätzt, da genfgend Ausweichmöglichkeiten vorhanden sind. Fällt jedoch der Server (und
damit alle Anwendungen, die diesen Server benötigen) aus, so ist der dadurch entstehende Scha­
den deutlich höher zu bewerten. Die Aufgabenerffllung kann unter Umständen nicht mehr in­
nerhalb der notwendigen Zeitspanne gewährleistet werden. Daher ist auch der Schutzbedarf
dieser „zentralen“ Komponente entsprechend höher zu bewerten.
Auch der umgekehrte Effekt kann eintreten. So ist es möglich, dass eine Anwendung einen hohen
Schutzbedarf besitzt, ihn aber deshalb nicht auf ein betrachtetes IT-System überträgt, weil auf diesem
IT-System nur unwesentliche Teilbereiche der Anwendung laufen. Hier ist der Schutzbedarf zu relati­
vieren (Verteilungseffekt). Der Verteilungseffekt kann natürlich auch bei anderen Zielobjekten, wie
beispielsweise Räumen, Gebäuden oder Kommunikationsverbindungen, auftreten.
Beispiel: Der Verteilungseffekt tritt hauptsächlich bezüglich des Grundwertes der Verfügbarkeit auf.
So kann bei redundanter Auslegung von IT-Systemen der Schutzbedarf der Einzelkomponenten nied­
riger sein als der Schutzbedarf der Gesamtanwendung. Auch im Bereich der Vertraulichkeit sind Ver­
teilungseffekte vorstellbar: Falls sichergestellt ist, dass ein Client nur unkritische Daten einer hochver­
traulichen Datenbankanwendung abrufen kann, so besitzt der Client im Vergleich zum Datenbank­
server unter Umständen einen geringeren Schutzbedarf.
Ein Verteilungseffekt tritt häufig auf, wenn bei der Einrichtung oder dem Aufbau von Zielobjekten
durch entsprechende Redundanzen bereits den Anforderungen an einen hohen Schutzbedarf Rech­
nung getragen wurde. Dies ist im Grunde ein Vorgriff auf Betrachtungen, die im Rahmen der Risiko­
analyse erforderlich sind. Deshalb sollten im Rahmen der Schutzbedarfsfeststellung getroffene Ent­
scheidungen sorgfältig dokumentiert werden.
Beispiel:
Bei Anwendungen, die im Hinblick auf Verffgbarkeit einen hohen Schutzbedarf haben, wurden
bereits Redundanzen vorgesehen, unter anderem Ausweicharbeitsplätze in Nachbargebäuden.
Durch die entstandenen Verteilungseffekte haben diese Arbeitsplätze normalen Schutzbedarf
bezfglich Verffgbarkeit, solange ausreichend Ausweicharbeitsplätze zur Verffgung stehen.
Die Schutzbedarfsfeststellung ist ein iterativer Prozess. Bereits ganz am Anfang, bei der ersten Dis­
kussion darüber, welche Geschäftsprozesse und Informationen welche Bedeutung für die Institution
haben, wird eine erste grobe Schutzbedarfsfeststellung durchgeführt. Auch nach Durchführung von
Risikoanalysen sollte die Schutzbedarfsfeststellung erneut dahingehend geprüft werden, ob sie an­
109
Beispiel:8.2 Schutzbedarfsfeststellung
gepasst werden muss, da sich während der Risikoanalyse und der Auswahl von Maßnahmen neue
Erkenntnisse für den Schutzbedarf von Assets ergeben können.
8.2.3 Schutzbedarfsfeststellung für Geschäftsprozesse und Anwendungen
Um den Schutzbedarf in den verschiedenen Bereichen eines Informationsverbunds zu bestimmen,
muss zunächst der Schutzbedarf der Geschäftsprozesse und der zugehörigen Informationen ermittelt
werden. Darauf aufbauend wird daraus der Schutzbedarf der einzelnen Anwendungen, IT-Systeme,
ICS- und sonstigen Geräte, Räume und Kommunikationsverbindungen abgeleitet.
Um den Schutzbedarf der Geschäftsprozesse zu ermitteln, sollte zunächst die Bedeutung der einzel­
nen Geschäftsprozesse für die Institution beleuchtet werden. Davon ausgehend sollte hinterfragt
werden, welche Abhängigkeiten zwischen Geschäftsprozessen und Anwendungen bestehen und
wie die sich daraus ergebenden Risiken entschärft werden können. Hierzu hat es sich bewährt, mit
der Fragestellung „Was wäre, wenn...?“ zusammen mit den Anwendern realistische Schadensszena­
rien zu diskutieren und die zu erwartenden materiellen oder ideellen Schäden zu beschreiben. Oft
führt dies auch dazu, dass kritische Abhängigkeiten zwischen Geschäftsprozessen und weiteren Ziel­
objekten aufgedeckt werden, die vorher nicht im Fokus standen.
Aus dem Schutzbedarf der Geschäftsprozesse ergibt sich der Schutzbedarf der Anwendungen, die für
deren Erledigung eingesetzt werden.
Hinweis:
Zur Einschätzung des Schutzbedarfs sollten die geeigneten Ansprechpartner gesucht werden, es
ist nicht erforderlich, größere Gruppe von Benutzern zu befragen. Beispielsweise ist es zur Bewer­
tung des Schutzbedarfs bestimmter zentraler Dienste, wie zum Beispiel DNS oder E-Mail, ausrei­
chend, den Schutzbedarf durch die Organisationseinheit festlegen zu lassen, die als Dienstanbie­
ter ffr die Institution auftritt (meist die IT-Abteilung oder das Provider-Management). Der Schutz­
bedarf dieser Dienste ist in der Institution zu kommunizieren. Wird ein höherwertiger
Schutzbedarf der Dienste durch einzelne Fachabteilungen benötigt, so sind mögliche Lösungen
zwischen Fachabteilung, Sicherheitsmanagement und dem Betreiber oder Anbieter des Dienstes
zu erörtern. Ein IT-Dienstleister kann im Regelfall seine Services nicht ffr jede mögliche Schutzbe­
darfskategorie bereitstellen. Deshalb wird er seine Dienste mit einer von ihm festgelegten Schutz­
bedarfseignung anbieten. Der Informationseigentfmer muss bei Nutzung eines Service ffr seinen
Geschäftsprozess entscheiden, ob die ihm vom IT-Dienstleister angebotene Schutzbedarfseig­
nung ausreicht oder ob zusätzliche Sicherheitsmaßnahmen infolge höheren Schutzbedarfs um­
gesetzt werden mfssen.
In die Schutzbedarfsfeststellung müssen auch die in der Strukturanalyse erfassten Gruppen von Da­
tenträgern und Dokumenten einbezogen werden.
Um die Ermittlung der möglichen Schäden und Auswirkungen zu vereinfachen, werden im Anhang
dieses Standards entsprechende Fragestellungen vorgestellt. Diese Anregungen erheben nicht den
Anspruch auf Vollständigkeit, sie dienen lediglich zur Orientierung. Um die individuelle Aufgabenstel­
lung und die Situation der Institution zu berücksichtigen, müssen diese Fragen gegebenenfalls ent­
sprechend ergänzt und angepasst werden.
Die Festlegung des Schutzbedarfs der Geschäftsprozesse und Anwendungen ist eine Entscheidung im
Rahmen des Risikomanagements und hat oft weitreichende Auswirkungen auf das Sicherheitskon­
zept für den betrachteten Informationsverbund. Der Schutzbedarf der Geschäftsprozesse und An­
1108 Erstellung einer Sicherheitskonzeption nach Standard-Absicherung
wendungen fließt in die Schutzbedarfsfeststellung der betroffenen technischen und infrastrukturellen
Objekte, wie zum Beispiel Server und Räume, ein.
Bei komplexen Geschäftsprozessen, insbesondere wenn diese hohen oder sehr hohen Schutzbedarf
haben, kann es sinnvoll sein, diese in Teilprozesse zu zerlegen. Wenn dabei der Bereich mit einem
hohen oder sehr hohen Schutzbedarf auf wenige Teilprozesse eingegrenzt werden kann, hat das den
Vorteil, dass sich der hohe bzw. sehr hohe Schutzbedarf auf wenige Objekte vererbt.
Um die Ergebnisse der Schutzbedarfsfeststellung und die daraus resultierenden Entscheidungen im
Rahmen des Informationssicherheitsmanagements später jederzeit nachvollziehen zu können, müs­
sen die Ergebnisse der Schutzbedarfsfeststellung der Geschäftsprozesse und Anwendungen gut do­
kumentiert werden. Dabei ist darauf zu achten, dass nicht nur die Festlegung des Schutzbedarfs fest­
gehalten wird, sondern auch die entsprechenden Begründungen. Diese Begründungen erlauben es
später, die Festlegungen zu überprüfen und weiter zu verwenden.
111112
Maximumprinzip
Arbeits­
platzrechner
keine Informationen
gespeichert
Anwendung
enthält
Informationen
Begründung
ent­
8.2 Schutzbedarfsfeststellunghoch
Zutritts­
unter­
Maximumprinzip
Zutritt,
Zugriff
risierte
hoch
Maximumprinzip
Begründung
Verfügbarkeit
8 Erstellung einer Sicherheitskonzeption nach Standard-Absicherung
1138.2 Schutzbedarfsfeststellung
An dieser Stelle kann es sinnvoll sein, über diese Informationen hinaus den Schutzbedarf auch aus
einer gesamtheitlichen Sicht der Geschäftsprozesse oder Fachaufgaben zu betrachten. Dazu bietet es
sich an, den Zweck einer Anwendung in einem Geschäftsprozess oder in einer Fachaufgabe zu be­
schreiben und daraus wiederum deren Bedeutung abzuleiten. Diese Bedeutung kann wie folgt klas­
sifiziert werden.
Die Bedeutung der Anwendung ist für den Geschäftsprozess bzw. die Fachaufgabe:
• normal: Der Geschäftsprozess bzw. die Fachaufgabe kann mit tolerierbarem Mehraufwand mit
anderen Mitteln (z. B. manuell) durchgeführt werden.
• hoch: Der Geschäftsprozess bzw. die Fachaufgabe kann nur mit deutlichem Mehraufwand mit
anderen Mitteln durchgeführt werden.
• sehr hoch: Der Geschäftsprozess bzw. die Fachaufgabe kann ohne die Anwendung überhaupt
nicht durchgeführt werden.
Der Vorteil, eine solche ganzheitliche Zuordnung vorzunehmen, liegt insbesondere darin, dass bei der
Schutzbedarfsfeststellung die Leitungsebene als Regulativ für den Schutzbedarf der einzelnen An­
wendungen agieren kann. So kann es sein, dass ein Verantwortlicher für eine Anwendung deren
Schutzbedarf aus seiner Sicht als „normal“ einschätzt, die Leitungsebene aus Sicht des Geschäftspro­
zesses bzw. der Fachaufgabe diese Einschätzung jedoch nach oben korrigiert.
Diese optionalen Angaben sollten ebenfalls tabellarisch oder mithilfe entsprechender Software-pro­
dukte dokumentiert werden.
Aktionspunkt zu 8.2.3 Schutzbedarfsfeststellung für Geschäftsprozesse und Anwendun­
gen
• Schutzbedarf der erfassten Geschäftsprozesse und Anwendungen anhand von Schadensszena­
rien und Fragenkatalogen ermitteln
• Schutzbedarf der Geschäftsprozesse und Anwendungen und die entsprechenden Begründungen
tabellarisch dokumentieren
8.2.4 Schutzbedarfsfeststellung für IT-Systeme
Um den Schutzbedarf eines IT-Systems festzustellen, müssen zunächst die Anwendungen betrachtet
werden, die in direktem Zusammenhang mit dem IT-System stehen. Eine Übersicht, welche Anwen­
dungen für die unterschiedlichen IT-Systeme relevant sind, wurde im Rahmen der Strukturanalyse
(siehe Kapitel 8.1) ermittelt. Der Schutzbedarf der Geschäftsprozesse und Anwendungen (siehe Ka­
pitel 8.2.3) fließt in die Schutzbedarfsfeststellung für die jeweils betroffenen IT-Systeme ein. Hierbei ist
darauf zu achten, dass nicht nur die IT-Systeme berücksichtigt werden, auf denen die jeweilige An­
wendung installiert ist. Vielmehr ist auch der Datenfluss der Anwendung zu beachten, über den der
Schutzbedarf der Anwendung auf die dazwischenliegenden Netzkomponenten vererbt wird.
Zur Ermittlung des Schutzbedarfs eines IT-Systems müssen nun die möglichen Schäden der relevanten
Anwendungen in ihrer Gesamtheit betrachtet werden. Die Ergebnisse der Schutzbedarfsfeststellung
der IT-Systeme sollten wiederum in einer Tabelle festgehalten werden. Darin sollte verzeichnet sein,
welchen Schutzbedarf jedes IT-System bezüglich Vertraulichkeit, Integrität und Verfügbarkeit hat. Der
Gesamtschutzbedarf eines IT-Systems leitet sich wiederum aus dem Maximum des Schutzbedarfs be­
züglich der drei Grundwerte Vertraulichkeit, Integrität und Verfügbarkeit ab. Ein IT-System ist also
hochschutzbedürftig, wenn es bezüglich eines oder mehrerer Grundwerte den Schutzbedarf „hoch“
1148 Erstellung einer Sicherheitskonzeption nach Standard-Absicherung
hat. Der Schutzbedarf eines IT-Systems sollte für alle drei Grundwerte einzeln dokumentiert werden,
da sich hieraus typischerweise verschiedene Arten von Sicherheitsmaßnahmen ergeben.
Bei einem IT-System kann sich beispielsweise der hohe Gesamtschutzbedarf daraus ableiten, dass der
Schutzbedarf bezüglich Vertraulichkeit hoch ist, bezüglich Integrität und Verfügbarkeit allerdings nor­
mal. Dann kann zwar der Gesamtschutzbedarf mit „hoch“ angegeben werden, dies zieht aber nicht
nach sich, dass dadurch der Schutzbedarf bezüglich Integrität und Verfügbarkeit angehoben werden
muss.
Die Festlegungen des Schutzbedarfs der IT-Systeme müssen begründet werden, damit die Entschei­
dungen auch für Außenstehende nachvollziehbar sind. Hier kann auf die Schutzbedarfsfeststellung
der Anwendungen zurückverwiesen werden.
115116
Konfigurationsei­
müssen
bleiben.
regeln
tenverkehr
den
RECPLAST
Zugang
Zugriff
risierte
Begründung
die
normal
8.2 Schutzbedarfsfeststellungnotwendig.
werden
Arbeitsplä­
weitere
zum
onsprozess
Server
bank
sind
Serverraum
Zugriff-,
gangs-
berechtigung
Begründung
Verfügbar­
normal
GmbH
8 Erstellung einer Sicherheitskonzeption nach Standard-Absicherung
1178.2 Schutzbedarfsfeststellung
Schutzbedarfsfeststellung bei virtualisierten Infrastrukturen
Wird Virtualisierung eingesetzt, bleibt die Schutzbedarfsfeststellung im Prinzip gleich. Um den
Schutzbedarf eines IT-Systems zu bestimmen, müssen zunächst die Anwendungen betrachtet wer­
den, die im direkten Zusammenhang mit dem IT-System stehen. In virtualisierten Infrastrukturen wer-
den in der Regel mehrere IT-Systeme auf einem Virtualisierungsserver betrieben. Der Schutzbedarf der
Anwendungen vererbt sich auf die virtuellen IT-Systeme. Die virtuellen IT-Systeme ihrerseits vererben
ihren Schutzbedarf auf den Virtualisierungsserver. Für den Schutzbedarf eines Virtualisierungsservers
lassen sich folgende Fälle unterscheiden:
Vertraulichkeit
Ist der Schutzbedarf der virtuellen IT-Systeme beispielsweise „normal“, so vererbt sich dieser auf den
Virtualisierungsserver. Er bekommt in der Regel auch den Schutzbedarf „normal“. Es sollte überlegt
werden, ob durch die Kumulation mehrerer (z. B. kleinerer) Schäden auf dem Virtualisierungsserver
ein insgesamt höherer Gesamtschaden entstehen kann. Dann erhöht sich der Schutzbedarf des Vir­
tualisierungsservers entsprechend auf „hoch“ (Kumulationseffekt).
Integrität
Das Schutzziel Integrität wird nicht gesondert betrachtet und ist wie Vertraulichkeit zu behandeln.
Verfügbarkeit
Ist der Schutzbedarf der virtuellen IT-Systeme beispielsweise „normal“, dann kommt es durch den
Kumulationseffekt in der Regel zu einer Erhöhung der Verfügbarkeit. Gleichzeitig bietet Virtualisie­
rung mit Konzepten wie Cold-, Warm- oder Hot-Standby die Möglichkeit, Redundanzen zu schaffen.
Dabei wird parallel zum Produktivsystem ein identisches Ersatzsystem auf einem weiteren physischen
Server aufgebaut und entweder ausgeschaltet (Cold-Standby) oder kurzfristig einschaltbar gehalten,
aber nicht eingesetzt (Warm-Standby) oder eingeschaltet und synchron gespiegelt mit Daten versorgt
(Hot-Standby). Sind entsprechende Maßnahmen umgesetzt, dann sinkt der Schutzbedarf (Vertei­
lungseffekt). Es können unter anderem folgende Fälle auftreten:
• Die virtuellen Maschinen weisen in Bezug auf Verfügbarkeit den Schutzbedarf „normal“ auf, dann
gibt es in der Regel eine Kumulation nach „hoch“ und dann durch Verteilung sinkt der Schutzbe­
darf wieder auf „normal“. In diesem Fall reicht der Warm-Standby-Ansatz aus.
• Die virtuellen Maschinen haben den Schutzbedarf „hoch“ in Bezug auf Verfügbarkeit. Aufgrund
von Kumulation kann sich ein insgesamt sehr hoher Schutzbedarf ergeben, der dann wegen Ver­
teilung auf „hoch“ abgesenkt werden kann, wenn entsprechende Maßnahmen (z. B. Hot-Stand­
by) umgesetzt werden.
Schutzbedarfsfeststellung beim Cloud-Computing (IaaS Compute)
Auch beim Cloud Computing ändert sich gegenüber der oben beschriebenen Schutzbedarfsfeststel­
lung wenig. Bei Angeboten der Form „IaaS Compute“ werden den Benutzern virtuelle Maschinen zur
Verfügung gestellt, z. B. über eine Webschnittstelle. Ähnlich wie bei der Virtualisierung wird der
Schutzbedarf des Virtualisierungsservers durch den Schutzbedarf der auf ihm betriebenen virtuellen
IT-Systeme beeinflusst. Techniken wie Live Migration, vMotion oder XenMotion ermöglichen, dass die
virtuellen Maschinen zwischen den Virtualisierungsservern verschoben werden oder Hostsysteme bei
geringer Last in den Stand-by-Modus geschaltet oder sogar heruntergefahren werden können, um
Strom zu sparen. Die Vorteile, die sich dadurch ergeben, sind unbestritten. Aber die Live Migration,
also die Verschiebung von VMs zwischen Virtualisierungsservern, erschwert die Schutzbedarfsfest­
1188 Erstellung einer Sicherheitskonzeption nach Standard-Absicherung
stellung. Daher wird empfohlen, die Cloud-Computing-Plattform für unterschiedliche Bereiche (Vir­
tualisierungscluster) anzulegen, abhängig vom Schutzbedarf (zum Beispiel „normal“ oder „hoch“).
Anwendungen, die denselben Schutzbedarf aufweisen, sollten dann auf einem hierfür vorgesehenen
Virtualisierungscluster betrieben werden. Die einzelnen Bereiche sollten untereinander physisch ge­
trennt sein und es ist sicherzustellen, dass virtuelle Maschinen nicht bereichsübergreifend verschoben
werden können.
Auf eine gesonderte Schutzbedarfsfeststellung für virtuelle IT-Systeme und Virtualisierungsserver
kann verzichtet werden.
Besitzen die meisten Anwendungen auf einem IT-System nur einen normalen Schutzbedarf und
sind nur eine oder wenige hochschutzbedfrftig, so sollte in Erwägung gezogen werden, die
hochschutzbedfrftigen Anwendungen auf ein isoliertes IT-System auszulagern, da dies wesent­
lich gezielter abgesichert werden kann und somit häufig kostengfnstiger ist. Eine solche Alterna­
tive kann dem Management zur Entscheidung vorgelegt werden.
8.2.5 Schutzbedarfsfeststellung für ICS-Systeme
Im Bereich industrieller Steuerungsanlagen muss der Schutzbedarf aller ICS-Systeme festgestellt wer­
den. Die ICS-Systeme wurden bereits in Kapitel 8.1.6 erfasst.
Bei der Feststellung des Schutzbedarfes für die ICS-Systeme muss berücksichtigt werden, dass nicht
per se alle Objekte einem sehr hohen Schutzbedarf unterliegen. In enger Abstimmung ist es sinnvoll,
mit den Verantwortlichen der ICS-Systeme in einem Gespräch die Schutzbedarfsfeststellung durch­
zuführen, da diese wissen, welche ICS-Geräte welche Anforderungen an Vertraulichkeit, Integrität
und Verfügbarkeit haben. Der Schutzbedarf leitet sich hierbei aus dem Anwendungszweck der indu­
striellen Steuerungsanlage ab.
Dabei sollte berücksichtigt werden, dass ICS-Systeme für verschiedene Aufgaben verwendet werden
können. So kann in einer Produktionsstraße im Wechsel ein für ein Unternehmen wichtiges umsatz­
starkes Produkt produziert werden und ein weniger umsatzstarkes Produkt. Bei der Feststellung des
Schutzbedarfs müssen diese Abhängigkeiten beachtet werden (Maximumprinzip).
Für die Definition des Schutzbedarfes kann es sinnvoll sein, die für alle weiteren Schutzbedarfsfest­
stellungen definierten Klassifikationen zu übernehmen. Darüber hinaus können die Schutzbedarfska­
tegorien entsprechend angepasst formuliert werden.
Beispiel: RECPLAST GmbH
Für ein IT-System aus einer Büroumgebung liegt eine Ausfallzeit von bis zu 30 Stunden im normalen
Bereich. Diese Ausfallzeit kann auch für den Betrieb von ICS-Systemen sinnvoll sein, möglicherweise
ist es jedoch erforderlich, die Ausfallzeit für die ICS-Geräte im normalen Schutzbedarf auf zwölf bis 24
Stunden zu reduzieren.
Der Schutzbedarf für jedes ICS-System wird bezüglich Vertraulichkeit, Integrität und Verfügbarkeit
ermittelt. Der Gesamtschutzbedarf der ICS-Systeme leitet sich nach dem Maximumprinzip bezüglich
der drei Grundwerte der Vertraulichkeit, Integrität und Verfügbarkeit ab.
Die Festlegungen des Schutzbedarfs von ICS-Systeme müssen kurz begründet werden, damit die
Entscheidungen für Dritte nachvollziehbar sind.
119
Hinweis:120
Die
Maximumprinzip
sehr hoch
SPSen
jederzeit
sein.
fügbarkeit
für
Verfügbarkeit
vorhan­
(ICS-Systeme)
8.2 Schutzbedarfsfeststellung8 Erstellung einer Sicherheitskonzeption nach Standard-Absicherung
8.2.6 Schutzbedarfsfeststellung für sonstige Geräte
Um den Schutzbedarf sonstiger Geräte festzustellen, muss zunächst bestimmt werden, für welche
Geschäftsprozesse und Anwendungen diese Geräte eingesetzt werden und wie sich deren Schutzbe­
darf vererbt. Diese Informationen wurden in Kapitel 8.1.7 ermittelt. Dabei muss der Datenfluss über
diese Geräte beachtet werden, über den sich der Schutzbedarf auf die dazwischenliegenden Netz­
komponenten vererbt.
Es sollte vermerkt werden, welchen Schutzbedarf jedes Gerät bezüglich Vertraulichkeit, Integrität und
Verfügbarkeit hat. Der Gesamtschutzbedarf eines Geräts leitet sich wiederum aus dem Maximum des
Schutzbedarfs bezüglich der drei Grundwerte Vertraulichkeit, Integrität und Verfügbarkeit ab.
Die Festlegungen des Schutzbedarfs von Geräten müssen kurz begründet werden, damit die Entschei­
dungen auch für Außenstehende nachvollziehbar sind. Hier kann auf die Schutzbedarfsfeststellung
der Geschäftsprozesse und Anwendungen zurückverwiesen werden.
In Institutionen werden je nach Branche unterschiedlichste Geräte eingesetzt, um die Geschäftspro­
zesse zu unterstützen. Neben IT-Systemen, die unmittelbar als solche zu identifizieren sind, können
auch viele andere Arten von Geräten Einfluss auf die Informationssicherheit haben. Zu solchen Gerä­
ten gehören beispielsweise Geräte mit Funktionalitäten aus dem Bereich Internet of Things (IoT).
121
Um den Schutzbedarf eines Geräts zu ermitteln, müssen nun die möglichen Schäden der relevanten
Geschäftsprozesse in ihrer Gesamtheit betrachtet werden. Die Ergebnisse der Schutzbedarfsfeststel­
lung von Geräten sollten wiederum in einer Tabelle festgehalten werden, wenn diese Einfluss auf die
Informationssicherheit haben. Um nicht beliebig viele Geräte in einer Institution erfassen zu müssen,
sollten nur Geräte betrachtet werden, die die Informationssicherheit nennenswert beeinträchtigen
könnten. Diese sollten möglichst zu Gruppen zusammengefasst und als ein Objekt behandelt werden.122
die
den
entsprechenden
Korrekt­
Daten
wichtig. Durch
Aufnahmebereiche normal Kühlschrank
vertraulichen
für
Verfügbarkeit
hoch
GmbH
8.2 Schutzbedarfsfeststellung8 Erstellung einer Sicherheitskonzeption nach Standard-Absicherung
Aktionspunkte zu 8.2.4, 8.2.5 und 8.2.6 Schutzbedarfsfeststellung für IT-, ICS-Systeme und
sonstige Geräte
• Schutzbedarf der IT-, ICS-Systeme und sonstigen Geräte anhand des Schutzbedarfs der Ge­
schäftsprozesse und Anwendungen ermitteln
• Abhängigkeiten, das Maximumprinzip und gegebenenfalls den Kumulations- beziehungsweise
Verteilungseffekt berücksichtigen
• Pro System(-Gruppe) die Ergebnisse für Vertraulichkeit, Integrität und Verfügbarkeit sowie die
Begründungen dokumentieren
Aus den Ergebnissen der Schutzbedarfsfeststellung der Geschäftsprozesse und Anwendungen sowie
der IT-Systeme, ICS- und sonstigen Geräte sollte abgeleitet werden, welcher Schutzbedarf für die
jeweiligen Liegenschaften bzw. Räume daraus resultiert. Dieser Schutzbedarf leitet sich aus dem
Schutzbedarf der im jeweiligen Raum installierten Objekte, verarbeiteten Informationen oder der Da­
tenträger, die in diesem Raum gelagert und benutzt werden, nach dem Maximumprinzip ab. Dabei
sollten eventuelle Abhängigkeiten und ein möglicher Kumulationseffekt berücksichtigt werden,
wenn sich in einem Raum eine größere Anzahl von IT-Systemen oder ICS-Geräten, Datenträgern usw.
befindet, wie typischerweise bei Serverräumen, Rechenzentren, Werkhallen oder Datenträgerarchi­
ven. Für jede Schutzbedarfseinschätzung sollte eine Begründung dokumentiert werden.
Hilfreich ist auch hier eine tabellarische Erfassung der notwendigen Informationen, aufbauend auf der
bereits vorher erstellten Übersicht über die erfassten Räume.
123
8.2.7 Schutzbedarfsfeststellung für Räume124
dürfen
häuslichen normal
keine
bearbeitet
Besprechungs­
werden
Unterlagen
Begründung
Verfügbarkeit
GmbH
8.2 Schutzbedarfsfeststellung8 Erstellung einer Sicherheitskonzeption nach Standard-Absicherung
Aktionspunkte zu 8.2.7 Schutzbedarfsfeststellung für Räume
• Schutzbedarf der Räume aus dem Schutzbedarf der Geschäftsprozesse, Anwendungen und
IT-Systeme, ICS- und sonstigen Geräte ableiten
• Abhängigkeiten, das Maximumprinzip und gegebenenfalls den Kumulationseffekt berücksichti­
gen
• Ergebnisse und Begründungen nachvollziehbar dokumentieren
Nachdem die Schutzbedarfsfeststellung für die betrachteten Geschäftsprozesse, Anwendungen,
IT-Systeme, ICS- und sonstigen Geräte und Räume abgeschlossen wurde, wird nun der Schutzbedarf
bezüglich der Vernetzungsstruktur erarbeitet. Grundlage für die weiteren Überlegungen ist der in
Kapitel 8.1.4 Netzplanerhebung erarbeitete Netzplan des zu untersuchenden Informationsverbunds.
Um die Entscheidungen vorzubereiten, auf welchen Kommunikationsstrecken kryptografische Sicher­
heitsmaßnahmen eingesetzt werden sollten, welche Strecken redundant ausgelegt sein sollten und
über welche Verbindungen Angriffe durch Innen- und Außentäter zu erwarten sind, müssen die Kom­
munikationsverbindungen analysiert werden. Hierbei werden folgende Kommunikationsverbindun­
gen als kritisch gewertet:
• Kommunikationsverbindungen, die Außenverbindungen darstellen, d. h. die in oder über unkon­
trollierte Bereiche führen (z. B. ins Internet oder über öffentliches Gelände). Dazu können auch
drahtlose Kommunikationsverbindungen gehören, da es hierbei schwierig ist, zu verhindern, dass
auf diese von öffentlichem Gelände aus zugegriffen wird. Bei Außenverbindungen besteht die
Gefahr, dass durch externe Angreifer Penetrationsversuche auf das zu schützende System vorge­
nommen oder Schadprogramme eingespielt werden können. Darüber hinaus könnten unter Um­
ständen Innentäter über eine solche Verbindung vertrauliche Informationen nach außen übertra­
gen. Auch in Bezug auf den Grundwert Verfügbarkeit sind Außenverbindungen oft besonders
gefährdet. Es darf nicht vergessen werden, Außenverbindungen für die Fernadministration mit
zu erfassen.
• Kommunikationsverbindungen, über die hochschutzbedürftige Informationen übertragen wer­
den, wobei dies sowohl Informationen mit einem hohen Anspruch an Vertraulichkeit wie auch
Integrität oder Verfügbarkeit sein können. Diese Verbindungen können das Angriffsziel vorsätzli­
chen Abhörens oder vorsätzlicher Manipulation sein. Darüber hinaus kann der Ausfall einer sol­
chen Verbindung die Funktionsfähigkeit wesentlicher Teile des Informationsverbunds beeinträch­
tigen.
• Kommunikationsverbindungen, die im produzierenden Bereich eingesetzt werden, müssen im
Netzplan ebenfalls erfasst werden. Dazu gehören (z. B. bei einer Netztrennung) die Kommunika­
tionsverbindungen zwischen den Netzen.
Bei der Erfassung der kritischen Kommunikationsverbindungen kann wie folgt vorgegangen werden.
Zunächst werden sämtliche „Außenverbindungen“ als kritische Verbindungen identifiziert und er­
fasst. Anschließend werden sämtliche Verbindungen untersucht, die von einem IT-System oder einer
Gruppe von IT-Systemen mit hohem oder sehr hohem Schutzbedarf ausgehen. Dabei werden dieje­
nigen Verbindungen identifiziert, über die hochschutzbedürftige Informationen übertragen werden.
Danach werden die Verbindungen untersucht, über die diese hochschutzbedürftigen Daten weiter­
125
8.2.8 Schutzbedarfsfeststellung für Kommunikationsverbindungen8.2 Schutzbedarfsfeststellung
geleitet werden. Abschließend sind die Kommunikationsverbindungen zu identifizieren, über die der­
lei Informationen nicht übertragen werden dürfen. Zu erfassen sind dabei:
• die Verbindungsstrecke,
• ob es sich um eine Außenverbindung handelt und
• ob hochschutzbedürftige Informationen übertragen werden und ob der Schutzbedarf aus der Ver­
traulichkeit, Integrität oder Verfügbarkeit resultiert.
Die Entscheidungen, welche Kommunikationsverbindungen als kritisch zu betrachten sind, sollten
tabellarisch dokumentiert oder grafisch im Netzplan hervorgehoben werden.
Beispiel: RECPLAST GmbH
Für das Unternehmen RECPLAST GmbH ergeben sich die Kommunikationsverbindungen, die im Netz­
plan im Kapitel 8.1.4 Netzplanerhebung dargestellt wurden. Diese wurden bei der RECPLAST auf­
grund von ähnlichen Anforderungen gruppiert und sowohl in der Strukturanalyse als auch in der
Schutzbedarfsfeststellung beschrieben und bewertet. Anhand der folgenden Tabellen können die
oben dargestellten Kommunikationsverbindungen nachvollzogen werden:
126Betrieb
Mitarbeiter
Verantwortlich
Administrator
8 Erstellung einer Sicherheitskonzeption nach Standard-Absicherung
127128
Administratoren
/
Administrator
8.2 SchutzbedarfsfeststellungMaximumprinzip
Es hoch Standleitung
internen
ministratoren
wurde,
Informationen
hohem
fälscht inner­
Netze
werden,
von
werden.
Begründung
Verfügbarkeit
(Kommunikationsverbindungen)
8 Erstellung einer Sicherheitskonzeption nach Standard-Absicherung
1298.2 Schutzbedarfsfeststellung
Aktionspunkte zu 8.2.8 Schutzbedarfsfeststellung für Kommunikationsverbindungen
• Außenverbindungen erfassen und in tabellarischer oder grafischer Form dokumentieren
• Verbindungen, über die kritische Informationen übertragen werden, identifizieren
• Alle kritischen Kommunikationsverbindungen in tabellarischer oder grafischer Form dokumen­
tieren
8.2.9 Schlussfolgerungen aus den Ergebnissen der Schutzbedarfsfeststellung
Die bei der Schutzbedarfsfeststellung erzielten Ergebnisse bieten einen Anhaltspunkt für die weitere
Vorgehensweise der Sicherheitskonzeption. Für den Schutz, der von den in den IT-Grundschutz-Bau­
steinen beschriebenen Sicherheitsanforderungen ausgeht, wird bezüglich der Schutzbedarfskatego­
rien Folgendes angenommen:
Schutzwirkung von Sicherheitsanforderungen nach IT-Grundschutz
Schutzbedarfskategorie „normal“ Sicherheitsanforderungen nach IT-Grundschutz sind im
Allgemeinen ausreichend und angemessen.
Schutzbedarfskategorie „hoch“ Sicherheitsanforderungen nach IT-Grundschutz liefern
eine Standard-Absicherung, sind aber unter Umständen
alleine nicht ausreichend. Weitergehende Maßnahmen
sollten auf Basis einer Risikoanalyse ermittelt werden.
Schutzbedarfskategorie „sehr hoch“ Sicherheitsanforderungen nach IT-Grundschutz liefern
eine Standard-Absicherung, reichen aber alleine im All­
gemeinen nicht aus. Die erforderlichen zusätzlichen Si­
cherheitsmaßnahmen müssen individuell auf der Grund­
lage einer Risikoanalyse ermittelt werden.
Tabelle 5: Schutzwirkung von Sicherheitsanforderungen nach IT-Grundschutz
Außer bei hohem oder sehr hohem Schutzbedarf muss eine Risikoanalyse auch dann durchgeführt
werden, wenn die Objekte des betrachteten Informationsverbunds
• mit den existierenden Bausteinen des IT-Grundschutzes nicht hinreichend abgebildet (modelliert)
werden können oder
• in Einsatzszenarien (Umgebung, Anwendung) betrieben werden, die im Rahmen des IT-Grund­
schutzes nicht vorgesehen sind.
Ausführliche Informationen zur Risikoanalyse finden sich in Kapitel 8.5.
Bereiche mit unterschiedlichem Schutzbedarf
Bei der Schutzbedarfsfeststellung zeigt sich häufig, dass es Bereiche innerhalb des betrachteten Infor­
mationsverbunds gibt, in denen Informationen verarbeitet werden, die einen hohen oder sehr hohen
Schutzbedarf haben. Auch wenn nur wenige, herausgehobene Daten besonders schutzbedürftig
sind, führt die starke Vernetzung und Kopplung von IT-Systemen, ICS- und sonstigen Geräten und
Anwendungen schnell dazu, dass sich der höhere Schutzbedarf nach dem Maximumprinzip auf an­
dere Bereiche überträgt.
1308 Erstellung einer Sicherheitskonzeption nach Standard-Absicherung
Um Risiken und Kosten einzudämmen, sollten daher Sicherheitszonen zur Trennung von Bereichen
mit unterschiedlichem Schutzbedarf eingerichtet werden. Solche Sicherheitszonen können sowohl
räumlich als auch technisch oder personell ausgeprägt sein.
Beispiele:
• Technische Sicherheitszonen: Um vertrauliche Daten auf bestimmte Bereiche innerhalb eines
LANs zu begrenzen und um zu verhindern, dass Störungen in bestimmten Komponenten oder
Angriffe die Funktionsfähigkeit beeinträchtigen, ist es hilfreich, das LAN in mehrere Teilnetze
aufzuteilen (siehe auch Baustein NET.1.1 Netzarchitektur und -design im IT-Grundschutz-Kom­
pendium).
• Personelle Sicherheitszonen: Grundsätzlich sollten an jede Person immer nur so viele Rechte
vergeben werden, wie es ffr die Aufgabenwahrnehmung erforderlich ist. Darfber hinaus gibt
es auch verschiedene Rollen, die eine Person nicht gleichzeitig wahrnehmen sollte. So sollte ein
Revisor nicht gleichzeitig in der Buchhaltung und in der IT-Administration arbeiten, da er sich
nicht selbst kontrollieren kann und darf. Um die Vergabe von Zugangs- und Zutrittsrechte zu
vereinfachen, sollten Personengruppen, die nicht miteinander vereinbare Funktionen wahr­
nehmen, in getrennten Gruppen oder Abteilungen arbeiten.
• Zonenkonzept bei virtualisierten Infrastrukturen:
Wird Virtualisierung eingesetzt, dann muss dies auch im technischen Zonenkonzept berfck­
sichtigt werden. Virtualisierung bedeutet eine Konsolidierung der Server, d. h. die Möglichkeit,
mehrere Server virtuell auf einem physischen Host zu betreiben. Hierbei können die eingesetz­
ten Server unterschiedlichem Schutzbedarf unterliegen, aufgrund der verschiedenen Anwen­
dungen und Dienste, die darauf laufen. Daher sollte vor einer Virtualisierung festgelegt wer­
den, welche Dienste oder Anwendungen zusammen in einer virtuellen Umgebung betrieben
werden dfrfen und welche durch geeignete Maßnahmen separiert werden mfssen. Bei der
Segmentierung sollte darauf geachtet werden, dass alle Bereiche der IT-Infrastruktur („Server“,
„Netze“, „Storage“ und „Management“) erfasst sind.
Bei der Entscheidung, welche Systeme auf einer gemeinsamen physischen Hardware virtuali­
siert werden dfrfen, ist Folgendes zu beachten:
• Die Server sollten aus organisatorischer Sicht und aus Sicherheitsgrfnden sinnvoll in Zonen
gruppiert werden. Zonen sollten nicht zusammen mit der Sicherheitskomponente, die ffr
die Separierung der Zonen sorgt, virtualisiert werden.
• Welche Komponenten zusammen auf einer gemeinsamen physischen Hardware virtualisiert
werden können, ist abhängig vom Schutzbedarf und Bedarfsträger.
Bedarfsträger können unterschiedliche Mandanten (Hosting-Szenarien), unterschiedliche Or­
ganisationseinheiten innerhalb eines Unternehmens oder einer Behörde oder unterschiedliche
Verfahren sein. Im ersten Fall besteht die Herausforderung bei der Planung, ein gleiches Ver­
ständnis der Bedarfsträger fber die verwendeten Schutzbedarfskategorien zu erreichen.
131
• Räumliche Sicherheitszonen: Um nicht jeden einzelnen Bfroraum permanent abschließen
oder fberwachen zu mfssen, sollten Zonen mit starkem Besucherverkehr von hochschutzbe­
dfrftigen Bereichen getrennt werden. So sollten sich Besprechungs-, Schulungs- oder Veran­
staltungsräume ebenso wie eine Kantine, die externes Publikum anzieht, in der Nähe des Ge­
bäudeeingangs befinden. Der Zugang zu Gebäudeteilen mit Bfros kann dann von einem Pfört­
ner einfach fberwacht werden. Besonders sensitive Bereiche wie eine Entwicklungsabteilung
sollten mit einer zusätzlichen Zugangskontrolle, z. B. fber Chipkarten, abgesichert werden.8.3 Modellierung eines Informationsverbunds
• Zonenkonzept beim Cloud Computing:
Um dem unterschiedlichen Schutzbedarf der Anwender Rechnung zu tragen, mfssen Cloud-Com­
puting-Plattformen mandantenfähig sein und eine verlässliche und durchgängige Trennung der
Anwender fber den kompletten Cloud-Computing-Stack (Server, Netze, Storage und Manage­
ment) gewährleisten. Neben den gängigen Sicherheitsmaßnahmen wie Schadprogramm- und
Spamschutz, IDS und IPS sollte auf Netzebene auf eine geeignete Segmentierung geachtet werden,
indem abhängig vom Schutzbedarf Sicherheitszonen definiert und eingerichtet werden. Beispiele
hierffr sind:
• Sicherheitszone ffr das Management der Cloud
• Sicherheitszone ffr die Live Migration
• Sicherheitszone ffr das Storage-Netz
• Sicherheitszonen ffr die virtuellen Maschinen
Darfber hinaus wird empfohlen, unterschiedliche Zonen ffr die Server-Hardware anhand des
Schutzbedarfs einzurichten und diese untereinander unter Verwendung von Sicherheitsgateways
zu trennen.
Bei der Planung neuer Geschäftsprozesse, Fachaufgaben oder Anwendungen sollte frühzeitig geprüft
werden, ob es zweckmäßig ist, Sicherheitszonen einzurichten. Häufig kann dadurch in allen nachfol­
genden Phasen bis hin zur Revision viel Arbeit gespart werden.
Aktionspunkte zu 8.2.9 Schlussfolgerungen aus den Ergebnissen der Schutzbedarfsfest­
stellung
• Prüfen, ob Objekte mit erhöhten Sicherheitsanforderungen in Sicherheitszonen konzentriert wer­
den können
• Objekte mit erhöhten Sicherheitsanforderungen für eine Risikoanalyse vormerken
8.3
Modellierung eines Informationsverbunds
Nachdem die notwendigen Informationen aus der Strukturanalyse und der Schutzbedarfsfeststellung
vorliegen, besteht der nächste Schritt darin, den betrachteten Informationsverbund mithilfe der vor­
handenen Bausteine aus dem IT-Grundschutz-Kompendium nachzubilden. Das Ergebnis ist ein
IT-Grundschutz-Modell des Informationsverbunds, das aus verschiedenen, gegebenenfalls auch
mehrfach verwendeten Bausteinen besteht und durch die Verwendung der Bausteine die sicherheits­
relevanten Aspekte des Informationsverbunds beinhaltet.
8.3.1 Das IT-Grundschutz-Kompendium
Das IT-Grundschutz-Kompendium (siehe [GSK]) kann in der jeweils aktuellen Fassung vom BSI-Web­
server heruntergeladen oder beim Bundesanzeiger Verlag erworben werden.
Die IT-Grundschutz-Bausteine
Das IT-Grundschutz-Kompendium enthält für verschiedene Vorgehensweisen, Komponenten und
IT-Systeme die Gefährdungslage, Sicherheitsanforderungen und weiterführende Informationen, die
jeweils in einem Baustein zusammengefasst sind.
1328 Erstellung einer Sicherheitskonzeption nach Standard-Absicherung
Um Innovationsschübe und Versionswechsel vor allem im IT-Bereich zu berücksichtigen, ist das
IT-Grundschutz-Kompendium mithilfe seiner Bausteinstruktur modular aufgebaut und konzentriert
sich auf die Darstellung der wesentlichen Sicherheitsanforderungen für die jeweiligen Bausteine. Da­
mit ist es leicht erweiter- und aktualisierbar. Übergeordnet sind die Bausteine in prozess- und system­
orientierte Bausteine aufgeteilt und nach zusammengehörigen Themen in ein Schichtenmodell ein­
sortiert.
Die prozessorientierten Bausteine sind in die folgenden Schichten gruppiert:
• ISMS (Managementsysteme für Informationssicherheit)
• ORP (Organisation und Personal)
• CON (Konzepte und Vorgehensweisen)
• OPS (Betrieb)
• DER (Detektion und Reaktion)
Die systemorientierten Bausteine sind in die folgenden Schichten gruppiert:
• INF (Infrastruktur)
• NET (Netze und Kommunikation)
• SYS (IT-Systeme)
• APP (Anwendungen)
• IND (Industrielle IT)
Gefährdungen
In jedem Baustein wird zunächst die zu erwartende spezifische Gefährdungslage beschrieben. Ergän­
zend hierzu befindet sich im separaten Anhang der jeweiligen Bausteine eine Auflistung der elemen­
taren Gefährdungen, die bei der Erstellung des Bausteins berücksichtigt wurden. Diese Gefährdungs­
liste ist Teil einer ersten Stufe der vereinfachten Risikoanalyse für typische Umgebungen der Informa­
tionsverarbeitung und bildet die Grundlage, auf Basis derer das BSI spezifische Anforderungen
zusammengestellt hat, um ein angemessenes Niveau der Informationssicherheit in einer Institution
zu gewährleisten. Der Vorteil dabei ist, dass die Anwender bei typischen Anwendungsfällen keine
aufwändigen oder weiterführenden Analysen benötigen, um das für einen normalen Schutzbedarf
notwendige Sicherheitsniveau zu erreichen. Vielmehr ist es ausreichend, die für die betrachteten Ge­
schäftsprozesse, und ihrer notwendigen Ressourcen relevanten Bausteine zu identifizieren und die
darin empfohlenen Anforderungen konsequent und vollständig zu erfüllen.
Auch wenn besondere Komponenten oder Einsatzumgebungen vorliegen, die im IT-Grundschutz
nicht hinreichend behandelt werden, bietet das IT-Grundschutz-Kompendium dennoch eine wertvolle
Arbeitshilfe. Die dann notwendige Risikoanalyse kann sich auf die elementaren Gefährdungen dieser
Komponenten oder Rahmenbedingungen konzentrieren.
Sicherheitsanforderungen
In jedem Baustein werden die Sicherheitsanforderungen, die für den Schutz des betrachteten Gegen­
stands relevant sind, aufgeführt. Sie beschreiben, was zu dessen Schutz zu tun ist. Die Anforderungen
sind in drei Kategorien unterteilt:
• Basis-Anforderungen müssen vorrangig erfüllt werden, da bei diesen Empfehlungen mit (relativ)
geringem Aufwand der größtmögliche Nutzen erzielt werden kann. Es handelt sich um uneinge­
1338.3 Modellierung eines Informationsverbunds
schränkte Anforderungen. Die Basis-Anforderungen sind ebenfalls die Grundlage für die Vorge­
hensweise „Basis-Absicherung“.
• Standard-Anforderungen bauen auf den Basis-Anforderungen auf und adressieren den norma­
len Schutzbedarf. Sie sollten grundsätzlich erfüllt werden, aber nicht vorrangig. Die Ziele der Stan­
dard-Anforderungen müssen erreicht werden, um eine Standard-Absicherung zu erzielen. Es kön­
nen sich aber durch die jeweiligen Rahmenbedingungen der Institution auch Gründe ergeben,
warum eine Standard-Anforderung nicht wie beschrieben umgesetzt wird, sondern die Sicher­
heitsziele auf andere Weise erreicht werden. Wenn eine Standard-Anforderung durch andere Si­
cherheitsmaßnahmen erfüllt wird, müssen die dadurch entstehenden Auswirkungen sorgfältig
abgewogen und geeignet dokumentiert werden.
• Anforderungen bei erhöhtem Schutzbedarf sind eine Auswahl von Vorschlägen für eine wei­
terführende Absicherung, die bei erhöhten Sicherheitsanforderungen oder unter bestimmten Rah­
menbedingungen als Grundlage für die Erarbeitung geeigneter Anforderungen und Maßnahmen
berücksichtigt werden können.
Die Bausteine wenden sich an Sicherheitsbeauftragte und Sicherheitsverantwortliche in Institutionen.
Umsetzungshinweise
Zusätzlich zu den Bausteinen des IT-Grundschutz-Kompendiums kann es Umsetzungshinweise ge­
ben. Diese beschreiben, wie die Anforderungen der Bausteine umgesetzt werden können, und ent­
halten dafür passende Sicherheitsmaßnahmen mit einer detaillierten Beschreibung. Die Sicherheits­
maßnahmen können als Grundlage für Sicherheitskonzeptionen verwendet werden, sollten aber un­
ter Umständen noch an die Rahmenbedingungen der jeweiligen Institution angepasst werden.
Die Umsetzungshinweise adressieren jeweils die Personengruppen, die für die Umsetzung der Anfor­
derungen aus den Bausteinen zuständig sind, beispielsweise den IT-Betrieb oder die Haustechnik.
Diese Umsetzungshinweise werden für ausgewählte, vor allem für stark nachgefragte Themen be­
reitgestellt.
8.3.2 Modellierung eines Informationsverbunds: Auswahl von Bausteinen
Das erstellte IT-Grundschutz-Modell ist unabhängig davon, ob der Informationsverbund aus bereits im
Einsatz befindlichen Komponenten besteht oder ob es sich um einen Informationsverbund handelt,
der sich ganz oder teilweise im Planungsstadium befindet. Jedoch kann das Modell unterschiedlich
verwendet werden:
• Das IT-Grundschutz-Modell eines bereits realisierten Informationsverbunds identifiziert über die
verwendeten Bausteine die relevanten Sicherheitsanforderungen. Es kann in Form eines Prüfplans
benutzt werden, um einen Soll-Ist-Vergleich durchzuführen.
• Das IT-Grundschutz-Modell eines geplanten Informationsverbunds stellt hingegen ein Entwick­
lungskonzept dar. Es beschreibt über die ausgewählten Bausteine, welche Sicherheitsanforde­
rungen bei der Realisierung des Informationsverbunds erfüllt werden müssen.
1348 Erstellung einer Sicherheitskonzeption nach Standard-Absicherung
Die Einordnung der Modellierung und die möglichen Ergebnisse verdeutlicht die folgende Abbildung:
Abbildung 27: Ergebnis der Modellierung nach IT-Grundschutz
Typischerweise wird ein im Einsatz befindlicher Informationsverbund sowohl realisierte als auch in Pla­
nung befindliche Anteile umfassen. Das resultierende IT-Grundschutz-Modell beinhaltet dann sowohl
einen Prüfplan wie auch Anteile eines Entwicklungskonzepts. Alle im Prüfplan bzw. im Entwicklungskon­
zept vorgesehenen Sicherheitsanforderungen bilden dann gemeinsam die Basis für die Erstellung des
Sicherheitskonzepts. Dazu gehören neben den bereits erfüllten Sicherheitsanforderungen die bei Durch­
führung des Soll-Ist-Vergleichs als unzureichend oder gar nicht erfüllt identifizierten Anforderungen so­
wie diejenigen, die sich für die in Planung befindlichen Anteile des Informationsverbunds ergeben.
Um einen im Allgemeinen komplexen Informationsverbund nach IT-Grundschutz zu modellieren, müs­
sen die passenden Bausteine des IT-Grundschutz-Kompendiums ausgewählt und umgesetzt werden.
Um die Auswahl zu erleichtern, sind die Bausteine im IT-Grundschutz-Kompendium zunächst in prozess­
und systemorientierte Bausteine aufgeteilt und diese jeweils in einzelne Schichten untergliedert.
Die Sicherheitsaspekte eines Informationsverbunds werden wie folgt den einzelnen Schichten zuge­
ordnet:
1358.3 Modellierung eines Informationsverbunds
Abbildung 28: Das Schichtenmodell des IT-Grundschutzes
Prozessorientierte Bausteine:
• Die Schicht ISMS enthält als Grundlage für alle weiteren Aktivitäten im Sicherheitsprozess den
Baustein Sicherheitsmanagement.
• In der Schicht ORP finden sich Bausteine, die organisatorische und personelle Sicherheitsaspekte
abdecken, wie die Bausteine Organisation und Personal.
• Die Schicht CON enthält Bausteine, die sich mit Konzepten und Vorgehensweisen befassen. Typi­
sche Bausteine der Schicht CON sind unter anderem Kryptokonzept und Datenschutz.
• Die Schicht OPS umfasst alle Sicherheitsaspekte betrieblicher Art. Insbesondere sind dies die Sicher­
heitsaspekte des operativen IT-Betriebs, sowohl bei einem Betrieb im Haus als auch bei einem IT-Be­
trieb, der in Teilen oder komplett durch Dritte betrieben wird. Ebenso enthält er die Sicherheitsas­
pekte, die bei einem IT-Betrieb für Dritte zu beachten sind. Beispiele für die Schicht OPS sind die
Bausteine Schutz vor Schadprogrammen und Outsourcing für Kunden.
• In der Schicht DER finden sich alle Bausteine, die für die Überprüfung der umgesetzten Sicherheits­
maßnahmen und insbesondere für die Detektion von Sicherheitsvorfällen sowie die geeigneten
Reaktionen darauf relevant sind. Typische Bausteine der Schicht DER sind Behandlung von Sicher­
heitsvorfällen und Forensik.
System-Bausteine:
• Die Schicht APP beschäftigt sich mit der Absicherung von Anwendungen und Diensten, unter an­
derem in den Bereich Kommunikation, Verzeichnisdienste, netzbasierte Dienste sowie Business-
und Client-Anwendungen. Typische Bausteine der Schicht APP sind Groupware, Office-Produkte,
Webserver und Browser.
• Die Schicht SYS betrifft die einzelnen IT-Systeme des Informationsverbunds, die gegebenenfalls in
Gruppen zusammengefasst wurden. Hier werden die Sicherheitsaspekte von Servern, Desk­
top-Systemen, Mobile Devices und sonstigen IT-Systemen wie Druckern und TK-Anlagen behan­
delt. Zur Schicht SYS gehören beispielsweise Bausteine zu konkreten Betriebssystemen, Smartpho­
nes und Tablets und Drucker, Kopierer und Multifunktionsgeräte.
1368 Erstellung einer Sicherheitskonzeption nach Standard-Absicherung
• Die Schicht NET betrachtet die Vernetzungsaspekte, die sich nicht auf bestimmte IT-Systeme, son­
dern auf die Netzverbindungen und die Kommunikation beziehen. Dazu gehören z. B. die Baustei­
ne Netzmanagement, Firewall und WLAN-Betrieb.
• Die Schicht INF befasst sich mit den baulich-technischen Gegebenheiten, hier werden Aspekte der
infrastrukturellen Sicherheit zusammengeführt. Dies betrifft unter anderem die Bausteine Gebäu­
de und Rechenzentrum.
• Die Schicht IND befasst sich mit Sicherheitsaspekten industrieller IT. In diese Schicht fallen beispiels­
weise die Bausteine Maschine, Sensoren und Speicherprogrammierbare Steuerung (SPS).
Die Einteilung in diese Schichten hat folgende Vorteile:
• Da übergeordnete Aspekte und gemeinsame infrastrukturelle Fragestellungen getrennt von den
IT-Systemen betrachtet werden, kommt es zu einer Vermeidung von Redundanzen, weil diese
Aspekte nur einmal bearbeitet werden müssen und nicht wiederholt für jedes IT-System.
• Die einzelnen Schichten sind so gewählt, dass auch die Zuständigkeiten für die betrachteten
Aspekte gebündelt sind. So betreffen beispielsweise die Schichten ISMS und ORP Grundsatzfragen
des sicheren Umgangs mit Informationen, die Schicht INF den Bereich Haustechnik, die Schicht SYS
die Zuständigen für die IT-Systeme, die Schicht NET die Ebene der Netzadministratoren und die
Schicht APP schließlich die Anwendungsverantwortlichen und -betreiber.
• Aufgrund der Aufteilung der Sicherheitsaspekte in Schichten können Einzelaspekte in resultieren­
den Sicherheitskonzepten leichter aktualisiert und erweitert werden, ohne dass andere Schichten
umfangreich tangiert werden.
Die Modellierung nach dem IT-Grundschutz besteht nun darin, für die Bausteine einer jeden Schicht zu
entscheiden, ob und wie sie zur Abbildung des Informationsverbunds herangezogen werden können.
Je nach betrachtetem Baustein können die Zielobjekte dieser Abbildung von unterschiedlicher Art
sein: einzelne Geschäftsprozesse oder Komponenten, Gruppen von Komponenten, Gebäude, Liegen­
schaften, Organisationseinheiten usw.
8.3.3 Reihenfolge der Baustein-Umsetzung
Um grundlegende Risiken abzudecken und eine ganzheitliche Informationssicherheit aufzubauen,
müssen die essenziellen Sicherheitsanforderungen frühzeitig erfüllt und entsprechende Sicherheits­
maßnahmen umgesetzt werden. Daher wird im IT-Grundschutz eine Reihenfolge für die umzusetzen­
den Bausteine vorgeschlagen.
Im IT-Grundschutz-Kompendium ist im Kapitel Schichtenmodell und Modellierung beschrieben, wann
ein einzelner Baustein sinnvollerweise eingesetzt werden soll und auf welche Zielobjekte er anzuwen­
den ist. Außerdem sind die Bausteine danach gekennzeichnet, ob sie vor- oder nachrangig umgesetzt
werden sollten.
• R1: Diese Bausteine sollten vorrangig umgesetzt werden, da sie die Grundlage für einen effektiven
Sicherheitsprozess bilden.
• R2: Diese Bausteine sollten als Nächstes umgesetzt werden, da sie in wesentlichen Teilen des In­
formationsverbunds für nachhaltige Sicherheit erforderlich sind.
137
• Die Komplexität der Informationssicherheit wird reduziert, indem eine sinnvolle Aufteilung der
Einzelaspekte vorgenommen wird.8.3 Modellierung eines Informationsverbunds
• R3: Diese Bausteine werden zur Erreichung des angestrebten Sicherheitsniveaus ebenfalls benötigt
und müssen umgesetzt werden, es wird aber empfohlen, diese erst nach den anderen Bausteinen
zu betrachten
Mit R1 sind die Bausteine gekennzeichnet, die notwendig sind, um ein grundlegendes Sicherheitsge­
rüst zu erreichen. Es handelt sich um die Bausteine der Bereiche
• ISMS Managementsysteme für Informationssicherheit,
• ORP Organisation und Personal,
• OPS.1.1 Kern-IT-Betrieb.
Die im zweiten und dritten Schritt umzusetzenden Bausteine (R2 und R3) finden sich in allen anderen
Schichten des IT-Grundschutz-Kompendiums.
Diese Kennzeichnung zeigt nur die sinnvolle zeitliche Reihenfolge für die Umsetzung der Anforderun­
gen des jeweiligen Bausteins auf und stellt keine Gewichtung der Bausteine untereinander dar.
Grundsätzlich müssen alle für den jeweiligen Informationsverbund relevanten Bausteine des IT-Grund­
schutz-Kompendiums umgesetzt werden.
Die Kennzeichnung der Bausteine stellt außerdem nur eine Empfehlung dar, in welcher Reihenfolge
die verschiedenen Bausteine sinnvoll umgesetzt werden könnten. Jede Institution kann hier eine da­
von abweichende, für sich sinnvolle Reihenfolge festlegen.
8.3.4 Zuordnung von Bausteinen
Die IT-Grundschutz-Modellierung, also die Zuordnung von Bausteinen zu Zielobjekten, sollte in Form
einer Tabelle mit folgenden Spalten dokumentiert werden:
• Nummer und Titel des Bausteins
• Relevanz: Diese Spalte dient der Entscheidung, ob ein Baustein für den zu modellierenden Infor­
mationsverbund relevant ist oder nicht. Sie liefert einen schnellen Überblick darüber, ob kein Bau­
stein vergessen wurde.
• Zielobjekt: Wenn ein Baustein für den Informationsverbund relevant ist, erfolgt über diese Spalte
die Zuordnung zum Zielobjekt bzw. einer Zielobjektgruppe.
• Begründung: In dieser Spalte können Randinformationen und Begründungen für die Modellierung
dokumentiert werden. Sind Bausteine für den betrachteten Informationsverbund nicht relevant,
sollte dies hier explizit begründet werden.
• Ansprechpartner: Der konkrete Ansprechpartner wird nicht im Rahmen der Modellierung, sondern
erst bei der Planung des eigentlichen Soll-Ist-Vergleichs im IT-Grundschutz-Check ermittelt. Basie­
rend auf den Rollen und Verantwortlichen, die in den Bausteinen genannten werden, kann hier
jedoch schon eine entsprechende Vorarbeit geleistet werden.
1388 Erstellung einer Sicherheitskonzeption nach Standard-Absicherung
Beispiel: RECPLAST GmbH
Die folgende Tabelle ist ein Auszug aus der Modellierung für das Unternehmen RECPLAST GmbH:
A.3 Modellierung der RECPLAST GmbH
Rele­
vanz
Zielobjekt
APP.5.2 Microsoft Exchange / Outlook nein
APP 3.6 DNS-Server
Ansprech­
partner
Wird nicht eingesetzt.
ja S019
Benutzerdef.BS.1 PC für die Industrie­
steuerung
ja C005
Auslandsreisen sind für
Informationsverbund
nicht relevant.
CON.7: Informationssicherheit auf
Auslandsreisen nein INF.1 Allgemeines Gebäude ja INF.7 Datenträgerarchiv nein INF.4 IT-Verkabelung ja Informations­
verbund
ISMS.1 (Sicherheitsmanagement) ja Informations­
verbund
NET.1.1 Netz-Architektur und -design ja Informations­
verbund
NET.3.1 Router und Switches S033
ja
Begründung
Nummer und Titel des Bausteins
G001
Es gibt kein Datenträ­
gerarchiv.
Die IT-Administration
findet außerhalb des
Informationsverbun­
des statt.
OPS.1.1.2 Ordnungsgemäße IT-Admi­
nistration
nein
OPS.2.4 Fernwartung ja Informations­
verbund
SYS.1.3 Server unter Unix ja S020
SYS.4.1 Drucker, Kopierer und Multi­
funktionsgeräte
ja S048
Abbildung 29: Auszug aus der Modellierung der RECPLAST GmbH
Eine detaillierte Beschreibung der Vorgehensweise zur Modellierung eines Informationsverbunds fin­
det sich im IT-Grundschutz-Kompendium im Kapitel Schichtenmodell und Modellierung.
8.3.5 Modellierung bei Virtualisierung und Cloud-Systemen
Grundsätzlich erfolgt die Modellierung virtueller IT-Systeme nach den gleichen Regeln wie bei eigen­
ständigen physischen IT-Systemen, d. h. es sind die Hinweise in Kapitel 2 des IT-Grundschutz-Kom­
pendiums zu beachten. Die Zuordnung der IT-Grundschutz-Bausteine richtet sich bei IT-Komponenten
in erster Linie nach der Funktion des IT-Systems (Server, Client, usw.), nach dem verwendeten Betriebs­
system (Linux, Windows usw.) und nach den darauf betriebenen Applikationen (Datenbank, Webser­
ver usw.).
1398.3 Modellierung eines Informationsverbunds
Bei Virtualisierungssoftware gibt es Produkte, die ein unterliegendes Betriebssystem benötigen (host­
basierte Virtualisierungslösungen), und andere, die direkt auf der physischen Hardware laufen (Bare
Metal Virtualisierung), ohne unterliegendes Betriebssystem. Falls unterhalb der Virtualisierungs­
schicht ein vollwertiges und eigenständiges Betriebssystem eingesetzt wird, muss der dazu passende
Baustein ebenfalls zugeordnet werden (z. B. aus SYS.1.2 Windows-Server), unabhängig von den vir­
tuellen IT-Systemen.
Wurde der Hypervisor direkt auf der physischen Hardware installiert (Bare Metal Virtualisierung) han­
delt es sich hierbei um ein Zielobjekt, das im IT-Grundschutz-Kompendium nicht enthalten ist, da es
sich hierbei um ein sehr spezielles Zielobjekt handelt. Daher muss eine Risikoanalyse für das entspre­
chende Zielobjekt durchgeführt und die Ergebnisse sollten anschließend mit den Anforderungen des
Bausteins SYS.1.5 Virtualisierung konsolidiert werden.
Beispielszenario:
Als Beispiel wird ein physischer Server S1 betrachtet, auf dem mithilfe einer Virtualisierungssoft­
ware die drei virtuellen Server VM1, VM2 und VM3 betrieben werden. Als Basis-Betriebssystem
kommt auf dem physischen Server S1 eine Linux-Version zum Einsatz. Die Virtualisierungsschicht
ist in diesem Beispiel eine Software-Komponente, die unter Linux läuft, also eine hostbasierte
Servervirtualisierung (Typ 2). Die beiden virtuellen Server VM1 und VM2 werden mit Windows
2012 betrieben, auf VM3 ist hingegen Linux installiert. Applikationen können sowohl auf den drei
virtuellen Servern als auch (unter Umgehung der Virtualisierungsschicht) direkt auf dem Basis-Be­
triebssystem des physischen Servers S1 ablaufen. Die folgende Abbildung zeigt ein Schema dieser
Beispielkonfiguration:
Abbildung 30: Schema einer Beispielkonfiguration
1408 Erstellung einer Sicherheitskonzeption nach Standard-Absicherung
Baustein Zielobjekt
SYS.1.1 Allgemeiner Server S1
SYS.1.1 Allgemeiner Server VM3
SYS.1.1 Allgemeiner Server Gruppe aus VM1 und VM2
SYS.1.3 Server unter Unix S1
SYS.1.3 Server unter Unix VM3
SYS.1.2.2 Windows Server 2012 Gruppe aus VM1 und VM2
Tabelle 6: Zuordnung Bausteine aus Virtualisierungsschicht zu Zielobjekten
Um eine angemessene Gesamtsicherheit für den IT-Betrieb von Cloud-Diensten zu erreichen, müssen
alle Cloud-Dienste (mit ihren zugeordneten virtuellen IT-Systemen, Netzen und weiteren Cloud-Kom­
ponenten) systematisch in der Sicherheitskonzeption berücksichtigt werden. Alle über Cloud-Dienste
bereitgestellten IT-Systeme, Netze und Anwendungen, die sich einerseits in der Betriebsverantwor­
tung und andererseits im Geltungsbereich des ISMS des Cloud-Diensteanbieters befinden, müssen in
der Modellierung gemäß der IT-Grundschutz-Vorgehensweise berücksichtigt werden. Hierbei kann
der Geltungsbereich des Informationsverbunds gleichzeitig als Grenze der Verantwortlichkeit verstan­
den werden: An der Grenze des Informationsverbunds endet die Verantwortung des Cloud-Dienste­
anbieters und beginnt die Verantwortung des Cloud-Anwenders. Der Umfang des Informationsver­
bunds unterscheidet sich dabei je nach dem Servicemodell.
Modellierung von IaaS-Angeboten
Bei IaaS (Infrastructure as a Service) ist der Cloud-Diensteanbieter für den Verwaltungsserver für die
Cloud und den Virtualisierungsserver verantwortlich. Deshalb kommen bei IaaS aus den Schichten
APP (Anwendungen) und SYS (IT-Systeme) nur die Verwaltungs- und die Virtualisierungssoftware als
Zielobjekte vor. Für diese müssen somit die zugehörigen Bausteine ausgewählt werden. Nach der
IT-Grundschutz-Vorgehensweise sind dies die Bausteine für IT-Systeme als Server (Schicht SYS.1).
Für den Cloud-Verwaltungsserver müssen die Bausteine SYS 1.5 Virtualisierung und OPS.3.2
Cloud-Anbieter umgesetzt werden.
Für IaaS stellt der Cloud-Diensteanbieter nicht mehr als eine virtuelle „Hülle“ über ein virtuelles Netz
bereit. Die Absicherung des Netzes nach IT-Grundschutz verantwortet bei IaaS der Cloud-Dienstean­
bieter, wohingegen die Cloud-Anwender die IT-Systeme des Cloud-Angebotes verantworten. Für das
Netz sind die passenden Bausteine aus der Schicht Netze und Kommunikation zu modellieren (z. B.
NET.1.1 Netzarchitektur und -design). In der Regel wird dem virtuellen Server ein Speicherkontingent
aus einem Speichernetz zugeordnet, hierfür ist der Baustein SYS.1.8 Speicherlösungen/Cloud Storage
ebenfalls vom Cloud-Diensteanbieter umzusetzen.
Ein virtueller Server aus der Cloud, der per IaaS angeboten wird, wird durch den Cloud-Anwender
konfiguriert. Die Umsetzungsverantwortung für seine Sicherheitsmaßnahmen liegt somit ebenfalls
beim Cloud-Anwender. Im Hinblick auf die Abgrenzung des Informationsverbunds des Cloud-Diens­
teanbieters befindet sich also dieser virtuelle Server außerhalb des Informationsverbunds des
Cloud-Diensteanbieters.
141
Modellierung beim Cloud-Computing8.3 Modellierung eines Informationsverbunds
Die Schnittstelle zur Bereitstellung von IaaS-Cloud-Diensten (Self-Service-Portal) ist durch geeignete
Mechanismen zur Netztrennung (z. B. über Netze, virtuelle Firewalls, Routing) vom Cloud-Dienstean­
bieter abzusichern und gegebenenfalls der Baustein APP.3.1 Webanwendungen umzusetzen.
Eine Modellierung der IaaS-Server als IT-Systeme im Sicherheitskonzept des Cloud-Diensteanbieters ist
möglich, allerdings nicht notwendig, da die Cloud-Anwender diese IT-Systeme verwalten.
Modellierung von PaaS-Angeboten
Bei PaaS (Platform as a Service) ist der Cloud-Diensteanbieter zusätzlich zu IaaS für die sichere Bereit­
stellung eines virtuellen Servers und einer angebotenen Plattform verantwortlich (z. B. einer Daten­
bank oder eines Webservers). Dementsprechend muss der Cloud-Diensteanbieter im Servicemodell
PaaS zunächst, wie bei IaaS, den Cloud-Verwaltungsserver und dessen Verwaltungssoftware model­
lieren. Dort erfolgt zentral die Zuordnung des Bausteins OPS.3.2 Cloud-Anbieter.
Darüber hinaus muss der Cloud-Diensteanbieter ein IT-System mit dem entsprechenden Betriebssys­
tem modellieren. Zu diesem IT-System ist je nach Cloud-Dienst auf Anwendungsschicht eine Daten­
bank oder ein Webserver zu modellieren.
Das PaaS-IT-System mit den verbundenen Cloud-Anwendungen muss für jeden Cloud-Mandanten
modelliert werden, wobei Mandanten mit gleichen Plattformen, gleichen Anwendungen und glei­
chem Schutzbedarf gemäß den Vorgaben in Kapitel 8.1.1 Komplexitätsreduktion durch Gruppenbil­
dung in einer Gruppe zusammengefasst werden können.
In der Praxis werden Cloud-Dienste des Servicemodells PaaS über virtuelle Profile bereitgestellt, die für
mehrere Cloud-Anwender bzw. Mandanten eingesetzt werden können. Es bietet sich daher in der
IT-Grundschutz-Modellierung an, diese Kombinationen in Form von Musterservern zu modellieren
und pro Mandant zu verknüpfen bzw. zu vervielfachen.
Modellierung von SaaS-Angeboten
Bei SaaS (Software as a Service) müssen zunächst die für die unterliegende Cloud-Infrastruktur rele­
vanten Zielobjekte wie bei IaaS und PaaS identifiziert und entsprechenden Bausteinen zugeordnet
werden.
Im Vergleich zu PaaS werden bei SaaS weitere Anwendungen auf den Cloud-IT-Systemen modelliert
(z. B. ein Webservice, eine Webanwendung oder ein SAP-System). Bei SaaS ist der Cloud-Dienstean­
bieter praktisch für den gesamten Cloud-Computing-Stack (Server, Netze, Storage, Management und
Anwendungen) verantwortlich. Die SaaS-Anwendungen liegen auch in seinem Verantwortungsbe­
reich und müssen somit in seinem Informationsverbund modelliert werden. Dabei können sowohl
mehrfache Ausprägungen derselben SaaS-Anwendung als auch Gruppen von SaaS-Anwendungen
gemäß den Vorgaben in Kapitel 8.1.1 zusammengefasst werden, wenn die dort angegebenen Vor­
aussetzungen erfüllt sind.
8.3.6 Anpassung der Baustein-Anforderungen
Über die Modellierung wurden die Bausteine des IT-Grundschutz-Kompendiums ausgewählt, die für
die einzelnen Zielobjekte des betrachteten Informationsverbunds umzusetzen sind. In den Bausteinen
werden die Sicherheitsanforderungen aufgeführt, die typischerweise für diese Komponenten geeig­
net und angemessen sind.
Für die Erstellung eines Sicherheitskonzepts oder für ein Audit müssen jetzt die einzelnen Anforde­
rungen bearbeitet und darauf aufbauend geeignete Sicherheitsmaßnahmen formuliert werden.
1428 Erstellung einer Sicherheitskonzeption nach Standard-Absicherung
Die Anforderungen sind knapp und präzise. Sie geben die Teilziele vor, die zusammen zur Umsetzung
der Ziele eines Bausteins beitragen. Die Sicherheitsanforderungen müssen daher noch in Handlungs­
vorgaben für die verschiedenen Akteure im Sicherheitsprozess umgewandelt werden. Dafür müssen
auf Basis der Anforderungen Sicherheitsmaßnahmen ausgearbeitet werden, die
• an die jeweiligen Rahmenbedingungen und den Sprachgebrauch einer Institution angepasst sein
müssen,
• ausreichend konkret sind, um im vorliegenden Informationsverbund angewendet zu werden, also
z. B. ausreichend technische Details enthalten.
Zu vielen Bausteinen des IT-Grundschutz-Kompendiums gibt es Umsetzungshinweise, in denen zu
den Sicherheitsanforderungen detailliertere Maßnahmen beschrieben sind. Diese Maßnahmen sind
einerseits so allgemein formuliert, dass sie in möglichst vielen Umgebungen anwendbar sind, und
andererseits so ausführlich, dass die Maßnahmenbeschreibungen als Umsetzungshilfe dienen kön­
nen.
Auch die in den Umsetzungshinweisen vorgeschlagenen Maßnahmen sollten noch an die jeweiligen
Rahmenbedingungen einer Institution angepasst werden. Es kann beispielsweise sinnvoll sein,
• Maßnahmen weiter zu konkretisieren, also z. B. um technische Details zu ergänzen,
• Maßnahmen dem Sprachgebrauch der Institution anzupassen, also z. B. andere Rollenbezeichnun­
gen zu verwenden, und
• aus Maßnahmen die im betrachteten Bereich nicht relevanten Empfehlungen zu streichen.
Um den Anwendern die zielgruppengerechte Anpassung der IT-Grundschutz-Texte zu erleichtern,
werden sämtliche Texte, Bausteine, Umsetzungshinweise, Tabellen und Hilfsmittel auch in elektroni­
scher Form zur Verfügung gestellt. Damit können diese Texte bei der Erstellung eines Sicherheitskon­
zepts und bei der Realisierung von Sicherheitsmaßnahmen weiterverwendet werden.
Bei der Sichtung der Sicherheitsanforderungen kann sich ergeben, dass einzelne Anforderungen un­
ter den konkreten Rahmenbedingungen nicht umgesetzt werden können. Dies kann beispielsweise
der Fall sein, wenn die Anforderungen in der betrachteten Umgebung nicht relevant sind (z. B. weil
Dienste nicht aktiviert wurden). In seltenen Fällen kann dies auch im Bereich der uneingeschränkt
notwendigen Basis-Anforderungen vorkommen, wenn deren Umsetzung essenzielle Schwierigkeiten
in anderen Bereichen mit sich bringen würde. Dies könnte beispielsweise der Fall sein, wenn sich
Anforderungen des Brand- und des Einbruchschutzes nicht miteinander vereinbaren lassen würden.
Dann müssten andere Lösungen gefunden und dies nachvollziehbar dokumentiert werden.
Werden Sicherheitsanforderungen zusätzlich aufgenommen oder geändert, muss dies im Sicherheits­
konzept dokumentiert werden. Dies erleichtert auch die Durchführung des IT-Grundschutz-Checks.
Bei der Auswahl und Anpassung der Sicherheitsmaßnahmen auf Basis der Anforderungen ist zu be­
achten, dass diese immer angemessen sein müssen. Angemessen bedeutet:
• Wirksamkeit (Effektivität): Sie müssen vor den möglichen Gefährdungen wirksam schützen, also
den identifizierten Schutzbedarf abdecken.
143
Generell sollten die Anforderungen der IT-Grundschutz-Bausteine immer sinngemäß umgesetzt wer­
den. Alle Änderungen gegenüber dem IT-Grundschutz-Kompendium sollten dokumentiert werden,
damit die Gründe auch später noch nachvollziehbar sind.8.3 Modellierung eines Informationsverbunds
• Eignung: Sie müssen in der Praxis tatsächlich umsetzbar sein, dürfen also z. B. nicht die Organisa­
tionsabläufe zu stark behindern oder andere Sicherheitsmaßnahmen aushebeln.
• Praktikabilität: Sie sollen leicht verständlich, einfach anzuwenden und wenig fehleranfällig sein.
• Akzeptanz: Sie müssen für alle Benutzer anwendbar (barrierefrei) sein und dürfen niemanden dis­
kriminieren oder beeinträchtigen.
• Wirtschaftlichkeit: Mit den eingesetzten Mitteln sollte ein möglichst gutes Ergebnis erreicht wer­
den. Die Sicherheitsmaßnahmen sollten also einerseits das Risiko bestmöglich minimieren und an­
dererseits in geeignetem Verhältnis zu den zu schützenden Werten stehen.
8.3.7 Einbindung externer Dienstleister
Viele Institutionen setzen externe oder interne Dienstleister ein, um Geschäftsprozesse ganz oder
teilweise durch diese durchführen zu lassen. Grundsätzlich kann die Einbindung externer Dienstleister
auf viele Arten erfolgen, z. B. in Form von Personal, das temporär eingesetzt wird, oder in Form von
Auslagerungen von IT-Systemen.
Bereits im Vorfeld der Einbindung externer Dienstleister müssen die Aufgaben im Bereich der Infor­
mationssicherheit abgegrenzt und die Schnittstellen genau festgelegt werden. Aufgaben können an
externe Dienstleister ausgelagert werden, die Verantwortung für die Informationssicherheit verbleibt
jedoch immer bei der auslagernden Institution.
Es muss geklärt sein, welche sicherheitsrelevanten Aufgaben durch den externen Dienstleister und
welche durch das eigene Sicherheitsmanagement abgedeckt werden. Folgende Fragen sollten vor der
Einbindung externer Dienstleister grundlegend geregelt werden:
• Welche Geschäftsprozesse, welche IT-Systeme oder welche Dienstleistungen sollen an einen exter­
nen Dienstleister ausgelagert werden?
• Welchen Schutzbedarf haben die Zielobjekte, die durch einen externen Dienstleister oder im Out­
sourcing verarbeitet werden?
• Auf welche Zielobjekte und welche Informationen hat der externe Dienstleister Zugriff? Hier muss
einerseits berücksichtigt werden, welche Zielobjekte und Informationen im Fokus der Dienstleis­
tungserbringung stehen, aber andererseits auch, auf welche Zielobjekte und Informationen die
Dienstleister zugreifen könnten, wie z. B. Reinigungskräfte auf Informationen in Büroräumen.
Sofern sich eine Institution für die Einbindung externer Dienstleister entscheidet, müssen neben
vertraglichen Rahmenbedingungen ebenfalls die Voraussetzungen für die Umsetzung der Anforde­
rungen des IT-Grundschutzes erfüllt werden. Generell muss die Modellierung der Bausteine ge­
trennt für die eigene Institution und für jeden externen Dienstleister durchgeführt werden. Die Vor­
gehensweise der Modellierung erfolgt wie in Kapitel 8.3.4 „Zuordnung von Bausteinen“ beschrie­
ben.
Auch bei der Einbindung externer Dienstleister muss es zu jedem Zeitpunkt für die auslagernde Insti­
tution möglich sein, die Risiken im Bereich der Informationssicherheit zu identifizieren und zu kontrol­
lieren. Informationen und Geschäftsprozesse müssen immer auf einem vergleichbaren Niveau gemäß
den Sicherheitszielen der Institution geschützt werden, auch wenn externe Dienstleister (oder wie­
derum deren Dienstleister) diese ganz oder in Teilen verarbeiten. Des Weiteren ist eine hohe Ereignis­
transparenz erforderlich, d. h., es muss Mechanismen geben, die gewährleisten, dass Gefährdungen
und Risiken, die Auswirkungen auf die Dienstleistungen haben könnten, erkannt und entsprechend
kommuniziert werden.
1448 Erstellung einer Sicherheitskonzeption nach Standard-Absicherung
Hierfür ist es erforderlich, Sicherheitsanforderungen sowie die regelmäßige Überwachung ihrer Ein­
haltung in den Verträgen aufzunehmen.
Bei der Einbindung externer Dienstleister ist es möglich, dass der Dienstleister bereits für die einge­
bundene Dienstleistung ein Zertifikat vorweisen kann. Hierbei muss immer berücksichtigt werden, ob
der Geltungsbereich des ausgestellten Zertifikates die Dienstleistung auch tatsächlich umfasst.
Aktionspunkte zu 8.3 Modellierung eines Informationsverbunds
• Kapitel Schichtenmodell und Modellierung aus dem IT-Grundschutz-Kompendium systematisch
durcharbeiten
• Zuordnung von Bausteinen zu Zielobjekten („IT-Grundschutz-Modell“) sowie die entsprechenden
Ansprechpartner dokumentieren
• Zielobjekte, die nicht geeignet modelliert werden können, für eine Risikoanalyse vormerken
• Festlegung einer Reihenfolge für die Umsetzung der Bausteine
• Sicherheitsanforderungen aus den identifizierten Bausteinen sorgfältig lesen und darauf aufbau­
end passende Sicherheitsmaßnahmen festlegen
8.4
IT-Grundschutz-Check
Für die nachfolgenden Betrachtungen wird vorausgesetzt, dass für einen ausgewählten Informations­
verbund folgende Teile des Sicherheitskonzepts nach IT-Grundschutz erstellt wurden:
Anhand der Strukturanalyse des Informationsverbunds wurde eine Übersicht über die vorhandenen
Geschäftsprozesse, die IT und deren Vernetzung, die unterstützten Anwendungen und die Räum­
lichkeiten erstellt. Darauf aufbauend wurde anschließend die Schutzbedarfsfeststellung durchge­
führt, deren Ergebnis eine Übersicht über den Schutzbedarf der Geschäftsprozesse, Anwendungen,
IT-Systeme, der genutzten Räume und der Kommunikationsverbindungen ist. Mithilfe dieser Infor­
mationen wurde die Modellierung des Informationsverbunds nach IT-Grundschutz durchgeführt.
Das Ergebnis war eine Abbildung des betrachteten Informationsverbunds auf Bausteine des
IT-Grundschutzes.
Die Modellierung nach IT-Grundschutz wird nun als Prüfplan benutzt, um anhand eines Soll-Ist-Ver­
gleichs herauszufinden, welche Anforderungen ausreichend oder nur unzureichend erfüllt wurden.
Dieses Kapitel beschreibt, wie bei der Durchführung des IT-Grundschutz-Checks vorgegangen wer­
den sollte. Der IT-Grundschutz-Check besteht aus drei unterschiedlichen Schritten. Im ersten Schritt
werden die organisatorischen Vorbereitungen getroffen, insbesondere die relevanten Ansprech­
partner für den Soll-Ist-Vergleich ausgewählt. Im zweiten Schritt wird der eigentliche Soll-Ist-Ver­
gleich mittels Interviews und stichprobenartiger Kontrolle durchgeführt. Im letzten Schritt werden
die erzielten Ergebnisse des Soll-Ist-Vergleichs einschließlich der erhobenen Begründungen doku­
mentiert.
Nachfolgend werden die Schritte des IT-Grundschutz-Checks detailliert beschrieben.
145
• Für jeden Baustein des IT-Grundschutz-Kompendiums ermitteln, auf welche Zielobjekte er im
betrachteten Informationsverbund anzuwenden ist8.4 IT-Grundschutz-Check
8.4.1 Organisatorische Vorarbeiten für den IT-Grundschutz-Check
Für die reibungslose Durchführung des Soll-Ist-Vergleichs sind einige Vorarbeiten erforderlich. Zu­
nächst sollten alle hausinternen Papiere, z. B. Organisationsverfügungen, Arbeitshinweise, Sicher­
heitsanweisungen, Handbücher und „informelle“ Vorgehensweisen, die die sicherheitsrelevanten
Abläufe regeln, gesichtet werden. Auch die Dokumentation der bereits umgesetzten Sicherheitsmaß­
nahmen gehört dazu. Diese Dokumente können bei der Ermittlung des Umsetzungsgrades hilfreich
sein, insbesondere bei Fragen nach bestehenden organisatorischen Regelungen. Weiterhin ist zu klä­
ren, wer gegenwärtig für deren Inhalt zuständig ist, um später die richtigen Ansprechpartner bestim­
men zu können.
Als Nächstes sollte festgestellt werden, ob und in welchem Umfang externe Stellen bei der Ermittlung
des Umsetzungsstatus beteiligt werden müssen. Dies kann beispielsweise bei externen Rechenzen­
tren, vorgesetzten Behörden, Firmen, die Teile von Geschäftsprozessen oder des IT-Betriebes als Out­
sourcing-Dienstleistung übernehmen, oder Baubehörden, die für infrastrukturelle Maßnahmen zu­
ständig sind, erforderlich sein.
Ein wichtiger Schritt vor der Durchführung des eigentlichen Soll-Ist-Vergleichs ist die Ermittlung ge­
eigneter Interviewpartner. Hierzu sollte zunächst für jeden einzelnen Baustein, der für die Modellie­
rung des vorliegenden Informationsverbunds herangezogen wurde, ein Hauptansprechpartner fest­
gelegt werden. Bei den Anforderungen in den Bausteinen werden die Rollen genannt, die für die
Umsetzung der Anforderungen erforderlich sind. Hieraus können die geeigneten Ansprechpartner
für die jeweilige Thematik in der Institution identifiziert werden. Nachfolgend finden sich einige Bei­
spiele für Ansprechpartner der verschiedenen Bereiche:
• Bei den Bausteinen der Schicht ORP, CON und OPS ergibt sich ein geeigneter Ansprechpartner in
der Regel direkt aus der im Baustein behandelten Thematik. Beispielsweise sollte für den Baustein
ORP.2 Personal ein Mitarbeiter der zuständigen Personalabteilung als Ansprechpartner ausgewählt
werden. Bei den konzeptionellen Bausteinen, z. B. Baustein CON.1 Kryptokonzept, steht im Ideal­
fall der Mitarbeiter zur Verfügung, der für die Fortschreibung des entsprechenden Dokuments zu­
ständig ist. Anderenfalls sollte derjenige Mitarbeiter befragt werden, zu dessen Aufgabengebiet
die Fortschreibung von Regelungen in dem betrachteten Bereich gehört.
• Im Bereich der Schicht INF (Infrastruktur) sollte die Auswahl geeigneter Ansprechpartner in Abstim­
mung mit der Abteilung Innerer Dienst/Haustechnik vorgenommen werden. Je nach Größe der
betrachteten Institution können beispielsweise unterschiedliche Ansprechpartner für die Infra­
strukturbereiche Gebäude und Technikräume zuständig sein. In kleinen Institutionen kann in vielen
Fällen der Hausmeister Auskunft geben. Zu beachten ist im Bereich der Infrastruktur, dass hier
unter Umständen externe Stellen zu beteiligen sind. Dies betrifft insbesondere größere Institutio­
nen.
• In den systemorientierten Bausteinen der Schichten SYS, NET und IND werden in den zu prüfenden
Sicherheitsmaßnahmen verstärkt technische Aspekte behandelt. In der Regel kommt daher der
Administrator derjenigen Komponente bzw. Gruppe von Komponenten, der der jeweilige Baustein
bei der Modellierung zugeordnet wurde, als Hauptansprechpartner infrage.
• Für die Bausteine der Schicht APP (Anwendungen) sollten die Betreuer bzw. die Verantwortlichen
der einzelnen Anwendungen als Hauptansprechpartner ausgewählt werden.
Für die anstehenden Interviews mit den Systemverantwortlichen, Administratoren und sonstigen An­
sprechpartnern sollte ein Terminplan erstellt werden. Ein besonderes Augenmerk gilt hier der Termin­
1468 Erstellung einer Sicherheitskonzeption nach Standard-Absicherung
koordination mit Personen aus anderen Organisationseinheiten oder anderen Institutionen. Zudem
erscheint es sinnvoll, bereits im Vorhinein Ausweichtermine abzustimmen.
Je nach Größe der Projektgruppe sollten für die Durchführung der Interviews Teams mit verteilten
Aufgaben gebildet werden. Es hat sich bewährt, in jeder Gruppe zwei Personen für die Durchführung
des Interviews einzuplanen. Dabei stellt eine Person die notwendigen Fragen und die andere Person
notiert die Ergebnisse und Anmerkungen, die durch den Interviewpartner gegeben werden.
147148
entbehrlich
die
Leitlinie
unterzeichnet.
gesamte
Informationssicherheit
delegiert
geforderten
erhält
ment-Report,
tus
8.4 IT-Grundschutz-CheckProzesse
Audit
entsprechende
die
antwortungsbereich
fallen.
8 Erstellung einer Sicherheitskonzeption nach Standard-Absicherung
1498.4 IT-Grundschutz-Check
Aktionspunkte zu 8.4.1 Organisatorische Vorarbeiten des IT-Grundschutz-Checks
• Hausinterne Dokumente mit Verfügungen und Regelungen sichten und Zuständigkeiten für diese
Unterlagen klären
• Feststellen, in welchem Umfang externe Stellen beteiligt werden müssen
• Hauptansprechpartner für jeden in der Modellierung angewandten Baustein festlegen
• Terminplan für Interviews abstimmen
• Team für Interviews zusammenstellen
8.4.2 Durchführung des Soll-Ist-Vergleichs
Sind alle erforderlichen Vorarbeiten erledigt, kann die eigentliche Erhebung an den zuvor festgesetz­
ten Terminen beginnen. Hierzu werden die Sicherheitsanforderungen des jeweiligen Bausteins, für
den die Interviewpartner zuständig sind, der Reihe nach durchgearbeitet.
Als Antworten bezüglich des Umsetzungsstatus der einzelnen Anforderungen kommen folgende
Aussagen in Betracht:
„entbehrlich“ Die Erfüllung der Anforderung ist in der vorgeschlagenen Art nicht notwendig, weil
die Anforderung im betrachteten Informationsverbund nicht relevant ist (z. B. weil
Dienste nicht aktiviert wurden) oder durch Alternativmaßnahmen behandelt wurde.
Wird der Umsetzungsstatus einer Anforderung auf „entbehrlich“ gesetzt, müssen
über die Kreuzreferenztabelle des jeweiligen Bausteins die zugehörigen elementa­
ren Gefährdungen identifiziert werden. Wurden Alternativmaßnahmen ergriffen,
muss begründet werden, dass das Risiko, das von allen betreffenden elementaren
Gefährdungen ausgeht, angemessen minimiert wurde. Generell ist zu beachten,
dass bei Basis-Anforderungen das entstehende Risiko nicht übernommen werden
kann.
Anforderungen dürfen nicht auf „entbehrlich“ gesetzt werden, wenn das Risiko für
eine im Baustein identifizierte elementare Gefährdung über die Kreuzreferenztabel­
le pauschal akzeptiert oder ausgeschlossen wird.
„ja“ Zu der Anforderung wurden geeignete Maßnahmen vollständig, wirksam und ange­
messen umgesetzt.
„teilweise“ Die Anforderung wurde nur teilweise umgesetzt.
„nein“ Die Anforderung wurde noch nicht erfüllt, also geeignete Maßnahmen sind größten­
teils noch nicht umgesetzt.
Es ist sinnvoll, bei den Interviews nicht nur die Bausteintexte, sondern auch die Umsetzungshinweise
oder andere ergänzende Materialien griffbereit zu haben. Den Befragten sollte der Zweck des
IT-Grundschutz-Checks kurz vorgestellt werden. Es bietet sich an, mit den Anforderungsüberschriften
fortzufahren und die Anforderungen kurz zu erläutern. Dem Gesprächspartner sollte die Möglichkeit
gegeben werden, auf die bereits umgesetzten Anforderungen und Maßnahmen einzugehen und
danach noch offene Punkte zu besprechen.
Die Befragungstiefe richtet sich zunächst nach dem Niveau von Basis- und Standard-Anforderungen;
über diese hinausweisende Aspekte hochschutzbedürftiger Anwendungen sollten erst nach Ab­
schluss des IT-Grundschutz-Checks betrachtet werden. Falls der Bedarf besteht, die in den Interviews
gemachten Aussagen zu verifizieren, bietet es sich an, stichprobenartig die entsprechenden Regelun­
1508 Erstellung einer Sicherheitskonzeption nach Standard-Absicherung
gen und Konzepte zu sichten, im Bereich Infrastruktur gemeinsam mit dem Ansprechpartner die zu
untersuchenden Objekte vor Ort zu besichtigen sowie Client- bzw. Servereinstellungen an ausgewähl­
ten IT-Systemen zu überprüfen.
Zum Abschluss jedes Bausteins sollte den Befragten das Ergebnis (Umsetzungsstatus der Anforderun­
gen: entbehrlich/ja/teilweise/nein) mitgeteilt und diese Entscheidung erläutert werden.
Aktionspunkte zu 8.4.2 Durchführung des Soll-Ist-Vergleichs
• Je nach Fachgebiet vorab Checklisten erstellen
• Zielsetzung des IT-Grundschutz-Checks den Interviewpartner n erläutern
• Umsetzungsstatus der einzelnen Anforderungen erfragen
• Den Befragten die Ergebnisse mitteilen
8.4.3 Dokumentation der Ergebnisse
Die Ergebnisse des IT-Grundschutz-Checks sollten so dokumentiert werden, dass sie für alle Beteilig­
ten nachvollziehbar sind und als Grundlage für die Umsetzungsplanung der defizitären Anforderun­
gen und Maßnahmen genutzt werden können. Der Dokumentationsaufwand sollte nicht unter­
schätzt werden. Daher sollten geeignete Hilfsmittel genutzt werden, die bei der Erstellung und Ak­
tualisierung aller im Sicherheitsprozess erforderlichen Dokumente unterstützen.
Dies können zum einen geeignete IT-Grundschutz-Tools sein, also Anwendungen, die die gesamte
Vorgehensweise nach IT-Grundschutz unterstützen, beginnend bei der Stammdatenerfassung, über
die Schutzbedarfsfeststellung, die Risikoanalyse sowie den Soll-Ist-Vergleich (IT-Grundschutz-Check)
bis hin zur Erfüllung der Anforderungen. Hierdurch ergeben sich komfortable Möglichkeiten zur Aus­
wertung und Revision der Ergebnisse, z. B. die Suche nach bestimmten Einträgen, die Generierung
von Reports, Kostenauswertungen sowie Statistikfunktionen.
Des Weiteren stehen als Hilfsmittel zum IT-Grundschutz Formulare zur Verfügung. Zu jedem Baustein
des IT-Grundschutz-Kompendiums gibt es eine Datei, in der tabellarisch für jede Anforderung des
Bausteins die Ergebnisse des Soll-Ist-Vergleichs erfasst werden können.
Zur Dokumentation des IT-Grundschutz-Checks sollten erfasst werden:
• Die Nummer und die Bezeichnung des Objektes oder Gruppe von Objekten, der der Baustein bei
der Modellierung zugeordnet wurde,
• der Standort der zugeordneten Objekte bzw. Gruppe von Objekten,
• das Erfassungsdatum und der Name des Erfassers und
• die befragten Ansprechpartner.
Die eigentlichen Ergebnisse des Soll-Ist-Vergleichs sollten tabellarisch erfasst werden. Dabei sollten zu
jeder Anforderung des jeweiligen Bausteins folgende Informationen festgehalten werden:
• Umsetzungsgrad (entbehrlich/ja/teilweise/nein)
Der im Interview ermittelte Umsetzungsstatus der jeweiligen Anforderung ist zu erfassen. Im Hin­
blick auf eine mögliche Zertifizierung sollte zudem festgehalten werden, durch welche Maßnah­
men die Anforderungen konkret erfüllt werden.
151
• Antworten anhand von Stichproben am Objekt verifizieren8.5 Risikoanalyse
• Umsetzung bis . . .
Ein solches Feld ist sinnvoll, auch wenn es während eines IT-Grundschutz-Checks im Allgemeinen
nicht ausgefüllt wird. Es dient als Platzhalter, um in der Realisierungsplanung an dieser Stelle zu
dokumentieren, bis zu welchem Termin die Anforderung vollständig umgesetzt sein soll.
• Verantwortliche
Falls es bei der Durchführung des Soll-Ist-Vergleichs eindeutig ist, welche Mitarbeiter für die voll­
ständige Umsetzung einer defizitären Anforderung oder Maßnahme verantwortlich sind, sollte das
namentlich in diesem Feld dokumentiert werden. Falls die Verantwortung nicht eindeutig erkenn­
bar ist, sollte das Feld frei gelassen werden. Im Zuge der späteren Realisierungsplanung ist dann ein
Verantwortlicher zu bestimmen, dessen Name hier eingetragen werden kann.
• Bemerkungen/Begründungen
Ein solches Feld ist wichtig, um getroffene Entscheidungen später nachvollziehen zu können, bei­
spielsweise für die Zertifizierung. Bei Anforderungen, deren Umsetzung entbehrlich erscheint, ist
hier die Begründung zu nennen. Bei Anforderungen, die noch nicht oder nur teilweise umgesetzt
sind, sollte in diesem Feld dokumentiert werden, welche Maßnahmen noch umgesetzt werden
müssen. In dieses Feld sollten auch alle anderen Bemerkungen eingetragen werden, die bei der
Beseitigung von Defiziten hilfreich oder im Zusammenhang mit der Anforderung zu berücksichti­
gen sind.
• Defizite/Kostenschätzung
Für Anforderungen, die nicht oder nur teilweise erfüllt wurden, ist das damit verbundene Risiko in
geeigneter Form zu ermitteln und zu dokumentieren. Dies ist beispielsweise für Audits und Zerti­
fizierungen wichtig. Bei solchen Maßnahmen sollte außerdem geschätzt werden, welchen finan­
ziellen und personellen Aufwand die Beseitigung der Defizite erfordert.
Aktionspunkte zu 8.4.3 Dokumentation der Ergebnisse
• Stamminformationen über jedes Zielobjekt erfassen
• Informationen zum IT-Grundschutz-Check und zum Umsetzungsstatus dokumentieren
• Felder beziehungsweise Platzhalter für die Realisierungsplanung vorsehen
8.5
Risikoanalyse
Eine Risikoanalyse im Kontext der Informationssicherheit hat die Aufgabe, relevante Gefährdungen
für den Informationsverbund zu identifizieren und die daraus möglicherweise resultierenden Risiken
abzuschätzen. Das Ziel ist es, die Risiken durch angemessene Gegenmaßnahmen auf ein akzeptables
Maß zu reduzieren, die Restrisiken transparent zu machen und dadurch das Gesamtrisiko systema­
tisch zu steuern.
Zweistufiger Ansatz der IT-Grundschutz-Vorgehensweise
In der Vorgehensweise nach IT-Grundschutz wird bei der Erstellung der IT-Grundschutz-Bausteine
implizit eine Risikobewertung für Bereiche mit normalem Schutzbedarf durchgeführt. Hierbei werden
nur solche Gefährdungen betrachtet, die nach sorgfältiger Analyse eine so hohe Eintrittswahrschein­
lichkeit oder so einschneidende Auswirkungen haben, dass Sicherheitsmaßnahmen ergriffen werden
müssen. Typische Gefährdungen, gegen die sich jeder schützen muss, sind z. B. Schäden durch Feuer,
Einbrecher, Schadsoftware oder Hardware-Defekte. Dieser Ansatz hat den Vorteil, dass Anwender des
IT-Grundschutzes für einen Großteil des InformationsverbundesInformationsverbunds keine individu­
1528 Erstellung einer Sicherheitskonzeption nach Standard-Absicherung
elle Bedrohungs- und Schwachstellenanalyse durchführen müssen, weil diese Bewertung vorab be­
reits vorgenommen wurde.
In bestimmten Fällen muss jedoch eine explizite Risikoanalyse durchgeführt werden, beispielsweise
wenn der betrachtete Informationsverbund Zielobjekte enthält, die
• einen hohen oder sehr hohen Schutzbedarf in mindestens einem der drei Grundwerte Vertraulich­
keit, Integrität oder Verfügbarkeit haben oder
• mit den existierenden Bausteinen des IT-Grundschutzes nicht hinreichend abgebildet (modelliert)
werden können oder
• in Einsatzszenarien (Umgebung, Anwendung) betrieben werden, die im Rahmen des IT-Grund­
schutzes nicht vorgesehen sind.
• Welchen Gefährdungen für die Informationsverarbeitung ist durch die Umsetzung der relevanten
IT-Grundschutz-Bausteine noch nicht ausreichend oder sogar noch gar nicht Rechnung getragen
worden?
• Müssen eventuell ergänzende Sicherheitsmaßnahmen, die über das IT-Grundschutz-Modell hin­
ausgehen, eingeplant und umgesetzt werden?
Zur Beantwortung dieser Fragen empfiehlt das BSI die Anwendung einer Risikoanalyse auf der Basis
von IT-Grundschutz, wie sie im BSI-Standard 200-3 beschrieben ist.
In dem Standard wird dargestellt, wie für bestimmte Zielobjekte festgestellt werden kann, ob und in
welcher Hinsicht über den IT-Grundschutz hinaus Handlungsbedarf besteht, um Risiken für die Infor­
mationsverarbeitung zu reduzieren. Hierzu werden Risiken, die von elementaren Gefährdungen aus­
gehen, eingeschätzt und anhand einer Matrix bewertet. Die Einschätzung erfolgt über die zu erwar­
tende Häufigkeit des Eintretens und die Höhe des Schadens, der bei Eintritt des Schadensereignisses
entsteht. Aus diesen beiden Anteilen ergibt sich das Risiko. Die Methodik lässt sich wie folgt in den
IT-Grundschutz-Prozess integrieren:
Abbildung 32: Integration der Risikoanalyse in den IT-Grundschutz-Prozess
153
In diesen Fällen stellen sich folgende Fragen:8.5 Risikoanalyse
Der Standard bietet sich an, wenn Institutionen bereits erfolgreich mit der IT-Grundschutz-Methodik ar­
beiten und möglichst direkt eine Risikoanalyse an die IT-Grundschutz-Analyse anschließen möchten. Hier­
zu empfiehlt der BSI-Standard 200-3 Risikoanalyse auf der Basis von IT-Grundschutz folgende zusätzliche
Arbeitsschritte, die hier kurz im Überblick aufgeführt sind:
• Etablierung eines Risikomanagementprozesses
Die Risikoanalyse ist ein wichtiger Bestandteil des Managementsystems für Informationssicherheit
(ISMS). Daher sollten die Grundvoraussetzungen dafür von der Institutionsleitung vorgegeben
werden. Die grundsätzliche Vorgehensweise der Institution zur Durchführung von Risikoanalysen
sollte in einer Richtlinie (siehe BSI-Standard 200-3, Kapitel 2) dokumentiert und durch die Leitungs­
ebene verabschiedet werden.
• Erstellung der Gefährdungsübersicht
In diesem Arbeitsschritt wird für jedes zu analysierende Zielobjekt eine Liste der jeweils relevanten
Gefährdungen zusammengestellt. Bei der Ermittlung von Gefährdungen geht das BSI zweistufig
vor. Zunächst werden die relevanten elementaren Gefährdungen identifiziert und darauf aufbau­
end werden weitere mögliche Gefährdungen (zusätzliche Gefährdungen) ermittelt, die über die
elementaren Gefährdungen hinausgehen und sich aus dem spezifischen Einsatzszenario ergeben.
Dies erfolgt im Rahmen eines gemeinsamen Brainstormings.
• Risikoeinstufung
Die Risikoanalyse ist zweistufig angelegt. Für jedes Zielobjekt und jede Gefährdung wird eine Be­
wertung unter der Annahme vorgenommen, dass bereits Sicherheitsmaßnahmen umgesetzt oder
geplant worden sind. In der Regel wird es sich hierbei um Sicherheitsmaßnahmen handeln, die aus
den Basis- und Standard-Anforderungen des IT-Grundschutz-Kompendiums abgeleitet worden
sind. An die erste Bewertung schließt sich eine zweite an, bei der mögliche Sicherheitsmaßnahmen
zur Risikobehandlung betrachtet werden. Durch einen Vorher-Nachher-Vergleich lässt sich die
Wirksamkeit der Sicherheitsmaßnahmen prüfen, die zur Risikobehandlung eingesetzt worden
sind.
• Behandlung von Risiken
Abhängig vom Risikoappetit einer Institution sind jeweils unterschiedliche Risikoakzeptanzkriterien
möglich. Risikoappetit bezeichnet die durch kulturelle, interne, externe oder wirtschaftliche Ein­
flüsse entstandene Neigung einer Institution, wie sie Risiken bewertet und mit ihnen umgeht. Es
gibt folgende Optionen zur Behandlung von Risiken:
• Risiken können vermieden werden (z. B. durch Umstrukturierung von Geschäftsprozessen oder des
Informationsverbunds).
• Risiken können durch entsprechende Sicherheitsmaßnahmen reduziert werden.
• Risiken können transferiert werden (z. B. durch Outsourcing oder Versicherungen).
Daran anschließend muss eine Institution Risikoakzeptanzkriterien festlegen und die Behandlung des
Risikos darauf abbilden. Bei der Entscheidung, wie mit den identifizierten Risiken umzugehen ist, muss
auf jeden Fall die Leitungsebene beteiligt werden, da sich daraus unter Umständen erhebliche Schä­
den ergeben oder zusätzliche Kosten entstehen können.
Die Schritte Gefährdungsbewertung und Risikobehandlung werden so lange durchlaufen, bis die Ri­
sikoakzeptanzkriterien der Institution erfüllt sind und das verbleibende Risiko („Restrisiko“) im Ein­
klang mit den Zielen und Vorgaben der Institution steht. Das verbleibende Risiko muss anschließend
1548 Erstellung einer Sicherheitskonzeption nach Standard-Absicherung
der Leitungsebene zur Zustimmung vorgelegt werden („Risiko-Akzeptanz“). Damit wird nachvoll­
ziehbar dokumentiert, dass die Institution sich des Restrisikos bewusst ist.
• Konsolidierung des Sicherheitskonzepts
Bevor der originäre IT-Grundschutz-Prozess fortgesetzt werden kann, muss das erweiterte Si­
cherheitskonzept konsolidiert werden. Dabei werden die Eignung, das Zusammenwirken, die
Benutzerfreundlichkeit und die Angemessenheit der Sicherheitsmaßnahmen insgesamt über­
prüft.
• Außerdem wird im BSI-Standard 200-3 Risikoanalyse auf der Basis von IT-Grundschutz erläutert,
wie die Methodik anzuwenden ist, wenn der Informationsverbund Zielobjekte umfasst, für die im
IT-Grundschutz-Kompendium bislang kein geeigneter Baustein enthalten ist.
Wichtig:
Die Risikoanalyse auf der Basis von IT-Grundschutz ist eine Vorgehensweise, um bei Bedarf Si­
cherheitsvorkehrungen zu ermitteln, die fber die im IT-Grundschutz-Kompendium genannten
Sicherheitsanforderungen hinausgehen. Obwohl diese Methodik gegenfber vielen anderen
ähnlichen Verfahren vereinfacht wurde, ist sie oft mit erheblichem Aufwand verbunden. Um
schnellstmöglich die wichtigsten Sicherheitsprobleme zu beseitigen, ist es manchmal zweckmä­
ßig, zuerst die IT-Grundschutz-Anforderungen vollständig zu erffllen und erst danach eine Risi­
koanalyse durchzuffhren (abweichend von obigem Schema). Dadurch mfssen zwar insgesamt
einige Schritte öfter durchlaufen werden, die IT-Grundschutz-Anforderungen werden jedoch
frfher erffllt.
Diese alternative Reihenfolge bietet sich besonders dann an, wenn
• der betrachtete Informationsverbund bereits realisiert und in Betrieb ist und
• die vorliegenden Zielobjekte mit den existierenden Bausteinen des IT-Grundschutz-Kompendiums
hinreichend modelliert werden können.
Für geplante Informationsverbünde oder für solche mit untypischen Techniken bzw. Einsatzszenarien
wird dagegen die oben abgebildete originäre Reihenfolge empfohlen. Die folgende Tabelle fasst die je­
weiligen Vor- und Nachteile der beiden alternativen Reihenfolgen zusammen:
155
Eine ausführliche Darstellung der Methodik findet sich im BSI-Standard 200-3.8.5 Risikoanalyse
Risikoanalyse direkt nach dem IT-Grund­ Risikoanalyse erst nach vollständiger Um­
schutz-Check
setzung der Sicherheitsmaßnahmen
Mögliche Vorteile:
Mögliche Vorteile:
• Es wird Mehraufwand vermieden, da keine • Sicherheitsmaßnahmen werden früher um-
Maßnahmen umgesetzt werden, die im Rah-
gesetzt, da die Risikoanalyse häufig aufwen­
men der Risikoanalyse eventuell durch stärkere
dig ist.
Maßnahmen ersetzt werden.
• Elementare Sicherheitslücken werden vor­
• Eventuell erforderliche Hochsicherheitsmaß­
rangig behandelt, bevor fortgeschrittene
nahmen werden früher identifiziert und umge-
Gefährdungen analysiert werden.
setzt.
Mögliche Nachteile:
Mögliche Nachteile:
• Sicherheitsmaßnahmen werden später umge­ • Es kann Mehraufwand entstehen, da even­
setzt, da die Risikoanalyse häufig aufwendig ist.
tuell einige Sicherheitsmaßnahmen umge­
setzt werden, die später im Rahmen der Risi­
• Eventuell werden elementare Sicherheitslücken
koanalyse durch stärkere Maßnahmen er­
vernachlässigt, während fortgeschrittene Ge­
setzt werden.
fährdungen analysiert werden.
• Eventuell erforderliche Hochsicherheitsmaß­
nahmen werden erst später identifiziert und
umgesetzt.
Tabelle 7: Vor- und Nachteile der alternativen Reihenfolgen bei der Risikoanalyse
Wichtig ist außerdem, dass eine Risikoanalyse auf der Basis von IT-Grundschutz häufig leichter durch­
zuführen ist, wenn sie nacheinander auf kleine Teilaspekte des Informationsverbunds angewandt
wird. Als ersten Schritt kann die Analyse beispielsweise auf die baulich-physische Infrastruktur be­
schränkt werden, d. h. auf den Schutz vor Brand, Wasser und unbefugtem Zutritt sowie auf die ord­
nungsgemäße Strom- und Klimaversorgung.
In vielen Behörden und Unternehmen existieren bereits Verfahren zur Risikoanalyse beziehungsweise
zur Risikobehandlung. Um eine einheitliche Methodik zu erreichen, kann es in solchen Fällen zweck­
mäßig sein, die vorhandenen Verfahren auf die Informationssicherheit auszudehnen und gegebenen­
falls nur Teilaspekte des BSI-Standards 200-3 anzuwenden. International haben sich eine Reihe von
unterschiedlichen Ansätzen zur Durchführung von Risikoanalysen im Bereich der Informationssicher­
heit etabliert. Diese Verfahren unterscheiden sich beispielsweise in Bezug auf den Detaillierungsgrad,
die Formalisierung und die thematischen Schwerpunkte. Abhängig von den Rahmenbedingungen
einer Institution und der Art des Informationsverbunds kann es zweckmäßig sein, alternativ zum
BSI-Standard 200-3 ein anderes etabliertes Verfahren oder eine angepasste Methodik für die Analyse
von Informationsrisiken zu verwenden.
1568 Erstellung einer Sicherheitskonzeption nach Standard-Absicherung
Aktionspunkte zu 8.5 Risikoanalyse
• Grundsätzliche Vorgehensweise der Institution zur Durchführung von Risikoanalysen in einer
Richtlinie dokumentieren und der Leitungsebene zur Verabschiedung vorlegen
• Ermitteln, für welche Zielobjekte oder Gruppen von Zielobjekten eine Risikoanalyse durchgeführt
werden soll
• BSI-Standard 200-3 Risikoanalyse auf der Basis von IT-Grundschutz systematisch durcharbeiten
• Ergebnisse der Risikoanalysen in das Sicherheitskonzept integrierenErstellung einer Sicherheitskonzeption nach der Vorgehens­
weise der Standard-Absicherung
Eines der Ziele der Standard-Absicherung des IT-Grundschutzes ist es, eine pragmatische und effektive
Vorgehensweise zur Erzielung eines normalen Sicherheitsniveaus anzubieten, das auch als Basis für
ein höheres Sicherheitsniveau dienen kann.
Nachdem ein Informationssicherheitsprozess initiiert, die Sicherheitsleitlinie und Informationssicher­
heitsorganisation definiert wurden, wird die Sicherheitskonzeption für die Institution erstellt. Als
Grundlage hierfür finden sich in den Bausteinen des IT-Grundschutz-Kompendiums Sicherheitsanfor­
derungen nach dem jeweiligen Stand der Technik für typische Komponenten von Geschäftsprozes­
sen, Anwendungen, IT-Systemen usw. Diese sind in Bausteinen strukturiert, sodass sie modular auf­
einander aufsetzen.
Abbildung 11: Erstellung der Sicherheitskonzeption bei der Standard-Absicherung
Die Durchführung einer Standard-Absicherung nach IT-Grundschutz gliedert sich in die nachfolgen­
den Aktionsfelder:
Festlegung des Geltungsbereichs
Bei der Entscheidung für die weitere Vorgehensweise (siehe Kapitel 3.3) wurde auch der Geltungsbe­
reich festgelegt, für den die Sicherheitskonzeption erstellt und umgesetzt werden soll. Dies können
beispielsweise bestimmte Organisationseinheiten einer Institution sein. Es könnten aber auch Berei­
che sein, die definierte Geschäftsprozesse oder Fachaufgaben bearbeiten, inklusive der dafür notwen­
digen Infrastruktur. Im IT-Grundschutz wird der Geltungsbereich für die Sicherheitskonzeption auch
als „Informationsverbund“ bezeichnet. Die Bestandteile des betrachteten Informationsverbunds sind
768 Erstellung einer Sicherheitskonzeption nach Standard-Absicherung
die mit den passenden Bausteinen des IT-Grundschutz-Kompendiums abzusichernden Komponen­
ten.
Strukturanalyse
Für die Erstellung eines Sicherheitskonzepts nach der Vorgehensweise Standard-Absicherung und
insbesondere für die Anwendung des IT-Grundschutz-Kompendiums ist es erforderlich, das Zusam­
menspiel der Geschäftsprozesse, der Anwendungen und der vorliegenden Informationstechnik zu
analysieren und zu dokumentieren. Aufgrund der heute üblichen starken Vernetzung von IT-Syste­
men, die sich auch auf die Bereiche ICS und IoT erstreckt, bietet sich ein Netztopologieplan als Aus­
gangsbasis für die weitere technische Analyse an. Die folgenden Aspekte müssen berücksichtigt wer­
den:
• die organisatorischen und personellen Rahmenbedingungen für den Informationsverbund,
• im Informationsverbund eingesetzte vernetzte und nicht vernetzte IT-Systeme, ICS- und IoT-Kom­
ponenten,
• die Kommunikationsverbindungen dazwischen und nach außen,
• die vorhandene Infrastruktur.
Die einzelnen Schritte der Strukturanalyse werden im Detail in Kapitel 8.1 dieses Dokuments in Form
einer Handlungsanweisung beschrieben.
Schutzbedarfsfeststellung
Zweck der Schutzbedarfsfeststellung ist es, zu ermitteln, welcher Schutz für die Geschäftsprozesse,
die dabei verarbeiteten Informationen und die eingesetzte Informationstechnik ausreichend und an­
gemessen ist. Hierzu werden für jede Anwendung und die verarbeiteten Informationen die zu erwar­
tenden Schäden betrachtet, die bei einer Beeinträchtigung von Vertraulichkeit, Integrität oder Ver­
fügbarkeit entstehen können. Wichtig ist es dabei auch, die möglichen Folgeschäden realistisch ein­
zuschätzen. Hierfür hat sich eine Einteilung in die drei Schutzbedarfskategorien „normal“, „hoch“
und „sehr hoch“ bewährt.
Die einzelnen Schritte der Schutzbedarfsfeststellung werden in Kapitel 8.2 ausführlicher verhandelt.
Auswahl von Anforderungen und Anpassung von Maßnahmen (Modellierung)
Die Voraussetzung für die Anwendung des IT-Grundschutz-Kompendiums auf einen Informationsver­
bund sind detaillierte Unterlagen über seine Struktur und den Schutzbedarf der darin enthaltenen
Zielobjekte. Diese Informationen sollten über die zuvor beschriebenen Arbeitsschritte ermittelt wer­
den. Um geeignete Sicherheitsanforderungen und darüber umzusetzende Maßnahmen für den vor­
liegenden Informationsverbund identifizieren zu können, müssen anschließend die Bausteine des
IT-Grundschutz-Kompendiums auf die Zielobjekte und Teilbereiche abgebildet werden.
Dieser Vorgang der Modellierung wird in Kapitel 8.3 detailliert besprochen.
IT-Grundschutz-Check
Der IT-Grundschutz-Check ist ein Organisationsinstrument, das einen schnellen Überblick über das
vorhandene Sicherheitsniveau bietet. Mithilfe von Interviews wird der Status quo eines bestehenden
(nach IT-Grundschutz modellierten) Informationsverbunds in Bezug auf den Umsetzungsgrad der Si­
cherheitsanforderungen des IT-Grundschutz-Kompendiums ermittelt. Als Ergebnis liegt ein Katalog
77
• im Informationsverbund betriebene Anwendungen und die dadurch gestützten Geschäftsprozes­
se,8.1 Strukturanalyse
vor, in dem für jede relevante Anforderung der Umsetzungsstatus „entbehrlich“, „ja“, „teilweise“
oder „nein“ erfasst ist. Durch die Identifizierung von noch nicht oder nur teilweise erfüllten Anforde­
rungen werden Verbesserungsmöglichkeiten für die Sicherheit der betrachteten Geschäftsprozesse
und der Informationstechnik aufgezeigt.
Kapitel 8.4 beschreibt einen Aktionsplan für die Durchführung eines IT-Grundschutz-Checks. Dabei
wird sowohl den organisatorischen Aspekten als auch den fachlichen Anforderungen bei der Projekt­
durchführung Rechnung getragen.
Risikoanalyse
Durch die Umsetzung der Sicherheitsanforderungen der Standard-Absicherung wird im Normalfall für
einen Informationsverbund ein angemessener und ausreichender Schutz erzielt. Bei einem hohen
oder sehr hohen Schutzbedarf kann es jedoch sinnvoll sein, zu prüfen, ob zusätzlich oder ersatzweise
höherwertige Sicherheitsmaßnahmen erforderlich sind. Dies gilt auch, wenn besondere Einsatzbedin­
gungen vorliegen oder wenn Komponenten verwendet werden, die nicht mit den existierenden Bau­
steinen des IT-Grundschutz-Kompendiums abgebildet werden können. In diesen Fällen ist eine Risi­
koanalyse durchzuführen. Sie sollte in regelmäßigen Abständen aktualisiert werden, damit auch ge­
änderte Gefährdungslagen schnell erkannt werden können.
Eine Methode für Risikoanalysen ist die im BSI-Standard 200-3 Risikoanalyse auf der Basis von
IT-Grundschutz beschriebene Vorgehensweise. In Kapitel 8.5 wird diese Methode überblicksartig dar­
gestellt. Die erfolgreiche Durchführung einer Risikoanalyse hängt entscheidend von den Fachkennt­
nissen des Projektteams ab. Daher ist es häufig sinnvoll, fachkundiges externes Personal hinzuzuzie­
hen.
Reihenfolge der Bearbeitung
Die verschiedenen Aktivitäten, die zur Erstellung einer Sicherheitskonzeption erforderlich sind, also
Strukturanalyse, Schutzbedarfsfeststellung, Modellierung eines Informationsverbunds, IT-Grund­
schutz-Check, Risikoanalyse, müssen nicht zwingend nacheinander abgearbeitet werden. Diese Ak­
tionsfelder können, soweit dies je nach vorhandenen Rahmenbedingungen und Größe des Sicher­
heitsteams möglich ist, auch unabhängig und zeitgleich durchgeführt werden.
8.1
Strukturanalyse
Die Strukturanalyse dient der Vorerhebung von Informationen, die für die weitere Vorgehensweise in
der Erstellung eines Sicherheitskonzepts nach IT-Grundschutz benötigt werden. Dabei geht es um die
Erfassung der Bestandteile (Geschäftsprozesse, Informationen, Anwendungen, IT- und ICS-Systeme,
Räume, Kommunikationsnetze), die zur Betrachtung des Geltungsbereichs benötigt werden.
Hinweis:
Häufig sind die Geschäftsprozesse noch nicht, nicht durchgängig oder nicht aktuell erfasst. Dann
mfssen zuerst die relevanten Geschäftsprozesse identifiziert werden, z. B. durch eine Auswer­
tung von Geschäftsverteilungsplänen, Aufgabenbeschreibungen oder anderen organisationsbe­
schreibenden Papieren.
Dazu müssen die für die Institution wesentlichen Geschäftsprozesse sowie die geschäftskritischen Infor­
mationen und Anwendungen ermittelt und die betroffenen IT-, ICS- oder IoT-Systeme, Räume und Netze
erfasst werden. Die klassische Vorgehensweise ist, zuerst die Anwendungen und ausgehend davon die
weiteren betroffenen Objekte zu ermitteln. Dieser Ansatz hat den Nachteil, dass es häufig schwierig ist,
788 Erstellung einer Sicherheitskonzeption nach Standard-Absicherung
abstrakte Anwendungen losgelöst von konkreten technischen Komponenten zu erfassen. Daher kann
es in einigen Fällen zweckmäßig sein, abweichend von der hier dargestellten Reihenfolge zunächst die
IT- und ICS-Systeme zu erheben, da sich die Anwendungen häufig anhand der betrachteten Systeme
leichter ermitteln lassen.
Zu beachten ist, dass die Objekte und Daten, die im Rahmen einer Strukturanalyse erfasst werden,
meist nicht nur für den Sicherheitsprozess, sondern auch für betriebliche Aspekte und die Verwaltung
erforderlich sind. Es sollte daher geprüft werden, ob bereits Datenbanken oder Übersichten gepflegt
werden, die im Rahmen der Strukturanalyse als Datenquellen genutzt werden könnten. In vielen In­
stitutionen werden beispielsweise Datenbanken für die Inventarisierung, das Konfigurationsmanage­
ment oder die Gestaltung von Geschäftsprozessen betrieben. Dadurch können sich Synergien erge­
ben.
• Erfassung der zum Geltungsbereich zugehörigen Geschäftsprozesse, Anwendungen und Informa­
tionen
• Netzplanerhebung
• Erhebung von IT-, ICS- und IoT-Systemen und ähnlichen Objekten
• Erfassung der Räume und Gebäude (für den ICS-Bereich sind auch die produzierenden Räumlich­
keiten zu berücksichtigen)
Bei allen Teilaufgaben ist zu beachten, dass es häufig nicht zweckmäßig ist, jedes Objekt einzeln zu
erfassen. Stattdessen sollten ähnliche Objekte zu Gruppen zusammengefasst werden.
8.1.1 Komplexitätsreduktion durch Gruppenbildung
Die Strukturanalyse liefert wichtige Grunddaten für den gesamten Sicherheitsprozess. Der Informati­
onsverbund setzt sich meist aus vielen Einzelobjekten zusammen, die bei der Konzeption berücksich­
tigt werden müssen. Wenn alle logischen und technischen Objekte einzeln erfasst werden, besteht
jedoch die Gefahr, dass die Ergebnisse der Strukturanalyse aufgrund der Datenmenge und der Kom­
plexität nicht handhabbar sind. Ähnliche Objekte sollten deshalb sinnvoll zu Gruppen zusammenge­
fasst werden.
Bei technischen Komponenten hat eine konsequente Gruppenbildung zudem den Vorteil, dass die
Administration wesentlich vereinfacht wird, wenn es nur wenige Grundkonfigurationen gibt. Durch
eine möglichst hohe Standardisierung innerhalb eines Informationsverbunds wird außerdem die Zahl
potenzieller Sicherheitslücken reduziert und die Sicherheitsmaßnahmen für diesen Bereich können
ohne Unterscheidung verschiedenster Schwachstellen umgesetzt werden. Dies kommt nicht nur
der Informationssicherheit zugute, sondern spart auch Kosten.
Objekte können dann ein und derselben Gruppe zugeordnet werden, wenn die Objekte alle
• vom gleichen Typ sind,
• ähnliche Aufgaben haben,
• ähnlichen Rahmenbedingungen unterliegen und
• den gleichen Schutzbedarf aufweisen.
Bei technischen Objekten bietet sich eine Gruppenbildung außerdem immer dann an, wenn sie
• ähnlich konfiguriert sind,
79
Die Strukturanalyse gliedert sich in folgende Teilaufgaben:8.1 Strukturanalyse
• ähnlich in das Netz eingebunden sind (z. B. im gleichen Netzsegment) und
• ähnlichen administrativen und infrastrukturellen Rahmenbedingungen unterliegen,
• ähnliche Anwendungen bedienen und
• den gleichen Schutzbedarf aufweisen.
Aufgrund der genannten Voraussetzungen für die Gruppenbildung kann bezüglich der Informations­
sicherheit davon ausgegangen werden, dass eine Stichprobe aus einer Gruppe in der Regel den Si­
cherheitszustand der Gruppe repräsentiert.
Wichtigstes Beispiel für die Gruppierung von Objekten ist sicherlich die Zusammenfassung von Clients.
In der Regel gibt es in einer Institution eine große Anzahl von Clients, die sich jedoch gemäß obigem
Schema in eine überschaubare Anzahl von Gruppen aufteilen lassen. Auch in produzierenden und ge­
werblichen Bereichen ist es empfehlenswert, Objekte zu gruppieren, wenn diese vergleichbar konfigu­
riert und eingesetzt werden (z. B. Handscanner, Arbeitsplatz-PCs). Dies gilt analog auch für Räume und
andere Objekte. In großen Informationsverbünden, wo aus Gründen der Redundanz oder des Durch­
satzes viele Server die gleiche Aufgabe wahrnehmen, können durchaus auch Server zu Gruppen zusam­
mengefasst werden.
Zunehmend werden IT-Systeme virtualisiert. Da hierbei typischerweise viele virtuelle Maschinen (VMs)
auf einem Virtualisierungsserver betrieben werden, ist eine sinnvolle Strukturanalyse bei virtualisierten
Infrastrukturen oder Cloud Computing nur durch geeignete Gruppenbildung möglich. Für die Grup­
penbildung gelten bei Virtualisierung dieselben Regeln wie für physische Zielobjekte. Prinzipiell kön­
nen auch solche VMs zu einer Gruppe zusammengefasst werden, die auf verschiedenen physischen
IT-Systemen laufen, wenn sie ähnliche Aufgaben erfüllen, gleichartig konfiguriert sind und denselben
Schutzbedarf aufweisen.
In der Regel bestehen Cloud Computing-Plattformen aus homogenen Hard- und Software-Kompo­
nenten. Aufgrund der Homogenität kann eine Vielzahl von Aufgaben automatisiert und zentral
durchgeführt werden. Eine Gruppenbildung, beispielsweise anhand des Schutzbedarfs, ist beim
Cloud Computing zwingend erforderlich.
Die Teilaufgaben der Strukturanalyse werden nachfolgend beschrieben und durch ein begleitendes
Beispiel erläutert. Eine ausführliche Version des Beispiels findet sich in den Hilfsmitteln zum IT-Grund­
schutz auf den einzelnen Webseiten bzw. auf der BSI-Website. Bei allen Teilaufgaben sollten jeweils
Objekte zu Gruppen zusammengefasst werden, wenn dies sinnvoll und zulässig ist.
Aktionspunkte zu 8.1.1 Komplexitätsreduktion durch Gruppenbildung
• Bei allen Teilaufgaben der Strukturanalyse gleichartige Objekte zu Gruppen zusammenfassen
• Typ und Anzahl der jeweils zusammengefassten Objekte vermerken
8.1.2 Erfassung der Geschäftsprozesse und der zugehörigen Informationen
Eine der Hauptaufgaben des Sicherheitsmanagements ist es, der Leitungsebene die Informationssicher­
heitsrisiken aufzuzeigen und damit Transparenz zu schaffen, wo Entscheidungs- oder Handlungsbedarf
erforderlich ist. Hierzu muss sich der ISB einen Überblick über die für die Institution wesentlichen Ge­
schäftsprozesse bzw. Fachaufgaben verschaffen und darstellen, was Informationssicherheitsrisiken
bzw. IT-Risiken für diese Geschäftsprozesse bedeuten.
808 Erstellung einer Sicherheitskonzeption nach Standard-Absicherung
Auf Basis des definierten Informationsverbunds sind in einem ersten Schritt die dort enthaltenen zen­
tralen Geschäftsprozesse oder Fachaufgaben zu erfassen und zu dokumentieren. Hierbei ist darauf zu
achten, dass eine sinnvolle Granularität gewählt wird. Dies bedeutet, dass nicht nur ein einzelner
Hauptprozess, wie z. B. das Personalmanagement, sondern auch die zugehörigen wichtigsten Sub­
prozesse, wie z. B. Personalgewinnung, Mitarbeiterverwaltung, Personalentwicklung usw. erfasst
werden, sofern diese Bestandteil des Informationsverbunds sind. Eine zu detaillierte Dokumentation
z. B. durch eine Auflistung von nachgelagerten Prozessen sollte jedoch vermieden werden. Auch im
ICS-Bereich müssen für die Strukturanalyse die Geschäftsprozesse mit den zugehörigen Informatio­
nen erfasst werden. Hier ist insbesondere darauf zu achten, dass neben dem Kernprozess der Produk­
tion auch weitere Nebenprozesse, wie z. B. die logistischen Prozesse für den Warenfluss und die In­
standhaltung, berücksichtigt werden.
Die einzelnen Prozesse sind wie folgt zu erfassen:
• eindeutiger Bezeichner
• Name
• Prozessverantwortlicher/Fachabteilung
• kurze Beschreibungen des Prozesses oder der Fachaufgabe und der dort verarbeiteten Informatio­
nen
• wichtige, für den Prozess benötigte Anwendung(en)
Um die wesentlichen Geschäftsprozesse zu identifizieren, kann in vielen Institutionen auf bestehende
Prozesslandkarten zurückgegriffen werden. Wenn die Geschäftsprozesse noch nicht, nicht durchgän­
gig oder nicht aktuell erfasst wurden, sollten zunächst Geschäftsverteilungspläne, Aufgabenbeschrei­
bungen oder andere organisationsbeschreibende Papiere ausgewertet werden, um die relevanten
Geschäftsprozesse zu identifizieren. Daneben kann das Verfahrensverzeichnis des Datenschutzbeauf­
tragten ein weiterer Startpunkt für die Erfassung der Prozesse, Fachaufgaben und nachfolgenden
Anwendungen sein, auch wenn dies lediglich die Verfahren und Anwendungen abbildet, die perso­
nenbezogene Daten verarbeiten. Sollten noch keine Prozessbeschreibungen vorliegen, sind kurze
Workshops oder Interviews mit den Fachverantwortlichen zu empfehlen.
Es kann durchaus sinnvoll sein, die Erhebung der Prozesse und Fachaufgaben mit der Erhebung der
Anwendungen zu koppeln, um damit redundante Fragen insbesondere in den Fachabteilungen zu ver­
meiden.
Aktionspunkte zu 8.1.2 Erfassung der Geschäftsprozesse und der zugehörigen Informatio­
nen
• Überblick über die Geschäftsprozesse erstellen
• Geschäftsprozesse mit eindeutigen Nummern oder Kürzeln kennzeichnen
• Zusammenhang zwischen Geschäftsprozessen und Anwendungen darstellen
81
Somit erscheint es sinnvoll, einen Bezug zwischen den Geschäftsprozessen und der Wertschöpfung
einer Institution und den zu schützenden Informationen sowie der verwendeten IT bzw. den verwen­
deten Anwendungen herzustellen. Hierfür müssen die Geschäftsprozesse und deren Abhängigkeit
von den wichtigsten Anwendungen dokumentiert werden.8.1 Strukturanalyse
8.1.3 Erfassung der Anwendungen und der zugehörigen Informationen
Ausgehend von jedem Geschäftsprozess bzw. jeder Fachaufgabe, die im Informationsverbund ent­
halten ist, müssen in dieser Phase die damit zusammenhängenden Anwendungen und die damit
verarbeiteten Informationen identifiziert werden. Anwendungen dienen der IT-technischen Unter­
stützung von Geschäftsprozessen und Fachaufgaben in Behörden und Unternehmen.
Die geeignete Granularität für die betrachteten Anwendungen muss in jeder Institution individuell
gewählt werden. Ziel sollte dabei sein, eine optimale Transparenz und Effizienz bei der Strukturanalyse
und der Schutzbedarfsfeststellung zu erreichen. Auch die im IT-Grundschutz-Kompendium betrach­
teten Bausteine aus der Schicht der Anwendungen können für diesen Schritt Aufschluss geben.
Zur weiteren Reduzierung des Aufwands kann die Strukturanalyse des Informationsverbunds auf die
Anwendungen und Informationen beschränkt werden, die für die betrachteten Geschäftsprozesse
oder Fachaufgaben erforderlich sind. Dabei sollte darauf geachtet werden, dass zumindest diejenigen
Anwendungen und Informationen berücksichtigt werden, die aufgrund der Anforderungen der be­
trachteten Geschäftsprozesse oder Fachaufgaben ein Mindestniveau an
• Geheimhaltung (Vertraulichkeit) oder
• Korrektheit und Unverfälschtheit (Integrität) oder
• Verfügbarkeit
erfordern.
Bei der Erfassung der Anwendungen sollten auch die Benutzer bzw. die für die Anwendung Verant­
wortlichen sowie die für den Geschäftsprozess Verantwortlichen befragt werden, wie sie das erfor­
derliche Sicherheitsniveau einschätzen.
Aufgrund der steigenden Komplexität von Anwendungen ist es jedoch oft für die Fachverantwortli­
chen nicht klar, welche Abhängigkeiten zwischen einem Geschäftsprozess oder einer Fachaufgabe zu
einer konkreten Anwendung bestehen. Es sollte also für jede einzelne Fachaufgabe festgestellt wer­
den, welche Anwendungen für ihre Abwicklung notwendig sind und auf welche Daten dabei zuge­
griffen wird. In einer gemeinsamen Sitzung der Fachabteilung, der Verantwortlichen der einzelnen
Anwendungen und der unterstützenden IT-Abteilung können diese Abhängigkeiten erfasst werden.
Beispielsweise können Bestellungen nicht abschließend bearbeitet werden, wenn keine Informatio­
nen über den Lagerbestand zur Verfügung stehen.
Falls abweichend von der hier vorgeschlagenen Reihenfolge zuerst die IT-Systeme erfasst wurden, ist
es häufig hilfreich, die Anwendungen an erster Stelle orientiert an den IT-Systemen zusammenzutra­
gen. Aufgrund ihrer Breitenwirkung sollte dabei mit den Servern begonnen werden. Um ein möglichst
ausgewogenes Bild zu bekommen, kann anschließend diese Erhebung aufseiten der Clients und Ein­
zelplatz-Systeme vervollständigt werden. Abschließend sollte noch festgestellt werden, welche Netz­
koppelelemente welche Anwendungen unterstützen. Für die Erfassung der Anwendungen auf einem
Standard-Client hat sich in der Praxis bewährt, seitens der unterstützenden IT-Abteilung die Stan­
dard-Software der Clients als Paket zu betrachten. So wird die Standard-Software nicht vergessen.
Oftmals wird diese als selbstverständlich angesehen und deren Anwendung wird in Interviews nicht
mehr explizit genannt (z. B. die E-Mail-Anwendung oder Bürokommunikation).
Ausgehend von den Anwendungen können die zugehörigen Geschäftsprozesse auch im Nachgang
erfasst werden (siehe Kapitel 8.1.2). Der Verantwortliche und die Benutzer der Anwendung sollten
ebenfalls erfasst werden, um Ansprechpartner für Sicherheitsfragen leichter identifizieren bzw. be­
troffene Benutzergruppen schnell erreichen zu können.
828 Erstellung einer Sicherheitskonzeption nach Standard-Absicherung
Bei der Erfassung der Anwendungen ist es empfehlenswert, auch Datenträger und Dokumente zu
betrachten und diese ähnlich wie Anwendungen zu behandeln. Sofern sie nicht fest mit einer An­
wendung oder einem IT-System verknüpft sind, müssen Datenträger und Dokumente gesondert in die
Strukturanalyse integriert werden. Natürlich ist es dabei nicht zweckmäßig, alle Datenträger einzeln
zu erfassen. Zum einen sollten nur Datenträger und Dokumente mit einem Mindestschutzbedarf be­
trachtet und zum anderen sollten möglichst Gruppen gebildet werden. Beispiele für Datenträger und
Dokumente, die im Rahmen der Strukturanalyse gesondert erfasst werden sollten, sind
• Archiv- und Back-up-Datenträger,
• Datenträger für den Austausch mit externen Kommunikationspartnern,
• Massenspeicher für den mobilen Einsatz (z. B. USB-Sticks oder externe Festplatten),
• Mikrofilme,
• wichtige Verträge mit Partnern und Kunden.
Es darf nicht vergessen werden, virtualisierte Anwendungen im Rahmen der Strukturanalyse mit zu
erfassen.
Zur Dokumentation der Ergebnisse bietet sich die Darstellung in tabellarischer Form oder die Nutzung
entsprechender Software-Produkte an.
Beispiel: RECPLAST GmbH
Im Folgenden wird anhand einer fiktiven Institution, der RECPLAST GmbH, beispielhaft dargestellt,
wie die erfassten Anwendungen dokumentiert werden können. Zu beachten ist, dass die Struktur der
RECPLAST GmbH im Hinblick auf die Informationssicherheit keineswegs optimal ist. Sie dient lediglich
dazu, die Vorgehensweise bei der Anwendung des IT-Grundschutzes zu illustrieren. In diesem Doku­
ment werden anhand der RECPLAST GmbH die einzelnen Aktivitäten zur Erstellung einer Sicherheits­
konzeption erläutert. Das komplette Beispiel findet sich unter den Hilfsmitteln zum IT-Grundschutz.
Die RECPLAST GmbH ist eine fiktive Institution mit ca. 500 Mitarbeitern, von denen 130 an Bildschirm­
arbeitsplätzen arbeiten. Räumlich ist die RECPLAST GmbH aufgeteilt in zwei Standorte innerhalb
Bonns, wo unter anderem die administrativen und produzierenden Aufgaben wahrgenommen wer­
den, und drei Vertriebsstandorte in Deutschland.
Um die Geschäftsprozesse zu optimieren, sind alle Arbeitsplätze vernetzt worden. Die Außenstelle in
Bonn ist über eine angemietete Standleitung an die Zentrale angebunden. Die Vertriebsstandorte sind
mit abgesicherten Verbindungen über das Internet an die Zentrale angebunden. Alle für die Aufga­
benerfüllung und die Informationssicherheit wesentlichen Richtlinien und Vorschriften sowie Formu­
lare und Textbausteine sind ständig für jeden Mitarbeiter über das Intranet abrufbar. Alle relevanten
Arbeitsergebnisse werden in eine zentrale Datenbank eingestellt. Entwürfe werden ausschließlich
elektronisch erstellt, weitergeleitet und unterschrieben. Die Realisierung und Betreuung aller benö­
tigten Funktionalitäten übernimmt eine IT-Abteilung in Bonn.
Die Geschäftsprozesse der RECPLAST werden elektronisch gepflegt und sind nach einem zweistufigen
Schema benannt. Hinter dem Kürzel GP wird die Nummer des Hauptprozesses angegeben, zum Bei­
spiel GP002. Ein Geschäftsprozess sollte immer beschrieben werden, damit ein einheitliches Verständ­
nis für die Abgrenzung eines Prozesses vorhanden ist. Optional kann eine Prozessart erfasst werden.
Diese dient lediglich zur Übersicht, welche Prozesse für eine Institution hauptsächlich zum Fortbe­
stand beitragen. Die Unterstützungsprozesse sind jedoch ebenso wichtig, diese sind jedoch eher für
den allgemeinen Betrieb einer Institution erforderlich.
83
• Notfallhandbücher, die in ausgedruckter Form vorgehalten werden,8.1 Strukturanalyse
Nachfolgend ist ein Auszug aus der Erfassung der Geschäftsprozesse und der dazugehörigen Infor­
mationen für die RECPLAST GmbH abgebildet:
A.1 Geschäftsprozesse der RECPLAST GmbH
Beschreibung des Prozesses Prozess-Art Prozessverant­
wortlicher Mitarbeiter
GP001 Produktion: Die Produktion der
Kunststoffartikel umfasst alle Pha­
sen von der Materialbereitstellung
bis hin zur Einlagerung des produ­
zierten Materials. Hierzu gehören
innerhalb der Produktion die inter­
nen Transportwege, die Produkti­
on und Fertigung der verschiede­
nen Komponenten und das Verpa­
cken der Teile. Kerngeschäft Leiter Produktion Alle Mitarbeiter
GP002 Angebotswesen: In der Ange­
botsabwicklung werden die Kun­
denanfragen für Produkte verar­
beitet. Im Regelfall werden Kun­
denanfragen formlos per E-Mail
oder Fax geschickt. Die Angebote
werden elektronisch erfasst und
ein schriftliches Angebot per Post Unterstützender
an den Kunden versendet.
Prozess
Leiter Angebotswesen Vertrieb
GP003 Auftragsabwicklung: Kunden
schicken die Bestellungen im Re­
gelfall per Fax oder E-Mail. Alle Be­
lege müssen ausgedruckt und
elektronisch erfasst werden. Eine
Auftragsbestätigung erhält der
Kunde nur, wenn er dies ausdrück­
lich wünscht oder der Produktions­
prozess von der üblichen Produkti­
onszeit abweicht. Leiter Auftrags­
abwicklung Vertrieb
GP004 Einkaufsabteilung: In der Ein­
kaufsabteilung werden alle erfor­
derlichen Artikel bestellt, die nicht
für den Produktionsprozess erfor­
derlich sind. In dieser Abteilung wer­
den externe Projekte verhandelt,
IT-Verträge gestaltet und Ver­
brauchsmaterial im organisatori­
schen Umfeld (Papier, Toner, etc.) Unterstützender
Prozess
beschafft. Leiter Einkaufsabtei­
lung Einkauf
Bezeichnung
84
Kerngeschäft8 Erstellung einer Sicherheitskonzeption nach Standard-Absicherung
A.1 Geschäftsprozesse der RECPLAST GmbH
Bezeichnung
GP005
Beschreibung des Prozesses Prozess-Art Prozessverant­
wortlicher Mitarbeiter
Disposition: In der Disposition
werden alle für die Produktion be­
nötigten Materialien (Kunststoffe,
Schrauben, Tüten, etc.) beschafft.
Hierzu liegen normalerweise Rah­
menverträge vor. Geplant wird in
diesem Umfeld anhand von Jahres­
planmengen und verschiedenen
Bestellwerten. Kerngeschäft Leiter Disposition Disposition, Pro­
duktion
Strukturanalyse der Anwendungen
Der zuständige Informationssicherheitsbeauftragte der RECPLAST GmbH erfasst in der Strukturana­
lyse neben den Geschäftsprozessen auch alle weiteren Objekte, die zur Institution selbst gehören.
Dazu zählen auch die Anwendungen, die zur Aufrechterhaltung der bereits erfassten Geschäftspro­
zesse benötigt werden.
Nachfolgend wird ein Auszug aus der Erfassung der Anwendungen und der zugehörigen Informatio­
nen für das fiktive Beispiel RECPLAST dargestellt:
85
Abbildung 12: Auszug aus den Geschäftsprozessen der RECPLAST GmbH86
Bonn
(Anwendungen)
Alle
Verantwortlich
Administrator
8.1 Strukturanalyse8 Erstellung einer Sicherheitskonzeption nach Standard-Absicherung
Der Zusammenhang zwischen den Geschäftsprozessen und den Anwendungen muss immer darge­
stellt werden. Diese Zuordnung sollte idealerweise mit Tools durchgeführt werden, um bei der übli­
chen Vielzahl von Prozessen und Anwendungen die Übersichtlichkeit und Aktualität zu gewährleis­
ten.
Abbildung 14: Zuordnung der Geschäftsprozesse zu den Anwendungen der RECPLAST GmbH
Aktionspunkte zu 8.1.3 Erfassung der Anwendungen und der zugehörigen Informationen
• Unter Einbeziehung der Verantwortlichen bzw. der Nutzer der Anwendungen herausfinden, wel­
che Anwendungen für die betrachteten Geschäftsprozesse erforderlich sind
• Übersicht über die Anwendungen erstellen und mit eindeutigen Nummern oder Kürzeln kenn­
zeichnen
8.1.4 Netzplanerhebung
Einen geeigneten Ausgangspunkt für die weitere technische Analyse stellt ein Netzplan (beispielswei­
se in Form eines Netztopologieplans) dar. Ein Netzplan ist eine grafische Übersicht über die im be­
trachteten Bereich der Informations- und Kommunikationstechnik eingesetzten Komponenten und
deren Vernetzung. Netzpläne oder ähnliche grafische Übersichten sind auch aus betrieblichen Grün­
den in den meisten Institutionen vorhanden. Im Einzelnen sollte der Plan in Bezug auf die Informati­
onssicherheit mindestens folgende Objekte darstellen:
• IT-Systeme, d.h. Client- und Server-Computer, aktive Netzkomponenten (wie Switches, Router,
WLAN Access Points), Netzdrucker usw.
• ICS- und IoT-Komponenten mit Netzanschluss, d. h. Clients, Handscanner, Industriedrucker, Gerä­
te mit speicherprogrammierbarer Steuerung (SPS), Schaltschränke usw.
• Netzverbindungen zwischen diesen Systemen, d. h. LAN-Verbindungen (wie Ethernet), WLAN,
Backbone-Techniken (wie ATM) usw.
• Verbindungen des betrachteten Bereichs nach außen, d. h. Einwahlzugänge über ISDN oder Mo­
dem, Internetanbindungen über analoge Techniken oder Router, Funkstrecken oder Mietleitungen
zu entfernten Gebäuden oder Liegenschaften usw.
87
Am Beispiel der RECPLAST GmbH wird nachfolgend dargestellt, dass für einen Prozess normalerweise
mehrere Anwendungen eingesetzt werden:8.1 Strukturanalyse
Zu jedem der dargestellten Objekte gehört weiterhin ein Minimalsatz von Informationen, die einem
zugeordneten Katalog zu entnehmen sind. Für jedes IT-System und sonstige Geräte sollten zumindest
• eine eindeutige Bezeichnung (beispielsweise der vollständige Hostname oder eine Identifikations­
nummer),
• Typ und Funktion (beispielsweise Datenbank-Server für Anwendung X),
• die zugrunde liegende Plattform (d. h. Hardware-Plattform und Betriebssystem),
• der Standort (beispielsweise Gebäude- und Raumnummer),
• der zuständige Administrator,
• die vorhandenen Kommunikationsschnittstellen (z. B. Internetanschluss, Bluetooth, WLAN Adap­
ter) sowie
• die Art der Netzanbindung und die Netzadresse
vermerkt sein. Bei Außenanbindungen oder drahtlosen Kommunikationsverbindungen (WLAN,
UMTS, LTE,...) sollten zusätzlich Details zum externen Netz (z. B. Internet, Geschäftspartner, Name
des Providers für die Datenübertragung sowie die Art der Leitung, z. B. MPLS, Leased Line, VPN) auf­
genommen werden.
Virtuelle IT-Systeme (virtuelle Switches, virtuelle Server usw.) und virtuelle Netzverbindungen, bei­
spielsweise virtuelle LANs (VLANs) oder virtuelle private Netze (VPNs), sollten ebenfalls in einem Netz­
plan dargestellt werden. Hierbei sind virtuelle IT-Systeme gemäß ihrem Typ und Einsatzzweck genauso
wie physische IT-Systeme zu behandeln. Darüber hinaus muss die Zuordnung von virtuellen IT-Syste­
men zu physischen Host-Systemen nachvollziehbar sein. Um die Übersichtlichkeit zu verbessern, ist es
bei zunehmender Größe eines Netzes sinnvoll, den Netzplan in mehrere Teilnetzpläne aufzuteilen.
Eine Cloud-Infrastruktur setzt sich aus einer Vielzahl von Elementen zusammen. Neben den physi­
schen (mit CPU, Arbeitsspeicher und anderer Hardware) und gegebenenfalls virtuellen Servern zählen
noch Netze und Speicherlösungen dazu. Die aufgezählten Bereiche verfügen in der Regel über eine
Verwaltungssoftware.
Für den Bereich „Netze“ sollten die eingesetzten Netzmanagement-Tools eine automatische Erzeu­
gung von Netzplänen unterstützen. Neben physischen sollten auch virtuelle IT-Systeme (z. B. virtuelle
Switches, virtuelle Router, virtuelle Sicherheitsgateways) automatisch abgebildet werden können.
Der ICS-Bereich kann als eigenständiges Netz betrieben werden. Bei der Erfassung der Netzverbin­
dungen sollten dabei auch die Schnittstellen erfasst werden (Auflistung der erlaubten und gesperrten
Schnittstellen). Auch die Internetanbindung aus dem ICS-Bereich heraus sollte erfasst werden. Die
Trennung der Netze zwischen dem Office-Bereich und dem ICS-Bereich sollte im Netzplan dargestellt
werden.
Es empfiehlt sich, Bereiche mit unterschiedlichem Schutzbedarf zu kennzeichnen. Der Netzplan sollte
möglichst in elektronischer Form erstellt und gepflegt werden. Hat die Informationstechnik in der
Institution einen gewissen Umfang überschritten, bietet es sich an, bei der Erfassung und Pflege des
Netzplans auf geeignete Hilfsprogramme zurückzugreifen, da die Unterlagen eine erhebliche Kom­
plexität aufweisen können und einem ständigen Wandel unterzogen sind.
Aktualisierung des Netzplans
Da die IT-Struktur in der Regel ständig an die Anforderungen der Institution angepasst wird und die
Pflege des Netzplans entsprechende Ressourcen bindet, ist der Netzplan der Institution nicht immer
888 Erstellung einer Sicherheitskonzeption nach Standard-Absicherung
Im Hinblick auf die Verwendung des Netzplans für die Strukturanalyse besteht demnach der nächste
Schritt darin, den vorliegenden Netzplan (bzw. die Teilpläne, wenn der Gesamtplan aus Gründen der
Übersichtlichkeit aufgeteilt wurde) mit der tatsächlich vorhandenen IT-Struktur abzugleichen und ge­
gebenenfalls auf den neuesten Stand zu bringen. Hierzu sind die IT-Verantwortlichen und Adminis­
tratoren der einzelnen Anwendungen und Netze zu konsultieren. Falls Programme für ein zentralisier­
tes Netz- und Systemmanagement eingesetzt werden, sollte auf jeden Fall geprüft werden, ob diese
Programme bei der Erstellung eines Netzplans Unterstützung anbieten. Zu beachten ist jedoch, dass
Funktionen zur automatischen oder halbautomatischen Erkennung von Komponenten temporär zu­
sätzlichen Netzverkehr erzeugen. Es muss sichergestellt sein, dass dieser Netzverkehr nicht zu Beein­
trächtigungen des IT-Betriebs führt. Ebenso sollte das Ergebnis von automatischen bzw. halbautoma­
tischen Erkennungen stets dahingehend geprüft werden, ob wirklich alle relevanten Komponenten
ermittelt wurden.
Der Bereich der industriellen Steuerung sollte ebenfalls in den Netzplan integriert werden. Ansprech­
partner sind neben den IT-Verantwortlichen und Administratoren auch die Mitarbeiter der Haustech­
nik.
Ein bereinigter Netzplan ist auch an anderen Stellen hilfreich. So kann dieser genutzt werden, um
Dritten schnell die Geschäftsprozess- und IT-Strukturen innerhalb der Institution darzustellen, da in
einem bereinigten Netzplan der Detaillierungsgrad auf das notwendige Maß reduziert wird. Auch für
eine Zertifizierung ist ein bereinigter Netzplan eine sinnvolle Grundlage.
Beispiel: RECPLAST GmbH
Die Netzpläne in der RECPLAST GmbH werden in der IT-Abteilung mit einem Tool verwaltet. Die Dar­
stellung aller Netzpläne ist sehr detailliert und oftmals für Dritte sehr unübersichtlich. Die RECPLAST
GmbH nutzt deshalb für die Darstellung der erfassten Zielobjekte einen bereinigten Netzplan.
89
auf dem aktuellen Stand. Vielmehr werden in der Praxis oftmals nur größere Änderungen an der
IT-Struktur einzelner Bereiche zum Anlass genommen, den Plan zu aktualisieren.(Teilausschnitt)
8.1 Strukturanalyse
908 Erstellung einer Sicherheitskonzeption nach Standard-Absicherung
Aktionspunkte zu 8.1.4 Netzplanerhebung
• Existierende grafische Darstellungen des Netzes, beispielsweise Netztopologiepläne, sichten
• Netzpläne gegebenenfalls aktualisieren oder neu erstellen
• Existierende Zusatzinformationen über die enthaltenen IT-, ICS- und IoT-Systeme sichten und ge­
gebenenfalls aktualisieren und vervollständigen
• Existierende Zusatzinformationen über die enthaltenen Kommunikationsverbindungen sichten
und gegebenenfalls aktualisieren und vervollständigen
Im Hinblick auf die später durchzuführende Schutzbedarfsfeststellung und Modellierung des Informa­
tionsverbunds sollte eine Liste der vorhandenen und geplanten IT-Systeme in tabellarischer Form auf­
gestellt werden. Der Begriff IT-System umfasst dabei nicht nur Computer im engeren Sinn, sondern
auch die IoT- und ICS-Geräte, aktive Netzkomponenten, Netzdrucker, TK-Anlagen, Smartphones, vir­
tuelle IT-Systeme usw. Die technische Realisierung eines IT-Systems steht im Vordergrund, beispiels­
weise Apple MacBook, Client unter Windows, Linux-Server, TK-Anlage usw. An dieser Stelle sollen nur
die Systeme als solche erfasst werden (z. B. Linux-Server), nicht die einzelnen Bestandteile, aus denen
die IT-Systeme zusammengesetzt sind (also nicht Rechner, Tastatur, Bildschirm usw.).
Hinweis:
Ffr einen ordnungsmäßigen IT-Betrieb ist eine vollständige und korrekte Erfassung der vorhan­
denen und geplanten IT-Systeme notwendig, beispielsweise ffr die Uberprffung, Wartung, Feh­
lersuche und Instandsetzung von IT-Systemen. Ffr die Erstellung eines Sicherheitskonzepts reicht
es, sich einen Uberblick fber die gruppierten IT-Systeme zu verschaffen.
Zu erfassen sind sowohl die vernetzten als auch die nicht vernetzten IT-Systeme, insbesondere also
auch solche, die nicht im zuvor betrachteten Netzplan aufgeführt sind. IT-Systeme, die im Netzplan zu
einer Gruppe zusammengefasst worden sind, können weiterhin als ein Objekt behandelt werden.
Auch bei den IT-Systemen, die nicht im Netzplan aufgeführt sind, ist zu prüfen, ob sie sinnvoll zusam­
mengefasst werden können. Möglich ist dies beispielsweise bei einer größeren Anzahl von nicht ver­
netzten Einzelplatz-PCs, die die im Kapitel 8.1.1 Komplexitätsreduktion durch Gruppenbildung ge­
nannten Bedingungen für eine Gruppierung erfüllen.
Bei dieser Erfassung sollten folgende Informationen vermerkt werden, die für die nachfolgende Arbeit
nützlich sind:
• eine eindeutige Bezeichnung der IT-Systeme bzw. der jeweiligen Gruppe (bei Gruppen sollte auch
die Anzahl der zusammengefassten IT-Systeme vermerkt sein),
• Beschreibung (z. B. Funktion, Typ),
• Plattform (z. B. Hardware-Architektur/Betriebssystem),
• Aufstellungsort der IT-Systeme (z. B. Ort, Gebäude, Raum),
• Status der IT-Systeme (in Betrieb, im Test, in Planung) und
• Benutzer bzw. Administratoren der IT-Systeme.
91
8.1.5 Erhebung der IT-Systeme8.1 Strukturanalyse
Anschließend werden die Anwendungen jeweils denjenigen IT-Systemen zugeordnet, die für deren
Ausführung benötigt werden. Dies können die IT-Systeme sein, auf denen die Anwendungen verar­
beitet werden, oder auch diejenigen, die Daten dieser Anwendungen transferieren. Das Ergebnis ist
eine Übersicht, in der die Zusammenhänge zwischen den wichtigen Anwendungen und den entspre­
chenden IT-Systemen dargestellt werden.
92Betrieb
Administratoren
Verantwortlich
8 Erstellung einer Sicherheitskonzeption nach Standard-Absicherung
9394
Betrieb
Administratoren
Verantwortlich
Administrator
8.1 Strukturanalyse8 Erstellung einer Sicherheitskonzeption nach Standard-Absicherung
Für die Zuordnung der Anwendungen zu den IT-Systemen setzt die RECPLAST GmbH ein Tool ein, da
die Pflege in Form einer Tabelle aufwendig ist. Jede Änderung, sei es ein IT-System oder eine Anwen­
dung, muss immer dokumentiert werden. Diese Zuordnung ist für die später folgende Schutzbedarfs­
feststellung erforderlich.
8.1.6 Erhebung der ICS-Systeme
In Institutionen mit Produktion und Fertigung müssen auch die industriellen Steuerungssysteme (ICS),
die von der Institution eingesetzt werden, erhoben werden.
Im ICS-Bereich gibt es Arbeitsplatz-PCs, die auch hier zu Gruppen zusammengefasst werden sollten.
Oftmals sind diese PCs mit den gleichen Anwendungen wie die der Büroumgebung ausgestattet.
Darüber hinaus sind auf einigen PCs spezielle Anwendungen installiert. Zu vielen PC-Arbeitsplätzen
gehört ein Drucker und neben der Standardperipherie (Maus, Tastatur) werden weitere periphere
Endgeräte (z. B. Handscanner) eingesetzt, die mit den Arbeitsplatz-PCs direkt verbunden sind. Bei
allen peripheren Endgeräten müssen die Kommunikationsverbindungen (z. B. Bluetooth) ebenfalls
berücksichtigt werden.
Im Bereich der Produktion und Fertigung werden weitere Endgeräte eingesetzt. Für die industrielle
Steuerung gibt es spezielle Endgeräte, z. B. Geräte mit speicherprogrammierbaren Steuerungen
(SPSen), WLAN-Module für Industriemaschinen, selbstfahrende Gabelstapler (Flurfahrzeuge).
Bei der Erfassung der ICS-Systeme sollten folgende Informationen vermerkt werden, die für die nach­
folgenden Schritte erforderlich sind:
• eine eindeutige Bezeichnung der ICS-Systeme bzw. der jeweiligen Gerätegruppe (die Anzahl der
Geräte in den Gruppen sollte ebenfalls vermerkt sein),
• Beschreibung (Typ und Funktion),
• Plattform (z. B. Betriebssystem, Art der (Netz-)Anbindung),
• Aufstellungsort der Geräte (z. B. Gebäude, Halle, Raum)
• Status der ICS-Systeme (in Betrieb, im Test, in Planung) und
• Verantwortliche für den Betrieb der ICS-Systeme.
95
Oftmals werden in der Produktion und Fertigung neben IT-Systemen noch eine Reihe weiterer Geräte
eingesetzt. Alle ICS-Geräte sollten entsprechend erfasst werden.96
Betrieb
Haustechnik
Verantwortlich
Administrator
8.1 Strukturanalyse8 Erstellung einer Sicherheitskonzeption nach Standard-Absicherung
8.1.7 Erhebung sonstiger Geräte
In Institutionen werden je nach Branche unterschiedlichste Geräte eingesetzt, um die Geschäftspro­
zesse zu unterstützen. Neben IT-Systemen, die unmittelbar als solche zu identifizieren sind, können
auch viele andere Arten von Geräten Einfluss auf die Informationssicherheit haben. Zu solchen Gerä­
ten gehören beispielsweise Geräte mit Funktionalitäten aus dem Bereich IoT.
Daher sollte die Institution einen Überblick darüber haben, welche Geräte wo eingesetzt werden und
welche Anforderungen an die Informationssicherheit sich hieraus ergeben könnten, wie regelmäßige
Überprüfung der Betriebssicherheit, Wartung oder das Einspielen von Patches.
Für die IT-Grundschutz-Modellierung sollten die Geräte mit IoT-Funktionalität erfasst werden, die ver­
netzt sind, insbesondere auch solche, die nicht im zuvor betrachteten Netzplan aufgeführt sind. Sol­
che Geräte sollten möglichst zu Gruppen zusammengefasst und als ein Objekt behandelt werden.
Bei dieser Erfassung sollten folgende Informationen vermerkt werden, die für die nachfolgende Arbeit
nützlich sind:
• eine eindeutige Bezeichnung der Geräte bzw. der jeweiligen Gruppe (bei Gruppen sollte auch die
Anzahl der zusammengefassten Geräte vermerkt sein),
• Beschreibung (Typ und Funktion),
• Plattform (z. B. Betriebssystem, Art der Netzanbindung),
• Aufstellungsort der Geräte,
• Status der IT-Systeme (in Betrieb, im Test, in Planung) und
• Verantwortliche für den Betrieb der Geräte.
Internet of Things (IoT)
IoT-Geräte sind häufig dadurch gekennzeichnet, dass sie überschaubare, begrenzte Außenmaße ha­
ben, oftmals preislich unterhalb von Grenzen liegen, die einen aufwendigen Beschaffungsvorgang in
Institutionen nach sich ziehen, und/oder bei denen die Internetfunktionalität nicht hervorsticht. Daher
ist es wahrscheinlich, dass bei jeder Art von Übersicht oder Bestandserhebung IoT-Geräte übersehen
werden. Es ist wichtig, sich darüber einen Überblick zu verschaffen,
• welche IoT-Geräte in der Institution derzeit oder demnächst eingesetzt werden und
• wer die Akteure in der Institution sind, die typischerweise IoT-Geräte nutzen, und mit diesen ins
Gespräch zu kommen.
Dafür kann es ein sinnvoller Ansatz für den ISB sein, in verschiedene Räumlichkeiten der Institution zu
gehen und zu überlegen, welche der dort vorhandenen Komponenten Strom benötigen und ob diese
über IT-Netze vernetzt sein könnten. Der ISB sollte insbesondere mit den Kollegen der Haustechnik,
aber auch mit den anderen Geräteverantwortlichen sprechen und sich die Funktionalitäten der ver­
schiedenen Geräte erläutern lassen. Die Vernetzung könnte beispielsweise über IT-Verkabelung oder
WLAN mit dem LAN erfolgen, über Mobilfunk mit dem Internet, aber auch über freie WLANs in der
97
Auch Geräte, wie beispielsweise Klimaanlagen, Gefahrenmeldeanlagen oder Kaffeemaschinen, die
nicht der direkten Unterstützung der Informationsverarbeitung oder anderer Geschäftsprozesse die­
nen, können die Informationssicherheit beeinträchtigen, wenn z. B. ein Kabelbrand Folgeschäden
nach sich zieht, aber auch, wenn Geräte dieser Art zur besseren Ressourcensteuerung ins IT-Netz
integriert werden.8.1 Strukturanalyse
Umgebung oder andere Funkschnittstellen wie Bluetooth erfolgen. Zusätzlich sollten regelmäßig
Netzscans durchgeführt werden und dabei nach nicht zuzuordnenden Geräten gesucht werden.
Geräte mit IoT-Funktionalitäten können in Institutionen beispielsweise folgende sein:
• Durch Mitarbeiter oder Externe mitgebrachte private Geräte, z. B. Smartwatches, digitale Bilder­
rahmen, Wetterstationen, Fitnessarmbänder und andere Gadgets.
• Durch die Institution beschaffte und betriebene Geräte wie Brand-, Gas- und andere Warnmelder,
Kaffeemaschinen oder Elemente der Gebäudesteuerung. Die Übergänge zu ICS-Systemen sind
hier fließend.
Dabei sind IoT-Geräte nicht immer direkt auf den ersten Blick als solche zu erkennen, beispielsweise
wenn die IoT-Funktionalität kein kaufentscheidendes Merkmal ist, aber für den Hersteller dadurch
eine für ihn gewinnbringende Datensammlung möglich wird, z. B. über die Art und Menge der Ver­
brauchsmaterialien.
Ein Beispiel für Geräte, in denen sich IoT-Funktionalitäten verstecken könnten, sind Komfortmöbel, die
sich automatisch an die jeweiligen Benutzer anpassen und nicht nur lokal die Einstellungen speichern,
sondern diese über IT-Netze mit anderen Arbeitsplätzen austauschen, sodass Mitarbeiter an beliebi­
gen Arbeitsplätzen arbeiten können („Smart Workplaces“).
98und
Server­
Pförtner,
sicherheitsfach­
8 Erstellung einer Sicherheitskonzeption nach Standard-Absicherung
998.1 Strukturanalyse
Aktionspunkte zu 8.1.5, 8.1.6 und 8.1.7 Erhebung der IT-, ICS-Systeme und
sonstiger Geräte
• Prüfen, ob existierende Datenbanken oder Übersichten über die vorhandenen oder geplanten IT-,
ICS-Systeme sowie die sonstigen Geräte als Ausgangsbasis für die weitere Vorgehensweise ge­
eignet sind
• Liste der vernetzten und nicht vernetzten IT-Systeme, IoT- und ICS-Geräte erstellen beziehungs­
weise aktualisieren und vervollständigen
• IT-, ICS-, IoT-Systeme beziehungsweise Systemgruppen mit eindeutigen Nummern oder Kürzeln
kennzeichnen
• Die Anwendungen den IT-, ICS-, IoT-Systemen (Servern, Clients, Netzkoppelelementen usw.) zu­
ordnen, die für ihre Ausführung benötigt werden
8.1.8 Erfassung der Räume
Die betrachteten Geschäftsprozesse und Fachaufgaben werden nicht nur auf definierten IT-Systemen
betrieben, sondern auch innerhalb der Grenzen der räumlichen Infrastruktur einer Institution. Je nach
Größe der Institution und abhängig von vielen anderen Faktoren kann sich eine Institution in einem
allein genutzten Gebäude oder auch nur auf einer Etage befinden. Viele Institutionen nutzen Liegen­
schaften, die weit verstreut sind oder mit anderen Nutzern geteilt werden müssen. Häufig sind Ge­
schäftsprozesse und Fachaufgaben auch in fremden Räumlichkeiten angesiedelt, zum Beispiel im
Rahmen von Dienstleistungsverträgen.
In ein Sicherheitskonzept müssen alle Liegenschaften, innerhalb derer die betrachteten Geschäftspro­
zesse und Fachaufgaben betrieben werden, einbezogen werden. Dazu gehören Betriebsgelände, Ge­
bäude, Etagen, Räume sowie die Wegstrecke zwischen diesen. Alle Kommunikationsverbindungen,
die über für Dritte zugängliche Gelände verlaufen, müssen als Außenverbindungen behandelt wer­
den. Dies gilt auch für drahtlose Kommunikationsverbindungen, wenn nicht ausgeschlossen werden
kann, dass Dritte darauf zugreifen können. Nicht vergessen werden sollten auch Räumlichkeiten, die
außerhalb der offiziellen Liegenschaften liegen, die aber auch sporadisch oder regelmäßig genutzt
werden, um dort Geschäftsprozesse und Fachaufgaben zu bearbeiten. Dazu gehören beispielsweise
Telearbeitsplätze oder temporär angemietete Arbeitsplätze und Lagerflächen.
Für die weitere Vorgehensweise der Modellierung nach IT-Grundschutz und für die Planung des
Soll-Ist-Vergleichs ist es hilfreich, eine Übersicht über die Liegenschaften, vor allem die Räume, zu
erstellen, in denen IT-, ICS- oder IoT-Systeme aufgestellt oder die für deren Betrieb genutzt werden.
Dazu gehören Räume, die ausschließlich dem IT-Betrieb dienen (wie Serverräume, Datenträgerarchi­
ve), solche, in denen unter anderem IT-, ICS- oder IoT-Systeme betrieben werden (wie Büroräume oder
Werkhallen), aber auch die Wegstrecken, über die Kommunikationsverbindungen laufen. Wenn
IT-Systeme statt in einem speziellen Technikraum in einem Schutzschrank untergebracht sind, ist der
Schutzschrank ebenfalls wie ein Raum zu erfassen.
1008 Erstellung einer Sicherheitskonzeption nach Standard-Absicherung
Hinweis:
Bei der Erhebung der IT-, ICS- und IoT-Systeme sind schon die Aufstellungsorte aufgelistet worden.
Zusätzlich muss untersucht werden, ob schutzbedürftige Informationen in weiteren Räumen aufbe­
wahrt werden. Diese Räume müssen dann ebenfalls benannt werden. Hierbei müssen auch Räume
hinzugezählt werden, in denen nicht elektronische schutzbedürftige Informationen aufbewahrt wer­
den, also beispielsweise Aktenordner oder Mikrofilme. Die Art der verarbeiteten Informationen muss
anhand dieser Dokumentation nachvollziehbar sein.
101102
27
Benutzer
aussehen
vergleichbare
8.1 StrukturanalyseBetrieb
Verantwortlich
Administrator
8 Erstellung einer Sicherheitskonzeption nach Standard-Absicherung
1038.2 Schutzbedarfsfeststellung
Aktionspunkte zu 8.1.8 Erfassung der Räume
• Liste aller bei der Erfassung der IT-, ICS- und IoT-Systeme notierten Liegenschaften, Gebäude und
Räume erstellen
• Weitere Räume ergänzen, in denen schutzbedürftige Informationen aufbewahrt oder auf andere
Weise verarbeitet werden
8.2
Schutzbedarfsfeststellung
Ziel der Schutzbedarfsfeststellung ist es, für die erfassten Objekte im Informationsverbund zu ent­
scheiden, welchen Schutzbedarf sie bezüglich Vertraulichkeit, Integrität und Verfügbarkeit besitzen.
Dieser Schutzbedarf orientiert sich an den möglichen Schäden, die mit einer Beeinträchtigung der
betroffenen Anwendungen und damit der jeweiligen Geschäftsprozesse verbunden sind.
Die Schutzbedarfsfeststellung für den Informationsverbund gliedert sich in mehrere Schritte:
• Definition der Schutzbedarfskategorien
• Schutzbedarfsfeststellung für Geschäftsprozesse und Anwendungen
• Schutzbedarfsfeststellung für IT-Systeme, IoT- und ICS-Geräte
• Schutzbedarfsfeststellung für Gebäude, Räume, Werkhallen usw.
• Schutzbedarfsfeststellung für Kommunikationsverbindungen
• Schlussfolgerungen aus den Ergebnissen der Schutzbedarfsfeststellung
Nach der Definition der Schutzbedarfskategorien wird anhand von typischen Schadensszenarien zu­
nächst der Schutzbedarf der Geschäftsprozesse und Anwendungen bestimmt. Anschließend wird dar­
aus der Schutzbedarf der einzelnen IT-Systeme, Räume und Kommunikationsverbindungen abgeleitet.
Die Vorgehensweise hierfür wird in den folgenden Abschnitten detailliert dargestellt.
8.2.1 Definition der Schutzbedarfskategorien
Da der Schutzbedarf meist nicht quantifizierbar ist, beschränkt sich der IT-Grundschutz somit auf eine
qualitative Aussage, indem der Schutzbedarf in drei Kategorien unterteilt wird:
Schutzbedarfskategorien
„normal“ Die Schadensauswirkungen sind begrenzt und überschaubar.
„hoch“ Die Schadensauswirkungen können beträchtlich sein.
„sehr hoch“ Die Schadensauswirkungen können ein existenziell bedrohliches, katastrophales
Ausmaß erreichen.
Hinweis:
Es kann ffr eine Institution auch sinnvoll sein, weitere Kategorien zu definieren. Beispielsweise
kann eine Abstufung nach unten, z. B. „unkritisch“, eingeffhrt werden. (Diese könnte wie folgt
definiert sein: „Schäden an Ressourcen der Schutzbedarfskategorie ,unkritisch‘ haben keine oder
nur minimale Beeinträchtigungen der Institution zur Folge.“)
1048 Erstellung einer Sicherheitskonzeption nach Standard-Absicherung
Werden nur ein oder zwei Kategorien genutzt, ist die damit erreichbare Abstufung meist nicht gra­
nular genug. Werden dagegen fünf oder mehr Schutzbedarfskategorien verwendet, ist eine klare
Unterscheidung zwischen den einzelnen Stufen schwieriger. Zudem ist die Zuordnung von Ressourcen
zu einer der möglichen Schutzbedarfskategorien schwer nachvollziehbar und es steigt dadurch auch
der Aufwand sowohl bei der Zuordnung als auch bei Revisionen.
Wenn mehr als drei Schutzbedarfskategorien definiert werden, so ist zu überlegen, welche der neu
definierten Kategorien den Schutzbedarfskategorien „hoch“ bzw. „sehr hoch“ entsprechen, denn
diese Information wird zur Überprüfung der Entscheidung benötigt, welche Objekte in die Risikoana­
lyse aufgenommen werden.
Die nachfolgenden Schritte erläutern, wie für Geschäftsprozesse und die mit diesen verbundenen
Anwendungen jeweils die adäquate Schutzbedarfskategorie ermittelt werden kann.
Die Schäden, die bei dem Verlust der Vertraulichkeit, Integrität oder Verfügbarkeit für einen Ge­
schäftsprozess bzw. eine Anwendung einschließlich ihrer Daten entstehen können, lassen sich typi­
scherweise folgenden Schadensszenarien zuordnen:
• Verstoß gegen Gesetze/Vorschriften/Verträge,
• Beeinträchtigung des informationellen Selbstbestimmungsrechts,
• Beeinträchtigung der persönlichen Unversehrtheit,
• Beeinträchtigung der Aufgabenerfüllung,
• negative Innen- oder Außenwirkung und
• finanzielle Auswirkungen.
Häufig treffen dabei für einen Schaden mehrere Schadensszenarien zu. So kann beispielsweise der
Ausfall einer Anwendung die Aufgabenerfüllung beeinträchtigen, was direkte finanzielle Einbußen
nach sich zieht und gleichzeitig auch zu einem Imageverlust führt.
Hinweis:
Auch die Art und Anzahl der betrachteten Szenarien können individuell angepasst werden. Je
nach Institution gibt es unterschiedliche Schwerpunkte, auf die sich das Sicherheitsmanagement
konzentrieren kann. So könnte das Szenario „Beeinträchtigung des informationellen Selbstbe­
stimmungsrechts“ entfallen, wenn beispielsweise in der Institution das Datenschutzmanagement
dieses Szenario bereits ausreichend betrachtet hat. In vielen Institutionen kann das Szenario „Be­
einträchtigung der persönlichen Unversehrtheit“ weggelassen werden, es sei denn, es handelt
sich um ein Unternehmen, bei dem Fehlfunktionen von IT-Systemen unmittelbar Personenschä­
den nach sich ziehen können. Dies könnte beispielsweise im Gesundheitswesen oder in Produk­
tionsbereichen der Fall sein.
Es könnten auch zusätzliche Szenarien betrachtet werden, wie beispielsweise
• Einschränkung der Dienstleistungen für Dritte oder
105
Eine andere Möglichkeit ist es, für Vertraulichkeit andere Kategorien als für Integrität oder Verfügbar­
keit zu nutzen. Einige Institutionen unterteilen beispielsweise Vertraulichkeit in die Kategorien „of­
fen“, „intern“, „vertraulich“ und „geheim“, aber die Kategorien Integrität oder Verfügbarkeit nur in
zwei Stufen „normal“ und „kritisch“.8.2 Schutzbedarfsfeststellung
• Auswirkungen auf weitere Infrastrukturen außerhalb des eigenen Informationsverbunds (z. B. Re­
chenzentren, IT-Betrieb von Kunden oder Dienstleistern).
Um die Schutzbedarfskategorien „normal“, „hoch“ und „sehr hoch“ voneinander abgrenzen zu
können, bietet es sich an, die Grenzen für die einzelnen Schadensszenarien zu bestimmen. Zur Ori­
entierung, welchen Schutzbedarf ein potenzieller Schaden und seine Folgen erzeugen, dienen die
folgenden Tabellen. Die Tabellen sollten von der jeweiligen Institution auf ihre eigenen Gegebenheiten
angepasst werden.
Schutzbedarfskategorie „normal“
1. Verstoß gegen Gesetze/
Vorschriften/Verträge
• Verstöße gegen Vorschriften und Gesetze mit geringfügigen
Konsequenzen
• Geringfügige Vertragsverletzungen mit maximal geringen Kon­
ventionalstrafen
2. Beeinträchtigung des infor­ • Es handelt sich um personenbezogene Daten, durch deren Ver­
mationellen Selbstbestim­
arbeitung der Betroffene in seiner gesellschaftlichen Stellung
mungsrechts
oder in seinen wirtschaftlichen Verhältnissen beeinträchtigt wer­
den kann.
3. Beeinträchtigung der per­
sönlichen Unversehrtheit • Eine Beeinträchtigung erscheint nicht möglich.
4. Beeinträchtigung der Auf­
gabenerfüllung • Die Beeinträchtigung würde von den Betroffenen als tolerabel
eingeschätzt werden.
• Die maximal tolerierbare Ausfallzeit liegt zwischen 24 und 72
Stunden.
5. Negative Innen- oder Au­
ßenwirkung • Eine geringe bzw. nur interne Ansehens- oder Vertrauensbeein­
trächtigung ist zu erwarten.
6. Finanzielle Auswirkungen • Der finanzielle Schaden bleibt für die Institution tolerabel.
Tabelle 2: Schutzbedarfskategorie „normal“
Schutzbedarfskategorie „hoch“
1. Verstoß gegen Geset­
ze/Vorschriften/Verträge
• Verstöße gegen Vorschriften und Gesetze mit erheblichen Kon­
sequenzen
• Vertragsverletzungen mit hohen Konventionalstrafen
2. Beeinträchtigung des infor­ • Es handelt sich um personenbezogene Daten, bei deren Verar­
mationellen Selbstbestim­
beitung der Betroffene in seiner gesellschaftlichen Stellung oder
mungsrechts
in seinen wirtschaftlichen Verhältnissen erheblich beeinträchtigt
werden kann.
3. Beeinträchtigung der per­
sönlichen Unversehrtheit
106
• Eine Beeinträchtigung der persönlichen Unversehrtheit kann
nicht absolut ausgeschlossen werden.8 Erstellung einer Sicherheitskonzeption nach Standard-Absicherung
Schutzbedarfskategorie „hoch“
• Die Beeinträchtigung würde von einzelnen Betroffenen als nicht
tolerabel eingeschätzt.
4. Beeinträchtigung der Auf­
gabenerfüllung
• Die maximal tolerierbare Ausfallzeit liegt zwischen einer und 24
Stunden.
5. Negative Innen- oder Au­
ßenwirkung • Eine breite Ansehens- oder Vertrauensbeeinträchtigung ist zu er­
warten.
6. Finanzielle Auswirkungen • Der Schaden bewirkt beachtliche finanzielle Verluste, ist jedoch
nicht existenzbedrohend.
Schutzbedarfskategorie „sehr hoch“
1. Verstoß gegen Gesetze/
Vorschriften/Verträge
• Fundamentaler Verstoß gegen Vorschriften und Gesetze
• Vertragsverletzungen, deren Haftungsschäden ruinös sind
2. Beeinträchtigung des infor­ • Es handelt sich um personenbezogene Daten, bei deren Verar­
mationellen Selbstbestim­
beitung eine Gefahr für Leib und Leben oder die persönliche Frei­
mungsrechts
heit des Betroffenen gegeben ist.
3. Beeinträchtigung der per­
sönlichen Unversehrtheit
• Gravierende Beeinträchtigungen der persönlichen Unversehrt­
heit sind möglich.
• Gefahr für Leib und Leben
4. Beeinträchtigung der Auf­
gabenerfüllung
• Die Beeinträchtigung würde von allen Betroffenen als nicht tole­
rabel eingeschätzt werden.
• Die maximal tolerierbare Ausfallzeit ist kleiner als eine Stunde.
5. Negative Innen- oder Au­
ßenwirkung • Eine landesweite Ansehens- oder Vertrauensbeeinträchtigung,
eventuell sogar existenzgefährdender Art, ist denkbar.
6. Finanzielle Auswirkungen • Der finanzielle Schaden ist für die Institution existenzbedrohend.
Tabelle 4: Schutzbedarfskategorie „sehr hoch“
Wenn bei individuellen Betrachtungen festgestellt wird, dass über diese sechs Schadensszenarien hi­
naus weitere infrage kommen, sollten diese entsprechend ergänzt werden. Für alle Schäden, die sich
nicht in diese Szenarien abbilden lassen, muss ebenfalls eine Aussage getroffen werden, wo die Gren­
zen zwischen „normal“, „hoch“ oder „sehr hoch“ zu ziehen sind.
Darüber hinaus sollten die individuellen Gegebenheiten der Institution berücksichtigt werden: Bedeu­
tet in einem Großunternehmen ein Schaden in Höhe von 200.000,- E gemessen am Umsatz noch
einen geringen Schaden, so kann für ein Kleinunternehmen schon ein Schaden in Höhe von 10.000,- E
existenziell bedrohlich sein. Daher kann es sinnvoll sein, eine prozentuale Größe als Grenzwert zu
definieren, der sich am Gesamtumsatz, am Gesamtgewinn oder an einer ähnlichen Bezugsgröße ori­
entiert.
Ähnliche Überlegungen können bezüglich der Verfügbarkeitsanforderungen angestellt werden. So
kann beispielsweise ein Ausfall von 24 Stunden Dauer in der Schutzbedarfskategorie „normal“ als
107
Tabelle 3: Schutzbedarfskategorie „hoch“8.2 Schutzbedarfsfeststellung
noch tolerabel eingeschätzt werden. Tritt jedoch eine Häufung dieser Ausfälle ein, z. B. mehr als ein­
mal wöchentlich, so kann dies in der Summe nicht tolerierbar sein. Die anhand der Schutzbedarfska­
tegorien festgelegten Verfügbarkeitsanforderungen sollten daher bei Bedarf konkretisiert werden.
Es kann erforderlich sein, für den Bereich ICS die Schutzbedarfskategorien separat festzulegen, aber
diese auf die des restlichen Informationsverbunds abzustimmen. In produzierenden Bereichen ist es
beispielsweise oftmals erforderlich, für die jeweiligen Kategorien kürzere Ausfallzeiten festzulegen als
im Bereich der Büro-IT. Zeitliche Vorgaben können z. B. aus Wartungsverträgen abgeleitet werden.
Unter Umständen müssen auch andere Punkte angepasst werden. Auch im Datenschutz muss der
Schutzbedarf festgelegt werden, um angemessen technische und organisatorische Schutzmaßnah­
men bestimmen und konfigurieren zu können. Das Standard-Datenschutzmodell (SDM) bietet eine
ganze Reihe an Kriterien, um das Risiko eines Grundrechtseingriffs, und daraus folgend des Schutz­
bedarfs, anhand von drei Stufen zu bestimmen. Das SDM bietet zudem Hilfestellungen, sollten die
Schutzbedarfe aus Sicht der Informationssicherheit und des Datenschutzes nicht übereinstimmen.
Bei der Festlegung der Grenze zwischen „normal“ und „hoch“ sollte berücksichtigt werden, dass für
den normalen Schutzbedarf die Basis- und Standardsicherheitsanforderungen des IT-Grundschutzes
ausreichen sollten. Die getroffenen Festlegungen sind in geeigneter Weise im Sicherheitskonzept zu
dokumentieren, da hiervon die Auswahl von Sicherheitsmaßnahmen und damit meist Folgekosten
abhängen.
Aktionspunkte zu 8.2.1 Definition der Schutzbedarfskategorien
• Typische Schadensszenarien für die Definition von Schutzbedarfskategorien betrachten
• Schutzbedarfskategorien „normal“, „hoch“ und „sehr hoch“ definieren beziehungsweise an die
eigene Institution anpassen
8.2.2 Vorgehen bei der Schutzbedarfsfeststellung
Zunächst wird der Schutzbedarf der Geschäftsprozesse und Anwendungen bestimmt. Anschließend
wird daraus der Schutzbedarf der einzelnen Objekte (z. B. IT-Systeme, Räume und Kommunikations­
verbindungen) abgeleitet.
Die Grundlage zur Bestimmung des Schutzbedarfs verschiedener Objekte ist der Schutzbedarf der
Geschäftsprozesse und der zugehörigen Informationen. Der für diese Elemente ermittelte Schutzbe­
darf vererbt sich auf die für deren Verarbeitung genutzten Objekte, also Anwendungen, IT-Systeme,
ICS- und sonstige Geräte, Räume und Kommunikationsverbindungen (Vererbung).
Zur Ermittlung des Schutzbedarfs eines Objektes müssen die möglichen Schäden der relevanten Teil­
objekte in ihrer Gesamtheit betrachtet werden. Beispielsweise müsste bei einem IT-System beleuchtet
werden, welche Auswirkungen Schäden bei den darauf betriebenen Anwendungen und den damit
verarbeiteten Informationen haben. Im Wesentlichen bestimmt der Schaden bzw. die Summe der
Schäden mit den schwerwiegendsten Auswirkungen den Schutzbedarf eines Objektes (Maximum­
prinzip).
Bei der Betrachtung der möglichen Schäden und ihrer Folgen muss auch beachtet werden, dass die
verschiedenen betrachteten Objekte eines Informationsverbunds natürlich eng miteinander verzahnt
sind. So kann z. B. eine IT-Anwendung Arbeitsergebnisse anderer Anwendungen als Input nutzen.
Eine, für sich betrachtet, weniger bedeutende Anwendung A kann wesentlich an Wert gewinnen,
wenn eine andere wichtige Anwendung B auf ihre Ergebnisse angewiesen ist. In diesem Fall muss der
ermittelte Schutzbedarf der Anwendung B auch auf die Anwendung A übertragen werden. Handelt
1088 Erstellung einer Sicherheitskonzeption nach Standard-Absicherung
es sich dabei um Anwendungen verschiedener IT-Systeme, dann müssen Schutzbedarfsanforderun­
gen des einen IT-Systems auch auf das andere übertragen werden (Beachtung von Abhängigkeiten).
Werden mehrere Anwendungen bzw. Informationen auf einem IT-System (oder in einem Raum oder
über eine Kommunikationsverbindung) verarbeitet, so ist zu überlegen, ob durch Kumulation meh­
rerer (z. B. kleinerer) Schäden auf einem IT-System ein insgesamt höherer Gesamtschaden entstehen
kann. Dann erhöht sich der Schutzbedarf des Objektes, also hier des IT-Systems, entsprechend (Ku­
mulationseffekt).
Auf einem Netzserver befinden sich sämtliche ffr die Kundendatenerfassung benötigten Anwen­
dungen einer Institution. Der Schaden bei Ausfall einer dieser Anwendungen wurde als gering
eingeschätzt, da genfgend Ausweichmöglichkeiten vorhanden sind. Fällt jedoch der Server (und
damit alle Anwendungen, die diesen Server benötigen) aus, so ist der dadurch entstehende Scha­
den deutlich höher zu bewerten. Die Aufgabenerffllung kann unter Umständen nicht mehr in­
nerhalb der notwendigen Zeitspanne gewährleistet werden. Daher ist auch der Schutzbedarf
dieser „zentralen“ Komponente entsprechend höher zu bewerten.
Auch der umgekehrte Effekt kann eintreten. So ist es möglich, dass eine Anwendung einen hohen
Schutzbedarf besitzt, ihn aber deshalb nicht auf ein betrachtetes IT-System überträgt, weil auf diesem
IT-System nur unwesentliche Teilbereiche der Anwendung laufen. Hier ist der Schutzbedarf zu relati­
vieren (Verteilungseffekt). Der Verteilungseffekt kann natürlich auch bei anderen Zielobjekten, wie
beispielsweise Räumen, Gebäuden oder Kommunikationsverbindungen, auftreten.
Beispiel: Der Verteilungseffekt tritt hauptsächlich bezüglich des Grundwertes der Verfügbarkeit auf.
So kann bei redundanter Auslegung von IT-Systemen der Schutzbedarf der Einzelkomponenten nied­
riger sein als der Schutzbedarf der Gesamtanwendung. Auch im Bereich der Vertraulichkeit sind Ver­
teilungseffekte vorstellbar: Falls sichergestellt ist, dass ein Client nur unkritische Daten einer hochver­
traulichen Datenbankanwendung abrufen kann, so besitzt der Client im Vergleich zum Datenbank­
server unter Umständen einen geringeren Schutzbedarf.
Ein Verteilungseffekt tritt häufig auf, wenn bei der Einrichtung oder dem Aufbau von Zielobjekten
durch entsprechende Redundanzen bereits den Anforderungen an einen hohen Schutzbedarf Rech­
nung getragen wurde. Dies ist im Grunde ein Vorgriff auf Betrachtungen, die im Rahmen der Risiko­
analyse erforderlich sind. Deshalb sollten im Rahmen der Schutzbedarfsfeststellung getroffene Ent­
scheidungen sorgfältig dokumentiert werden.
Beispiel:
Bei Anwendungen, die im Hinblick auf Verffgbarkeit einen hohen Schutzbedarf haben, wurden
bereits Redundanzen vorgesehen, unter anderem Ausweicharbeitsplätze in Nachbargebäuden.
Durch die entstandenen Verteilungseffekte haben diese Arbeitsplätze normalen Schutzbedarf
bezfglich Verffgbarkeit, solange ausreichend Ausweicharbeitsplätze zur Verffgung stehen.
Die Schutzbedarfsfeststellung ist ein iterativer Prozess. Bereits ganz am Anfang, bei der ersten Dis­
kussion darüber, welche Geschäftsprozesse und Informationen welche Bedeutung für die Institution
haben, wird eine erste grobe Schutzbedarfsfeststellung durchgeführt. Auch nach Durchführung von
Risikoanalysen sollte die Schutzbedarfsfeststellung erneut dahingehend geprüft werden, ob sie an­
109
Beispiel:8.2 Schutzbedarfsfeststellung
gepasst werden muss, da sich während der Risikoanalyse und der Auswahl von Maßnahmen neue
Erkenntnisse für den Schutzbedarf von Assets ergeben können.
8.2.3 Schutzbedarfsfeststellung für Geschäftsprozesse und Anwendungen
Um den Schutzbedarf in den verschiedenen Bereichen eines Informationsverbunds zu bestimmen,
muss zunächst der Schutzbedarf der Geschäftsprozesse und der zugehörigen Informationen ermittelt
werden. Darauf aufbauend wird daraus der Schutzbedarf der einzelnen Anwendungen, IT-Systeme,
ICS- und sonstigen Geräte, Räume und Kommunikationsverbindungen abgeleitet.
Um den Schutzbedarf der Geschäftsprozesse zu ermitteln, sollte zunächst die Bedeutung der einzel­
nen Geschäftsprozesse für die Institution beleuchtet werden. Davon ausgehend sollte hinterfragt
werden, welche Abhängigkeiten zwischen Geschäftsprozessen und Anwendungen bestehen und
wie die sich daraus ergebenden Risiken entschärft werden können. Hierzu hat es sich bewährt, mit
der Fragestellung „Was wäre, wenn...?“ zusammen mit den Anwendern realistische Schadensszena­
rien zu diskutieren und die zu erwartenden materiellen oder ideellen Schäden zu beschreiben. Oft
führt dies auch dazu, dass kritische Abhängigkeiten zwischen Geschäftsprozessen und weiteren Ziel­
objekten aufgedeckt werden, die vorher nicht im Fokus standen.
Aus dem Schutzbedarf der Geschäftsprozesse ergibt sich der Schutzbedarf der Anwendungen, die für
deren Erledigung eingesetzt werden.
Hinweis:
Zur Einschätzung des Schutzbedarfs sollten die geeigneten Ansprechpartner gesucht werden, es
ist nicht erforderlich, größere Gruppe von Benutzern zu befragen. Beispielsweise ist es zur Bewer­
tung des Schutzbedarfs bestimmter zentraler Dienste, wie zum Beispiel DNS oder E-Mail, ausrei­
chend, den Schutzbedarf durch die Organisationseinheit festlegen zu lassen, die als Dienstanbie­
ter ffr die Institution auftritt (meist die IT-Abteilung oder das Provider-Management). Der Schutz­
bedarf dieser Dienste ist in der Institution zu kommunizieren. Wird ein höherwertiger
Schutzbedarf der Dienste durch einzelne Fachabteilungen benötigt, so sind mögliche Lösungen
zwischen Fachabteilung, Sicherheitsmanagement und dem Betreiber oder Anbieter des Dienstes
zu erörtern. Ein IT-Dienstleister kann im Regelfall seine Services nicht ffr jede mögliche Schutzbe­
darfskategorie bereitstellen. Deshalb wird er seine Dienste mit einer von ihm festgelegten Schutz­
bedarfseignung anbieten. Der Informationseigentfmer muss bei Nutzung eines Service ffr seinen
Geschäftsprozess entscheiden, ob die ihm vom IT-Dienstleister angebotene Schutzbedarfseig­
nung ausreicht oder ob zusätzliche Sicherheitsmaßnahmen infolge höheren Schutzbedarfs um­
gesetzt werden mfssen.
In die Schutzbedarfsfeststellung müssen auch die in der Strukturanalyse erfassten Gruppen von Da­
tenträgern und Dokumenten einbezogen werden.
Um die Ermittlung der möglichen Schäden und Auswirkungen zu vereinfachen, werden im Anhang
dieses Standards entsprechende Fragestellungen vorgestellt. Diese Anregungen erheben nicht den
Anspruch auf Vollständigkeit, sie dienen lediglich zur Orientierung. Um die individuelle Aufgabenstel­
lung und die Situation der Institution zu berücksichtigen, müssen diese Fragen gegebenenfalls ent­
sprechend ergänzt und angepasst werden.
Die Festlegung des Schutzbedarfs der Geschäftsprozesse und Anwendungen ist eine Entscheidung im
Rahmen des Risikomanagements und hat oft weitreichende Auswirkungen auf das Sicherheitskon­
zept für den betrachteten Informationsverbund. Der Schutzbedarf der Geschäftsprozesse und An­
1108 Erstellung einer Sicherheitskonzeption nach Standard-Absicherung
wendungen fließt in die Schutzbedarfsfeststellung der betroffenen technischen und infrastrukturellen
Objekte, wie zum Beispiel Server und Räume, ein.
Bei komplexen Geschäftsprozessen, insbesondere wenn diese hohen oder sehr hohen Schutzbedarf
haben, kann es sinnvoll sein, diese in Teilprozesse zu zerlegen. Wenn dabei der Bereich mit einem
hohen oder sehr hohen Schutzbedarf auf wenige Teilprozesse eingegrenzt werden kann, hat das den
Vorteil, dass sich der hohe bzw. sehr hohe Schutzbedarf auf wenige Objekte vererbt.
Um die Ergebnisse der Schutzbedarfsfeststellung und die daraus resultierenden Entscheidungen im
Rahmen des Informationssicherheitsmanagements später jederzeit nachvollziehen zu können, müs­
sen die Ergebnisse der Schutzbedarfsfeststellung der Geschäftsprozesse und Anwendungen gut do­
kumentiert werden. Dabei ist darauf zu achten, dass nicht nur die Festlegung des Schutzbedarfs fest­
gehalten wird, sondern auch die entsprechenden Begründungen. Diese Begründungen erlauben es
später, die Festlegungen zu überprüfen und weiter zu verwenden.
111112
Maximumprinzip
Arbeits­
platzrechner
keine Informationen
gespeichert
Anwendung
enthält
Informationen
Begründung
ent­
8.2 Schutzbedarfsfeststellunghoch
Zutritts­
unter­
Maximumprinzip
Zutritt,
Zugriff
risierte
hoch
Maximumprinzip
Begründung
Verfügbarkeit
8 Erstellung einer Sicherheitskonzeption nach Standard-Absicherung
1138.2 Schutzbedarfsfeststellung
An dieser Stelle kann es sinnvoll sein, über diese Informationen hinaus den Schutzbedarf auch aus
einer gesamtheitlichen Sicht der Geschäftsprozesse oder Fachaufgaben zu betrachten. Dazu bietet es
sich an, den Zweck einer Anwendung in einem Geschäftsprozess oder in einer Fachaufgabe zu be­
schreiben und daraus wiederum deren Bedeutung abzuleiten. Diese Bedeutung kann wie folgt klas­
sifiziert werden.
Die Bedeutung der Anwendung ist für den Geschäftsprozess bzw. die Fachaufgabe:
• normal: Der Geschäftsprozess bzw. die Fachaufgabe kann mit tolerierbarem Mehraufwand mit
anderen Mitteln (z. B. manuell) durchgeführt werden.
• hoch: Der Geschäftsprozess bzw. die Fachaufgabe kann nur mit deutlichem Mehraufwand mit
anderen Mitteln durchgeführt werden.
• sehr hoch: Der Geschäftsprozess bzw. die Fachaufgabe kann ohne die Anwendung überhaupt
nicht durchgeführt werden.
Der Vorteil, eine solche ganzheitliche Zuordnung vorzunehmen, liegt insbesondere darin, dass bei der
Schutzbedarfsfeststellung die Leitungsebene als Regulativ für den Schutzbedarf der einzelnen An­
wendungen agieren kann. So kann es sein, dass ein Verantwortlicher für eine Anwendung deren
Schutzbedarf aus seiner Sicht als „normal“ einschätzt, die Leitungsebene aus Sicht des Geschäftspro­
zesses bzw. der Fachaufgabe diese Einschätzung jedoch nach oben korrigiert.
Diese optionalen Angaben sollten ebenfalls tabellarisch oder mithilfe entsprechender Software-pro­
dukte dokumentiert werden.
Aktionspunkt zu 8.2.3 Schutzbedarfsfeststellung für Geschäftsprozesse und Anwendun­
gen
• Schutzbedarf der erfassten Geschäftsprozesse und Anwendungen anhand von Schadensszena­
rien und Fragenkatalogen ermitteln
• Schutzbedarf der Geschäftsprozesse und Anwendungen und die entsprechenden Begründungen
tabellarisch dokumentieren
8.2.4 Schutzbedarfsfeststellung für IT-Systeme
Um den Schutzbedarf eines IT-Systems festzustellen, müssen zunächst die Anwendungen betrachtet
werden, die in direktem Zusammenhang mit dem IT-System stehen. Eine Übersicht, welche Anwen­
dungen für die unterschiedlichen IT-Systeme relevant sind, wurde im Rahmen der Strukturanalyse
(siehe Kapitel 8.1) ermittelt. Der Schutzbedarf der Geschäftsprozesse und Anwendungen (siehe Ka­
pitel 8.2.3) fließt in die Schutzbedarfsfeststellung für die jeweils betroffenen IT-Systeme ein. Hierbei ist
darauf zu achten, dass nicht nur die IT-Systeme berücksichtigt werden, auf denen die jeweilige An­
wendung installiert ist. Vielmehr ist auch der Datenfluss der Anwendung zu beachten, über den der
Schutzbedarf der Anwendung auf die dazwischenliegenden Netzkomponenten vererbt wird.
Zur Ermittlung des Schutzbedarfs eines IT-Systems müssen nun die möglichen Schäden der relevanten
Anwendungen in ihrer Gesamtheit betrachtet werden. Die Ergebnisse der Schutzbedarfsfeststellung
der IT-Systeme sollten wiederum in einer Tabelle festgehalten werden. Darin sollte verzeichnet sein,
welchen Schutzbedarf jedes IT-System bezüglich Vertraulichkeit, Integrität und Verfügbarkeit hat. Der
Gesamtschutzbedarf eines IT-Systems leitet sich wiederum aus dem Maximum des Schutzbedarfs be­
züglich der drei Grundwerte Vertraulichkeit, Integrität und Verfügbarkeit ab. Ein IT-System ist also
hochschutzbedürftig, wenn es bezüglich eines oder mehrerer Grundwerte den Schutzbedarf „hoch“
1148 Erstellung einer Sicherheitskonzeption nach Standard-Absicherung
hat. Der Schutzbedarf eines IT-Systems sollte für alle drei Grundwerte einzeln dokumentiert werden,
da sich hieraus typischerweise verschiedene Arten von Sicherheitsmaßnahmen ergeben.
Bei einem IT-System kann sich beispielsweise der hohe Gesamtschutzbedarf daraus ableiten, dass der
Schutzbedarf bezüglich Vertraulichkeit hoch ist, bezüglich Integrität und Verfügbarkeit allerdings nor­
mal. Dann kann zwar der Gesamtschutzbedarf mit „hoch“ angegeben werden, dies zieht aber nicht
nach sich, dass dadurch der Schutzbedarf bezüglich Integrität und Verfügbarkeit angehoben werden
muss.
Die Festlegungen des Schutzbedarfs der IT-Systeme müssen begründet werden, damit die Entschei­
dungen auch für Außenstehende nachvollziehbar sind. Hier kann auf die Schutzbedarfsfeststellung
der Anwendungen zurückverwiesen werden.
115116
Konfigurationsei­
müssen
bleiben.
regeln
tenverkehr
den
RECPLAST
Zugang
Zugriff
risierte
Begründung
die
normal
8.2 Schutzbedarfsfeststellungnotwendig.
werden
Arbeitsplä­
weitere
zum
onsprozess
Server
bank
sind
Serverraum
Zugriff-,
gangs-
berechtigung
Begründung
Verfügbar­
normal
GmbH
8 Erstellung einer Sicherheitskonzeption nach Standard-Absicherung
1178.2 Schutzbedarfsfeststellung
Schutzbedarfsfeststellung bei virtualisierten Infrastrukturen
Wird Virtualisierung eingesetzt, bleibt die Schutzbedarfsfeststellung im Prinzip gleich. Um den
Schutzbedarf eines IT-Systems zu bestimmen, müssen zunächst die Anwendungen betrachtet wer­
den, die im direkten Zusammenhang mit dem IT-System stehen. In virtualisierten Infrastrukturen wer-
den in der Regel mehrere IT-Systeme auf einem Virtualisierungsserver betrieben. Der Schutzbedarf der
Anwendungen vererbt sich auf die virtuellen IT-Systeme. Die virtuellen IT-Systeme ihrerseits vererben
ihren Schutzbedarf auf den Virtualisierungsserver. Für den Schutzbedarf eines Virtualisierungsservers
lassen sich folgende Fälle unterscheiden:
Vertraulichkeit
Ist der Schutzbedarf der virtuellen IT-Systeme beispielsweise „normal“, so vererbt sich dieser auf den
Virtualisierungsserver. Er bekommt in der Regel auch den Schutzbedarf „normal“. Es sollte überlegt
werden, ob durch die Kumulation mehrerer (z. B. kleinerer) Schäden auf dem Virtualisierungsserver
ein insgesamt höherer Gesamtschaden entstehen kann. Dann erhöht sich der Schutzbedarf des Vir­
tualisierungsservers entsprechend auf „hoch“ (Kumulationseffekt).
Integrität
Das Schutzziel Integrität wird nicht gesondert betrachtet und ist wie Vertraulichkeit zu behandeln.
Verfügbarkeit
Ist der Schutzbedarf der virtuellen IT-Systeme beispielsweise „normal“, dann kommt es durch den
Kumulationseffekt in der Regel zu einer Erhöhung der Verfügbarkeit. Gleichzeitig bietet Virtualisie­
rung mit Konzepten wie Cold-, Warm- oder Hot-Standby die Möglichkeit, Redundanzen zu schaffen.
Dabei wird parallel zum Produktivsystem ein identisches Ersatzsystem auf einem weiteren physischen
Server aufgebaut und entweder ausgeschaltet (Cold-Standby) oder kurzfristig einschaltbar gehalten,
aber nicht eingesetzt (Warm-Standby) oder eingeschaltet und synchron gespiegelt mit Daten versorgt
(Hot-Standby). Sind entsprechende Maßnahmen umgesetzt, dann sinkt der Schutzbedarf (Vertei­
lungseffekt). Es können unter anderem folgende Fälle auftreten:
• Die virtuellen Maschinen weisen in Bezug auf Verfügbarkeit den Schutzbedarf „normal“ auf, dann
gibt es in der Regel eine Kumulation nach „hoch“ und dann durch Verteilung sinkt der Schutzbe­
darf wieder auf „normal“. In diesem Fall reicht der Warm-Standby-Ansatz aus.
• Die virtuellen Maschinen haben den Schutzbedarf „hoch“ in Bezug auf Verfügbarkeit. Aufgrund
von Kumulation kann sich ein insgesamt sehr hoher Schutzbedarf ergeben, der dann wegen Ver­
teilung auf „hoch“ abgesenkt werden kann, wenn entsprechende Maßnahmen (z. B. Hot-Stand­
by) umgesetzt werden.
Schutzbedarfsfeststellung beim Cloud-Computing (IaaS Compute)
Auch beim Cloud Computing ändert sich gegenüber der oben beschriebenen Schutzbedarfsfeststel­
lung wenig. Bei Angeboten der Form „IaaS Compute“ werden den Benutzern virtuelle Maschinen zur
Verfügung gestellt, z. B. über eine Webschnittstelle. Ähnlich wie bei der Virtualisierung wird der
Schutzbedarf des Virtualisierungsservers durch den Schutzbedarf der auf ihm betriebenen virtuellen
IT-Systeme beeinflusst. Techniken wie Live Migration, vMotion oder XenMotion ermöglichen, dass die
virtuellen Maschinen zwischen den Virtualisierungsservern verschoben werden oder Hostsysteme bei
geringer Last in den Stand-by-Modus geschaltet oder sogar heruntergefahren werden können, um
Strom zu sparen. Die Vorteile, die sich dadurch ergeben, sind unbestritten. Aber die Live Migration,
also die Verschiebung von VMs zwischen Virtualisierungsservern, erschwert die Schutzbedarfsfest­
1188 Erstellung einer Sicherheitskonzeption nach Standard-Absicherung
stellung. Daher wird empfohlen, die Cloud-Computing-Plattform für unterschiedliche Bereiche (Vir­
tualisierungscluster) anzulegen, abhängig vom Schutzbedarf (zum Beispiel „normal“ oder „hoch“).
Anwendungen, die denselben Schutzbedarf aufweisen, sollten dann auf einem hierfür vorgesehenen
Virtualisierungscluster betrieben werden. Die einzelnen Bereiche sollten untereinander physisch ge­
trennt sein und es ist sicherzustellen, dass virtuelle Maschinen nicht bereichsübergreifend verschoben
werden können.
Auf eine gesonderte Schutzbedarfsfeststellung für virtuelle IT-Systeme und Virtualisierungsserver
kann verzichtet werden.
Besitzen die meisten Anwendungen auf einem IT-System nur einen normalen Schutzbedarf und
sind nur eine oder wenige hochschutzbedfrftig, so sollte in Erwägung gezogen werden, die
hochschutzbedfrftigen Anwendungen auf ein isoliertes IT-System auszulagern, da dies wesent­
lich gezielter abgesichert werden kann und somit häufig kostengfnstiger ist. Eine solche Alterna­
tive kann dem Management zur Entscheidung vorgelegt werden.
8.2.5 Schutzbedarfsfeststellung für ICS-Systeme
Im Bereich industrieller Steuerungsanlagen muss der Schutzbedarf aller ICS-Systeme festgestellt wer­
den. Die ICS-Systeme wurden bereits in Kapitel 8.1.6 erfasst.
Bei der Feststellung des Schutzbedarfes für die ICS-Systeme muss berücksichtigt werden, dass nicht
per se alle Objekte einem sehr hohen Schutzbedarf unterliegen. In enger Abstimmung ist es sinnvoll,
mit den Verantwortlichen der ICS-Systeme in einem Gespräch die Schutzbedarfsfeststellung durch­
zuführen, da diese wissen, welche ICS-Geräte welche Anforderungen an Vertraulichkeit, Integrität
und Verfügbarkeit haben. Der Schutzbedarf leitet sich hierbei aus dem Anwendungszweck der indu­
striellen Steuerungsanlage ab.
Dabei sollte berücksichtigt werden, dass ICS-Systeme für verschiedene Aufgaben verwendet werden
können. So kann in einer Produktionsstraße im Wechsel ein für ein Unternehmen wichtiges umsatz­
starkes Produkt produziert werden und ein weniger umsatzstarkes Produkt. Bei der Feststellung des
Schutzbedarfs müssen diese Abhängigkeiten beachtet werden (Maximumprinzip).
Für die Definition des Schutzbedarfes kann es sinnvoll sein, die für alle weiteren Schutzbedarfsfest­
stellungen definierten Klassifikationen zu übernehmen. Darüber hinaus können die Schutzbedarfska­
tegorien entsprechend angepasst formuliert werden.
Beispiel: RECPLAST GmbH
Für ein IT-System aus einer Büroumgebung liegt eine Ausfallzeit von bis zu 30 Stunden im normalen
Bereich. Diese Ausfallzeit kann auch für den Betrieb von ICS-Systemen sinnvoll sein, möglicherweise
ist es jedoch erforderlich, die Ausfallzeit für die ICS-Geräte im normalen Schutzbedarf auf zwölf bis 24
Stunden zu reduzieren.
Der Schutzbedarf für jedes ICS-System wird bezüglich Vertraulichkeit, Integrität und Verfügbarkeit
ermittelt. Der Gesamtschutzbedarf der ICS-Systeme leitet sich nach dem Maximumprinzip bezüglich
der drei Grundwerte der Vertraulichkeit, Integrität und Verfügbarkeit ab.
Die Festlegungen des Schutzbedarfs von ICS-Systeme müssen kurz begründet werden, damit die
Entscheidungen für Dritte nachvollziehbar sind.
119
Hinweis:120
Die
Maximumprinzip
sehr hoch
SPSen
jederzeit
sein.
fügbarkeit
für
Verfügbarkeit
vorhan­
(ICS-Systeme)
8.2 Schutzbedarfsfeststellung8 Erstellung einer Sicherheitskonzeption nach Standard-Absicherung
8.2.6 Schutzbedarfsfeststellung für sonstige Geräte
Um den Schutzbedarf sonstiger Geräte festzustellen, muss zunächst bestimmt werden, für welche
Geschäftsprozesse und Anwendungen diese Geräte eingesetzt werden und wie sich deren Schutzbe­
darf vererbt. Diese Informationen wurden in Kapitel 8.1.7 ermittelt. Dabei muss der Datenfluss über
diese Geräte beachtet werden, über den sich der Schutzbedarf auf die dazwischenliegenden Netz­
komponenten vererbt.
Es sollte vermerkt werden, welchen Schutzbedarf jedes Gerät bezüglich Vertraulichkeit, Integrität und
Verfügbarkeit hat. Der Gesamtschutzbedarf eines Geräts leitet sich wiederum aus dem Maximum des
Schutzbedarfs bezüglich der drei Grundwerte Vertraulichkeit, Integrität und Verfügbarkeit ab.
Die Festlegungen des Schutzbedarfs von Geräten müssen kurz begründet werden, damit die Entschei­
dungen auch für Außenstehende nachvollziehbar sind. Hier kann auf die Schutzbedarfsfeststellung
der Geschäftsprozesse und Anwendungen zurückverwiesen werden.
In Institutionen werden je nach Branche unterschiedlichste Geräte eingesetzt, um die Geschäftspro­
zesse zu unterstützen. Neben IT-Systemen, die unmittelbar als solche zu identifizieren sind, können
auch viele andere Arten von Geräten Einfluss auf die Informationssicherheit haben. Zu solchen Gerä­
ten gehören beispielsweise Geräte mit Funktionalitäten aus dem Bereich Internet of Things (IoT).
121
Um den Schutzbedarf eines Geräts zu ermitteln, müssen nun die möglichen Schäden der relevanten
Geschäftsprozesse in ihrer Gesamtheit betrachtet werden. Die Ergebnisse der Schutzbedarfsfeststel­
lung von Geräten sollten wiederum in einer Tabelle festgehalten werden, wenn diese Einfluss auf die
Informationssicherheit haben. Um nicht beliebig viele Geräte in einer Institution erfassen zu müssen,
sollten nur Geräte betrachtet werden, die die Informationssicherheit nennenswert beeinträchtigen
könnten. Diese sollten möglichst zu Gruppen zusammengefasst und als ein Objekt behandelt werden.122
die
den
entsprechenden
Korrekt­
Daten
wichtig. Durch
Aufnahmebereiche normal Kühlschrank
vertraulichen
für
Verfügbarkeit
hoch
GmbH
8.2 Schutzbedarfsfeststellung8 Erstellung einer Sicherheitskonzeption nach Standard-Absicherung
Aktionspunkte zu 8.2.4, 8.2.5 und 8.2.6 Schutzbedarfsfeststellung für IT-, ICS-Systeme und
sonstige Geräte
• Schutzbedarf der IT-, ICS-Systeme und sonstigen Geräte anhand des Schutzbedarfs der Ge­
schäftsprozesse und Anwendungen ermitteln
• Abhängigkeiten, das Maximumprinzip und gegebenenfalls den Kumulations- beziehungsweise
Verteilungseffekt berücksichtigen
• Pro System(-Gruppe) die Ergebnisse für Vertraulichkeit, Integrität und Verfügbarkeit sowie die
Begründungen dokumentieren
Aus den Ergebnissen der Schutzbedarfsfeststellung der Geschäftsprozesse und Anwendungen sowie
der IT-Systeme, ICS- und sonstigen Geräte sollte abgeleitet werden, welcher Schutzbedarf für die
jeweiligen Liegenschaften bzw. Räume daraus resultiert. Dieser Schutzbedarf leitet sich aus dem
Schutzbedarf der im jeweiligen Raum installierten Objekte, verarbeiteten Informationen oder der Da­
tenträger, die in diesem Raum gelagert und benutzt werden, nach dem Maximumprinzip ab. Dabei
sollten eventuelle Abhängigkeiten und ein möglicher Kumulationseffekt berücksichtigt werden,
wenn sich in einem Raum eine größere Anzahl von IT-Systemen oder ICS-Geräten, Datenträgern usw.
befindet, wie typischerweise bei Serverräumen, Rechenzentren, Werkhallen oder Datenträgerarchi­
ven. Für jede Schutzbedarfseinschätzung sollte eine Begründung dokumentiert werden.
Hilfreich ist auch hier eine tabellarische Erfassung der notwendigen Informationen, aufbauend auf der
bereits vorher erstellten Übersicht über die erfassten Räume.
123
8.2.7 Schutzbedarfsfeststellung für Räume124
dürfen
häuslichen normal
keine
bearbeitet
Besprechungs­
werden
Unterlagen
Begründung
Verfügbarkeit
GmbH
8.2 Schutzbedarfsfeststellung8 Erstellung einer Sicherheitskonzeption nach Standard-Absicherung
Aktionspunkte zu 8.2.7 Schutzbedarfsfeststellung für Räume
• Schutzbedarf der Räume aus dem Schutzbedarf der Geschäftsprozesse, Anwendungen und
IT-Systeme, ICS- und sonstigen Geräte ableiten
• Abhängigkeiten, das Maximumprinzip und gegebenenfalls den Kumulationseffekt berücksichti­
gen
• Ergebnisse und Begründungen nachvollziehbar dokumentieren
Nachdem die Schutzbedarfsfeststellung für die betrachteten Geschäftsprozesse, Anwendungen,
IT-Systeme, ICS- und sonstigen Geräte und Räume abgeschlossen wurde, wird nun der Schutzbedarf
bezüglich der Vernetzungsstruktur erarbeitet. Grundlage für die weiteren Überlegungen ist der in
Kapitel 8.1.4 Netzplanerhebung erarbeitete Netzplan des zu untersuchenden Informationsverbunds.
Um die Entscheidungen vorzubereiten, auf welchen Kommunikationsstrecken kryptografische Sicher­
heitsmaßnahmen eingesetzt werden sollten, welche Strecken redundant ausgelegt sein sollten und
über welche Verbindungen Angriffe durch Innen- und Außentäter zu erwarten sind, müssen die Kom­
munikationsverbindungen analysiert werden. Hierbei werden folgende Kommunikationsverbindun­
gen als kritisch gewertet:
• Kommunikationsverbindungen, die Außenverbindungen darstellen, d. h. die in oder über unkon­
trollierte Bereiche führen (z. B. ins Internet oder über öffentliches Gelände). Dazu können auch
drahtlose Kommunikationsverbindungen gehören, da es hierbei schwierig ist, zu verhindern, dass
auf diese von öffentlichem Gelände aus zugegriffen wird. Bei Außenverbindungen besteht die
Gefahr, dass durch externe Angreifer Penetrationsversuche auf das zu schützende System vorge­
nommen oder Schadprogramme eingespielt werden können. Darüber hinaus könnten unter Um­
ständen Innentäter über eine solche Verbindung vertrauliche Informationen nach außen übertra­
gen. Auch in Bezug auf den Grundwert Verfügbarkeit sind Außenverbindungen oft besonders
gefährdet. Es darf nicht vergessen werden, Außenverbindungen für die Fernadministration mit
zu erfassen.
• Kommunikationsverbindungen, über die hochschutzbedürftige Informationen übertragen wer­
den, wobei dies sowohl Informationen mit einem hohen Anspruch an Vertraulichkeit wie auch
Integrität oder Verfügbarkeit sein können. Diese Verbindungen können das Angriffsziel vorsätzli­
chen Abhörens oder vorsätzlicher Manipulation sein. Darüber hinaus kann der Ausfall einer sol­
chen Verbindung die Funktionsfähigkeit wesentlicher Teile des Informationsverbunds beeinträch­
tigen.
• Kommunikationsverbindungen, die im produzierenden Bereich eingesetzt werden, müssen im
Netzplan ebenfalls erfasst werden. Dazu gehören (z. B. bei einer Netztrennung) die Kommunika­
tionsverbindungen zwischen den Netzen.
Bei der Erfassung der kritischen Kommunikationsverbindungen kann wie folgt vorgegangen werden.
Zunächst werden sämtliche „Außenverbindungen“ als kritische Verbindungen identifiziert und er­
fasst. Anschließend werden sämtliche Verbindungen untersucht, die von einem IT-System oder einer
Gruppe von IT-Systemen mit hohem oder sehr hohem Schutzbedarf ausgehen. Dabei werden dieje­
nigen Verbindungen identifiziert, über die hochschutzbedürftige Informationen übertragen werden.
Danach werden die Verbindungen untersucht, über die diese hochschutzbedürftigen Daten weiter­
125
8.2.8 Schutzbedarfsfeststellung für Kommunikationsverbindungen8.2 Schutzbedarfsfeststellung
geleitet werden. Abschließend sind die Kommunikationsverbindungen zu identifizieren, über die der­
lei Informationen nicht übertragen werden dürfen. Zu erfassen sind dabei:
• die Verbindungsstrecke,
• ob es sich um eine Außenverbindung handelt und
• ob hochschutzbedürftige Informationen übertragen werden und ob der Schutzbedarf aus der Ver­
traulichkeit, Integrität oder Verfügbarkeit resultiert.
Die Entscheidungen, welche Kommunikationsverbindungen als kritisch zu betrachten sind, sollten
tabellarisch dokumentiert oder grafisch im Netzplan hervorgehoben werden.
Beispiel: RECPLAST GmbH
Für das Unternehmen RECPLAST GmbH ergeben sich die Kommunikationsverbindungen, die im Netz­
plan im Kapitel 8.1.4 Netzplanerhebung dargestellt wurden. Diese wurden bei der RECPLAST auf­
grund von ähnlichen Anforderungen gruppiert und sowohl in der Strukturanalyse als auch in der
Schutzbedarfsfeststellung beschrieben und bewertet. Anhand der folgenden Tabellen können die
oben dargestellten Kommunikationsverbindungen nachvollzogen werden:
126Betrieb
Mitarbeiter
Verantwortlich
Administrator
8 Erstellung einer Sicherheitskonzeption nach Standard-Absicherung
127128
Administratoren
/
Administrator
8.2 SchutzbedarfsfeststellungMaximumprinzip
Es hoch Standleitung
internen
ministratoren
wurde,
Informationen
hohem
fälscht inner­
Netze
werden,
von
werden.
Begründung
Verfügbarkeit
(Kommunikationsverbindungen)
8 Erstellung einer Sicherheitskonzeption nach Standard-Absicherung
1298.2 Schutzbedarfsfeststellung
Aktionspunkte zu 8.2.8 Schutzbedarfsfeststellung für Kommunikationsverbindungen
• Außenverbindungen erfassen und in tabellarischer oder grafischer Form dokumentieren
• Verbindungen, über die kritische Informationen übertragen werden, identifizieren
• Alle kritischen Kommunikationsverbindungen in tabellarischer oder grafischer Form dokumen­
tieren
8.2.9 Schlussfolgerungen aus den Ergebnissen der Schutzbedarfsfeststellung
Die bei der Schutzbedarfsfeststellung erzielten Ergebnisse bieten einen Anhaltspunkt für die weitere
Vorgehensweise der Sicherheitskonzeption. Für den Schutz, der von den in den IT-Grundschutz-Bau­
steinen beschriebenen Sicherheitsanforderungen ausgeht, wird bezüglich der Schutzbedarfskatego­
rien Folgendes angenommen:
Schutzwirkung von Sicherheitsanforderungen nach IT-Grundschutz
Schutzbedarfskategorie „normal“ Sicherheitsanforderungen nach IT-Grundschutz sind im
Allgemeinen ausreichend und angemessen.
Schutzbedarfskategorie „hoch“ Sicherheitsanforderungen nach IT-Grundschutz liefern
eine Standard-Absicherung, sind aber unter Umständen
alleine nicht ausreichend. Weitergehende Maßnahmen
sollten auf Basis einer Risikoanalyse ermittelt werden.
Schutzbedarfskategorie „sehr hoch“ Sicherheitsanforderungen nach IT-Grundschutz liefern
eine Standard-Absicherung, reichen aber alleine im All­
gemeinen nicht aus. Die erforderlichen zusätzlichen Si­
cherheitsmaßnahmen müssen individuell auf der Grund­
lage einer Risikoanalyse ermittelt werden.
Tabelle 5: Schutzwirkung von Sicherheitsanforderungen nach IT-Grundschutz
Außer bei hohem oder sehr hohem Schutzbedarf muss eine Risikoanalyse auch dann durchgeführt
werden, wenn die Objekte des betrachteten Informationsverbunds
• mit den existierenden Bausteinen des IT-Grundschutzes nicht hinreichend abgebildet (modelliert)
werden können oder
• in Einsatzszenarien (Umgebung, Anwendung) betrieben werden, die im Rahmen des IT-Grund­
schutzes nicht vorgesehen sind.
Ausführliche Informationen zur Risikoanalyse finden sich in Kapitel 8.5.
Bereiche mit unterschiedlichem Schutzbedarf
Bei der Schutzbedarfsfeststellung zeigt sich häufig, dass es Bereiche innerhalb des betrachteten Infor­
mationsverbunds gibt, in denen Informationen verarbeitet werden, die einen hohen oder sehr hohen
Schutzbedarf haben. Auch wenn nur wenige, herausgehobene Daten besonders schutzbedürftig
sind, führt die starke Vernetzung und Kopplung von IT-Systemen, ICS- und sonstigen Geräten und
Anwendungen schnell dazu, dass sich der höhere Schutzbedarf nach dem Maximumprinzip auf an­
dere Bereiche überträgt.
1308 Erstellung einer Sicherheitskonzeption nach Standard-Absicherung
Um Risiken und Kosten einzudämmen, sollten daher Sicherheitszonen zur Trennung von Bereichen
mit unterschiedlichem Schutzbedarf eingerichtet werden. Solche Sicherheitszonen können sowohl
räumlich als auch technisch oder personell ausgeprägt sein.
Beispiele:
• Technische Sicherheitszonen: Um vertrauliche Daten auf bestimmte Bereiche innerhalb eines
LANs zu begrenzen und um zu verhindern, dass Störungen in bestimmten Komponenten oder
Angriffe die Funktionsfähigkeit beeinträchtigen, ist es hilfreich, das LAN in mehrere Teilnetze
aufzuteilen (siehe auch Baustein NET.1.1 Netzarchitektur und -design im IT-Grundschutz-Kom­
pendium).
• Personelle Sicherheitszonen: Grundsätzlich sollten an jede Person immer nur so viele Rechte
vergeben werden, wie es ffr die Aufgabenwahrnehmung erforderlich ist. Darfber hinaus gibt
es auch verschiedene Rollen, die eine Person nicht gleichzeitig wahrnehmen sollte. So sollte ein
Revisor nicht gleichzeitig in der Buchhaltung und in der IT-Administration arbeiten, da er sich
nicht selbst kontrollieren kann und darf. Um die Vergabe von Zugangs- und Zutrittsrechte zu
vereinfachen, sollten Personengruppen, die nicht miteinander vereinbare Funktionen wahr­
nehmen, in getrennten Gruppen oder Abteilungen arbeiten.
• Zonenkonzept bei virtualisierten Infrastrukturen:
Wird Virtualisierung eingesetzt, dann muss dies auch im technischen Zonenkonzept berfck­
sichtigt werden. Virtualisierung bedeutet eine Konsolidierung der Server, d. h. die Möglichkeit,
mehrere Server virtuell auf einem physischen Host zu betreiben. Hierbei können die eingesetz­
ten Server unterschiedlichem Schutzbedarf unterliegen, aufgrund der verschiedenen Anwen­
dungen und Dienste, die darauf laufen. Daher sollte vor einer Virtualisierung festgelegt wer­
den, welche Dienste oder Anwendungen zusammen in einer virtuellen Umgebung betrieben
werden dfrfen und welche durch geeignete Maßnahmen separiert werden mfssen. Bei der
Segmentierung sollte darauf geachtet werden, dass alle Bereiche der IT-Infrastruktur („Server“,
„Netze“, „Storage“ und „Management“) erfasst sind.
Bei der Entscheidung, welche Systeme auf einer gemeinsamen physischen Hardware virtuali­
siert werden dfrfen, ist Folgendes zu beachten:
• Die Server sollten aus organisatorischer Sicht und aus Sicherheitsgrfnden sinnvoll in Zonen
gruppiert werden. Zonen sollten nicht zusammen mit der Sicherheitskomponente, die ffr
die Separierung der Zonen sorgt, virtualisiert werden.
• Welche Komponenten zusammen auf einer gemeinsamen physischen Hardware virtualisiert
werden können, ist abhängig vom Schutzbedarf und Bedarfsträger.
Bedarfsträger können unterschiedliche Mandanten (Hosting-Szenarien), unterschiedliche Or­
ganisationseinheiten innerhalb eines Unternehmens oder einer Behörde oder unterschiedliche
Verfahren sein. Im ersten Fall besteht die Herausforderung bei der Planung, ein gleiches Ver­
ständnis der Bedarfsträger fber die verwendeten Schutzbedarfskategorien zu erreichen.
131
• Räumliche Sicherheitszonen: Um nicht jeden einzelnen Bfroraum permanent abschließen
oder fberwachen zu mfssen, sollten Zonen mit starkem Besucherverkehr von hochschutzbe­
dfrftigen Bereichen getrennt werden. So sollten sich Besprechungs-, Schulungs- oder Veran­
staltungsräume ebenso wie eine Kantine, die externes Publikum anzieht, in der Nähe des Ge­
bäudeeingangs befinden. Der Zugang zu Gebäudeteilen mit Bfros kann dann von einem Pfört­
ner einfach fberwacht werden. Besonders sensitive Bereiche wie eine Entwicklungsabteilung
sollten mit einer zusätzlichen Zugangskontrolle, z. B. fber Chipkarten, abgesichert werden.8.3 Modellierung eines Informationsverbunds
• Zonenkonzept beim Cloud Computing:
Um dem unterschiedlichen Schutzbedarf der Anwender Rechnung zu tragen, mfssen Cloud-Com­
puting-Plattformen mandantenfähig sein und eine verlässliche und durchgängige Trennung der
Anwender fber den kompletten Cloud-Computing-Stack (Server, Netze, Storage und Manage­
ment) gewährleisten. Neben den gängigen Sicherheitsmaßnahmen wie Schadprogramm- und
Spamschutz, IDS und IPS sollte auf Netzebene auf eine geeignete Segmentierung geachtet werden,
indem abhängig vom Schutzbedarf Sicherheitszonen definiert und eingerichtet werden. Beispiele
hierffr sind:
• Sicherheitszone ffr das Management der Cloud
• Sicherheitszone ffr die Live Migration
• Sicherheitszone ffr das Storage-Netz
• Sicherheitszonen ffr die virtuellen Maschinen
Darfber hinaus wird empfohlen, unterschiedliche Zonen ffr die Server-Hardware anhand des
Schutzbedarfs einzurichten und diese untereinander unter Verwendung von Sicherheitsgateways
zu trennen.
Bei der Planung neuer Geschäftsprozesse, Fachaufgaben oder Anwendungen sollte frühzeitig geprüft
werden, ob es zweckmäßig ist, Sicherheitszonen einzurichten. Häufig kann dadurch in allen nachfol­
genden Phasen bis hin zur Revision viel Arbeit gespart werden.
Aktionspunkte zu 8.2.9 Schlussfolgerungen aus den Ergebnissen der Schutzbedarfsfest­
stellung
• Prüfen, ob Objekte mit erhöhten Sicherheitsanforderungen in Sicherheitszonen konzentriert wer­
den können
• Objekte mit erhöhten Sicherheitsanforderungen für eine Risikoanalyse vormerken
8.3
Modellierung eines Informationsverbunds
Nachdem die notwendigen Informationen aus der Strukturanalyse und der Schutzbedarfsfeststellung
vorliegen, besteht der nächste Schritt darin, den betrachteten Informationsverbund mithilfe der vor­
handenen Bausteine aus dem IT-Grundschutz-Kompendium nachzubilden. Das Ergebnis ist ein
IT-Grundschutz-Modell des Informationsverbunds, das aus verschiedenen, gegebenenfalls auch
mehrfach verwendeten Bausteinen besteht und durch die Verwendung der Bausteine die sicherheits­
relevanten Aspekte des Informationsverbunds beinhaltet.
8.3.1 Das IT-Grundschutz-Kompendium
Das IT-Grundschutz-Kompendium (siehe [GSK]) kann in der jeweils aktuellen Fassung vom BSI-Web­
server heruntergeladen oder beim Bundesanzeiger Verlag erworben werden.
Die IT-Grundschutz-Bausteine
Das IT-Grundschutz-Kompendium enthält für verschiedene Vorgehensweisen, Komponenten und
IT-Systeme die Gefährdungslage, Sicherheitsanforderungen und weiterführende Informationen, die
jeweils in einem Baustein zusammengefasst sind.
1328 Erstellung einer Sicherheitskonzeption nach Standard-Absicherung
Um Innovationsschübe und Versionswechsel vor allem im IT-Bereich zu berücksichtigen, ist das
IT-Grundschutz-Kompendium mithilfe seiner Bausteinstruktur modular aufgebaut und konzentriert
sich auf die Darstellung der wesentlichen Sicherheitsanforderungen für die jeweiligen Bausteine. Da­
mit ist es leicht erweiter- und aktualisierbar. Übergeordnet sind die Bausteine in prozess- und system­
orientierte Bausteine aufgeteilt und nach zusammengehörigen Themen in ein Schichtenmodell ein­
sortiert.
Die prozessorientierten Bausteine sind in die folgenden Schichten gruppiert:
• ISMS (Managementsysteme für Informationssicherheit)
• ORP (Organisation und Personal)
• CON (Konzepte und Vorgehensweisen)
• OPS (Betrieb)
• DER (Detektion und Reaktion)
Die systemorientierten Bausteine sind in die folgenden Schichten gruppiert:
• INF (Infrastruktur)
• NET (Netze und Kommunikation)
• SYS (IT-Systeme)
• APP (Anwendungen)
• IND (Industrielle IT)
Gefährdungen
In jedem Baustein wird zunächst die zu erwartende spezifische Gefährdungslage beschrieben. Ergän­
zend hierzu befindet sich im separaten Anhang der jeweiligen Bausteine eine Auflistung der elemen­
taren Gefährdungen, die bei der Erstellung des Bausteins berücksichtigt wurden. Diese Gefährdungs­
liste ist Teil einer ersten Stufe der vereinfachten Risikoanalyse für typische Umgebungen der Informa­
tionsverarbeitung und bildet die Grundlage, auf Basis derer das BSI spezifische Anforderungen
zusammengestellt hat, um ein angemessenes Niveau der Informationssicherheit in einer Institution
zu gewährleisten. Der Vorteil dabei ist, dass die Anwender bei typischen Anwendungsfällen keine
aufwändigen oder weiterführenden Analysen benötigen, um das für einen normalen Schutzbedarf
notwendige Sicherheitsniveau zu erreichen. Vielmehr ist es ausreichend, die für die betrachteten Ge­
schäftsprozesse, und ihrer notwendigen Ressourcen relevanten Bausteine zu identifizieren und die
darin empfohlenen Anforderungen konsequent und vollständig zu erfüllen.
Auch wenn besondere Komponenten oder Einsatzumgebungen vorliegen, die im IT-Grundschutz
nicht hinreichend behandelt werden, bietet das IT-Grundschutz-Kompendium dennoch eine wertvolle
Arbeitshilfe. Die dann notwendige Risikoanalyse kann sich auf die elementaren Gefährdungen dieser
Komponenten oder Rahmenbedingungen konzentrieren.
Sicherheitsanforderungen
In jedem Baustein werden die Sicherheitsanforderungen, die für den Schutz des betrachteten Gegen­
stands relevant sind, aufgeführt. Sie beschreiben, was zu dessen Schutz zu tun ist. Die Anforderungen
sind in drei Kategorien unterteilt:
• Basis-Anforderungen müssen vorrangig erfüllt werden, da bei diesen Empfehlungen mit (relativ)
geringem Aufwand der größtmögliche Nutzen erzielt werden kann. Es handelt sich um uneinge­
1338.3 Modellierung eines Informationsverbunds
schränkte Anforderungen. Die Basis-Anforderungen sind ebenfalls die Grundlage für die Vorge­
hensweise „Basis-Absicherung“.
• Standard-Anforderungen bauen auf den Basis-Anforderungen auf und adressieren den norma­
len Schutzbedarf. Sie sollten grundsätzlich erfüllt werden, aber nicht vorrangig. Die Ziele der Stan­
dard-Anforderungen müssen erreicht werden, um eine Standard-Absicherung zu erzielen. Es kön­
nen sich aber durch die jeweiligen Rahmenbedingungen der Institution auch Gründe ergeben,
warum eine Standard-Anforderung nicht wie beschrieben umgesetzt wird, sondern die Sicher­
heitsziele auf andere Weise erreicht werden. Wenn eine Standard-Anforderung durch andere Si­
cherheitsmaßnahmen erfüllt wird, müssen die dadurch entstehenden Auswirkungen sorgfältig
abgewogen und geeignet dokumentiert werden.
• Anforderungen bei erhöhtem Schutzbedarf sind eine Auswahl von Vorschlägen für eine wei­
terführende Absicherung, die bei erhöhten Sicherheitsanforderungen oder unter bestimmten Rah­
menbedingungen als Grundlage für die Erarbeitung geeigneter Anforderungen und Maßnahmen
berücksichtigt werden können.
Die Bausteine wenden sich an Sicherheitsbeauftragte und Sicherheitsverantwortliche in Institutionen.
Umsetzungshinweise
Zusätzlich zu den Bausteinen des IT-Grundschutz-Kompendiums kann es Umsetzungshinweise ge­
ben. Diese beschreiben, wie die Anforderungen der Bausteine umgesetzt werden können, und ent­
halten dafür passende Sicherheitsmaßnahmen mit einer detaillierten Beschreibung. Die Sicherheits­
maßnahmen können als Grundlage für Sicherheitskonzeptionen verwendet werden, sollten aber un­
ter Umständen noch an die Rahmenbedingungen der jeweiligen Institution angepasst werden.
Die Umsetzungshinweise adressieren jeweils die Personengruppen, die für die Umsetzung der Anfor­
derungen aus den Bausteinen zuständig sind, beispielsweise den IT-Betrieb oder die Haustechnik.
Diese Umsetzungshinweise werden für ausgewählte, vor allem für stark nachgefragte Themen be­
reitgestellt.
8.3.2 Modellierung eines Informationsverbunds: Auswahl von Bausteinen
Das erstellte IT-Grundschutz-Modell ist unabhängig davon, ob der Informationsverbund aus bereits im
Einsatz befindlichen Komponenten besteht oder ob es sich um einen Informationsverbund handelt,
der sich ganz oder teilweise im Planungsstadium befindet. Jedoch kann das Modell unterschiedlich
verwendet werden:
• Das IT-Grundschutz-Modell eines bereits realisierten Informationsverbunds identifiziert über die
verwendeten Bausteine die relevanten Sicherheitsanforderungen. Es kann in Form eines Prüfplans
benutzt werden, um einen Soll-Ist-Vergleich durchzuführen.
• Das IT-Grundschutz-Modell eines geplanten Informationsverbunds stellt hingegen ein Entwick­
lungskonzept dar. Es beschreibt über die ausgewählten Bausteine, welche Sicherheitsanforde­
rungen bei der Realisierung des Informationsverbunds erfüllt werden müssen.
1348 Erstellung einer Sicherheitskonzeption nach Standard-Absicherung
Die Einordnung der Modellierung und die möglichen Ergebnisse verdeutlicht die folgende Abbildung:
Abbildung 27: Ergebnis der Modellierung nach IT-Grundschutz
Typischerweise wird ein im Einsatz befindlicher Informationsverbund sowohl realisierte als auch in Pla­
nung befindliche Anteile umfassen. Das resultierende IT-Grundschutz-Modell beinhaltet dann sowohl
einen Prüfplan wie auch Anteile eines Entwicklungskonzepts. Alle im Prüfplan bzw. im Entwicklungskon­
zept vorgesehenen Sicherheitsanforderungen bilden dann gemeinsam die Basis für die Erstellung des
Sicherheitskonzepts. Dazu gehören neben den bereits erfüllten Sicherheitsanforderungen die bei Durch­
führung des Soll-Ist-Vergleichs als unzureichend oder gar nicht erfüllt identifizierten Anforderungen so­
wie diejenigen, die sich für die in Planung befindlichen Anteile des Informationsverbunds ergeben.
Um einen im Allgemeinen komplexen Informationsverbund nach IT-Grundschutz zu modellieren, müs­
sen die passenden Bausteine des IT-Grundschutz-Kompendiums ausgewählt und umgesetzt werden.
Um die Auswahl zu erleichtern, sind die Bausteine im IT-Grundschutz-Kompendium zunächst in prozess­
und systemorientierte Bausteine aufgeteilt und diese jeweils in einzelne Schichten untergliedert.
Die Sicherheitsaspekte eines Informationsverbunds werden wie folgt den einzelnen Schichten zuge­
ordnet:
1358.3 Modellierung eines Informationsverbunds
Abbildung 28: Das Schichtenmodell des IT-Grundschutzes
Prozessorientierte Bausteine:
• Die Schicht ISMS enthält als Grundlage für alle weiteren Aktivitäten im Sicherheitsprozess den
Baustein Sicherheitsmanagement.
• In der Schicht ORP finden sich Bausteine, die organisatorische und personelle Sicherheitsaspekte
abdecken, wie die Bausteine Organisation und Personal.
• Die Schicht CON enthält Bausteine, die sich mit Konzepten und Vorgehensweisen befassen. Typi­
sche Bausteine der Schicht CON sind unter anderem Kryptokonzept und Datenschutz.
• Die Schicht OPS umfasst alle Sicherheitsaspekte betrieblicher Art. Insbesondere sind dies die Sicher­
heitsaspekte des operativen IT-Betriebs, sowohl bei einem Betrieb im Haus als auch bei einem IT-Be­
trieb, der in Teilen oder komplett durch Dritte betrieben wird. Ebenso enthält er die Sicherheitsas­
pekte, die bei einem IT-Betrieb für Dritte zu beachten sind. Beispiele für die Schicht OPS sind die
Bausteine Schutz vor Schadprogrammen und Outsourcing für Kunden.
• In der Schicht DER finden sich alle Bausteine, die für die Überprüfung der umgesetzten Sicherheits­
maßnahmen und insbesondere für die Detektion von Sicherheitsvorfällen sowie die geeigneten
Reaktionen darauf relevant sind. Typische Bausteine der Schicht DER sind Behandlung von Sicher­
heitsvorfällen und Forensik.
System-Bausteine:
• Die Schicht APP beschäftigt sich mit der Absicherung von Anwendungen und Diensten, unter an­
derem in den Bereich Kommunikation, Verzeichnisdienste, netzbasierte Dienste sowie Business-
und Client-Anwendungen. Typische Bausteine der Schicht APP sind Groupware, Office-Produkte,
Webserver und Browser.
• Die Schicht SYS betrifft die einzelnen IT-Systeme des Informationsverbunds, die gegebenenfalls in
Gruppen zusammengefasst wurden. Hier werden die Sicherheitsaspekte von Servern, Desk­
top-Systemen, Mobile Devices und sonstigen IT-Systemen wie Druckern und TK-Anlagen behan­
delt. Zur Schicht SYS gehören beispielsweise Bausteine zu konkreten Betriebssystemen, Smartpho­
nes und Tablets und Drucker, Kopierer und Multifunktionsgeräte.
1368 Erstellung einer Sicherheitskonzeption nach Standard-Absicherung
• Die Schicht NET betrachtet die Vernetzungsaspekte, die sich nicht auf bestimmte IT-Systeme, son­
dern auf die Netzverbindungen und die Kommunikation beziehen. Dazu gehören z. B. die Baustei­
ne Netzmanagement, Firewall und WLAN-Betrieb.
• Die Schicht INF befasst sich mit den baulich-technischen Gegebenheiten, hier werden Aspekte der
infrastrukturellen Sicherheit zusammengeführt. Dies betrifft unter anderem die Bausteine Gebäu­
de und Rechenzentrum.
• Die Schicht IND befasst sich mit Sicherheitsaspekten industrieller IT. In diese Schicht fallen beispiels­
weise die Bausteine Maschine, Sensoren und Speicherprogrammierbare Steuerung (SPS).
Die Einteilung in diese Schichten hat folgende Vorteile:
• Da übergeordnete Aspekte und gemeinsame infrastrukturelle Fragestellungen getrennt von den
IT-Systemen betrachtet werden, kommt es zu einer Vermeidung von Redundanzen, weil diese
Aspekte nur einmal bearbeitet werden müssen und nicht wiederholt für jedes IT-System.
• Die einzelnen Schichten sind so gewählt, dass auch die Zuständigkeiten für die betrachteten
Aspekte gebündelt sind. So betreffen beispielsweise die Schichten ISMS und ORP Grundsatzfragen
des sicheren Umgangs mit Informationen, die Schicht INF den Bereich Haustechnik, die Schicht SYS
die Zuständigen für die IT-Systeme, die Schicht NET die Ebene der Netzadministratoren und die
Schicht APP schließlich die Anwendungsverantwortlichen und -betreiber.
• Aufgrund der Aufteilung der Sicherheitsaspekte in Schichten können Einzelaspekte in resultieren­
den Sicherheitskonzepten leichter aktualisiert und erweitert werden, ohne dass andere Schichten
umfangreich tangiert werden.
Die Modellierung nach dem IT-Grundschutz besteht nun darin, für die Bausteine einer jeden Schicht zu
entscheiden, ob und wie sie zur Abbildung des Informationsverbunds herangezogen werden können.
Je nach betrachtetem Baustein können die Zielobjekte dieser Abbildung von unterschiedlicher Art
sein: einzelne Geschäftsprozesse oder Komponenten, Gruppen von Komponenten, Gebäude, Liegen­
schaften, Organisationseinheiten usw.
8.3.3 Reihenfolge der Baustein-Umsetzung
Um grundlegende Risiken abzudecken und eine ganzheitliche Informationssicherheit aufzubauen,
müssen die essenziellen Sicherheitsanforderungen frühzeitig erfüllt und entsprechende Sicherheits­
maßnahmen umgesetzt werden. Daher wird im IT-Grundschutz eine Reihenfolge für die umzusetzen­
den Bausteine vorgeschlagen.
Im IT-Grundschutz-Kompendium ist im Kapitel Schichtenmodell und Modellierung beschrieben, wann
ein einzelner Baustein sinnvollerweise eingesetzt werden soll und auf welche Zielobjekte er anzuwen­
den ist. Außerdem sind die Bausteine danach gekennzeichnet, ob sie vor- oder nachrangig umgesetzt
werden sollten.
• R1: Diese Bausteine sollten vorrangig umgesetzt werden, da sie die Grundlage für einen effektiven
Sicherheitsprozess bilden.
• R2: Diese Bausteine sollten als Nächstes umgesetzt werden, da sie in wesentlichen Teilen des In­
formationsverbunds für nachhaltige Sicherheit erforderlich sind.
137
• Die Komplexität der Informationssicherheit wird reduziert, indem eine sinnvolle Aufteilung der
Einzelaspekte vorgenommen wird.8.3 Modellierung eines Informationsverbunds
• R3: Diese Bausteine werden zur Erreichung des angestrebten Sicherheitsniveaus ebenfalls benötigt
und müssen umgesetzt werden, es wird aber empfohlen, diese erst nach den anderen Bausteinen
zu betrachten
Mit R1 sind die Bausteine gekennzeichnet, die notwendig sind, um ein grundlegendes Sicherheitsge­
rüst zu erreichen. Es handelt sich um die Bausteine der Bereiche
• ISMS Managementsysteme für Informationssicherheit,
• ORP Organisation und Personal,
• OPS.1.1 Kern-IT-Betrieb.
Die im zweiten und dritten Schritt umzusetzenden Bausteine (R2 und R3) finden sich in allen anderen
Schichten des IT-Grundschutz-Kompendiums.
Diese Kennzeichnung zeigt nur die sinnvolle zeitliche Reihenfolge für die Umsetzung der Anforderun­
gen des jeweiligen Bausteins auf und stellt keine Gewichtung der Bausteine untereinander dar.
Grundsätzlich müssen alle für den jeweiligen Informationsverbund relevanten Bausteine des IT-Grund­
schutz-Kompendiums umgesetzt werden.
Die Kennzeichnung der Bausteine stellt außerdem nur eine Empfehlung dar, in welcher Reihenfolge
die verschiedenen Bausteine sinnvoll umgesetzt werden könnten. Jede Institution kann hier eine da­
von abweichende, für sich sinnvolle Reihenfolge festlegen.
8.3.4 Zuordnung von Bausteinen
Die IT-Grundschutz-Modellierung, also die Zuordnung von Bausteinen zu Zielobjekten, sollte in Form
einer Tabelle mit folgenden Spalten dokumentiert werden:
• Nummer und Titel des Bausteins
• Relevanz: Diese Spalte dient der Entscheidung, ob ein Baustein für den zu modellierenden Infor­
mationsverbund relevant ist oder nicht. Sie liefert einen schnellen Überblick darüber, ob kein Bau­
stein vergessen wurde.
• Zielobjekt: Wenn ein Baustein für den Informationsverbund relevant ist, erfolgt über diese Spalte
die Zuordnung zum Zielobjekt bzw. einer Zielobjektgruppe.
• Begründung: In dieser Spalte können Randinformationen und Begründungen für die Modellierung
dokumentiert werden. Sind Bausteine für den betrachteten Informationsverbund nicht relevant,
sollte dies hier explizit begründet werden.
• Ansprechpartner: Der konkrete Ansprechpartner wird nicht im Rahmen der Modellierung, sondern
erst bei der Planung des eigentlichen Soll-Ist-Vergleichs im IT-Grundschutz-Check ermittelt. Basie­
rend auf den Rollen und Verantwortlichen, die in den Bausteinen genannten werden, kann hier
jedoch schon eine entsprechende Vorarbeit geleistet werden.
1388 Erstellung einer Sicherheitskonzeption nach Standard-Absicherung
Beispiel: RECPLAST GmbH
Die folgende Tabelle ist ein Auszug aus der Modellierung für das Unternehmen RECPLAST GmbH:
A.3 Modellierung der RECPLAST GmbH
Rele­
vanz
Zielobjekt
APP.5.2 Microsoft Exchange / Outlook nein
APP 3.6 DNS-Server
Ansprech­
partner
Wird nicht eingesetzt.
ja S019
Benutzerdef.BS.1 PC für die Industrie­
steuerung
ja C005
Auslandsreisen sind für
Informationsverbund
nicht relevant.
CON.7: Informationssicherheit auf
Auslandsreisen nein INF.1 Allgemeines Gebäude ja INF.7 Datenträgerarchiv nein INF.4 IT-Verkabelung ja Informations­
verbund
ISMS.1 (Sicherheitsmanagement) ja Informations­
verbund
NET.1.1 Netz-Architektur und -design ja Informations­
verbund
NET.3.1 Router und Switches S033
ja
Begründung
Nummer und Titel des Bausteins
G001
Es gibt kein Datenträ­
gerarchiv.
Die IT-Administration
findet außerhalb des
Informationsverbun­
des statt.
OPS.1.1.2 Ordnungsgemäße IT-Admi­
nistration
nein
OPS.2.4 Fernwartung ja Informations­
verbund
SYS.1.3 Server unter Unix ja S020
SYS.4.1 Drucker, Kopierer und Multi­
funktionsgeräte
ja S048
Abbildung 29: Auszug aus der Modellierung der RECPLAST GmbH
Eine detaillierte Beschreibung der Vorgehensweise zur Modellierung eines Informationsverbunds fin­
det sich im IT-Grundschutz-Kompendium im Kapitel Schichtenmodell und Modellierung.
8.3.5 Modellierung bei Virtualisierung und Cloud-Systemen
Grundsätzlich erfolgt die Modellierung virtueller IT-Systeme nach den gleichen Regeln wie bei eigen­
ständigen physischen IT-Systemen, d. h. es sind die Hinweise in Kapitel 2 des IT-Grundschutz-Kom­
pendiums zu beachten. Die Zuordnung der IT-Grundschutz-Bausteine richtet sich bei IT-Komponenten
in erster Linie nach der Funktion des IT-Systems (Server, Client, usw.), nach dem verwendeten Betriebs­
system (Linux, Windows usw.) und nach den darauf betriebenen Applikationen (Datenbank, Webser­
ver usw.).
1398.3 Modellierung eines Informationsverbunds
Bei Virtualisierungssoftware gibt es Produkte, die ein unterliegendes Betriebssystem benötigen (host­
basierte Virtualisierungslösungen), und andere, die direkt auf der physischen Hardware laufen (Bare
Metal Virtualisierung), ohne unterliegendes Betriebssystem. Falls unterhalb der Virtualisierungs­
schicht ein vollwertiges und eigenständiges Betriebssystem eingesetzt wird, muss der dazu passende
Baustein ebenfalls zugeordnet werden (z. B. aus SYS.1.2 Windows-Server), unabhängig von den vir­
tuellen IT-Systemen.
Wurde der Hypervisor direkt auf der physischen Hardware installiert (Bare Metal Virtualisierung) han­
delt es sich hierbei um ein Zielobjekt, das im IT-Grundschutz-Kompendium nicht enthalten ist, da es
sich hierbei um ein sehr spezielles Zielobjekt handelt. Daher muss eine Risikoanalyse für das entspre­
chende Zielobjekt durchgeführt und die Ergebnisse sollten anschließend mit den Anforderungen des
Bausteins SYS.1.5 Virtualisierung konsolidiert werden.
Beispielszenario:
Als Beispiel wird ein physischer Server S1 betrachtet, auf dem mithilfe einer Virtualisierungssoft­
ware die drei virtuellen Server VM1, VM2 und VM3 betrieben werden. Als Basis-Betriebssystem
kommt auf dem physischen Server S1 eine Linux-Version zum Einsatz. Die Virtualisierungsschicht
ist in diesem Beispiel eine Software-Komponente, die unter Linux läuft, also eine hostbasierte
Servervirtualisierung (Typ 2). Die beiden virtuellen Server VM1 und VM2 werden mit Windows
2012 betrieben, auf VM3 ist hingegen Linux installiert. Applikationen können sowohl auf den drei
virtuellen Servern als auch (unter Umgehung der Virtualisierungsschicht) direkt auf dem Basis-Be­
triebssystem des physischen Servers S1 ablaufen. Die folgende Abbildung zeigt ein Schema dieser
Beispielkonfiguration:
Abbildung 30: Schema einer Beispielkonfiguration
1408 Erstellung einer Sicherheitskonzeption nach Standard-Absicherung
Baustein Zielobjekt
SYS.1.1 Allgemeiner Server S1
SYS.1.1 Allgemeiner Server VM3
SYS.1.1 Allgemeiner Server Gruppe aus VM1 und VM2
SYS.1.3 Server unter Unix S1
SYS.1.3 Server unter Unix VM3
SYS.1.2.2 Windows Server 2012 Gruppe aus VM1 und VM2
Tabelle 6: Zuordnung Bausteine aus Virtualisierungsschicht zu Zielobjekten
Um eine angemessene Gesamtsicherheit für den IT-Betrieb von Cloud-Diensten zu erreichen, müssen
alle Cloud-Dienste (mit ihren zugeordneten virtuellen IT-Systemen, Netzen und weiteren Cloud-Kom­
ponenten) systematisch in der Sicherheitskonzeption berücksichtigt werden. Alle über Cloud-Dienste
bereitgestellten IT-Systeme, Netze und Anwendungen, die sich einerseits in der Betriebsverantwor­
tung und andererseits im Geltungsbereich des ISMS des Cloud-Diensteanbieters befinden, müssen in
der Modellierung gemäß der IT-Grundschutz-Vorgehensweise berücksichtigt werden. Hierbei kann
der Geltungsbereich des Informationsverbunds gleichzeitig als Grenze der Verantwortlichkeit verstan­
den werden: An der Grenze des Informationsverbunds endet die Verantwortung des Cloud-Dienste­
anbieters und beginnt die Verantwortung des Cloud-Anwenders. Der Umfang des Informationsver­
bunds unterscheidet sich dabei je nach dem Servicemodell.
Modellierung von IaaS-Angeboten
Bei IaaS (Infrastructure as a Service) ist der Cloud-Diensteanbieter für den Verwaltungsserver für die
Cloud und den Virtualisierungsserver verantwortlich. Deshalb kommen bei IaaS aus den Schichten
APP (Anwendungen) und SYS (IT-Systeme) nur die Verwaltungs- und die Virtualisierungssoftware als
Zielobjekte vor. Für diese müssen somit die zugehörigen Bausteine ausgewählt werden. Nach der
IT-Grundschutz-Vorgehensweise sind dies die Bausteine für IT-Systeme als Server (Schicht SYS.1).
Für den Cloud-Verwaltungsserver müssen die Bausteine SYS 1.5 Virtualisierung und OPS.3.2
Cloud-Anbieter umgesetzt werden.
Für IaaS stellt der Cloud-Diensteanbieter nicht mehr als eine virtuelle „Hülle“ über ein virtuelles Netz
bereit. Die Absicherung des Netzes nach IT-Grundschutz verantwortet bei IaaS der Cloud-Dienstean­
bieter, wohingegen die Cloud-Anwender die IT-Systeme des Cloud-Angebotes verantworten. Für das
Netz sind die passenden Bausteine aus der Schicht Netze und Kommunikation zu modellieren (z. B.
NET.1.1 Netzarchitektur und -design). In der Regel wird dem virtuellen Server ein Speicherkontingent
aus einem Speichernetz zugeordnet, hierfür ist der Baustein SYS.1.8 Speicherlösungen/Cloud Storage
ebenfalls vom Cloud-Diensteanbieter umzusetzen.
Ein virtueller Server aus der Cloud, der per IaaS angeboten wird, wird durch den Cloud-Anwender
konfiguriert. Die Umsetzungsverantwortung für seine Sicherheitsmaßnahmen liegt somit ebenfalls
beim Cloud-Anwender. Im Hinblick auf die Abgrenzung des Informationsverbunds des Cloud-Diens­
teanbieters befindet sich also dieser virtuelle Server außerhalb des Informationsverbunds des
Cloud-Diensteanbieters.
141
Modellierung beim Cloud-Computing8.3 Modellierung eines Informationsverbunds
Die Schnittstelle zur Bereitstellung von IaaS-Cloud-Diensten (Self-Service-Portal) ist durch geeignete
Mechanismen zur Netztrennung (z. B. über Netze, virtuelle Firewalls, Routing) vom Cloud-Dienstean­
bieter abzusichern und gegebenenfalls der Baustein APP.3.1 Webanwendungen umzusetzen.
Eine Modellierung der IaaS-Server als IT-Systeme im Sicherheitskonzept des Cloud-Diensteanbieters ist
möglich, allerdings nicht notwendig, da die Cloud-Anwender diese IT-Systeme verwalten.
Modellierung von PaaS-Angeboten
Bei PaaS (Platform as a Service) ist der Cloud-Diensteanbieter zusätzlich zu IaaS für die sichere Bereit­
stellung eines virtuellen Servers und einer angebotenen Plattform verantwortlich (z. B. einer Daten­
bank oder eines Webservers). Dementsprechend muss der Cloud-Diensteanbieter im Servicemodell
PaaS zunächst, wie bei IaaS, den Cloud-Verwaltungsserver und dessen Verwaltungssoftware model­
lieren. Dort erfolgt zentral die Zuordnung des Bausteins OPS.3.2 Cloud-Anbieter.
Darüber hinaus muss der Cloud-Diensteanbieter ein IT-System mit dem entsprechenden Betriebssys­
tem modellieren. Zu diesem IT-System ist je nach Cloud-Dienst auf Anwendungsschicht eine Daten­
bank oder ein Webserver zu modellieren.
Das PaaS-IT-System mit den verbundenen Cloud-Anwendungen muss für jeden Cloud-Mandanten
modelliert werden, wobei Mandanten mit gleichen Plattformen, gleichen Anwendungen und glei­
chem Schutzbedarf gemäß den Vorgaben in Kapitel 8.1.1 Komplexitätsreduktion durch Gruppenbil­
dung in einer Gruppe zusammengefasst werden können.
In der Praxis werden Cloud-Dienste des Servicemodells PaaS über virtuelle Profile bereitgestellt, die für
mehrere Cloud-Anwender bzw. Mandanten eingesetzt werden können. Es bietet sich daher in der
IT-Grundschutz-Modellierung an, diese Kombinationen in Form von Musterservern zu modellieren
und pro Mandant zu verknüpfen bzw. zu vervielfachen.
Modellierung von SaaS-Angeboten
Bei SaaS (Software as a Service) müssen zunächst die für die unterliegende Cloud-Infrastruktur rele­
vanten Zielobjekte wie bei IaaS und PaaS identifiziert und entsprechenden Bausteinen zugeordnet
werden.
Im Vergleich zu PaaS werden bei SaaS weitere Anwendungen auf den Cloud-IT-Systemen modelliert
(z. B. ein Webservice, eine Webanwendung oder ein SAP-System). Bei SaaS ist der Cloud-Dienstean­
bieter praktisch für den gesamten Cloud-Computing-Stack (Server, Netze, Storage, Management und
Anwendungen) verantwortlich. Die SaaS-Anwendungen liegen auch in seinem Verantwortungsbe­
reich und müssen somit in seinem Informationsverbund modelliert werden. Dabei können sowohl
mehrfache Ausprägungen derselben SaaS-Anwendung als auch Gruppen von SaaS-Anwendungen
gemäß den Vorgaben in Kapitel 8.1.1 zusammengefasst werden, wenn die dort angegebenen Vor­
aussetzungen erfüllt sind.
8.3.6 Anpassung der Baustein-Anforderungen
Über die Modellierung wurden die Bausteine des IT-Grundschutz-Kompendiums ausgewählt, die für
die einzelnen Zielobjekte des betrachteten Informationsverbunds umzusetzen sind. In den Bausteinen
werden die Sicherheitsanforderungen aufgeführt, die typischerweise für diese Komponenten geeig­
net und angemessen sind.
Für die Erstellung eines Sicherheitskonzepts oder für ein Audit müssen jetzt die einzelnen Anforde­
rungen bearbeitet und darauf aufbauend geeignete Sicherheitsmaßnahmen formuliert werden.
1428 Erstellung einer Sicherheitskonzeption nach Standard-Absicherung
Die Anforderungen sind knapp und präzise. Sie geben die Teilziele vor, die zusammen zur Umsetzung
der Ziele eines Bausteins beitragen. Die Sicherheitsanforderungen müssen daher noch in Handlungs­
vorgaben für die verschiedenen Akteure im Sicherheitsprozess umgewandelt werden. Dafür müssen
auf Basis der Anforderungen Sicherheitsmaßnahmen ausgearbeitet werden, die
• an die jeweiligen Rahmenbedingungen und den Sprachgebrauch einer Institution angepasst sein
müssen,
• ausreichend konkret sind, um im vorliegenden Informationsverbund angewendet zu werden, also
z. B. ausreichend technische Details enthalten.
Zu vielen Bausteinen des IT-Grundschutz-Kompendiums gibt es Umsetzungshinweise, in denen zu
den Sicherheitsanforderungen detailliertere Maßnahmen beschrieben sind. Diese Maßnahmen sind
einerseits so allgemein formuliert, dass sie in möglichst vielen Umgebungen anwendbar sind, und
andererseits so ausführlich, dass die Maßnahmenbeschreibungen als Umsetzungshilfe dienen kön­
nen.
Auch die in den Umsetzungshinweisen vorgeschlagenen Maßnahmen sollten noch an die jeweiligen
Rahmenbedingungen einer Institution angepasst werden. Es kann beispielsweise sinnvoll sein,
• Maßnahmen weiter zu konkretisieren, also z. B. um technische Details zu ergänzen,
• Maßnahmen dem Sprachgebrauch der Institution anzupassen, also z. B. andere Rollenbezeichnun­
gen zu verwenden, und
• aus Maßnahmen die im betrachteten Bereich nicht relevanten Empfehlungen zu streichen.
Um den Anwendern die zielgruppengerechte Anpassung der IT-Grundschutz-Texte zu erleichtern,
werden sämtliche Texte, Bausteine, Umsetzungshinweise, Tabellen und Hilfsmittel auch in elektroni­
scher Form zur Verfügung gestellt. Damit können diese Texte bei der Erstellung eines Sicherheitskon­
zepts und bei der Realisierung von Sicherheitsmaßnahmen weiterverwendet werden.
Bei der Sichtung der Sicherheitsanforderungen kann sich ergeben, dass einzelne Anforderungen un­
ter den konkreten Rahmenbedingungen nicht umgesetzt werden können. Dies kann beispielsweise
der Fall sein, wenn die Anforderungen in der betrachteten Umgebung nicht relevant sind (z. B. weil
Dienste nicht aktiviert wurden). In seltenen Fällen kann dies auch im Bereich der uneingeschränkt
notwendigen Basis-Anforderungen vorkommen, wenn deren Umsetzung essenzielle Schwierigkeiten
in anderen Bereichen mit sich bringen würde. Dies könnte beispielsweise der Fall sein, wenn sich
Anforderungen des Brand- und des Einbruchschutzes nicht miteinander vereinbaren lassen würden.
Dann müssten andere Lösungen gefunden und dies nachvollziehbar dokumentiert werden.
Werden Sicherheitsanforderungen zusätzlich aufgenommen oder geändert, muss dies im Sicherheits­
konzept dokumentiert werden. Dies erleichtert auch die Durchführung des IT-Grundschutz-Checks.
Bei der Auswahl und Anpassung der Sicherheitsmaßnahmen auf Basis der Anforderungen ist zu be­
achten, dass diese immer angemessen sein müssen. Angemessen bedeutet:
• Wirksamkeit (Effektivität): Sie müssen vor den möglichen Gefährdungen wirksam schützen, also
den identifizierten Schutzbedarf abdecken.
143
Generell sollten die Anforderungen der IT-Grundschutz-Bausteine immer sinngemäß umgesetzt wer­
den. Alle Änderungen gegenüber dem IT-Grundschutz-Kompendium sollten dokumentiert werden,
damit die Gründe auch später noch nachvollziehbar sind.8.3 Modellierung eines Informationsverbunds
• Eignung: Sie müssen in der Praxis tatsächlich umsetzbar sein, dürfen also z. B. nicht die Organisa­
tionsabläufe zu stark behindern oder andere Sicherheitsmaßnahmen aushebeln.
• Praktikabilität: Sie sollen leicht verständlich, einfach anzuwenden und wenig fehleranfällig sein.
• Akzeptanz: Sie müssen für alle Benutzer anwendbar (barrierefrei) sein und dürfen niemanden dis­
kriminieren oder beeinträchtigen.
• Wirtschaftlichkeit: Mit den eingesetzten Mitteln sollte ein möglichst gutes Ergebnis erreicht wer­
den. Die Sicherheitsmaßnahmen sollten also einerseits das Risiko bestmöglich minimieren und an­
dererseits in geeignetem Verhältnis zu den zu schützenden Werten stehen.
8.3.7 Einbindung externer Dienstleister
Viele Institutionen setzen externe oder interne Dienstleister ein, um Geschäftsprozesse ganz oder
teilweise durch diese durchführen zu lassen. Grundsätzlich kann die Einbindung externer Dienstleister
auf viele Arten erfolgen, z. B. in Form von Personal, das temporär eingesetzt wird, oder in Form von
Auslagerungen von IT-Systemen.
Bereits im Vorfeld der Einbindung externer Dienstleister müssen die Aufgaben im Bereich der Infor­
mationssicherheit abgegrenzt und die Schnittstellen genau festgelegt werden. Aufgaben können an
externe Dienstleister ausgelagert werden, die Verantwortung für die Informationssicherheit verbleibt
jedoch immer bei der auslagernden Institution.
Es muss geklärt sein, welche sicherheitsrelevanten Aufgaben durch den externen Dienstleister und
welche durch das eigene Sicherheitsmanagement abgedeckt werden. Folgende Fragen sollten vor der
Einbindung externer Dienstleister grundlegend geregelt werden:
• Welche Geschäftsprozesse, welche IT-Systeme oder welche Dienstleistungen sollen an einen exter­
nen Dienstleister ausgelagert werden?
• Welchen Schutzbedarf haben die Zielobjekte, die durch einen externen Dienstleister oder im Out­
sourcing verarbeitet werden?
• Auf welche Zielobjekte und welche Informationen hat der externe Dienstleister Zugriff? Hier muss
einerseits berücksichtigt werden, welche Zielobjekte und Informationen im Fokus der Dienstleis­
tungserbringung stehen, aber andererseits auch, auf welche Zielobjekte und Informationen die
Dienstleister zugreifen könnten, wie z. B. Reinigungskräfte auf Informationen in Büroräumen.
Sofern sich eine Institution für die Einbindung externer Dienstleister entscheidet, müssen neben
vertraglichen Rahmenbedingungen ebenfalls die Voraussetzungen für die Umsetzung der Anforde­
rungen des IT-Grundschutzes erfüllt werden. Generell muss die Modellierung der Bausteine ge­
trennt für die eigene Institution und für jeden externen Dienstleister durchgeführt werden. Die Vor­
gehensweise der Modellierung erfolgt wie in Kapitel 8.3.4 „Zuordnung von Bausteinen“ beschrie­
ben.
Auch bei der Einbindung externer Dienstleister muss es zu jedem Zeitpunkt für die auslagernde Insti­
tution möglich sein, die Risiken im Bereich der Informationssicherheit zu identifizieren und zu kontrol­
lieren. Informationen und Geschäftsprozesse müssen immer auf einem vergleichbaren Niveau gemäß
den Sicherheitszielen der Institution geschützt werden, auch wenn externe Dienstleister (oder wie­
derum deren Dienstleister) diese ganz oder in Teilen verarbeiten. Des Weiteren ist eine hohe Ereignis­
transparenz erforderlich, d. h., es muss Mechanismen geben, die gewährleisten, dass Gefährdungen
und Risiken, die Auswirkungen auf die Dienstleistungen haben könnten, erkannt und entsprechend
kommuniziert werden.
1448 Erstellung einer Sicherheitskonzeption nach Standard-Absicherung
Hierfür ist es erforderlich, Sicherheitsanforderungen sowie die regelmäßige Überwachung ihrer Ein­
haltung in den Verträgen aufzunehmen.
Bei der Einbindung externer Dienstleister ist es möglich, dass der Dienstleister bereits für die einge­
bundene Dienstleistung ein Zertifikat vorweisen kann. Hierbei muss immer berücksichtigt werden, ob
der Geltungsbereich des ausgestellten Zertifikates die Dienstleistung auch tatsächlich umfasst.
Aktionspunkte zu 8.3 Modellierung eines Informationsverbunds
• Kapitel Schichtenmodell und Modellierung aus dem IT-Grundschutz-Kompendium systematisch
durcharbeiten
• Zuordnung von Bausteinen zu Zielobjekten („IT-Grundschutz-Modell“) sowie die entsprechenden
Ansprechpartner dokumentieren
• Zielobjekte, die nicht geeignet modelliert werden können, für eine Risikoanalyse vormerken
• Festlegung einer Reihenfolge für die Umsetzung der Bausteine
• Sicherheitsanforderungen aus den identifizierten Bausteinen sorgfältig lesen und darauf aufbau­
end passende Sicherheitsmaßnahmen festlegen
8.4
IT-Grundschutz-Check
Für die nachfolgenden Betrachtungen wird vorausgesetzt, dass für einen ausgewählten Informations­
verbund folgende Teile des Sicherheitskonzepts nach IT-Grundschutz erstellt wurden:
Anhand der Strukturanalyse des Informationsverbunds wurde eine Übersicht über die vorhandenen
Geschäftsprozesse, die IT und deren Vernetzung, die unterstützten Anwendungen und die Räum­
lichkeiten erstellt. Darauf aufbauend wurde anschließend die Schutzbedarfsfeststellung durchge­
führt, deren Ergebnis eine Übersicht über den Schutzbedarf der Geschäftsprozesse, Anwendungen,
IT-Systeme, der genutzten Räume und der Kommunikationsverbindungen ist. Mithilfe dieser Infor­
mationen wurde die Modellierung des Informationsverbunds nach IT-Grundschutz durchgeführt.
Das Ergebnis war eine Abbildung des betrachteten Informationsverbunds auf Bausteine des
IT-Grundschutzes.
Die Modellierung nach IT-Grundschutz wird nun als Prüfplan benutzt, um anhand eines Soll-Ist-Ver­
gleichs herauszufinden, welche Anforderungen ausreichend oder nur unzureichend erfüllt wurden.
Dieses Kapitel beschreibt, wie bei der Durchführung des IT-Grundschutz-Checks vorgegangen wer­
den sollte. Der IT-Grundschutz-Check besteht aus drei unterschiedlichen Schritten. Im ersten Schritt
werden die organisatorischen Vorbereitungen getroffen, insbesondere die relevanten Ansprech­
partner für den Soll-Ist-Vergleich ausgewählt. Im zweiten Schritt wird der eigentliche Soll-Ist-Ver­
gleich mittels Interviews und stichprobenartiger Kontrolle durchgeführt. Im letzten Schritt werden
die erzielten Ergebnisse des Soll-Ist-Vergleichs einschließlich der erhobenen Begründungen doku­
mentiert.
Nachfolgend werden die Schritte des IT-Grundschutz-Checks detailliert beschrieben.
145
• Für jeden Baustein des IT-Grundschutz-Kompendiums ermitteln, auf welche Zielobjekte er im
betrachteten Informationsverbund anzuwenden ist8.4 IT-Grundschutz-Check
8.4.1 Organisatorische Vorarbeiten für den IT-Grundschutz-Check
Für die reibungslose Durchführung des Soll-Ist-Vergleichs sind einige Vorarbeiten erforderlich. Zu­
nächst sollten alle hausinternen Papiere, z. B. Organisationsverfügungen, Arbeitshinweise, Sicher­
heitsanweisungen, Handbücher und „informelle“ Vorgehensweisen, die die sicherheitsrelevanten
Abläufe regeln, gesichtet werden. Auch die Dokumentation der bereits umgesetzten Sicherheitsmaß­
nahmen gehört dazu. Diese Dokumente können bei der Ermittlung des Umsetzungsgrades hilfreich
sein, insbesondere bei Fragen nach bestehenden organisatorischen Regelungen. Weiterhin ist zu klä­
ren, wer gegenwärtig für deren Inhalt zuständig ist, um später die richtigen Ansprechpartner bestim­
men zu können.
Als Nächstes sollte festgestellt werden, ob und in welchem Umfang externe Stellen bei der Ermittlung
des Umsetzungsstatus beteiligt werden müssen. Dies kann beispielsweise bei externen Rechenzen­
tren, vorgesetzten Behörden, Firmen, die Teile von Geschäftsprozessen oder des IT-Betriebes als Out­
sourcing-Dienstleistung übernehmen, oder Baubehörden, die für infrastrukturelle Maßnahmen zu­
ständig sind, erforderlich sein.
Ein wichtiger Schritt vor der Durchführung des eigentlichen Soll-Ist-Vergleichs ist die Ermittlung ge­
eigneter Interviewpartner. Hierzu sollte zunächst für jeden einzelnen Baustein, der für die Modellie­
rung des vorliegenden Informationsverbunds herangezogen wurde, ein Hauptansprechpartner fest­
gelegt werden. Bei den Anforderungen in den Bausteinen werden die Rollen genannt, die für die
Umsetzung der Anforderungen erforderlich sind. Hieraus können die geeigneten Ansprechpartner
für die jeweilige Thematik in der Institution identifiziert werden. Nachfolgend finden sich einige Bei­
spiele für Ansprechpartner der verschiedenen Bereiche:
• Bei den Bausteinen der Schicht ORP, CON und OPS ergibt sich ein geeigneter Ansprechpartner in
der Regel direkt aus der im Baustein behandelten Thematik. Beispielsweise sollte für den Baustein
ORP.2 Personal ein Mitarbeiter der zuständigen Personalabteilung als Ansprechpartner ausgewählt
werden. Bei den konzeptionellen Bausteinen, z. B. Baustein CON.1 Kryptokonzept, steht im Ideal­
fall der Mitarbeiter zur Verfügung, der für die Fortschreibung des entsprechenden Dokuments zu­
ständig ist. Anderenfalls sollte derjenige Mitarbeiter befragt werden, zu dessen Aufgabengebiet
die Fortschreibung von Regelungen in dem betrachteten Bereich gehört.
• Im Bereich der Schicht INF (Infrastruktur) sollte die Auswahl geeigneter Ansprechpartner in Abstim­
mung mit der Abteilung Innerer Dienst/Haustechnik vorgenommen werden. Je nach Größe der
betrachteten Institution können beispielsweise unterschiedliche Ansprechpartner für die Infra­
strukturbereiche Gebäude und Technikräume zuständig sein. In kleinen Institutionen kann in vielen
Fällen der Hausmeister Auskunft geben. Zu beachten ist im Bereich der Infrastruktur, dass hier
unter Umständen externe Stellen zu beteiligen sind. Dies betrifft insbesondere größere Institutio­
nen.
• In den systemorientierten Bausteinen der Schichten SYS, NET und IND werden in den zu prüfenden
Sicherheitsmaßnahmen verstärkt technische Aspekte behandelt. In der Regel kommt daher der
Administrator derjenigen Komponente bzw. Gruppe von Komponenten, der der jeweilige Baustein
bei der Modellierung zugeordnet wurde, als Hauptansprechpartner infrage.
• Für die Bausteine der Schicht APP (Anwendungen) sollten die Betreuer bzw. die Verantwortlichen
der einzelnen Anwendungen als Hauptansprechpartner ausgewählt werden.
Für die anstehenden Interviews mit den Systemverantwortlichen, Administratoren und sonstigen An­
sprechpartnern sollte ein Terminplan erstellt werden. Ein besonderes Augenmerk gilt hier der Termin­
1468 Erstellung einer Sicherheitskonzeption nach Standard-Absicherung
koordination mit Personen aus anderen Organisationseinheiten oder anderen Institutionen. Zudem
erscheint es sinnvoll, bereits im Vorhinein Ausweichtermine abzustimmen.
Je nach Größe der Projektgruppe sollten für die Durchführung der Interviews Teams mit verteilten
Aufgaben gebildet werden. Es hat sich bewährt, in jeder Gruppe zwei Personen für die Durchführung
des Interviews einzuplanen. Dabei stellt eine Person die notwendigen Fragen und die andere Person
notiert die Ergebnisse und Anmerkungen, die durch den Interviewpartner gegeben werden.
147148
entbehrlich
die
Leitlinie
unterzeichnet.
gesamte
Informationssicherheit
delegiert
geforderten
erhält
ment-Report,
tus
8.4 IT-Grundschutz-CheckProzesse
Audit
entsprechende
die
antwortungsbereich
fallen.
8 Erstellung einer Sicherheitskonzeption nach Standard-Absicherung
1498.4 IT-Grundschutz-Check
Aktionspunkte zu 8.4.1 Organisatorische Vorarbeiten des IT-Grundschutz-Checks
• Hausinterne Dokumente mit Verfügungen und Regelungen sichten und Zuständigkeiten für diese
Unterlagen klären
• Feststellen, in welchem Umfang externe Stellen beteiligt werden müssen
• Hauptansprechpartner für jeden in der Modellierung angewandten Baustein festlegen
• Terminplan für Interviews abstimmen
• Team für Interviews zusammenstellen
8.4.2 Durchführung des Soll-Ist-Vergleichs
Sind alle erforderlichen Vorarbeiten erledigt, kann die eigentliche Erhebung an den zuvor festgesetz­
ten Terminen beginnen. Hierzu werden die Sicherheitsanforderungen des jeweiligen Bausteins, für
den die Interviewpartner zuständig sind, der Reihe nach durchgearbeitet.
Als Antworten bezüglich des Umsetzungsstatus der einzelnen Anforderungen kommen folgende
Aussagen in Betracht:
„entbehrlich“ Die Erfüllung der Anforderung ist in der vorgeschlagenen Art nicht notwendig, weil
die Anforderung im betrachteten Informationsverbund nicht relevant ist (z. B. weil
Dienste nicht aktiviert wurden) oder durch Alternativmaßnahmen behandelt wurde.
Wird der Umsetzungsstatus einer Anforderung auf „entbehrlich“ gesetzt, müssen
über die Kreuzreferenztabelle des jeweiligen Bausteins die zugehörigen elementa­
ren Gefährdungen identifiziert werden. Wurden Alternativmaßnahmen ergriffen,
muss begründet werden, dass das Risiko, das von allen betreffenden elementaren
Gefährdungen ausgeht, angemessen minimiert wurde. Generell ist zu beachten,
dass bei Basis-Anforderungen das entstehende Risiko nicht übernommen werden
kann.
Anforderungen dürfen nicht auf „entbehrlich“ gesetzt werden, wenn das Risiko für
eine im Baustein identifizierte elementare Gefährdung über die Kreuzreferenztabel­
le pauschal akzeptiert oder ausgeschlossen wird.
„ja“ Zu der Anforderung wurden geeignete Maßnahmen vollständig, wirksam und ange­
messen umgesetzt.
„teilweise“ Die Anforderung wurde nur teilweise umgesetzt.
„nein“ Die Anforderung wurde noch nicht erfüllt, also geeignete Maßnahmen sind größten­
teils noch nicht umgesetzt.
Es ist sinnvoll, bei den Interviews nicht nur die Bausteintexte, sondern auch die Umsetzungshinweise
oder andere ergänzende Materialien griffbereit zu haben. Den Befragten sollte der Zweck des
IT-Grundschutz-Checks kurz vorgestellt werden. Es bietet sich an, mit den Anforderungsüberschriften
fortzufahren und die Anforderungen kurz zu erläutern. Dem Gesprächspartner sollte die Möglichkeit
gegeben werden, auf die bereits umgesetzten Anforderungen und Maßnahmen einzugehen und
danach noch offene Punkte zu besprechen.
Die Befragungstiefe richtet sich zunächst nach dem Niveau von Basis- und Standard-Anforderungen;
über diese hinausweisende Aspekte hochschutzbedürftiger Anwendungen sollten erst nach Ab­
schluss des IT-Grundschutz-Checks betrachtet werden. Falls der Bedarf besteht, die in den Interviews
gemachten Aussagen zu verifizieren, bietet es sich an, stichprobenartig die entsprechenden Regelun­
1508 Erstellung einer Sicherheitskonzeption nach Standard-Absicherung
gen und Konzepte zu sichten, im Bereich Infrastruktur gemeinsam mit dem Ansprechpartner die zu
untersuchenden Objekte vor Ort zu besichtigen sowie Client- bzw. Servereinstellungen an ausgewähl­
ten IT-Systemen zu überprüfen.
Zum Abschluss jedes Bausteins sollte den Befragten das Ergebnis (Umsetzungsstatus der Anforderun­
gen: entbehrlich/ja/teilweise/nein) mitgeteilt und diese Entscheidung erläutert werden.
Aktionspunkte zu 8.4.2 Durchführung des Soll-Ist-Vergleichs
• Je nach Fachgebiet vorab Checklisten erstellen
• Zielsetzung des IT-Grundschutz-Checks den Interviewpartner n erläutern
• Umsetzungsstatus der einzelnen Anforderungen erfragen
• Den Befragten die Ergebnisse mitteilen
8.4.3 Dokumentation der Ergebnisse
Die Ergebnisse des IT-Grundschutz-Checks sollten so dokumentiert werden, dass sie für alle Beteilig­
ten nachvollziehbar sind und als Grundlage für die Umsetzungsplanung der defizitären Anforderun­
gen und Maßnahmen genutzt werden können. Der Dokumentationsaufwand sollte nicht unter­
schätzt werden. Daher sollten geeignete Hilfsmittel genutzt werden, die bei der Erstellung und Ak­
tualisierung aller im Sicherheitsprozess erforderlichen Dokumente unterstützen.
Dies können zum einen geeignete IT-Grundschutz-Tools sein, also Anwendungen, die die gesamte
Vorgehensweise nach IT-Grundschutz unterstützen, beginnend bei der Stammdatenerfassung, über
die Schutzbedarfsfeststellung, die Risikoanalyse sowie den Soll-Ist-Vergleich (IT-Grundschutz-Check)
bis hin zur Erfüllung der Anforderungen. Hierdurch ergeben sich komfortable Möglichkeiten zur Aus­
wertung und Revision der Ergebnisse, z. B. die Suche nach bestimmten Einträgen, die Generierung
von Reports, Kostenauswertungen sowie Statistikfunktionen.
Des Weiteren stehen als Hilfsmittel zum IT-Grundschutz Formulare zur Verfügung. Zu jedem Baustein
des IT-Grundschutz-Kompendiums gibt es eine Datei, in der tabellarisch für jede Anforderung des
Bausteins die Ergebnisse des Soll-Ist-Vergleichs erfasst werden können.
Zur Dokumentation des IT-Grundschutz-Checks sollten erfasst werden:
• Die Nummer und die Bezeichnung des Objektes oder Gruppe von Objekten, der der Baustein bei
der Modellierung zugeordnet wurde,
• der Standort der zugeordneten Objekte bzw. Gruppe von Objekten,
• das Erfassungsdatum und der Name des Erfassers und
• die befragten Ansprechpartner.
Die eigentlichen Ergebnisse des Soll-Ist-Vergleichs sollten tabellarisch erfasst werden. Dabei sollten zu
jeder Anforderung des jeweiligen Bausteins folgende Informationen festgehalten werden:
• Umsetzungsgrad (entbehrlich/ja/teilweise/nein)
Der im Interview ermittelte Umsetzungsstatus der jeweiligen Anforderung ist zu erfassen. Im Hin­
blick auf eine mögliche Zertifizierung sollte zudem festgehalten werden, durch welche Maßnah­
men die Anforderungen konkret erfüllt werden.
151
• Antworten anhand von Stichproben am Objekt verifizieren8.5 Risikoanalyse
• Umsetzung bis . . .
Ein solches Feld ist sinnvoll, auch wenn es während eines IT-Grundschutz-Checks im Allgemeinen
nicht ausgefüllt wird. Es dient als Platzhalter, um in der Realisierungsplanung an dieser Stelle zu
dokumentieren, bis zu welchem Termin die Anforderung vollständig umgesetzt sein soll.
• Verantwortliche
Falls es bei der Durchführung des Soll-Ist-Vergleichs eindeutig ist, welche Mitarbeiter für die voll­
ständige Umsetzung einer defizitären Anforderung oder Maßnahme verantwortlich sind, sollte das
namentlich in diesem Feld dokumentiert werden. Falls die Verantwortung nicht eindeutig erkenn­
bar ist, sollte das Feld frei gelassen werden. Im Zuge der späteren Realisierungsplanung ist dann ein
Verantwortlicher zu bestimmen, dessen Name hier eingetragen werden kann.
• Bemerkungen/Begründungen
Ein solches Feld ist wichtig, um getroffene Entscheidungen später nachvollziehen zu können, bei­
spielsweise für die Zertifizierung. Bei Anforderungen, deren Umsetzung entbehrlich erscheint, ist
hier die Begründung zu nennen. Bei Anforderungen, die noch nicht oder nur teilweise umgesetzt
sind, sollte in diesem Feld dokumentiert werden, welche Maßnahmen noch umgesetzt werden
müssen. In dieses Feld sollten auch alle anderen Bemerkungen eingetragen werden, die bei der
Beseitigung von Defiziten hilfreich oder im Zusammenhang mit der Anforderung zu berücksichti­
gen sind.
• Defizite/Kostenschätzung
Für Anforderungen, die nicht oder nur teilweise erfüllt wurden, ist das damit verbundene Risiko in
geeigneter Form zu ermitteln und zu dokumentieren. Dies ist beispielsweise für Audits und Zerti­
fizierungen wichtig. Bei solchen Maßnahmen sollte außerdem geschätzt werden, welchen finan­
ziellen und personellen Aufwand die Beseitigung der Defizite erfordert.
Aktionspunkte zu 8.4.3 Dokumentation der Ergebnisse
• Stamminformationen über jedes Zielobjekt erfassen
• Informationen zum IT-Grundschutz-Check und zum Umsetzungsstatus dokumentieren
• Felder beziehungsweise Platzhalter für die Realisierungsplanung vorsehen
8.5
Risikoanalyse
Eine Risikoanalyse im Kontext der Informationssicherheit hat die Aufgabe, relevante Gefährdungen
für den Informationsverbund zu identifizieren und die daraus möglicherweise resultierenden Risiken
abzuschätzen. Das Ziel ist es, die Risiken durch angemessene Gegenmaßnahmen auf ein akzeptables
Maß zu reduzieren, die Restrisiken transparent zu machen und dadurch das Gesamtrisiko systema­
tisch zu steuern.
Zweistufiger Ansatz der IT-Grundschutz-Vorgehensweise
In der Vorgehensweise nach IT-Grundschutz wird bei der Erstellung der IT-Grundschutz-Bausteine
implizit eine Risikobewertung für Bereiche mit normalem Schutzbedarf durchgeführt. Hierbei werden
nur solche Gefährdungen betrachtet, die nach sorgfältiger Analyse eine so hohe Eintrittswahrschein­
lichkeit oder so einschneidende Auswirkungen haben, dass Sicherheitsmaßnahmen ergriffen werden
müssen. Typische Gefährdungen, gegen die sich jeder schützen muss, sind z. B. Schäden durch Feuer,
Einbrecher, Schadsoftware oder Hardware-Defekte. Dieser Ansatz hat den Vorteil, dass Anwender des
IT-Grundschutzes für einen Großteil des InformationsverbundesInformationsverbunds keine individu­
1528 Erstellung einer Sicherheitskonzeption nach Standard-Absicherung
elle Bedrohungs- und Schwachstellenanalyse durchführen müssen, weil diese Bewertung vorab be­
reits vorgenommen wurde.
In bestimmten Fällen muss jedoch eine explizite Risikoanalyse durchgeführt werden, beispielsweise
wenn der betrachtete Informationsverbund Zielobjekte enthält, die
• einen hohen oder sehr hohen Schutzbedarf in mindestens einem der drei Grundwerte Vertraulich­
keit, Integrität oder Verfügbarkeit haben oder
• mit den existierenden Bausteinen des IT-Grundschutzes nicht hinreichend abgebildet (modelliert)
werden können oder
• in Einsatzszenarien (Umgebung, Anwendung) betrieben werden, die im Rahmen des IT-Grund­
schutzes nicht vorgesehen sind.
• Welchen Gefährdungen für die Informationsverarbeitung ist durch die Umsetzung der relevanten
IT-Grundschutz-Bausteine noch nicht ausreichend oder sogar noch gar nicht Rechnung getragen
worden?
• Müssen eventuell ergänzende Sicherheitsmaßnahmen, die über das IT-Grundschutz-Modell hin­
ausgehen, eingeplant und umgesetzt werden?
Zur Beantwortung dieser Fragen empfiehlt das BSI die Anwendung einer Risikoanalyse auf der Basis
von IT-Grundschutz, wie sie im BSI-Standard 200-3 beschrieben ist.
In dem Standard wird dargestellt, wie für bestimmte Zielobjekte festgestellt werden kann, ob und in
welcher Hinsicht über den IT-Grundschutz hinaus Handlungsbedarf besteht, um Risiken für die Infor­
mationsverarbeitung zu reduzieren. Hierzu werden Risiken, die von elementaren Gefährdungen aus­
gehen, eingeschätzt und anhand einer Matrix bewertet. Die Einschätzung erfolgt über die zu erwar­
tende Häufigkeit des Eintretens und die Höhe des Schadens, der bei Eintritt des Schadensereignisses
entsteht. Aus diesen beiden Anteilen ergibt sich das Risiko. Die Methodik lässt sich wie folgt in den
IT-Grundschutz-Prozess integrieren:
Abbildung 32: Integration der Risikoanalyse in den IT-Grundschutz-Prozess
153
In diesen Fällen stellen sich folgende Fragen:8.5 Risikoanalyse
Der Standard bietet sich an, wenn Institutionen bereits erfolgreich mit der IT-Grundschutz-Methodik ar­
beiten und möglichst direkt eine Risikoanalyse an die IT-Grundschutz-Analyse anschließen möchten. Hier­
zu empfiehlt der BSI-Standard 200-3 Risikoanalyse auf der Basis von IT-Grundschutz folgende zusätzliche
Arbeitsschritte, die hier kurz im Überblick aufgeführt sind:
• Etablierung eines Risikomanagementprozesses
Die Risikoanalyse ist ein wichtiger Bestandteil des Managementsystems für Informationssicherheit
(ISMS). Daher sollten die Grundvoraussetzungen dafür von der Institutionsleitung vorgegeben
werden. Die grundsätzliche Vorgehensweise der Institution zur Durchführung von Risikoanalysen
sollte in einer Richtlinie (siehe BSI-Standard 200-3, Kapitel 2) dokumentiert und durch die Leitungs­
ebene verabschiedet werden.
• Erstellung der Gefährdungsübersicht
In diesem Arbeitsschritt wird für jedes zu analysierende Zielobjekt eine Liste der jeweils relevanten
Gefährdungen zusammengestellt. Bei der Ermittlung von Gefährdungen geht das BSI zweistufig
vor. Zunächst werden die relevanten elementaren Gefährdungen identifiziert und darauf aufbau­
end werden weitere mögliche Gefährdungen (zusätzliche Gefährdungen) ermittelt, die über die
elementaren Gefährdungen hinausgehen und sich aus dem spezifischen Einsatzszenario ergeben.
Dies erfolgt im Rahmen eines gemeinsamen Brainstormings.
• Risikoeinstufung
Die Risikoanalyse ist zweistufig angelegt. Für jedes Zielobjekt und jede Gefährdung wird eine Be­
wertung unter der Annahme vorgenommen, dass bereits Sicherheitsmaßnahmen umgesetzt oder
geplant worden sind. In der Regel wird es sich hierbei um Sicherheitsmaßnahmen handeln, die aus
den Basis- und Standard-Anforderungen des IT-Grundschutz-Kompendiums abgeleitet worden
sind. An die erste Bewertung schließt sich eine zweite an, bei der mögliche Sicherheitsmaßnahmen
zur Risikobehandlung betrachtet werden. Durch einen Vorher-Nachher-Vergleich lässt sich die
Wirksamkeit der Sicherheitsmaßnahmen prüfen, die zur Risikobehandlung eingesetzt worden
sind.
• Behandlung von Risiken
Abhängig vom Risikoappetit einer Institution sind jeweils unterschiedliche Risikoakzeptanzkriterien
möglich. Risikoappetit bezeichnet die durch kulturelle, interne, externe oder wirtschaftliche Ein­
flüsse entstandene Neigung einer Institution, wie sie Risiken bewertet und mit ihnen umgeht. Es
gibt folgende Optionen zur Behandlung von Risiken:
• Risiken können vermieden werden (z. B. durch Umstrukturierung von Geschäftsprozessen oder des
Informationsverbunds).
• Risiken können durch entsprechende Sicherheitsmaßnahmen reduziert werden.
• Risiken können transferiert werden (z. B. durch Outsourcing oder Versicherungen).
Daran anschließend muss eine Institution Risikoakzeptanzkriterien festlegen und die Behandlung des
Risikos darauf abbilden. Bei der Entscheidung, wie mit den identifizierten Risiken umzugehen ist, muss
auf jeden Fall die Leitungsebene beteiligt werden, da sich daraus unter Umständen erhebliche Schä­
den ergeben oder zusätzliche Kosten entstehen können.
Die Schritte Gefährdungsbewertung und Risikobehandlung werden so lange durchlaufen, bis die Ri­
sikoakzeptanzkriterien der Institution erfüllt sind und das verbleibende Risiko („Restrisiko“) im Ein­
klang mit den Zielen und Vorgaben der Institution steht. Das verbleibende Risiko muss anschließend
1548 Erstellung einer Sicherheitskonzeption nach Standard-Absicherung
der Leitungsebene zur Zustimmung vorgelegt werden („Risiko-Akzeptanz“). Damit wird nachvoll­
ziehbar dokumentiert, dass die Institution sich des Restrisikos bewusst ist.
• Konsolidierung des Sicherheitskonzepts
Bevor der originäre IT-Grundschutz-Prozess fortgesetzt werden kann, muss das erweiterte Si­
cherheitskonzept konsolidiert werden. Dabei werden die Eignung, das Zusammenwirken, die
Benutzerfreundlichkeit und die Angemessenheit der Sicherheitsmaßnahmen insgesamt über­
prüft.
• Außerdem wird im BSI-Standard 200-3 Risikoanalyse auf der Basis von IT-Grundschutz erläutert,
wie die Methodik anzuwenden ist, wenn der Informationsverbund Zielobjekte umfasst, für die im
IT-Grundschutz-Kompendium bislang kein geeigneter Baustein enthalten ist.
Wichtig:
Die Risikoanalyse auf der Basis von IT-Grundschutz ist eine Vorgehensweise, um bei Bedarf Si­
cherheitsvorkehrungen zu ermitteln, die fber die im IT-Grundschutz-Kompendium genannten
Sicherheitsanforderungen hinausgehen. Obwohl diese Methodik gegenfber vielen anderen
ähnlichen Verfahren vereinfacht wurde, ist sie oft mit erheblichem Aufwand verbunden. Um
schnellstmöglich die wichtigsten Sicherheitsprobleme zu beseitigen, ist es manchmal zweckmä­
ßig, zuerst die IT-Grundschutz-Anforderungen vollständig zu erffllen und erst danach eine Risi­
koanalyse durchzuffhren (abweichend von obigem Schema). Dadurch mfssen zwar insgesamt
einige Schritte öfter durchlaufen werden, die IT-Grundschutz-Anforderungen werden jedoch
frfher erffllt.
Diese alternative Reihenfolge bietet sich besonders dann an, wenn
• der betrachtete Informationsverbund bereits realisiert und in Betrieb ist und
• die vorliegenden Zielobjekte mit den existierenden Bausteinen des IT-Grundschutz-Kompendiums
hinreichend modelliert werden können.
Für geplante Informationsverbünde oder für solche mit untypischen Techniken bzw. Einsatzszenarien
wird dagegen die oben abgebildete originäre Reihenfolge empfohlen. Die folgende Tabelle fasst die je­
weiligen Vor- und Nachteile der beiden alternativen Reihenfolgen zusammen:
155
Eine ausführliche Darstellung der Methodik findet sich im BSI-Standard 200-3.8.5 Risikoanalyse
Risikoanalyse direkt nach dem IT-Grund­ Risikoanalyse erst nach vollständiger Um­
schutz-Check
setzung der Sicherheitsmaßnahmen
Mögliche Vorteile:
Mögliche Vorteile:
• Es wird Mehraufwand vermieden, da keine • Sicherheitsmaßnahmen werden früher um-
Maßnahmen umgesetzt werden, die im Rah-
gesetzt, da die Risikoanalyse häufig aufwen­
men der Risikoanalyse eventuell durch stärkere
dig ist.
Maßnahmen ersetzt werden.
• Elementare Sicherheitslücken werden vor­
• Eventuell erforderliche Hochsicherheitsmaß­
rangig behandelt, bevor fortgeschrittene
nahmen werden früher identifiziert und umge-
Gefährdungen analysiert werden.
setzt.
Mögliche Nachteile:
Mögliche Nachteile:
• Sicherheitsmaßnahmen werden später umge­ • Es kann Mehraufwand entstehen, da even­
setzt, da die Risikoanalyse häufig aufwendig ist.
tuell einige Sicherheitsmaßnahmen umge­
setzt werden, die später im Rahmen der Risi­
• Eventuell werden elementare Sicherheitslücken
koanalyse durch stärkere Maßnahmen er­
vernachlässigt, während fortgeschrittene Ge­
setzt werden.
fährdungen analysiert werden.
• Eventuell erforderliche Hochsicherheitsmaß­
nahmen werden erst später identifiziert und
umgesetzt.
Tabelle 7: Vor- und Nachteile der alternativen Reihenfolgen bei der Risikoanalyse
Wichtig ist außerdem, dass eine Risikoanalyse auf der Basis von IT-Grundschutz häufig leichter durch­
zuführen ist, wenn sie nacheinander auf kleine Teilaspekte des Informationsverbunds angewandt
wird. Als ersten Schritt kann die Analyse beispielsweise auf die baulich-physische Infrastruktur be­
schränkt werden, d. h. auf den Schutz vor Brand, Wasser und unbefugtem Zutritt sowie auf die ord­
nungsgemäße Strom- und Klimaversorgung.
In vielen Behörden und Unternehmen existieren bereits Verfahren zur Risikoanalyse beziehungsweise
zur Risikobehandlung. Um eine einheitliche Methodik zu erreichen, kann es in solchen Fällen zweck­
mäßig sein, die vorhandenen Verfahren auf die Informationssicherheit auszudehnen und gegebenen­
falls nur Teilaspekte des BSI-Standards 200-3 anzuwenden. International haben sich eine Reihe von
unterschiedlichen Ansätzen zur Durchführung von Risikoanalysen im Bereich der Informationssicher­
heit etabliert. Diese Verfahren unterscheiden sich beispielsweise in Bezug auf den Detaillierungsgrad,
die Formalisierung und die thematischen Schwerpunkte. Abhängig von den Rahmenbedingungen
einer Institution und der Art des Informationsverbunds kann es zweckmäßig sein, alternativ zum
BSI-Standard 200-3 ein anderes etabliertes Verfahren oder eine angepasste Methodik für die Analyse
von Informationsrisiken zu verwenden.
1568 Erstellung einer Sicherheitskonzeption nach Standard-Absicherung
Aktionspunkte zu 8.5 Risikoanalyse
• Grundsätzliche Vorgehensweise der Institution zur Durchführung von Risikoanalysen in einer
Richtlinie dokumentieren und der Leitungsebene zur Verabschiedung vorlegen
• Ermitteln, für welche Zielobjekte oder Gruppen von Zielobjekten eine Risikoanalyse durchgeführt
werden soll
• BSI-Standard 200-3 Risikoanalyse auf der Basis von IT-Grundschutz systematisch durcharbeiten
• Ergebnisse der Risikoanalysen in das Sicherheitskonzept integrieren