Zusammenspiel ITSM mit ISMS
In den letzten Jahren haben sich in der IT unterschiedliche Frameworks und Prozessmodelle etabliert. Ab einer gewissen Unternehmensgrösse und Komplexität ist es heute üblich und notwendig ein IT Service Management (ITSM) zu nutzen. Massgebend für ITSM ist im operativen IT-Betrieb das ITIL Framework,welches den gesamten IT-Betrieb überspannt und die Themen Security und Riskmanagement aufführt. Der Fokus liegt hier jedoch auf dem gesamten IT-Betrieb und Security ist nur eines von vielen Themen. ITIL als Framework korrespondiert in vielen Punkten mit dem ISO 20000 Standard, der sich auch zertifizieren lässt. Der ISO 20000 Standardorientiert sich sehr stark an Prozessen, in der Form von Practices und Value Streams, die beschrieben und festgelegt werden.
Auf der anderen Seite haben sich im Bereich IT-Sicherheit, basierend auf Anforderungen unterschiedlicher Stakeholder innerhalb und ausserhalb des IT-Betriebs, «Information Management Security Systems» (ISMS) etabliert. Diese orientieren sich meist an der ISO 27001als Norm und an Best Practice Guides wie dem NIST Cyber Security Framework.Daraus abgeleitet werden Anforderungen in der Form von Controls, und als praktische Umsetzung wird idealerweise eine Cyber-Defense-Plattform etabliert, die von einem internen oder externen SOCbetrieben wird.
Es ist im Weiteren zu beachten, dass Organisationen in klassischen Strukturen oder «agile» in «DevOps» Teams arbeiten können. Dies kann die Umsetzung der Standards beeinflussen; schlussendlich müssen aber die Anforderungen eines ITSM oder eines ISMS trotzdem erfüllt werden. In der Praxis zeigt sich, dass «DevOps» und «Agile» andere Vor- und Nachteile und neue Risiken ergeben, die es zu adressieren gilt. Dies ist ein eigener Themenbereich, auf den wir an dieser Stelle nicht im Detail eingehen.
Für die praktische Lösung der Aufgaben und der Dokumentation der Aktivitäten werden unterschiedlichste Tools eingesetzt.
Tools sind nur Hilfsmittel, Ausgangslage sind die Prozesse
Gewisse technische Lösungen sind etabliert und gehören zum üblichen Standard. Dies sind typischerweise Monitoring und Ticketing im IT-Betrieb, Endpoint Detection und Response (EDR) sowie Security Information und Event Management (SIEM)im IT-Security Bereich. Diese Tools ermöglichen eine zielgerichtete und effektive Arbeit und sind jeweils Teil der gesamten Lösung.
Zu beachten ist, dass die Prozesse immer an erster Stelle stehen; sie sind den Tools vorgelagert beziehungsweise übergeordnet. Hier besteht vielfach ein noch grosses Potential, in dem erst Prozesse definiert werden, idealerweise angelehnt an bestehen und erprobte Frameworks, und diese dann ihre Abbildung in unterschiedlichen Tools finden sollen. Vielfach existieren die operativen Prozesse getrennt von den Prozessen des Security Managements. Aus unserer Erfahrung ist immer wieder zu prüfen, wie diese Prozesse integriert werden können. Insbesondere bei der Einführung neuer Cyber Defense Tools ist es wichtig, auch die Prozesse zu analysieren und bestehende IT-Betriebsprozesse um IT-Security-Elemente zu ergänzen. Wie bei «DevOps», wo Entwicklung und IT-Betrieb als Ganzes gesehen werden sollen, muss auch hier angestrebt werden, dass IT-Betrieb und Security Operations als Ganzes agieren können. Dies ist primär und prioritär auf der Prozessebene anzugehen. In einem weiteren Schritt können Tools integriert werden.
Identifikation von Stakeholdern
Innerhalb des gesamten Prozessframeworks gibt es unterschiedliche Personengruppen mit divergierenden Ansprüchen. Es ist wichtig diese Stakeholderzu identifizieren und in das Gesamtkonzept einzubeziehen, denn nur wenn die gesamten personellen Ressourcen genutzt werden können, wird das Optimum erreicht. Langfristig muss eine Sicherheitskultur etabliert werden, die von allen getragen wird. So wie die Qualität nicht nachträglich durch Tests in ein Produkt integriert werden kann, sondern bereits bei der Produktentwicklung berücksichtigt werden muss, verhält es sich auch mit der Sicherheit. Bereits bei der Konzeptentwicklung, beziehungsweise Integration müssen die IT-Sicherheitsaspekte beachtet werden. Nur so entstehen nachhaltig sichere Lösungen. Wir können mit frühzeitiger Beratung und Auditsbereits in der Anfangsphase entsprechende Unterstützung bieten, vorausgesetzt wir kennen die Stakeholder. Vielfach ist auch das Schaffen von Awareness hilfreich, wobei Awareness-Kampagnensehr wohl auch spezifisch auf IT-Abteilungen oder Development-Teams fokussieren können.
Prozessbeschreibung
Vorsicht vor zu komplexen Prozessen
Wenn wir uns über Prozesse und Tools unterhalten, ist immer auch zu berücksichtigen, wie Prozesse gestaltet werden sollen. Bei meiner Tätigkeit ̶ sowohl bei IT-Dienstleistern wie auch auf IT-Betreiberseite ̶ konnte ich immer wieder feststellen, dass an sich sehr professionell und umfassend definierte Prozesse daran gescheitert sind, dass sie im Tagesgeschäft nicht praktikabel waren. Ein klassisches Beispiel ist der Change Prozess, der bei vielen Unternehmen als ein relativ komplexer Prozess mit vielen Schritten und Attributen definiert ist. In der Praxis führt dies dazu, dass der Prozess nicht benutzt wird bzw. dass man Begründungen und Wege findet wie man den Prozess umgehen kann. Ich werde in einem separaten Blogartikel vertieft auf den Change Prozess und seine Signifikanz für die IT-Security eingehen. Kurz gesagt, Prozesse müssen so aufgebaut sein, dass sie auch genutzt werden. Dies ist meist mit einfachen Prozessen und einem anwenderfreundlichen und den Benutzer mit Automatismen unterstützenden Tool zu erreichen.
Risikomanagement ist Teil der Prozesslandschaft
Das Risikomanagement ist meist einer eigenen Abteilung oder Person zugeordnet, losgelöst von den operativen Prozessen. Vielfach wird themenübergreifend gearbeitet, da neben den IT-Risiken auch noch andere Risiko- und Compliance-Themenzu behandeln sind. Trotzdem sollte man Risikomanagement nicht komplett von operativen Aufgaben entkoppeln. Es ist so viel Awareness für das Thema «Risiko» schaffen, dass innerhalb der IT-Betriebs- und IT-Security-Prozesse Input für das Risikomanagement gegeben werden kann; d.h. Risiken werden identifiziert und zur Beurteilung an das Risikomanagement übergeben. Hierbei muss beachtet werden, dass Change- und Incident-Prozesse nicht blockiert oder verzögert werden, sondern dass weitergearbeitet wird unter Berücksichtigung der Risikobeurteilung.
Governance
Wo sind SOC und CISO/ISO in der Organisation angegliedert? Diese Frage beschäftigt IT-Organisationen und Verantwortliche immer wieder. Die Governance innerhalb der IT-Organisation muss beachtet werden. Soll das SOC eine Kontrollinstanz sein oder soll es unterstützend wirken? Je nach dem ist das SOC Teil der IT-Organisation oder separiert.
Zu welcher Instanz wird bei Vorkommnissen eskaliert, wer trifft schlussendlich die Entscheidungen? Angesichts der heutigen Relevanz der Governance ist klar, dass ein Information Security Officernicht ausreicht: der ISO muss als CISOim C-Level angesiedelt sein. Er braucht Unterstützung vom SOC und vom Riskmanagement sowie Akzeptanz im IT-Betrieb und in der Entwicklung, gleich wie Rückendeckung vom Management.
Wie kann terreActive Sie unterstützen?
Wir bieten über unseren SOC-Servicebaukastendiverse Module an, die auf den klassischen Grundleistungen eines alltäglichen SOC-Betriebs aufbauen. Es gibt Lösungen für dedizierte oder hybride SOC,wobei wir individuell auf Ihre evtl. schon bestehende Cyber-Defense-Plattform eingehen können. Dazu kommen ergänzende Baukastenelemente wie Reporting der KPSIs und regelmässige Beratungen in Steering Meetings, die auch den C-Level adressieren.
Zudem unterstützen wir unsere Kunden mit Workshopsum das Vorgehen planen, mit Tabletop-Exercises um die Planung zu validieren und mit Simulationen um die ganze Organisation «End to End» zu testen.
Im Weiteren kann unser Audit- und Consulting-TeamSie bei der Optimierung Ihrer Sicherheitsinfrastruktur und dem Aufbau der Cyber Resilienzunterstützen.
In den nächsten Blogartikeln werden wir auf einzelne Aspekte der Organisation eingehen. Unter anderem werden CMDB und typische Prozesse wie Incident, Change und Eskalation detailliert betrachtet.