Sicherheit in vernetzten Systemen - RRZ Universität Hamburg
Sicherheit in vernetzten Systemen - RRZ Universität Hamburg
Sicherheit in vernetzten Systemen - RRZ Universität Hamburg
Erfolgreiche ePaper selbst erstellen
Machen Sie aus Ihren PDF Publikationen ein blätterbares Flipbook mit unserer einzigartigen Google optimierten e-Paper Software.
4.4. ERSTELLUNG UND UMSETZUNG<br />
Besonders bei schweren Vorfällen wie Bränden, Personenschäden oder Ausfällen von weiten Teilen<br />
der Systeme z.B. durch Gewitterschaden stellt für alle Beteiligten e<strong>in</strong>e starke psychische Belastung<br />
dar, unter der es schwer ist, aus dem Stand s<strong>in</strong>voll und effizient zu handeln. In manchen Fällen kann<br />
es sogar unmöglich se<strong>in</strong>, auf e<strong>in</strong>en Vorfall s<strong>in</strong>nvoll zu reagieren, wenn nicht vorher schon Vorbereitungen<br />
getroffen wurden. So sollte zum Beispiel e<strong>in</strong>e Kopie der Pläne zur Vorfallsbearbeitung an<br />
mehreren Stellen gelagert werden, damit diese bei e<strong>in</strong>em Brand auch zur Verfügung stehen und nicht<br />
verbrennen.<br />
Idealerweise bieten die Pläne zur Vorfallsbearbeitung die „Vorbereitung auf das Unvorhersehbare“<br />
und zu jedem möglichen Vorfall gibt es Handlungsanweisungen, wie vorzugehen ist. Solch e<strong>in</strong> „Zauberbuch“<br />
wird es jedoch <strong>in</strong> der Praxis natürlich nicht geben. Trotzdem ist es s<strong>in</strong>nvoll, möglichst viele<br />
Möglichkeiten bei der Erstellung dieser Pläne <strong>in</strong> Betracht zu ziehen, denn jede Stunde die für die<br />
Erstellung e<strong>in</strong>es solchen Dokumentes verwendet wird, zahlt sich im Ernstfall um e<strong>in</strong> Vielfaches aus.<br />
4.4.5 Zusammenspiel<br />
In den vorigen Abschnitten wurden drei Teile vorgestellt, aus denen e<strong>in</strong> vollständiges <strong>Sicherheit</strong>skonzept<br />
bestehen sollte, die Risikoanalyse, die Policy selbst und die Vorfallsbearbeitung.<br />
Am Anfang steht e<strong>in</strong>e Risikoanalyse, die Risiken und Schwachstellen aufdeckt und Gegenmaßnahmen<br />
abwägt.<br />
Diese Menge von Risiken wird dadurch <strong>in</strong> zwei Teile aufgespalten. Der größte Teil sollte <strong>in</strong> der Policy<br />
durch entsprechende Maß nahmen verh<strong>in</strong>dert oder verr<strong>in</strong>gert werden. Die restlichen Risiken sollten<br />
dann <strong>in</strong> den Plänen zur Vorfallsbearbeitung Beachtung f<strong>in</strong>den.<br />
Risiken<br />
Schwachstellen-<br />
Analyse<br />
Vorfalls-Bearbeitung /<br />
Notfall-Plan<br />
Policy<br />
Abbildung 4.2: Das Zusammenspiel der drei Teile<br />
Idealerweise gibt es also ke<strong>in</strong> Risiko, das weder <strong>in</strong> der Policy noch bei der Vorfallsbearbeitung behandelt<br />
wird (siehe Abbildung 4.2). Natürlich ist auch dies wieder e<strong>in</strong> Idealbild, das <strong>in</strong> der Praxis kaum<br />
zu erreichen ist. Es sollte aber auf jeden Fall das angestrebte Ziel se<strong>in</strong>, dieses Bild so weit wie möglich<br />
zu verwirklichen.<br />
4.4.6 Umsetzung der Policy und Kontrolle<br />
Nach der erfolgreichen Erstellung der Policy und ihrer Zusätze (Handbücher, Standards usw.) kann<br />
diese „<strong>in</strong> Betrieb genommen“ werden. Sie wird also nochmals durch den zuständigen Entscheidungsträger<br />
abgesegnet und ist ab sofort gültig und b<strong>in</strong>dend. Jedoch ist die Arbeit an der Policy nicht abge-<br />
SS 99, Sem<strong>in</strong>ar 18.416: <strong>Sicherheit</strong> <strong>in</strong> <strong>vernetzten</strong> <strong>Systemen</strong> 65