Sicherheit gehört ins IT-Management

Kleiner Fehler, großer Schaden: Aufgrund von Ferienabwesenheit wurde in einem Finanzinstitut ein ungeprüfter Change eingespielt, der am Access System einige Konfigurationsparameter änderte. Wegen einer Sicherheitslücke in einer veralteten Software konnte außerdem ein noch aktiver Account eines früheren Administrators übernommen werden. So hat sich ein Angreifer weitere Zugriffsrechte verschafft und über längere Zeit sensible Kundendaten extrahiert.

Dieses Szenario ist zwar fiktiv, aber nicht unrealistisch. Zwar wird Security in den meisten Unternehmen als strategische Management-Aufgabe wahrgenommen und entsprechend "High-Level" behandelt. Die konkreten Sicherheits-Projekte werden jedoch häufig isoliert vom Betrieb als zusätzliche Layer aufgesetzt und nicht in die IT-Governance eingebunden. Cyberangriffe erfolgen aber nicht auf PowerPoint-Folien, sondern auf die meistens sehr kleinen Schwachstellen in der operativen Infrastruktur.

Vom CISO, der internen Revision oder dem Regulator getrieben, wird meist top-down ein Policy-Framework aufgebaut. Doch von oben veranlasste Vorgaben greifen selten bis in die betriebliche Realität. Was fehlt, ist die Rückmeldeschleife aus dem Betrieb. Damit ist nicht der regelmäßige Auditbericht gemeint, der als zusätzliches Kontrollinstrument seine Berechtigung hat. Es geht vielmehr um die Nutzung der vorhandenen Informationsquellen aus dem Service-Management.

Zwar führen viele Unternehmen Service-Management-Prozesse wie Change, Deployment und Incident sowie die entsprechenden Tools auf einem hohen Reifegrad nach ITIL ein oder lassen sich sogar nach ISO 20000 zertifizieren. Aber für das Risiko-Management werden diese Methoden meist nicht genutzt. Wenn Security als Qualitätsfaktor eines IT-Services verstanden wird, liegt die Integration in die Service-Management-Prozesse eigentlich auf der Hand.

In der Praxis könnte die Integration wie folgt aussehen: Aus den bestehenden Service-Management-Tools (wie CMDB – Configuration Management Data Base) werden Reports generiert, etwa zum aktuellen Stand aller Patches. Sind Systeme veraltet, veranlasst der zuständige Administrator die Aktualisierung. Dies geschieht im Rahmen des operativen Risiko-Managements respektive im "kleinen Risiko-Management-Kreislauf". Jede einzelne Abweichung soll und kann für sich allein nicht bis zum verantwortlichen Management durchdringen. Die Informationsflut wäre zu groß. Die Informationen müssen aggregiert werden und fließen erst bei Überschreitung eines definierten Schwellenwerts in den übergeordneten strategischen oder eben "großen"Risiko-Prozess ein.

Zum Beispiel könnte als Eskalationswert eine bestimmte Anzahl von Systemen mit veralteter Software sein, der Zustand einzelner kritischer Systeme oder Ähnliches. Die Schwellenwerte dienen einerseits als Input für den kontinuierlichen Verbesserungsprozess. Die Werte können aber gleichzeitig auch für die strategische Steuerung über den Risiko-Management-Prozess verwendet werden (siehe Grafik).

Dass eine Verknüpfung der verschiedenen Management-Systeme nicht immer ganz einfach ist, weiß Georges Mathis, CISO bei Reist Telecom: "Das Feintuning der Schwellenwerte ist knifflig. Es braucht genügend Informationstiefe, um eine Aussage zu machen, ohne jedoch das Management mit Details zu überfluten." Das Zürcher Unternehmen hat die Integration von IT-Service- und Security-Management bereits umgesetzt. Der Aufwand lohnt sich, meint Mathis, "da wir durch die ISO-20000-Zertifizierung bereits einen hohen Prozess-Reifegrad besitzen".

Durch die Verknüpfung der Prozesse des IT-Service- mit denen des Security-Managements sind die Schnittstellen und Verantwortlichkeiten klar definiert. Die beiden Disziplinen haben jedoch eine unterschiedliche Sicht auf die Risiko-Evaluierung und -Akzeptanz. Hier ist die Definition der Begriffe, das Aufzeigen von Gemeinsamkeiten und insbesondere die transparente Darstellung der unterschiedlichen Bedürfnisse wichtig. Nur so lassen sich allfällige Missverständnisse vermeiden.

Während aus Sicht der Security ein einzelner Prozess definiert ist, um Incidents zu bearbeiten, können im Service-Management gleich mehrere Prozesse (wie Change, Incident, Problem et cetera.) betroffen sein. Auch werden unterschiedliche Definitionen verwendet: Ist bei der IT-Security eine Abweichung von der Vorgabe ein "Security Incident", kann es beim Service-Management ein "Information Security Incident", "Known Error"oder ein "Problem" sein. Die unterschiedlichen Betrachtungsweisen zeigen folgende Beispiele auf:

Die Verknüpfung von IT-Service- und Security-Management reicht für sich alleine zwar nicht aus, um Cyberangriffe abzuwehren. Sie ist aber der tragende Grundpfeiler für ein nachhaltiges Verteidigungskonzept. Ein Aspekt, den viele Abwehrstrategien vernachlässigen. Meist wird zunächst in technische oder reaktive Maßnahmen investiert. Es macht sich auf PowerPoint-Folien eben besser, ein neues Projekt mit coolen Schlagwörtern wie APT (Advanced Persistent Threat), IDS (Intrusion Detection System), SIEM (Security Information and Event Management) zu starten, als bestehende Prozesse zu verschlanken. Schuld daran sind auch die Hersteller, die mit ihren Tools die Lösung aller Security-Probleme versprechen.

Ein erprobter und erfolgreicher Ansatz ist die Integration von Service-Management- und Security-System. So lassen sich Doppelspurigkeiten vermeiden, Kosten optimieren und durch verlässliche IT-Dienste die Glaubwürdigkeit bei den Kunden erhöhen. Erst wenn diese Hausaufgaben gemacht sind, können die auf Hochglanzfolien angepriesenen Sicherheits-Tools ihre Wirkung voll entfalten.