BSI/200-3/Vorarbeiten

Vorarbeiten zur Risikoanalyse

Bevor die eigentliche Risikoanalyse beginnt, sollten folgende Vorarbeiten abgeschlossen sein, die in

der IT-Grundschutz-Methodik gemäß BSI-Standard 200-2 beschrieben sind:

• Es muss ein systematischer Informationssicherheitsprozess initiiert worden sein. Dieser dient dazu, die Aktivitäten im Bereich der Informationssicherheit strukturiert abzuarbeiten. Beispielsweise müssen geeignete Rollen und Aufgaben definiert werden.
• Gemäß Kapitel 3.3 der IT-Grundschutz-Methodik muss ein Geltungsbereich für die Sicherheitskon­zeption definiert worden sein. Dieser Geltungsbereich wird im Folgenden als Informationsverbund bezeichnet.
• Für den Informationsverbund sollte eine Strukturanalyse gemäß Kapitel 8.1 der IT-Grund­schutz-Methodik durchgeführt worden sein.

Dadurch werden die wichtigsten Informationen über den Informationsverbund ermittelt, z. B. Geschäftsprozesse, der Netzplan sowie eine Liste der wichtigsten Anwendungen mit Abhängigkeit von den IT-Systemen.

• Anschließend sollte eine Schutzbedarfsfeststellung gemäß Kapitel 8.2 der IT-Grundschutz-Metho­dik durchgeführt worden sein. Als Ergebnis liegen der Schutzbedarf der Geschäftsprozesse, An­wendungen, IT-Systeme, genutzten Räume sowie eine Liste der kritischen Kommunikationsverbin­dungen vor. Der Schutzbedarf bezieht sich jeweils auf die Grundwerte Vertraulichkeit, Integrität und Verfügbarkeit und wird nach IT-Grundschutz normalerweise in den Stufen normal, hoch und sehr hoch festgelegt.
• Es sollte eine Modellierung gemäß Kapitel 8.3 der IT-Grundschutz-Methodik und Kapitel 2 des IT-Grundschutz-Kompendiums durchgeführt worden sein. Dabei wird für jedes Zielobjekt im Infor­mationsverbund festgelegt, ob es passende IT-Grundschutz-Bausteine gibt und wie diese anzu­wenden sind. Die in den einzelnen Bausteinen genannten Sicherheitsanforderungen und die dar­aus abgeleiteten Sicherheitsmaßnahmen bilden die Basis für das IT-Grundschutz-Sicherheitskon­zept des betrachteten Informationsverbundes.
• Es sollte vor der Risikoanalyse ein IT-Grundschutz-Check gemäß Kapitel 8.4 der IT-Grund­schutz-Methodik durchgeführt werden. Dadurch wird festgestellt, welche Basis- und Standard-Si­cherheitsanforderungen für den vorliegenden Informationsverbund bereits erfüllt sind und wo noch Defizite bestehen.

Als Ergebnis der Vorarbeiten liegt eine Liste der Zielobjekte vor, für die eine Risikoanalyse durchgeführt werden sollte („betrachtete Zielobjekte“). Damit diese Aufgabe mit vertretbarem Aufwand geleistet werden kann, ist es wichtig, dass die Zielobjekte – gemäß IT-Grundschutz-Vorgehensweise – sinnvoll zu Gruppen zusammengefasst worden sind.

Falls trotz Gruppenbildung viele Zielobjekte einer Risikoanalyse unterzogen werden müssen, sollte eine geeignete Priorisierung vorgenommen werden

• Falls für den IT-Grundschutz die Vorgehensweise „Standard-Absicherung“ gewählt wurde, sollten vorrangig die übergeordneten Zielobjekte bearbeitet werden (insbesondere Geschäftsprozesse, Teilverbünde und gesamter Informationsverbund). Aus diesen Arbeiten ergeben sich oft wertvolle Anhaltspunkte für die Risikoanalysen der untergeordneten technischen Zielobjekte.
• Falls für den IT-Grundschutz die Vorgehensweise „Kern-Absicherung“ gewählt wurde, sollten vorrangig die Zielobjekte mit dem höchsten Schutzbedarf bearbeitet werden.
• Falls für den IT-Grundschutz die Vorgehensweise „Basis-Absicherung“ gewählt wurde, werden zunächst keine Risikoanalysen durchgeführt, sondern es werden als Erstes nur die Basis-Anforde­rungen umgesetzt.

Von der hier beschriebenen Vorgehensweise kann abgewichen werden.

• Unter Umständen bietet es sich an, eine Risikoanalyse erst nach Erfüllung der IT-Grundschutz-Anforderungen durchzuführen.
• Dies kann beispielsweise bei Zielobjekten sinnvoll sein, die bereits im Einsatz sind und die hinreichend durch IT-Grundschutz-Bausteine dargestellt werden können.
• Als Entscheidungshilfe dazu, nach wel­chem Schritt eine Risikoanalyse sinnvoll ist, findet sich eine Zusammenstellung der Vor- und Nachteile der möglichen Zeitpunkte in Kapitel 8.5 der IT-Grundschutz-Methodik (siehe [BSI2]).

Hinweis

Bei den betrachteten Zielobjekten muss es sich nicht zwangsläufig um systemorientierte Zielob­jekte (z. B. Anwendungen, IT-Systeme oder -Räume) handeln. Vielmehr kann die Risikoanalyse auch auf Geschäftsprozessebene durchgeffhrt werden.

Zu den Vorarbeiten gehört auch, dass die Grundvoraussetzungen für die Risikoanalyse von der Insti­tutionsleitung vorgegeben werden.

Hierzu muss die Leitungsebene eine Richtlinie zum Umgang mit Risiken verabschieden. Diese sollte unter anderem folgende Aspekte umfassen:

• Unter welchen Voraussetzungen muss in jedem Fall eine Risikoanalyse durchgeführt werden?
• Welche Methodik beziehungsweise welcher Standard wird dazu eingesetzt, um die Risiken zu identifizieren, einzuschätzen, zu bewerten und zu behandeln?
• Wie wird die gewählte Methodik auf die speziellen Belange der Institution angepasst?
• Was sind die Risikoakzeptanzkriterien?
• Welche Organisationseinheiten sind für welche Teilaufgaben der Risikoanalyse verantwortlich? Sind Risiken den jeweiligen Risikoeigentümern zugeordnet?
• Auf welche Weise werden Risikoanalysen in den Sicherheitsprozess integriert, geschieht dies bei­spielsweise vor oder nach Umsetzung der IT-Grundschutz-Anforderungen?
• Welche Berichtspflichten bestehen im Rahmen von Risikoanalysen?
• In welchem Zeitrahmen muss die Risikoanalyse vollständig aktualisiert werden?

Da die Risikoakzeptanzkriterien einer Institution in entscheidendem Maße von deren Risikoneigung (Risikoappetit) abhängen, kann es sinnvoll sein, auch die Risikoneigung (siehe Kapitel 9) in der Richt­linie zu beschreiben.

• Möglicherweise ist sich eine Institution ihrer eigenen Risikoneigung nicht be­wusst oder hat ungenaue Vorstellungen von diesem Begriff. In diesem Fall sollte die Leitungsebene eine Klärung und Entscheidung herbeiführen, gegebenenfalls sollte die Institution hierfür auf externe Experten zurückgreifen.

Richtlinie zur Risikoanalyse

• Die in der Richtlinie zur Risikoanalyse beschriebenen Vorgaben der Leitungsebene müssen konse­quent umgesetzt werden, wenn Risiken bewertet und behandelt werden.
• Zweifelsfälle können auf­ treten, beispielsweise wenn es bei einem bestimmten Risiko nicht sinnvoll erscheint, die festgelegte Risikoneigung anzuwenden. Solche Ausnahmefälle sollten abgestimmt und dokumentiert werden.

Die Richtlinie zur Risikoanalyse sollte gemäß den Vorgaben des Informationssicherheits-management­systems (siehe BSI-Standard 200-2 IT-Grundschutz Methodik [BSI2]) erstellt werden. Sie muss in re­gelmäßigen Abständen oder anlassbezogen auf ihre Aktualität hin überprüft und gegebenenfalls orientiert an den Zielen der Institution angepasst werden. Insbesondere sollte auch die eingesetzte Vorgehensweise zur Risikoanalyse regelmäßig überprüft werden. Die Richtlinie zur Risikoanalyse muss durch die Institutionsleitung freigegeben werden.

Beispiel 1

Im Folgenden wird anhand einer fiktiven Institution, der RECPLAST GmbH, beispielhaft darge­stellt, wie Risiken eingeschätzt, bewertet und behandelt werden können. Zu beachten ist, dass die Struktur der RECPLAST GmbH im Hinblick auf Informationssicherheit keineswegs optimal ist. Sie dient lediglich dazu, die Vorgehensweise bei der Durchführung von Risikoanalysen zu illustrie­ren. Die RECPLAST GmbH ist eine fiktive Institution mit ca. 500 Mitarbeitern, von denen 130 an Bild­schirmarbeitsplätzen arbeiten. Räumlich ist die RECPLAST GmbH aufgeteilt in zwei Standorte in­nerhalb Bonns, wo unter anderem die administrativen und produzierenden Aufgaben wahrge­nommen werden, und drei Vertriebsstandorte in Deutschland.

Das IT-Netz ist in mehrere Teilbereiche aufgeteilt. Für die Beispiele in dieser Risikoanalyse wird das Teilnetz A (vergleiche Abbildung 2 in Kapitel 4) näher betrachtet. Der Zugang zum Teilnetz A ist durch die Firewall N1 abgesichert. Die Server S1 (Virtualisierungsserver) und S5 werden durch einzelne Switches angebunden. Der Virtualisierungsserver S1 stellt verschiedene Dienste zur Verfügung, z. B. werden dort in vir­tuellen Maschinen File- und E-Mail-Server betrieben. Diese Anwendungen haben teilweise einen hohen Schutzbedarf in mindestens einem der drei Grundwerte Vertraulichkeit, Integrität oder Verfügbarkeit. Durch das Maximumprinzip gilt für den Virtualisierungsserver S1 der höchste Schutzbedarf der zur Verfügung gestellten virtuellen Maschinen bzw. IT-Anwendungen. Um die Stunden der Mitarbeiter zu erfassen, verwendet die RECPLAST GmbH eine Softwarelösung, die als Webanwendung implementiert ist. Ffr die Datenhaltung nutzt diese eine Datenbank, die im Datenbankmanagementsystem (A1) auf dem Server S5 betrieben wird.

Darfber hinaus betreibt die RECPLAST GmbH eine Reihe von Servern, die dazu eingesetzt wer­ den, alle IT-Systeme und darauf betriebenen Anwendungen kontinuierlich zu fberwachen.

Beispiel 2

Das fiktive Unternehmen MUSTERENERGIE GmbH betreibt eine Smart Meter Gateway Infrastruk­tur (intelligentes Netz). Kernbausteine einer solchen Infrastruktur sind intelligente Messsysteme, auch „Smart Metering Systems“ genannt. Das Smart Meter Gateway (SMGW) stellt dabei die zentrale Kommunikationseinheit dar. Es kommuniziert im lokalen Bereich beim Endkunden mit den elektronischen Zählern (Local Metrological Network, LMN-Bereich), mit Geräten aus dem Home Area Network (HAN-Bereich) und im Wide Area Network (WAN-Bereich) mit autorisierten Marktteilnehmern. Außerdem ermöglicht das SMGW die Verbindungsaufnahme von lokalen Ge­räten des HAN über das WAN mit autorisierten Marktteilnehmern.

Für die Installation, Inbetriebnahme, den Betrieb, die Wartung und Konfiguration des SMGW ist der Smart-Meter-Gateway-Administrator (SMGW-Admin) verantwortlich. Da es sich hierbei teil­weise um sensible Informationen handelt, ist der Schutz dieser Informationen wichtig. Daher muss sichergestellt sein, dass der IT-Betrieb beim SMGW-Admin sicher erfolgt. Für die Beispiele in dieser Risikoanalyse wird neben Teilnetz A der RECPLAST GmbH auch die Smart-Meter-Gateway-Administration der MUSTERENERGIE GmbH näher betrachtet.