ITIL und Informationssicherheit

ITIL und Informationssicherheit
Version 1.0.1
Aspekte der Integration von Incident und
Security Management
KBSt-Brief 2/2006
Oktober 2006
Seite 1
Nachdruck, auch auszugsweise, ist genehmigungspflichtig
Dieser Band wurde erstellt von der KBSt im Bundesministerium des Innern in
Zusammenarbeit mit HiSolutions AG
Redaktion: HiSolutions AG, Berlin
Interessenten erhalten die derzeit lieferbaren Veröffentlichungen der KBSt
und weiterführende Informationen zu den Dokumenten beim
Bundesministerium des Innern
Referat IT 2 (KBSt)
11014 Berlin
Homepage der KBSt: http://www.kbst.bund.de/
E-Mail: IT2@bmi.bund.de
Seite 2
ITIL und Informationssicherheit
Aspekte der Integration von Incident und Security Management
Version 1.0.1
September 2006
Herausgegeben vom
Bundesministerium des Innern
Seite 3
Inhaltsverzeichnis
1. Einleitung ....................................................................................................................6
1.1 Zielsetzung .............................................................................................................6
1.2 Zielgruppen ............................................................................................................7
1.3 Einordnung und Ausblick........................................................................................7
1.4 Dokumentaufbau ....................................................................................................8
2. Standards im IT-Service- und IT-Sicherheitsmanagement ..................................10
2.1 ITIL und IT-Service Management .........................................................................10
2.3 Standards und Richtlinien im IT-Sicherheitsmanagement ....................................10
2.3.1 IT-Grundschutz-Standards ..........................................................................10
2.3.2 BS 7799/ ISO 17799:2005...........................................................................11
2.3.3 ISO 27001 ...................................................................................................12
3. Zusammenspiel von Incident Management und IT-Sicherheit .............................13
3.1 Der Service Desk im Incident Management .........................................................13
3.2 Incident Management ...........................................................................................14
3.2.1 Übergeordnete Anforderungen....................................................................18
3.2.2 Incident erkennen und erfassen ..................................................................20
3.2.3 Incident qualifizieren und Erstlösungsversuch.............................................22
3.2.4 Incident analysieren und Lösung vorschlagen.............................................26
3.2.5 Incident lösen und Service wiederherstellen ...............................................27
3.2.6 Incidents überwachen und steuern..............................................................29
3.2.7 Incident abschließen ...................................................................................31
4. Referenzen ................................................................................................................33
5. Glossar ......................................................................................................................34
Anhang ..........................................................................................................................36
Tabellenverzeichnis
Tabelle 1: Erläuterung der Tabellen .................................................................................8
Tabelle 2: Störungsannahme für Sicherheitsvorfälle ......................................................15
Tabelle 3: IT-Sicherheitsrichtlinie....................................................................................19
Tabelle 4: Rollen und Verantwortlichkeiten.....................................................................20
Tabelle 5: Erkennungs- und Registrierungsregeln..........................................................21
Tabelle 6: Bewusstsein für IT-Sicherheit schaffen..........................................................22
Seite 4
Tabelle 7: Priorisierungsmatrix für Sicherheitsvorfälle....................................................24
Tabelle 8: Klassifizierung von Sicherheitsvorfällen.........................................................25
Tabelle 9: Verifizierung des Verdachts eines sicherheitsrelevanten Incident .................26
Tabelle 10: Informationsbeschaffung über Sicherheitslücken des Systems ...................27
Tabelle 11: Zugriff auf Incident Informationen (Konzeption und Planung) ......................28
Tabelle 12: Eskalations- und Benachrichtigungswege bei Sicherheitsvorfällen..............30
Tabelle 13: Notfallvorsorge.............................................................................................31
Tabelle 14: Dokumentationsregeln .................................................................................32
Tabelle 15: Glossar ........................................................................................................35
Tabelle 16: Berührungspunkte Incident Management / IT-Sicherheitsmanagement ......37
Abbildungsverzeichnis
Abbildung 1: Übersicht über BSI Publikationen zum IT-Sicherheitsmanagement...........11
Abbildung 2: Prozesse im Service Desk .........................................................................14
Abbildung 3: Prozessübersicht Incident Management....................................................17
Seite 5
1. Einleitung
Die IT-Organisationen in Behörden und Unternehmen werden zunehmend mit der
Anforderung konfrontiert, ihre IT-Prozesse aufgrund der dynamischen Änderungen in
den Geschäftsprozessen neu auszurichten und gleichzeitig zu optimieren. Auch der
schnelle Fortschritt in der Informationstechnologie selbst führt zu neuen Anforderungen
an Prozesse im IT-Bereich.
Um dieser Dynamik gewachsen zu sein, führt kein Weg an Standardisierung vorbei.
Dies gilt nicht nur für die Betriebsprozesse in der IT, sondern vor allem auch für die ITService-Management-Prozesse, die für die Planung und Steuerung der Servicequalität
und für das serviceorientierte Zusammenwirken der Betriebsverfahren verantwortlich
sind..
Eine gute Orientierung für diese Prozessstandardisierung bietet die „IT Infrastructure
Library (ITIL)“, die sich als fachliche Anleitung zur Planung, Erbringung und
Qualitätssicherung von IT Dienstleistungen etabliert hat.
Doch nur zu oft muss festgestellt werden, dass das Thema Informationssicherheit obwohl ein fester Bestandteil des ITIL-Standards - bei Einrichtung oder Optimierung von
IT-Service-Management-Prozessen isoliert und ohne gegenseitige Berücksichtigung
behandelt wird. Dieser Umstand führt zu Reibungsverlusten. Daher ist es dringend
notwendig, den IT-Sicherheitsbeauftragten frühzeitig und in der richtigen Weise
einzubeziehen.
Dieses Dokument zeigt auf, welche Aspekte und Anforderungen für den ITIL-Prozess
„Incident Management“ (Störungsmanagement) diskutiert werden müssen. Es soll den
dringend notwendigen Dialog zwischen den jeweiligen Verantwortlichen fördern. Alle
Beteiligten müssen nach Wegen suchen, um Medienbrüche und Redundanzen in den
Prozessen zu vermeiden und gemeinsame Synergiepotenziale zur Gewährleistung
sicherer und wirtschaftlicher IT-Services zu erschließen.
1.1 Zielsetzung
Was dieses Dokument erreichen kann.
Ziel dieser Veröffentlichung ist es, eine Grundlage für das Verständnis
sicherheitsrelevanter Anforderungen im Incident Management (Störungsmanagement)
zu schaffen. Tabellarisch wird dargestellt, welche Sicherheitsvorgaben berücksichtigt
werden sollten, welche Fragen beantwortet werden müssen und welche Empfehlungen
für die Umsetzung ausgesprochen werden können.
Die hier berücksichtigten Sicherheitsanforderungen basieren auf dem ISO17799Standard sowie den IT-Grundschutz-Standards des Bundesamtes für Sicherheit in der
Informationstechnik (BSI).
Das Dokument bietet somit Hilfestellung für eine Ist-Aufnahme, mit der überprüft werden
kann, welche Anforderungen bereits abgedeckt sind und wo die Verbesserungspotenziale liegen. Dabei geht es nicht darum, ob alle Aktivitäten hochintegriert oder
automatisiert unterstützt werden. Wichtig ist vielmehr, dass grundsätzlich Lösungen zur
Erfüllung der Anforderungen in angemessenem Umfang bereitgestellt werden können,
auch wenn diese zunächst mit rein organisatorischen Maßnahmen verbunden sind.
Sind Verbesserungspotenziale identifiziert, gibt das Dokument Hinweise zur Ableitung
geeigneter Maßnahmen. Insbesondere die IT-Grundschutz-Kataloge (GSK) des BSI mit
ihren konkreten Maßnahmenempfehlungen bieten ausreichende Unterstützung bei der
Umsetzung.
Seite 6
Was dieses Dokument nicht erreichen kann.
Pauschale Lösungen „von der Stange“ gibt es nicht. In diesem Dokument können zwar
Hinweise gegeben werden, die konkrete Umsetzung ist jedoch stark vom individuellen
Umfeld und den besonderen Erfordernissen der IT-Organisation einer Behörde oder
eines Unternehmens abhängig. Es geht in diesem Dokument nur um das „Was“ und
„Warum“, nicht um das „Wie“ und „Wer“.
Deshalb werden auch keine Vorschläge zur Prozess- und Rollenorganisation gegeben.
Für diese Aspekte sei auf den BSI-Standard 100-1 Managementsysteme für
Informationssicherheit und Baustein B 1.0 IT-Sicherheitsmanagement der GSK
verwiesen.
Diese sollten im Rahmen einer anschliessenden Umsetzungsplanung zwischen
Incident- und IT-Sicherheits-management abgestimmt werden.
Auch das zum Incident Management gemäß ITIL notwendige Grundlagenwissen wird in
diesem Dokument nicht vermittelt. Der Prozess mit seinen Einzelschritten wird lediglich
kurz beschrieben (siehe Kapitel: 3.2 Incident Management). Zur detaillierten Darstellung
der Funktionsweise des Incident Management wird auf die weiterführende ITIL-Literatur
verwiesen (siehe Anhang).
1.2 Zielgruppen
Das Dokument wendet sich an alle IT-Organisationen, die ihr implementiertes Incident
Management gegen die sicherheitsrelevanten Prozessanforderungen prüfen möchten.
Insbesondere werden die Prozessverantwortlichen für Incident Management und ITSicherheitsmanagement angesprochen, denen ein Gerüst für den notwendigen Dialog
an die Hand gegeben werden soll.
Ist die Incident Management Einführung geplant oder aktuell in der Umsetzung, ergeben
sich konkrete Anforderungen und Fragestellungen für das Projektteam. Auch die
Vorbereitung interner und externer Audits wird unterstützt.
Grundsätzlich gelten die Sicherheitsanforderungen unabhängig davon, in welcher
Reifephase sich die Prozesseinführung befindet. Je höher die Prozeßreife, desto stärker
greift der Anspruch an Automatismen und Integration. Jede IT-Organisation muss selbst
eruieren, wo sie steht und welche vordergründigen Ziele mit einem konkreten Horizont
anzustreben sind.
Zusätzlich kann diese Dokumentation für alle an den Synergien zwischen IT-Sicherheit
und IT-Service-Management interessierte Personen eine weiterführende Informationsquelle sein.
1.3 Einordnung und Ausblick
In diesem Dokument wird das Incident Management behandelt. Es soll die
Wechselwirkung von ITIL und IT-Sicherheitsmanagement für weitere ITIL-Prozesse
dargestellt werden.
Aktuell im Fokus stehen dabei
•
das Change Management (Änderungsmanagement)
•
das Configuration Management (Konfigurationsmanagement)
und
•
das Service Level Management
Seite 7
Bei allen Veröffentlichungen stehen dabei nicht die Prozesse selbst, sondern die
gegenseitigen Wechselwirkungen mit dem IT-Sicherheitsmanagement im Vordergrund.
Das Ziel dabei ist konkrete Anforderungen sowie Hinweise zur Umsetzung in den
jeweiligen Prozessen zu liefern und somit die Zusammenarbeit beider Managementdisziplinen zu fördern.
1.4 Dokumentaufbau
Das Dokument umfasst folgende Kapitel:
Kapitel 1: Einleitung
Kapitel 2.: Standards im IT-Service-Management und IT-Sicherheitsmanagement
Dargestellt wird ein Überblick über die relevanten Sicherheitsstandards im
Zusammenhang mit den ITIL-Best-Practices.
Kapitel 3.: Zusammenspiel von IT-Service und IT-Sicherheitsmanagement:
In diesem Kapitel wird auf die Schnittstellen zwischen Incident Management
und dem IT-Sicherheitsmanagement sowie ihre Integrationsmöglichkeiten auf
Ebene der konkreten Prozessschritte eingegangen. In tabellarischer Form
werden in den Prozessschritten des Incident Management die
sicherheitsrelevanten Ziele benannt, deren Auswirkungen erläutert sowie
Kontrollfragen gestellt. Zur Unterstützung der Durchführung von
Verbesserungsmaßnahmen
werden
an
ausgewählten
Stellen
Umsetzungshinweise geliefert.
Die Tabellen sind wie folgt aufgebaut:
Benennung der festgestellten Anforderungen, welche zu berücksichtigen sind
Phase
In Anlehnung an die IT-Grundschutz-Standards wurden die
Anforderungen mit den entsprechenden Maßnahmen in einem
Phasenzyklus aufgelistet. In der Regel können folgende Phasen
identifiziert werden, in welchen anschließend die angeführten Themen
bearbeitet werden können:
» Planung und Konzeption
» Umsetzung und Betrieb
Ziel
Erläuterung der Anforderung und des zu erreichenden Ziels
Auswirkung
Erläuterung möglicher Auswirkungen
Kontrollfragen
(Prio1)
Essentielle Fragen, welche vor der Umsetzung kritisch zu hinterfragen
sind
Kontrollfragen
optional (Prio2)
Weiterführende Fragen unterstützender Natur
ITGS
Maßnahmen
Maßnahmen aus den Maßnahmenkatalogen des ITGS. Die Details zu
den Maßnahmen können dem IT-Grundschutz entnommen werden.
Siehe: http://www.bsi.de/gshb
Umsetzungshinweis
An ausgewählten Stellen werden zur Verdeutlichung zusätzlich
Umsetzungsbeispiele benannt
Tabelle 1: Erläuterung der Tabellen
Seite 8
Neben der Zusammenfassung der Sicherheitsziele und ihren Auswirkungen
können durch die Beantwortung gezielter Kontrollfragen Verbesserungspotentiale sowie mögliche Risiken abgeleitet werden. Sie haben zum Ziel,
den erörterten Punkt abzurunden und abschließend einen kritischen Blick auf
das Thema zu ermöglichen. Sie sind jedoch nicht als abschließend zu
verstehen und sollten um die behörden- oder unternehmensinternen Anforderungen erweitert werden.
Kapitel 4.: Referenzen:
Benennung weiterführender Dokumentationen, die als Grundlage zur
Erstellung dieser Veröffentlichung genutzt wurden.
Kapitel 5.: Glossar:
Erläuterung der in diesem Dokument verwendeten Abkürzungen und Begriffe.
Anhang: Darstellung einer Matrix, welche im Überblick die Sicherheitsanforderungen
zusammenfasst, die in konkreten Prozessschritten des Incident Management
berücksichtigt werden sollten. Die Sicherheitsziele entsprechen dem ISO
17799 Standard und werden um korrespondierende Maßnahmen aus den ITGrundschutz Standards ergänzt.
Seite 9
2. Standards im IT-Service- und IT-Sicherheitsmanagement
Nachfolgend wird ein kurzer Überblick über die Grundkonzepte und
allgemeingültigen und in der Praxis anzutreffendnen Standards des
Sicherheitsmanagements gegeben, welche in dieser Studie heangezogen wurden.
die
IT-
Als Orientierungshilfe für den Umgang mit aktuellen Prozess-Standards werden die
Standards des IT-Service-Management und des IT-Sicherheitsmanagements in der
KBSt-Studie „Aktuelle Standards für die Gestaltung von IT-Prozessen“ ausführlicher
behandelt. Diese liefert einen Überblick über relevante Normen in der Prozess- und
Projektorganisation und verweist auf weiterführende Quellen.
2.1 ITIL und IT-Service Management
Ausgangspunkt für die Entwicklung der IT Infrastructure Library (ITIL) ist die Erkenntnis,
dass Behörden und Unternehmen zunehmend von IT abhängig sind. Die Steigerung der
Effizienz und Effektivität in den Prozessabläufen einerseits sowie die Erreichung der
gestellten Geschäftsanforderungen andererseits führt zunehmend zu Bedarf an
gesteuerten IT-Services.
So rückt das Management von IT-Services zunehmend ins Zentrum der taktischen und
operativen Steuerung der IT-Organisation.
ITIL beschreibt, wie Betriebsleistungen der IT-Organisation und die betroffene
Infrastruktur in IT-Services gebündelt und wie diese Services prozessorientiert gesteuert
und unterstützt werden. Da die Qualität der IT-Services meist in verschiedenen
Verantwortungsbereichen der IT beeinflußt wird, ziehen sich diese Prozesse durch die
gesamte IT-Organisation. Damit wird sichergestellt, dass allen Beteiligten das
gemeinsame Serviceziel bewußt wird und sich ihre Aktivitäten daran ausrichten.
Auf Grundlage der ITIL-Best-Practices entstand der BS15000-Standard für das ITService-Management, der erstmals eine entsprechende Zertifizierung für ITOrganisationen ermöglicht. Inzwischen sind die Best Practices auch im ISO20000Standard normiert.
Dieses Dokument berücksichtigt das Incident Management (Störungsmanagement) als
einen der wesentlichen Service-Support-Management-Prozesse von ITIL.
2.3 Standards und Richtlinien im IT-Sicherheitsmanagement
2.3.1 IT-Grundschutz-Standards
Die BSI Standards des Bundesamtes für Sicherheit in der Informationstechnik (BSI)
liefern konkrete Richtlinien zur Etablierung eines IT-Sicherheitsmanagements. Sie
haben sich weit über die Behörden hinaus zu einem anerkannten Standard für die
Gewährleistung grundsätzlicher Sicherheitsanforderungen etabliert.
Die BSI-Standards bieten einerseits bewährte Empfehlungen und Lösungsvorschläge
und benennen andererseits Hilfsmittel für zahlreiche IT-Konfigurationen, um gängigen
Sicherheitsproblemen wirksam begegnen zu können:
» BSI-Standard 100-1: Managementsysteme für Informationssicherheit (ISMS)
Der vorliegende BSI-Standard definiert allgemeine Anforderungen an ein ISMS.
Seite 10
» BSI-Standard 100-2: IT-Grundschutz-Vorgehensweise
Die IT-Grundschutz Vorgehensweise beschreibt den schrittweisen Aufbau und Betrieb
eines IT-Sicherheitsmanagements in der Praxis. Er ist vollständig kompatibel zum
ISO Standard 27001 und berücksichtigt weiterhin die Empfehlungen der ISO
Standards 13335 und 17799.
» BSI-Standard 100-3: Risikoanalyse auf der Basis von IT-Grundschutz
Zur Abdeckung von Sicherheitsanforderungen, die über das normale Maß hinaus
gehen, hat das BSI einen Standard zur Risikoanalyse auf der Basis von ITGrundschutz erarbeitet. Diese Vorgehensweise ermöglicht den Behörden oder
Unternehmen eine zur IT-Grundschutzanalyse ergänzende Risikoanalyse, um die
erweiterten Anforderungen zu erfüllen.
Abbildung 1: Übersicht über BSI Publikationen zum IT-Sicherheitsmanagement
2.3.2 BS 7799/ ISO 17799:2005
In den Best Practices von ITIL wird das Betreiben eines IT-Sicherheitsmanagements als
unabdingbarer Bestandteil der IT-Organisation angesehen. Der britische Standard BS
7799
beschreibt
allgemein
gültige
Vorgaben
zum
Aufbau
eines
ITSicherheitsmanagements und basiert auf einem Best Practice Ansatz.
Der BS 7799 gliedert sich in zwei Teile:
Part 1: „Code of Practice for Information Security Management“ liefert einen Leitfaden
zum Management der Informationssicherheit mit Darstellung entsprechender
Maßnahmen
Seite 11
Part 2: „Information Security Management Systems - Specification with guidance for
use“ liefert Anforderungen an IT-Sicherheitsmanagementsysteme und damit als
Grundlage ein Raster zur Beurteilung für Zertifizierungen
Der Part 1 wurde in den ISO-Standard 17799 übernommen. Der im Jahr 2005
erschienene ISO 17799-2005 enthält eine wesentliche Neuerung im Vergleich zu ISO
17799-2000: der Standard wurde um einen elften Abschnitt erweitert, der sich
ausschließlich dem Thema „Information Security Incident Handling“ (Umgang mit
Sicherheitsvorfällen) widmet und die ursprünglich in anderen Abschnitten verstreuten
Anforderungen und Inhalte zum Umgang mit Sicherheitsvorfällen konsolidiert.
Der Inhalt des Part 2 des BS 7799 ist im Oktober 2005 als ISO 27001 verabschiedet
worden (siehe Kapitel 2.3.3 ISO 27001).
2.3.3 ISO 27001
Der ISO Standard 27001 "Information technology - Security techniques - Information
security management systems requirements specification" ist der erste internationale
Standard zum IT-Sicherheitsmanagement, der auch eine Zertifizierung ermöglicht.
Obwohl er der direkte Nachfolger des zweiten Teiles des BS 7799 Standards ist, enthält
er jedoch im Vergleich zu seinem Vorgänger in folgenden Bereichen wesentliche
Neuerungen:
» Management von Sicherheitsvorfällen
» Sicherheit bei Personaleinsatz sowie
» Management von Sicherheitslücken (Vulnerability Management).
Der Standard spezifiziert die Anforderungen an
• Herstellung,
• Einführung,
• Betrieb,
• Überwachung,
• Wartung und
• Verbesserung
eines dokumentierten ISMS unter Berücksichtigung der Risiken innerhalb der gesamten
Institution.
Seite 12
3. Zusammenspiel von Incident Management und ITSicherheit
Im Folgenden werden Integrationsaspekte in den jeweiligen Prozessschritten des
Incident Management hinsichtlich Abhängigkeiten und Synergien zum ITSicherheitsmanagement aufgezeigt.
Mit der Gegenüberstellung der beiden Themenbereiche werden die Zusammenhänge
zwischen ITIL und den korrespondierenden Sicherheitszielen des ISO 17799 Standards
sowie der IT-Grundschutz-Kataloge (GSK) des BSI dargestellt. Damit werden
Anforderungen aus dem Blickwinkel des Incident Management einerseits und der ITSicherheit andererseits identifiziert und miteinander verknüpft.
3.1 Der Service Desk im Incident Management
Der Service Desk spielt eine wichtige Rolle, um eine zeitnahe Unterstützung für den
Anwender zu gewährleisten. So fungiert der Service Desk als die zentrale Anlaufstelle
der IT-Organisation (Single Point of Contact) für alle Anfragen der Anwender und
garantiert die schnelle und zuverlässige Bearbeitung. Im Service Desk wird ermittelt, ob
es sich um eine Störungsmeldung oder eine Serviceanfrage handelt. Dementsprechend
wird die weitere Bearbeitung des Vorgangs gesteuert. Dem Anwender bleibt die Suche
nach einer kompetenten und zuständigen Person erspart, die ihm bei der Lösung seiner
Probleme und Anfragen behilflich sein kann.
Im Gegensatz zu den Servicemanagement-Prozessen in ITIL stellt der Service Desk
keinen eigentlichen Prozess dar, sondern eine Funktion, die eine Schnittstelle zwischen
Anwendern und IT-Organisation bildet und hier verschiedene Prozesse abwickelt.
Je nach Aufgabenstellung ist der Service Desk in folgende ITIL-Prozesse involviert:
» Incident Management: dies ist wohl der wichtigste Prozess, in den der Service Desk
involviert ist. Üblicherweise ist bereits die erste Ebene (1st Level Support) des
Incident Management im Service Desk verankert. Dort werden die Störungen
aufgenommen, wenn möglich gelöst oder an die nächste Support-Ebene (2nd, nLevel) weitergeleitet.
» Configuration Management: während der Erfassung einer Anfrage oder Störung
verifiziert der Service Desk die Daten des Anwenders und der betroffenen ITKomponenten in der zentralen Configuration Database (nach ITIL: CMDB)
» Change Management: der Service Desk nimmt Änderungsanträge der Anwender auf
und kann mitunter selbständig standardisierte Aufträge bearbeiten.
» Service Level Management: der Service Desk kann einerseits die Anwender über
neue Produkte und Services informieren; andererseits kontaktiert er das Service
Level Management bei Anfragen und Beschwerden, die in die Definition veränderter
Service-Anforderungen einfließen.
» Darüber hinaus kann der Service Desk für operative Betriebsprozesse wie z.B.
Installation von Soft- und Hardware eingesetzt werden. In diesem Fall würde er das
Release Management in der Roll-Ort-Phase unterstützen.
Seite 13
ConfigurationManagement
Incident-
Change-
Management
Management
Service
Desk
Release-
Service-Level-
Management
Management
Abbildung 2: Prozesse im Service Desk
In dieser Dokumentation wird nur auf die Aufgaben des Service Desk im Rahmen des
Incident
Management
eingegangen.
In
den
darüber
hinaus
geplanten
Veröffentlichungen werden die in den anderen ITIL-Prozessen relevanten Tätigkeiten
des Service Desk mit behandelt.
3.2 Incident Management
Umfang und Ziele:
Das Incident Management hat zur Aufgabe, alle Meldungen von Störungen (englisch:
Incidents) sowie Anfragen und Aufträge seitens der Anwender entgegenzunehmen, um
die Anwender in ihrer Arbeit zu unterstützen.
Auch IT-Sicherheitsvorfälle (Security Incidents) gelten als Störungen, da hierdurch die
Verfügbarkeit, Integrität oder Vertraulichkeit der in den IT-Services verarbeiteten
Informationen beeinträchtigt werden und damit entsprechende Schäden in den
Geschäftsfunktionen verursacht werden können.
Service-Störungen können auch Folge unerkannter Sicherheitsvorfälle sein. Dies ist z.B.
der Fall, wenn der Sicherheitsvorfall mit Angriffen verbunden ist, die Schwachstellen
nutzen, um IT-Services gezielt zu destabilisieren. Mitunter werden diese
Sicherheitsvorfälle erst über ihre Wirkung in Form eingetretener Störungen erkannt.
Wenn die Destabilisierung der IT-Services das eigentliche Ziel eines Angriffs ist, spricht
man auch von Denial-of-Service-Attacken (DoS).
Ebenso können durch IT-Störungen auch neue Sicherheitslücken verursacht werden,
wenn z.B. Sicherheitsmechanismen durch instabile Systeme oder notwendige
Umgehungslösungen außer Kraft gesetzt werden.
Seite 14
Servicebeeinträchtigungen und Sicherheitsvorfälle können also jeweils sowohl Ursache
als auch Wirkung sein. Deshalb müssen sollten diese im Zusammenhang betrachtet
und behandelt werden.
In der Praxis bieten sich zwei Möglichkeiten für die Meldung von Sicherheitsvorfällen:
1. Alle Störungen (inkl. der Sicherheitsvorfälle) werden über die zentrale
Störungsannahme, also üblicherweise über den Service Desk im 1st Level des
Incident Management gemeldet.
2. Sicherheitsvorfälle werden über eine separate Meldestelle bei einem dedizierten
Ansprechpartner gemeldet.
Beide Alternativen bieten folgende Vor- und Nachteile:
Zentrale Störungsannahme für alle
Störungen
Separate Störungsannahme für
Sicherheitsvorfälle
Anwender sind nicht in der Lage,
eine Störung als sicherheitsrelevant
einzustufen
FÜR
WIDER
IT-Sicherheitsmanagement nutzt
bereits vorhandene Infrastruktur und
Prozesse im IT-Service-Management
FÜR
WIDER
Sicherheitsvorfälle werden ebenfalls
in einer zentralen DB verwaltet 1 2
FÜR
WIDER
Sensible Sachverhalte könnten trotz
aller Vorkehrungen zum sensiblen
Umgang unerwünscht an die
Öffentlichkeit gelangen
WIDER
FÜR
Tabelle 2: Störungsannahme für Sicherheitsvorfälle
Das primäre Ziel im Incident Management ist, Störungen schnellstmöglich zu beheben
und den vereinbarten Service wiederherzustellen, um negative Auswirkungen auf
Geschäftsprozesse so gering wie möglich zu halten.
Wie die Übersicht oben zeigt, könnte jedoch die Vorgehensweise bei
Sicherheitsvorfällen eine andere sein, da in diesem Fall andere Prozessanforderungen
zu berücksichtigen sind. Dies kann die vertrauliche Behandlung von
Sicherheitsstörungen, notwendige forensische Analysen, die Veranlassung der
Täterverfolgung u.a. Aspekte betreffen.
1
Die zentrale Verwaltung in einer gemeinsamen DB wäre möglich, wenn mit strenger Authentisierung
gearbeitet wird und das Werkzeug eine hinreichend differenzierte Berechtigungsverwaltung erlaubt. In der
Praxis stößt man hier derzeit jedoch noch schnell an praktische Grenzen der Umsetzbarkeit.
2
Ausnahme: Sicherheitsvorfälle, die gegen Sicherheitsrichtlinien verstoßen und gesondert behandelt
werden müssen (z. B. interne Angriffe)
Seite 15
Daher lässt sich hier keine pauschale Aussage treffen, über welche Kanäle die
Sicherheitsvorfälle gemeldet werden sollten. Die Entscheidung muss auf jeden Fall auf
die Anforderungen der Behörde bzw. des Unternehmens abgestimmt sein.
Unumstritten ist jedoch, dass dafür eine klare Vorgehensweise definiert sein und sie
allen Mitarbeitern der Behörde oder des Unternehmens bekannt gemacht werden muss.
Die Chancen, Störungen und Sicherheitsvorfälle in einem umfassenden und
standardisierten Incident Management behandeln zu können, steigen, wenn die
nachfolgend beschriebenen Integrationsaspekte berücksichtigt werden.
Seite 16
Prozessübersicht:
Abbildung 3: Prozessübersicht Incident Management
Die Abbildung veranschaulicht die wesentlichen Prozessschritte im Incident
Management mit Ihren Aktivitäten. Die folgenden Kapitel beschreiben, welche
Integrationsaspekte hier hinterfragt werden sollten, um den Prozess auch an den
Anforderungen des IT-Sicherheitsmanagements auszurichten:
» Erkennen und Erfassen (Kapitel 3.2.2)
» Qualifizieren und Erstlösungsversuch (Kapitel 3.2.3)
» Analysieren und Lösung vorschlagen (Kapitel 3.2.4)
» Lösen und Service wiederherstellen (Kapitel 3.2.5)
» Überwachen und steuern (Kapitel 3.2.6)
» Abschließen (Kapitel 3.2.7)
Seite 17
3.2.1 Übergeordnete Anforderungen
Bevor eine zentrale Bearbeitung von Sicherheitsvorfällen in einem Incident Management
Prozess etabliert werden kann, sind im Vorfeld organisatorische Rahmenbedingungen
zu schaffen, Leitaussagen zu formulieren sowie konzeptionelle Vorgaben zu erarbeiten.
IT-Sicherheitsrichtlinie und Regelungen zur Behandlung von Sicherheitsvorfällen
Phase
Planung und Konzeption
Ziel
Eine Sicherheitsrichtlinie soll die Ziele und Rahmenbedingungen der ITSicherheitsstrategie festschreiben.
Der Umgang mit Sicherheitsvorfällen ist mit der Festlegung des Geltungsbereichs einer
Sicherheitsrichtlinie zu verabschieden und in konkreten Prozessregelungen zu
konkretisieren. Die Sicherheitsrichtlinie und die Regelungen zum Umgang mit
Sicherheitsvorfällen sind anschließend innerhalb der Behörde oder des Unternehmens
entsprechend zu kommunizieren und bereitzustellen.
In der Konzeptionsphase des Prozesses sind zu berücksichtigen:
• Festlegung von Verantwortlichkeiten bei Sicherheitsvorfällen
• Definition der Verhaltensregeln und Meldewege
o Aufnahme und Fortschrittsverfolgung aller Sicherheitsvorfälle im
Incident Management
o Kommunikationsschnittstellen zwischen Incident Management und ITSicherheitsmanagement
• Abstimmung der Eskalationsstrategie zwischen Incident Management und ITSicherheitsmanagement
• Festlegung von Prioritätsklassen für die Behandlung von Sicherheitsvorfällen
Pauschale Empfehlungen zur angemessenen Detailtiefe der Regelungen im Umgang
mit Sicherheitsvorfällen sind kaum sinnvoll. In der Regel sind die Festlegungen
detaillierter und konkreter, je reifer der Incident Management Prozess entwickelt ist, was
also mit den konkreten Gegebenheiten in der IT-Organisation zusammenhängt.
Auswirkung
Durch die Verankerung des Prozesses in den Regelungen zum Umgang mit
Sicherheitsvorfällen sowie mit den Rahmenbedingungen der Sicherheitsrichtlinie wird
sichergestellt, dass:
• Sicherheitsvorfälle bemerkt und an die entsprechende Stelle weitergeleitet werden
• bei einem Sicherheitsvorfall die notwendigen Maßnahmen kurzfristig ergriffen und
umgesetzt werden
• weitere direkt oder indirekt betroffene Stellen rechtzeitig benachrichtigt werden
• Überwachung des Prozesses zur Behandlung von Sicherheitsvorfällen stattfindet
Kontrollfragen
(Prio1)
• Gibt es eine von der Leitungsebene verabschiedete IT-Sicherheitsleitlinie?
• Unterstützt die Leitungsebene die Verankerung des Incident Management Prozesses
in der IT-Sicherheitsrichtlinie?
• Ist in der IT-Sicherheitsleitlinie der Umgang mit Sicherheitsvorfällen geregelt?
• Berücksichtigt diese auch Verhaltensregeln, Verantwortlichkeiten,
Eskalationsprozeduren?
• Wurde die Sicherheitsrichtlinie innerhalb der Behörde oder des Unternehmens
kommuniziert?
• Sind die Meldewege für Sicherheitsvorfälle in der Behörde oder im Unternehmen
allen Mitarbeitern bekannt?
• Ist die Sicherheitsrichtlinie zum Umgang mit Sicherheitsvorfällen dem 1st Level
Support (Service Desk) und den Mitarbeitern im IT-Betrieb bekannt?
• Sind die Prioritätsklassen und Eskalationsprozeduren für Sicherheitsvorfälle im 1st
Level Support bekannt?
Seite 18
• Sind die Aufgabenbereiche zum Umgang mit Sicherheitsvorfällen den
Sicherheitsexperten bekannt?
Kontrollfragen
optional
(Prio2)
• Finden regelmäßige Tests des Prozesses zur Behandlung von Sicherheitsvorfällen
statt?
• Wird der Prozess zur Behandlung von Sicherheitsvorfällen in der Sicherheitsrichtlinie
aktualisiert?
• Werden die Prioritätsklassen und Eskalationsprozeduren aktualisiert?
ITGS
Maßnahmen
M 1.92, M 2.192, M 2.193, M 6.58 – M 6.68, M 2.201
Umsetzungshinweis
Der zu definierende Umgang mit Sicherheitsvorfällen kann der Maßnahme M 6.58
(siehe http://www.bsi.de/gshb/deutsch/m/m06058.htm) entnommen werden.
Tabelle 3: IT-Sicherheitsrichtlinie und Umgang mit IT-Sicherheitsvorfällen
Input: Incident Management / IT-Sicherheitsmanagement
Rollen und Verantwortlichkeiten
Phase
Planung und Konzeption
Ziel
Durch das IT-Sicherheitsmanagement sind Rollen mit der Beschreibung der Aufgaben,
Kompetenzen und Verantwortlichkeiten zu identifizieren, die bei Sicherheitsvorfällen
(oder bei sicherheitsrelevanten Service-Anfragen) zu involvieren sind. Die Rollen sollten
folgende Aufgabenbereiche abdecken:
• Annahme und Bearbeitung des Sicherheitsvorfalls
• Untersuchung und Bewertung des Sicherheitsvorfalls
• Eskalation des Sicherheitsvorfalls an die Leitungsebene
Die Beschreibung der Rollen inkl. der zu verantwortenden Aufgabenbereiche sind im
Incident Management zu kommunizieren.
Auswirkung
Mit klar definierten Rollen und Verantwortlichkeiten werden redundante Arbeiten zur
Lösung der Sicherheitsvorfälle vermieden.
Kontrollfragen
(Prio1)
• Sind alle notwendigen Rollen für Sicherheitsvorfälle im Incident Management
bekannt, die für konkrete Arten von Bedrohungen zu informieren sind? (auch bei
Gefährdungen durch höhere Gewalt oder vermuteten vorsätzlichen Handlungen)
• Kennen die benannten Rollen ihren Aufgaben- und Verantwortlichkeitsbereich?
ITGS
Maßnahmen
M 6.59
Umsetzungshinweis
Die zu benennenden Rollen mit ihren Aufgabenbereichen und Verantwortlichkeiten
können der Maßnahme M 6.59 (siehe http://www.bsi.de/gshb/deutsch/m/m06059.htm)
entnommen werden.
Beispielhaft sollen genannt werden:
• IT-Sicherheitsbeauftragter:
•
Aufgabe: Entscheidungsfindung über Sicherheitsproblem oder -vorfall,
Untersuchung und Bewertung des Sicherheitsvorfalls, Auswahl und
Veranlassung der Umsetzung der notwendigen Maßnahmen, Eskalation an die
Geschäftsleitung
•
Kompetenz: Eskalation, Genehmigung von finanziellen und personellen
Ressourcen
• IT-Administrator:
•
Aufgabe: Entgegennahme der Aufgabe, die sicherheitsrelevante Störung zu
prüfen und zu beheben, ggf. Eskalation an die nächst höhere Support-Ebene
•
Kompetenz: Entscheidung, ob für die Lösung weitere Personen hinzuzuziehen
sind
Seite 19
Tabelle 4: Rollen und Verantwortlichkeiten
Input: Incident Management / IT-Sicherheitsmanagement
3.2.2 Incident erkennen und erfassen
Die Erfassung der von Anwendern gemeldeten Störungen erfolgt im Incident
Management im 1st Level Support . Damit ist der 1st Level Support von Beginn an in
den Bearbeitungszyklus der Störung involviert. Im IT-Betrieb festgestellte Störungen
werden i.d.R. durch die Administratoren der Systeme selbständig erfasst. Die
Störungen können also auf unterschiedliche Art und Weise erkannt und
entgegengenommen werden. Dies macht deutlich, warum ITIL klare
Prozessregelungen für die Steuerung der Störungsbearbeitung empfiehlt.
Auch Sicherheitsvorfälle können auf unterschiedlichen Wegen bekannt werden:
• Feststellung durch Benutzer: Dieser meldet die Störung, z. B. vermuteten oder
tatsächlichen Virenbefall
• Erkennung durch ein System:
o In der Systemüberwachung (Monitoring) wird bei Überschreitung eines
kritischen Grenzwertes ein Ereignis generiert und entweder als Störung
an ein Support-Team weitergeleitet oder automatisch an ein Incident
Management System übergeben.
o IDS (Intrusion Detection System) meldet z. B. eine „Hacking Attack“
oder einen Einbruch in einen Server
• Feststellung durch einen Mitarbeiter aus einer IT-Abteilung: dieser registriert
die Störung selbst im Störungserfassungssystem.
• Feststellung durch einen externen Partner
• Information durch Strafverfolgungsbehörden oder Presse
Achtung:
Bereits bei der Erfassung einer Störung im 1st Level Support könnten Indizien darauf
hindeuten, dass es sich um einen Sicherheitsvorfall handelt, ohne dass dies dem
Anwender bewusst ist. Das Incident Management - in diesem Fall der 1st Level
Support - sollte berücksichtigen, dass eine forensische Analyse des Vorfalls
notwendig sein könnte und die meldende Person entsprechend darauf hingewiesen
wird.
Erkennungs- und Registrierungsregeln
Phase
Konzeption und Planung / Umsetzung und Betrieb
Ziel
Zwischen dem IT-Sicherheitsmanagement und dem Incident Management sind
Erkennungs- und Registrierungsregeln sowie Detektionsmechanismen technischer und
organisatorischer Art für Sicherheitsvorfälle zu identifizieren und etablieren, über welche
sicherheitsrelevante Störungen erkannt und registriert werden können.
Erkennungs- und Registrierungsregeln leiten sich ab aus den durch die Kritikalität der
Geschäftsprozesse definierten Anforderungen an die IT-Ressourcen (IT-Infrastruktur,
IT-Anwendungen, Informationen, Human Ressources). Im Rahmen einer ITStrukturanalyse zur Erhebung von Informationen, Anwendungen und Systemen sowie
bei der Feststellung deren Schutzbedarf werden die hierzu relevanten Kriterien erhoben,
um danach die notwendigen Prozesse zur Analyse, Prävention oder Reaktion bei den
verantwortlichen Ansprechpartnern zielorientiert anstoßen zu können.
Seite 20
Der BSI-Standard 100-2 "IT-Grundschutz Vorgehensweise" liefert methodische
Grundlagen für die Aktivitäten zur "IT-Strukturanalyse" (Kapitel 4.1) und zur
"Schutzbedarfsfeststellung" (Kapitel 4.2 ).
Auswirkung
Durch klar definierte Erkennungs- und Registrierungsregeln erhöht sich die
Zuverlässigkeit der Feststellung, ob es sich um einen Sicherheitsvorfall handelt und
dementsprechend daraus die Reaktionsfähigkeit. Dies kann im deutlichen Maße durch
sowohl durch technische als auch durch organisatorische Detektionsmechanismen
unterstützt werden.
Kontrollfragen
(Prio1)
• Ist im Incident Management bekannt, welche Informationen bei Meldung eines
Sicherheitsvorfalls zu registrieren sind (sofern bereits bei der Meldung erkennbar ist,
dass es sich um einen Sicherheitsvorfall handelt)?
• Ist sichergestellt, dass die im IDS durch das IT-Sicherheitsmanagement erkannten
Sicherheitsvorfälle als Störung registriert werden und ist geregelt in welchen
Systemen diese erfasst werden?
• Gibt es ein Konzept für die Erkennung, Weiterleitung und Alarmierung beim Auftreten
von Sicherheitsvorfällen
• Werden die Detektionsmechanismen regelmäßig geprüft und bei Bedarf um neue
Muster aktualisiert?
ITGS
Maßnahmen
M 5.71, M 6.60, M 6.67
Umsetzungshinweis
Erkennung / Meldung durch Systeme:
• Mit der Anbindung eines Intrusion Detection Systems (IDS) werden
sicherheitsrelevante Ereignisse unmittelbar an das IT-Sicherheitsmanagement
gemeldet. Mittels der Konfiguration eines IDS kann die Bewertung eines Ereignisses
im Vorfeld durch das IDS vorgenommen und eine entsprechende Eskalation
ausgelöst werden. Wenn solche Sicherheitsvorfälle als Sicherheitsstörungen
angesehen werden, sollte erwogen werden, diese auch als Incidents durchgängig zu
behandeln und zu erfassen. In diesem Fall sollte dann auch eine automatische
Übergabe an das Incident Management sowie die Dokumentation und Steuerung
über das Support-Management-System in Erwägung gezogen werden.
• Nicht alle Sicherheitsvorfälle müssen als Störungen im Incident Management System
erfasst werden. Vertraulich zu behandelnde Vorfälle können in anderen Werkzeugen
registriert und verfolgt werden, wenn hier andere spezifische Prozesse greifen.
Tabelle 5: Erkennungs- und Registrierungsregeln
Input: Sicherheits-/Incident Management
Bewusstsein für IT-Sicherheit schaffen
Phase
Umsetzung und Betrieb
Ziel
Durch organisatorische Maßnahmen ist das Verständnis der Mitarbeiter für die ITSicherheit zu trainieren. Ziel ist es, Wissen über Sicherheitsrisiken und deren
Auswirkungen zu vermitteln, damit ein Bewusstsein entwickelt werden kann und
Sicherheitsvorfälle als solche erkannt und richtig gemeldet werden können, um
angemessen reagieren zu können.
Auswirkung
Durch die Verbesserung der Sicherheitskenntnisse der Mitarbeiter wird einerseits bei
den IT-Fachkräften die Kompetenz im richtigen Umgang mit Bedrohungen entwickelt,
die sie bei der Ausführung ihrer Fachaufgaben benötigen. Andererseits können die
Anwender ein besseres Verständnis für die Folgen eines Sicherheitsvorfalls entwickeln.
Bewusstes Handeln hilft, Schäden in folge von Sicherheitsvorfällen zu minimieren.
Kontrollfragen
(Prio1)
• Werden auch neue Mitarbeiter für alle relevanten IT-Sicherheitsmaßnahmen
sensibilisiert und wirksam geschult?
• Werden alle Mitarbeiter in den sicheren Umgang mit IT-Systemen eingewiesen?
• Ist den Mitarbeitern bekannt, wo und wie konkrete Sicherheitsvorfälle gemeldet
Seite 21
werden (Meldewege und Verhaltensregeln)?
• Werden den Mitarbeitern alle hausinternen Regelungen und Vorschriften zur ITSicherheit erläutert?
• Sind die Mitarbeiter in Notfallmaßnahmen eingewiesen worden?
• Sind die Ansprechpartner für Sicherheitsfragen in der Organisation bekannt?
Kontrollfragen
optional
(Prio2)
• Werden Informationsveranstaltungen in regelmäßigen Intervallen zu
Sicherheitsmaßnahmen angeboten?
• Werden die Veranstaltungen regelmäßig an die Gegebenheiten in der Behörde bzw.
im Unternehmen angepasst?
• Stehen Informationen über Auswirkungen früherer Sicherheitsvorfälle zur Verfügung
und werden diese für die Sensibilisierung genutzt?
ITGS
Maßnahmen
M 3.1, M 3.26, M 3.45, M 3.5
Umsetzungshinweis
Die Schärfung des Bewusstseins für die IT-Sicherheit ist ein fortwährender Lern- und
Motivationsprozess. Dieser kann durch folgende Aktivitäten unterstützt werden:
• Mail-Aktionen und Hinweise im Intranet über angebotene Veranstaltungen
• Integration von Sicherheitsthemen in abteilungsinterne Veranstaltungen
regelmäßiger Information über aktuelle Bedrohungen und Schwachstellen
mit
• Aufbau eines Kommunikationsforums, um Mitarbeiter zu ermutigen, aktuelle
Sicherheitsthemen zu diskutieren, Fragen zu stellen und auch auf bestehende
Sicherheitsprobleme hinzuweisen
• Regelmäßige Interviews ausgewählter Mitarbeitern zu IT-Sicherheitsaspekten
• Workshops, um Schwachstellen aufzudecken und passende Sicherheitsmaßnahmen
zu finden
Es ist nicht leicht, hierfür die Aufmerksamkeit der Anwender wie auch IT-Fachkräfte zu
gewinnen und kontinuierlich zu gewährleisten. Deshalb ist es wichtig, die Information im
richtigen Maß und in der richtigen Form durchzuführen. Die Akzeptanz solcher
Maßnahmen steigt, wenn die betroffenen Mitarbeiter praxisnah informiert werden. Das
heißt vor allem, dass vor allem aktuelle Sicherheitsfragen und die möglichen
Auswirkungen im konkreten Arbeitsumfeld der Mitarbeiter in den Mittelpunkt gestellt
werden sollten.
Tabelle 6: Bewusstsein für IT-Sicherheit schaffen
Input: IT-Sicherheitsmanagement
3.2.3 Incident qualifizieren und Erstlösungsversuch
Die Qualifizierung eines Sicherheitsvorfalls wird im wesentlichen durch die Kritikalität
des beeinträchtigten Geschäftsprozesses bestimmt, insofern spielen die
Anforderungen an Verfügbarkeit, Integrität und Vertraulichkeit aus Sicht der
Geschäftsprozesse eine zentrale Rolle für die Bestimmung der Anforderungen an den
angemessenen Umgang mit konkreten Incidents. Die Einschätzung für die
Priorisierung und Kategorisierung einer Störung sollte auf Grundlage einer im Vorfeld
durchgeführten Schutzbedarfsfeststellung und einer anschließenden Business Impact
Analyse stattfinden.
Ergänzende Informationen zu diesem Thema können auch der AKIS-Studie des BSI
entnommen werden, siehe http://www.bsi.bund.de/fachthem/kritis/acis_paper_d.pdf
Die Kritikalität der Geschäftsprozesse und deren Anforderungen an die ITRessourcen sollten in allen Support-Stufen des Incident Management bekannt sein.
Seite 22
Auch die Verantwortlichkeiten in der Bearbeitung von Sicherheitsvorfällen sowie
entsprechende Eskalationsstrategien sind bereits in der Konzeptions- und
Planungsphase zu definieren.
Um eine optimale Bearbeitung zu ermöglichen, wird jede Störung qualifiziert. Hierzu
werden Incidents nach vordefinierten Kriterien beurteilt. Folgende Punkte sind dabei
zu berücksichtigen:
•
Klassifizierung der Störung
•
Analyse der Auswirkungen und Dringlichkeit sowie Priorisierung der Störung
•
Vergabe des Status
Üblicherweise wird bereits im 1st Level Support der Versuch unternommen, die
gemeldete Störung zu beheben. Dabei sollte der meldende Anwender, wie bei allen
Incidents, nach den sichtbaren Auswirkungen der Störung sowie deren Beurteilung
befragt werden.
Wie für schwerwiegende IT-Störungen kann auch für konkrete Klassen von
Sicherheitsvorfällen die Eskalation sehr früh und auf den oberen Führungsebenen
greifen. So wird sichergestellt, dass notwendige Maßnahmen wie Verbot der
Informationsweitergabe, Einschaltung von Ermittlungsbehörden zum richtigen
Zeitpunkt initiiert und autorisiert werden.
Priorisierungsmatrix für Sicherheitsvorfälle
Phase
Planung und Konzeption
Ziel
Durch das IT-Sicherheitsmanagement sind möglichst im Vorfeld Prioritäten für die
Bearbeitung von Sicherheitsvorfällen festzulegen und im Incident Management zu
hinterlegen.
Dies sollte im Rahmen einer Schutzbedarfsfeststellung erfolgen, in der
Schadenskategorien mit wahrscheinlicher Schadenshöhe für die Geschäftsprozesse,
ihre Anwendungen, Systeme und Kommunikationsverbindungen festgestellt werden.
Die Ergebnisse werden in einer Priorisierungsmatrix verankert.
Hinweis:
Die vorab vorgenommene Prioritätensetzung bei einem Sicherheitsvorfall ist nur eine
erste Orientierung und kann nach genauer Bewertung des Vorfalls durch die nächste
Support-Ebene korrigiert werden.
Auswirkung
Mit einer vorab festgelegten Priorisierungsmatrix lässt sich die Reihenfolge der
abzuarbeitenden Sicherheitsvorfälle steuern und eine ordnungsgemäße Verteilung von
erforderlichen Ressourcen für Störungsbehebungen sicherstellen. Dies ist wichtig, weil
mitunter ein hohes Störungsaufkommen mit begrenzten IT-Ressourcen behoben
werden muss. Gerade hier ist eine systematische Steuerung über angemessene
Prioritäten unverzichtbar.
Kontrollfragen
(Prio1)
• Sind die Prioritätenklassen für Sicherheitsvorfälle mit der Behörden- bzw.
Unternehmensleitung abgestimmt und verabschiedet worden?
• Sind die Prioritätenklassen im Incident Management hinterlegt?
• Ist die Prioritätensetzung allen Entscheidungsträgern, welche in die Behandlung von
Sicherheitsvorfällen involviert sind, bekannt?
• Ist sichergestellt, dass die Priorisierungsmatrix bei Änderung der Anforderung
aktualisiert wird?
• Sind die Prioritäten für Sicherheitsvorfälle und andere dringliche Störungen in ITServices aufeinander abgestimmt und konsistent?
Seite 23
ITGS
Maßnahmen
M 6.62, M 6.63
Umsetzungshinweis
Ein Beispiel, wie die Prioritätenklassen durch Unterstützung einer
Schutzbedarfsfeststellung definiert werden können, kann der Maßnahme M 6.62 (siehe
http://www.bsi.de/gshb/deutsch/m/m06062.htm) der IT-Grundschutzkataloge
entnommenen werden und auf die Bedürfnisse der Behörde / des Unternehmens
abgeleitet werden.
ITIL empfiehlt konkrete Methoden für die Priorisierung von Incidents. Grundlage hierfür
ist die Bewertung der Auswirkungen und der Dringlichkeit einer Störungsklasse. Die
Bewertung wird i.d.R. im Rahmen einer Business Impact Analyse vorgenommen.
Sicherheitsstörungen und sonstige Incidents sollten hier im Zusammenhang und mit der
selben Methodik bewertet werden, um Durchgängigkeit und Konsistenz zu
gewährleisten. Dies bedeutet auch, dass die Analyse und Bewertung eine gemeinsame
Aufgabe von IT-Sicherheits- und Service-Management ist.
Tabelle 7: Priorisierungsmatrix für Sicherheitsvorfälle
Input: IT-Sicherheitsmanagement
Klassifizierung von Sicherheitsvorfällen
Phase
Planung und Konzeption
Ziel
Gemeinsam mit dem IT-Sicherheitsmanagement sind Klassen für Sicherheitsvorfälle zu
definieren. Diese sollten anschließend in die Klassenstruktur des Incident Management
aufgenommen werden.
Bei der Meldung eines Sicherheitsvorfalls ermöglicht dies eine schnelle und genaue
Einordnung und ermöglicht eine gezielte Auswertung der Sicherheitsvorfälle.
Hinweis:
Je differenzierter die Klassifizierung erfolgt, desto präziser sind die Steuerung der
Bearbeitung und die Auswertung dieser Störung möglich, aber umso aufwendiger sind
Abstimmung und Anwendung der Klassifizierung. Deshalb sollte die Klassenstruktur auf
ihre Wirksamkeit und Angemessenheit regelmäßig überprüft werden.
Die finale Klassifizierung kann sich von der gemeldeten Klassifizierung unterscheiden,
da durch die Benutzer üblicherweise bei der Meldung nur Symptome und nicht die
Ursache genannt werden.
Auswirkung
Die Klassifizierung ermöglicht eine gezielte Auswertung der Sicherheitsvorfälle – z. B. in
Bezug auf konkrete Bedrohungsarten. Dies wiederum ermöglicht die Ableitung
notwendiger Maßnahmen, um künftig dieser Bedrohung proaktiv entgegenwirken zu
können.
Gleichzeitig können auch konkrete Sicherheitsvorfälle spezifisch gesteuert werden.
Zusammen mit der Klassifizierung sollte die Störung mit weiteren Informationen
verknüpft werden:
» Betroffener Service
» Auswahl der richtigen Arbeitsgruppe zur Störungsbehebung
» Bekannte Fehler und Probleme – z.B. Sicherheitslücken in IT-Produkten und Konfigurationen
Kontrollfragen
(Prio1)
• Ist durch das IT-Sicherheitsmanagement im Incident Management kommuniziert
worden, wie Sicherheitsvorfälle zu klassifizieren sind?
• Wird die Klassifizierung auf ihre Aktualität überprüft?
• Wird regelmäßig überprüft, ob die Klassifikation korrekt angewendet wird?
Kontrollfragen
(Prio2)
• Gibt es im Incident Management ein Verfahren, mit dem neue, unbekannte Arten von
Bedrohungen behandelt werden?
• Erfolgen Auswertungen der Störungen auf Grundlage der vorgenommenen
Klassifikation?
Seite 24
ITGS
Maßnahmen
M 6.62, M 6.63
Umsetzungshinweis
Beispiele für Klassen sind:
• Störung
o Virenbefall
o Fehlfunktion im System
o Fehlfunktion in der Anwendung
o Zugriffs- / Zugangsverletzung
o Benutzerfehlverhalten, das zu Datenverlust oder sicherheitskritischer
Änderung von Systemparametern führt
o Hacking von Internet- oder Intranet-Servern
o Offenlegung vertraulicher Daten
o kriminelle Handlungen (etwa Einbruch, Diebstahl oder Erpressung mit ITBezug)
• Service-Anfrage
o Passwort Freischaltung
o Portfreischaltung auf der Firewall
Tabelle 8: Klassifizierung von Sicherheitsvorfällen
Input: IT-Sicherheitsmanagement
Verifizierung des Verdachts eines sicherheitsrelevanten Incident
Phase
Umsetzung und Betrieb
Ziel
Nach der Störungsregistrierung ist die Qualifizierung im Incident Management
vorzunehmen. Dies schließt wie oben beschrieben die Feststellung ein, dass es sich
möglicherweise um einen Sicherheitsvorfall handelt, dessen Priorisierung sowie dessen
Kategorisierung entsprechend Klassifikationsschema.
Die Erkennung kann durch aktuell vorgehaltene Checklisten mit Mustern von
Sicherheitsvorfällen (Szenarien) unterstützt werden. Bei nicht klaren, aber vermuteten
Sicherheitsangriffen ist das IT-Sicherheitsmanagement in jedem Fall zu involvieren.
Hinweis:
Die Checklisten werden vermutlich breitere Anwendung bei Mitarbeitern aus dem ITBetrieb finden (z.B. bei Systemadministratoren und Applikationsbetreuern), da diese in
der Lage sind, die Zusammenhänge der durch sie betreuten Systeme einzuschätzen.
Da es schwierig ist, diese Checklisten auf aktuellstem Stand vorzuhalten, sollte man
sich auf Muster konzentrieren, die formulierbar sind und regelmäßig auftreten sowie
sicherstellen, dass diese im Incident Management bekannt sind.
Auswirkung
Da mitunter Zusammenhänge zwischen Störung und Sicherheitsvorfällen schwer zu
erkennen sind, benötigt der 1st Level Support Unterstützung in der richtigen Bewertung.
Gelingt es, eine Störung frühzeitig als Sicherheitsvorfall einzustufen, so können die
betroffenen Bereiche zeitnah informiert, die notwendigen Maßnahmen umgehend
eingeleitet und somit die Schadenhöhe minimiert werden.
Kontrollfragen
(Prio1)
• Wurde im Incident Management eine aktuelle Checkliste mit Mustern von
Sicherheitsvorfällen / Szenarien durch das IT-Sicherheitsmanagement bereitgestellt?
• Wird die Checkliste kontinuierlich aktualisiert?
• Ist sichergestellt, dass die Checkliste den Mitarbeitern im Incident Management
bekannt ist und dort angewandt wird?
Kontrollfragen
(Prio2)
• Ist klar, in welchen Fällen die meldende Person auf eine notwendige
Spurensicherung (forensische Analyse) hinzuweisen ist? Æ z. B. System nicht
herunterfahren, Datei nicht löschen, etc.
Seite 25
ITGS
Maßnahmen
M 6.63
Umsetzungshinweis
Es sollte konkretisiert werden, welche Indizien auf vorsätzliches Herbeiführen der
Störung hindeuten können und ob die Störung besondere Auswirkungen auf die
Verfügbarkeits-, Integritäts- und Vertraulichkeitsanforderungen hat. Dazu siehe die
Maßnahme M 6.63 (http://www.bsi.de/gshb/deutsch/m/m06063.htm).
Tabelle 9: Verifizierung des Verdachts eines sicherheitsrelevanten Incident
Input: IT-Sicherheitsmanagement
3.2.4 Incident analysieren und Lösung vorschlagen
Mit Hilfe dieses Prozessschrittes im Incident Management wird kontrolliert, ob eine
ähnliche Störung bereits aufgetreten und dafür eine geeignete Lösung oder ein
Workaround vorhanden ist.
Da dieser Prozessschritt iterativen Charakter hat und die Störung unterschiedlichen
Support-Ebenen entsprechend ihrem fachlichen Wissen zur Analyse und Diagnose
zugewiesen werden kann, müssen die Rollen und Verantwortlichkeiten sowie der
Informationsfluss bereits im Vorfeld mit dem IT-Sicherheitsmanagement etabliert
worden sein.
Es erfolgt also ein Review des Incidents gegen:
a. Erfasste Probleme
b. Bekannte Fehler (Known Errors)
c. Geplante bzw. durchgeführte Änderungen in IT-Komponenten
Wird ein Workaround gefunden, so werden umgehend die erforderlichen
Umsetzungsmaßnahmen eingeleitet. Die Bereitstellung eines Workarounds hat zum
Ziel, den Benutzer in die Lage zu versetzen, den gestörten Service mindestens in
eingeschränkter Form wieder zu nutzen. Zusätzlich wird dadurch die Wirkung der
Störung auf die Geschäftsprozesse minimiert und mehr Zeit zur Bereitstellung einer
endgültigen Lösung gewonnen.
Details zur Abstimmung der zu involvierenden Rollen und Verantwortlichkeiten
zwischen dem Incident Management und IT-Sicherheitsmanagement können dem
Kapitel 3.2.1 „Übergeordnete Anforderungen“ entnommen werden.
Informationsbeschaffung über Sicherheitslücken des Systems
Phase
Umsetzung und Betrieb
Ziel
Informationen über bekannte Sicherheitsprobleme und Sicherheitslücken von ITSystemen und IT-Anwendungen sollen im 1st und 2nd Level Support verfügbar sein,
damit es möglich ist, Sicherheitsvorfälle mit diesen Problemen bzw. bekannten Fehlern
zu verknüpfen.
Solche Informationen werden in der Regel durch interne oder externe CERT (Computer
Emergency Response Teams) bereitgestellt.
Auswirkung
Durch die Zuordnung des Sicherheitsvorfalls zu einem Problem oder einem bekannten
Fehler, können auch angemessene Handlungsempfehlungen bereitgestellt werden.
Seite 26
Dies vereinfacht die Kommunikation zwischen dem IT-Sicherheitsmanagement und dem
Incident Management.
Außerdem können die eindeutig zugeordneten Sicherheitsvorfälle durch das ITSicherheitsmanagement gezielt ausgewertet werden.
Kontrollfragen
(Prio1)
• Stehen im Incident Management aktuelle Informationen über Sicherheitsprobleme
und Sicherheitslücken von IT-Systemen und IT-Anwendungen zur Verfügung?
• Ist geregelt in welchem Umfang diese Informationen proaktiv bereitgestellt und
aktualisiert werden?
• Werden zu den Informationen Handlungsanweisungen angeboten, auf die der 1stLevel-Support mit den betroffenen Anwendern zurückgreifen kann?
• Ist Ihre Organisation beim Warn- und Informationsdienst CERT-Bund des BSI
registriert? (siehe http://www.bsi.bund.de/certbund/infodienst/index.htm)
ITGS
Maßnahmen
M 2.35, M 6.63, M 6.64
Umsetzungshinweis
Es ist praktisch nicht möglich, die Fülle verfügbarer Informationen über bestehende
Sicherheitsprobleme in IT-Produkten und -Konfigurationen dem Support systematisch
zur Verfügung zu stellen. Deshalb sollten zumindest Sicherheitsprobleme und -lücken
dokumentiert werden, welche zu konkreten Sicherheitsvorfällen im eigenen Hause
geführt haben oder mit hoher Wahrscheinlichkeit führen könnten und die einen
signifikanten Schaden in kritischen Anwendungen verursachen können.
Gleichzeitig sollten vor allem die Sicherheitsprobleme dokumentiert werden, für welche
auch tatsächlich Symptome bekannt sind, die dem IT-Sicherheitsmanagement in der
konkreten Zuordnung und Bearbeitung helfen könnten.
Tabelle 10: Informationsbeschaffung über Sicherheitslücken des Systems
Input: IT-Sicherheitsmanagement
3.2.5 Incident lösen und Service wiederherstellen
Nachdem die Analyse der Störung erfolgreich abgeschlossen und eine Lösung
gefunden wurde, wird deren Umsetzung veranlasst. Sofern es sich nicht um eine
Trivialstörung handelte, die mittels bekannter Lösungen direkt im 1st Level Support
behoben werden konnte, wird dies aufgrund des erforderlichen Expertenwissens
üblicherweise im 2nd oder 3rd Level Support erfolgen,
Bei einem Sicherheitsvorfall erfolgt die Umsetzung der Lösung ggf. von dem
verantwortlichen Systemadministrator, dem Computer Emergency Response Team
(CERT), dem Hersteller des IT-Systems oder einem IT-Sicherheitsexperten (siehe
Maßnahme M 6.64, http://www.bsi.de/gshb/deutsch/m/m06064.htm der ITGrundschutzkataloge).
In diesem Prozess wird großer Wert auf die Dokumentation der eingeleiteten
Maßnahmen gelegt (Workaround, endgültige Lösung, KnowHow Träger), und die
Wissensdatenbank (Problem- und Lösungsdatenbank) entsprechend aktualisiert.
Sollte zur Umsetzung der Lösung ein Change Request (Änderungsantrag) notwendig
sein, so wird dieser beim Change Management (Änderungsmanagement) gestellt. In
diesem Fall bleibt der Sicherheitsvorfall offen, bis die Änderung erfolgreich
durchgeführt wurde. Üblicherweise greifen bei kritischen Sicherheitsvorfällen
besondere Change-Management-Szenarien (Emergency Changes), die eine
umgehende Lösung ermöglichen sollen.
Seite 27
Da gerade bei der Behebung der Störung externe Dienstleister involviert sein können,
ist auf klare Festlegungen zu achten, welche Informationen über den
Sicherheitsvorfall wem zugänglich gemacht werden dürfen.
Zugriff auf Incident Informationen
Phase
Konzeption und Planung
Ziel
Für die nutzungsberechtigten Personen (extern und intern) muss der Zugang zu und der
Umgang mit den Informationen aus einem Sicherheitsvorfall klar geregelt und
sichergestellt sein.
Auswirkung
Durch eine klare Regelung von Berechtigungen und einer strengen Authentisierung für
sicherheitsrelevante Informationen über Störungen kann die Manipulation der Daten
verhindert und ihre Integrität sichergestellt werden.
Unabhängig davon ist organisatorisch zu gewährleisten, dass eine unbefugte
Weitergabe dieser Daten unterbunden wird.
Kontrollfragen
(Prio1)
• Liegt im Incident Management eine Regelung vor, die festlegt, welche Informationen
bei Sicherheitsvorfällen wie und an wen weitergegeben werden dürfen?
• Ist im Incident Management geklärt, über welche Kommunikationskanäle die
sensiblen Informationen weitergegeben werden dürfen?
• Werden die Mitarbeiter regelmäßig auf den sorgfältigen Umgang mit Informationen
hingewiesen?
• Wird die Einhaltung dieser Regelung überprüft und auf Abweichungen reagiert?
ITGS
Maßnahmen
M 2.217, M 2.226, M 2.42
Umsetzungshinweis
Da zur Aufklärung und Lösung des Störungsvorfalls Fachexperten aus
unterschiedlichen Support Ebenen hinzugezogen werden - z. B. 2nd, 3rd Level
(organisationsexterne Unterstützung wie Hersteller, Berater), sollte in der Richtlinie für
die Zugriffs- / Zugangskontrolle festgehalten werden, wie mit sicherheitskritischen
Informationen umzugehen ist.
Hier sollte das IT-Sicherheitsmanagement in der Konzeptions- und Planungsphase
Informationen oder Daten mit höherem Schutzbedarf (oder falls sie besonderen
Restriktionen unterliegen) kategorisieren und das Incident Management informieren, an
wen, in welcher Form und über welches Medium die Daten weitergegeben dürfen.
Tabelle 11: Zugriff auf Incident Informationen (Konzeption und Planung)
Input: IT-Sicherheitsmanagement
Seite 28
3.2.6 Incidents überwachen und steuern
Die Überwachung der Störungsbearbeitung liegt im klassischen Sinne in der
Verantwortung des Service Desk im 1st Level Support, um eine durchgängige
Überwachung von Beginn an sicherstellen zu können. Der Verantwortliche für den
konkreten Incident im Service Desk muss den Fortschritt regelmäßig im Auge
behalten und ihn hinsichtlich der Einhaltung der vereinbarten Service Levels
überwachen.
Eine mögliche Regelung
folgendermaßen aussehen:
für
den
Umgang
mit
Sicherheitsvorfällen
könnte
» Sicherheitsvorfälle mit bekannten Umgehungen (work arounds) werden durch
den 1st Level Support des HelpDesk (Virenaufkommen, neue Signatur laden)
überwacht und gesteuert
» Bei Sicherheitsvorfällen mit erheblichen Auswirkungen oder durch vorsätzliche.
Handlungen
wird das Sicherheitsmanagement einbezogen, um die
besonderen Anforderungen an die notwendigen Maßnahmen erfüllen zu
können
Entwickeln sich aus Störungen Notfälle, so werden diese grundsätzlich durch das
Notfallmanagement ausgerufen und deren Bearbeitung im Notfallmanagement
gesteuert.
Hieraus wird deutlich, dass zwischen den beteiligten Managementdisziplinen
gemeinsame Eskalationsregeln festzulegen sind, die im konkreten Fall die
Zusammenarbeit regeln.
Festlegung der Eskalationsstrategie
Phase
Planung und Konzeption
Ziel
Damit die Sicherheitsstörungen ohne Zeitverluste nach der Erkennung und
Registrierung von den Verantwortlichen bearbeitet werden können, sind im Vorfeld
Eskalationsstrategien, -ansprechpartner und -wege zu definieren.
Es wird zwischen zwei Eskalationstypen unterschieden:
» Fachliche Eskalation: Die fachliche Eskalation wird eingeleitet, wenn für die
Erstlösung im 1st Level Support keine zutreffende Checkliste (Matching Szenario)
vorliegt oder das Matching Szenario im Eskalationsweg z.B. die Einbeziehung
weiterer notwendiger Kompetenzen vorsieht. Das IT-Sicherheitsmanagement sollte
regelmäßig nach den gleichen Bedingungen einbezogen werden, insbesondere
sollte bei vermuteten Sicherheitsvorfällen, bei denen im 1st Level Support kein
Matching Szenario vorliegt sofort in Richtung IT-Sicherheitsmanegment eskaliert
werden.
» Hierarchische Eskalation: Der Fall tritt ein, wenn
o neben den genannten Voraussetzungen absehbar ist, dass vereinbarte
Wiederherstellzeiten nicht eingehalten werden können
o oder aber im Verlauf der Bearbeitung Entscheidungen getroffen werden
müssen, die nicht in der Kompetenz der Bearbeiter liegen, z.B. weil
ƒ sicherheitskritische Geschäftsprozesse betroffen sind
ƒ Existenzbedrohende Schäden vermutet werden
ƒ kriminelle Handlungen vermutet werden,
ƒ folgenreiche Flächenstörungen oder Notfälle abzusehen sind, etc.
Es ist erforderlich, dass für die Planung der Eskalationsstrategie ebenfalls die
erwarteten Reaktionen und Aktivitäten der Eskalationsinstanz klar definiert werden und
Seite 29
die Eskalation nicht nur einen informativen Charakter erhält.
Auswirkung
Über die Regelung, unter welchen Bedingungen an welchen Empfänger welche Klasse
von Sicherheitsvorfall eskaliert wird, wird eine transparente und zügige Reaktion auf alle
wichtigen Sicherheitsvorfälle gewährleistet.
Kontrollfragen
(Prio1)
• Liegt dem 1st Level Support im Incident Management eine aktuelle Eskalationsmatrix
vor?
• Enthält die Eskalationsmatrix eindeutige Handlungsanweisungen, wer, auf welchem
Wege bei welcher Art von erkennbaren/ vermuteten Sicherheitsstörungen in welchem
Zeitraum zu involvieren ist?
• Ist auch geregelt, zu welchen Maßnahmen diese Eskalation führen und welche
Aktivitäten ausgelöst werden sollen?
• Wird das Eskalationsverfahren regelmäßig überprüft und ggf. aktualisiert?
ITGS
Maßnahmen
M 6.59, M 6.60, M 6.61, M 6.65
Umsetzungshinweis
Als Beispiel können die für die Umsetzung einer Eskalationsstrategie für
Sicherheitsvorfälle notwendigen Schritte der Maßnahme M 6.61 (siehe
http://www.bsi.de/gshb/deutsch/m/m06061.htm) der IT-Grundschutzkataloge
entnommenen werden und auf die Bedürfnisse der Behörde / des Unternehmens
abgeleitet werden.
Tabelle 12: Festlegung der Eskalationsstrategie
Input: IT-Sicherheitsmanagement
Notfallvorsorge / Notfalleintritt
Phase
Planung und Konzeption / Umsetzung und Betrieb
Ziel
Das Incident Management ist in die Lage zu versetzen, einen möglichen Notfall zu
erkennen und angemessen auf diese Situation zu reagieren. Dazu ist durch das ITSicherheitsmanagement im Rahmen der Erstellung eines Notfallvorsorgekonzeptes (in
der Konzeption- und Planungsphase) dem Incident Management :
» ein Alarmierungsplan bereitzustellen
» Regelungen zur Verantwortung im Notfall bereitzustellen,
» Kritische Schadensereignisse mit Handlungsanweisungen (z. B. Ausfall der
Datenfernübertragungseinrichtung, Ausfall der Klimaanlage) zu benennen
» Matrix mit kritischen IT-Systemen mit der Zuordnung zu IT-Komponenten,
Anwendungen und der tolerierbaren Ausfallzeit und sowie zu den
Prozessverantwortlichen (z. B. Großrechner, Systeme mit hohen
Verfügbarkeitsanforderungen) bereitzustellen.
Sollte während der Meldung einer Sicherheitsstörung festgestellt werden, dass es sich
um einen Notfall handelt, werden gemäß Alarmierungsplan Personen oder
Organisationseinheiten involviert.
Auswirkung
Mögliche Notfallsituationen werden in der Störungsbearbeitung als solche erkannt und
rechtzeitig an die Verantwortlichen eskaliert.
Kontrollfragen
(Prio1)
• Sind die Kriterien zur Erkennung eines Notfalls definiert und bekannt?
• Liegt dem Incident Management ein aktueller Alarmierungsplan vor?
• Sind noch alle im Alarmierungsplan genannten Personen Mitarbeiter der Behörde
bzw. des Unternehmens?
• Sind im Incident Management die Handlungsanweisungen klar, mit denen bei
Erkennung eines Notfalls zu reagieren ist?
• Sind die Aktivitäten des Notfallmanagements von denen des Incident Management
klar abgegrenzt?
Seite 30
ITGS
Maßnahmen
M 6.1, M 6.7, M 6.8, M 6.9
Umsetzungshinweis
Die Abgrenzung in der Verantwortung und die Eskalationswege sollten mit dem
Notfallmanager abgestimmt werden.
Nähere Informationen zum Aufbau eines Notfallmanagements können aus dem
Baustein http://www.bsi.de/gshb/deutsch/baust/b01003.htm der ITGrundschutzkataloge des BSI entnommen werden.
Tabelle 13: Notfallvorsorge
Input: IT-Sicherheitsmanagement
3.2.7 Incident abschließen
Im
Incident
Management
Prozess
übernimmt
üblicherweise
der
Incidentverantwortliche im Service Desk die Aufgabe, nach erfolgreicher Behebung
der Störung den Vorgang ordnungsgemäß abzuschließen. Dies kann auch
beinhalten, ein Feedback des Kunden einzuholen und die Wirksamkeit der Lösung zu
überprüfen. In jedem Fall wird aber geprüft, ob die Regelungen zur
Incidentbearbeitung eingehalten worden sind und der Vorgang angemessen
dokumentiert wurde.
Nach einem ordnungsgemäß durchgeführten Abschluss (und einer Auswertung) des
Vorfalls sollten Aussagen zu folgenden Aspekten möglich sein:
» Betroffenes System (Identifikationsnummern, etc.)
» Zeitpunkt der Meldung
» Beschreibung, inwiefern
eingeschränkt war
die
Nutzung
der
betroffenen
IT-Systeme
» Name des Verantwortlichen für die Behebung, ggf. weiterer Lösungsbeteiligter
» Reaktions- und Durchlaufzeit
» Zeitpunkt der Fehlerbehebung
» Bekanntheitsgrad des Meldewegs
» Wirksamkeit der Eskalationsstrategie
» Effektivität der Untersuchung
Dokumentationsregeln
Phase
Konzeption und Planung
Ziel
Zwischen Incident Management und IT-Sicherheitsmanagement sind die zu
dokumentierenden Inhalte eines Sicherheitsvorfalls zu definieren und in einer
Dokumentationsrichtlinie festzuhalten.
Das Incident Management hat dafür Sorge zu tragen, dass die benötigten Informationen
vor dem Abschluss der Störung gepflegt sind. Wird für bestimmte Sicherheitsvorfälle die
Incidentverantwortung dem IT-Sicherheitsmanagement zugeordnet, so gelten hier die
selben Qualitätssicherungsanforderungen.
Auswirkung
Durch die im Vorfeld geplanten Dokumentationsanforderungen kann ein Lerneffekt
erzielt werden. Oftmals lassen sich daraus Verbesserungen im Umgang mit
Sicherheitsvorfällen herausarbeiten oder Rückschlüsse auf die Wirksamkeit der
Maßnahmen und Regelungen ziehen.
Seite 31
Kontrollfragen
(Prio1)
• Existiert eine Dokumentationsrichtlinie, in welcher geregelt ist, welche Inhalte eines
Sicherheitsvorfalls in welchem Detaillierungsgrad zu dokumentieren ist?
ITGS
Maßnahmen
M 2.215, M 2.219, M 6.66
Umsetzungshinweis
Beispielhafte Inhalte zu Dokumentation eines Sicherheitsvorfalls können der Maßnahme
M 2.215 (siehe http://www.bsi.de/gshb/deutsch/m/m02215.htm) der ITGrundschutzkataloge entnommen werden.
Besonders bei Sicherheitsvorfällen sollte Wert auf folgende Aspekte gelegt werden:
• Ist definiert, ob im Rahmen der Dokumentation zusätzliche Daten, Informationen (z.
B. Protokolldateien, Auswertungen) zu dokumentieren sind?
• Formalisieren der Berichte über den Vorfall (so weit wie möglich)
• Zustimmung zum Bericht durch alle beteiligten Personen (besonders auch zur
Ursachenbeschreibung)
• Veranstalten von „Lessons Learned“ Meetings mit den betroffenen Fachabteilungen
oder Administratoren
• Erstellung einer Management Summary
• Ableitung von präventiven Maßnahmen
• Schließen der Sicherheitslücken und Überprüfen der Änderungen
• Sammeln von Beweisen, um mögliche Strafverfolgung veranlassen zu können (z. B.
Protokolldateien)
Letztendlich sollte nach der Auswertung des Sicherheitsvorfalls folgendes erreicht
werden:
• bessere Aussagen zu Eintrittswahrscheinlichkeiten
• Welche Schäden entstehen wirklich?
• Greifen die technischen und organisatorischen Maßnahmen?
• Wie hoch ist die Wiederholungsrate des gleichen Sicherheitsvorfalls?
• Sind die Investitionen in die Sicherheit richtig gesteuert?
Tabelle 14: Dokumentationsregeln
Input: IT-Sicherheitsmanagement
Seite 32
4. Referenzen
1. IT Service Management, eine Einführung, van Haren Publishing, V1.0 März 2002,
ISBN 9077212124
2. Service Support, Central Computer & Telecommunications Agency, June 14, 2000,
ISBN 0113300158
3. Qualitätsmanagement nach ISO 9001:2000, Michael Cassel, Hanser Verlag,
München
4. http://www.itsmf.net
5. http://www.exin.nl
6. A Manager’s Guide to Service Management, British Standards Institution, London,
ISBN 0580427641
7. BS ISO/IEC 17799:2005, Informationstechnik – Leitfaden zum Management von
Informationssicherheit, (Deutsche Übersetzung), British Standards Institution,
London
8. ISO/IEC FDIS 27001:2005, Information technology – Security techniques –
Information Security Management Systems – Requirements
9. http://www.bsi.de
Seite 33
5. Glossar
Begriff
Erklärung
AKIS
Analyse Kritischer Infrastruktursektoren
Siehe AKIS-Studie des BSI
(http://www.bsi.bund.de/fachthem/kritis/acis_paper_d.pdf )
Best Practice
Praktisch bewährte und wirtschaftliche Managementverfahren
und Prozeduren
BS
British Standard
CERT
Computer Emergency Response Team
Team von Sicherheitsexperten, die über das Fachwissen
verfügen, Sicherheitslücken zu ermitteln und zu beheben
CMDB
Configuration Management Database =
Konfigurationsmanagementdatenbank
Eine Datenbank, welche die Konfiguration eingesetzter ITBetriebsmittel und ihre Abhängigkeiten untereinander aufzeigt
und die im Rahmen des Change Management gepflegt wird.
Event
Ereignis, welches durch ein Überwachungssystem (z.B. IDS)
generiert wird, sobald definierte Schwellwerte überschritten
werden, die einen Normalbetrieb beschreiben und das somit zur
Erkennung möglicher Störungen genutzt werden kann.
GSK
Grundschutzkatalog
ITGS
IT-Grundschutz (Standard des Bundesamtes für Sicherheit in der
Informationstechnik)
Hacker
Angreifer auf IT-Systeme mit dem Ziel, Sicherheitsbarrieren zu
überwinden
ICT
Information and Communications Technology
IDS
Intrusion Detection System
Detektionsmechanismus zur Früherkennung von
Sicherheitsvorfällen (Angriffen, Systemeinbrüchen) in Netzen
und auf Systemen
Incident
Störung, Vorfall
Beschreibt Ereignisse, die die Nutzbarkeit eines IT-Service
unterbrechen oder beeinträchtigen.
Incident
Managment
Störungsmanagement = Aufnahme und schnellstmögliche
Behebung von Störungen
ISO
International Standards Organisation
Internationale Organisation für Normung
ITIL
Information Technology Infrastructure Library
Anerkannte Best Practice und Defacto-Standard für Gestaltung,
Implementierung und Management wesentlicher
Seite 34
Begriff
Erklärung
Steuerungsprozesse in der IT
IT-Service
Bereitstellung eines oder mehrer IT-Systeme incl. Benötigter
Leistungen der IT zur Unterstützung von Geschäftsprozessen.
ITSM
Information Technology Service Management
Zusammenfassung integrierter Managementdisziplinen zur
Steuerung und Unterstützung von IT-Services
Known Error
Bekannter Fehler
Bekannte Ursache eines Problems, das tatsächlich oder
potenziell Störungen in IT-Services verursacht
Prozessschritt
Teil eines Prozesses, der wiederum bestimmte
Prozessaktivitäten umfasst
Service Request
Service-Anfrage
Vorgänge an der Anwenderschnittstelle zur IT, die vom
Anwender ausgehen und in der IT zu bearbeiten sind. Hierbei
kann es sich um Fragen, Aufträge, Beschwerden u.a. Vorgänge
handeln, die in der Praxis von Störungsmeldungen abgegrenzt
werden.
SPOC
Single Point Of Contact
zentrale Stelle, welche alle Meldungen (Störungen, Anfragen)
entgegennimmt, qualifiziert und entsprechend kanalisiert.
Workaround
Umgehungslösung für ein bekanntes Problem.
Mit einem Workaround wird gewährleistet, dass der vereinbarte
Service mindestens in einer eingeschränkten Form wieder
nutzbar wird, bevor eine nachhaltige Lösung geschaffen werden
kann.
Tabelle 15: Glossar
Seite 35
Anhang
Die nachfolgende Matrix veranschaulicht die Aspekte der Integration von Incident Management und IT-Sicherheitsmanagement auf
Prozessschrittsebene. In dem jeweiligen Prozessschritt werden die korrespondierenden Sicherheitsziele des ISO17799 angeführt
und die dazugehörigen Maßnahmen aus den Grundschutzbausteinen der ITGS ergänzt.
Allgemein
Incident erkennen
und erfassen
Erläuterung:
Management (14)
Business Continuity
Information Security Incident
Management (13)
IT-Grundschutz Standards
Access Control (11)
Operations Management (10)
Communications and
Human Resources Security (8)
Asset Management (7)
Policy (5)
Security
ISO 17799:2005
X.X Grundschutzbaustein
M 0.00. Maßnahme
1.8 Behandlung von Sicherheitsvorfällen
M 6.60, M 6.61, M 6.62, M 6.58, M 6.59
X
X
(5.1.1)
(13.1.1)
1.0 IT-Sicherheitsmanagement
(13.2.1)
M 2.201, M 2.192, M 2.193
1.8 Behandlung von Sicherheitsvorfällen
X
X
X
(8.2.2)
(10.1.1)
(13.1.2)
M 5.71, M 6.60, M 6.67
1.2. Personal
M 3.1, M 3.26, M 3.45, M 3.5
Incident qualifizieren
und
1.8 Behandlung von Sicherheitsvorfällen
Seite 36
Erstlösungsversuch
X
X
X
(10.1.1)
(13.2.1)
(14.1.2)
Incident analysieren
und Lösung
vorschlagen
X
(13.2.1)
M 6.62, M 6.63
1.8 Behandlung von Sicherheitsvorfällen
M 6.63, M 6.64
1.9 Hard- und Software-Management
M 2.35
Incident lösen und
Service
wiederherstellen
1.9 Hard- und Software-Management
X
X
M 2.217, M 2.226
(6.2.1)
(13.2.1)
1.1 Organisation
M 2.42
1.8 Behandlung von Sicherheitsvorfällen
M 6.64
Incidents
überwachen und
steuern
X
X
X
(7.2.2)
(10.8.1)
(13.2.1)
1.8 Behandlung von Sicherheitsvorfällen
M 6.59, M 6.60, M 6.61, M 6.65
1.3 Notfallvorsorge-Konzept
M 6.1, M 6.7, M 6.8, M 6.9
Incident abschließen
1.8 Behandlung von Sicherheitsvorfällen
X
X
(7.2.2)
(13.2.2)
M 6.66
3.9 Hard- und Software-Management
M 2.215, M 2.219
Tabelle 16: Berührungspunkte Incident Management / IT-Sicherheitsmanagement
Seite 37
Zur Verdeutlichung hier ein Beispiel aus dem Prozessschritt „Incident
erkennen und erfassen“:
Incident erkennen und
erfassen
IT-Grundschutz Standards
Information Security
Incident Management
(13)
Communications and
Operations
Management (10)
Human Resources
Security (8)
ISO 17799
X
X
X
(8.2.2)
(10.1.1)
(13.1.2)
Erläuterung:
X.X Grundschutzbausteine
M 0.00. Maßnahme
1.8 Behandlung von
Sicherheitsvorfällen
M 6.60, M 6.67, M 5.71
1.2. Personal
M 3.5, M 3.1, M 3.45, M 3.26
In der Matrix werden in der oberen Zeile die Sicherheitsstandards benannt:
» Standard ISO 17799 (hellblau) mit Kennzeichnung des entsprechenden
Kapitels in Klammern
» IT-Grundschutz-Standards (grau)
In der linken Spalte werden die jeweiligen Prozessschritte des Incident
Management aufgelistet (in diesem Beispiel „Incident erkennen und
erfassen“)
In den Zellen der Matrix wird dargestellt, welche Sicherheitsziele aus ISO
17799 oder IT Grundschutz in den Regelungen zum Prozessschritt
berücksichtigt werden sollten.
So ist in dem o.g. Beispiel erkennbar, dass der Prozessschritt „Incident
erkennen und erfassen“ sicherheitsrelevante Berührungspunkte im ISO
17799 in folgenden Themen aufzeigt
» „Human Resources Security“ Kapitel 8.2.2
» „Communications and Operations Management” Kapitel 10.1.1
» “Informations Systems, Acquisition, Development. Maintenance“ Kapitel
12.1.2
Diese
lassen
sich
um
konkrete
Grundschutzbausteinen ergänzen:
Massnahmen
aus
den
» 1.8 Behandlung von Sicherheitsvorfällen mit den Maßnahme M 6.60, M
6.67, M 5.71
» 1.2. Personal mit den Maßnahmen M 3.5, M 3.1, M 3.45, M 3.26
Seite 38