Informationssicherheitsmanagement - ISM Ablauf

Information Security Management – Ablauf

Ziele der Lektion

• Kennenlernen des Prozesses der Entwicklung eines Information Security Programs

• Kennenlernen des Prozesses der Umsetzung und kontinuierlichen Verbesserung eines Information Security Programs

• Einsatz der Konzepte und Bausteine in der laufenden Umsetzung des Information Security Programs

Process

Information Security Risk Management

NIST Risk Assessment Methode

Diese Risk Assessment Methode des US National Institute of Standards and Technology verfolgt ein definiertes Neun-Schritte-Modell, wie Abb. 2.1. zeigt. Ursprünglich ist es rein IT-orientiert, kann jedoch allgemein für Information Security angewandt werden. Die Schritte sind nacheinander durchzuführen, wobei Schritte 2, 3, 4 und 6 parallel nach Schritt 1 durchgeführt werden können. Wichtig ist es hier, der aufgestellten Methodik zu folgen und die erforderlichen Inputs zur Verfügung zu stellen [CIS10, S99].

NIS Risk Assessment Methode / Flowchart

Information Security Management

Angestrebten Security Status formulieren

Der definierte Zielzustand – ein „Snapshot“ der gewünschten Informationssicherheit – kann nicht über rein quantitative Begriffe ausgedrückt werden. Man bedient sich Frameworks, die eine strukturierte Herangehensweise ermöglichen. Hier sind die Frameworks CobiT, die speziell auf Security fokussierte ISO 2700x-Serie oder Messmetriken wie Capability Maturity Models oder Balanced Scorecard hilfreich einsetzbar. Dabei soll man sich das für die zu erreichenden Ziele passende Framework oder einzelne Aspekte wählen. Insbesondere gibt es auch verschiedene Arten von Enterprise Information Security Architectures, die im Wesentlichen die existierenden Organisationen, Rollen, Elemente und Beziehungen darstellen, die an der Ausführung der Geschäftsprozesse beteiligt sind. Die Taxonomie identifiziert, welche Prozesse von welchem Geschäftsprozess angewandt werden und bietet Möglichkeiten, wie diese Prozesse operativ ausgeführt und über welche Security Controls abgesichert werden können. Stellvertretend für diese Art von Frameworks sei das SABSA-Modell erwähnt [CIS10, S53ff, S61].

Die Sherwood Applied Business Security Architecture (c) Security Architecture Matrix

Eine Hauptkomponente in der Bestimmung des angestrebten Security Status ist der Risikoansatz des Unternehmens und dessen individueller Risikoappetit. Dieser stellt das akzeptierte Risiko dar. Der Kostenfaktor spielt hier eine wesentliche Rolle bei steigendem Level von risikominimierenden Maßnahmen. Es gilt nämlich, den optimalen Punkt zwischen den fallenden Kosten bei Verlusten und steigenden Kosten für Gegenmaßnahmen zu bestimmen. Hier muss also bestimmt werden, wieviel Investitionen in Information Security Maßnahmen sinnvoll und möglich sind, um so eine optimale Balance zwischen Kosten und Nutzen zu erreichen („so wenig wie möglich, so viel wie nötig“).

Für die Formulierung des angestrebten Zielzustands müssen zwei Begriffe näher erläutert werden. Die Annual Loss Expectancy (ALE) wird bestimmt durch den potentiellen Verlust mal der Eintrittswahrscheinlichkeit. Die Risikoakzeptanz kann über die Recovery Time Objective (RTO), ein Konzept aus dem Business Continuity Management, abgeleitet werden. Dies ist die Zeitspanne, die ein Business Process unterbrochen werden darf, ohne das Kerngeschäft zu gefährden [CIS10, S57].

Aktuellen Security Status bestimmen

Um den Ausgangspunkt für die Information Security Strategie bestimmen zu können, muss der aktuelle Status für Information Security definiert werden. Hierbei soll man sich denselben Methoden bedienen, die auch bei der Bestimmung des gewünschten Zielzustandes eingesetzt wurden. Nur so stellt man auch eine Vergleichbarkeit und die Überprüfung der Zielerreichung sicher, die für die anschließende Gap Analyse eine notwendige Grundvoraussetzung darstellt. Außerdem können über dieselben Methoden auch Security Baselines entwickelt werden, werden also jene Maßnahmen definiert, die den Mindestsicherheitslevel für Sicherheit festlegen.

Zusätzlich muss der aktuelle Risikostatus durch ein Risiko Assessment evaluiert werden. Risikoziele werden formuliert und dienen auch als Input für die Gap-Analyse. Durch regelmäßige Durchführung von Risiko Assessments können die Metriken entwickelt werden, um später die Fortschritte zu messen.

Eine Business Impact Analyse darf bei der Bestimmung des aktuellen Status nicht fehlen, um die kritischen Systeme und Prozesse miteinzubeziehen und dadurch ein Gesamtbild zu bekommen. Auf Basis der hier gewonnenen Informationen lässt sich eine kosteneffektive Information Security Strategie entwickeln [CIS10, S57f].

Information Security Strategie entwickeln

Eine Unternehmensstrategie kann gesehen werden als ein Entscheidungsmuster im Unternehmen, das Ziele und Zweck des Handelns definiert und repräsentiert. Sie bedient sich Policies und Plänen, definiert den Bereich des Kerngeschäfts, ihre Art der Organisation sowie die Art ihrer Beiträge für Shareholder, Mitarbeiter*innen, Kund*innen und Institutionen. Eine Information Security Strategie erweitert die oben genannte Definition um den Sicherheitsaspekt, woraus sich eine durchaus gute Arbeitsdefinition ergibt. Eine andere pragmatischere Definition von McKinsey besagt, dass Strategie ein kohärentes und sich entwickelndes Portfolio von Initiativen ist, welches den Shareholder Value und die Langzeitperformance des Unternehmens bestimmt. Das Management soll hier auch stark die Kultur in Form von Priorisierung und Initiierung von Initiativen „vorleben“, was sich in den Handlungen manifestiert und weniger an Visionen oder Mission Statements. Durch den Mix an Initiativen kann das Gesamtportfolio ausgewogener und feiner justiert werden als traditionellere starre Ansätze. Das Ziel einer Information Security Strategie ist jedenfalls das Erreichen eines vorab definierten angestrebten Zustandes, den das Business und die Sicherheitsrahmenbedingungen vorgeben. Letztlich geht es bei einer Information Security Strategie immer um eine Sicherstellung der Kernprozesse unabhängig von der speziellen Geschäftstätigkeit.

Der Startpunkt für Information Security Governance bildet das Aufsetzen der Information Security Strategie. Wie bei allen strategischen Überlegungen müssen zunächst der Gültigkeitsbereich (Scope), Verantwortungen sowie eine Grundsatzdefinition (Charter) klar formuliert und niedergeschrieben werden. Information Security betrifft alle Aspekte von Information, egal ob gesprochen, geschrieben, gedruckt, elektronisch oder auf einem anderen Medium gespeichert, über deren kompletten Lebenszyklus, also von der Generierung, über Anzeige, Transfer, Speicherung bis zur Löschung. Die Sicherstellung von Information Security muss über einen Qualitätssicherungsprozess erfolgen, der möglichst in die Prozesslandschaft integriert wird [CIS10, S42].

Es besteht allerdings die Gefahr, dass die Strategie rein von der Erfahrung aus der Vergangenheit abgeleitet wird, was zu kurz greift. Die Strategie bildet die Grundvoraussetzung für einen Aktionsplan, der wiederum aus ein oder mehreren Security Programs bestehen kann, welche an den Sicherheitszielen ausgerichtet sein sollen. Beide Elemente, Security Strategie und Aktionsplan, müssen bereits Vorgaben zu Monitoring und Metriken enthalten, um später überhaupt das Erreichen der Ziele verifizieren zu können. Erst dadurch können die/der CISO oder das Steering Committee bei Bedarf unmittelbar Korrekturen anbringen, um fehlgeleitete Security Initiativen wieder auf Plan zu bekommen [CIS10, S48f, S58].

Klassische negative Einflüsse bei der Entwicklung einer Information Security Strategie und insbesondere im Zusammenhang mit dem menschlichen Beurteilungsvermögen sollten vermieden werden. Diese Einflüsse können – hier grob zusammengefasst – sein [CIS10, S50]:

• ein übersteigertes Selbstvertrauen in das eigene Einschätzungsvermögen
• eine zu optimistische Prognose
• eine zuvor präsentierte Zahl beeinflusst die darauf folgende Abschätzung
• eine Neigung zum bekannten und gewohnten Status Quo
• das geistige (unterschiedliche) Kategorisieren der Herkunft, des Ortes und der Investition von Geld (Stichwort „strategisches Investment“)
• der Herdentrieb im Sinne des Versuchs, sich Bestätigung seines eigenen Handelns durch andere zu verschaffen
• eine gemeinsame falsche Übereinstimmung
• die Bestätigung der eigenen Meinung
• eine selektive und verklärende Erinnerung
• Gruppendenken

Die Strategie selbst wird durch die weiter oben vorgestellten Bausteine – soweit vorhanden – implementiert, wobei die festgestellten Rahmenbedingungen zu beachten sind.

Gap Analyse durchführen

Den Vergleich zwischen aktuellen und angestrebten Status von Information Security führt man im Rahmen einer Gap-Analyse durch. Dabei sollen die verschiedenen Bausteine der Information Security Strategie miteinander verglichen werden, also jede Steuerungsaktivität, jedes Risiko, jede Auswirkung. Eine Gap-Analyse sollte zumindest jährlich, besser öfter, wiederholt werden. Somit sind das Messen und das Setzen korrektiver Maßnahmen als Antwort auf sich ändernde Rahmenbedingungen möglich. Um einen strukturierten Zugang sicherzustellen, werden dieselben Methoden wie bei der Bestimmung der beiden Status angewandt [CIS10, S69].

Aktionsplan festlegen

Die Ergebnisse der Gap-Analyse und die daraus abgeleiteten Konsequenzen werden in einem Aktionsplan zusammengefasst. Der Aktionsplan ist im Wesentlichen ein Projektplan, der gemäß der Roadmap die Information Security Strategie implementiert. Es müssen Policies und Standards formuliert werden, um für den Aktionsplan Leitlinien vorzugeben. Insgesamt müssen diese Bausteine und der formulierte Aktionsplan zur Information Security Strategie in Beziehung stehen und darüber hinaus konsistent sein. Der Aktionsplan soll auch laufende Maßnahmen zu Awareness und Training inkludieren. Der Fortschritt bei der Durchführung soll auch messbar sein, weshalb im Rahmen des Aktionsplans auch Metriken entwickelt werden müssen. Da man den Aktionsplan als Projektplan sehen kann, werden die Arbeitspakete und Meilensteine entsprechend mit Zeiten und inhaltlichen Zielen hinterlegt [CIS10, S68ff].

Bei der Entwicklung eines Information Security Programs sind naturgemäß einige konzeptuelle Aktivitäten durchzuführen sowie allfällige Vorbereitungen für die Umsetzung zu initiieren. Es stellt gewissermaßen die Fortführung eines Risk Assessments dar und führt zur Formulierung einer Security Strategie, welche die zu behandelnden Risiken adressiert. Zusätzlich sollen die aus der Strategie destillierten Ziele an die organisatorischen Ziele des Unternehmens geknüpft werden. Das Information Security Program stellt also eine übergreifende Klammer dar, in der sämtliche Projekte, Initiativen, Aktivitäten für Information Security zusammengefasst werden. Im Rahmen der Entwicklung des Programs wird eine Infrastruktur für die Durchführung dieser Projekte, Initiativen, Aktivitäten geplant und geschaffen. Somit wird auch der Bogen vom Konzept zu operativen Zielen geschlagen [CIS10. S146].

Information Security Program strukturieren

Zunächst muss – wie bei eigentlich jedem Grundsatzdokument – ein Gültigkeitsbereich (Scope) und eine Grundsatzdefinition (Charter) formuliert werden. Die Aufgabe des Managements sollte in diesem Teil festgeschrieben werden. Gleich vorab müssen qualitätssichernde Funktionen integriert werden, die es erlauben, später die inhaltliche Erfüllung der Vorgaben bewerten zu können. Dazu müssen Risikomanagement, Qualitätssicherung, rechtliche Aspekte einfließen. Genau diese Vielschichtigkeit ist eine Herausforderung, weil sämtliche Aspekte People, Process, Products (Technologie) konsistent in dem Information Security Program zu berücksichtigen sind. Zudem sind die Elemente ständiger Veränderung unterworfen, also etwa laufende Veränderungen in der Organisation, den Verantwortungen oder den Funktionen. Auch müssen ineffektive Situationen aus dem Projektmanagement, Compliance Management, Strategie-Mankos, Fehler bei den Messmetriken oder allgemein den technischen Security-Zustand von Software erkannt und darauf reagiert werden können. Anschließend werden Ziele definiert, welche die Strategie in konkrete operative Zielsetzungen, Prozesse und technische Maßnahmen herunterbrechen, wobei das Heranziehen von wohldefinierten Security Architekturen hilfreich ist. Die Ziele können mitunter durch Gap-Analysen ausgehend von der aktuellen Ist-Situation formuliert und Prozesse und Konzepte zur Verringerung des ermittelten Deltas entwickelt werden. Da Ziele immer messbar sein sollen, sind in dieser Phase bereits Überlegungen zu MAGs anzustellen. Weiters ist das akzeptierte Risiko des betreffenden Unternehmens festzuhalten, da diese Auswirkungen auf sämtliche Aktivitäten des Information Security Programs haben. Diesem muss ein Business Case zugrunde liegen, sodass das verbleibende Risiko auch ökonomisch argumentiert werden kann. Der angestrebte Zielzustand von Information Security, dem eigentlichen ursächlichen Grund für die Entwicklung eines Information Security Programs, wird in einem folgenden Abschnitt dargelegt. Diese haben korrespondierende MAGs, die aber unterschiedlich kosten-, zeit- und aufwandsintensiv erreicht werden können. Die Eruierung des für das Unternehmen optimal erscheinenden Weges wird durch die Definition von MAPs erreicht. Sind die Ziele definiert, wird in einem nächsten Schritt eine Roadmap entwickelt, welche den grundsätzlichen Weg zur Zielerreichung vorgibt. Diese Grobplanung zeigt in einer folgenden Detailstufe die grundsätzlichen Aktivitäten zur geplanten Erfüllung eines spezifischen Ziels. Dabei werden das Ziel, der Gültigkeitsbereich, Beschränkungen, die Methodik sowie das angestrebte Ergebnis inklusive Kriterien für die Messung dokumentiert. Bereits hier müssen Rollen und Verantwortlichkeiten für die allgemeinen und abteilungsspezifischen Aktivitäten im Rahmen des Information Security Programs vergeben werden. Der Umgang mit Information und ihre Sicherheit sollen möglichst in allen Lebenszyklusphasen der Information definiert sein, wiewohl das schwierig zu realisieren ist. Auf Basis dieser Vorgaben können dann die einzelnen Projekte, Initiativen, Aktivitäten für Information Security abgeleitet und in einem Aktionsplan genauer geplant werden. Dieser konzentriert sich rein auf die Umsetzung der MAGs und MAPs. Die Erfahrungen damit fließen über eine Feedbackschleife schlussendlich wieder in die Weiterentwicklung des Information Security Programs [CIS10, S152ff].

Policy und Standard Compliance sicherstellen

Die Policies und Standards sollten alle wesentlichen Situationen im Zusammenhang mit dem Umgang mit Information beantworten. Durch eine mögliche Schichten- und Modulstruktur sollen sie auch flexibel erweiter- und adaptierbar sein, sodass auf neue Herausforderungen – etwa Prozess- oder Technologieänderungen – reagiert werden kann. Für die Standards gilt fürderhin, dass gleiche Aufgabenstellungen möglichst in gleicher Art und Weise realisiert werden sollen. Eine automatisierte Umsetzung der Standards vermindert die Fehleranfälligkeit. Klare Rollendefinitionen für Information Security in den einzelnen Organisationseinheiten müssen zugewiesen werden. Zusätzlich müssen diese Einzelelemente zu einem konsistenten Ganzen zusammengefasst werden. Etwaige Widersprüche müssen auf Einzelbasis und Risiko-/Nutzen-Faktoren basieren. [CIS10, S166].

Training und Schulung initiieren

Nicht nur Vorgaben, auch die proaktive Schulung der handelnden Personen muss bei der Entwicklung des Programs sichergestellt werden. Training und Schulung auf regelmäßiger Basis fördern die Awareness und Sensibilität der Mitarbeiter*innen im Umgang mit Information. Sie schaffen ein Bewusstsein, was im Zuge ihrer tagesgeschäftlichen Aktivitäten zu beachten ist [CIS10, S166f].

Steuerungsaktivitäten (Controls) planen

Zur Implementierung von einschlägigen Steuerungsaktivitäten können Frameworks, wie etwa COBIT oder ISO 2700x herangezogen werden. Anhand von Zielformulierungen wird der Rahmen dafür abgesteckt, wobei die konkrete Implementierung auf die Unternehmenssituation abgestimmt sein muss. Die/der Information Security Manager*in muss den Einsatz der Steuerungsaktivitäten – seien sie allgemein oder applikationsspezifisch – optimieren, sodass effektiv und effizient das Steuerungsziel erreicht werden kann [CIS10, S167].

Lebenszyklusintegration gewährleisten

Um Information Security über die gesamte Lebensdauer eines Services, eines Systems oder Applikation und einer Information sicherzustellen, müssen in den Vorgehensweisen für die Entwicklung und den Betrieb entsprechende sicherheitsrelevante Aktivitäten berücksichtigt werden. Insbesondere sind dabei das Projektmanagement und der Software Development Life Cycle (SDLC) zu adressieren. Diese Sicherheitsprozesse müssen integraler Bestandteil sein, insbesondere bei sich ständig ändernden Umwelten, technologisch wie auch organisatorisch. Im Sinne einer Produkt- oder Service-Evolution müssen für jede Lebensphase der Information Mechanismen existieren [CIS10, S168].

Im Rahmen des Prozesses geht es um die Implementierung des Managements eines Information Security Programs, die aus einer Vielzahl von nicht sequentiell zusammenhängenden Aktivitäten bestehen. Zuerst ist es wichtig, sich einen Überblick über den Wirkungsbereich, den „Scope“, sowie die Verantwortlichkeiten des Programs zu machen. Die bestehenden Strukturen, vorhandene Security-Funktionen müssen dabei erfasst und dokumentiert werden, sodass ein gegenseitiges gemeinsames Verständnis bei allen Beteiligten erreicht wird. Dabei müssen Widersprüche und Konflikte erkannt und möglichst bereinigt werden, in vielen Fällen ist es nur möglich, sich derer gewahr zu sein.

Policies und Standards überprüfen und aktualisieren

Policies sollten eher selten geändert werden, obschon man sie regelmäßig auf Aktualität überprüfen muss. Standards werden dagegen in der Regel etwas häufiger adaptiert und sind in vielen Fällen Änderungen in Technologien geschuldet. Viele Policies weisen unterschiedliche Hierarchiestufen auf, wobei die operativer formulierten häufiger Änderungen unterworfen sind. Jedenfalls muss es für den Ablauf des Reviews und der Anpassung vorgegebene Abläufe für Erweiterung, Adaptierung oder Streichungen geben. Es muss sichergestellt sein, dass alle betroffenen Stakeholder – eventuell durch Einbindung des Security Committees – in diesen Prozess eingebunden werden, sodass die neue Version entsprechend gemeinsam tragfähig bleibt. Die Verantwortung für Change Management trägt die/der Information Security Manager*in [CIS10, S220].

Security Management Metriken hinterfragen und überwachen

Eine wichtige andauernde Tätigkeit ist das Adaptieren der Metriken für das Information Security Program einerseits und das Gewinnen von Messinformationen andererseits. Metriken werden auf allen Ebenen strategisch/taktisch/operativ benötigt und richten sich an verschiedenes Zielpublikum. Dazu zählen sowohl organisatorische, prozessorientierte als auch insbesondere technische Metriken. Zusätzlich muss die Effektivität, also das korrekte Arbeiten des Programs, sichergestellt und damit verifiziert werden. Auch soll die Kosteneffektivität der eingesetzten Steuerungsaktivitäten regelmäßig hinterfragt werden. Als weiteren Aspekt muss man innerhalb der Metrik bestimmen können, was die Messung bedeutet und ab welchem Wert man zufrieden sein kann. Daher sind aussagekräftige MAPs zu definieren, die Schwellwerte zu nennen und den Wert mit einer qualitativen Aussage zu verknüpfen. Es gilt also, sämtliche Aspekte durch ausgeklügelte Metriken „auszuleuchten“, ständig deren Aussagekraft zu hinterfragen und regelmäßig Zahlen dafür zu akquirieren und zu bewerten. Ziel dieser Aktivität ist es, Änderungen, die sich auf Information Security auswirken, rasch zu erkennen und frühzeitig darauf – in welcher Art und Weise auch immer – reagieren zu können. Dabei muss auch immer die Messmethode und die zugrundeliegende Basisannahme evaluiert werden [CIS10, S221f].

Steuerungsaktivitäten testen und adaptieren

Änderungen in der Gesamtkonstellation stellen die bisherigen Aktivitäten in Frage und bedingen möglicherweise eine Änderung der Steuerungsaktivitäten, um diese zu schärfen, anzupassen, besser zu machen. Dazu muss ein formalisierter Change Management Prozess eingehalten werden. Eine nachfolgende sensible Beobachtungsphase, eventuelle Walkthroughs oder sogar Effektivitätstests erhöhen die Prozess-und Kontrollsicherheit [CIS10, S222].

Outsourcing und externe Service Provider steuern

Bei Auslagerungsszenarien ist immer Information Security betroffen, da dies mannigfaltige Risiken aufwirft. Der Verlust von Skills, Wissen, Transparenz von Abläufen, die veränderte formalisierte Zusammenarbeit, Kostenverrechnung, aber auch kulturelle und ethische Unterschiede müssen behandelt werden. Hinzu kommt die Kompatibilität des Internen Kontrollsystems (IKS) des Partners mit den eigenen Steuerungsaktivitäten. Alle Aspekte der Information müssen geregelt werden. Die Handhabung der Information soll jederzeit nachgewiesen werden können, was Anforderungen an die Protokollierung impliziert. Der Outsourcingpartner muss gesteuert und gemessen und im Sinne des Kunden seine Services weiterentwickeln. Der/dem Information Security Manager*in kommt hier eine besondere Treiberfunktion zu; sie/er muss die End-to-End-Sicht für die Risiken und die Informationssicherheit haben und muss demnach dem vom Dienstleister verantworteten Bereich in ihren/seinen Fokus miteinbeziehen. Das ist allerdings nur möglich, wenn bereits bei der Vertragsgestaltung – neben SLA-Bestimmungen und rechtlichen Regelungen – im Rahmen von Information Security dem Kunden das Recht eingeräumt wird, die Abläufe und Steuerungsaktivitäten zu auditieren, dem Dienstleister bestimmte Vorgaben hinsichtlich der Informationshandhabung (Klassifizierung, Zugriff, Veränderung, Datenschutz, Löschung) auferlegt werden. Die Anlehnung oder Einforderung von Qualitätsnachweisen, etwa ISO 2700x-Audits oder ISAE3402-Prüfungen ist ebenso ein probates Mittel zur Sicherstellung ordnungsgemäßen Umgangs mit Informationssicherheit. Ist der Dienstleister eine reine Black Box für den Kunden, sind Security Incidents vorprogrammiert [CIS10, S222ff].

Information Security in den System Development Life Cycle integrieren

Im Rahmen des Managements des Information Security Programs sollten Risiko- und Sicherheitsüberlegungen bereits in den System Development Life Cycle (SDLC) integriert werden, also komplett von den ersten Konzept-, Design- und Entwicklungstätigkeiten, über Produktivstellung bis zur End-of-Life-Stellung des Systems. Security Baselines sollten dafür definiert worden sein, die in das Konzept frühzeitig einbezogen werden. Die/der Information Security Manager*in soll als Person ebenso in das Entwicklungsprojekt einbezogen werden, damit diese ihre/seine Sicht und Aspekte einfließen lassen kann. Auch im Rahmen der Testphase ist ihr/sein Engagement sehr wichtig, die Sicherheitsmechanismen sollen so explizit verifiziert werden [CIS10, S224].

Informationssicherheit überwachen und kommunizieren

Im Rahmen des normalen betrieblichen Monitorings sollen zusätzlich sicherheitsrelevante Aspekte überwacht werden. Spezielle sicherheitsrelevante Ereignisse, wie etwa fehlgeschlagene Anmeldeversuche am System, Prozessfehler, ressourcenbedingte Fehler, Änderungen an der Systemkonfiguration – speziell bei Sicherheitsfunktionen, Aktivitäten mit Administrations-Accounts oder andere applikationsspezifische Plausibilitätsprüfungen sollen – wie andere betriebliche Aspekte – überwacht und gemäß Vorgaben eskaliert und bearbeitet werden. Spezielle Trendanalysen von sicherheitsrelevanten Ereignissen komplettieren diese Aktivität [CIS10, S224f].

Informationssicherheit dokumentieren

Die Erstellung und Wartung von sicherheitsrelevanter Dokumentation ist ebenso notwendig. Dazu gehören eine geforderte Schriftlichkeit für Policies, Standards, Guidelines, Abläufe, die Dokumentation der technischen Architektur und Infrastruktur, Applikationen, Datenflüsse, Schulungsdokumentation, Risikoanalysen und Risikomanagement-Dokumentation allgemein, Design-, Konfigurations- und Wartungsdokumentation von Security-Systemen, Betriebsdokumentation und Definition der Verantwortlichkeiten – eventuell in Form von RACI-Modell-Matrizen. Die Aufgabe des Dokumentierens muss genauso mit Verantwortlichkeiten hinterlegt werden, wie jede andere Prozessaktivität auch. Zu jedem Dokument sollte es eine/n Besitzer*in, eine Versionierung, eine Dokumentenhistorie und ein Erstellungs- und Freigabedatum geben. Die Dokumente sollen sich in das unternehmensweite Dokumentenmanagementsystem einfügen [CIS10, S225].

Qualitätssicherungsfunktion fördern

Information Security Aktivitäten bilden eine Qualitätssicherungsfunktion für Business Prozesse, weswegen diese in die normalen Abläufe des Geschäftsprozesses integriert werden sollen. Maßnahmen, wie die Einbeziehung der Business Owner in das Information Security Committee oder die Integration der Policies und Standards in die Organisation unterstützen diese Aktivität [CIS10, S225].

Nutzungsrichtlinien erstellen

Für die Breite der allgemeinen Nutzer*innen von Information soll eine Nutzungsrichtlinie zur Verfügung stehen, die sich auf die Policy stützt, aber darüber hinaus konkrete Verhaltensregeln formuliert. Dies umfasst Themen wie Internet- und Emailnutzung, Klassifizierung und Handhabung von sowie Zugriff auf Dokumente. Gerade für neue Mitarbeiter*innen ist eine derartige Formulierung der Rahmenbedingungen ein guter Einstieg in die Unternehmenskultur und hilft, sich ins Unternehmen einzufügen. Diese Nutzungsrichtlinie muss kommuniziert und von allen Mitarbeiter*innen bestätigt werden [CIS10, S225].

Verantwortlichkeiten zuweisen

Wie in jedem Prozess ist ein Schlüsselelement die Zuweisung von Verantwortlichkeiten. Es muss klar sein, wer was bis wann durchzuführen hat und welche Verantwortung sie/er trägt. Nicht selten resultieren Security Incidents aus nicht oder nicht ausreichend wahrgenommenen Verantwortlichkeiten. Es ist dabei sinnvoll, zwischen regelmäßigen und einmaligen Security-Aktivitäten zu unterscheiden. Bei der Zuweisung bedient man sich nicht expliziter Personen, sondern Rollen, die von Mitarbeiter*innen übernommen werden. Manchmal können auch ganze Abteilungen verantwortlich sein, was aber eine interne Organisation für die Aufgabenzuteilung notwendig macht [CIS10, S225f].

Eine weit verbreitete Darstellungsart ist das sogenannte RACI-Modell, bei der jede Aktivität in einem Prozess einer Rolle zugeordnet wird und diese verschiedene Verantwortlichkeitsausprägungen hat:

• R – Responsible: durchführungsverantwortlich
• A – Accountable: ergebnisverantwortlich
• C – Consulted: beratend
• I – Informed: informiert

Es existieren dafür noch eine Vielzahl von Varianten und Erweiterungen, wie etwa S- Sign off; autorisierend, das Grundmodell umfasst aber nur die oben genannten vier Ausprägungen von Verantwortlichkeiten.

Change Management Prozess einhalten

Jegliche Änderungen von – wie es in ITIL genannt wird – Configuration Items erfordern das Durchlaufen eines einheitlichen formalisierten Change Management Prozesses. In großen dezentralen Unternehmen ist dies mitunter schwierig, da mehrere Change Management Prozesse existieren. Wichtig ist die Einhaltung eines formalen Change Managements, damit Risiken, Prioritäten, Auswirkungen und Sicherheitsaspekte bei der Änderung hinreichend berücksichtigt, getestet und autorisiert werden. Vor allem bei sehr oft durchlaufenen Betriebsprozessen ist ein verlässliches Change Management unumgänglich. Sicherheitsfunktionen bei Systemen, die häufig Changes unterworfen sind, tendieren mit der Zeit eher dazu, weniger effektiv zu werden. Daher müssen Steuerungsaktivitäten und Gegenmaßnahmen für Information Security regelmäßig evaluiert und adaptiert werden [CIS10, S226].

Operative Security Information Aktivitäten durchführen

Die tägliche Arbeit der/des Information Security Manager*in ist – neben der Tätigkeiten zur Sicherstellung der Effektivität des Information Security Programs – das Lösen auftretender sicherheitsrelevanter Ereignisse. Dies sind zum Beispiel Durchführen von Schwachstellenanalysen – Scanning, Penetration Testing, Szenarientests – inklusive dem Entwickeln und Effektivitätstesten der gesetzten Maßnahmen. Eine weitere operative Aktivität ist das Analysieren, Behandeln und Lösen von Non-Compliance-Aspekten, die etwa durch Monitoring, Reviews, Vulnerability Scans oder Audits erkannt werden. Dafür müssen diese Fälle analysiert, aufbereitet, berichtet, Verbesserungsvorschläge ausgearbeitet, deren Umsetzung überwacht und die Effekte verifiziert werden. Die immer wiederkehrenden operativen Tätigkeiten werden durch die/den Information Security Manager*in koordiniert und überwacht [CIS10, S226ff].

Results

Gerade bei derart strategisch angesiedelten Ansätzen wie Information Security Management, die top down implementiert werden müssen , ist es ganz wesentlich, die erwarteten Effekte der gesetzten Maßnahmen zu definieren und danach auch messen zu können. Dies soll wohlüberlegt sein und nicht außerhalb von Information Security Governance erfolgen.

Ergebnis

Typischerweise wird Information Security Governance nach unterschiedlichen Ergebniskriterien bewertet. Jeder dieser Aspekte muss betrachtet werden, um ein ganzheitliches Bild von Information Security Governance zu bekommen.

Anhand von sechs Zielkategorien auf strategischer Ebene lässt sich das angepeilte Zielergebnis des Information Security Programs messen und darstellen. Zumindest sollte ein Mindestlevel dieser sechs Zielkategorien erreicht werden.

Strategische Ausrichtung (Strategic Alignment)

Die strategische Ausrichtung ist höchst wünschenswert, immer anzustreben, jedoch nie komplett erreichbar. Ausschlaggebend für den Erfolg von Information Security Governance ist die konsistente Ausrichtung von verhältnismäßigen Maßnahmen und Aktivitäten in einer kosteneffizienten Art und Weise. Stückwerk und Schnellschüsse bedrohen diese Konsistenz und erzeugen Ineffizienz. Jede Aktivität muss sich demnach transparent auf einen bestimmten strategischen Aspekt beziehen, muss also zur operativen Handlung zurückverfolgbar sein [CIS10, S46].

Prozesse stellen die Berücksichtigung der Geschäftsziele in den Security-Aktivitäten sicher. Dabei muss auch eine Feedbackschleife ausgehend von den Business Owners und den Stakeholdern für das Information Security Program gegeben sein. Zusätzlich sind Kommunikationskanäle und geordnetes Change Management zu etablieren. Essentiell ist es einerseits, zu hinterfragen, ob sich die grundsätzlichen Annahmen für die Entwicklung des Information Security Programs geändert haben. Andererseits bedingen Änderungen der strategischen Ziele auch Anpassungen für die Ziele des Information Security Programs. Die laufende strategische Ausrichtung kann gewissermaßen am Ausmaß der Beteiligung der anderen Geschäftsbereiche im Information Security Committee abgelesen werden [CIS10, S147, S176f].

Eine regelmäßige Reportingstruktur – z.B. in Form eines Security Strategie Reports – über die relevante Tätigkeiten aus dem Information Security Program sowie regelmäßige Reviews über den Status von Risiken, Risikotoleranz, Steuerungsaktivitäten, Maßnahmen sowie finanzielle, operative oder andere Rahmenbedingungen soll fest etabliert werden. Eine Schlüsselrolle dabei spielt natürlich die/der Information Security Manager*in als Schaltstelle aller sicherheitsrelevanten Aktivitäten, da sämtliche Handlungen und ihre/seine Präsenz an sich Awareness und Verantwortlichkeit für Informationssicherheit schafft und ausdrückt. Je stärker das Thema Information Security in strategischer Planung berücksichtigt wird, desto höher ist der Stellenwert und in der Regel besser die strategische Ausrichtung an den Geschäftszielen [CIS10, S198].

Risikomanagement (Risk Management)

Risikomanagement ist das oberste Ziel aller Information Security Aktivitäten und aller Qualitätssicherungsmaßnahmen innerhalb der Organisation. Die Erwartungen und Zielsetzungen an das Risikomanagement müssen definiert werden, da andernfalls keine Aussage über dessen Erfolg, die richtige Richtung und den effizienten Ressourceneinsatz getroffen werden kann. Hauptziel von Information Security ist die Reduktion von negativen Auswirkungen bis zu einem akzeptablen Niveau [CIS10, S46f].

Die sich ständig ändernde Risikolandschaft soll durch einen laufenden Prozess überwacht, angepasst, die akzeptierten Risikolevels entwickelt und abgestimmt, neue Risiken berücksichtigt werden. Dieser Prozess ist ein ständiger Inputgeber für die Entwicklung eines Information Security Programs. Man muss das Risiko auch anhand seines Lebenszyklus betrachten und messen. Vor allem Design- und Projektrisiken sind während der Entwicklung des Information Security Programs vorherrschend. [CIS10, S147, S177].

Risikomanagement-Themen stellen die Entscheidungsgrundlage für praktisch alle sicherheitsrelevanten Aspekte, die durch das Information Security Program zusammengefasst werden, dar. Treibende Rolle ist ebenfalls die/der Information Security Manager*in [CIS10, S198].

Wertbeitrag (Value Delivery)

Ein Wertbeitrag wird erreicht, wenn Security Investments optimal die Geschäftsziele unterstützen. Der Wertbeitrag ist eine Funktion der strategischen Ausrichtung der Information Security Strategie mit den Geschäftszielen. Salopp formuliert, ein Wertbeitrag wird dann generiert, wenn ein positiver Business Case für alle Information Security Aktivitäten formuliert werden kann. Eine optimale Kostenbalance wird dann erreicht, wenn die strategischen Ziele für Information Security sowie ein akzeptables Maß an Risiko zu den niedrigstmöglichen Kosten erreicht werden [CIS10, S47].

Das Information Security Program soll derart entwickelt werden, dass der geforderte Steuerungslevel effektiv und effizient erreicht werden kann. Natürlich erfordert dies hinreichend gute Projektplanung und Steuerung bei der Entwicklung des Programs, aber auch die Überwachung von Budget und Kosten der laufenden Projekte. Entsprechende Kontrollpunkte geben Auskunft über den Wirkungsgrad der eingesetzten Ressourcen, insbesondere von Technologien. Dazu ist auch Feedback vom Business über die Wertigkeit der IT-Services hilfreich [CIS10, S147, S177].

Der Wertbeitrag von Sicherheit muss sich auch in den laufenden operativen Tätigkeiten des Information Security Programs widerspiegeln. Die Darstellung dieses Wertbeitrages sollte institutionalisiert werden, ist aber naturgemäß schwierig. Dennoch liefert eine gute Vorbereitung keine schlechten Argumente für allfällige Rechtfertigungen oder Verhandlungen über neue Investitionen in Information Security. Jedenfalls muss dabei die End-to-End-Sicht der operativen Prozesse betont werden [CIS10, S199].

Ressourcen-Management (Resource Management)

Der Begriff Ressourcen-Management bezieht sich hier auf die Prozesse für Planung, Zuweisung und Steuerung von Information Security Ressourcen. COBIT 5 [COB12, S29] nennt in diesem Zusammenhang zunächst einmal vier allgemeine „Enabler“ durch deren Anwendung ein Unternehmen seine Ziele erreichen kann, die aber nicht als Ressourcen gemanagt werden müssen:

1. Prinzipien, Richtlinien und Rahmenwerke

2. Prozesse

3. Organisationsstrukturen

4. Kultur, Ethik und Verhalten

Darüber hinaus – und jetzt wird es interessant – nennt COBIT 5 auch noch drei spezielle „Enabler“, die auch als Ressourcen gemanagt werden müssen, damit ein Unternehmen seine Ziele erreichen kann:

5. Informationen

6. Services, Infrastruktur und Anwendungen

7. Mitarbeiter*innen, Fähigkeiten und Kompetenzen

Alle diese Ressourcen sollen effizient eingesetzt und ausreichend dokumentiert, referenziert und verfügbar gemacht werden. Mehrfachlösungen sollen tunlichst vermieden werden, z.B. der Einsatz von zwei Mailprogrammen oder drei Change Management Prozessen. Über Standardisierung werden administrativer Aufwand und Schulungskosten reduziert [CIS10, S47].

Bei der Entwicklung des Information Security Programs werden naturgemäß Ressourcen gebunden. Hier sind gute Projektplanung, Technologieauswahl und optimaler Einsatz der vorhandenen Mitarbeiter*innen-Skills vonnöten. Vor allem beim operativen Tagesgeschäft ist es wichtig, Ressourcen über lange Sicht möglichst effektiv einzusetzen. Bei Schlüsselpersonen im Hinblick auf die Entwicklung des Information Security Programs ist auf eine Stellvertreter*innenregelung zu achten, damit Wissen nicht auf eine einzige Ressource konzentriert wird [CIS10, S147].

Das Management aller Ressourcen im Rahmen des Information Security Programs soll natürlich effektiv und effizient sein. Insbesondere das Erzeugen, Sichern und Verfügbarmachen von Wissen (als eine Form von „5. Informationen“) ist wichtig, was eine gute Dokumentation der sicherheitsrelevanten Aktivitäten impliziert. Als gemeinsame Sicht empfiehlt sich die Definition einer Sicherheitsarchitektur [CIS10, S199].

Leistungsmessung (Performance Measurement)

Messung, Überwachung und Reporting sind zentrale Instrumente für die Sicherstellung der Zielerreichung. Metriken müssen bereits im Vorfeld überlegt, später entwickelt und implementiert werden. Durch die regelmäßige Überprüfung des Fortschrittes kann frühzeitig korrigierend eingegriffen werden. Es gilt das Prinzip: „was nicht messbar ist, kann nicht ‚gemanaged‘ werden“ [CIS10, S47].

Bereits in einer frühen Phase muss sich die/der Information Security Manager*in mit den Metriken, Schwellwerten in Form von MAPs auseinandersetzen. Gerade bei der Entwicklung des Information Security Programs kommt der Fortschrittsfeststellung und dem Monitoring besondere Bedeutung zu – immer abhängig von der Auswahl der Mess- oder Kontrollpunkte. Diese sollen natürlich auf ihre Aussagekraft hin ebenfalls überwacht werden – die Metrik der Metrik oder als Supervision sozusagen. Sie geben Auskunft über das Funktionieren des Information Security Programs [CIS10, S147, S178].

Metriken zur Leistungsfeststellung müssen auf den verschiedenen Ebenen, also strategisch, taktisch, operativ, aufgestellt und regelmäßig evaluiert werden. Durch die gewissenhafte Analyse kann eine Feedbackschleife etabliert werden, sodass die Sicherheitsaktivitäten und deren Unzulänglichkeiten ständig adaptiert und kontinuierlich verbessert werden können – sofern die Metriken in der Lage sind, sinnvoll verwendbare Informationen zu Verfügung zu stellen [CIS10, S199].

Prozess-Sicherheit (Process Assurance)

Die Gewährleistung der Prozess-Sicherheit ist notwendig, um die Einzelfälle, die den Prozess durchlaufen, auch in gleicher Art und Weise durchführen zu können. Ausnahmen und Varianten vermindern die Vergleichbarkeit, die Möglichkeit der Messung, erhöhen den administrativen Aufwand, wirken sich negativ auf den effizienten Ressourceneinsatz aus. Das Ziel ist, dass der Prozess die Einzelfälle in einer erwarteten Weise aus End-to-End-Sicht behandelt und die inhärenten Risiken minimiert. Qualitätssichernde Aktivitäten sollen möglichst in die Geschäftsprozesse integriert werden [CIS10, S47].

Durch die Entwicklung eines Information Security Programs können bestehende Prozesse erweitert oder adaptiert werden. Hier sollte insbesondere auf die Verbindung zu anderen unterstützenden Prozessen geachtet werden, etwa Human Resources, Risikomanagement, physische Sicherheit, Compliance, Recht, Qualitätssicherung oder andere. Wichtig ist eine vernünftige Anzahl an Qualitätssicherungsfunktionen bei der Entwicklung des Information Security Programs. Faktisch jeder Prozess im Unternehmen ist von Informationssicherheit betroffen [CIS10, S147, S178].

Es gilt, sich im Unternehmen an den verschiedenen Stellen entsprechende Informationen über die Qualität von Prozessen, Technologien, Vorgaben zu holen. Diese Funktionen können sein: physische Sicherheit, Risikomanagement, Qualitätsmanagement, Geheimhaltung, Revision und Audit, Versicherungen, Personal, Business Continuity Management (BCM) inklusive Disaster Recovery (DR) und andere [CIS10, S199].

Darüber hinaus gibt es auf sehr detaillierter operativer Ebene ebenso angepeilte Ergebnisse, eventuell Lösungsvorgaben bei Aktivitäten, definierte Rahmenbedingungen bei Outsourcingverhältnissen, technische Sicherheitsempfehlungen bei Entwicklungslösungen oder ähnliches. Zusammengefasst sucht die/der Information Security Manager*in beim Management des Information Security Programs folgende sechs Zielsetzungen auf operativer Ebene , die durch die Unternehmensaufsicht und Unternehmensführung von der/dem Information Security Manager*in eingefordert und kontrolliert werden sollen [CIS10, S199]:

• taktischer und strategischer Wertbeitrag für die Organisation

• effizientes Abarbeiten unter Berücksichtigung der laufenden Kosten

• Verständnis über Treiber, Aktivitäten, Nutzen und Anforderungen

• Weiterentwicklung des Wissens

• Unterstützung der Zusammenarbeit der einzelnen Organisationseinheiten

• Verständnis über Rollen, Verantwortlichkeiten und Erwartungen der Stakeholder.

  Metriken

Als Metriken bezeichnet man Messwerte, die auf Referenzwerte Bezug nehmen. Sie stellen Informationen zur Verfügung, um die Entscheidungsfindung zu unterstützen. Möglichst früh – bereits bei der Zielformulierung von jeder der hier vorgestellten Komponente einer Information Security Strategie – sollte man sich Gedanken darüber machen:

• Wie bestimme ich, ob meine Aktivitäten inhaltlich das Ziel erreichen?
• Wie bestimme ich, ob meine Aktivitäten innerhalb einer vereinbarten Zeit erbracht werden?
• Wie bestimme ich, ob meine Aktivitäten einen definierten Kostenrahmen nicht überschreiten?

Mögliche Überwachungsmetriken beinhalten folgende Konzepte [COB12, S30f]  :

• MAG – “Metrics for Achievement of Goals”, Metriken für die Erreichung von Zielen (“Lag Indicators”, rückwärts gerichtete Indikatoren)

MAGs zeigen im Nachhinein an, ob gesetzte Ziele erreicht wurden. Es handelt sich hierbei um eine Ergebnismessung.

• MAP – “Metrics for Application of Practice”, Metriken für die Anwendung von Praktiken (“Lead Indicators”, vorwärts gerichtete Indikatoren)

MAPs zeigen den momentanen Erfüllungsgrad von Zielen oder Erfolgsfaktoren an. Sie können als Frühindikatoren fungieren.

Wie immer bei Messmetriken muss man definieren, was wirklich zu messen relevant ist. Information Security ist tendenziell schwer zu messen. Dies führt dazu, dass Maßzahlen herangezogen werden, nur weil sie verfügbar und nicht primär, weil sie aussagekräftig sind. Messmetriken sollen in Zusammenarbeit mit den betroffenen Business Owners formuliert werden, da sie die Grundlage für inhaltliche Entscheidungen darstellen und somit auch sichergestellt werden muss, dass die Messmetrik die inhaltliche Sachlage richtig darstellt. Die Aussagekraft und Relevanz für die gesetzten Ziele sollen regelmäßig hinterfragt werden. Es können auf Basis der Metrik gemessene Werte aber in vielen Fällen eine reine Indikatorfunktion für mögliche Risiken oder potentielle Auswirkungen erfüllen. Eine Vorhersage auf Basis der vergangenen Messungen ist mitunter recht risikoreich. Dadurch tendiert man zum exzessiven Datensammeln. Die Metriken sollen aber in einer überschaubaren Anzahl vorliegen, um das große Ganze weiterhin sehen zu können. Sie sollen je nach Aspekt und Unternehmensbereich differenziert sein und sich in drei Kategorien einteilen lassen: strategisch, taktisch, operativ – vornehmlich um die richtige Hierarchie-Ebene und Zielgruppen adressieren zu können [CIS10, S44, S70f].

Beispiel operativer MAP: Anzahl der Passwortrücksetzungen pro Monat
Beispiel taktischer MAP: Anzahl der Policy-Abweichungen pro Jahr
Beispiel strategischer MAP: Anzahl der signifikanten Änderungen von Risiken und möglichen Auswirkungen in Bezug auf die Geschäftsprozesse pro Jahr'

Die Entwicklung von Metriken kann man in Form von Fragen entwickeln, etwa:

• Wie sicher ist unsere Organisation?
• Wieviel Security ist „genug“?
• Wie wissen wir, wann wir „sicher“ sind?
• Was sind die kosteneffizientesten Lösungen?
• Wie bestimmen wir das Risiko?
• Wie gut kann man das Risiko vorhersagen?
• Gehen wir in die richtige Richtung?

Die Antwort auf diese Fragen führen zur Metrik, die Messungen sind die Antworten darauf. Trotzdem können sie nur Momentaufnahmen eines gegenwärtigen Zustandes sein. Daher müssen Messungen regelmäßig durchgeführt werden, um eine Entwicklung feststellen zu können.

Bei der Entwicklung eines Information Security Programs müssen einige Aspekte für Metriken berücksichtigt werden. Zunächst dienen Metriken dazu, den Entwicklungsprozess auf Projekt-, Management- und Strategie-Ebene zu verfolgen und zu begleiten. Sie bilden auch Input für den nachfolgenden Managementprozess, wobei hier die Effektivität und Effizienz der Messbarkeit einfließt. Steuerungsaktivitäten, die nicht messbar sind, sind für diese Zwecke also wertlos. Bei den Metriken muss das angesprochene Zielpublikum berücksichtigt werden, da technische Metriken andere Adressaten (hier taktisches und operatives Management) haben als strategische Metriken (für das strategische Top-Management), die einen Gesamtzusammenhang messen [CIS10, S175f].

Metrik-Entwicklung

Eine Metrik muss sich immer auf sinnvolle Referenzpunkte beziehen, um für das Information Security Program nützlich zu sein. Durch den substantiellen Hintergrund – also den basierenden Zielen, die sich wiederum auf die Strategie beziehen – können Metriken wesentliche Entscheidungshilfen geben. Jede Metrik muss für ihre jeweilige Ebene (strategisch, taktisch, operativ) aussagekräftig genug sein und damit für die richtige Person zur richtigen Zeit den richtigen Inhalt darstellen. Die operative Ebene beinhaltet zumeist technische und prozesstechnische Metriken, etwa Schwachstellen, Patch Management Status o.ä. Taktische Metriken beschäftigen sich mit management-relevanten Aussagen über die Entwicklung des Programs, etwa Policies, Standards, Compliance, Ressourcenauslastung oder Effektivität bei Incident Management and Response. Strategische Metriken bilden eine Zusammenstellung anderer Management-Metriken, etwa Budgeteinhaltung, Kosten, Ergebniskennzahlen. Wesentlich für Metriken ist es, dass sie folgende Eigenschaften aufweisen: handhabbar und kontrollierbar; aussagekräftig; verfolgbar; unmissverständlich; zuverlässig; zeitnahe; vorhersagbar [CIS10, S176].

Security Baseline

Baselines sind immer ein probates Mittel, wenn es darum geht, Mindestkriterien – hier für Information Security – festzulegen. Sie stellen eine spezifische Implementierung eines Standards dar, können – je nach Kritikalität und Sensitivität der Information – in Klassen abgestuft werden und demnach bei Vorliegen von Einteilungskriterien auch gemessen werden. Sie werden ebenfalls als Referenzpunkt herangezogen, quasi als Zielzustand bei Verbesserungsinitiativen [CIS10, S178].

Akkreditierung und Zertifizierung

Eine andere Form der Messung stellen Akkreditierungen und Zertifizierungen dar. Dies sind eigentlich simple regelmäßig wiederkehrende Überprüfungen einer vorgegebenen (oder gewählten) Baseline und werden mit einer Art Gütesiegel bestätigt. Je nach Form wird Compliance zu einer Baseline akkreditiert (für spätere Auditor*innen) oder zertifiziert (für reine Kund*innen). Welche Baseline oder vorgegebenes Framework dafür angewendet wird, bleibt frei wählbar. Beispielsweise ist die fälschlicherweise landläufig als Zertifizierung bezeichnete ISAE3402-Prüfung durch ihren wiederkehrenden Überprüfungscharakter, dem angewendeten Framework, etwa COBIT, und dem Abschlussbericht durchaus in der Praxis als Zertifikat interpretierbar [CIS10, S179].

Ein oftmals unterschätzter Aspekt ist die Messbarkeit des Erfolges des Information Security Programs. Jede Aktivität, jede Initiative, jeder Aufwand muss in irgendeiner Form gemessen und bewertet werden können, sodass man Argumente für eine Rechtfertigung, eine Ausweitung oder eine Optimierung erhält. Man sollte sich bereits bei der Entwicklung der Strukturen in einem frühen Stadium über Messbarkeit, mögliche Metriken, MAP-Strukturen und der Gewinnung von Messwerten Gedanken machen, um umfassend und möglichst objektiv Qualitätsmesskriterien für Erfolg oder Misserfolg, dem Erreichen oder Verfehlen der zuvor gesetzten Ziele herauszukristallisieren. Die/der Information Security Manager*in wird dies in den meisten Fällen gegenüber dem Security Steering Committee oder dem Management des Unternehmens tun. Dabei helfen quantitative und qualitative Messmethoden und man kann auf bekannte Konzepte, wie CMMI, BSC, Six Sigma oder andere hilfreiche Informationen aus bekannten Frameworks zurückgreifen. Bei Information Security Management gibt es grundsätzliche übliche Zielsetzungen, die folgend besprochen werden [CIS10, S207].

Risiko und Verlust

Wichtigstes Ziel des Information Security Programs ist es, dass mit Risiko in einer vernünftigen Form umgegangen wird und sich ein möglicher Schaden innerhalb akzeptabler Grenzen bewegt. Anders ausgedrückt, muss eine optimale Balance zwischen operativer Effizienz und adäquater Sicherheit gefunden werden. Dieser optimale Punkt muss eruiert und dessen Erreichen auch gemessen werden können. Quantitative Metriken für Risiko und Verlust sind beispielsweise:

• Anzahl der technischen und operativen Schwachstellen
• Anzahl der bereinigten Schwachstellen
• Durchschnittliche Zeit der Bereinigung
• Anzahl der wieder aufgetretenen Schwachstellen
• Anzahl der betroffenen Systeme
• Anzahl der durch externe Ausnützung der Schwachstelle betroffenen Systeme
• Anzahl der Schwachstellen mit signifikantem weiter reichenden Schadenspotential
• Anzahl der bestehenden Risiken mit Klassifizierung hoch/mittel/niedrig inkl. ALE
• Anzahl der bereinigten Risiken
• Verteilung der angewendeten Risikobehandlungsstrategien
• Anzahl der Verlustvorfälle
• Anzahl der vermeidbaren Ereignisse
• Durchschnittliche Zeit für die Identifikation von Verlustvorfällen
• etc.

Diese diskreten Werte können mit qualitativen Messungen erweitert werden:

• Wurden die Risiko Management Aktivitäten wie geplant durchgeführt?
• Wurden Incident Response Pläne und Business Continuity Pläne getestet?
• Wurden die Unternehmens- und Informationswerte, Bewertungen und Risikoanalysen aktualisiert?
• Gibt es einen gemeinsam getragenen akzeptierten Risikolevel?
• Nimmt das Management seine Überwachungs- und Treiberrolle wahr?
• etc.

So oder so ähnlich können diese Aspekte gemessen werden, es gilt eine optimale Mischung zwischen dem Aufwand für die Gewinnung aktueller Messdaten und der Aussagekraft zu finden [CIS10, S207].

Unterstützung der Unternehmensziele

Es gilt den Grad der Unterstützung der übergeordneten Organisationsziele zu messen. Mögliche qualitative Fragestellungen können diesen Aspekt umschreiben:

• Gibt es eine Korrelation zwischen den Schlüssel-Meilensteinen der Organisation und den Zielen des Information Security Programs?
• Wie viele Ziele der Information Security wurden durch Unterstützung der Unternehmensziele erreicht?
• Wurden Unternehmensziele wegen zuwiderlaufender Ziele der Information Security verfehlt?
• Wie stark ist der Konsens zwischen Organisationseinheiten, dem Management und den Stakeholdern bezüglich der Ziele der Information Security ausgeprägt?

Mögliche Konfliktpunkte, die durch diese qualitativen Fragestellungen aufgedeckt werden, bedürfen einer weiteren Analyse, um die ursächlichen Gründe festzustellen und bearbeiten zu können [CIS, S207f].

Compliance

Die Messung von Compliance-Graden ist hinreichend schwierig. In manchen Bereichen ist eine Compliance-Rate unter hundert Prozent inakzeptabel (Atomkraftwerke, Fliegerei), in der IT ist dies mitunter schwierig oder ökonomisch oft nicht zu rechtfertigen. Technische Compliance lässt sich in vielen Fällen relativ leicht automatisieren, schwieriger wird das bei Prozess-Standards. Es stellt sich auch die Frage, welche Arten von Steuerungsmaßnahmen – detektiv, präventiv oder korrektiv – im Einzelfall gesetzt werden müssen, um die Compliance sicherzustellen. Falls man sich freiwillig oder vorgeschrieben gewissen Standards unterwerfen möchte, sollten die gesetzten Ziele mit jenen des Information Security Programs abgestimmt sein – und sich keinesfalls widersprechen. Compliance-Feststellungen sind aber in der Regel nur Momentaufnahmen, oftmals über Audits festgestellt und bedürfen regelmäßiger iterativer Wiederholung [CIS10, S208].

Operative Produktivität

Die Maximierung der operativen Produktivität der eingesetzten Ressourcen ist ein Ziel der/des Information Security Manager*in. Produktivität ist hier zu verstehen als Arbeitsprodukt einer Ressource, welche nicht immer der Mensch sein muss. Effizienzsteigerungen können über Automatisierungen, Outsourcing von niedrig priorisierten operativen Tätigkeiten oder Verlagerung von Tätigkeiten an andere Organisationseinheiten erreicht werden. Die eingesetzten Security Technologien helfen bei einem regelmäßigen Einsatz die Produktivität zu steigern, etwa Vulnerability Scanning Tools oder Intrusion Detection Systems (IDS). Manuelle Analysen sind hier aufgrund der Fülle von Systemen und Ansatzpunkten schlichtweg unmöglich. Hier wird die Produktivitätssteigerung durch Automatisierung plakativ demonstriert [CIS10, S208].

Kosteneffektivität

Die Finanzierung des Information Security Programs soll stabil und nachhaltig sein. Die Kostenrestriktionen verursachen mitunter Abstriche in der Sicherheit oder auch der operativen Wartungsarbeiten. Daher muss mit dem vorhandenen Budget die bestmögliche Sicherheit für das Unternehmen lukriert werden. Wie jeder andere Geschäftsprozess auch muss dieser budgetiert, dessen Kosten geplant und im laufenden Geschäftsjahr überwacht werden. Dazu soll die Kosteneffektivität des eingesetzten Geldes ständig gemessen werden können, um einen hohen Wirkungsgrad zu erreichen. Die Kostenarten reichen von Personalkosten, Kosten für Akquisition und Einsatz, für Wartung und Betrieb, aber auch End-of-Life und Verwaltung, die sich in einem Total-Cost-of-Ownership-Modell (TCO) widerspiegeln. Plakative Berechnungen, wie etwa jährlich 4 Euro-Cent pro tausend virus-gescannter Emails können gegenüber dem Security Steering Committee oder dem Management die Kosteneffektivität unterstreichen [CIS, S208f].

Security Awareness

Begründet durch die Tatsache, dass das menschliche Verhalten das schwächste Glied in der Information Security darstellt, muss besonderer Fokus auf das ständige Bewusstsein der Mitarbeiter*innen gelegt werden. Diese Fortbildung der Personen muss ständig überwacht und angetrieben werden, weswegen es auch Metriken braucht, den Grad der Awareness festzustellen. Aufzeichnungen über Schulungsteilnahmen, Unterfertigen von Policies und Verwendungsrichtlinien und Berücksichtigung in Personalentwicklungsplänen müssen in Zusammenarbeit mit der Personalabteilung diesen Gedanken fortführen. Denkbar sind auch Tests oder Computer-based Trainings, woraus Messdaten gezogen werden können [CIS10, S209].

Sicherheitsarchitektur

Die technische Sicherheitsarchitektur soll mit Metriken deren Effektivität transparent machen. Hier kommt es aber auf die Mischung und sinnvolle Aussagekraft an.

Mögliche quantitative Fragestellungen können sein:

• Eindringungsversuche, die von Netzwerkzugriffsmechanismen oder IDS erkannt wurden
• Anzahl und Art der Kompromittierungen
• Statistiken von schadensverursachendem Code (Viren, Würmer etc.)
• Anzahl der Downtimes infolge von Security Incidents
• Anzahl der Daten, Datensätze, Sessions, die durch das IDS analysiert wurden

Weitere qualitative Fragen können sein:

• Technische Sicherheitsmaßnahmen zur Sicherstellung der gesetzten Aktivitätsziele und Policy-Umsetzungen
• Adäquate Steuerungsaktivitäten auf den einzelnen Architekturebenen
• Etablierte Kontrollmechanismen
• Kritische Datenflüsse zu Security-Mitarbeiter*innen oder Security-Technologien

Viele dieser technischen Metriken sind nicht management-tauglich, da zu operativ angesiedelt. Sie bedürfen einer Aggregation, will man die gewonnenen Informationen auf Managementebene positionieren [CIS10, S209].

Framework und Bausteine

Das angewandte Framework als auch die eingesetzten Bausteine sollten ebenfalls regelmäßig auf ihren Beitrag hin evaluiert werden. Dazu sollte eruiert werden:

• Wiederholtes Auftreten von bereits behandelten Ereignissen
• Überprüfung des operativen Wissenslevels der Mitarbeiter*innen
• Standardisierungsgrad von Prozessen
• Klarheit und Umfang der Rollen und Verantwortlichkeiten
• Sicherheitsanforderungen, die in Projektplänen berücksichtigt wurden
• Produktivität und Kosteneffizienz des Information Security Programs
• Auslastung der Security Ressourcen
• Alignment mit und Unterstützung von Unternehmenszielen

Die Sichtbarmachung des Wertes eines Information Security Programs ist Aufgabe der/des Information Security Manager*in [CIS10, S209f].

Operative Performance

Die Leistungsmessung der operativen Komponenten hilft, die Performance des Information Security Program Managements darzustellen [CIS10, S210]:

• Zeit für das Erkennen, Eskalieren, Isolieren und Eindämmen von Security Incidents

• Zeit zwischen Schwachstellenerkennung und –beseitigung

• Quantität, Frequenz und Schwere von Incidents

• Durchschnittliche Zeit zwischen Hersteller-Patch-Release und deren Einspielung

• Prozentueller Anteil der auditierten Systeme

Wiederholungsaufgaben

1. Welchen Ansatz verfolgen Sie bei der Einführung von Information Security Governance und welche Aktivitäten führen Sie durch?
2. Skizzieren Sie die Aktivitäten bei der Entwicklung eines Information Security Programs!
3. Erklären Sie, was bei der Einbeziehung von Third Party Service Provider in Hinblick auf die Informationssicherheit beachtet werden muss?
4. Was ist bei einer Outsourcing-Situation für die/den Information Security Manager*in zu beachten?
5. Nennen Sie mögliche Stolpersteine beim Information Security Program Management!
6. Welchen Problemen sehen Sie sich allgemein bei der Selbsteinschätzung einer Situation im Unternehmen gegenüber?

---

1. Welchen Ansatz verfolgen Sie bei der Einführung von Information Security Governance und welche Aktivitäten führen Sie durch?

   Es wird ein konsequenter Top-Down-Ansatz verfolgt. Die Aktivitäten sind: Angestrebten Security Status formulieren, Aktuellen Security Status bestimmen, Information Security Strategie entwickeln, Gap Analyse durchführen, Aktionsplan festlegen.

2. Skizzieren Sie die Aktivitäten bei der Entwicklung eines Information Security Programs!

   • Information Security Program strukturieren
   • Policy und Standard Compliance sicherstellen
   • Training und Schulung initiieren
   • Steuerungsaktivitäten (Controls) planen
   • Lebenszyklusintegration gewährleisten

3. Erklären Sie, was bei der Einbeziehung von Third Party Service Provider in Hinblick auf die Informationssicherheit beachtet werden muss?

   Für den Fall, dass Unternehmensfunktionen an Dritte ausgelagert wurden, gelten spezielle Implikationen für Information Security. Unterschiedliche Organisationsformen und Sourcing-Modelle erfordern unterschiedliche Sicherheitsaspekte. Verantwortung, gerade für Informationssicherheit, müssen klar definiert werden und formale Abläufe müssen unbedingt eingehalten werden. Zugriffe auf Daten und Informationen des jeweils anderen Partners sind schon aufgrund der Service-Aufgabe unumgänglich. Daher muss auf Basis des Lebenszyklus der Daten bestimmt werden, wem sie gehören, wer sie verändern, löschen, erweitern, wer auf sie wann zugreifen darf. Übergabepunkte, Voraussetzungen, Qualitätsmindestmaßstäbe, eingesetzte Ressourcen, Service Level Agreements, Reporting und auch Audits schaffen die notwendigen Voraussetzungen für die Etablierung eines Checks- and-Balances-Systems. Jedenfalls gelten differenzierte Sicherheitsaspekte bei unterschiedlichen Organisationsformen und Partnerschaftsmodellen, die zu berücksichtigen, vertraglich festzuschreiben und regelmäßig zu auditieren sind.

4. Was ist bei einer Outsourcing-Situation für den Information Security Manager zu beachten?

   Zusammenarbeit mit dem Dienstleister betrachten. Der Verlust von Skills, Wissen, Transparenz von Abläufen, die veränderte formalisierte Zusammenarbeit, Kostenverrechnung, aber auch kulturelle und ethische Unterschiede müssen behandelt werden. Hinzu kommt die Kompatibilität des Internen Kontrollsystems (IKS) des Partners mit den eigenen Steuerungsaktivitäten. Information Security hat eine End-to-End-Sicht und muss auch die durch Unternehmensgrenzen gekennzeichnet. Die Handhabung der Information soll jederzeit nachgewiesen werden können. Der Outsourcingpartner muss gesteuert und gemessen und im Sinne des Kunden seine Services weiterentwickeln. Das ist allerdings nur möglich, wenn bereits bei der Vertragsgestaltung –neben SLA-Bestimmungen und rechtlichen Regelungen – im Rahmen von Information Security dem Kunden das Recht eingeräumt wird, die Abläufe und Steuerungsaktivitäten zu auditieren, dem Dienstleister bestimmte Vorgaben hinsichtlich der Informationshandhabung (Klassifizierung, Zugriff, Veränderung, Datenschutz, Löschung) auferlegt werden.

5. Nennen Sie mögliche Stolpersteine beim Information Security Program Management!

   Fehlender Management-Support, unangemessene finanzielle Rahmenbedingungen, ineffizienter Personaleinsatz, politische Strömungen.

6. Welchen Problemen sehen Sie sich allgemein bei der Selbsteinschätzung einer Situation im Unternehmen gegenüber?

   Siehe dazu Aufzählungsliste im Kapitel