ITIL (IT Infrastructure Library), die aus England stammende Sammlung praxiserprobter Verfahren für das IT-Service-Management (ITSM), hat sich längst als international akzeptierte Leitlinie etabliert. Vor dem Hintergrund strengerer gesetzlicher Regulierung von IT-Abläufen stößt ITIL bei Unternehmen aller Größen auf verstärktes Interesse. Vor diesem Hintergrund gilt es insbesondere, Best Practices à la ITIL mit strukturierten Prozessen im Sicherheitsmanagement unter einen Hut zu bringen.
Die international verbreiteten Best-Prac- tice-Empfehlungen von ITIL haben inzwischen Eingang in
renommierte Standards gefunden, so in die britische Norm BS 15.000 und in der Nachfolge auch in den
ISO/IEC-Standard 20.000. Eine entsprechende Richtlinie für das IT-Security-Management liegt als BS
7799 beziehungsweise ISO 17799 bereits länger vor. Auf dieses ISO-Dokument verweisen die
ITIL-Bücher wie auch ISO 20.000 in Sachen Sicherheit. Über den formalen Bezug hinaus ist
festzustellen: Die möglichst enge Verzahnung von IT-Service- und Security-Management ist in der
Praxis sinnvoll und oft sogar dringend notwendig – laut Branchenkennern aber häufig bestenfalls
ansatzweise umgesetzt.
ITIL-konformes ITSM weist eine deutliche Schnittmenge mit dem IT-Sicherheitsmanagement auf. Es
liefert in seinen beiden Kernbereichen Service-Support und Service-Delivery eine ganze Reihe von
Anknüpfungspunkten, an denen die Zusammenarbeit der Fachleute beider Disziplinen gefordert ist.
Der ITIL-Band "Service-Support" befasst sich mit dem Alltagsbetrieb der IT-Abteilung und ihres
Service-Desks, der bei ITIL als zentrale Schnittstelle zu den Anwendern vorgesehen ist. Die
Anwender heißen bei ITIL stets "Kunden", geht es doch um die strukturierte Bereitstellung von
IT-Services: IT als "Dienst" am Kunden – sei es seitens hausinterner oder externer Dienstleister.
Service-Support gliedert sich laut ITIL in die fünf Standarddisziplinen Störungs-, Problem-,
Konfigurations-, Veränderungs- und Versionsmanagement (im Original: Incident-, Problem-,
Configuration-, Change- und Release-Management).
Der Band "Service-Delivery" stellt die verlässliche, nachvollziehbare und letztlich auch
finanziell verrechenbare Lieferung dieser Dienste an die Kunden in den Mittelpunkt. Entsprechend
geht es hier um die Planung und Kontrolle der Dienstgütezusagen, die Sicherung der Verfügbarkeit
und der Kapazität der Infrastruktur, die Ausfallsicherheit der Services und schließlich die
Budgetierung und Verrechnung der Services. Die entsprechenden Disziplinen heißen bei ITIL
Service-Level-, Availability-, Capacity-, IT-Service-Continuity- und Financial-Management.
Der Themenblock Security-Management wurde der ITIL-Bibliothek nachträglich angegliedert. In der
grafischen Darstellung des ITIL-Aufbaus gemäß dem britischen ITIL-Herausgeber OGC (Office of
Government Commerce) wirkt das Security-Management auf den ersten Blick wie eine separate Insel. Im
IT-Alltag ist aber die möglichst engmaschige Verknüpfung mit dem IT-Service-Management mehr als
wünschenswert: Das White Paper "ITIL und Informationssicherheit" des Bundesamts für Sicherheit in
der Informationstechnik (BSI), erstellt vom Berliner Unternehmen Hisolutions, fordert hier,
isolierte Prozesse aufzugeben und stattdessen Sicherheits- und Service-Managementprozesse
miteinander zu verzahnen. Einer der "häufigsten Fehler in der IT-Sicherheit" sei es,
Überwachungsmechanismen und -systeme zum Beispiel für Intrusion Detection ohne Prozesseinbindung zu
etablieren.
Den ersten offensichtlichen Nexus zur Security liefert bereits die Disziplin, mit der zahlreiche
Unternehmen den ITIL-Einstieg in Angriff nehmen: das Incident-Management (Störungsbearbeitung).
Denn eine Verletzung der IT-Sicherheit ist zunächst eine Störung des regulären IT-Betriebs, die
Bearbeitung eines Security-Vorfalls eine mögliche Variante des Incident-Managementprozesses.
Der Service-Desk ist als zentrale Anlaufstelle für alle möglichen Anwenderbelange zuständig –
darunter neben Änderungsanforderungen (Change Requests) vor allem Störungsmeldungen. Bei einem
Incident ist oft zunächst unklar, ob er durch Sicherheitsmängel aufgetreten ist oder nicht. Zu den
Aufgaben des Service-Desks im Rahmen der sicherheitsrelevanten Prozesse zählen laut BSI:
die Annahme und Erfassung von Sicherheitsvorfällen,
die Feststellung von Flächenstörungen,
die Dokumentation der Incidents einschließlich deren Historie,
die Sensibilisierung der Anwender entsprechend der Security-Policy sowie
letztlich
die Alarmierung der Verantwortlichen bei möglichen Sicherheitsvorfällen.
"Möglich ist dies aber nur", so das BSI-Papier, "wenn das Sicherheitsmanagement die
Anwenderbetreuung in Zusammenarbeit mit dem Service-Desk organisiert und ihn entsprechend befähigt."
Von großer Bedeutung sei es, "dass die Verfahren zur Behebung von Sicherheitsstörungen nicht nur
technologiezentriert zu sehen sind, sondern im Servicezusammenhang wirksam werden müssen." Dass
hier erhebliche Konflikte lauern, zeigt der Fall der forensischen Analyse: Hier stehen die Aufgaben
des Incident-Managements, das ja gerade auf das schnelle Wiederherstellen des Regelbetriebs zielt,
in diametralem Gegensatz zur Zielsetzung des Security-Managements, Sicherheitslücken zu analysieren
und Spuren möglichst zu sichern.
"Die Vermeidung solcher Konflikte ist einer der Knackpunkte im IT-Service- und
-Security-Management", so Timo Kob, Leiter Informationssicherheit bei Hisolutions und Mitautor des
BSI-Papiers. "Hier ist das Management gefordert, bereits im Vorfeld die Prioritäten zu klären und
klare Aussagen zu treffen." In der Regel wünsche das Management die Gleichzeitigkeit von
Wiederanlauf des IT-Betriebs und Spurensicherung. "Dann muss ein Unternehmen eben mehr Technik
vorhalten" – zum Beispiel um via Imaging-Software schnell ein Abbild korrumpierter Systeme für die
forensische Analyse ziehen zu können, ohne die Wiederaufnahme des IT-Betriebs allzu lange zu
behindern.
Während beim Incident-Management die Interessen des ITSM- und des Security-Teams mitunter in
gegensätzliche Richtungen laufen, sind die Synergien bei der Anschlussdisziplin Problem-Management
offensichtlich. Ein "Problem" im ITIL-Sinn ist die Ursache eines oder mehrerer Incidents. Nicht nur
im Alltagssprachgebrauch, sondern auch gemäß der ITIL-Definition steht also fest: Jede
Sicherheitslücke ist ein Problem. Denn jede Lücke kann zu Beeinträchtigungen der IT-Infrastruktur
und damit der IT-Services führen. Das Problem-Management zielt auf die Analyse und damit Vermeidung
von Problemen zum Beispiel durch die Untersuchung wiederholt aufgetretener Störungen. Hier kann und
sollte sich das ITSM-Team auf die Sicherheitsspezialisten stützen, denn solche Analysen zählen zu
deren Kernkompetenz. Bei jedem auftretenden Problem gilt es laut BSI-Papier zu berücksichtigen, "
dass in der Problemanalyse häufig noch nicht bekannt ist, ob die Störungsursache mit
Sicherheitsproblemen verbunden ist. Ein Unternehmen muss also Prozesse definieren, wann und auf
welche Weise das Security-Team in das Problem-Management mit einzubeziehen ist. Die Ausgestaltung
dieses Zusammenspiels bleibt dabei jedem Unternehmen selbst überlassen. Wichtig ist aber auf jeden
Fall, bei ITIL-Projekten diese notwendige Kooperation a priori mit einzuplanen: "Bei der Einführung
eines ITIL-Prozesses sollte ein Unternehmen von Anfang an alle betroffenen Teams mit ins Boot holen"
, rät Sicherheitsexperte Kob. "Hier gilt es, besonders den jeweiligen wechselseitigen Nutzen ins
rechte Licht zu rücken. Denn von einer ITIL-Einführung profitiert das Systemmanagement ebenso wie
das Security-Team."
Bei anderen ITIL-Disziplinen ist die Schnittmenge zwischen ITSM und Security-Managment mitunter
nicht ganz so offensichtlich. Große Bedeutung kommt dabei dem Configuration-Management zu, also der
Bereitstellung einer umfassenden Informationsgrundlage über die IT-Bestandteile und deren
Zusammenhänge. Die CMDB (Configuration Management Database, Konfigurationsdatenbank) dient hier als
zentrale Sammelstelle (IT-Repository). Über eine reine Asset-Datenbank geht eine CMDB schon dadurch
hinaus, dass hier auch Informationen über die Beziehungen der einzelnen Configuration Items (CIs)
untereinander vorliegen sollen. Das BSI fordert, auch das Sicherheitsmanagement als CMDB-Benutzer
zu berücksichtigen. Dies bedeutet beispielsweise, den CIs Angaben zur Bedeutung für kritische
Prozesse und zur Risikoeinstufung beizufügen. Damit eignet sich die CMDB dann auch als verlässliche
Informationsquelle für Security Audits.
Soweit die Theorie – in der Praxis erweist es sich allerdings als sehr schwierig, die CMDB immer
auf dem aktuellen Stand zu halten. Die Anforderung, diese Datenbasis auch noch um
sicherheitsrelevante Faktoren zu erweitern, macht diese Arbeit noch ein gutes Stück komplizierter,
zumal sich Security-bezogene Parameter schnell ändern können. "Ein automatisierter Abgleich
zwischen CMDB und Security-Geräten wie IDS/IPS ist heute leider nicht üblich", warnt Kob von
Hisolutions. "Es besteht in der Praxis also durchaus das Risiko, dass die CMDB in Security-Fragen
schnell veraltet. Wünschenswert wäre, wenn in einem Unternehmen die CMDB zumindest für den
IT-Grundschutz verwendbar ist."
Die Kombination von IT-Service-Management und IT-Sicherheitsmanagement gemäß den Forderungen der
ITIL-Bücher und des BSI bietet eine sinnvolle Verwebung von Prozessen, die erst gemeinsam die
Geschäftsprozesse unterbrechungsfrei am Laufen halten können. Was im Text dieser Standards ganz
lapidar als Notwendigkeit dargestellt wird, kann sich im Alltag der IT-Abteilungen aber als sehr
komplex und aufwändig erweisen. Unternehmen sind also gut beraten, bereits bei der Konzeption der
hausinternen Anpassung der ITIL-Prozesse genau darauf zu achten, dass die IT- und Security-Teams
die an sie gestellten Anforderungen später im Alltagsbetrieb auch stemmen können.