Nachdruck – auch auszugsweise –, Weitergabe an Dritte und Benutzung für die Erteilung von Unterricht nur mit ausdrücklicher Zustimmung der Ferdinand Porsche Fernfachhochschule GmbH.

Es wird ausdrücklich erklärt, dass alle Angaben trotz sorgfältiger Bearbeitung ohne Gewähr erfolgen und eine Haftung des Autors/der Autorin oder des Verlegers/der Verlegerin ausgeschlossen ist.

Medieninhaberin (Verlegerin):

Ferdinand Porsche Fernfachhochschule GmbH

Ferdinand Porsche Ring 3

2700 Wiener Neustadt

Austria, Europe

Melanie Rainer

Melanie Rainer hat die wirtschaftliche Ausbildung in der HBLA für wirtschaftliche Berufe als Grundlage für das Studium der Angewandten Betriebswirtschaftslehre in Klagenfurt genutzt. Sie verbrachte ein Semester an der University of Northern Iowa und zwei Jahre bei Daimler AG im Bereich KAIZEN^®/KVP-Kontinuierlicher Verbesserungsprozess. Nach den ersten Erfahrungen als Projektleiterin bei MANOVA NetBusiness Solutions und hier speziell mit Themen wie Benchmarking, Marktforschung und Kundezufriedenheit in der Seilbahnbranche und Hotellerie wechselte sie in die Welt der Financial Services zur Allianz Elementar Versicherung in die Betriebsorganisation. Sie leitete interne und externe Projekte und agierte als Business Analyst für Prozessoptimierungen. Berufsbegleitend absolvierte sie den Bachelor Wirtschaftsinformatik an der FernFH. Bei PwC ist Melanie Rainer seit 2011 tätig und ist verantwortlich für IT-Audits, Interne Revisionen und Projekte im FS Bereich. Weitere Projekte wie z.B. Umsetzung eines operativen IT-Controllings, Softwaredokumentationsprojekte, Prozess-modellierung, Portfolio- und Programmmanagement sind Teil ihrer Projektliste als IT-Beraterin. Derzeit ist sie zertifizierte Projektmanagerin (IPMA Level C), CFSA-Certified Financial Services Auditor, ITIL Foundation v3 und als Schadensach-bearbeiterin zertifiziert.

Thomas Neuroth-Pfeiffer

Thomas Neuroth-Pfeiffer konnte bereits während seines Studiums der Wirtschaftsinformatik an der Universität Wien in allen relevanten Bereichen des operativen IT Betriebs der Österreich Werbung praktische Erfahrungen sammeln. Es folgten mehrere Jahre der Koordination und Leitung von Softwareentwicklungsprojekten, wobei die prozessorientierte Anforderungsanalyse im Vordergrund stand. Während seiner fast dreijährigen Beschäftigung bei der BOC Unternehmensberatung GmbH beriet er als Senior Consultant zahlreiche Unternehmen bei der Einführung von Geschäftsprozess-, IT-Architektur- und IT-Service Management, bevor er bei ACP IT Solutions GmbH die interne IT der Unternehmensgruppe stellvertretend führte und mehr als drei Jahre für IT-Service Management (ITSM) verantwortlich war. Derzeit ist der zertifizierte ITIL Service Manager V2, ITIL Expert V3, CISA und CISM als Enterprise Architect bei Microsoft Österreich tätig.

Information Security Management – Aufbau

Ziele der Lektion

Kennenlernen der grundlegenden IT-Sicherheitsprinzipien
Schaffung eines theoretischen Konstrukts für Informationssicherheitsmanagement
Interpretation eines Informationssicherheitsmanagementsystems mit seinen Komponenten
Einführung, Struktur, Abgrenzung und Einbettung von Information Security Governance
Diskussion der einzelnen Bausteine für Information Security Governance
Vorstellen der Rahmenbedingungen und der benötigten Ressourcen
Kennenlernen der wesentlichen Rollen
Herausarbeiten der Aufgaben und Verantwortlichkeiten der wesentlichen Rollen und der Mitarbeiter*innen

Grundlagen

Informationssicherheitsmanagement ist grundlegend ein Thema, das vielmehr eine Frage von Zusammenwirken von Menschen und Prozessen und weniger von Technologie ist. Hier gilt wie so oft: das schwächste Glied einer Kette bestimmt die Stärke der gesamten Kette. Die Rolle des Menschen steht dabei immer mehr im Vordergrund. Werden die Aspekte der Verwendung der Technologie durch den Menschen im Sicherheitssystem richtig berücksichtigt, kann wiederum der Mensch auch als stärkste Sicherheitsbarriere gegen Angriffe wirken. Daher ist es umso wichtiger, alle Elemente eines Informationssicherheitsmanagementsystems ausgewogen zu gestalten und in der richtigen Priorität aufeinander abzustimmen.

Doch woher kommt der Bedarf nach Informationssicherheit? Zum einen natürlich aus wirtschaftlichen, unternehmerischen Gründen und zum anderen aus den gesetzlichen Vorgaben [ISM14, S1ff].

Grundlegend ist das Datenschutzgesetz aus dem Jahre 2000 inklusive aller Novellen, beginnend im Jahr 2001 mit BGBl. I Nr. 136/2001 bis zuletzt im Jahr 2013 mit BGBl. I Nr. 83/2013 (Anpassung an die EU-Richtlinie 95/46/EG), für Unternehmen zu berücksichtigen. Es regelt in § 1. (1) DSG 2000 (Datenschutzgesetz 2000) das Grundrecht auf Datenschutz, „Jedermann hat, insbesondere auch im Hinblick auf die Achtung seines Privat- und Familienlebens, Anspruch auf Geheimhaltung der ihn betreffenden personenbezogenen Daten, soweit ein schutzwürdiges Interesse daran besteht. …“ [DSG00]. Daraus ergeben sich für Unternehmen aber auch öffentliche Stellen eine Vielzahl an Pflichten im Rahmen der Datenverarbeitung, -speicherung und -nutzung.

Das Gesetz gegen den unlauteren Wettbewerb (UWG) aus dem Jahre 2004 enthält ebenfalls unzulässige Handlungen z.B. bei der Weitergabe von Informationen. Weitere gesetzliche Grundlagen regeln den Datenschutz spezieller Teilbereiche des gesellschaftlichen Lebens. Im Sozialgesetzbuch (SGB), das bereits im 19. Jahrhundert in Kraft trat, sind Bestimmungen zum Sozialgeheimnis verankert. Demnach dürfen Sozialdaten von Leistungsträgern nicht unbefugt erhoben, verarbeitet oder genutzt werden. In der Abgabenordnung (AO) von 1977 sind nach § 30 das Steuergeheimnis, nach § 30a der Schutz von Bankkunden geregelt. (§ 31 beinhaltet Ausnahmen von diesen Regelungen wie z.B. zur Bekämpfung von illegalen Aktivitäten oder Missbrauch). Je nach Geschäftszweig, Gesellschaftsform und Betätigungsfeld können weitere Gesetze wie z.B. Aktiengesetz (AG), GmbH Gesetz, Urheberrechtsgesetz (UG), Strafgesetzbuch (STGB), Handelsgesetzbuch (HGB) etc. relevant sein.

Das Ziel von Informationssicherheitsmanagementsystemen ist die Gewährleistung von Informationssicherheit (nicht Informationstechnologie (IT) Sicherheit). Die IT ist natürlich Bestandteil des ISMS, aber im Blickfeld des ISMS ist der Schutz aller Informationen im Unternehmen unter Zuhilfenahme von Technologie (IT). D.h. es sind nicht nur Maßnahmen im IT-Umfeld zu treffen, sondern auch im Unternehmen und Miteinbeziehung der Menschen (z.B. Verhaltensrichtlinien und richtiger Umgang mit Informationen).

Informationssicherheit wird als die “Wahrung von Vertraulichkeit, Verfügbarkeit und Integrität“ definiert. Dieses Ziel soll durch die im ISMS definierten Risikomanagementprozesse und Sicherheitsmaßnahmen erreicht werden [ISM14, S3]:

Confidentiality (Vertraulichkeit)

Vertraulichkeit stellt sicher, dass Informationen nicht unberechtigt eingesehen, weitergegeben oder veröffentlicht werden können [ISM14, S16]. Dazu sind z.B. Sicherheitsmaßnahmen zur Verschlüsselung beim Informationstransfer, bei der Datenspeicherung auf Backup-Medien zu gewährleisten. Die Vertraulichkeit wird auch durch die Funktionstrennung und dem Prinzip der geringsten Rechte ermöglicht.

Das Prinzip des „Least Privilege“ (Prinzip der geringsten Rechte) besagt, dass jede/r Mitarbeiter*in nur so viele Rechte bekommen soll, die unbedingt notwendig sind, um die tägliche Arbeit zu erfüllen. Mit diesem Grundsatz wird einerseits die Funktionstrennung (Segregation of Duty) unterstützt und andererseits eine zu weitreichende Vergabe von Rechten verhindert.

Die Aufgaben werden so auf unterschiedliche und für die Aufgabe vorgesehene Personen verteilt, dass kritische Zugriffe oder Prozesse nicht von einer Person im Alleingang durchgeführt werden können und die Aufgaben nur von den dafür kompetenten Personen möglich sind [ISM03, S267].

Integrity (Unveränderbarkeit und Vollständigkeit)

Unveränderbarkeit bedeutet in Bezug auf die Buchführung z.B., dass eine Buchung nicht in einer Weise verändert werden darf, indem der ursprüngliche Inhalt nicht mehr feststellbar ist. Daher sind spätere Veränderungen ausschließlich so vorzunehmen, dass sowohl der ursprüngliche Inhalt als auch die Tatsache, dass Veränderungen vorgenommen wurden, für einen sachverständigen Dritten in angemessener Zeit nachvollziehbar sind. Ab dem technischen Buchungszeitpunkt darf eine Buchung bei Verwendung der regulären Anwendungsfunktionalität nur mehr über eine Stornobuchung rückgängig gemacht werden. Änderungen vor dem technischen Buchungszeitpunkt sind hiervon nicht betroffen [KW11]. Die IT-Systeme müssen diesen Anforderungen entsprechen, genauso wie dem Grundsatz der Vollständigkeit. Buchungen dürfen nicht einfach gelöscht werden und es muss durch organisatorische Maßnahmen sichergestellt werden, dass alle Geschäftsfälle als Buchungen lückenlos und ordnungsgemäß in das System aufgenommen werden.

Availability (Verfügbarkeit)

Informationen und die für Datenverarbeitung und -speicherung eingesetzte IT-Anwendungen und IT-Infrastruktur stehen so zur Verfügung, dass die Informationen jederzeit bei Bedarf eingesehen werden können [ISM14, S16].

Das Fachgutachten der Wirtschaftskammer der Treuhänder regelt außerdem, dass die inhaltsgleiche, vollständige und geordnete Wiedergabe aller Geschäftsvorfälle bis zum Ablauf der gesetzlichen Aufbewahrungspflicht jederzeit gewährleistet sein muss. Da regelmäßig Datenbestände im Rahmen von Datensicherungs- und Archivsystemen und nicht in den IT-Buchführungssystemen selbst aufbewahrt werden, erstrecken sich die Ordnungsmäßigkeitskriterien auch auf diese Datenbestände und Systeme [KW11].

Die obigen drei Kernprinzipien werden in der Literatur auch als der sogenannte „CIA-Ansatz“ bezeichnet. Allerdings gibt es weiterführende Prinzipien, welche die vorangegangenen erweitern und somit komplettieren.

Authenticity ^[1] (Authentizität)

Mit dem Begriff Authentizität wird die Eigenschaft bezeichnet, die gewährleistet, dass ein Kommunikationspartner tatsächlich derjenige ist, der er vorgibt zu sein. Bei authentischen Informationen ist sichergestellt, dass sie von der angegebenen Quelle erstellt wurden. Der Begriff wird nicht nur verwendet, wenn die Identität von Personen geprüft wird, sondern auch bei IT-Komponenten oder Anwendungen. [BSI15]

Authentication ^[2] (Authentisierung)

Unter einer Authentisierung versteht man die Vorlage eines Nachweises eines Kommunikationspartners, dass er tatsächlich derjenige ist, der er vorgibt zu sein. [BSI15]

Authentication² (Authentifizierung)

Unter einer Authentifizierung versteht man die Prüfung einer Authentisierung, d. h. die Überprüfung, dass ein Kommunikationspartner tatsächlich derjenige ist, der er vorgibt zu sein. Dies kann unter anderem durch Passwort-Eingabe, Chipkarte oder Biometrie erfolgen. [BSI15]

Authentifizierung bestätigt die Identität von Kommunikationspartnern (Personen, IT-Komponenten oder Anwendungen). Authentizität von Informationen besagt, dass diese von der angegebenen Quelle erstellt wurden. Die gegenseitige Authentifizierung zwischen Kommunikationspartnern ist daher eine unbedingte Voraussetzung für die Authentizität von Informationen, die zwischen diesen ausgetauscht werden. Die feine Unterscheidung zwischen Authentisierung und Authentifizierung wird nur im Deutschen gemacht und hat in der Praxis keine Bedeutung: eine Authentisierung ohne nachfolgende Authentifizierung ist de facto wertlos.

Authorisation (Autorisierung)

Autorisierung soll sicherstellen, dass weder Personen noch IT-Systeme aktiv werden, die nicht diejenigen sind, für die sie sich ausgeben (z.B. durch Nutzung von Userkennungen der Kolleg*innen) oder denen nicht schon vorab eine Zugriffsberechtigung erteilt worden ist. Elemente des Autorisierungsprozesses sind die Identifikation, die Authentifizierung und zuletzt die Autorisierung selbst. Die Identifikation stellt die Identität einer Person fest und bei der Authentifizierung wird die Wahrhaftigkeit der Identität überprüft und bestätigt. Bei der abschließenden Autorisierung wird der Zugriff auf Basis einer vorangegangenen offiziellen Erlaubnis oder Freigabe von einem definierten Verantwortlichen erteilt [ISM14, S1]. Diese Elemente sind integrale Bestandteile beispielsweise der Berechtigungsverwaltung.

Bei der Freigabe von Berechtigungen wird meist die/der Vorgesetzte oder Abteilungsleiter*in als verantwortliche Person nominiert. Dabei muss sichergestellt werden, dass diese Person sowohl die fachliche, persönliche und formale Befähigung erhält, dem nachzukommen. Weiters muss darauf geachtet werden, dass die Leitungsspanne (Span of Control) aus Sicherheitsaspekten nicht zu groß wird. Die Leitungsspanne ist die Anzahl an Stellen, die einer Leitungsfunktion direkt zugeordnet sind. Wenn eine Führungskraft zu viele Stellen unter sich kontrollieren muss, kann die Übersicht verloren gehen und Fehler sind wahrscheinlicher [ISM03, S305].

Technologische Ansätze zur Authentifizierung sind [ISM14, S4ff]:

Passwort-basierter Ansatz (Authentifizierung aufgrund einer geheimen Information – dem Passwort oder PIN)
Token-basierter Ansatz (Authentifizierung mittels eines Tokens – ein physischer Schlüssel/Gegenstand)
Biometrischer Ansatz (Authentifizierung mittels physikalischer Merkmale oder Verhalten einer Person)

Non-Repudiation (Nicht-Abstreitbarkeit)

Des Weiteren ist es wichtig, dass sämtliche Aktivitäten der Anwender*innen auch derart dokumentiert werden, sodass diese ex-post – von welchen Beteiligten auch immer – nicht abgestritten werden können. Dieses Prinzip ist insbesondere im elektronischen Zahlungsverkehr wesentlich.

Sicherheits-Risikomanagement

Risikomanagement für den Bereich Sicherheit ist der Ausgangspunkt für die Bewertung von möglichen Sicherheitsrisiken und der Entscheidung über den

Schutzbedarf

des Unternehmens. Wie wichtig eine adäquate Bewertung und Umgang mit Sicherheitsrisiken ist, hat eine Studie der CSI 2001 Computer Crime and Security Survey bestätigt. 85% der Befragten haben in den vergangenen zwölf Monaten vor der Befragung in ihrer Organisation Sicherheitslücken festgestellt. Der finanzielle Verlust belief sich auf mehr als zwei Millionen US-Dollar pro Vorfall [CSI01, S346].

Der Risikomanagementprozess besteht aus folgenden Teilschritten [ISM03, S342f]:

Risikoidentifikation und -bewertung (Assess): Es wird eine umfassende Analyse möglicher Sicherheitsrisiken in allen Bereichen des Unternehmens durchgeführt. Von möglichen unerwünschten physischen Zutritten bis hin zu Netzwerk-Sicherheitslücken werden alle möglichen Risiken identifiziert und deren Eintrittswahrscheinlichkeit und Auswirkungsgrad bewertet.
Risikobehandlung (Mitigate): Es werden eine Reihe von Maßnahmen definiert und umgesetzt, die zu einer Risikominimierung oder -vermeidung führen. Die Maßnahmen reichen vom Aufsetzen von Sicherheitsrichtlinien bis hin zum Einsatz von geeigneten Technologien.
Versichern (Insure): Versicherungen sind ein geeignetes Mittel, um den finanziellen Verlust abzudecken. Allerdings kann es bei Sicherheitslücken nicht nur zu finanziellen Verlusten kommen, sondern z.B. zu Reputationsverlusten. Für solche Risiken sind Versicherungen nicht das geeignete Mittel.
Überwachung (Detect): Dabei werden alle Sicherheitsmaßnahmen konstant überwacht. Unübliche Vorkommnisse werden rechtzeitig erkannt und analysiert z.B. durch eine Anti-Viren-Software oder ein 24/7-Monitoring System zur Intrusion Detection (Entdecken von versuchten oder tatsächlichen Angriffen).
Remediate: Ist ein Angriff auf das Unternehmen erfolgreich, müssen Prozesse und Maßnahmen sofort greifen, um den eingetretenen Schaden möglichst gering zu halten und einen erneuten Angriff abzuwehren. Diesen Prozess nennt man Incident Response (Vorfallsbehandlung; siehe auch Kapitel Incident Response).

Informationssicherheitsmanagementsystem - ISMS

Definition

In einem Unternehmen sind Informationen an unterschiedlichen Stellen zu finden. Sie weisen unterschiedliche Qualität, verschiedene Themeninhalte und Charakteristika auf. Die Verarbeitung und Speicherung erfolgt teils automatisiert durch oder mit IT-Systemen aber auch manuell. Ein Informationssicherheitsmanagementsystem (ISMS) dient dazu, alle schutzwürdigen Informationen im Unternehmen durch ein geeignetes Managementsystem vor unzulässigem Zugriff und Verbreitung zu schützen. Das ISMS ist ein Bündel aus organisatorischen und technischen Maßnahmen und umfasst neben Richtlinien, Vorgaben und Regelungen auch Managementprozesse. ISO/IEC 27000:2014 [ISO00] definiert ein ISMS folgendermaßen: „Ein ISMS ist ein Managementsystem für die Festlegung, Umsetzung, Durchführung, Überwachung, Revision, Aufrechterhaltung und Verbesserung von Informationssicherheit. Dies umfasst den angemessenen Schutz von Informationen auf der Basis einer Risikoanalyse. Das ISMS verfolgt einen praktischen Ansatz und zielt damit auf eine Optimierung der Informationssicherheits-Managementsysteme in ökonomischer und organisatorischer Hinsicht.“ [ISM14, S2].
Ausgangspunkt sind die Überlegungen des Unternehmens zur Klassifikation von schutzwürdigem Informationsvermögen (Assets) aufgrund [FRG07, S64]:
Products

Konzepte

Der Begriff „Information“ versteht sich hierbei als Daten, die mit einer Bedeutung und einem Zweck versehen sind [vgl. CIS10, S32]. Die Bedeutung von Information im Unternehmensprozess wächst seit Jahren sukzessive. Ganze Branchen sind hochgradig abhängig von richtiger, zeitgerecht vorhandener, abrufbarer Information und ziehen mitunter sogar ihr Kerngeschäft aus dieser Tatsache. Nicht zuletzt deswegen müssen Maßnahmen ergriffen werden, sodass mit dieser Information insgesamt ordnungsgemäß und sicher verfahren wird. Diese Überlegungen betreffen den kompletten Lebenszyklus der Information, von der Entstehung, Dokumentation, Veränderung, Aktualisierung, Übermittlung bis hin zur Löschung und Vernichtung. Insbesondere sensible Daten, nicht zuletzt direkt oder auch indirekt personenbezogene Daten bedürfen eines speziellen Schutzes. Nicht nur in Europa wird der Umgang mit Informationen und dem elektronischen Abbild – den Daten – argwöhnisch betrachtet. Große Informations- und Medienkonzerne sind im Zeitalter von Web 2.0 bei Aufnahmen des öffentlichen Raums und der Menschen, die auf Fotos, Abbildern, Dokumenten identifiziert werden könn(t)en oder auch Daten, die im Zuge der Teilnahme an sozialen Netzwerken erfasst und für andere sichtbar gemacht werden, zunehmend der öffentlichen Kritik ausgesetzt. Es bestehen also berechtigte Interessen von diversen Personengruppen – sowohl inner- als auch außerhalb des Unternehmens – diese Informationen zu schützen, sei es durch den Gesetzgeber oder durch Unternehmensvorgaben, die sich im Compliance Management manifestieren. Daten, Information und Wissen haben sich in den letzten Jahren als das Asset in der modernen Geschäftswelt etabliert. Im Zusammenhang damit gehen natürlich Risiken, Nutzen und Möglichkeiten einher und das Unternehmen muss sich diesen Herausforderungen stellen. Als Vorteile bei einem positiv-konstruktiven Umgang mit Informationssicherheit sind dabei überschaubarere rechtliche Haftungsaspekte, Regelkonformität, Vorhersehbarkeit, Strukturiertheit, Qualitätssicherung, erhöhte Vertrauensbasis im täglichen Geschäftsverkehr, Reputation, transparentere Verantwortlichkeiten für alle Unternehmensabläufe, Aktivitäten und Tools hervorzustreichen.
Information kann somit auch in einem Gesamtzusammenhang für Wissensmanagement eingebettet werden. Dies kann in einem sogenannten DIKW-Modell visualisiert werden, das in Abb. 1.1 dargestellt wird. Das Akronym “DIKW” bedeutet „Data–to–Information–to–Knowledge–to–Wisdom“. Bei diesem Modell werden die Daten als die Summe von einzelnen Fakten über Ereignisse definiert, also Nummern, Zahlen, Buchstaben, Zeichen. Diese werden gesammelt, analysiert, synthetisiert und transformiert zu Information. Information stellt in diesem Modell gewissermaßen den Kontext der Daten her, also zum Beispiel in semi-strukturierten Inhalten wie Dokumenten, Email oder Multimedia-Dateien. Dieser Kontext spezifiziert die empfangene und verstandene Botschaft bei der Person und verknüpft somit „Wer“, „Was“, „Wann“ und „Wo“ mit den Daten zu Information. Diese kann nun erfasst, gesucht, gefunden, wiederverwendet und mit dieser gelernt werden. Wird die Information mit Erfahrung, Ideen, Erkenntnis, Werten und Urteilsvermögen der Person kombiniert, wird Wissen generiert. Die Kenntnis der Person über Methoden, Anwendungen und Lösungswege erklärt das „Wie“. Wird das Wissen hier noch um Fähigkeit für korrekte Einschätzungen und Entscheidungen erweitert – also das „Warum“ dahinter geklärt – entsteht Weisheit. Dieser Begriff stellt die breite Streuung des verfügbaren Wissens dar [vgl. IST07, Seite 146].

Das DIKW-Modell

Anhand dieses Modells zeigt sich ganz offensichtlich, dass der Begriff „Daten“ hier zu kurz greift. Da sich IT primär auf Daten und ihre Verarbeitung konzentriert, beschränkt sich IT-Sicherheit hier zu sehr auf den technisch-operativen Aspekt. Informationssicherheit konzentriert sich auf Information als übergeordneten Begriff und betrachtet auch die Stufen Wissen und Weisheit des oben vorgestellten Modells, weil die Person und ihre Verantwortlichkeiten ebenso in Betracht gezogen werden.
Im Rahmen dieses vorliegenden Skriptums werden wir die oben genannten Aspekte strukturiert diskutieren und versuchen, dadurch Informationssicherheit zu gewährleisten. Wir werden vom visionären Ansatz ausgehend in jeder Lektion sukzessive operativer. Zunächst muss man über Information Security Governance die unternehmenskulturellen und infrastrukturellen Rahmenbedingungen schaffen. Über das Risikomanagement wird das Unternehmensumfeld analysiert. Auf die daraus gewonnenen Ergebnisse aufsetzend wird ein Information Security Program entwickelt und dann umgesetzt. Tritt der Fall eines Information Security Incidents ein, muss dieser rasch erkannt und auf diesen reagiert werden.

Information Security Management

Information Security Management versteht sich als ganzheitliche Disziplin, wie im Unternehmen Informationen in sicherer Art und Weise behandelt werden. Dieser Ansatz beschränkt sich nicht auf die Informations- und Kommunikationstechnologie, mit der diese Informationen verarbeitet werden. Vielmehr geht man hier vom inhärenten Risiko aus, welcher der Information innewohnt, wenn unabhängige Dritte davon Kenntnis erlangen. Dabei ist IT Sicherheit ein wesentlicher Teil, jedoch nicht ausschließlich. Essentiell ist allerdings, dass die IT ihrerseits die Geschäftsziele unterstützt (zumindest ihr nicht zuwider läuft) und demnach ein hoher Grad an IT Business Alignment gegeben ist.
Der Ausdruck „ganzheitlich“ legt bereits die grundlegende Intention nahe, sich dem Thema Informationssicherheit mittels eines Top-Down-Ansatzes zu nähern. Informationssicherheit ist definitiv ein Management-Thema und muss erfahrungsgemäß von der Spitze der Hierarchie an definiert und in die operativen Ebenen hineingetragen werden. Es müssen insbesondere
- Konzepte angewandt,
- Bausteine – also Ressourcen – zur Verfügung gestellt,
- Verantwortlichkeiten und Rollen definiert,
- diese an Personen zugewiesen,
- Rahmenbedingungen vorgegeben,
- Aktivitäten ausgeführt,
- Umsetzungsergebnisse kontrolliert
und objektiv gemessen und überprüft werden.
In einem ersten Schritt müssen die grundsätzlichen Rahmenbedingungen als Basis für Information Security Management vom Top Management hergestellt werden. Dies wird hier unter dem Begriff „Information Security Governance“ subsumiert. Die Aufgabe von Governance (engl. für „führen“, „regieren“) ist es, Mechanismen zu schaffen, dass sich die Mitarbeiter*innen und andere Ressourcen an etablierten Prozessen und Policies orientieren. Es ist die Verantwortung der Unternehmensführung, Information Security Governance als integralen und transparenten Bestandteil der Unternehmensführung zu etablieren. Sie gibt dafür die Leitlinien vor.

Information Security Program

Ein Information Security Program umfasst all jene Aktivitäten und Ressourcen, die für Informationssicherheit sorgen. Die Entwicklung eines Information Security Programs kann sich von einem kleinen Projekt bis zu einem mehrjährigen Vorhaben erstrecken. Sie kann eine Vielzahl an Aktivitäten, Projekten und Initiativen, in denen Personen, Prozesse und Technologien über einen langen Zeitraum involviert sind, mit sich bringen. Im Management muss daher Awareness geschaffen werden, damit die benötigten Ressourcen über die erforderliche Zeitspanne zur Verfügung gestellt werden. Die Ziele und der erwartete Nutzen eines Information Security Programs können dem Management am besten näher gebracht werden, wenn sie in der „Sprache des Business“ formuliert sind, damit Stakeholder ohne technischem Wissen die Ziele des Programs verstehen und befürworten können. In einigen Fällen kann der Information Security Manager das Information Security Program von Grund auf beginnen. In den meisten Fällen werden jedoch bereits bestehende Programs angepasst, erweitert und verbessert [CIS10, S146].
Es gibt drei Elemente, die für die erfolgreiche Entwicklung und Umsetzung eines Security Programs essentiell sind:
- Das Program muss die Umsetzung einer definierten Information Security Strategie, die eng an den Unternehmenszielen ausgerichtet ist, umfassen.
- Das Program muss mit Einbindung und Unterstützung des Managements und Stakeholder entwickelt werden.
- Kennzahlen müssen sowohl für die Entwicklung und Umsetzungsphasen, als auch für die nachfolgenden Security-Program-Management-Phasen entwickelt werden, um die Ausführung des Programs steuern zu können, damit die vereinbarten Ziele erreicht werden können.
Einmal entwickelt, muss das Information Security Program auch umgesetzt werden, wobei dies nicht als einmalige Tätigkeit anzusehen ist. Vielmehr ist dies ein laufender Prozess, der – wie alle anderen Prozesse auch – geplant, koordiniert, geführt und gemessen werden muss.

Bausteine eines ISMS

Um Information Security Governance schaffen zu können, bedient man sich einiger Bausteine. Diese müssen entsprechend gestaltet und/oder eingerichtet werden, um das Umfeld für Information Security aufbereiten zu können. Nicht alle Bausteine müssen im Unternehmen vorhanden sein und sie sind auch – genauso wie die Gesamtsituation – ständigen Veränderungen unterworfen. Durch die Bausteine soll ein konsistentes Gesamtbild für eine Information Security Strategie entstehen.
Für die Entwicklung und Umsetzung eines Information Security Programs werden viele und unterschiedliche Ressourcen benötigt. Mit dem Einsatz dieser Ressourcen kann der gewünschte und angestrebte Zustand von Sicherheit über die Zeit im Unternehmen erreicht werden.
Auch beim Management des Information Security Programs bedient man sich diverser Bausteine, um die laufenden Tätigkeiten zu unterstützen und in die gewünschte Richtung zu lenken. Sie haben in dieser Phase einen spezielleren Fokus auf ständige Anpassung.
Die Bausteine eines ISMS können beispielsweise anhand von Normen (standards) im Unternehmen implementiert werden z.B. durch die ISO/IEC 27000 Normenfamilie. ISO/IEC 27002:2013 ist ein Best-Practice-Ansatz und führt in 14 Abschnitten (clauses) 35 Steuerungsziele (control objectives) mit insgesamt 114 anerkannten und praxiserprobten Steuerungsmaßnahmen (controls) im „Code of Practice“ als Bausteine des ISMS an. Der Code of Practice versteht sich als Leitfaden für Informationssicherheit, aber auch als Katalog für Informationssicherheitsfragen und Empfehlungen und ist nicht technologieorientiert. Die nachfolgende Aufzählung listet alle Abschnitte von ISO/IEC 27002:2013 auf, wobei das Vorwort, die Abschnitte 0 bis 4 und das Literaturverzeichnis kursiv geschrieben sind, weil diese keine Maßnahmenziele und auch keine Maßnahmen enthalten [ISO02]:
Foreword
Introduction
Scope
Normative references
Terms and definitions
Structure of this standard
Information security policies
Organization of information security
Human resource security
Asset management
Access control
Cryptography
Physical and environmental security
Operations security
Communications security
System acquisition, development and maintenance
Supplier relationships
Information security incident management
Information security aspects of business continuity management
Compliance

Bibliography

In ISO/IEC 27001:2013 werden in Anhang A exakt dieselben 35 Steuerungsziele (control objectives) und exakt dieselben 114 Steuerungsmaßnahmen (controls), die zum Schutz des Unternehmens implementiert werden sollten, genannt [ISO01]:

A.5 Information security policies

A.6 Organization of information security

A.7 Human resource security

A.8 Asset management

A.9 Access control

A.10 Cryptography

A.11 Physical and environmental security

A.12 Operations security

A.13 Communications security

A.14 System acquisition, development and maintenance

A.15 Supplier relationships

A.16 Information security incident management

A.17 Information security aspects of business continuity management

Achtung: Dieser Abschnitt beschreibt nicht alle Anforderungen an den Prozess Business Continuity Management, damit dieser sein Prozessziel (nämlich die Fortführung der Geschäftsprozesse) erreichen kann, sondern nur jene Maßnahmen, die in den Prozess Business Continuity Management integriert werden müssen, damit die Informationssicherheit auch im Fall eines Business-Continuity-Ereignisses lückenlos gewährleistet ist. (Frühere Ausgaben von ISO/IEC 27002, 27001 und 17799 haben das nicht so klar abgegrenzt).

Anmerkung: Anforderungen (requirements) an den Prozess Business Continuity Management sind in ISO 22301 [ISO03] beschrieben, einen zugehörigen „Code of Practice“ findet man in ISO 22313 [ISO04].

A.18 Compliance

In früheren Ausgaben der ISO/IEC 27002 und ISO/IEC 27001 (und deren Vorgängernorm ISO/IEC 17799) gab es noch einige Unterschiede zwischen den Strukturen von „Code of Practice“ und „Requirements“, diese Unterschiede wurden aber im Jahr 2013 alle bereinigt. In derselben Ausgabe wurde die ISO/IEC 27001 auch als erste internationale Norm für die Zertifizierung von Managementsystemen auf die neue einheitliche „High Level Structure“ der ISO für Managementsysteme umgestellt; Normen für andere Managementsysteme wie z.B. Qualitätsmanagement und Umweltmanagement werden denselben Weg einschlagen.

Weiters gilt es zu beachten, dass jedes Unternehmen aufgrund der eigenen Sicherheitspolitik das zu erreichende Sicherheitsniveau des Unternehmens unter Berücksichtigung des Risikoappetits festlegt. Die Standards geben Anhaltspunkte für generische Sicherheitsmaßnahmen ohne Bezug auf die speziellen Technologien, Umfeldbedingungen und gesetzlichen Rahmenbedingungen der Unternehmen. Daher müssen die Bausteine aufgrund der Politik, der Risikoanalyse und der eingesetzten Technologien genau bewertet und ausgewählt werden.

Information Security Risk Management

Die Bausteine für Information Risk Management sind Konzepte und Risikomanagementmethoden. Es gibt eine Vielzahl an möglichen Methoden, aber nur wenige können für Information Security herangezogen werden. Nachfolgend werden einige grundsätzliche Ansätze anhand von verschiedenen Methoden vorgestellt. Weiters haben Sicherheitstechnologien auch risikominimierendes Potential.

Faktorenanalyse

Die Faktorenanalyse (Factor Analysis of Information Risk) spaltet Risiken auf ihre Einzelkomponenten auf (siehe Abb. 1.2) und versucht so, die Komplexität von Risiken aufzulösen. Über eine Taxonomie wird das inhaltliche Verständnis des Risikos gefördert, Messmethoden für die Faktoren gewinnen Daten über Auftrittsfrequenz von Ereignissen, Schwachstellen, Wahrscheinlichkeit der Ausnutzung ebendieser und potentiellen Verlust. Eine Berechnungseinheit wendet mathematisch-statistische Methoden an und simuliert die Verbindungen zwischen den Faktoren. Ein Simulationsmodell analysiert daraufhin Risikoszenarien [CIS10, S99] [FAR05].

Faktorenanalyse nach FAIR

Risikofaktorenanalyse

Diese semiquantitative Methode versucht über Risikofaktoren, nämlich Kosten, Budget, Zeit und Technik, spezielle Aspekte herauszustreichen – siehe Abb. 1.3 – und Risiken qualitativ in Risikokategorien (gering/mittel/hoch) – siehe Abb. 1.4 – einzuordnen. Diese Aspekte können zum Beispiel Produktivitätsunsicherheit (Zeitaspekt), Technologiereife (Technik), Unsicherheit bei Equipment und Materialkosten (Kosten), Investitionsgrenzen (Budget) sein. Über eine Einteilung des Risikos in die Matrix wird das Risiko bewertet [CIS10, S99].

Risikofaktoren

Risikokategorien und generische Risikofaktoren

Statistisches Risk Assessment

Als Beispiel für eine quantitative Methode sei das Probabilistic Risk Assessment erwähnt. Es wurde von der US Nuclear Regulatory Commission entwickelt und evaluiert Risiken, die mit einer komplexen konstruierten technologischen Einheit – etwa einem Atomkraftwerk – verbunden sind. Risiko ist bei dieser Methode charakterisiert durch Ausmaß und Eintrittswahrscheinlichkeit jeder Auswirkung (Konsequenz). Diese wird durch numerische Werte ausgedrückt. Die Wahrscheinlichkeit kann strukturiert über Fehler- oder Ereignisbaumanalyse ermittelt werden. Das Risiko ergibt sich aus dem Produkt beider Komponenten. Über das statistische Risk Assessment stellt man sich die folgenden Fragen:

Was kann schiefgehen? Was sind die Auslöser von negativen Ereignissen?
Was ist der potentielle Schaden und wie schwerwiegend ist dieser?
Wie wahrscheinlich ist das Eintreten des negativen Ereignisses?

Annual Loss Expectancy (ALE)

Quantitative Risikoanalysemethoden versuchen immer, numerische Werte aus den Annahmen abzuleiten. Ein typischer Wert in dem Zusammenhang ist der Single Loss Expectancy (SLE) sowie der davon abgeleitete Annual Loss Expectancy (ALE). Die SLE ist dabei das Produkt des Unternehmenswertes, dem Asset Value (AV) mal dem Gefährdungsfaktor (Exposure) (EF). Dabei ist der Gefährdungsfaktor EF die Wahrscheinlichkeit, dass ein Ereignis eintritt, in Verbindung mit dem potentiellen Ausmaß. Dies ist ein Prozentwert des realisierten Schadens, falls eine Bedrohung eine Schwachstelle ausnutzt. Die ALE addiert dazu noch eine jährliche Ereignisrate, die Annualized Rate of Occurence (ARO). Die ARO repräsentiert also den jährlich erwarteten finanziellen Schaden in Bezug eines Unternehmenswertes. Wenn ein Ereignis einmal in 25 Jahren eintritt, beträgt die ARO also 0,04. Je höher das Risiko der Bedrohung, desto höher ist der ARO [CIS10, S108].

SLE = AV [Absolutwert] x EF [Prozentwert]

ALE = SLE [Absolutwert] x ARO [Anzahl]

Value at Risk (VAR)

Ein weiteres quantitatives Konzept ist der Value at Risk (VAR) und soll hier nur grob erwähnt werden. Der VAR ist eine Berechnung basierend auf historischen Daten über die Wahrscheinlichkeitsverteilung für eine gegebene Zeitperiode mit einer Unsicherheit von maximal fünf Prozent. Die Wahrscheinlichkeitsverteilung wendet dabei iterative Monte-Carlo-Simulationen an. Es versucht so eine Größe für die Beschreibung von Sicherheitsrisiken zu erstellen [CIS10, S108f].

Recovery Time Objective (RTO)

Dieser Begriff wird vornehmlich im Zusammenhang mit Business Continuity Management (BCM) verwendet. Der Recovery Time Objective (RTO) ist business-getrieben und bezeichnet die Zeit, die für einen Wiederanlauf (Recovery) bis zu einem akzeptierten Betriebslevel benötigt wird. Die Bestimmung dieses Zeitwertes kann von den Informationszyklen, den Abhängigkeiten zwischen den Informationen und den Anforderungen der Organisation – etwa SLAs, Vertragsbestimmungen oder gesetzliche Anforderungen – oder den Kosten für die Verfügbarkeit abgeleitet werden. Üblicherweise wird der RTO im Rahmen einer Geschäftsauswirkungsanalyse, also einer Business Impact Analyse (BIA), ermittelt. Der RTO kann auch variieren, etwa wenn es um den Monatsabschluss geht. In so einem Fall ist der RTO am Monatsende wesentlich geringer als in der Monatsmitte. Auch sind Differenzen in Bezug auf den RTO aus dem Blickwinkel der einzelnen Hierarchieebenen zu konstatieren, was eine allgemeine Bestimmung des Wertes erschwert. In jedem Falle bedeutet ein geringer RTO-Wert höhere Kosten, diesen auch zu gewährleisten. Daher ist hier wiederum das Gleichgewicht der Ausfallskosten zu den Kosten der Maßnahmen für einen raschen Wiederanlauf zu finden. [CIS10, S119f]

Recovery Point Objective (RPO)

Der Recovery Point Objective (RPO), ein weiterer Begriff aus dem Themengebiet Business Continuity Management (BCM) wird durch den akzeptierten Datenverlust bei Betriebsunterbrechungen bestimmt. Er repräsentiert also den spätest möglichen Zeitpunkt vor einer Betriebsunterbrechung, dessen Zustand wiederhergestellt werden kann/soll. Der RPO hat somit einen Effekt hinsichtlich der Gewährleistung von z.B. sehr kurz bemessenen RTOs und ist in so einem Fall möglicherweise gar nicht leistbar [CIS10, S120].

Service Delivery Objective (SDO)

Das Service Delivery Objective (SDO) ist definiert als der Mindestlevel, bis zu dem nach einem Ereignis ein Service wiederhergestellt werden muss. Es liegt typischerweise unter dem normalen Service Level. RTO und RPO haben demgemäß Einfluss auf das SDO. Höhere Service Levels für das SDO erfordern allgemein mehr Ressourcen und einen kürzeren RPO.

Technologien

Wiederum können auch Information Security Technologien verwendet werden, um Risiken zu behandeln und in letzter Konsequenz zu minimieren [CIS10, S94]:

Applikationssicherheitsmaßnahmen
Physische Sicherheitsmaßnahmen
Umgebungssicherheitsmaßnahmen
Logische Zugriffsmaßnahmen
Netzwerkzugriffsmaßnahmen
Router, Firewall- und Netzwerkkomponenten
Intrusion Detection/Prevention
Wireless Security
Platform Security
Kryptographie
Public Key Infrastructure (PKI)
Antivirus-/Antispam/Malware/Spyware/Adware-Infrastruktur
Telekommunikation und Voice over IP (VOIP)

Security Control Baseline

Baselines stellen allgemein Minimumanforderungen dar, in dem Fall an Sicherheitsaktivitäten. Diese sollen so gewählt sein, dass sie konsistent mit dem akzeptierten Risikolevel sind. Es sollen verschiedene Baselines für unterschiedliche Sicherheitsklassifikationen entwickelt werden, je nachdem wie sensibel die Ressource ist [CIS10, S124].

Enterprise Information Security Architecture

In den letzten Jahren wurden viele Ansätze zu Architekturen für Sicherheit als Teil der Unternehmensarchitektur (Enterprise Architecture) entwickelt. Allerdings gibt es wenige Dinge in großen Organisationen die komplexer sind, als Informationssysteme. Diese Systeme wurden meist ohne umfassende Architektur oder umfangreichen Aufwänden für das Design konstruiert. Informationssysteme entwickeln sich mit der Zeit durch Erweiterungen, sobald neue Anforderungen entstehen. Ergebnisse dieser „historisch gewachsenen“ Systeme können mangelnde Integration, planlose Sicherheitsstandards und eine Menge anderer systemimmanenten Unzulänglichkeiten sein. Eine Information Security Architecture besteht aus mehreren Ebenen [CIS10, S158f].

Über allen steht die Ebene der Business-Architektur. Diese Ebene ist stark mit den Geschäftszielen verbunden und stellt sicher, dass die Security-Architektur an den Zielen und Anforderungen des Business ausgerichtet ist. Hier werden Antworten auf eine Reihe von Fragen, beispielsweise „Was macht das Business? Wo liegen die Betätigungsfelder? Wer macht es? Welche Informationen werden verwendet, um die Ziele zu erreichen? Wo wird es gemacht?“

Durch die Beantwortung dieser Fragen kann für die Entwicklung der Security-Architektur eine umfassende Strategie- und Prozesslandkarte sowie Organigramme erstellt oder herangezogen werden.

Auf Basis dieser Informationen kann der Informationsfluss innerhalb des Unternehmens bestimmt werden. Durch die Beantwortung der Fragen „Welche Applikationen werden verwendet, um die Geschäftsziele zu erreichen?, Welche Daten werden von diesen Applikationen benötigt?, Welche Integrationsmethoden existieren, um den Austausch dieser Informationen zu ermöglichen?“, kann die Informationsarchitektur erstellt werden. Nur wenn diese Technologien und Prozesse verstanden werden, kann eine Strategie entwickelt werden, welche die Sicherheit der Daten gewährleistet und die Geschäftsprozesse nicht behindert.

Komponenten einer Enterprise Information Security Architecture

Letztendlich ist es notwendig, die bestehende technologische Architektur, welche die Applikationen und Prozesse unterstützt, zu analysieren. Die technologische Architektur der meisten Unternehmen ist sehr komplex, da sie gewöhnlich viele verschiedene Technologien, die auf unterschiedlichen Plattformen in einem heterogenen Umfeld laufen, umfasst. Die Sicherheit dieser Technologien zu gewährleisten, während in Geschäftsprozessen der nötige Zugriff auf die Informationen zur Verfügung gestellt wird, kann eine schwierige Aufgabe sein [BPC10].

Es ist wichtig, die gesamte Hardware zur Unterstützung der Geschäftsprozesse zu kennen, beispielsweise die Standorte und Zwecke der Server, die Art, wie Rechner auf die Informationen auf diesen Servern zugreifen etc. Es sollten Netzpläne (LAN, WAN) der Organisation erstellt werden, damit die verschiedenen nötigen Verbindungen innerhalb und außerhalb der Organisation erkannt und geschützt werden können.

Zu Beginn der Entwicklung und Implementierung eines Information Security Programs sollten zumindest High-Level-Architekturen vorbereitet sein. Viele Organisationen haben jedoch keine Enterprise- oder Security-Architekturen entwickelt, obwohl die Anpassung einer entsprechenden Architektur essentiell für die Entwicklung und Umsetzung eines Information Security Programs ist. Es existiert eine Vielzahl von Architekturansätzen, die Security-Aspekte beinhalten oder sich ausschließlich auf Security beziehen. Dazu zählen beispielsweise

Open Security Architecture
The Open Group Architecture Framework (TOGAF)
Model-driven Architecture (MDA) der Object Management Group
Ownership, Business Processes, Applications, Systems, Hardware, and Infrastructure business and IT methodology and framework (OBASHI)
SABSA comprehensive framework for Enterprise Security Architecture and Service Management

Die Ziele all dieser Ansätze sind im Wesentlichen gleich, allerdings variieren die Methoden sehr stark. Sofern kein Architekturansatz im Unternehmen besteht, können diese Methoden für einen Einsatz evaluiert werden.

Steuerungsmaßnahmen (controls)

operative

Aktivitäten reguliert, steuert oder kontrolliert. Steuerungsmaßnahmen sind definiert als die Policies, Procedures, Practices, Technologien und organisatorische Strukturen, die entwickelt wurden, um sicherzustellen, dass die Geschäftsziele erreicht werden können und unerwünschte Ereignisse verhindert oder erkannt und korrigiert werden. Zum Beispiel ist eine Zutrittskontrolle eine präventive Steuerungsmaßnahme, die unautorisierten Zutritt, der zu Systemschäden führen kann, verhindert. Intrusion Detection ist eine detektive Steuerungsmaßnahme, da durch sie unautorisierter Zugriff erkannt werden kann. Backup und Wiederherstellung ist eine korrigierende Steuerungsmaßnahme, welche die Wiederherstellung von Systemen ermöglicht, wenn ein Ereignis zum Verlust oder irreparabler Schädigung von Daten führt.

Produkte aus der Sicherheitstechnik bieten oft Kombinationen dieser drei Typen von Steuerungsmaßnahmen. Eine Firewall beispielsweise kann einerseits Netzwerkverkehr auf Adress-,Protokoll- und Portebene filtern, um Zugriffe einzuschränken (präventiv), kann aber auch den eingehenden Verkehr auf Attacken oder andere verdächtige Muster prüfen und bei der Erkennung Alarmmeldungen senden (detektiv).

Steuerungsmaßnahmen sollten so weit wie möglich automatisiert und systemtechnisch abgebildet werden, sodass es technisch nicht möglich ist, sie zu umgehen. Einige Mechanismen, die es Anwender*innen schwer machen, die Steuerungsmaßnahmen zu umgehen, umfassen beispielsweise folgende Prinzipen:

Bei der (logischen) Zugriffskontrolle wird gewährleistet, dass Benutzer*innen von Informationen identifiziert, authentifiziert und autorisiert werden, bevor sie auf die Informationen zugreifen können. Es gibt viele Methoden, um Zugriffskontrollen zu implementieren. Die meisten fallen in eine der beiden Kategorien Mandatory Access Control (MAC) oder Discretionary Access Control (DAC). MAC ist eine Methode der Zugriffskontrolle, bei der die Entscheidung über den Zugriff auf Informationen aufgrund von Regeln und Eigenschaften des Users und der Information getroffen wird. Modelle der MAC sind vor allem dazu geeignet, die Vertraulichkeit, Integrität und Verfügbarkeit der Daten zu garantieren. Bei der Zugriffsmethode DAC wird auf Basis der Identität eines Users entschieden, ob der Zugriff auf ein Objekt (Datei, Ressource) erlaubt wird. Die Zugriffsrechte werden je User festgelegt und können von Usern an andere weitergegeben werden. Welche Art der Zugriffskontrolle gewählt wird, hängt von den organisatorischen Anforderungen für die Datensicherheit ab.

Secure Failure bezieht sich auf ein Gerät, das die Informationsverarbeitung unterbricht, sobald es eine Fehlfunktion entdeckt, die den Zugriffskontrollmechanismus beeinträchtigen könnte. Beim Einsatz dieser Geräte muss jedoch bedacht werden, dass die Verfügbarkeit von Informationen beeinträchtigt werden kann.

Das Prinzip der geringsten Rechte (Least Privilege) bedeutet, dass der Zugriff auf Ressourcen so eingeschränkt wird, dass User nur mit jenen Rechten (z.B. lesen, schreiben) darauf zugreifen können, die tatsächlich benötigt werden, um ihre Aufgabe ausführen zu können.

Dem Prinzip der Untergliederung von Informationen (Need-to-know Prinzip) liegt die Idee zugrunde, den Zugriff auf Informationen so zu beschränken, sodass User nur auf jene Informationen zugreifen können, die sie benötigen, um bestimmte Aufgaben durchführen zu können.

Beim Prinzip der Funktions- oder Aufgabentrennung soll durch Aufteilung oder Übertragung von Aufgaben, Funktionen und Verantwortlichkeiten bei bestimmten, sensiblen Vorgängen (z.B. Zahlungsverkehr) auf verschiedene, voneinander unabhängig tätige Personen Missbrauch vermieden werden. So soll beispielsweise verhindert werden, dass ein User die Möglichkeit hat Rechnungen zu drucken und gleichzeitig durch administrative Rechte die/den Rechnungsempfänger*in vor und nach dem Druck ändern kann.

Durch das Prinzip der Transparenz soll es auch Laien möglich sein, die Art und Weise der Sicherheitsmechanismen in Systemen zu verstehen. Damit sollen alle Anwender*innen nachvollziehen können, welchen Einfluss und welche Auswirkungen deren operative Aktivitäten in den Systemen auf die Systemsicherheit haben. Transparenz kann oftmals dadurch erreicht werden, dass Systeme so einfach wie möglich gestaltet werden, um Verwirrung oder Unsicherheit bei den Anwender*innen zu vermeiden.

Steuerungsaktivitäten (control activities)

Steuerungsaktivitäten sind Abläufe und Praktiken, die hinreichende Sicherheit für das Erreichen von Geschäftszielen bieten. Aus dem Rahmen fallende Ereignisse sollen durch sie verhindert, aufgedeckt oder korrigiert werden. Steuerungsaktivitäten können physischer, technischer oder prozessorientierter Natur sein. Die Auswahl und die Gestaltung der Steuerungsaktivitäten basiert auf deren Effektivität, Risikominimierungspotential, aber insbesondere auch auf deren Aufwand, Kosten oder Restriktionen auf das Business. Die Summe sämtlicher (Schlüssel-) Steuerungsaktivitäten bildet ein Internes Kontrollsystem (IKS). Dabei werden durch die Gesamtstruktur sich gegenseitig absichernde Security Controls implementiert, die diese auf verschiedenen Ebenen anbringt („layered defense“). Insgesamt entsteht dadurch eine Art Netz von Steuerungsaktivitäten, die sich so gegenseitig absichern. Somit kann ein nicht entdeckter Fehler in der einen Aktivität noch durch eine andere Aktivität aufgedeckt werden. In der IT existiert mit COBIT eine ganzheitliche, etablierte und allgemein anerkannte Sammlung von Zielen für Steuerungsaktivitäten.

Beispiel: Einmal jährlich evaluiert die/der Durchführende die technischen Authentifzierungsmechanismen auf den Kernsystemen, -applikationen und -datenbanken. Sie/er vergleicht die Ergebnisse mit den Vorgaben aus der IT Security Policy. Eventuelle Abweichungen werden identifiziert und im Rahmen des Risikomanagements bewertet und in deren Defizitliste eingepflegt. Das Review wird dokumentiert und der/dem CISO per Email übermittelt.

Es ist festzuhalten, dass im Rahmen der Information Security auch Nicht-IT-Aktivitäten zu betrachten sind. Aspekte aus der physischen Sicherheit, dem Social Engineering, allgemeine Identifikation, Umgang und Speicherung von Information im Rahmen des Geschäftsprozesses müssen evaluiert werden. Auch sind applikationsspezifische IT-Steuerungsaktivitäten neben den allgemeinen (IT General Controls - ITGC) zu betrachten. Das sind jene Aktivitäten und Mechanismen, die inhaltlich dem Geschäftsprozess zuzuordnen sind, aber von IT-Mechanismen abhängig sind. Als Beispiel sind Eingabekontrollen zu nennen, etwa Prüfung auf Schwellwerte oder Plausibilität [CIS10, S61f][COB07].

Gegenmaßnahmen (Countermeasures)

Gegenmaßnahmen sind Schutzmechanismen, welche das Ausmaß der Schwachstelle hinsichtlich bestimmter Bedrohungen reduziert. Sie sind daher als zielgerichtete Steuerungsaktivitäten zu sehen [CIS10, S62].

Beispiel: Als Gegenmaßnahme für die Schwäche einer nicht den Passwortrichtlinien entsprechende Applikation gegenüber unautorisiertem Zugriff ist der Remote Access nur über eine zuvor eingerichtete sichere VPN-Verbindung mit Zwei-Wege-Authentifizierung (Einmalpasswort) möglich.

Oft sind diese kostenintensiver und aufwändiger und bedürfen dabei besonderer Aufmerksamkeit und müssen ständig auf deren Effektivität hinsichtlich der zugrundeliegenden Bedrohung überprüft werden. Sie sind als Ergänzung zu den gesammelten Steuerungsaktivitäten – dem Internen Kontrollsystem (IKS) – zu sehen [CIS10, S214].

Technologien

Mittlerweile existieren mannigfaltige Security-Technologien, die einer immer stärker zunehmenden Anzahl von Bedrohungen von Informationsressourcen entgegenwirken. Natürlich ist eine starke Technologie ein Herzstück von Information Security, kann aber keine Managementschwächen oder Defizite in Kultur und betrieblichen Abläufen kompensieren. Nur in Verbindung mit den anderen Bausteinen kann eine tragfähige Enterprise Information Security Architektur aufgebaut werden. Beispielhaft seien die folgenden bekanntesten Technologien aufgezählt (nicht ausschließende Liste) [CIS10, S63]:

Firewall- und Netzwerktechnologien
Identifizierungs-, Authentifizierungs- und Autorisierungsmechanismen
Intrusion Detection/Prevention Systeme
Antivirus-/Antispam-Infrastruktur
Public Key Infrastructure (PKI)
Biometrie
Kryptographie
Remote Access Technologien
Digitale Signaturen
Sichere mobile Verbindungen (Remote Access, VPN, sichere Protokolle)
Monitoring-Technologien
Security Information Management Systeme (z.B. Log-Korrelationen)

Information Security muss als Management-Prozess im Unternehmen und seiner Prozesslandschaft gut verankert sein. Je höher der Grad der Unabhängigkeit und der Stimmgewichtung in der Führungsebene, desto gewichtiger ist das Thema im Unternehmen akzentuiert. Organisationsstrukturen, wo das Thema Informationssicherheit als notwendiges Anhängsel betrachtet wird und auch in sehr operativen Bereichen positioniert ist, sind von vornherein ein Hemmschuh.

Sind solche Voraussetzungen gegeben, bedarf es eines Information Security Frameworks, das die technischen, operativen, administrativen und management-relevanten Komponenten definiert. Darüber hinaus legt es organisatorische Verantwortlichkeiten, Schnittstellen, Ziele und erwartete Ergebnisse für jede Komponente fest.

Naturgemäß nehmen technische Komponenten breiten Raum ein, die als natürliche oder zusätzliche Steuerungstechnologien sowie management-unterstützende Technologien kategorisiert werden können. Basis-Steuerungstechnologien sind Out-of-the-box-Sicherheitsfunktionen, etwa Authentifizierungsmechanismen, Zugriffsprotokollierung oder verschlüsselte SSL-Übertragung eines Webservers. Sie sind natürliche Sicherheitsbausteine des Webservers und werden üblicherweise von der IT betrieben. Zusätzliche Steuerungstechnologien sind spezialisierter angelegt als die natürlichen und werden zumeist in Zusammenarbeit von IT und Security-Spezialist*innen angewendet. Identity Management oder Zugriffsmanagement-Technologien sind mögliche Beispiele dafür. Gemeinsam bilden diese Kategorien die technische Sicherheitsarchitektur. Management-unterstützende Technologien bereiten operative Daten auf und aggregieren diese zu Managementinformation. Beispielsweise können das Security Information Management Systeme (SIM) sein, die verschiedene Daten aggregieren, korrelieren und daraus Informationen für das Management generieren. Andere Beispiele sind Log Analyzer oder Compliance Monitoring Scanner. Diese Systeme werden in der Regel ausschließlich durch die Information Security Teams betrieben. Generell ist es wichtig, zu hinterfragen, welche Steuerungsmaßnahmen wo platziert sind, wie effektiv sie sind, wie effizient sie sind, welche Richtung sie verfolgen und wie sie implementiert sind. Nicht überraschend, sollen die technischen Komponenten im Einklang mit den Geschäftszielen stehen, das Konzept eines Information Security Frameworks unterstützt dabei die erforderliche gesamtheitliche Sicht [CIS10, S204f].

Operative Komponenten sind die eigentlichen regelmäßig durchzuführenden Management- und administrativen Tätigkeiten, um den Sicherheitslevel sicherzustellen. Dies können Standardbetriebstätigkeiten, sicherheitsrelevante Geschäftsprozessaktivitäten oder Wartung und Administration der Sicherheitstechnologien sein und haben üblicherweise eine tägliche oder maximal wöchentliche Durchführungsfrequenz. Dies ist keine reine IT-Angelegenheit, vielmehr muss die/der Information Security Manager*in mit den Geschäfts- und Organisationseinheiten zusammenarbeiten, um die operativen Anforderungen erfassen und abdecken zu können. Es muss gemeinsam erörtert werden, wie z.B. Zugriffsberechtigungen, Security Event Monitoring und Analyse, Patch Management, Konfigurationsmanagement, Change und Release Management, Security Metriken, Messung und Reporting, Incident Response und Resolution zu erfolgen hat. Für jede operative Einheit muss ein Owner definiert werden, der gemeinsam mit ihm die Inputs, Outputs, Auslöser, Zeitplan, Prozess-Schritte, Erfolgsfaktoren, Eskalations- sowie Genehmigungsverfahren festlegt. Zusätzlich müssen qualitätssichernde Mechanismen in den Prozess eingebaut werden [CIS10, S205].

Die management-relevanten Komponenten umfassen strategische Aktivitäten wie Policy-Reviews, Entwicklung und Anpassung von Standards, sowie Überblicks-Kontroll-Tätigkeiten, wie Projektreporting und Controlling. Außerdem muss dafür gesorgt sein, dass Information Risk Management auf einer regelmäßigen Basis durchgeführt wird und die Kommunikation von Information Security ins Unternehmen sichergestellt ist. Hauptaufgabe ist die Gewährleistung, dass die Aktivitäten innerhalb des Programs mit den Geschäftszielen im Einklang stehen und gegebenenfalls Anpassungen initiiert werden [CIS10, S205].

Der Anteil administrativer Komponenten steigt mit der Bedeutung von Information Security als Managementfunktion. Somit sind finanzielle Administrationstätigkeiten, wie Budgetplanung, Total Cost of Ownership Analysen (TCO), Return on Investment Berechnungen (ROI), Einkauf, Bestandsmanagement in Bezug auf den Prozess Information Security zu tätigen. Auch sollten die im Unternehmen gültigen finanziellen Grundsätze ebenso hier angewendet werden. Personalmanagementfunktionen sind ebenso Teil der administrativen Aufgaben, etwa Personalplanung und -entwicklung, Recruitment, Rollenbeschreibungen, Entlohnung. Die klassischen Tradeoffs im Ressourcenmanagement zwischen operativen Tätigkeiten und Projektaufgaben sind auch hier zu lösen. Die restriktiven Faktoren Auslastung und Headcount zwingen zum Priorisieren von Aktivitäten – genauso wie bei anderen Geschäftsprozessen auch. Schulung, Awareness und Training von Sicherheitsrisiken, das Kommunizieren und Akzeptieren von Security Policies, Verhaltensrichtlinien, Verfahren zur sicheren Abarbeitung von Geschäftsfällen - z.B. Authentifizierungsprozeduren beim Service Desk müssen aus dem Prozess heraus gelöst und in die anderen Geschäftsprozesse eingebracht werden. Qualitätssicherungsaktivitäten runden den administrativen Part ab [CIS10, S206].

Personal

Die Mitarbeiter*innen sind – um es wenig diplomatisch auszudrücken – aus Sicht der Information Security ein gewisser Risikofaktor. Interne Aktivitäten haben – schon aufgrund des Zugangs der Mitarbeiter*innen zu Information – ein großes Schadenspotential als auch eine hohe Eintrittswahrscheinlichkeit. Der Auswahl von und dem Einholen von Hintergrundinformationen über sowie der Sicherstellung der persönlichen Integrität von Personal werden vor allem in Europa durch gesetzliche Vorgaben Grenzen gesetzt, die USA sind hier traditionell freizügiger im Umgang mit persönlichen Informationen. Policies, Richtlinien, Arbeitsanweisungen geben Verhaltensvorgaben an die Mitarbeiter*innen und müssen auch regelmäßig überprüft werden [CIS10, S63f].

Beispiel: Einholen eines Strafregisterauszugs bei einer Neuanstellung, Richtlinie über die Verwendung des unternehmenseigenen Email Accounts der/s Mitarbeiter*in für private Zwecke.

Interner Widerstand oder negative Einstellungen der Mitarbeiter*innen beeinflussen die Umsetzung der Information Security Strategie negativ. Vor allem muss dann unermüdlich Überzeugungsarbeit geleistet werden, was sehr zeitaufwändig ist. Andere Mitarbeiter*innen müssen über Anordnungen oder mehr oder weniger sanften Zwang motiviert werden, was deren innere Einstellung nicht nachhaltig verändern dürfte [CIS10, S68].

Die personellen Anforderungen für die Entwicklung eines Security Programs unterscheiden sich von jenen für die Umsetzung des Programs. Architekt*innen, Entwickler*innen, Tester*innen etc. die bei der Erstellung des Programs involviert sind, unterscheiden sich von jenem Personal, das die Systeme administriert, sobald sich diese im Normalbetrieb befinden. Verschiedene Rollen müssen für die Entwicklung des Programs definiert werden, wobei die klare Zuweisung von Verantwortlichkeiten zu den Rollen wesentlich für eine effektive Implementierung ist. Rollen sind wichtig für die Informationssicherheit, da sie die Zuweisung von Verantwortlichkeiten und Zugriffsrechten basierend auf den Funktionen ermöglichen, statt sie den Personen individuell zuweisen zu müssen. Diese rollenbasierte Zuordnung erleichtert die Administration. Der Aufbau einer sicherheitsbewussten Unternehmenskultur hängt von den Personen ab und wie sie in ihren Rollen ihre Aufgaben, in Hinblick auf den Schutz der Informationen, durchführen. Jede Person sollte sich darüber im Klaren sein, in welchen Zusammenhang die Informationssicherheit mit ihrer Rolle steht. Indikatoren für eine erfolgreich etablierte Sicherheitskultur sind die Einbindung der Verantwortlichen für Informationssicherheit in Projekte zur richtigen Zeit, wenn Benutzer*innen sicherheitsrelevante Ereignisse erkennen und melden, wenn die Organisation die/den Information Security Manager*in kennen und wenn die Mitarbeiter*innen ihre Rolle beim Schutz von Informationen kennen.

Das Personal gilt auch als die kostenintensivste und damit wertvollste Ressource. Dies gilt es so effizient wie möglich für das Information Security Program einzusetzen. Die Zuweisung von Rollen zu Mitarbeiter*innen, die Abdeckung aller Rollen durch Personen sowie die Vermeidung von Unvereinbarkeiten in den Verantwortlichkeiten für die einzelnen Mitarbeiter*innen und die Anpassung an die sich ändernden Rahmenbedingungen ist Aufgabe der Information Security Managerin bzw. des Managers [CIS10, S215].

Organisationsstruktur

Vor allem in international operierenden Unternehmen ist es ausschlaggebend, welche Struktur für das Thema Information Security gewählt wird. Eine zentral agierende Information Security kann einheitliche Standards und Vorgaben formulieren, jedoch die Überprüfung derselben in den lokalen Einheiten erschweren. Zudem existieren mitunter verschiedene lokale Restriktionen, die beachtet werden müssen. Als Beispiel sei das oben erwähnte Thema Datenschutz in Europa und Amerika angeführt. Eine ähnliche Problematik kann aber schon bei Unternehmen aufgeworfen werden, die verschiedene Standorte haben und vor allem durch Zukäufe vieler kleiner Unternehmen entstanden sind. Die unterschiedlichen Kulturen, Abläufe, Technologien, Einzelregelungen erschweren die Etablierung einer einheitlichen zentralen Information Security. Ein dezentraler Ansatz hat den Vorteil, dass Information Security Administrator*innen näher beim lokalen User operieren, schneller auf Informationssicherheitsthemen – Changes oder Incidents – reagieren können. Wichtig ist hierbei, dass trotz aller Unterschiede die Gesamtverantwortung und Ziele von Information Security klar und konsistent sind [CIS10, S64].

Die Organisation selbst beschränkt oder ermöglicht bestimmte Information Security Aktivitäten. Je größer und verteilter die Organisation, desto schwieriger und herausfordernder ist die Etablierung einer übergreifenden Information Security Strategie. Hier ist auch das Management gefordert, entsprechende Unterstützung angedeihen zu lassen [CIS10, S68].

Verantwortlichkeiten

Es muss im Unternehmen klar herausgestrichen werden, dass Information Security jede/n Mitarbeiter*in betrifft und jede/r auch dafür verantwortlich ist. Der Gedanke von Information Security muss demnach an jede Zielgruppe im Unternehmen gerichtet sein, um effektiv funktionieren zu können. Dabei ist die/der Endbenutzer*in besonders gefordert. Durch den integralen Ansatz soll ein sensibles Umgehen mit Information Teil der Unternehmenskultur werden. Darüber hinaus gibt es spezielle Rollen und Verantwortlichkeiten, die in Jobbeschreibungen explizit aufgezählt werden müssen [CIS10, S64].

Beispiel: Spezielle Richtlinien im Umgang mit Information für Systemadministrator*innen.

Skills

Eine ganze Reihe von Security Incidents entsteht durch unsachgemäßes Umgehen mit Systemen, Datenbanken, Applikationen und Daten. Daher sollen die Mitarbeiter*innen entsprechende Skills aufweisen, wenn sie im Rahmen ihres Arbeitsinhaltes sensible Tätigkeiten durchführen [CIS10, S64].

Beispiel: Superuser-Berechtigung für die/den Chefsekretär*in im ERP-System für Aufbereitung von Daten für ihren Vorgesetzten. Diese Berechtigung kann bei unsachgemäßem Einsatz Datenverlust, Löschung oder Änderung von geschäftskritischen Informationen nach sich ziehen.

Nicht nur die Mitarbeiter*innen selbst, auch deren Skills müssen weiterentwickelt und immer neu bewertet werden, da die eingesetzten Technologien, das erforderliche Wissen, das Information Security Program sowie die Mitarbeiter*innen und ihr Einsatzgebiet ständigen Veränderungen unterworfen ist. Für nicht ständig gebrauchte Skills ist eine Fremdvergabe oder das Engagement eines externen Beratungsunternehmens eine mögliche Lösung [CIS10, S215].

Awareness und Training

Bedingt durch die Tatsache, dass Information Security jede/n Mitarbeiter*in betrifft und diese auch dafür Verantwortung trägt, kommt Awareness und Training eine besondere Bedeutung zu. Es geht hierbei darum, die erstellten Policies, Standards, Abläufe, Guidelines sprichwörtlich „unters Volk“ zu bringen, das Thema ständig präsent zu halten, sodass es sukzessive in die Unternehmenskultur einfließt. Dies kann mit Security Awareness Programs, Einzelaktionen, aber auch spezifischen Audits beim End-User erreicht werden. Dies muss aber auf die Zielgruppen abgestimmt sein und regelmäßig erfolgen. Auf lange Sicht gesehen ist eine Investition in Security Awareness, Training und Schulung kosteneffizient, da gut geschulte Mitarbeiter*innen die Gesamtsicherheit im Unternehmen stärken, bei Security Incidents schneller reagieren und somit das Schadensausmaß nicht im vollen Ausmaß realisiert wird [CIS10, S64f].

Beispiel: Umgang mit Passwörtern – aber richtig! Mitarbeiter*innen unseres Informationssicherheitsteams werden Sie in den nächsten Tagen am Arbeitsplatz besuchen und mit Ihnen die fünf wichtigsten Regeln im Umgang mit Ihren Passwörtern diskutieren.

Das Bewusstsein für Risiken und Sicherheitsmaßnahmen ist immer die letzte Verteidigungslinie für die Sicherheit von Informationen, Informationssysteme und Netzwerke: selbst wenn alle technischen und organisatorischen Maßnahmen versagen, kann ein mitdenkender Mensch unter günstigen Umständen noch immer das Ärgste verhindern. Awareness Programs zielen daher auf alle Mitarbeiter*innen ab und sollten auch Partnerunternehmen und Hersteller einbinden. Die Themen für Awareness Programs können je nach Organisation variieren, und beinhalten beispielsweise das Sichern relevanter Dateien, die Auswahl eines sicheren Passworts und Schutz des Passwortes, Erkennen von Social Engineering, das Erkennen und Melden von sicherheitsrelevanten Incidents etc.

Security Awareness Programs bestehen oft aus Online-Trainings, Publikationen, Aussendungen per Email, sichtbarer Ausführung von Sicherheitsregelungen, NDA-Regelungen oder expliziten Trainings, müssen jedoch ständig erneuert werden. Der Erfolgsfaktor für ein derartiges Security Awareness Program ist die Ausrichtung auf das Zielpublikum und die Frequenz, aber auch adäquate Messkriterien, was mitunter schwierig ist [CIS10, S215].

Audits

Interne und externe Audits haben eine Qualitätssicherungsfunktion. Sie vergleichen die Ist-Situation mit den Vorgaben und Rahmenbedingungen und prüfen somit die Compliance. Trotz der Tatsache, dass Audits in vielen Fällen aus dem Finanzbereich initiiert werden, bieten diese Audits wichtige Informationen für die/den Information Security Manager*in. Insbesondere die Themen IKS, SOX404, ISAE3402 o.ä. bieten Implikationen für Information Security [CIS10, S65].

Beispiel: Beim IKS-Audit der Steuerungsaktivität „Review von Authentifizierungsmechanismen“ wurde festgestellt, dass die Authentifizierung gegenüber der Unternehmensdomain nicht – wie in der IT Security Policy definiert – zwei zusätzliche Sonderzeichen im Passwort erfordert. Wir empfehlen die Änderung der Passworteinstellung und dadurch technische Sicherstellung der Passwortstruktur.

Die/der Information Security Manager*in sollte eng mit den Auditor*innen zusammenarbeiten, intensiven Informations- und Wissensaustausch betreiben und gemeinsam getragene Lösungen für Feststellungen finden. Die Ausgewogenheit des Auditplans und die Auffassung der Auditorin bzw. des Auditors, eben nicht mit eisernen Besen durch die Organisationseinheiten zu kehren, sondern stattdessen als Berater*in und Qualitätssicherer die Mitarbeiter*innen dort abzuholen, wo sie stehen, sind essentielle Erfolgsfaktoren. Nur dann können sich Audits als starker Mechanismus, die Sicherheitskultur im Unternehmen im positiven Sinne zu prägen, etablieren [CIS10, S215f].

Sicherstellung von Compliance

Verletzung von Informationssicherheit stellt immer eine Aufgabe für Information Security Manager*innen dar. Gerade auf Management-Ebene stellt die Sicherstellung von Compliance ein großes Problem dar. Falls keine Managementunterstützung dafür zu erwirken ist, mag es schwierig sein, dies auch in den unteren Ebenen zu gewährleisten. Konsistente Regelungen, klare Kommunikation und gemeinsame Umsetzung sind dabei wesentlich [CIS10, S66].

Prozesse für ein Durchsetzen der Compliance müssen während der Entwicklung des Programs berücksichtigt werden, um die Effektivität und Handhabbarkeit nach Implementierung des Programs gewährleisten zu können. Das Durchsetzen der Compliance bezieht sich dabei auf jede Aktivität innerhalb des Information Security Programs, das entwickelt wird, um die Compliance mit den Sicherheitsrichtlinien, Standards und Policies der Organisation sicherzustellen. Die Möglichkeiten, die Einhaltung der Compliance überwachen und durchsetzen zu können, muss speziell bei prozessorientierten Maßnahmen berücksichtigt werden. Komplexe Kontrollprozesse, die nicht durchzusetzen oder schwer zu überwachen sind, bringen einerseits wenig Nutzen und können andererseits selbst wiederum ein Risiko darstellen. Prozesse für die Durchsetzung der Compliance können als zusätzliche Kontrollstufe angesehen werden, die prüft, ob festgelegte und vorgegebene Verfahren und Abläufe befolgt werden. Bei einem Verfahren zum Zurücksetzen eines Passworts kann ein Prozess für die Durchsetzung der Compliance so gestaltet sein, dass ein Supervisor zufällig Helpdesk-Calls überprüft und jeden Agent, der nicht die Identität der Anruferin bzw. des Anrufers vor dem Zurücksetzen des Passworts prüft, vermerkt. Die Compliance wird anschließend dadurch durchgesetzt, dass die vermerkten Agents zunächst verwarnt werden und bei weiterer Nichtbefolgung mit Konsequenzen rechnen müssen.

Audits sind eine Momentaufnahme, die Sicherstellung von Compliance dagegen ist ein laufender Prozess. Die Verantwortlichkeiten für Compliance sind üblicherweise im Unternehmen verteilt, nur selten gibt es explizite Compliance-Abteilungen. Aus der Information Security heraus gilt es, diesen laufenden Prozess zu initiieren, ihn ständig abzustimmen und zu forcieren sowie bei Feststellungen oder Vorfällen Verbesserungsmaßnahmen zu setzen [CIS10, S216].

Regelmäßige Bedrohungsanalyse (Threat Analysis)

Eine Bedrohungsanalyse ist Teil des Risikomanagements.

Bedrohungen verändern sich ständig. Daher können die regelmäßigen Bedrohungsanalysen auch als Informationsquelle für das Information Security Program herangezogen werden. Dieses muss ja schließlich auf die sich ändernden Rahmenbedingungen reagieren und muss demnach auch adaptiert werden können. Daher sollen auch die auf Basis vergangener Bedrohungsanalysen bereits etablierten Gegenmaßnahmen und Steuerungsaktivitäten evaluiert werden. Bedrohungsanalysen sollten zumindest jährlich durchgeführt werden, je nach Bedarf und Branche oder ereignisgesteuert auch öfter [CIS10, S216].

Regelmäßige Schwachstellenanalyse (Vulnerability Analysis)

Wiewohl auf technischer Ebene Schwachstellenanalysen über Netzwerkscans mittlerweile Usus sind, haben sie für Information Security nur einen überschaubaren Effekt. Prozesse und Equipment sind höchst verletzliche Komponenten, was aber in solchen Scans – aus nachvollziehbaren Gründen – nicht inkludiert ist. Um einen größeren Effekt für Information Security zu erzielen, müssen diese Komponenten auf einer regelmäßigen Basis analysiert werden [CIS10, S66].

Beispiel: Die Kernapplikation wurde auf ein Secure Operating System aufgesetzt. Dieses wird wöchentlich auf Schwachstellen über Vulnerability Scans analysiert, die erforderlichen Patches zeitnah eingebracht und gehärtet (Hardening). Das System selbst ist physisch in einem nicht zutrittsgesicherten IT-Infrastrukturraum ohne Absicherung der Umgebungssicherheit untergebracht.

Bei allen möglichen Zugriffspunkten wird getestet, ob der Zugriff nur durch berechtigte Benutzer*innen und für diese erlaubte Daten, Programme, Prozesse und Einrichtungen erfolgen kann.

Sowohl die bereits bekannten als auch durch neue Konstellationen neu hinzugekommenen Schwachstellen müssen überwacht und analysiert werden. Jegliche Konfigurations- oder Strukturänderungen im IT-System, sei es durch Umzüge, Changes oder nur Re-Konfigurationen, können potentielle neue Schwachstellen aufwerfen. Dies ist das primäre Einsatzgebiet von Vulnerability Scanning Tools, netzwerk- und host-basierender Intrusion Detection Systems. Die Crux ist hier, die Unmenge an erhaltener Information zu strukturieren, kategorisieren und zu bewerten, aber anschließend auch effektive Gegenmaßnahmen zu entwickeln. Daher ist ein formaler, strukturierter Ansatz von Vorteil, der auch wiederum – wenig überraschend – regelmäßig durchgeführt werden soll [CIS10, S216f].

Regelmäßiges Risk Assessment

Nur die Verbindung einer Bedrohung mit einer Schwachstelle wirft ein Risiko auf. Risiken verändern sich ständig und es bedarf einer regelmäßigen strukturierten Analyse der Risiken, denen sich das Unternehmen gegenüber sieht.

Analyse der Projektrisiken

Eine erfolgreiche Entwicklung eines Security Programs kann durch viele Einflüsse gefährdet werden. Gefahren lauern bei jeder Stufe der Entwicklung des Programs und -umsetzung und können beispielsweise in unklaren Zielen, mangelnder Strategie, schlechter Planung, zu geringen Ressourcen etc. oder schlicht Gleichgültigkeit begründet sein. Die Analyse dieser Risiken und Gefahren und der daraus ableitbaren potentiellen Verwundbarkeiten für ein erfolgreiches Projekt zur Entwicklung des Programs sollten direkt in die Entscheidungen des Entwicklungsprojekts einfließen, um den Erfolg der Umsetzung des Programs sicherstellen zu können.

Business Impact Analysis

Eine Business Impact Analyse wird durchgeführt, um die Auswirkung eines Verlustes der Verfügbarkeit einer Ressource zu bestimmen, festzustellen wie sich diese Auswirkungen mit der Zeit steigern, das Minimum an benötigten Ressourcen für eine Wiederherstellung zu ermitteln und die Wiederherstellung von Prozessen und unterstützenden Systemen zu priorisieren. Die Ergebnisse der Prozesse der Business Impact Analyse liefern wichtige und kritische Inputs sowohl für die Entwicklungsphase, als auch für das laufende Management eines Information Security Programs.

Genauso, wie sich Bedrohungen und Schwachstellen verändern, entwickeln sich bekanntlich auch die Risiken für Unternehmens- und Informationswerte. Aus diesem Grunde sollte ein Risk Assessment mindestens jährlich, mitunter je nach Branche und Erfordernis auch unterjährig – von quartalsweise bis in extremen Fällen monatlich – und mit Schwerpunktthemen durchgeführt werden. Es ist wichtig, dass den Stakeholdern die aktuellen Risiken bewusst sind, da diese in deren Entscheidungsfindungen einfließen müssen. Ein passender Rahmen dafür kann das Information Security Committee sein [CIS10, S217].

Versicherung

Bestimmten Risiken – vor allem jene mit einem hohen Schadenspotential und einer geringen Eintrittswahrscheinlichkeit – können durch Versicherungen entgegengewirkt werden. Zumeist wird dies aber als letztes Mittel, wenn sonst keine andere Möglichkeit besteht, eingesetzt. Dabei kann der Schaden an sich oder Haftungen zur Versicherung transferiert werden. Auch Garantieversicherungen für Handlungen der eigenen Mitarbeiter*innen – etwa Geheimnisverrat oder Veruntreuung – sind üblich [CIS10, S66].

Ressourcenabhängigkeitsanalyse (Resource Dependency Analysis)

Ähnlich der Geschäftsauswirkungsanalyse untersucht die Ressourcenabhängigkeitsanalyse die Auswirkung des Risikos, jedoch auf Ebene der Hard- und Software. Es werden die vorhandenen Ressourcen (Systeme, Hard- und Software, Netzwerk etc.) den Abhängigkeiten (Eingabeprozesse, Storage-Größe etc.) gegenübergestellt. Es betrachtet also den technischen Unterbau von Business Continuity Management (BCM) und ist somit Teil des Disaster Recoverys (DR) [CIS10, S66].

Finanzielle und operative Auswirkungen von Unterbrechungen oder Störungen werden dabei nicht berücksichtigt, weshalb eine Resource-Dependency-Analyse eine Business-Impact-Analyse nicht ersetzen kann.

Outsourcingverhältnisse

Outsourcingbeziehungen werfen Risiken auf. Die Aufteilung von Ressourcen und demnach Know How, die Separierung von Verantwortlichkeiten stellen Reibeflächen dar. Weiters gibt es unterschiedliche Ausprägungen von Policies, Standards, Abläufen, Guidelines, die zueinander in Einklang gebracht werden müssen. Ein kritischer Erfolgsfaktor ist die Schaffung eines Systems von Checks-and-Balances, sodass die Kundin bzw. der Kunde die Möglichkeit hat, die Servicequalität in möglichst allen Bereichen zu verifizieren [CIS10, S67].

External Security Service Providers

Abhängig vom Plan, der für die Implementierung der Security Strategie angewandt wird, bedarf es möglicherweise eines Outsourcings bestimmter Funktionen an einen Security Service Provider. Diese Security Services können entweder mittels Outsourcing oder Service Contracting von externen Dienstleistern bezogen werden. Der Unterschied liegt darin, dass bei Service Contracting die/der Information Security Manager*in die Verantwortung für das Security Service und für die Performance des Services beibehält. Typischerweise bestimmt der ISM was der Service Provider zu tun hat. Die Methode der Erfüllung wird gemeinsam festgelegt. Beim Outsourcing übernimmt der Service Provider die zusätzliche Verantwortung, festzulegen, wie die Sicherheitsanforderungen umgesetzt werden. Es ist wichtig zu verstehen, dass die gesetzliche Haftung und Verantwortung nicht durch Outsourcing abgegeben werden kann. Einige Services, die typischerweise von externen Dienstleistern erbracht werden umfassen beispielsweise Beratung bei Themen des Security Managements, Physische Sicherheit, Überprüfung von Personen (Screening), Forensische Untersuchungen und Wiederherstellung, Penetrationstests, Audits und Security Reviews.

Es können auch andere Arten der externen Unterstützung angenommen werden, um externe Fachkompetenz in das Security Program einbinden zu können. Bei „Security Network Roundtables“ kommen Expert*innen der Informationssicherheit ähnlicher Branchen in Diskussionsrunden zu Themen der Information Security zusammen. Institutionen für Security Training bieten Kurse oder Trainings für bestimmte Themen der Information Security wie beispielsweise Vulnerability Analysis oder Strategien für Plattformkonfigurationen, etc. an. Services zur Warnung von Sicherheitslücken und Schwachstellen liefern aktuelle Meldungen in Bezug auf die im Unternehmen eingesetzten Technologien.

Das Hereinholen externen Spezialistenwissens ist immer eine gute Möglichkeit, den eigenen Wissenstand zu evaluieren und neue Impulse zu generieren. Es ist auch eine Möglichkeit, eine gewisse „Betriebsblindheit“ zu überwinden und Themengebiete objektiv zu auditieren. Diese Tätigkeiten sollen im Einklang mit dem Information Security Program stehen [CIS10, S218].

Andere Provider

Neben den explizit security-gerichteten Dienstleistern kann sich die/der Information Security Manager*in anderen Support- und Qualitätssicherungseinheiten bedienen, wie das weiter oben bereits nahegelegt wurde. Diese Organisationseinheiten sind Interne Revision, Rechts- und Personalabteilung, Risikomanagement, Informationstechnologie, Compliance-Funktionen. Die Breite des Themas erfordert einen breiten Konsens, viel Abstimmungsarbeit, führt aber dabei zu einer breiten Unterstützung im Unternehmen und bei den Mitarbeiter*innen [CIS10, S218].

Qualitätssicherung

Es gibt im Unternehmen eine Reihe von qualitätssichernden Funktionen, die auch als Teil von Informationsressourcen anzusehen sind. Personal- und Rechtsabteilungen, Compliance-Beauftragte, Revision und Audit, Einkauf als Organisationseinheiten, aber auch Versicherungen, Disaster Recovery, physische Sicherheit, Schulung, Projektmanagement, Change Management, Qualitätsmanagement – jedes Thema liefert Inputs für Information Security, wenngleich dies nicht immer effizient in das Unternehmen integriert ist. Die Entwicklung der Information Security Strategie muss versuchen diese verschiedenen Quellen friktionsfrei miteinzubeziehen [CIS10, S67].

Technische Maßnahmen (technical controls)

Technische Maßnahmen stellen sicher, dass der Zutritt zum Gebäude des Unternehmens und zu den Informationen in den Systemen gesichert ist. Folgende Maßnahmen gehören zu einem technologischen Standardsicherheitskonzept [Siegel, Sagalow, Serritella in ISM03, S356ff]:

Physische Zutrittskontrolle umfasst alle Maßnahmen, die den Zutritt zum Gebäude, zum Rechenzentrum und zu den einzelnen „Points of Access“ (z.B. Computer oder Terminals) zu Daten und Systemen abschirmen. Dabei können Tools wie biometrische Erkennungssoftware, Zutrittssysteme, Videoüberwachung etc. zur Anwendung kommen. Natürlich gehört auch die physische Sicherung von Ein- und Ausgängen durch Sicherheits- und Empfangspersonal ebenfalls in diesen Bereich.
Netzwerksicherheit beinhaltet alle Maßnahmen, die einen unberechtigten Zugriff auf die Systeme im Unternehmen verhindern sowie mögliche unautorisierte Zugriffe mittels geeigneter Tracking Software erkennen und eine Alarmierung auslösen. Zu den Standardtools in diesem Bereich sind Firewalls, Intrusion Detection Systems (IDS) welche die Hauptknotenpunkte im Netzwerk überwachen und mit Monitoring Systemen verbunden sind, aber auch Antivirus Software.
Anwendungssicherheit ist die Sicherung von einzelnen Applikationen vor unautorisiertem Zugriff. Dabei sind nicht nur auf Betriebssystemebene geeignete Methoden zu verankern als auch auf Einzelapplikationsebene und Datenbankebene. Dabei ist es wichtig, sowohl eine Authentifizierung des Users durch das System zu haben als auch einen verlässlichen User Management Prozess zu implementieren. Damit wird einerseits sichergestellt, dass nur berechtigte Mitarbeiter*innen einen Zutritt erhalten und beim Zugang zum System identifiziert werden.
Daten-Backup und Archivierung verhindern einen ungewollten Verlust von Daten durch einen Angriff von außen mit bösartiger Schädigungsabsicht, aber auch durch Fehler im Unternehmen. Verschlüsselung der Daten ermöglicht eine zusätzliche Sicherheit im Falle von Datendiebstahl. Auch sollten kritische Systeme redundant betrieben werden, um Verluste aufgrund von Systemausfällen zu vermeiden.

Rahmenbedingungen

Eine Vielzahl an Rahmenbedingungen muss bei der Entwicklung einer Information Security Strategie beachtet werden. Durch diese werden Optionen möglich, verhindert, beschränkt, begünstigt oder gefährdet.

Bei der nachfolgenden Umsetzung eines Information Security Programs wird man mit einigen Schlüsselaspekten konfrontiert, die für sich allein entscheidend zum Erfolg oder Misserfolg beitragen. Es gilt, diese Aspekte zu identifizieren und so zu beeinflussen, dass sie im Sinne der Information Security ausgerichtet werden.

Rechtliche und regulative Rahmenbedingungen

Eine der weitreichendsten Einflüsse auf das unternehmerische Handeln hat der Gesetzgeber. Dessen Vorgaben, Grenzen, Bedingungen werden durch die gültigen Gesetze repräsentiert. Als Beispiele seien Datenschutz, intellektuelles Eigentum, Arbeitsrecht, Unternehmensrecht, Steuerrecht, Vertragsrecht oder Strafrecht genannt. Darüber hinaus gibt es spezifische Branchen- oder Technologie-Regelungen, etwa im Banken- und Finanzdienstleistungsbereich, in der Telekommunikation, in der Medizin- und Gesundheitsbranche oder durch Regelungen bei digitalen Signaturen, elektronischer Rechnungslegung oder E-Commerce. Verschärft wird die rechtliche Situation dann zusätzlich, wenn das Unternehmen in Einflussbereichen von verschiedenen Gesetzgebern steht, etwa durch Teilnahme in verschiedenen Märkten oder durch das Betreiben lokaler Standorte in anderen Staaten. Natürlich impliziert dies Restriktionen bei Datenübertragung und Informationsaustausch – etwa im Rahmen des Reportings. Weiters bestehen noch zusätzliche Konzern- oder Gruppenregulative, die es ebenfalls zu beachten gilt. Diese sollten tunlichst nicht im Konflikt mit gesetzlichen Vorgaben stehen. Außerdem muss die Information Security Strategie Inhalt und Nachvollziehbarkeitsanforderungen von Geschäftsfällen, sowohl aus Geschäfts- als auch rechtlicher Sicht gewährleisten. Diese können natürlich aufgrund der Anforderungen unterschiedlich gestaltet sein, zumindest muss aber die rechtliche Bedingung erfüllt werden. Selbstredend müssen diese Vorgaben in die Information Security Strategie einfließen [CIS10, S67].

Bei der Entwicklung des Information Security Programs gilt es aus Sicht von Information Security sicherzustellen, dass die Rechtsabteilung nicht nur rein reaktiv auf Vertragswesen und gesellschaftsrechtlichen Fragestellungen beschränkt bleibt, sondern sich aktiv auch um informationssicherheits- und technologierelevante Aspekte kümmert. Umgekehrt ist es auch keine Bringschuld der Rechtsabteilung, da die eigentlich Betroffenen sehr wohl am besten über deren gesetzlichen Rahmenbedingungen Bescheid wissen und von neuen Entwicklungen Kenntnis erlangen. Daher können regelmäßige Reviews sowohl von Betroffenen-, Informationssicherheits- als auch rechtlicher Seite initiiert werden und bedürfen enger Zusammenarbeit. Dies schließt auch arbeitsrechtliche Themen mit ein [CIS10, S218].

Physische Rahmenbedingungen

Es gibt einige physische Einflussfaktoren, welche die Information-Security-Strategie beeinflussen. Diese sind Kapazität, Raum- oder Platzbedarf, Verfügbarkeit oder Umgebungsgefahren wie Wasser, Feuer, Rauch, Erdbeben, potentiell gefährliche Aktivitäten in der näheren Umgebung – etwa eine Kaserne in der Nachbarschaft oder in der Einflugschneise eines Flughafens [CIS10, S67f].

Trotz der fortschreitenden Ortsunabhängigkeit, Virtualisierung, Schichtenmodellen, Globalisierung – irgendwo müssen die Systeme, also die Hardware-Komponenten an sich, stehen. Dies sollte ein abgeschlossener Sicherheitsbereich sein, der auch speziellen Schutzmechanismen unterworfen ist, denn Zugriff auf die Systeme bedeutet in der Regel auch Zugriff auf die darin vorhandene Information. Dazu haben sich auch mittlerweile State-of-the-Art-Mechanismen etabliert. Es sichern Zutrittsmechanismen, wie elektronische Zugangskontrollen, Vereinzelungsanlagen, Codes oder auch biometrische Verfahren den Zugang. Überwachungseinrichtungen wie Kameras, Bewegungsmelder, Sensoren beobachten die Situation innerhalb dieser Zone. Zur Überwachung hinsichtlich der Umgebungssicherheit, also Feuer, Wasser, Rauch, Brand, Erschütterung werden entsprechende Alarmierungsanlagen eingesetzt. Strom und Klima sind mit Redundanzmaßnahmen, Ersatz- oder Überbrückungseinrichtungen abgesichert. Treten Ereignisse ein, welche die Umgebungssicherheit negativ beeinträchtigen, treten Disaster-Recovery-Pläne in Kraft. Diese profitieren von der Tatsache, dass die physischen Sicherheitsmaßnahmen zeitnah alarmieren und dass die IT-Landschaft den vorgegebenen Policies und Standards folgt – um an einem Notfallstandort möglichst rasch nach einem IT-Desaster die Systeme und damit die Business Services wieder – wenn auch möglicherweise in einer rudimentären Form – anbieten zu können [CIS10, S174].

Die Vertraulichkeit, Integrität und Verfügbarkeit (CIA) von Information kann auch durch unsachgemäße physische Handhabung beeinträchtigt werden. Dies umfasst Beschädigung, Zerstörung, Sabotage, unberechtigten Zutritt. Der physische Ort, wo sich Informationen in geballter Form befinden, soll eine eigene Sicherheitszone bilden und entsprechend der Kritikalität der Systeme, der Sensitivität der Information, der Bedeutung der Applikationen und der Höhe der Unternehmenswerte geschützt werden. Dies kann durch physische Sicherheitsmaßnahmen erreicht werden, also elektronische Zutrittskontrolle, Bewegungsmelder, Glasbruchdetektoren, Alarmanalage, Gitterkäfigen oder ähnlichem. Zu solche Sicherheitszonen sollen nur jene Mitarbeiter*innen Zutritt erlangen, die dies für die Erfüllung ihres Arbeitsinhaltes auch benötigen. Eventuelle Regelungen für Subdienstleister, externe Besucher*innen sind in den Policies für physische Sicherheit zu berücksichtigen. Darüber hinaus soll den Umgebungsgefahren – also geographisch bedingte Rahmenbedingungen wie Feuer, Wasser (Flut), Erschütterung (Erdbeben), Rauch, Strom, Klima oder Umgebungsgefahren (Kasernen, chemische Industrie, Atomkraftwerke, Flughäfen, etc.) begegnet werden und etwaige Risiken von vornherein minimiert werden. Zum Beispiel ist es ratsam, die Rechenzentrumsräumlichkeiten nicht direkt unter einer Kantine oder Toiletten zu positionieren. Problematischer ist der Schutz von Client-PCs in anderen Unternehmensbereichen, die üblicherweise geringeren Umgebungsschutz haben. Auch hier sind aber allgemeine Zutrittskontrollen und logische Zugriffsmaßnahmen Teil des Minimalschutzes. Auch sind Regeln hinsichtlich Datenquellen (DVD, CD, USB, lokale Festplatte, Netzlaufwerke, Backupbänder) zu treffen. Gerade diese Art der Datenübertragung, bei der große Datenmengen abgezogen und aus dem System entfernt werden können, war seit jeher eine Herausforderung für Information Security [CIS10, S218f].

Ethik

Ethisches Verhalten der Kund*innen oder der Gesellschaft kann ebenfalls Auswirkung auf die Information Security Strategie haben, da sie auch Auswirkung auf das Bild des Unternehmens in der Öffentlichkeit haben. Dies muss das Unternehmen in die Überlegungen zur Entwicklung einer Information Security Strategie einbeziehen. Als Beispiel sind hier Umweltschutzorganisationen, Tierschützer*innen oder auch ethische-moralische Aspekte der eigenen angebotenen Dienstleistung oder des Produktes, etwa im Glückspielbereich, zu nennen [CIS10, S68].

Kultur

Unternehmenskultur hat – wie bereits schon erwähnt – naturgemäß Einfluss auf das Verhalten und die Einstellung der Mitarbeiter*innen. Eine Information-Security-Strategie, welche Regelungen aufstellt, die der Unternehmenskultur widersprechen, führt zu Widerstand und Nichtbeachtung [CIS10, S68].

Regionale Aspekte

Dieser Aspekt schlägt natürlich bei multinationalen Unternehmen besonders durch. Etwa ist die Überwachung von Mitarbeiter*innen in den USA stärker ausgeprägt als in Europa, Spanier*innen pflegen in der frühen Nachmittagsspitze nicht zu arbeiten und Engländer*innen beginnen traditionell erst um zehn Uhr vormittags zu arbeiten. Diese Kenntnisse gilt es für Information Security zu berücksichtigen, wobei das Gespräch mit den lokalen Personalabteilungen gesucht werden muss [CIS10, S219].

Politische Aspekte

Politische Strömungen sind ebenfalls ausschlaggebend für den Erfolg eines Information Security Programs. Security bringt Transparenz. Dies ist möglicherweise nicht in jeder Situation des Unternehmens gewünscht. Die/der Information Security Manager*in soll politische Strömungen, Verbindungen, Motivationen möglichst erkennen und sich unter Berücksichtigung dieser entsprechend positionieren. Dies ist keine leichte Aufgabe, da man mit dem Thema Information Security natürlich potentiell kontroversielle Standpunkte einnehmen muss.

Kosten

Eine der wichtigsten Rahmenbedingungen in allen unternehmerischen Aktivitäten stellen die Kosten dar. Sämtliche Aktivitäten müssen gerechtfertigt werden. Business Cases, Projektkalkulationen, Kosten-Nutzen-Analysen, Leistungsverrechnungen oder auch Konzepte wie Opportunitätskosten, Annual Loss Expectancy (ALE) oder Return on Investment (ROI) werden angewandt, um den kosteneffizientesten Lösungsweg zu ermitteln. Ein Information Security Program muss jedenfalls auch über Kosten gerechtfertigt werden, wiewohl Security einem Versicherungskonzept gehorcht: Man investiert, damit „nichts“ passiert. Daraus ergeben sich natürlich je nach Charakter der Manager*innen Argumentationsprobleme [CIS10, S68].

Ressourcen

Eine andere Rahmenbedingung bezieht sich auf die vorhandenen Ressourcen, sowohl Personen als auch Geld, Raum, Platz, Kapazität. Diese Restriktionen geben den Ausschlag für das weitere Vorgehen bei der Implementierung einer Information Security Strategie.

Finanzierung

Durchaus frustrierend sind unzureichende finanzielle Rahmenbedingungen, die nicht zuletzt aus Unverständnis für die Wichtigkeit von Information Security Management entstehen. Natürlich resultiert dies aus einem unzureichendem Management Support, wo wiederum Meinungsbildung – initiiert durch die/den Information Security Manager*in – gefragt ist: das Management erkennt den Wert und den Bedarf von Security Investments nicht, Information Security wird als Kostenträger mit wenig Wertbeitrag angesehen, es ist für sie der aktuelle finanzielle Ressourceneinsatz nicht ausreichend transparent dargestellt, die Branchentrends im Bereich Information Security werden nicht ausreichend wahrgenommen. Man muss nun im Rahmen des finanziellen Umfelds als Information Security Manager*in agieren und kann mit folgenden Strategien entgegenwirken [CIS10, S210]:

Anzapfen von Budgets aus anderen Organisationeinheiten, etwa Produktentwicklung, Audit, IT
Effizienzsteigerung des aktuellen Information Security Programs
Repriorisierung des Ressourceneinsatzes und von Projekten in Abstimmung mit dem Information Security Steering Committee

Personaleinsatz

Natürlich wird immer und überall unter der Arbeitslast gelitten. Allerdings müssen die richtigen Personen auch die richtigen – also ihren Skills entsprechenden – Tätigkeiten ausführen. Wichtig ist dabei zu wissen, wie es um die tatsächliche Auslastung der Mitarbeiter*innen bestellt ist. Dabei muss das Verhältnis der Produktivität zu Information Security Aktivitäten stimmig sein. Ist es nicht möglich, intern die Ressourcen so umzustellen, dass ein vernünftiges Arbeiten möglich ist, sind folgende Strategien möglich [CIS10, S210f]:

Zusammenarbeit mit anderen Organisationseinheiten, um Synergie-Effekte bei Information Security zu lukrieren
Evaluierung von Outsourcing-Möglichkeiten, insbesondere für ressourcenintensive operative Arbeit
Repriorisierung des Ressourceneinsatzes und von Projekten in Abstimmung mit dem Information Security Steering Committee

Fähigkeiten

Die Fähigkeiten und Möglichkeiten der vorhandenen Ressourcen, also Erfahrung und Skills müssen ebenfalls beachtet werden. Die vorhandenen Stärken sollten bei der Information Security Strategie adressiert werden, damit diese auch zum Erfolg führt [CIS10, S68].

Zeit

Eine hauptsächliche Rahmenbedingung neben den Kosten bildet der zeitliche Aufwand. Abgabetermine, Meilensteine, Geschäfts- und Quartalstermine beeinflussen sehr stark das Handeln und die Qualität. Für bestimmte Themen öffnet sich mitunter ein Window of Opportunity, z.B. bei der Finanzierung für ein Intrusion Detection System kurz nach einem Hacker-Angriff, der möglicherweise finanziellen Schaden bewirkt hat [CIS10, S68].

Risikoappetit

Der individuelle Risikoappetit einer Organisation bestimmt die Gestaltung der Information Security Strategie mit. Allerdings ist jedes unternehmerische Handeln mit einem Risiko besetzt. Daher ist der Aufwand für risikominimierende Maßnahmen dem potentiellen Schadensausmaß gegenüberzustellen. Das Restrisiko wird akzeptiert und direkt durch die Risikotoleranz bestimmt.

Informations-Infrastruktur und -Architektur

Im Zuge von umfassendem strukturellen Infrastruktur- und Architekturdesign einer IT-Landschaft gilt es vor allem den Überblick zu behalten. Eine IT-Landschaft kann sehr rasch sehr komplex werden, wenn neben Servern, Storage, Security Appliances wie Router und Firewalls, Netzwerk, Middleware, Datenbanken auch noch eine Vielzahl an möglicherweise verteilten Applikationen hinzukommt. Zusätzlich muss dieser Technologiemix noch konsistent mit Policies und Standards sein. Um diese Komplexität zu gewährleisten, werden Frameworks, Road Maps und eine modulare Schichten-Philosophie angewendet. Ähnlich der physischen Architektur gibt es Pendants zu Masterplänen, Bebauungsplänen, Bauvorschriften (die Policies und Standards). Für speziell eingesetzte Technologien sollten die entsprechenden Policies befolgt werden, etwa für Webapplikationen, Datenbank-Management-Systeme oder Telekommunikationsanwendungen. Zielführend ist es auch, eine einzige autorisierte Organisationseinheit für Architektur- und Infrastrukturdesign zu schaffen, die sowohl das Gesamtbild als auch die Business-Grundlage als Basis für die technische Implementierung im Fokus hat. Diese bedient sich gewisser Kontrollpunkte in der Architektur, um die Einhaltung der Vorgaben regelmäßig zu prüfen (Datenverkehr, Datentypen, Kommunikations-Metainformation o.ä.). Die Abstraktion auf ein Schichtenmodell erleichtert das konzeptuelle Verständnis. Jeweils eine Schicht beleuchtet einen Aspekt. Die Summe der Schichten muss dabei allerdings wieder widerspruchsfrei sein. Die Schichten können beispielsweise Perspektiven der Business-Verantwortlichen, Architekt*innen, Designer*innen, Implementierungsverantwortlichen, die Verkäufern und/oder die Facility Manager*innen einschließen (wie beim SABSA-Modell), die dann in den Schichten Kontext, Konzept, Logik, Physik und Komponenten der Information Security Architecture aufgehen. Sie ermöglichen auch eine spätere Detaillierung ohne das komplette Architekturmodell neu strukturieren zu müssen [CIS10, S170ff].

Feststellen des Information Security Status

In vielen Fällen wird es erforderlich sein, den aktuellen Status von Information Security zu bestimmen, sei es, wenn ein/e neue/r Information Security Manager*in die Arbeit aufnimmt oder bei regelmäßigen Bestandsaufnahmen oder Reviews. Auf Basis der gewonnenen Informationen können dann Strategien und weitere Schritte aufgesetzt werden. Bei der Evaluierung des Information Security Status gibt es Schlüsselkriterien, die immer wieder auftreten und die man in Folge anhand einer Standortbestimmung eruieren kann [CIS10, S211f]:

Ziele des Programs: messbar, realistisch; stehen sie im Einklang mit den Security Governance Zielen und den Unternehmenszielen; sind sie Bestandteil von Metriken, Reviews und werden sie gemeinsam getragen?
Compliance Anforderungen: sind sie definiert; werden sie kommuniziert; sind sie in Policies, Standards, Abläufen, Betrieb und Erfolgsfaktoren integriert, sind die Komponenten konsistent zu den Compliance-Vorgaben; was ist das Ergebnis von Reviews und Audits und werden die identifizierten Defizite überwacht, berichtet und zeitnah behandelt?
Management des Programs: existiert eine adäquate Dokumentation, wurde es an das Zielpublikum ausreichend kommuniziert, sind Rollen und Verantwortlichkeiten definiert, ist Information Security auch in den Kerngeschäftsbereichen präsent; wurden Policies und Standards definiert und formal autorisiert; existiert ein Information Security Steering Committee mit Business-Beteiligung; wie sind die Berichtslinien für Information Security aufgebaut; wurden administrative Funktionen integriert; gibt es aussagekräftige Metriken und erfolgt ein regelmäßiges Reporting; ist die Management-Aufsicht adäquat?
Betriebliches Security Management: bestehen Sicherheitsanforderungen für die betrieblichen Abläufe; sind spezielle Security-Standard-Abläufe definiert, gibt es einen Zeitplan für wiederkehrende operative (Review-) Tätigkeiten und sind diese dokumentiert, ist eine Funktionstrennung implementiert; bestehen Metriken und Reportingstrukturen, gibt es Management-Reviews?
Technisches Security Management: sind technische Standards und Konfigurationen für alle technischen Komponenten definiert und im Einklang mit Policies und den Anforderungen; gibt es eine Trennung von Test- und Produktivumgebung, Funktionstrennung und durchgängig nachvollziehbare Systemprotokollierung?
Ressourcen Level: werden die Zuweisungen der finanziellen, personellen und technischen Ressourcen gemäß den Zielen und Prioritäten strukturiert durchgeführt? Werden Skills und Auslastung von Mitarbeiter*innen beobachtet? Werden die Ressourcenzuweisungen hinsichtlich ihrer Effizienz und Effektivität überwacht und laufend optimiert?

Third Party Service Providers

Für den Fall, dass Unternehmensfunktionen an Dritte ausgelagert wurden, gelten spezielle Implikationen für Information Security. Für unterschiedliche Organisationsformen und Sourcing-Modelle müssen unterschiedliche Sicherheitsaspekte berücksichtigt werden. Durch einen offensichtlichen Bruch entlang der Unternehmensgrenzen bei gleichzeitiger Aufrechterhaltung von Prozessinteraktionen liegt es auf der Hand, dass die Verantwortung – auch und gerade für Informationssicherheit – klar definiert werden muss und formale Abläufe auch unbedingt eingehalten werden müssen. 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 und tunlichst auch vertraglich festzuschreiben und regelmäßig zu auditieren sind [CIS10, S167f].

Management Support

Nicht angemessene Managementunterstützung ist vor allem in kleineren Unternehmen, aber auch in nicht übermäßig technologiegetriebenen Organisationen ein sehr verbreiteter Stolperstein. Sie haben keinen offensichtlichen Leidensdruck und auch Möglichkeiten, sich mit Information Security intensiv auseinanderzusetzen. Oft geht in solchen Unternehmen aber das Unverständnis über die eigentliche Abhängigkeit von Informationstechnologie sowie der Bedrohungs- und Risikoumgebung und möglichen Auswirkungen von singulären Ereignissen einher [CIS10, S210].

Logistik

Logistische Aspekte haben auch Auswirkung auf die Informationssicherheit. Hat ein Unternehmen viele Standorte oder Außenstellen, ist der Bedarf an Kommunikation und Interaktion besonders hoch. Dies betrifft strategische Planung und Umsetzung, Projektmanagement, Besprechungsinfrastruktur, Zeitplanung, Aktivitäten- und Arbeitsplanung und allgemeinen Informationsaustausch. Mobile Technologien helfen hierbei, diese physischen Grenzen zu überwinden und die Information Security zu verbessern [CIS10, S219].

People

Natürlich steht Information Security – wie im vorigen Abschnitt dargelegt – in der Verantwortung jeder Mitarbeiterin bzw. jedes Mitarbeiters. Nichtsdestotrotz gibt es bestimmte Schlüsselrollen und spezielle Verantwortungen für Information Security, die nun in diesem Kapitel näher diskutiert werden.

Rollen und Verantwortlichkeiten

Die Rollen, die im Rahmen von Sicherheitsthemen in einem Unternehmen definiert werden, hängen von verschiedenen Kriterien ab, wie z.B. Größe des Unternehmens, Gefahrenpotenzial, Branche, Schutzwürdigkeit von Daten etc.

Gründe für die Nominierung eines dezidierten Security Management Teams (SMT) sind u.a. das Bewahren eines Wettbewerbsvorteils, indem die Geheimnisse und Prozesse, die für den Wettbewerbsvorteil sorgen, geschützt werden. Durch eine ausreichende Sicherheit wird auch der Ruf des Unternehmens geschützt. Beispiele, wo Daten durch Attacken an die Öffentlichkeit gelangten oder Software über Stunden oder Tage nicht zugänglich waren, gelangen unverzüglich an die Öffentlichkeit. Das Vertrauen der Kund*innen kann innerhalb kürzester Zeit ruiniert sein. Und nicht zuletzt kann das Team in Zusammenarbeit mit dem Compliance Officer, der Internen Revision und der Rechtsabteilung dafür sorgen, dass diesbezügliche Gesetze und Regelungen eingehalten werden. Erfolgsfaktor für die Arbeit ist die uneingeschränkte Unterstützung der Geschäftsführung oder des Vorstandes. [ISM03,S263].

Organisatorisch kann das Team zentral oder dezentral angesiedelt sein. Diese Entscheidung wird zumeist aufgrund des eingeschätzten Risikos getroffen, ist jedoch schlussendlich eine individuelle Entscheidung des Unternehmens.

Zentrales Security Management Team:

Das zentrale SMT ist alleinig verantwortlich für das Security Management Program und berichtet direkt an die/den Information Security Manager*in. Die Aufgaben umfassen auch die Kommunikation und Bewerbung von Sicherheitsthemen im Unternehmen, Implementieren von Sicherheitsinitiativen und Durchführung von täglichen Sicherheitsadministrationsaufgaben (wie z.B. Zugangskontrollen).

Dezentrales Security Management Team:

Die Personen sind für Sicherheitsthemen zusätzlich zu ihren täglichen Aufgaben der eigenen disziplinarischen Abteilung (z.B. IT, Finanzen, HR oder Produktion) nominiert.

Hybridlösungen:

In manchen Fällen werden Kombinationen von einer zentralen Organisationseinheit mit dezentralen Sicherheitsverantwortlichen umgesetzt. Dies hat den Vorteil, dass das zentrale Team den Überblick bewahrt und unternehmensweite Sicherheitsinitiativen umsetzen kann. Die dezentralen Sicherheitsverantwortlichen kümmern sich um die administrativen und abteilungsbezogenen Aufgaben.

Zu berücksichtigen bei der Umsetzung ist die Einbindung in die Reportingstruktur des Unternehmens und die Ansiedelung am Ort der maximalen Entscheidungsbefugnis und Commitment. Die oberste Führungsebene muss das Security Program maximal unterstützen. Doch auch auf den unteren Führungsebenen bis zu den Endanwender*innen muss eine Durchgängigkeit der Maßnahmen gewährleistet werden. Folgende acht Rollen zusätzlich zum Informationssicherheitsmanagement sind in einer Organisation in die Informationssicherheit eingebunden [ISM03, S266f]:

Geschäftsführung, Vorstand (Executive Management) sind für den Erfolg der Informationssicherheitsaktivitäten verantwortlich und daher verantwortlich für die Ausstattung von ausreichenden Ressourcen und Unterstützung.
Informationssicherheitsexpert*innen (Information Security Professionals) sind Expert*innen, die für das Design, Implementierung, Management und Review von Sicherheitsrichtlinien, -standards, -maßnahmen, -methoden und -prozessen zuständig sind.
Dateneigner (Data Owner) klassifizieren die verantworteten Daten in Schutzwürdigkeit und sorgen für die Datenintegrität und Datenqualität.
Datenverwalter (Custodians) sind Mitarbeiter*innen der Dateneigner, die sich um die Datensicherung und Wiederherstellung kümmern. Sie betreiben das betreffende System und sorgen für die Einhaltung von definierten Sicherheitsmaßnahmen und Richtlinien.
Prozesseigner (Process Owner) sorgen für die Umsetzung von Sicherheitsrichtlinien in ihrem verantworteten Prozess und dabei beteiligten IT-Systemen.
Technologieexpert*innen (Technology Providers) sind Expert*innen für Sicherheitstechnologien.
Nutzer*innen (Users) sind die Anwender*innen der zur Verfügung gestellten Systeme und Infrastruktur im Unternehmen. Sie müssen die Sicherheitsrichtlinien kennen und sich danach richten.
Informationssicherheits-Auditor*innen (Information Security Auditors) überprüfen die Zweckmäßigkeit und die Umsetzung von Sicherheitsmaßnahmen zur Erreichung der Sicherheitsziele des Unternehmens (siehe auch Kapitel IT Audits).

Die folgende Beschreibung bezieht sich sowohl auf spezielle Rollen, als auch auf die Verantwortung für bestimmte Unternehmensbereiche.

Information Security Risk Management

Information Security Risk Management ist ein integraler Bestandteil von Informationssicherheitsmanagement. Dementsprechend muss die Verantwortung für Risikomanagement in der Hierarchie hoch angesiedelt werden, um einen nachhaltigen kontinuierlichen Verbesserungsprozess sicherzustellen. Iterative Überprüfung, Berichtsstrukturen oder explizite Zuweisung von Verantwortlichkeiten sind ganz wesentliche Instrumente dafür.

Unternehmensaufsicht

Die Unternehmensaufsicht muss als letztverantwortliche Instanz die Rahmenbedingungen sicherstellen und sich regelmäßig den Status im Information Security Risk Management berichten lassen.

Unternehmensführung

Das ausführende Management hat die erforderlichen Ressourcen zur Verfügung zu stellen und die Risikomanagementaktivitäten bestmöglich zu unterstützen. Es fordert regelmäßige und ereignisorientierte Risikoevaluierungsberichte an, autorisiert akzeptierbare Risikolevels genauso wie Risikomanagement-Ziele. Zudem evaluiert es die Ergebnisse des Risk Assessments und trifft Entscheidungen.

Security Steering Committee

Die hauptsächlichen Stakeholder definieren die Prioritäten und Ziele im Risikomanagement. Diese sollen die Geschäftsstrategie unterstützen. Diese Runde entwickelt akzeptierbare Risikolevels für die verschiedenen Geschäftsprozesse und bestimmt Strategien für den Umgang mit Risiko. Es versichert sich des Management Supports, dem Schlüsselelement für effektives Risikomanagement.

Chief Information Security Officer (CISO)

Die/der Chief Information Security Officer (CISO) ist für das Information Security Program zuständig, das auf Information Security Risk Management basiert. Sie/er bekleidet also eine wichtige Rolle für die angewandte Methodik für die Identifikation, die Evaluierung und die Minimierung von Risiken. Die/der CISO agiert als Hauptansprechpartner*in für das Management hinsichtlich der Information Security Risk Management Aktivitäten.

System- und Informationsverantwortliche

Die System- und Informationsverantwortlichen stellen sicher, dass adäquate Steuerungsaktivitäten die Vertraulichkeit, die Integrität und die Verfügbarkeit der IT-Systeme und der Daten, die diese verwalten, gewährleisten. Sie sind verantwortlich für das Change Management ihrer Systeme, prüfen und autorisieren Änderungsanträge.

Business Manager*in und Führungskräfte

Die Kerngeschäftsverantwortlichen und leitenden Mitarbeiter*innen sind für die operative Geschäftstätigkeit verantwortlich und müssen daher auch eine aktive Rolle im Risikomanagementprozess übernehmen. Sie treffen täglich Entscheidungen über das korrekte Vorgehen bei Einzelfällen und können sehr viel beitragen, wie bestehende Prozesse und Systeme mit minimalem Aufwand und Ressourceneinsatz mit möglichst geringem Risiko durchgeführt oder verwendet werden.

Sicherheitsfachleute

Techniker*innen, Berater*innen und Praktiker*innen stellen die operative Umsetzung in ihren IT Systemen sicher. Sie setzen Änderungen in den Systemen um und können umgekehrt wertvolles Feedback für neue oder sich ändernde potentielle Risiken oder neue Steuerungsaktivitäten geben.

Security Awareness Trainer*in

Im Zuge einer ständigen Risikominimierung müssen sämtliche Mitarbeiter*innen mit dem Thema Security und Risikomanagement konfrontiert werden. Durch Trainings, Schulungen, Verlautbarungen und Aktionen muss das Thema präsent gehalten werden. Sie müssen den Risikomanagementprozess verstehen, aktuelles Schulungsmaterial erstellen, weiterentwickeln und die Regelungen in den Policies, Standards, Abläufen, Guidelines und Verhaltensregeln bewerben und schulen [CIS10, S93f].

Information Security Management

Unternehmensaufsicht (Board of Directors)

Die strategische Ausrichtung von Information Security Governance wird vom Aufsichtsorgan ^[3] des Unternehmens vorgegeben. Es erfordert den Auftrag für die Bereitstellung von Ressourcen und finanziellen Mitteln und die Definition von Verantwortlichkeiten einerseits, andererseits auch die Mittel für eine Überprüfung, ob die Vorgaben inhaltlich umgesetzt wurden. Der Unternehmensaufsicht als höchstes Organ im Unternehmen kommt dabei vor allem eine symbolisch-repräsentative Bedeutung zu und hat eine Trägerfunktion für das Thema inne. Im Englischen gibt es hierfür den Begriff „Tone at the Top“, also etwa die Stimmigkeit oder Konsistenz der Maßnahmen von den oberen zu den unteren Hierarchieebenen. Den Mitgliedern des Aufsichtsorgans sollen dabei die Bedeutung der Unternehmenswerte (Assets) und insbesondere deren Kritikalität im Rahmen des täglichen Geschäftsablaufes bewusst sein, was sich auch in Priorisierungen für einzelne Assets und Vorgaben für deren Schutz widerspiegeln muss. Hier geht es also vornehmlich um High-Level-Aktivitäten, reichend von Autorisierung von Policies, Einfordern von Geschäftsauswirkungsanalysen (Business-Impact-Analysen), Reports, Risikoanalysen. Naturgemäß müssen Verfehlungen auch entsprechend mit Konsequenzen oder Disziplinierungsmaßnahmen geahndet werden. Diese symbolisch-repräsentative Funktion in einem Unternehmen darf nicht unterschätzt werden. Jede Aktivität, jedes Meeting, jede Aussage hat unmittelbar Auswirkung auf die unteren Hierarchieebenen, da diese eine Wichtigkeit und Bedeutung für das Unternehmen symbolisieren. Wird auf gewisse Information-Security-Aspekte oder –Regelungen auf der Aufsichtsebene nicht wertgelegt, werden die operativen Einheiten diesen Aspekten mit hoher Wahrscheinlichkeit ebenfalls keine hohe Bedeutung beimessen [vgl. CIS10, S35].

Im operativen Geschäft soll die Unternehmensaufsicht auch einen gewissen Einblick in die aktuellen Tätigkeiten erlangen. Schon allein die unternehmerische Haftung gegenüber Stakeholdern, Aktionären, der Öffentlichkeit legt eine entsprechende Involvierung nahe. Berichtswesen, Einforderung von MAPs, Initiierung von Reviews sind dafür gängige Instrumente. Ein plakatives Beispiel ist die im wahrsten Sinne des Wortes (im Gesetz) festgeschriebene Aufgabe des Managements, sich von der Effektivität des formalen Internen Kontrollsystems (IKS) im Zuge von SOX404 zu vergewissern [CIS10, S202].

Unternehmensführung (Executive Management)

Das der Unternehmensaufsicht gegenüber gestellte Organ ist das ausführende Management, je nach Gesellschaftsform zumeist als Geschäftsführung (in Gesellschaft mit beschränkter Haftung) oder Vorstand (Aktiengesellschaft) ^[4] bezeichnet. Diese verantworten die Umsetzung der Vorgaben der Unternehmensaufsicht, sie setzen sie um. Die diese Rolle bekleidenden Personen übernehmen eine Art Thementreiberfunktion im Unternehmen, sie „führen“ es. Ihre Aufgabe ist es auch, die verschiedenen Ziele, Vorgaben unter den gegebenen Rahmenbedingungen konsistent in Aktivitäten umzusetzen. Beispielsweise müssen Information Security Aktivitäten im Einklang (Alignment) mit den Geschäftszielen (Business Objectives) stehen. Dies hat allerdings kosteneffizient zu erfolgen, wofür die Unternehmensführung der Unternehmensaufsicht Rechenschaft ablegen muss. Durch ihre Unterstützung (Management Support) und ihr Bewusstsein (Management Awareness) werden Themen, wie eben Information Security ständig im Bewusstsein der Mitarbeiter*innen gehalten. Auch hier wiederum ist deren Bedeutung für den Erfolg von Projekten, Initiativen, Maßnahmen – gerade dann, wenn viele Geschäftsbereiche oder Personen davon betroffen sind – nicht zu unterschätzen [vgl. CIS10, S35f].

Die Sollbruchstellen liegen allerdings zwischen Sicherheitsaktivitäten und dem operativen Tagesgeschäft, was eine ausgewogene Balance zwischen diesen beiden Bereichen erfordert. Die Prioritäten, die das Management dafür setzt, repräsentieren diese Balance [CIS10, S147].

Als eindeutige Statements zählen eine klare Verabschiedung einer formalen Information Security Strategie und Policies, regelmäßiges Überwachen und Messen der Umsetzung, Forcieren von Security Awareness und Schulungen für die Mitarbeiter*innen sowie auch eine entsprechende Gewichtung bei der Ressourcenverteilung [CIS10, S200, S202].

Information Security Steering Committee

Aufgrund der Tatsache, dass Information Security ein sehr weites Feld ist und viele Unternehmensbereiche betrifft, ist es ratsam, das Thema möglichst breit im Unternehmen zu etablieren. Durch ein regelmäßig zusammentretendes Steering Committee (Lenkungsausschuss), wo alle betroffenen Bereiche und Gruppen vertreten sein sollen, werden Information Security Aktivitäten abgestimmt, priorisiert, berichtet. Auch kann es als Kommunikationsmedium in den Unternehmensbereichen genutzt werden. Es beauftragt die/den Chief Information Security Officer (CISO) mit der Entwicklung einer Informationssicherheitsstrategie und anderen Sicherheitsaufgaben, entlastet sie/ihn nach Vorliegen und Review von Ergebnissen, trifft Entscheidungen für Maßnahmen. Die von der Unternehmensführung formulierten Aufgaben werden auf dieser Ebene weiter konkretisiert, priorisiert sowie deren Umsetzung beauftragt und abgenommen. Das Security Steering Committee muss Information Security als Aspekt den Business Owners nahebringen und danach trachten, dass Informationssicherheit in ihre Geschäftsprozesse möglichst als integraler Bestandteil verankert wird. Die Entscheidungen des Security Steering Committees haben Konsequenzen auf die Verhaltensweisen der einzelnen Mitarbeiter*innen und können stark auf das operative Arbeiten Einfluss nehmen [vgl. CIS10, S36f].

Auch im operativen Management des Information Security Programs ist das Information Security Steering Committee die wesentliche Infrastruktur- und Kommunikationseinrichtung, alle betroffenen Bereiche zu erreichen. Vor allem die Priorisierung der Sicherheitsinitiativen und das Behandeln von Problemfällen ist eine wesentliche Hauptaufgabe. Die/der Information Security Manager benötigt dieses Gremium als Abstimmungsinstrument, um sich der Mitarbeit und der Unterstützung der anderen Organisationseinheiten im Unternehmen zu versichern. Auch erhält sie/er laufend Informationen über Geschäftspraktiken, Abläufe, aufkommende Problemfälle aus den Kerngeschäftsprozessen heraus, die wiederum Auswirkung auf die Information Security haben. Es muss aber auch vor allem gemeinsam getragene Entscheidungen treffen. Einzelne Subarbeitsgruppen des Information Security Committees können dabei auch temporär einzelne komplexe Security Initiativen steuern [CIS10, S202f].

Chief Information Security Officer (CISO)

Eine zentrale Rolle für Informationssicherheitsmanagement kommt der/dem Chief Information Security Officer (CISO) zu. Die Rolle muss nicht immer so bezeichnet sein, mitunter gibt es Information Security Manager*in (ISM), (Chief) Security Manager*in (CSO), Security, Risk & Compliance Teams oder aber die Aufgabe wird von einer/m leitenden Manager*in – Chief Information Officer (CIO), Chief Financial Officer (CFO) oder überhaupt vom Chief Executive Officer (CEO) direkt wahrgenommen. Jedenfalls sollte diese Funktion möglichst Entscheidungsbefugnis und in der Geschäftsleitung („C-Level Manager“) Einfluss haben. Die Stellung und das Gewicht in der Hierarchie sind dabei ganz wesentlich, denn zu oft müssen für andere – auch leitende Manager*innen – durchaus unangenehme Dinge besprochen und entschieden werden, wobei hier natürlich eine Unabhängigkeit und eine Autorität in der Geschäftsleitung vonnöten ist. Anhand der Funktion kann man auch den Stellenwert von Information Security im Unternehmen ablesen – in vielen Fällen wird diese Aufgabe von einer anderen Rolle mitabgedeckt oder überhaupt unzulänglich abgedeckt. In anderen Fällen wurde diese Funktion zwar eingerichtet, allerdings berichtet sie an den CIO – also an jene Person, die eigentlich über die Funktion eines CISOs qualitätsgesichert werden soll, was funktional adäquat erscheint, aber dennoch strukturell aufgrund des inhärenten Interessenskonflikts des CIOs und des eigentlich erweiterten Aufgabenspektrums und stärkerer Business-Orientierung des CISOs natürlich suboptimal ist [vgl. CIS10, S36, S41]. In diesem Skriptum sprechen wir vom Chief Information Security Officer (CISO) und vom Information Security Manager (ISM). Im ersten Fall wird lediglich die Wichtigkeit der hierarchischen Stellung betont, inhaltlich sind die Begriffe synonym zu interpretieren.

Als wesentliche Aufgabe entwickelt die/der CISO die Informationssicherheitsstrategie, legt das Security Program fest, steuert, überwacht die Sicherheitsinitiativen und nimmt deren Ergebnisse ab. Des Weiteren ist sie/er in ständigem Kontakt mit den Business Owners im Hinblick auf die Sicherstellung von Alignment zwischen Informationssicherheit und Geschäftsprozess [vgl. CIS10, S37]. Somit stellt die/der CISO die operative Schlüsselfunktion für Information Security dar, sämtliche dafür relevanten Aktivitäten sollten durch sie/ihn koordiniert und überblickt werden. Diese Rolle ist definitiv keine technische Funktion, wiewohl die/der CISO die wichtigsten Sicherheitskonzepte und -technologien kennen und überblicksmäßig beurteilen können sollte. Vielmehr stellt sie/er die fehlende Verbindung zwischen Management und Sicherheit dar. Dies erfolgt nicht nur in den unteren Hierarchiestufen, sondern umgekehrt muss Information Security als Thema auch im Top Management verankert werden. Durch regelmäßige Berichte, Analysen und Eingaben muss die/der CISO den Management Support sowie die Awareness sicherstellen. Gerade ersteres ist immens wichtig. Diese Rolle ist explizit zu differenzieren von einer/m IT Security Manager*in, welche/r an sich ausschließlich Informationstechnologie im Fokus hat und auch operativ-technisch angesiedelt sein sollte. Vielmehr unterstützt die/der IT Security Manager*in die/den Information Security Manager*in bei dem so wichtigen Aspekt der technischen Maßnahmen für Informationssicherheit. IT ist hier als Tool, als Business Enabler selbst zu sehen. Es ist nicht das Business selbst [vgl. CIS10, S41].

Durch alle ihre/seine Aktivitäten hat sie/er den Gesamtüberblick über Information Security und setzt regelmäßig Schwerpunkte in den Überprüfungen, Nachfragen, Reviews und Audits. Sie/er ist ebenso lebende/r Botschafter*in für Security Awareness gegenüber allen Mitarbeiter*innen als auch Partner*in und muss im Rahmen ihrer/seiner Tätigkeit die/der symbolische/n Fahnenträger*in für Informationssicherheit sein [CIS10, S226ff].

Natürlich hat die/der CISO auch eine zentrale Rolle bei der Entwicklung des Information Security Programs, wobei es hier ganz besonders auf die Definition und die Formulierung von Sicherheitszielen ankommt. Dies sollte ein großes Ganzes ergeben und nicht in vielen kleinen lose verbundenen sicherheitsrelevanten Projekten aufgehen. Wie so oft muss es dafür Management Awareness und somit Rückendeckung für die/den CISO geben [CIS10, S57].

Organisationsübergreifende Verantwortungen

Durch die Vielzahl an beteiligten Personen an der Entwicklung eines Information Security Programs steigen natürlich die Gefahr von Unvereinbarkeiten, Doppelgleisigkeiten sowie der Aufwand an Koordination. Gerade Verantwortungen der Informationssicherheit sind über viele verschiedene Rollen verteilt und ergeben erst in Summe ein konsistentes Gesamtbild. Die/der Information Security Manager*in muss diese sich vielerorts überlappenden Verantwortungen identifizieren und über Mechanismen – wie etwa Funktionstrennung oder Vier-Augen-Prinzip – sicherstellen, dass diese sich nicht widersprechen. Beispielsweise sollen Entwickler*innen aufgrund der potentiellen Risiken nicht eigenständig Applikationen produktiv stellen. In jedem Falle müssen alle Rollen und Verantwortungen organisationsweit klar definiert und dokumentiert werden [CIS10, S149f].

Die Rolle der/des CISO umfasst – wenig überraschend – auch operative Koordinations- und Umsetzungsverantwortlichkeiten. Sie/er muss entsprechend den Rahmenbedingungen – insbesondere dem verfügbaren Budget – Information Security in Form des Information Security Programs gemäß den Vorgaben der Unternehmensaufsicht und -führung implementieren. Auch die zentrale Kommunikation zwischen allen mit Information Security Belangen betrauten Unternehmensinformationen obliegt der/dem Information Security Manager*in. Eine sehr breite Themenausrichtung erfordert auch eine gewisse Entscheidungskompetenz, gutes Kooperations- und Kommunikationsverhalten. Dadurch ist auch ein sehr strukturierter Ansatz von Vorteil. Die/der CISO sollte einen Überblick über gängige anwendbare Standards und Praktiken haben, einen risikoorientierten Ansatz verfolgen, die grundsätzlich einsetzbaren Technologien kennen, einschätzen und zueinander abwägen können sowie Management-Verantwortung in Form von Finanz-, Personal-, Projekt- und Performance Management übernehmen, aber auch Betriebs- und Entwicklungsmanagementfähigkeiten mitbringen. Auch fungiert die/der Information Security Manager*in als eine Art Competence Center für die ihr/ihm übergeordneten Hierarchie-Einheiten. Sie/er leitet die Unternehmensaufsicht und -führung im Zuge ihrer/seiner Tätigkeit an, sichert deren Beteiligung, fordert deren Unterstützung ein. Wohlgemerkt bedeutet das keinesfalls, dass diese Rolle einen ausgewiesenen technischen Fokus hat, vielmehr geht es um die grobe Bewertung, Einschätzung, sowie das Grundverständnis für technische Sicherheitsimplementierungen, wobei das auch auf die Organisationsstruktur, die technische und operative Ausrichtung des Unternehmens ankommt. Überschaubarere Technologieunternehmen werden wohl tiefergehende technische Anforderungen an eine/n Information Security Manager*in stellen als multinationale Konzerne, die etwa eine/n rein managementorientierten Group Security Officer stellt, die/der sich auf High-Level-Tätigkeiten beschränken muss [CIS10, S200f].

Interne Revision (internal audit)

Eine wesentliche Qualitätssicherungsfunktion kommt der Revision zu. Risiko-orientierte Audits – sowohl interne als auch externe – sollen immer als Qualitätsverbesserung angesehen werden. Jede objektivierbare Sicht auf die Abläufe, Messmetriken, Systeme, Applikationen, Datenbanken, Policies, Regelungen oder Zielerreichungen sollten regelmäßig auf Einhaltung, strukturelle Zusammensetzung, Effizienz, Effektivität, Sinn und Compliance überprüft werden. Diese Prüfungshandlungen können mit dem Information Security Management konzentriert werden und dieses unterstützen. Die Erkenntnisse der Reviews bieten Ansätze für Verbesserungsmaßnahmen, die wiederum von der Revision auch regelmäßig verfolgt werden. Dadurch wird ein kontinuierlicher Verbesserungsprozess in Gang gehalten und ein ständiges Streben nach Verbesserung im Unternehmen gewährleistet [vgl. CIS10, S37].

Informationstechnologie (information technology)

Die technischen Maßnahmen sind im operativen Management naturgemäß stark gefragt, da diese eine effektive Information Security Umsetzung fördern und in vielen Fällen sogar garantieren. Kontroll- und Steuerungsmechanismen in Netzwerk, Systemen, Applikationen, Webumgebungen sind dabei wesentliche Elemente. Auch die allgemeinen IT-Prozesse selbst können signifikante Auswirkungen auf die Informationssicherheit aufweisen, man denke hier nur an Change Management oder überhaupt die Transitionprozesse von der Entwicklung bis hin zur Produktivstellung. Nicht selten stehen die Anforderungen hinsichtlich Performance und Effizienz im Gegensatz zu Sicherheitsanforderungen, bei dem letztere nicht selten als geringer eingeschätzt werden. Neuere Organisationsansätze trennen die IT-Betriebs- von der Sicherheitsverantwortung, um diese Unvereinbarkeiten nicht virulent werden zu lassen [CIS10, S203].

Business Unit Manager*in

Schlussendlich ist immer die/der Kerngeschäftsverantwortliche dafür zuständig, die im Information Security Program definierten Maßnahmen unmittelbar anzuwenden. Das muss der/dem Business Unit Manager*in bewusst sein. Bei etwaigen Themenstellungen aus dem Kerngeschäft muss diese/r auch mit der/dem Information Security Manager*in oder dem Information Security Committee kommunizieren und gegebenenfalls eine gesamtheitliche Lösung zu erarbeiten. Ganz wesentlich ist die Einbeziehung der F&E-Organisationseinheiten, etwa Produktentwicklung oder Architekturdesign, um bereits frühzeitig im System Development Life Cycle (SDLC) Information Security Aspekte, insbesondere definierte Security Baselines, berücksichtigen zu können [CIS10, S203].

Personalabteilung (human resources)

Sämtliche Mitarbeiter*innen-Prozesse wie Recruiting, Administration, Verrechnung, Training und Schulung haben Auswirkung auf die Information Security, da diese von den Mitarbeiter*innen selbst getragen und verantwortet werden muss. Auch bei Sicherheitsvorfällen im Zusammenhang mit Angestellten soll die/der Information Security Manager*in hinzugezogen werden, um eine rechtlich haltbare und im Sinne der Unternehmensinteressen stehende Vorgehensweise sicherzustellen [CIS10, S203].

Recht (legal department)

Information Security Themen treten im Zusammenhang mit Compliance, Haftungsfragen, Unternehmensbewertungen (Due Diligence) auf, aber auch bei den zuvor genannten Personalthemen. Sie bedürfen im Einzelfall ebenfalls einer engen Abstimmung mit der/dem Information Security Manager*in [CIS10, S203].

Wiederholungsaufgaben

Nennen Sie die Bestandteile des Information Security Frameworks und geben Sie zu jeder Komponente mögliche Anwendungsbeispiele!
Stellen Sie die Rolle Information Security Manager*in jener der IT Security Manager*in bzw. des IT Security Managers gegenüber! Welche signifikanten Unterschiede bei den Aufgaben und Verantwortlichkeiten bestehen hierbei?
Nach welchen Dimensionen wird Information Security Governance beurteilt?
Erklären Sie den Begriff Countermeasures (Gegenmaßnahmen) als notwendige Ressource für die Entwicklung eines Information Security Programs!
Erklären Sie den Begriff der Security Baseline!
Was ist die Aufgabe der/des Information Security Manager*in im Rahmen des Managements des Information Security Programs?

Lösungen

Nennen Sie die Bestandteile des Information Security Frameworks und geben Sie zu jeder Komponente mögliche Anwendungsbeispiele!
- Technische Komponenten bilden die technische Sicherheitsarchitektur
  - natürliche Security-Technologien, z.B. Out-of-the-box-Sicherheitsfunktionen, etwa Authentifizierungsmechanismen, Zugriffsprotokollierung oder verschlüsselte SSL-Übertragung eines Webservers
  - zusätzliche Security-Technologien, z.B. Identity Management oder Zugriffsmanagement-Technologien
Zusätzliche Management-unterstützende Security-Technologien bereiten operative Daten auf und aggregieren diese zu Managementinformation, z.B. SIM-Lösungen, Log Analyzer, Compliance Monitoring Scanner.
- Operative Komponenten: regelmäßig durchzuführenden Management- und administrativen Tätigkeiten, Standardbetriebstätigkeiten, sicherheitsrelevante Geschäftsprozessaktivitäten oder Wartung und Administration der Sicherheitstechnologien, z.B. Zugriffsberechtigungen, Security Event Monitoring und Analyse, Patching, Konfigurationsmanagement, Change und Release Management, Security Metriken, Messung und Reporting, Incident Response und Resolution
- Management-relevante Komponenten: umfassen strategische Aktivitäten wie Policy-Reviews, Entwicklung und Anpassung von Standards, sowie Überblicks-Kontroll-Tätigkeiten, wie Projektreporting und Controlling.
- Administrative Komponenten: finanzielle Administrationstätigkeiten, Personalmanagement, Ressourcenmanagement, Schulung, Awareness und Training, Kommunizieren und Akzeptieren von Security Policies, Verhaltensrichtlinien, Verfahren zur sicheren Abarbeitung von Geschäftsfällen, Qualitätssicherungsaktivitäten.
Stellen Sie die Rolle Information Security Manager jener des IT Security Managers gegenüber! Welche signifikanten Unterschiede bei den Aufgaben und Verantwortlichkeiten bestehen hierbei?
Der CISO ist nicht auf IT beschränkt, sondern für den Umgang mit Information im Unternehmen in jeglicher Art und Weise zuständig. Er sollte ein C-Level-Manager und möglichst nicht dem CIO unterstellt sein. Der IT Security #:Manager ist operativer angesiedelt und technischer Experte. Der CISO bedient sich des IT Security Managers bei technischen Aufgabenstellungen in Bezug auf Information Security.
Nach welchen Dimensionen wird Information Security Governance beurteilt?
Strategische Ausrichtung (Strategic Alignment), Risikomanagement (Risk Management), Wertbeitrag (Value Delivery), Ressourcen-Management (Resource Management), Prozess-Sicherheit (Process Assurance).
Erklären Sie den Begriff Countermeasures (Gegenmaßnahmen) als notwendige Ressource für die Entwicklung eines Information Security Programs!
Gegenmaßnahmen (Countermeasures) sind Kontrollen, die als Reaktion auf bestimmte, bekannte Bedrohungen eingesetzt werden. Sie können präventiv, detektiv oder korrektiv (oder eine Kombination davon) sein. Eine Gegenmaßnahme kann beispielsweise sein, einen Spamfilter einzuführen, um Spam-Attacken zu verhindern. Gegenmaßnahmen müssen aber nicht nur technischer Natur sein, sondern können sich auch beispielsweise in Prozessen zeigen.
Erklären Sie den Begriff der Security Baseline!
Mit Security Baselines werden Mindestkriterien für die Information Security festgelegt. 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.
Was ist die Aufgabe des Information Security Manager im Rahmen des Managements des Information Security Programs?
Er ist der operative Koordinations- und Umsetzungsverantwortliche. Er implementiert das Information Security Program gemäß den Vorgaben der Unternehmensaufsicht- und -führung. Er übernimmt Management-Verantwortung in Form von Finanz-, Personal-, Projekt-, Performance Management für Information Security. Auch fungiert der Information Security Manager als eine Art Competence Center für die ihm übergeordneten Hierarchie-Einheiten. Er leitet die Unternehmensaufsicht und -führung im Zuge seiner Tätigkeit an, er sichert deren Beteiligung, fordert deren Unterstützung ein.

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 ^[5] , 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 ^[6] 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 ^[7] , 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] ^[8] :

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. ^[9]

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. ^[10]

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

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

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.
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
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.
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.
Nennen Sie mögliche Stolpersteine beim Information Security Program Management!
Fehlender Management-Support, unangemessene finanzielle Rahmenbedingungen, ineffizienter Personaleinsatz, politische Strömungen.
Welchen Problemen sehen Sie sich allgemein bei der Selbsteinschätzung einer Situation im Unternehmen gegenüber?
Siehe dazu Aufzählungsliste im Kapitel

Information Security Incident Management – Aufbau

Ziele der Lektion

Kennenlernen des Aufbaus der Prozesse Incident Management und Incident Response für das Management und die Abhandlung von sicherheitsrelevanten Incidents bis hin zu Notfallsituationen
Kennenlernen von Konzepten für die Wiederherstellung
Vorstellen der für die Prozesse benötigten Bausteine, Rollen und Verantwortlichkeiten

Incident Management & Incident Response

Incident Management ist nach ITIL v3 jener Prozess, der für die Verwaltung des Lebenszyklus aller Incidents verantwortlich ist. Wichtigstes Ziel des Incident Management ist eine schnellstmögliche Wiederherstellung des IT Services für die Anwender*innen. Im Rahmen des Incident Managements wird sichergestellt, dass Vorfällen, welche den laufenden Betrieb und damit Geschäftsprozesse beeinträchtigen können, auf effektive und effiziente Art und Weise begegnet wird. Dafür gewährleistet das Incident Management, dass solche Vorfälle erkannt, dokumentiert und derart behandelt werden, damit die Auswirkungen der Vorfälle und die damit verbunden Beeinträchtigungen minimiert werden.

Incident Response stellt einen strukturierten Ansatz dar, um auf einen sicherheitsrelevanten Vorfall „richtig“ zu reagieren und somit die Auswirkungen eines über einen „üblichen“ Vorfall hinausgehenden sicherheitsrelevanten zu bewältigen. Das Ziel ist es, die Situation derart zu behandeln, dass der hervorgerufene Schaden eines Incidents in Grenzen gehalten wird und die Wiederherstellungszeit und erforderlichen Kosten minimiert werden. Incident Response stellt damit den operativen Teil des Incident Management dar, in dem auf Vorfälle reagiert wird.

Die Ziele der Aktivitäten im Incident Management und Incident Response können zusammengefasst werden als:

Vorfälle / Incidents rasch erkennen
Incidents sorgfältig und präzise diagnostizieren
Incidents entsprechend handhaben und bewältigen
Schäden eindämmen und minimieren
Betroffene Services wiederherstellen
Ursachen der Vorfälle bestimmen
Verbesserungen implementieren, um ein Wiederauftreten zu verhindern

Vorfälle der Informationssicherheit nehmen in Unternehmen eine Sonderstellung ein, da sie den Fortbestand des Unternehmens gefährden können (z.B. Abhandenkommen von Unternehmenswissen, Vertrauensverlust durch Verlust von kundenrelevanten Daten etc.). Dabei muss auch die Möglichkeit von Incidents mit nicht technischem Hintergrund in Betracht gezogen werden. Vorgehen, um diesen Vorfällen effektiv und effizient begegnen zu können, müssen daher sorgfältig geplant werden. Um Incident Management und Incident Response in adäquater Weise implementieren und durchführen zu können, muss eine Reihe an Ressourcen, Betriebs- und Hilfsmitteln zur Verfügung gestellt werden.

Für das Information Security Incident Management ist die/der Information Security Manager*in gesamtverantwortlich.

Products

Konzepte

Um auf effektive Art und Weise mit Incidents umgehen zu können, ist für die/den Information Security Manager*in ein gutes konzeptuelles und praktisches Verständnis für die Behandlung von Vorfällen und Störungen unerlässlich. Zu den wichtigsten Konzepten zählen dabei, das Erkennen und Berichten von Vorfällen, das Beurteilen und Einteilen von Vorfällen (Kategorisieren, Priorisieren, zuweisen von Events und Incidents), die Analyse des Vorfalls, die Reaktion auf Vorfälle (Incident Response) und ein effektives Incident Management. Wesentlich in der Behandlung von Vorfällen ist für die/den Information Security Manger*in, dass auch die Möglichkeit von Incidents mit nicht technischem Hintergrund in Betracht gezogen werden muss [CIS10, S244f]. Dazu gehört beispielsweise Social Engineering. Social Engineering ist eine Methode, um unberechtigten Zugang zu Informationen oder IT-Systemen mittels Aushorchen zu erlangen. Dabei werden menschliche Eigenschaften wie z. B. Hilfsbereitschaft, Vertrauen, Angst oder Respekt vor Autorität ausgenutzt, um Mitarbeiter*innen so zu manipulieren, dass sie unzulässig handeln. Weiters müssen beispielsweise verlorene oder gestohlene Sicherungsbänder, entwendete Laptops oder der Diebstahl von sensiblen Materialien berücksichtigt werden [BSI11].

Benötigte Ressourcen

Um Incident Management und Incident Response in adäquater Weise implementieren und durchführen zu können, muss eine Reihe an Ressourcen, Betriebs- und Hilfsmitteln zur Verfügung gestellt werden.

Konzepte und Technologien

Im Incident Response Team (IRT) muss spezielles Wissen und Verständnis für einige Konzepte und Technologien vorhanden sein oder es müssen diese Kenntnisse aufgebaut werden.

Ein generelles Wissen über die Sicherheitsprinzipien

Confidentiality (Vertraulichkeit)
Availability (Verfügbarkeit)
Authentication (Authentifizierung)
Integrity (Vollständigkeit)
Access Control (Zugangskontrolle)
Privacy (Datenschutz)
Non-Repudiation (Nicht-Abstreitbarkeit, Nachweisbarkeit)

ist notwendig, um potentielle Probleme, die auftreten können wenn entsprechende Sicherheitsmaßnahmen nicht korrekt implementiert sind, und deren Auswirkungen auf IT-Systeme zu verstehen.

Wissen über Netzwerkprotokolle, wie beispielsweise Internet Protocol (IP), Transmission Control Protocol (TCP), User Datagram Protocol (UDP), Internet Control Message Protocol (ICMP), Address Resolution Protocol (ARP) und Netzwerkservices, wie z.B. Domain Name Service (DNS), Network File System (NFS) und Secure Shell (SSH), und wie diese eingesetzt und richtig (sicher) konfiguriert werden, sollte vorhanden sein. Ebenso sollten die Teammitglieder über bekannte Risiken oder Angriffe auf diese Protokolle sowie Strategien zur Vermeidung oder Abwehr von Angriffen Bescheid wissen. Die Teammitglieder sollten verstehen, wie bösartiger Code durch gängige Methoden (z.B. Email, Datenträger, Programme etc.) oder auf spezielle Weise, wie beispielsweise PostScript, Makros, Peer-to-peer Sharing etc., verbreitet wird. Kennnisse über verschiedene Betriebssysteme und Programmiersprachen sollten ebenso vorhanden sein, wie die Fähigkeit, verwundbare Stellen in Netzwerkkonfigurationen erkennen zu können [CIS10, S250f].

Incident Management Systeme

Das Incident Management und Incident Response besteht aus Prozessen, welche zum Teil manuell durchgeführt werden. Automatisierte Incident Management Systeme können viele dieser manuell durchgeführten Prozesse unterstützen oder sogar zu einem hohen Grad automatisieren. Eine wesentliche Eigenschaft eines Incident Management Systems ist die Überwachung der Incidents über ihren kompletten Lebenszyklus. Das verhindert einerseits, dass Incidents übersehen werden und gewährleistet andererseits, dass Incidents hinsichtlich ihrer Priorität entsprechend behandelt werden. Um eine bestmögliche Unterstützung bieten zu können, muss ein Incident Management System (IMS) eine Reihe an Anforderungen erfüllen, wie beispielsweise Inputs von unterschiedlichen Systemen konsolidieren und in Bezug setzen können, Incidents oder potentielle Incidents erkennen und identifizieren können, Incidents anhand der Auswirkung für das Gesamtunternehmen priorisieren können, Incidents über den gesamten Lebenszyklus hinweg überwachen, Information und Benachrichtigungen über den aktuellen Status des Incidents bieten, konform mit Good oder Best Practices sein etc.

Durch den Einsatz eines Incident Management Systems können mitunter auch Kosteneinsparungen erzielt werden. Einerseits können operative Kosten gesenkt werden, da ohne integrierte IMS unterschiedliche Sicherheitssysteme überwacht und Events miteinander in Verbindung gesetzt werden müssen. Diese Informationen müssen dann manuell verarbeitet werden. Neben einer wahrscheinlichen Häufigkeit von Fehlern fallen Kosten für Schulungen und Wartungen über einen längeren Zeitraum an. Andererseits können Wiederherstellungskosten reduziert werden. Ein richtig konfiguriertes, automatisiertes System erkennt und eskaliert Incidents im Vergleich zu einem manuellen Prozess erheblich schneller. Das führt zu einer Verminderung des Schadens und Vermeidung weiterer Schäden, was wiederum die Kosten für die Wiederherstellung nach einem Zwischenfall reduziert [CIS10, S245].

Richtlinien (Policies) und Standards

Richtlinien und Standards gewährleisten, dass die Aktivitäten des Incident Managements an der Mission des Managementteams (Incident Management Team) ausgerichtet sind. Es werden die richtigen Ziele und Erwartungen gesetzt und Richtlinien zur operativen Umsetzung (Incident Response Plan) zur Verfügung gestellt. In einem Incident Response Plan wird dabei einerseits definiert, was ein Security Incident ist und andererseits werden die Phasen für die Abhandlung von Incidents und dabei nötigen Verantwortlichkeiten beschrieben. Ein Incident Response Plan muss durch definierte, gut verständliche und dokumentierte Richtlinien und Arbeitsanweisungen für dessen Ausführung vervollständigt werden [CIS10, S250]. Auch die ISO 2700x Familie beinhaltet einen Standard für das Management von Incidents – ISO/IEC 27035 – Information technology – Security techniques – Information Security Incident Management. Die Norm enthält vier grundlegende Elemente: Entdeckung, Meldung und Bewertung von Informationssicherheits-Vorfällen (IS-Vorfällen), Behandlung und Management von IS-Vorfällen, Entdeckung, Bewertung und Management von IS-Schwachstellen und kontinuierliche Verbesserung des IS-Managements als Ergebnis des Managements von IS-Vorfällen und -Schwachstellen [ISM14, S1ff].

Um die Einhaltung von, für das Unternehmen festgelegten, Richtlinien (Policies), Standards und Abläufen zu überprüfen, werden (regelmäßig) Audits durchgeführt. Interne Audits werden von Expert*innenen innerhalb der Organisation durchgeführt und dienen im Allgemeinen dazu, Anforderungen an die Einhaltung und Übereinstimmung mit Richtlinien zu unterstützen oder bestimmte Situationen im Unternehmen zu verbessern. Externe Audits werden meist von Drittfirmen aufgrund von verpflichtenden Auflagen durchgeführt. Das wichtigste Ergebnis eines Audits ist der Audit-Bericht, der neben dem Umfang der Prüfung auch Beobachtungen und Feststellungen sowie begleitende Empfehlungen enthält.

Personal und Verantwortlichkeiten

Für das Management und die Abhandlung von sicherheitsrelevanten Vorfällen und zumeist schwerwiegenden Ereignisse werden eine Reihe an Rollen mit unterschiedlichen Verantwortlichkeiten vorgeschlagen.

Für die Planung und Steuerung (Management) der Behandlung von sicherheitsrelevanten Incidents ist die/der Information Security Manager*in gesamtverantwortlich. Das bedeutet, dass die/der Information Security Manager*in sicherstellen muss, dass Vorfälle, welche den laufenden Betrieb und damit Geschäftsprozesse beeinträchtigen können, auf effektive und effiziente Art und Weise behandelt werden und die Auswirkungen von solchen Vorfällen minimiert werden.

Fähigkeiten - Skills

Die technischen Skills umfassen technisches Grundwissen über jene, im Unternehmen eingesetzte Technologien, und Verständnis für Techniken, Entscheidungspunkte und Softwarewerkzeuge, welche die täglichen Aktivitäten einer/s Incident Bearbeiter*in unterstützen.

Awareness und Ausbildung

Wenn keine Expert*innen innerhalb des Unternehmens gefunden bzw. ausgebildet werden können, um das benötigte Spezialwissen zu nutzen, müssen evtl. Fachexpert*innen mit den nötigen Skills außerhalb des Unternehmens beauftragt werden. Wenn eine Situation eintritt, in der das innerbetriebliche Wissen nicht mehr ausreicht, kann auf diese Expert*innen zurückgegriffen werden, um die Lücke in der Fachkenntnis zu schließen.

Audits

Audits werden durchgeführt, um die Einhaltung von, für das Unternehmen festgelegten, Richtlinien (Policies), Standards und Abläufen zu überprüfen. Interne Audits werden von Expert*innen innerhalb der Organisation durchgeführt und dienen im Allgemeinen dazu, Anforderungen an die Einhaltung und die Übereinstimmung mit Richtlinien zu unterstützen oder bestimmte Situationen im Unternehmen zu verbessern. Externe Audits werden meist von Drittfirmen aufgrund von verpflichtenden Auflagen durchgeführt. Das wichtigste Ergebnis eines Audits ist der Audit-Bericht, der neben dem Umfang der Prüfung auch Beobachtungen und Feststellungen sowie begleitende Empfehlungen enthält.

People

Rollen und Verantwortlichkeiten

Für das Incident Management und Incident Response im Enterprise Security Bereich ist die Rolle der/des Information Security Manager*in (ISM) gesamtverantwortlich. Das bedeutet, dass die/der Information Security Manager*in sicherstellen muss, dass Vorfälle, welche den laufenden Betrieb und damit Geschäftsprozesse beeinträchtigen können, auf effektive und effiziente Art und Weise behandelt werden und die Auswirkungen von solchen Vorfällen minimiert werden.

Senior Management Commitment

Eine eindeutige Zustimmung des Senior Managements kann als kritischer Erfolgsfaktor für Incident Management und Response angesehen werden. Fehlt das Engagement und der Rückhalt, besteht die Gefahr, dass benötige Ressourcen nicht zur Verfügung gestellt werden und damit ein effizientes und effektives Incident Management im Unternehmen nicht etabliert werden kann.

Information Security Manager*in

Die/der Information Security Manager*in definiert, ab wann von einem sicherheitsrelevanten Incident (Security Incident) gesprochen wird, denn nicht alle Ereignisse stellen sicherheitsrelevante Vorfälle dar. Security Incidents umfassen im Allgemeinen

Attacken über bösartigen Code
Nicht autorisierter Zugriff auf IT- oder Informationsressourcen
Nicht autorisierte Nutzung von IT Services
Nicht autorisierte Änderungen an Systemen oder Informationen
Denial of Service
Missbräuchliche Verwendung
Spionage und Überwachung
Hoaxes und Social Engineering

Zu den Aufgaben der/des Information Security Manager*in zählt auch die Entwicklung der Incident Management und Response Pläne, sowie die Koordination und Abwicklung der Security-Incident-Response-Aktivitäten auf effiziente und effektive Weise. Sie/er validiert, überprüft und berichtet über technische und organisatorische Schutz- und Gegenmaßnahmen. Die/der ISM ist verantwortlich für die Planung, Budgetierung und Entwicklung des Programs aller Belange, die in Zusammenhang mit Information Security Management und Behandlung sicherheitsrelevanter Incidents stehen. Darüber hinaus muss die/der Information Security Manager*in das Engagement und den Rückhalt durch das Senior Management (Commitment) sicherstellen. Das erfordert einerseits das Aufbereiten eines Business Cases, um Kosten und Nutzen des Incident Managements und Response darzustellen. Andererseits ist ein regelmäßiges Reporting von MAPs als Basis, um die stetige Unterstützung (politisch und monetär) zu rechtfertigen, nötig.

Incident Response Team

Ein Incident Response Team (Team zur Abhandlung von Incidents) besteht im Allgemeinen aus permanent und vorübergehend zugehörigen Teammitgliedern und kann zentral oder dezentral organisiert sein.

Zu den permanent angehörigen, fixen Teammitgliedern zählen meist jene Personen, welche die Incidents untersuchen und behandeln. Es handelt sich in der Regel um IT-Expert*innen und Spezialist*innen für physische Sicherheit.

Die vorübergehenden Mitglieder des Incident Response Teams setzen sich im Allgemeinen aus Vertreter*innen der Fachbereiche oder des mittleren Management oder Mitarbeiter*innen aus Rechtsabteilungen und Public Relations zusammen. Sie bewerten z.B. (finanzielle) Auswirkungen von Vorfällen für das Gesamtunternehmen. Aber auch Personen aus dem Bereich Risk Management oder IT Spezialist*innenen werden vorübergehend, z.B. projektbezogen, in IRTs aufgenommen [CIS10, S251].

Ein zentrales IRT behandelt alle Incidents in der Regel für eine kleine Organisation oder ein zentral organisiertes Unternehmen.

In einem verteilten oder dezentral organisierten IRT ist jedes der einzelnen Teilteams für ein logisches oder physisches Segment der Infrastruktur verantwortlich. Ein verteiltes IRT wird gewöhnlich bei großen Unternehmen oder geographisch verteilten Organisationen angewendet. Dabei übernimmt dann ein weiteres, zentrales Team die Leitung der verteilten, dezentralen Teil-IRTs. Das zentrale Team entwickelt Richtlinien und Standards, bietet Trainings und Schulungen und koordiniert oder unterstützt die Behandlung von speziellen Incidents. Die verteilten Teams führen die Schritte zur Behandlung der Incidents aus [CIS10, S251].

Incident Management Team und Incident Response Team

Die nachfolgende Tabelle beschreibt typische Rollen und Verantwortlichkeiten von Mitgliedern des Incident Management Teams und Incident Response Teams [CIS10, S252].

Security Steering Group	Gruppe von Mitgliedern des Senior Managements	Ist für die Genehmigung der strategischen Ausrichtung des Incident Management verantwortlich Dient als Eskalationsstelle für das Incident Management Team Genehmigt Abweichungen und Ausnahmen zu den definierten, standardisierten Verfahren des Incident Management und Incident Response
Information Security Manager*in	Leiter*in des Incident Management Teams IMT	Ist für die Entwicklung und Aufrechterhaltung der Incident Management und Response Fähigkeiten verantwortlich Verwaltet effizient Risiken und Incidents Führt proaktive und reaktive Maßnahmen zur Steuerung der Höhe des Informationsrisikos durch
Incident Response Manager*in	Leiter*in des Incident Response Teams IRT	Überwacht und betreut die Incident Response Aufgaben Koordiniert Ressourcen für eine effektive Bearbeitung der Incident Response Aufgaben Übernimmt die Verantwortung für die erfolgreiche Ausführung des Incident Response Plans Präsentiert Incident Response Berichte und Berichte über Erfahrungen (Lessons Learned) an die Mitglieder der SSG
Incident Handler (Incident Bearbeiter*in)	Mitglied des IMT/IRT	Führt Aufgaben des Incident Response aus, um die Auswirkungen eines Incidents einzudämmen Dokumentiert die Schritte, die bei der Ausführung des Incident Response Plans durchgeführt werden Hält die Kontrollkette aufrecht (Beweissicherung) und überwacht die Abläufe bei der Incident Behandlung für den Fall einer gerichtlichen Anwendung Erstellt Incident Response Berichte und dokumentiert gemachte Erfahrungen (Lessons Learned)
Investigator (Ermittlerin, Untersuchender)	Mitglied des IMT/IRT	Untersucht spezielle Incidents Findet die Ursachen eines Incidents Erstellt Untersuchungsberichte
IT Security Spezialist*in	Mitglied des IMT/IRT Spezialist für bestimmte Bereiche der IT Security	Führt komplexe und spezielle sicherheitsrelevante Aufgaben als Teil des Incident Response Plans aus Führt Beurteilungen und Prüfungen der IT Security als proaktive Maßnahmen durch

Tabelle 1: Typische Rollen und Verantwortlichkeiten von Mitgliedern des Incident Management Teams und Incident Response Teams (Teil 1)

[CIS10, S252]

Business Manager*innen (Mitglieder der Fachbereiche)	Verantwortliche für Fachbereiche Prozess- oder Systemver-antwortliche	Trifft im Falle eines Incidents Entscheidungen, die den Prozess oder System betreffen, auf Basis der Empfehlungen des IMT/IRT Unterstützt mit Wissen über die Auswirkungen eines Incidents auf das Business im Prozess der BIA oder im Incident Response Plan
IT Spezialist*in	Spezialist*innen für bestimmte IT Services	Unterstützt das IMT/IRT bei der Lösung von Incidents Wartet IT Systeme anhand von Richtlinien oder Best Practice Empfehlungen
Rechtsvertreter*innen	Spezialist*innen für rechtliche Angelegenheiten	Bietet rechtliche Unterstützung für das Incident Management und Incident Response, z.B. im Falle von Klagen
Human Resources	Spezialist*innen für personelle Angelegenheiten	Unterstützt im Incident Management und Response, wenn die Untersuchung von verdächtigen Mitarbeiter*innen erfolgen muss Passt die HR-Richtlinien an, um Sanktionen des Incident Managements im Falle personeller Konsequenzen zu unterstützen
Vertreter*innen aus Public Relations	Vertreter*innen der Presseabteilung	Unterstützt mit einer kontrollierten Kommunikation (intern und extern), um Beeinträchtigungen der laufenden Incident Response Aktivitäten zu minimieren und das Images das Unternehmens zu schützen Unterstützt das IMT/IRT in kommunikationsrelevanten Belangen, um dem Team den Umgang mit kritischen Themen bei der Lösung von Incidents zu erleichtern
Spezialist*innen für Risk Management	Spezialist*innen für Risiko-management	Arbeitet eng mit Business Manager*innen und dem Senior Management zusammen, um Risiken zu bestimmen und zu behandeln Liefert wichtigen Input, z.B. BIA, Strategie des Risk Managements etc. für das Incident Management

Tabelle 2: Typische Rollen und Verantwortlichkeiten von Mitgliedern des Incident Management Teams und Incident Response Teams (Teil 2)

[CIS10, S252]

Kenntnisse und Training

Im Incident Response Team (IRT) muss ein generelles Wissen über Sicherheitsprinzipien vorhanden sein, um potentielle Probleme und Auswirkungen nicht korrekt implementierter Sicherheitsmaßnahmen verstehen zu können. Die Teammitglieder sollten Kenntnisse über Verwundbarkeiten und Schwächen in der Sicherheit und wie sich ein Angriff bei einer bestimmten Software oder Hardwaretechnologie zeigt, haben. Zu den bekanntesten Schwachstellen mit entsprechenden Angriffen zählen:

Physische Sicherheitsaspekte
Fehler im Protokolldesign (z.B. Man-in-the-middle-Attacken, Spoofing etc.)
Bösartiger Code (Viren, Würmer, Trojaner etc.)
Fehler in der Implementierung (Buffer Overflow, Race Condition etc.)
Schwachstellen bei Konfigurationen
Anwender*innenfehler oder mangelndes Sicherheitsbewusstsein (Awareness)

Wissen über Netzwerkprotokolle (z.B. TCP/IP, UDP, ICMP, ARP etc.) und Netzwerkservices (z.B. DNS, NFS, SSH etc.), und wie diese eingesetzt und richtig (sicher) konfiguriert werden, sollte vorhanden sein. Ebenso sollten die Teammitglieder über bekannte Risiken oder Angriffe auf diese Protokolle, sowie Strategien zur Vermeidung oder Abwehr von Angriffen Bescheid wissen. Die Teammitglieder sollten verstehen, wie bösartiger Code durch gängige Methoden (z.B. Email, Datenträger, Programme etc.) oder auf spezielle Weise, wie beispielsweise PostScript, Makros, Peer-to-peer Sharing etc., verbreitet wird. Kennnisse über verschiedene Betriebssysteme und Programmiersprachen sollten ebenso vorhanden sein, wie die Fähigkeit, verwundbare Stellen in Netzwerkkonfigurationen erkennen zu können [CIS10, S250f].

Die Mitglieder eines Incident-Response-Teams müssen allerdings neben technischen Fähigkeiten zur Behandlung von Incidents und für Analysetätigkeiten, auch über andere persönliche Eigenschaften (Soft Skills) verfügen. Soft Skills müssen besonders berücksichtigt werden, da sie für einen Großteil der täglichen Aktivitäten einer/s Bearbeiterin von Incidents benötigt werden. Dazu zählen:

Kommunikationsfähigkeit, um die richtigen und benötigten Informationen bekommen und weitergeben zu können
Fähigkeit, Richtlinien und Arbeitsanweisungen zu befolgen, um einen effizienten Ablauf in der Incident Behandlung zu gewährleisten
Teamfähigkeit
Stressresistenz
Vertraulichkeit, da die Teammitglieder oft mit sensiblen und vertraulichen Daten in Berührung kommen oder Zugriff darauf haben
Problemlösungskompetenz, wie beispielsweise „über den Tellerrand blicken können“, um Probleme aus mehreren Perspektiven betrachten zu können
Präsentationsfähigkeiten, um dem Management Bericht darstellen zu können

Wiederholungsaufgaben

Beschreiben Sie kurz was ein IMS ist, wie ein IMS im Incident Management und Incident Response unterstützen kann und welche Anforderungen an ein IMS gestellt werden!
Nennen Sie vier Bespiele für Recovery Sites und beschreiben Sie diese kurz!
Was bedeutet RACI?

Beschreiben Sie kurz was ein IMS ist, wie ein IMS im Incident Management und Incident Response unterstützen kann und welche Anforderungen an ein IMS gestellt werden!
Incident Management Systeme können viele von manuell durchgeführten Prozessen unterstützen oder sogar automatisieren, indem Incidents über deren kompletten Lebenszyklus überwacht werden. Das verhindert einerseits, dass Incidents übersehen werden und gewährleistet andererseits, dass Incidents hinsichtlich ihrer Priorität entsprechend behandelt werden. Durch den Einsatz eines Incident Management Systems können auch Einsparungen im operativen Bereich und bei den Wiederherstellungskosten erzielt werden. Ein Incident Management System sollte Inputs von unterschiedlichen Systemen konsolidieren und in Bezug setzen können, potentielle Incidents erkennen und identifizieren können, Incidents anhand der Auswirkung auf das Business priorisieren können, Incidents über den Lebenszyklus hinweg überwachen, bis sie geschlossen werden, Information und Benachrichtigungen über den aktuellen Status des Incidents bieten, mit den wichtigsten IT Management Systemen integriert werden können, konform mit Good oder Best Practices sein.
Nennen Sie vier Bespiele für Recovery Sites und beschreiben Sie diese kurz!
Hot sites: sind komplett konfiguriert und innerhalb weniger Stunden betriebsbereit. Ausstattung, Netzwerk, Systemsoftware müssen mit der primären Installation, welche gesichert wird, kompatibel sein. Zum Einsatz der Hot site werden zusätzlich nur Personal, Programme, Daten und Dokumentationen benötigt.

Warm sites: bestehen aus einer kompletten Infrastruktur, welche jedoch nur teilweise konfiguriert ist, im Allgemeinen mit Netzwerkverbindungen und grundlegender Peripherie wie z.B. Disk Drives, Tape Drives oder Controllers. Manchmal sind Warm sites im Vergleich zur primären, produktiven Installation auch weniger leistungsfähig ausgestattet, z.B. CPU, Memory.

Cold sites: bestehen lediglich aus einer Basisausstattung, wie z.B. Klima, Verkabelung, doppelte Böden etc.), die zum Betrieb von IT-Anlagen benötigt werden. In der Cold site kann die benötigte IT-Ausstattung bei Bedarf installiert und konfiguriert werden, was durchaus einige Wochen in Anspruch nehmen kann.

Mirror sites: sind ident, oder sehr ähnlich, zum primären IT Standort und werden im Rahmen von Load Balancing oder Load Sharing im produktiven Betrieb eingesetzt. Typischer Weise wird die Last der Applikationen automatisch nach Kapazität und Verfügbarkeit auf die Standorte verteilt. Unter der Voraussetzung, dass ausreichend Kapazitäten zur Verfügung stehen (Capacity Management), kann der Ort der Ausführung der Applikationen nahtlos und unterbrechungsfrei zwischen den Standorten gewechselt werden. Bei Organisationen mit mehreren Niederlassungen und mehreren Rechenzentren, bietet sich die Variante des „Spiegelns“ zwischen den einzelnen Rechenzentren an.

Weitere siehe Aufzählungsliste im Kapitel Recovery Sites.
Was bedeutet RACI?
Das RACI-Modell wird zur Darstellung von Verantwortlichkeiten von Rollen für Prozessaktivitäten verwendet, wobei die Art der Verantwortlichkeit in vier Grundformen unterschieden werden kann:
- R – Responsible: durchführungsverantwortlich
- A – Accountable: ergebnisverantwortlich
- C – Consulted: beratend
- I – Informed: Informiert

Information Security Incident Management – Ablauf

Ziele der Lektion

Kennenlernen des Ablaufs der Prozesse Incident Management und Incident Response für das Management und die Abhandlung von sicherheitsrelevanten Incidents bis hin zu Notfallsituationen
Darstellung der Phasen eines Incident Response Plans
Diskussion von kritischen Erfolgsfaktoren

Process

Aktivitäten

Bestimmung der bestehenden Möglichkeiten, um auf Incidents zu reagieren

Die meisten Unternehmen haben bereits Methoden und Vorgehen etabliert, um entweder ad hoc oder formal auf Incidents zu reagieren. Die/der Information Security Manager*in muss zunächst diese Abläufe identifizieren, um so den Ist-Stand zu erheben. Dies kann durch unterschiedliche Methoden erfolgen.

Umfragen / Interviews von Senior Management, Business Manager*innen, IT bieten eine gute Möglichkeit, um herauszufinden, wie in der Vergangenheit auf Incidents reagiert wurde und wie die Einschätzung der Leistungsfähigkeit, auf Incidents zu reagieren, ist.

Ein Self-Assessment kann durch das Incident Management Team selbst gegen eine Reihe von Kriterien und Fragen durchgeführt werden, um eine Selbsteinschätzung der derzeitigen Leistungsfähigkeit zu bekommen. Das Self-Assessment kann relativ schnell und einfach, ohne die Beteiligung von anderen Interessensvertreter*innen berücksichtigen zu müssen, durchgeführt werden. Dem gegenüber steht aber der Nachteil, dass die eingeschränkte Selbstbewertung der derzeitigen Leistungsfähigkeit möglicherweise nicht mit der durch die Interessensvertreter*innen wahrgenommenen Leistung, übereinstimmt.

Ein externes Audit und die Beurteilung durch Dritte stellt die umfassendste Methode dar, da formalisierte Interviews, Umfragen, Simulationen und andere Beurteilungsmethoden für die Bewertung kombiniert werden. Diese Methode wird im Allgemeinen von Organisationen eingesetzt, die bereits ein adäquates Incident Management betreiben, dieses aber verbessern wollen oder die bereits etablierten Prozesse überarbeiten möchten.

Entwickeln eines Incident Response Plans

Der Incident Response Plan stellt die operative Komponente des Incident Managements dar. Der Plan beinhaltet einen detaillierten Aktionsplan, Personalbeschreibungen und Aktivitäten, die in Situationen zu tragen kommen, wenn durch einen sicherheitsrelevanten Incident IT Services beeinträchtigt sind oder der Verlust von Informationen eingetreten ist.

Entwickeln von Detailplänen für Recovery und Response

Bei der Entwicklung von Response und Recovery Plänen müssen einige Dinge in Betracht gezogen werden, wie beispielsweise verfügbare Ressourcen, erwartete Leistungen und Arten und Schweregrad von Bedrohungen, denen die Organisation gegenüber steht. Die derzeitigen Möglichkeiten zur Erkennung von Incidents und für Monitoring müssen bekannt sein und die Risikotoleranz, welche die Organisation bereit ist zu tragen, muss bestimmt werden. Ziel einer effektiven Strategie für Recovery Pläne ist es, ein kosteneffizientes Gleichgewicht zwischen den Bemühungen des Risk Managements, Incident Management and Response und des Business Continuity- und Disaster Recovery Plans zu schaffen.

Organisation, Training und Ausrüsten des Response Personals

Das Training des Response Teams ist unerlässlich. Die/der Information Security Manager*in sollte Szenarios von Vorfällen entwickeln und daraufhin die Response- und Recovery-Pläne testen, um sicherstellen zu können, dass die Teammitglieder mit deren Aufgaben und Verantwortlichkeiten vertraut sind. Durch diesen Prozess kann das Team auch jene Ressourcen identifizieren, die für die geeignete Basisausrüstung des Teams für Response und Recovery benötigt werden. Ein zusätzlicher Nutzen des Trainings ist, dass unklare Abläufe und unpassende sowie ineffiziente Recovery-Maßnahmen erkannt und verbessert werden können.

Die Mitglieder des IMT sollten ein Trainingsprogramm mit mehreren Phasen durchlaufen.

Einführung in das IMT: Während der Einführung werden die grundlegenden und wichtigsten Informationen für effektives IMT bereitgestellt.
Betreuen neuer Teammitglieder hinsichtlich Rollen, Verantwortlichkeiten und Abläufen (Mentoring): Erfahrene Teammitglieder können an neue Mitglieder wertvolles Wissen weitergeben, um diese nach der Einführungsphase zu unterstützen. Realisiert wird das im Allgemeinen im Rahmen einer Mentoring-Phase, in der ein erfahrenes Teammitglied (Mentor) einem neuen Mitglied über einige Zeit zur Seite steht.
Training-on-the-job: Dient dazu, um ein Verständnis für die Unternehmensrichtlinien, Standards, Abläufe, verfügbare Softwaretools und Applikationen, richtige Verhaltensregeln etc. zu schaffen.
Schulungen: Teammitglieder benötigen Schulungen, um geeignete Kompetenzen für umfassende Incident-Management-Fähigkeiten zu erreichen.

Wiederherstellungsstrategien

Es gibt viele Strategien für die Wiederherstellung kritischer Informationen, deren Entwicklung je nach Größe und Komplexität der Organisation entsprechend Zeit beansprucht und Kosten verursachen kann. Es sollte jene verfolgt werden, die wahrscheinliche Ereignisse innerhalb akzeptabler Wiederherstellungszeiten zu gerechtfertigten Kosten mit Sicherheit abdeckt. Die Gesamtkosten für Wiederherstellungsfähigkeiten setzt sich aus den Kosten für die Vorbereitung auf mögliche Unterbrechungen (z.B. Beschaffung, Wartung und Test von redundanten Rechnern, Wartung alternativer Netzwerkrouten, Schulungs- und Personalkosten etc.) und den Kosten des Einsatzes der vorbereiteten Maßnahmen bei Eintritt eines Ereignisses. Bei den Überlegungen möglicher Strategien sollen auch Versicherungen, welche verschiedene Formen von Beeinträchtigungen des Geschäftsbetriebs abdecken, berücksichtigt werden.

Planung der Wiederherstellung und Business Recovery Prozesse

Die/der Information Security Manager*in muss die nötigen grundlegenden Prozesse für die Wiederherstellung des Betriebs nach Incidents, wie z.B. DoS-Attacken, Naturereignisse und anderen potentiellen Unterbrechungen der Geschäftstätigkeiten, kennen. Unter Disaster Recovery (DR) versteht man die Wiederherstellung von IT-Systemen nach Zerstörungen durch Naturgewalten. Business Recovery (BR) bezeichnet die Wiederherstellung von kritischen Geschäftsprozessen um mit dem Geschäftsbetrieb fortfahren bzw. diesen wieder aufnehmen zu können. Business Recovery beinhaltet dabei neben dem Disaster Recovery alle anderen Aspekte des Geschäftsbetriebs.

Bei der Planung müssen die Kriterien für die Deklaration eines IT-Desasters festgelegt werden. Nicht alle Ereignisse, Incidents oder kritische Unterbrechungen müssen notwendigerweise als Security Incident klassifiziert werden. Zum Beispiel können Serviceunterbrechungen durch einen System- oder Applikationsfehler verursacht worden sein. Unabhängig von der Ursache der Unterbrechung des Geschäftsbetriebs müssen die Aktivitäten zum Erhalt oder Wiederherstellung des Geschäftsbetriebs rasch gesetzt werden, um den Erwartungen des Business nach einer zufriedenstellenden Lösung gerecht zu werden. Ein wesentlicher Prozess während der Planung, ist die Durchführung einer BIA, um die Kosten beim Ausfall von Systemen bestimmen zu können. Das bereitet die Basis für die Festlegung angemessener RTOs, was wiederum Einfluss auf die Örtlichkeit und Kosten von außerbetrieblichen Einrichtungen zur Wiederherstellung (z.B. Ausfallsrechenzentren) nimmt.

Recovery Sites

Die Auswahl der geeigneten Recovery Site hängt von der Wahrscheinlichkeit eintretender Ereignisse, Auswirkungen und Kosten bei Ausfall ab. Bei langen und kostenintensiven Ausfällen, welche die primären physischen Einrichtungen beeinträchtigen, bieten sich Backup Alternativen außerhalb der Organisation an. Als mögliche Alternativen können in Betracht gezogen werden:

Hot Sites sind komplett konfiguriert und innerhalb weniger Stunden betriebsbereit. Ausstattung, Netzwerk, Systemsoftware müssen mit der primären Installation, welche gesichert wird, kompatibel sein. Zum Einsatz der Hot Site werden zusätzlich nur Personal, Programme, Daten und Dokumentationen benötigt.

Warm Sites bestehen aus einer kompletten Infrastruktur, welche jedoch nur teilweise konfiguriert ist, im Allgemeinen mit Netzwerkverbindungen und grundlegender Peripherie wie z.B. Disk Drives, Tape Drives oder Controllers. Manchmal sind Warm Sites im Vergleich zur primären, produktiven Installation auch weniger leistungsfähig ausgestattet, z.B. CPU, Memory.

Cold Sites bestehen lediglich aus einer Basisausstattung, wie z.B. Klima, Verkabelung, doppelte Böden etc., die zum Betrieb von IT-Anlagen benötigt werden. In der Cold Site kann die benötigte IT-Ausstattung bei Bedarf installiert und konfiguriert werden, was durchaus einige Wochen in Anspruch nehmen kann.

Mobile Sites sind spezielle Fahrzeuge oder Anhänger, die rasch an einen Geschäftsstandort oder andere Standorte gebracht werden können. Diese sind meist mit vorkonfigurierten IT Komponenten wie Server, Desktops, Equipment für die Kommunikation etc. ausgestattet und bieten somit eine einsatzbereite Anlage und Ausstattung für die Informationsverarbeitung. Mobile Sites sind sehr nützlich, wenn es keine Möglichkeit für Einrichtungen zur Wiederherstellung in der gewünschten Umgebung gibt.

Mirror Sites sind die beste Alternative, wenn der IT Betrieb ununterbrochen verfügbar sein soll. Mirror Sites sind ident oder sehr ähnlich zum primären IT Standort und werden im Rahmen von Load Balancing oder Load Sharing im produktiven Betrieb eingesetzt. Typischerweise wird die Last der Applikationen automatisch nach Kapazität und Verfügbarkeit auf die Standorte verteilt. Unter der Voraussetzung, dass ausreichend Kapazitäten zur Verfügung stehen (Capacity Management), kann der Ort der Ausführung der Applikationen nahtlos und unterbrechungsfrei zwischen den Standorten gewechselt werden. Bei Organisationen mit mehreren Niederlassungen und mehreren Rechenzentren, bietet sich die Variante des „Spiegelns“ zwischen den einzelnen Rechenzentren an.

Die Auswahl der passenden Alternative für das Wiederherstellungsszenario hängt von den betrieblichen Anforderungen, welche durch eine BIA bestimmt werden, der Gegenüberstellung von Kosten und Nutzen und der Risikotoleranz des Unternehmens ab. Bei der Festlegung der Anforderungen kann sich auch herausstellen, dass einige kritische betrieblichen Aspekte mit Mirror Sites abgesichert werden müssen, um bestimmte Service Level Anforderungen erfüllen zu können, während andere Aspekte z.B. durch Hot, Warm oder Cold Sites abgedeckt sind.

Grundlagen für die Auswahl einer Recovery Site

Die Auswahl der geeigneten Site für die Response und Recovery Strategie sollte auf den Parametern: Interruption Window, RTO, RPO, SDO und MTO beruhen. Um eine passende Wiederherstellungsstrategie vorbereiten zu können, muss der Information Security Manger all diese Parameter mit den Möglichkeiten der verschiedenen Arten von Recovery Sites und deren Kosten vergleichen. Die Komplexität und Kosten der Response- und Recovery-Pläne, genauso wie die Arten und Kosten der Recovery Sites sind proportional zu diesen zeitlichen Zielen der Wiederherstellung. Ein Zeitfenster für eine Unterbrechung von zwei Stunden benötigt eine Hot-Site- oder Mirror-Site-Lösung, die meist recht teuer ist, der korrespondierende Wiederherstellungsplan dagegen ist recht simpel und daher günstig. Im Gegensatz dazu bedeutet ein Zeitfenster für eine Unterbrechung von einer Woche den Einsatz einer recht günstigen Cold Site, wobei der zugehörige Recovery Plan recht komplex und damit teuer sein wird.

Incident Management und Response Teams

Im Incident Response Plan müssen die Teams und deren Verantwortlichkeiten im Falle eines Incidents festgelegt und trainiert werden. Je nach Umfang des Geschäftsbetriebs können diese Teams auch aus Einzelpersonen bestehen. Der Einsatz der entsprechenden Teams ist abhängig von der Schwere der Unterbrechung und Art der betroffenen Systeme oder Informationen. Es sollte eine Matrix erstellt werden, in der die Beziehung zwischen den Funktionen und den verschiedenen Teams ersichtlich ist. Beispiele für Teamarten in einem Response Plan:

Team für Notfalleinsatz: Besteht z.B. aus Feuerwarten, deren Funktion die Behandlung von Ereignissen mit Feuer oder anderen Notfallszenarios ist.

Team für Schadensaufnahme: Qualifizierte Personen, deren Funktion die Feststellung des Ausmaßes des Schadens an physischen Einrichtungen oder Anlagen ist. Weiter wird durch dieses Team eine erste Einschätzung getroffen, was wiederhergestellt werden kann, was rettungswürdig ist oder ob es sich um einen totalen Verlust handelt.

Team für Notfall Management: Ist verantwortlich für die Koordination der Aktivitäten aller anderen Recovery Teams und trifft relevante Entscheidungen.

Team für Übersiedlung und Verschiebung von Standorten: Dieses Team ist verantwortlich für die Koordination des Prozesses für die Verschiebung einer Hot Site auf einen neuen Standort oder auf den wiederhergestellten Originalstandort.

Security-Team: Wird auch Security Incident Response Team genannt und ist verantwortlich für die Überwachung der Sicherheit von kritischen Systemen und Kommunikationsverbindungen, Lösen von Sicherheitsproblemen, welche die schnelle Wiederherstellung von Systemen behindern und die einwandfreie Installation und Funktionsweise jeder sicherheitsrelevanten Software.

Voraussetzungen für Benachrichtigungen

Der Plan muss die Voraussetzungen für die Benachrichtigung von Schlüsselpersonen und Entscheidungsträger*innen, Systemverantwortlichen und Endanwender*innen bilden, die für die Initiierung und Ausführung der Incident-Behandlung benötigt werden. Ein Verzeichnis von Telefonnummern von Personen, die im Falle eines Incidents benachrichtigt werden müssen, ist ein wesentlicher Bestandteil des Benachrichtigungsprozesses. Dieses Verzeichnis sollte Informationen, wie beispielsweise eine priorisierte Liste zu benachrichtigender Kontakte, Primär- und Notfalltelefonnummer und Adressen für jede Schlüsselperson, Kontaktdaten von Lieferanten und Herstellern relevanter Hard- und Software, Kontaktdaten von Mitarbeiter*innen des Betriebs, Telefonnummern von Behörden und Personen mit gesetzlichen Durchsetzungsrechten im Falle schwerwiegender Sicherheitszwischenfällen.

Betriebsmittel

Der Plan muss Regelungen für alle Betriebsmittel, die für die Aufrechterhaltung des Geschäftsbetriebs während der Wiederherstellungsaktivitäten nötig sind, enthalten. Das inkludiert auch detaillierte, aktuelle Ablaufbeschreibungen und Checklisten auf Papier, die auch leicht vom Personal befolgt werden können, die mit dem Wiederherstellungsablauf nicht vertraut sind. Dies dient dazu, die Ausführung des Planes zu gewährleisten, auch wenn Mitglieder des vorgesehenen Teams nicht verfügbar sind. Ebenso sollten benötigte spezielle Formulare und Checklisten, sowie Bestellformulare für kritische Hardwarekomponenten am Wiederherstellungsstandort verschlossen aufbewahrt werden. Wenn die Funktionsweise von Applikationen von bestimmten Hardwarekomponenten oder Betriebssystemen abhängig ist, müssen dieses Equipment oder Softwarekomponenten am Wiederherstellungsort verfügbar sein.

Versicherungen

Der Plan sollte auch wichtige Informationen hinsichtlich der Versicherungen der Organisation beinhalten. Eine Versicherung für informationsverarbeitende Systeme ist gewöhnlich eine Bündelpolice, die verschiedenste Arten und Typen von IT abdeckt. Sie sollte modular aufgebaut sein, sodass sie an das spezielle IT Equipment des Versicherungsnehmers angepasst werden kann. Die verschiedenen Arten der Abdeckungen durch Versicherungen umfassen beispielsweise das IT Equipment und IT-Einrichtungen, Unterbrechungen im Geschäftsbetrieb, den Wert von Unterlagen und Aufzeichnungen, Transport von Medien etc.

Regelmäßige Anpassung des Recovery Plans

Durch die Dynamik von Organisationen und stetigen Veränderungen müssen auch die Response und Recovery Pläne regelmäßig angepasst werden, um den aktuellen Zielen und Ansprüchen des Unternehmens zu entsprechen. Dabei ist es wichtig, die Zustimmung und Rückendeckung des Senior Managements für den Prozess der regelmäßigen Anpassung zu erhalten, da dieser fortlaufende Prozess Unternehmensressourcen beansprucht, um ein akzeptables Niveau der Wiederherstellungsfähigkeiten zu erreichen und zu erhalten.

Wiederherstellungspläne und Informationssicherheit

Es ist wichtig, dass die Informationsressourcen auch bei notfallbedingt chaotischen Verhältnissen geschützt bleiben. Die/der Information Security Manager*in muss sicherstellen, dass die Informationssicherheit bei allen Response und Recovery Plänen entsprechend berücksichtigt ist. Die/der Information Security Manager*in sollte die Pläne überprüfen um sicherzugehen, dass deren Ausführung keine Standards und Anforderungen der Informationssicherheit gefährdet. Es sollte auch eine Risikoanalyse durchgeführt werden, um das Management über mögliche Auswirkungen der Sicherheitsrisiken durch die Ausführung der Pläne zu informieren.

Umsetzung der Detailpläne für Response und Recovery

Um sicher zu gehen, dass die Response- und Recovery-Pläne nach den Bedürfnissen des Business ausgeführt werden, muss eine bestimmte Person, wie eine Art Regisseur*in, die Aufgaben innerhalb der Pläne koordinieren, ihre Ausführung überblicken und überwachen, mit dem Senior Management eng zusammenarbeiten und nötige Entscheidungen treffen. Die/der Information Security Manager*in kann, muss aber nicht, diese Rolle der/des Recovery-Plan-Koordinator*in übernehmen, muss aber zumindest sicherstellen, dass diese Rolle einer geeigneten Person zugeteilt wird.

Eskalationsprozess

Die/der Information Security Manager*in sollte einen Eskalationsprozess implementieren, um jene Ereignisse festzulegen, die durch das IRT gehandhabt werden müssen. Ereignisse, die zunächst als Routine erscheinen, können sicherheitsgefährdend sein und sich als Security-Incident herausstellen. Zum Beispiel kann eine Datenverfälschung nicht aufgrund eines Applikationsfehlers verursacht sein, sondern auf Grund eines Virus oder Wurms. Als Teil der Policies und Procedures des Notfall- und Incident Managements, sollte eine detaillierte Beschreibung des Eskalationsprozesses dokumentiert sein. Für jedes Ereignis sollte eine Liste von Aktionen und Aufgaben und die Reihenfolge deren Abarbeitung beschrieben sein (Aktionsplan). Für jede aufgelistete Aktion sollten die verantwortliche Person und eine geschätzte Ausführungszeit angegeben sein. Sollte irgendeine Aktion nicht ausgeführt werden können oder die geschätzte Ausführungszeit überschritten werden, so sollte im Prozess mit der nächsten Aktion fortgefahren werden, da jede gescheiterte Aktion wertvolle Zeit verschwendet. Wenn die Summe aller Ausführungszeiten ein vordefiniertes Limit erreicht, kann die Notfallsituation zu einer Alarmstufe (niedrig, mittel, hoch) hinaufgestuft werden. Die Situation einer Alarmstufe führt zu einer Benachrichtigung von hierarchisch übergeordneten Stellen, wie beispielsweise dem Senior Management (hierarchische Eskalation). Darüber hinaus könnten spezielle Recovery Teams, Versicherungen, Hersteller etc. benachrichtigt werden (fachliche Eskalation). Die/der Information Security Manager*in sollte einen Kommunikationsplan in Zusammenarbeit mit PR-Abteilung, Rechtsberatung und Senior Management entwickeln, um eine angemessene Informationsweitergabe zu gewährleisten.

Policies und Prozesse für Intrusion Detection (ID)

In Unternehmen werden oft Intrusion Detection Systems (IDS) eingesetzt, um Versuche in das Unternehmensnetz einzudringen und andere verdächtige Aktivitäten zu erkennen. Dabei sollten die Basissysteme des IDS fehlertolerant und gegen Angriffe abgesichert sein. Die IDS selbst sollten durchgehend verfügbar, leicht zu überwachen und rasch anpassbar sein, nicht übermäßig viel Netzwerk-Overhead verursachen und eine große Anzahl an Anomalien erkennen können. Das Personal, das für den Betrieb des IDS zuständig ist, muss dafür ausreichend geschult sein. Idealerweise sollten sowohl host- als auch netzwerkbasierte IDS eingesetzt werden, um eine möglichst große Abdeckung der Netzwerk-Topologien zu erreichen. Die meisten Systeme können so konfiguriert werden, dass im Falle verdächtiger Ereignisse das Personal automatisch benachrichtigt wird. Wenn eine verdächtige Aktivität identifiziert wurde, sollten definierte Prozeduren initiiert werden, um auf diesen Vorfall zu reagieren.

Service Desk Prozesse für die Identifizierung von Security Incidents

Die/der Information Security Manager*in sollte Prozesse für das Service Personal definieren, um diesen die Unterscheidung eines typischen Service Desk Requests von einem möglichen Security Incident zu ermöglichen. Der Service Desk ist meist die erste Anlaufstelle für Meldungen eines möglichen sicherheitsrelevanten Vorfalls. Das schnelle Erkennen von Security Incidents und rasche Setzen von Maßnahmen sind kritische Faktoren für die erfolgreiche Vermeidung oder Verminderung der Schäden durch so einen Vorfall. Dafür sind die Festlegung entsprechender Kriterien für die Kategorisierung von Incidents und eine große Sensibilität des Service Desk Personals für Sicherheitsthemen unerlässlich. Ausreichendes Training des Personals kann die Gefahr erfolgreich durchgeführter Angriffe mittels Social Engineering gegenüber Service Desk Agents verringern. Neben der Fähigkeit mögliche Security Incidents zu erkennen, muss das Service-Desk-Personal über entsprechende Arbeitsanweisungen für Informationsweitergabe (Benachrichtigungen) und Eskalation verfügen und diese befolgen.

Benachrichtigungsprozess

Die effektive und zeitnahe Benachrichtigung über das Auftreten eines Security Incidents stellt einen kritischen Faktor für jedes Security Program dar. Wenn alle relevanten Informationen zur richtigen Zeit verteilt werden, kann die Organisation rasch auf Incidents reagieren und so vor potentiellen Schäden der Incidents geschützt werden. Dabei können beispielsweise Automatismen in Monitoring Systemen unterstützen, indem automatisch Emails oder SMS abhängig vom eintretenen Ereignis an bestimmte Personengruppen verschickt werden. Unternehmensbereiche, die meist Informationen beim Auftreten von Incidents benötigen sind z.B. Risk Management (zur Beurteilung des möglichen Risikos für das Unternehmen), Human Resources (sobald ein Angriff von Mitarbeiter*innen des Unternehmens initiiert wurde), Rechtsabteilung (sobald Verletzungen von Gesetzen zu befürchten sind), Public Relations (wenn das Image des Unternehmens betroffen sein könnte) und Betrieb (damit erste Maßnahmen zur Eindämmung getroffen werden können).

Dokumentieren von Ereignissen

Wenn ein Incident eintritt, muss das Security Team über dokumentierte Verfahren (Handlungsanweisungen) verfügen, um sicherstellen zu können, dass die nötigen Informationen aufgezeichnet und die relevanten Daten sichergestellt werden. Durch die Sicherstellung von diesen Informationen können die Ereignisse untersucht und an Teams der Forensik oder gegebenenfalls an Behörden weitergegeben werden.

Festlegen der Verfahren und Handlungsanweisungen

Die/der Information Security Manager*in sollte gemeinsam mit Hilfe von Managementebenen, Rechtsberater*innen und Gesetzesbehörden die Verfahren für die Sicherstellung von Daten entwickeln. Durch Einbeziehung dieser speziellen Stakeholder können Verfahren entwickelt werden, mit denen sicherheitsrelevante Vorfälle so sorgfältig behandelt werden können, dass Beweise sichergestellt werden können, die rechtlich benötigte Kontrollkette eingehalten wird und die diesbezüglichen Unternehmensanforderungen angemessen erfüllt werden.

Es gibt einige grundlegende Aktivitäten, die Mitarbeiter*innen von Informationssystemen befolgen müssen. Dazu zählt, nichts zu unternehmen, was potentielle oder bestehende Belege und Beweise verändern, beeinträchtigen oder zerstören könnte. Geschultes Personal der Forensik kann attackierte oder infizierte IT-Systeme untersuchen, aber wenn Informationen auf diesen Systemen durch anderes Personal verändert wurden, können diese Daten möglicherweise vom Forensik-Team für die Untersuchung des Incidents nicht verwendet oder vom Gericht nicht anerkannt werden. Bei Security Incidents müssen die IT-Forensiker*innen die Informationen und physische Objekte auf systematische Art und Weise sammeln und behandeln, sodass diese vor Gericht als Beweise anerkannt werden. Daher sollte die IT-Forensik durch speziell geschultes Personal im Security Incident Response Team, Spezialist*innen von Drittfirmen oder Gesetzesbehörden durchgeführt werden. In der ersten Reaktion einer/s Systemadministrator*in sollte der Incident bestätigt, Umfang und Größe des betroffenen Umfelds identifiziert (z.B. Netzwerk, Systeme, Applikationen etc.), der Grad des Verlustes, Zerstörung oder Veränderung bestimmt und der mögliche Hergang und die eingesetzten Mittel bei der Attacke identifiziert werden.

Voraussetzungen für die Sicherung von Beweisen

Jede Veränderung von Beweismitteln eines Ein- oder Angriffs kann die Verfolgung der/des Täter*in verhindern oder zumindest die Möglichkeiten der Verfolgung einschränken. Weiters kann die Änderung von Daten die nötigen Aktivitäten der Computer-Forensik, um die/den Täter*in und alle verursachten Änderung ausfindig zu machen, behindern. Die Wahrscheinlichkeit, den Hergang der Attacke rekonstruieren zu können, sinkt. Damit kann das Security Program nicht entsprechend angepasst oder erweitert werden, um das Risiko ähnlicher Attacken für die Zukunft zu verringern. Eine gängige, aber nicht generell einsetzbare, Empfehlung für die Behandlung eines kompromittierten Systems ist es, dieses abzuschalten, um die Beweise auf der Festplatte vollständig zu bewahren. Für ein Unternehmen müssen also individuell passende Verfahren festgelegt und das Personal in diesen Verfahren geschult werden. Im Falle eines kompromittierten IT-Systems muss aber durch geschultes Personal mittels spezieller Forensik-Tools eine Bit-by-bit-Kopie jeglicher Beweise, die sich auf der Festplatte oder anderen Medien des betroffenen Systems befinden, gemacht werden, um diese Beweise rechtlich verwenden zu können. Diese Kopie kann dann für die weitere Analyse oder Tests herangezogen werden. Das Original muss unverändert bleiben und sollte einer bestimmten Aufsichtsperson übergeben und bis zur Verwendung vor Gericht sicher verwahrt werden. Die/der Information Security Manager*in muss für den Fall eines Security Incidents dokumentierte Verfahren und Handlungsanweisungen für die Beweissicherung festgelegt haben. Eine weitere Voraussetzung für rechtlich verwendbare Beweise ist die detaillierte Dokumentation der Security Incidents.

Postevent Reviews

Nach der Bearbeitung und dem Abschluss von Incidents sollten die durchgeführten Aktivitäten einer Überprüfung unterzogen werden. Durch diese Postevent Reviews kann von jedem Incident und den resultierenden Aufwänden für eine entsprechende Reaktion und für die Wiederherstellung gelernt werden. Diese Erkenntnisse liefern wesentlichen Input für die Verbesserung der Verfahren und Handlungsanweisungen für die Behandlung von Incidents und die Wiederherstellung.

Identifizieren der Ursachen und korrigierende Maßnahmen

Security Incidents müssen nicht immer das Ergebnis von Attacken außerhalb oder innerhalb des Unternehmens sein, sondern können auch durch Fehler in den implementierten Security Controls verursacht werden. Für eine systematische Überprüfung von sicherheitsrelevanten Ereignissen, sollte ein Team für die Überprüfung der Ereignisse gebildet werden. Durch diese Überprüfungen kann das Team entsprechende Empfehlungen für die Verbesserung oder Erweiterung des Security Programs entwickeln, indem die Ursachen für das Ereignis und nötige Maßnahmen zur Vermeidung des wiederholten Auftretens identifiziert werden. Die Ursache vieler Einbrüche in Systeme sind oft schwache oder sogar fehlende Bewertungen von Schwachstellen und mangelndes Patch Management. Analysen sollten durchgeführt werden, um Fragen hinsichtlich der involvierten Personen, Symptom und Ursache der Attacke, Grund und Zeitraum des Angriffs etc. zu finden.

Post Incident Reviews und anschließende Prozeduren

Post Incident Reviews und die anschließenden Prozeduren sind wesentlich für eine kontinuierliche Verbesserung des Security Programs. Eine konsistente Methodik sollte innerhalb der für Sicherheit verantwortlichen Organisationseinheiten eingeführt und angewandt werden, sodass nach der Identifikation eines Problems ein Aktionsplan zur Vermeidung oder Verhinderung desselben entwickelt wird und Schritte zur Lösung ergriffen werden. Durch Wiederholen dieser einfachen Prinzipien kann das Security Program an Änderungen der Organisation und der daraus resultierenden möglichen Gefahren und Bedrohungen angepasst werden. Darüber hinaus wird der zeitliche Aufwand für die Reaktion des Personals auf Security Incidents verringert, sodass mehr Zeit für proaktive Aktivitäten genutzt werden kann. Der Follow-Up-Prozess nach der Incident-Behandlung ist das nützlichste Ergebnis des Aufwandes. Gesammelte Erfahrungen (Lessons Learned) während der Bearbeitung von Incidents können sowohl die Sicherheitsverfahren als auch den Prozess für die Incident-Behandlung selbst verbessern.

Herausforderungen bei der Entwicklung eines Incident Management Plans

Bei der Entwicklung und beim Erhalt eines Incident Management Plans können unerwartete Hürden auftreten, die durch vielfältige Gründe entstehen können.

Fehlende Unterstützung des Managements durch mangelnde Einbindung und mangelnde organisatorische Zustimmung können der Grund vieler Stolpersteine sein. Wenn ein Incident eintritt, kann die durch das Management entgegengebrachte Resonanz nicht wie benötigt sein und dadurch die Anstrengungen des Incident Managements behindern. Das passiert meistens dann, wenn das Senior Management und andere Interessensvertreter*innen nicht in die Implementierung und Planung des Incident Managements involviert werden.

Mangelnde Übereinstimmung mit organisatorischen Zielen und Strukturen führt dazu, dass die Leistungen des Incident Management nicht den Erwartungen des Senior Managements und den Fachbereichen entsprechen. Obwohl es sicherlich nicht einfach ist, die Fähigkeiten des Incident Managements an die sich rasch ändernden Ziele und Strukturen der Organisation anzupassen, müssen durch Gespräche kritische Business Funktionen und die betroffenen Stakeholder ermittelt, sowie die Rahmenbedingungen, denen das Business unterliegt, verstanden werden.

Die Entwicklung eines Incident Management Plans kann viel Zeit in Anspruch nehmen und erfordert eine intensive Interaktion mit unterschiedlichen Stakeholdern. Der oberste Kopf des Incident Managements, normalerweise Mitglied des Senior Managements oder die/der Information Security Manager*in, könnte unerwartet das Unternehmen verlassen und somit alle Planungs- und Entwicklungsanstrengungen zum Erliegen bringen. So eine Fluktuation oder auch ein Wechsel im Incident Management Team kann dazu führen, dass die Konzentration auf die Planung und Umsetzung schwindet oder Ressourcen dafür reduziert werden.

Mängel im Kommunikationsprozess führen entweder zu übermäßiger oder mangelnder Informationsweitergabe. Wenn zu wenig Information an die relevanten Stakeholder weitergegeben wird, führt das zu einem fehlenden oder falschen Verständnis für die Notwendigkeit der Planung, den Nutzen oder deren Rolle bei der Planung, Implementierung und Aufrechterhaltung des Incident Managements. Zu viel Information wiederum kann bei den Stakeholdern zu Ablehnung führen, da sie das Gefühl bekommen, zu viel Aufwand in die Planung investieren zu müssen oder andere, für sie wichtige, Themen zu vernachlässigen.

Der vorgeschlagene Plan kann gut sein und sehr viele Bereiche abdecken, aber gleichzeitig zu komplex und weit gegriffen. Pläne, die überdimensioniert erscheinen, können zu Ablehnung bei allen Beteiligten führen.

Incident Response Plan

Der Incident Response Plan stellt die operative Komponente des Incident Managements dar. Der Plan beinhaltet einen detaillierten Aktionsplan, Personalbeschreibungen und Aktivitäten, die in Situationen zu tragen kommen, wenn durch einen sicherheitsrelevanten Incident IT Services beeinträchtigt sind oder der Verlust von Informationen eingetreten ist. Der Response Plan umfasst dabei auch Wiederherstellungsstrategien und -pläne (Recovery Plans). Bei der Entwicklung von Response- und Recovery-Plänen müssen einige Dinge in Betracht gezogen werden, wie beispielsweise verfügbare Ressourcen, erwartete Arten und Schweregrad von Bedrohungen, denen die Organisation gegenüber steht. Die derzeitigen Möglichkeiten zur Erkennung von Incidents und für Monitoring müssen bekannt sein und die Risikotoleranz, welche die Organisation bereit ist zu tragen, muss bestimmt werden. Ziel einer effektiven Strategie für Recovery Plans ist es, ein kosteneffizientes Gleichgewicht zwischen den Bemühungen des Risk Managements, Incident Management und Response und der Business Continuity- und Disaster Recovery Plans zu schaffen.

Phasen eines Incident Response Plans

Vorbereitung und Grundlagen

In dieser Phase werden Vorbereitungen in der Organisation getroffen und grundlegende Voraussetzungen geschaffen, um den Incident Response Plan zu entwickeln. Eine ausreichende Vorbereitung erleichtert die spätere Umsetzung. Aktivitäten in dieser Phase sind

Festlegen einer Methode, um Incidents zu behandeln
Festlegen einer Policy und von Warnhinweisen in Informationssystemen, um Unberechtigte abzuschrecken und Informationen sammeln zu dürfen
Festlegen eines Kommunikationsplans gegenüber den Interessensvertreter*innen (Fachbereichen etc.)
Bestimmen von Kriterien, ab wann Incidents an hierarchisch übergeordnete Stellen berichtet werden (Eskalationspfade)
Entwickeln eines Prozesses, um das Incident Management Team zu aktivieren
Bestimmen einer sicheren Umgebung, in der der Incident Response Plan durchgeführt werden kann
Sicherstellen, dass das benötigte Equipment vorhanden oder verfügbar ist

Identifikation

In dieser Phase wird bestätigt, dass es sich um einen sicherheitsrelevanten Incident handelt und es werden Details über diesen Incident gesammelt. Mögliche Incidents können unter anderem von Informationssystemen, Endanwender*innen oder anderen Personen des Unternehmens gemeldet werden. Nicht alle dieser gemeldeten Vorfälle sind als sicherheitsrelevante Incidents einzustufen, da es sich um Fehlalarme handeln kann, oder weil der Vorfall nicht den Kriterien eines sicherheitsrelevanten Incidents entspricht. Aktivitäten in dieser Phase sind

Zuweisen des (potentiellen) Incidents an eine/n Bearbeiter*in (Incident Handler)
Prüfen, dass es sich bei dem gemeldeten Ereignis um einen Security Incident handelt
Festlegen einer Kontroll- oder Überwachungskette während der Identifikation, wenn mögliche Beweise gesichert werden müssen
Bestimmen der Dringlichkeit des Incidents und entsprechende Eskalation, wenn nötig

Eindämmung

Nachdem ein Security Incident identifiziert und bestätigt wurde, wird das Incident Management Team (IMT) aktiviert und die Informationen, die die/der Incident Handler gesammelt hat, im Team verteilt. Das Team führt daraufhin eine detaillierte Beurteilung und Bewertung durch. Es informiert die/den Systemverantwortliche*n oder Business Manager*in über die betroffenen Informationssysteme oder Assets, um weitere Schritte zu koordinieren. Die Aktivitäten in dieser Phase zielen darauf ab, die Gefahren des Incidents einzudämmen. Aktivitäten in dieser Phase sind

Aktivierung des IMT, um den Incident zu beurteilen und einzudämmen
Benachrichtigung der Stakeholder, welche von dem Incident betroffen sind
Zustimmung für Aktivitäten, welche die Verfügbarkeit eines IT Services beeinflussen können oder für Risiken, die aus den nötigen Prozessen zur Eindämmung entstehen können, einholen
Zusammenführen der involvierten IT Expert*innen und relevanten Mitglieder des virtuellen Teams, um die Prozeduren für die Eindämmung durchzuführen
Einholen und Sichern von möglichen Beweisen
Dokumentieren von und Sicherungen erstellen bei Aktivitäten von dieser Phase an
Steuern der Kommunikation gegenüber der Öffentlichkeit durch das PR Team

Im Incident Response Plan müssen Voraussetzungen für die Benachrichtigung von Schlüsselpersonen und Entscheidungsträger*innen, Systemverantwortlichen und Endanwender*innen vorhanden sein, die für die Initiierung und Ausführung der Incident-Behandlung benötigt werden. Ein Verzeichnis von Telefonnummern von Personen, die im Falle eines Incidents benachrichtigt werden müssen, ist ein wesentlicher Bestandteil des Benachrichtigungsprozesses. Dieses Verzeichnis sollte Informationen, wie beispielsweise eine priorisierte Liste zu benachrichtigender Kontakte, Primär- und Notfalltelefonnummer und Adressen für jede Schlüsselperson, Kontaktdaten von Lieferanten und Herstellern relevanter Hard- und Software, Kontaktdaten von Mitarbeiter*innen des Betriebs, Telefonnummern von Behörden und Personen mit gesetzlichen Durchsetzungsrechten im Falle schwerwiegender Sicherheitszwischenfällen, beinhalten.

Beseitigung

Wenn die Maßnahmen zur Eindämmung durchgeführt wurden, muss die Ursache des Incidents gefunden und beseitigt werden. Das kann auf unterschiedliche Art und Weise erfolgen. Beispielsweise durch Rücksichern, um einen bestimmten Zustand des Systems wiederherzustellen, einfaches Beheben der Ursache oder Verstärken der Abwehrmechanismen und Durchführen von Schwachstellenanalysen (Vulnerability Analysis), um weitere mögliche Schadenspotentiale durch die gleiche Ursache zu verhindern. Aktivitäten in dieser Phase sind

Bestimmen der Symptome und der Ursache eines Incidents
Finden der aktuellsten Version des Backups oder von alternativen Lösungen
Beheben der Ursache (auch z.B. durch Einspielen entsprechender Patches)
Verstärken der Abwehrmechanismen, durch Implementierung von technischen Sicherheitsmaßnahmen
Durchführen von Schwachstellenanalysen, um neue Schwachstellen aufgrund der gleichen Ursache zu finden

Wiederherstellung

Diese Phase stellt sicher, dass betroffene Systeme oder Services nach den definierten RPOs (Recovery Point Objectives) wiederhergestellt werden. RPO gibt an, wie alt die Daten zum Zeitpunkt der Wiederherstellung sein dürfen. Die Zeit, in der die Wiederherstellung erfolgen muss, ist in den RTOs (Recovery Time Objectives) definiert. Aktivitäten in dieser Phase sind

Wiederherstellen des normalen Geschäftsbetriebes oder Funktionszustandes
Überprüfen, ob die durchgeführten Aktivitäten für die Wiederherstellung der Systeme erfolgreich waren
Testen der Systeme durch die Systemverantwortlichen
Unterstützung der Systemverantwortlichen bei der Bekanntgabe des Normalbetriebs

Es gibt viele Strategien für die Wiederherstellung kritischer Informationen, deren Entwicklung je nach Größe und Komplexität der Organisation entsprechend Zeit beansprucht und Kosten verursachen kann. Es sollte jene verfolgt werden, die wahrscheinliche Ereignisse innerhalb akzeptabler Wiederherstellungszeiten zu gerechtfertigten Kosten mit Sicherheit abdeckt. Die Gesamtkosten für Wiederherstellungsfähigkeiten setzen sich aus den Kosten für die Vorbereitung auf mögliche Unterbrechungen (z.B. Beschaffung, Wartung und Test von redundanten Rechnern, Wartung alternativer Netzwerkrouten, Schulungs- und Personalkosten etc.) und den Kosten des Einsatzes der vorbereiteten Maßnahmen bei Eintritt eines Ereignisses zusammen. Bei den Überlegungen möglicher Strategien sollen auch Versicherungen, welche verschiedene Formen von Beeinträchtigungen des Geschäftsbetriebs abdecken, berücksichtigt werden.

Die/der Information Security Manager*in muss die nötigen grundlegenden Prozesse für die Wiederherstellung des Betriebs nach Incidents, wie z.B. DoS-Attacken, Naturereignisse und anderen potentiellen Unterbrechungen der Geschäftstätigkeiten, kennen. Unter Disaster Recovery (DR) versteht man dabei die Wiederherstellung von IT-Systemen nach Zerstörungen durch Naturgewalten. Business Recovery (BR) bezeichnet die Wiederherstellung von kritischen Geschäftsprozessen, um den Geschäftsbetrieb wieder aufnehmen zu können. Business Recovery beinhaltet dabei neben dem Disaster Recovery alle anderen Aspekte des Geschäftsbetriebs. Unabhängig von der Ursache der Unterbrechung des Geschäftsbetriebs, müssen Aktivitäten und Maßnahmen zum Erhalt oder Wiederherstellung des Geschäftsbetriebs rasch gesetzt werden.

Ein wesentlicher Prozess während der Planung ist die Durchführung einer Business Impact Analyse (BIA), um die Kosten beim Ausfall von Systemen bestimmen zu können. Das bereitet die Basis für die Festlegung angemessener Recovery Time Objectives (RTOs), was wiederum Einfluss auf die Örtlichkeit und Kosten von außerbetrieblichen Einrichtungen zur Wiederherstellung (z.B. Ausfallsrechenzentren) nimmt. Der Zweck einer Business Impact Analyse (BIA) ist die Erstellung eines Dokuments, das Interessensvertreter*innen hilft, zu verstehen, welche Auswirkung ein Incident auf das Business und die Geschäftsprozesse hat. Die Auswirkung oder Beeinflussung kann dabei entweder qualitativ (z.B. Einschätzungen) oder quantitativ (z.B. Kosten) bewertet werden. Um den Prozess einer BIA adäquat durchführen zu können, ist es wesentlich, über die Struktur und Kultur des Unternehmens, seine Kerngeschäftsprozesse, Risikotoleranz und kritische IT-Ressourcen Bescheid zu wissen. Für eine erfolgreiche BIA wird die Beteiligung von Prozessverantwortlichen, Senior Management, IT, Sicherheitsverantwortlichen und Endanwender*innen benötigt.

Eine BIA verfolgt drei Ziele:

Priorisierung nach Kritikalität: Jeder kritische Prozess von Geschäftsbereichen muss identifiziert, priorisiert und die Auswirkung eines Incidents auf den Geschäftsbereich evaluiert werden. Je größer die Auswirkung, desto höher muss die Priorität gesetzt werden.
Schätzung der (maximalen) Ausfallszeit: Die BIA wird auch genutzt, um die maximal tolerierbare Ausfallszeit (Maximum Tolerable Downtime MTD) und die maximal tolerierbare Unterbrechung (Maximum Tolerable Outage MTO) von kritischen Prozessen, IT Services und Informationen für das Business zu ermitteln, sodass das Business noch funktionsfähig bleibt.
Benötigte Ressourcen zuweisen: Benötigte Ressourcen für kritische Prozesse werden zu diesem Zeitpunkt ebenfalls identifiziert. Jene Prozesse, die am zeitkritischsten sind und der größten Beeinflussung durch Incidents ausgesetzt sind, erhalten dabei die höchste Ressourcenzuteilung.

Der Prozess einer BIA besteht aus folgenden Aktivitäten:

Sammlung von Informationen für die Beurteilung: Der erste Schritt einer BIA ist die Identifikation der kritischen Geschäftsbereiche des Unternehmens. Dieser Schritt kann soweit detailliert und verfeinert werden, um jene kritischen Tätigkeiten festzustellen, die durchgeführt werden müssen, um den Fortbestand des Business zu gewährleisten.

Bewertung der Störanfälligkeit (Vulnerability Assessment)

Analyse der zusammengestellten Informationen: In dieser Phase werden die relevanten Prozesse dokumentiert, Wechselbeziehungen identifiziert und die akzeptable Unterbrechungszeit ermittelt. Die Phase beinhaltet

Identifizierung von Wechselbeziehungen zwischen Funktionen und Geschäftsbereichen
Aufdecken aller möglichen Störungen und Unterbrechungen, welche die Geschäftsbereiche in ihrer Zusammenarbeit behindern
Identifizierung und Dokumentation potentieller Bedrohungen, welche die Kommunikation zwischen den Geschäftsbereichen unterbrechen können
Sammlung von qualitativen und quantitativen Informationen in Bezug auf diese Bedrohungen
Bereitstellen von alternativen Methoden, um Funktionalitäten und Kommunikation wieder herstellen zu können
Dokumentation des Ergebnisses und Präsentation der Empfehlungen

Lessons Learned

Am Ende des Incident-Response-Prozesses wird ein Bericht erstellt, aus dem hervorgeht, was passiert ist, welche Maßnahmen gesetzt und die Ergebnisse dokumentiert wurden, nachdem der Incident Response Plan ausgeführt wurde. Der Plan sollte die „Lessons Learned“ beinhalten, die dem IMT und anderen Stakeholdern wertvolle Hinweise zur Verbesserung liefern können. Diese Hinweise sollten ebenso in die Weiterentwicklung des Incident Response Plans aufgenommen werden, um die Leistungsfähigkeit des Incident Management zu erhöhen.

Aktivitäten in dieser Phase sind

Erstellen eines Incident-Berichts
Analysieren auf Probleme während der Incident-Response-Aktivitäten
Entwickeln von Verbesserungsvorschlägen auf Basis der erkannten Probleme
Präsentation des Berichts vor den relevanten Stakeholdern

Phasen eines Incident Response Plans

Regelmäßige Anpassung des Incident Response Plans und Recovery Plans

Durch die Dynamik von Organisationen und stetigen Veränderungen müssen auch die Response und Recovery Plans regelmäßig angepasst werden, um den aktuellen Zielen und Ansprüchen des Unternehmens zu entsprechen. Dabei ist es wichtig, die Zustimmung und Rückendeckung des Senior Managements für den Prozess der regelmäßigen Anpassung zu erhalten, da dieser fortlaufende Prozess Unternehmensressourcen beansprucht um ein akzeptables Niveau der Wiederherstellungsfähigkeiten zu erreichen und zu erhalten.

Regelmäßige Tests und Training

Das Testen aller Aspekte der Notfallpläne ist der wichtigste Faktor für die erfolgreiche Bewältigung einer Notfallsituation. Durch das Testen soll sichergestellt werden, dass die Ausführung des Plans zu einer erfolgreichen Wiederherstellung der Infrastruktur und Wiederaufnahme kritischer Geschäftsprozesse führt. Bei Response-und-Recovery-Plänen, die nicht getestet wurden, bleibt eine gewisse Unsicherheit, ob diese Pläne auch tatsächlich funktionieren. Jeder Test sollte mit folgenden Aktivitäten in Form eines Kreislaufes aufgebaut werden.

Entwickeln und Festlegen der Ziele des Tests
Ausführung des Tests
Evaluierung des Testablaufs und der Testergebnisse
Entwickeln von Empfehlungen um die Effektivität der Testprozesse und damit der Response-und-Recovery-Pläne zu verbessern
Implementierung eines Follow-Up-Prozesses, um die Umsetzung der Empfehlungen zu prüfen

Kreislauf: Ablauf von Aktivitäten bei Tests

Jeder Test sollte den Fokus auf das Identifizieren von Schwachstellen, das Prüfen und Bestätigen von Vermutungen, das Testen der Einhaltung von Zeiten, die Effektivität der entwickelten Strategien, die Leistungen der beteiligten Personen und die Vollständigkeit und Aktualität der Informationen aus den Plänen richten.

Tests fördern die Zusammenarbeit und die Koordination innerhalb des Teams und stellen ein nützliches Trainingswerkzeug dar. Deshalb führen viele Organisationen jährlich vollständige Wiederherstellungstests durch.

Nach der Fertigstellung von Entwurfs- oder Ergänzungsplänen sowie bei Änderungen, die das Schlüsselpersonal betreffen, bei Änderungen in der eingesetzten Technologie oder im Umfeld des Business oder den Regelwerken sollten entsprechende Tests durchgeführt werden.

Das Testen muss sorgfältig geplant und kontrolliert durchgeführt werden, da das Testen einerseits Zeit und Ressourcen in Anspruch nimmt, andererseits, um das Business nicht erhöhten Risiken auszusetzen. Vor jedem Test sollte die/der Information Security Manager*in darauf achten, dass das Risiko und die Unterbrechung durch das Testen minimiert werden, das Business über das entsprechende Risiko informiert ist und dieses akzeptiert, Vorbereitungen für den Rückstieg (Fallback) zu jedem Zeitpunkt des Tests existieren. Um die regelmäßige Durchführung von Tests aller Pläne zu gewährleisten, sollte ein Testplan mit dem Datum des geplanten Tests für alle kritischen Funktionen erstellt und gewartet werden. Alle Tests müssen durchgehend mit Pre-Test-, Test- und Post-Test- Berichten dokumentiert werden und diese Dokumentationen sollten für Audits etc. aufbewahrt werden. Darüber hinaus muss die/der Information Security Manager*in sicherstellen, dass die Sicherheit von Informationen während der Tests nicht gefährdet wird, sondern mitgetestet wird.

Arten von Tests

Das Testen sollte einfach beginnen und stufenweise durch Erweitern der Ziele und Erfolgskriterien gesteigert werden, um das Vertrauen des Business in die Tests zu stärken und Risiken für das Business zu vermindern.

Prüfen von Checklisten: Sollte als einleitender Schritt für Tests durchgeführt werden. Bestehende Checklisten werden an alle Mitglieder des Recovery Teams zur Prüfung auf Aktualität verteilt.
Strukturiertes Durchgehen: Teammitglieder führen den Plan auf Papier aus und prüfen jeden Schritt auf seine Effektivität und identifizieren Verbesserungen, Einschränkungen oder Mängel.
Simulationstests: Das Recovery Team spielt ein vorbereitetes Notfallszenario mit entsprechenden Rollenverteilungen durch, ohne jedoch die Wiederherstellungseinrichtungen zu aktivieren.
Paralleltests: Die Wiederherstellungseinrichtungen werden in einen aktiven Betriebszustand gebracht, wobei die primären Einrichtungen ihre Arbeit normal fortsetzen.
Tests mit vollständiger Unterbrechung: Der Betrieb der primären Einrichtungen wird eingestellt (unterbrochen) und nach dem Recovery Plan in der Wiederherstellungseinrichtung wieder aufgenommen. Dies ist zwar die am meisten rigorose Art zu testen, aber gleichzeitig auch die teuerste und risikoreichste. Ein Test mit voller Unterbrechung sollte jährlich durchgeführt werden, nachdem alle einzelnen Komponenten des Plans separat erfolgreich getestet wurden.

Stufenweises Durchführen der Testarten

Tests, vor allem jene mit Unterbrechungen des Normalbetriebs, sollten zu Zeiten eingeplant werden, an denen der normale Geschäftsbetrieb so wenig wie möglich beeinträchtigt wird. Wochenenden und Feiertage können dafür eine gute Wahl sein. Es ist wichtig, dass alle Schlüsselpersonen des Recovery Teams im Testprozedere involviert sind und dem Team auch ausreichend Zeit für die Durchführung der Tests zugeteilt wird. Für realistische Ergebnisse sollte der Test alle kritischen Komponenten abdecken und Bedingungen des Betriebs zu Spitzenzeiten simulieren, auch wenn der Test außerhalb der Betriebszeiten durchgeführt wird.

Results

Ziele

Incident Management wird eingeführt, um unausweichliche Ereignisse zu behandeln, die den Betrieb jeder Organisation gefährden. Daher werden bei der Planung und Einführung von Incident Management bestimmte Ziele verfolgt. Die Behandlung von eintretenen Incidents muss so erfolgen, dass die Auswirkungen eingedämmt werden, um eine Wiederherstellung innerhalb der AIW (Acceptable Interruption Window) zu ermöglichen. Durch Dokumentation und Lerneffekte vergangener Incidents soll verhindert werden, dass diese früher aufgetretenen Incidents wieder auftreten. Proaktive Gegenmaßnahmen müssen entwickelt und ausgerollt werden, um das Eintreten von Incidents zu verhindern oder die Eintrittswahrscheinlichkeit zu mindern. Incident Management und Response muss die Behandlung einer breiten Palette an möglichen, unerwarteten Ereignissen abdecken. Dafür müssen entsprechende Überwachungsfunktionen auf technischer oder prozessualer Ebene entwickelt und eingesetzt werden, damit potentielle Probleme möglichst früh erkannt werden können. Das Personal muss ausreichend geschult und trainiert werden, um Situationen richtig einschätzen und die Handlungsreihenfolge festlegen zu können, effektive Reaktionen für die Aufrechterhaltung des Betriebs setzen zu können und die Auswirkungen zu minimieren.

Kennzahlen

Kennzahlen sind wichtige Kriterien, um die Effektivität und Effizienz des Incident Managements zu messen. Sie basieren auf Key Performance Indicators (MAPs) und Zielen des Programs für das Incident Management und sollten dem Senior Management als Basis für eine nachhaltige Unterstützung (regelmäßig) präsentiert werden. Berichte über Maßzahlen des Incident Managements sind auch als Werkzeug zur Selbstüberprüfung des IMT nötig, damit ein Verständnis geschaffen wird, was zufriedenstellend läuft oder wo Verbesserungen nötig sind.

Übliche Kriterien für Kennzahlen des Incident Managements sind:

Anzahl der gemeldeten Incidents
Anzahl der entdeckten Incidents
Durchschnittliche Reaktionszeit auf einen Incident in Relation zum Acceptable Interruption Window (AIW, ist die maximale Zeitspanne die ein System ausfallen darf, bevor die Geschäftstätigkeiten gefährdet sind)
Durchschnittliche Lösungszeit
Anzahl der erfolgreich gelösten Incidents
Anzahl der gesetzten proaktiven und präventiven Maßnahmen
Anzahl der Mitarbeiter*innen, die an Security Awareness Trainings teilnahmen
Gemessener Schaden von gemeldeten und entdeckten Incidents, wenn die Incidents nicht behandelt wurden
Einsparung von potentiellem Schaden durch gelöste Incidents

Wiederholungsaufgaben

Beschreiben Sie kurz die Phasen eines Incident Response Plans!
Welche Aktivitäten sollen beim Testen der Detailpläne für Incident Response und Recovery durchgeführt werden?
Nennen Sie fünf Kriterien für Kennzahlen des Incident Managements! Beschreiben Sie kurz, warum der Einsatz von Kennzahlen wichtig ist?

Beschreiben Sie kurz die Phasen eines Incident Response Plans!
Vorbereitung: In dieser Phase werden Vorbereitungen in der Organisation getroffen, um den Incident Response Plan zu entwickeln, denn eine ausreichende Vorbereitung erleichtert die spätere Umsetzung.

Identifikation: In dieser Phase wird bestätigt, dass es sich um einen sicherheitsrelevanten Incident handelt und es werden Details über diesen Incident gesammelt. Mögliche Incidents können unter anderem von Informationssystemen, Endanwendern oder anderen Personen des Unternehmens gemeldet werden.

Eindämmung: Nachdem ein Security Incident identifiziert und bestätigt wurde, wird das IMT aktiviert und die Informationen, die der Incident Handler gesammelt hat, im Team verteilt. Das Team führt daraufhin eine detaillierte Beurteilung und Bewertung durch. Es informiert den Systemverantwortlichen oder Business Manager über die betroffenen Informationssysteme oder Assets um weitere Schritte zu koordinieren. Die Aktivitäten in dieser Phase zielen darauf ab, die Gefahren des Incidents einzudämmen.

Beseitigung: Wenn die Maßnahmen zur Eindämmung durchgeführt wurden, muss die Ursache des Incidents gefunden und beseitigt werden. Das kann auf unterschiedliche Art und Weise erfolgen.

Wiederherstellung: Diese Phase stellt sicher, dass betroffene Systeme oder Services nach den definierten RPOs wiederhergestellt werden.

Lessons Learned: Am Ende des Incident Response Prozesses sollte immer ein Bericht erstellt werden, aus dem hervorgeht, was passiert ist, welche Maßnahmen gesetzt wurden und die Ergebnisse, nachdem der Incident Response Plan ausgeführt wurde. Der Plan sollte die „Lessons Learned“ beinhalten, die dem IMT und anderen Stakeholdern wertvolle Hinweise zur Verbesserung liefern können. Diese Hinweise sollten ebenso in die Weiterentwicklung des Incident Response Plans aufgenommen werden, um die Leistungsfähigkeit des Incident Management zu erhöhen.
Welche Aktivitäten sollen beim Testen der Detailpläne für Incident Response und Recovery durchgeführt werden?
Jeder Test sollten mit folgenden Aktivitäten in Form eines Kreislaufes aufgebaut werden.
- Entwickeln und Festlegen der Ziele des Tests
- Ausführung des Tests
- Evaluierung des Testablaufs und der Testergebnisse
- Entwickeln von Empfehlungen um die Effektivität der Testprozesse und damit der Response und Recovery Pläne zu verbessern
- Implementierung eines Follow-Up Prozesses, um die Umsetzung der Empfehlungen zu prüfen
Nennen Sie fünf Kriterien für Kennzahlen des Incident Managements! Beschreiben Sie kurz, warum der Einsatz von Kennzahlen wichtig ist?
Kennzahlen sind wichtige Kriterien, um die Effektivität und Effizienz des Incident Managements zu messen. Sie sollten dem Senior Management als Basis für eine nachhaltige Unterstützung (regelmäßig) präsentiert werden. Berichte über Maßzahlen des Incident Managements sind auch als Werkzeug zur Selbstüberprüfung des IMT nötig, damit ein Verständnis geschaffen wird, was zufriedenstellend läuft, oder wo Verbesserungen nötig sind.
5 Kriterien für Kennzahlen des Incident Managements sind:
- Anzahl der gemeldeten Incidents
- Durchschnittliche Lösungszeit
- Anzahl der erfolgreich gelösten Incidents
- Gemessener Schaden von gemeldeten und entdeckten Incidents, wenn die Incidents nicht behandelt wurden
- Einsparung von potentiellem Schaden durch gelöste Incidents

↑ engl. property that an entity is what it is claims to be [ISO00]
↑ engl. provision of assurance that a claimed characteristic of an entity is correct [ISO00]
↑ In der diesem Skriptum zugrunde liegenden Hauptliteratur [CIS10] wird von „Board of Directors“ gesprochen. Dieser ist allerdings nicht 1:1 mit dem Aufsichtsrat mitteleuropäischer Unternehmen gleichzusetzen, da im angelsächsischen Raum dieses Board mehr Kompetenzen hat. Deswegen sprechen wir hier allgemein von „Unternehmensaufsicht“.
↑ Im angelsächsischen Raum, mittlerweile aber auch in Mitteleuropa haben sich die C-Level-Akronyme durchgesetzt, also CEO, CFO, CIO. Wir sprechen allgemein von „Unternehmensführung“ oder „Management“.
↑ Information Security (ohne „Management“) kann selbstverständlich auch bottom up implementiert werden; man kann zwar sicher sein, dass man alles richtig macht („do things right“) – aber nicht, dass man auch das Richtige macht („do the right things“).
↑ Diese sind zu unterscheiden von den (ebenfalls sechs) Zielsetzungen auf operativer Ebene (siehe weiter unten).
↑ Diese sind zu unterscheiden von den (ebenfalls sechs) Zielkategorien auf strategischer Ebene (siehe weiter oben).
↑ „MAG“ und „MAP“ sind eigene Abkürzungen und stammen nicht aus [COB12].
↑ MAGs wurden in früheren Ausgaben von COBIT als KGIs bezeichnet.
↑ MAPs wurden in früheren Ausgaben von COBIT als KPIs bezeichnet.

[1] . property that an entity is what it is claims to be [ISO00]

[2] . provision of assurance that a claimed characteristic of an entity is correct [ISO00]

[3] In der diesem Skriptum zugrunde liegenden Hauptliteratur [CIS10] wird von „Board of Directors“ gesprochen. Dieser ist allerdings nicht 1:1 mit dem Aufsichtsrat mitteleuropäischer Unternehmen gleichzusetzen, da im angelsächsischen Raum dieses Board mehr Kompetenzen hat. Deswegen sprechen wir hier allgemein von „Unternehmensaufsicht“.

[4] Im angelsächsischen Raum, mittlerweile aber auch in Mitteleuropa haben sich die C-Level-Akronyme durchgesetzt, also CEO, CFO, CIO. Wir sprechen allgemein von „Unternehmensführung“ oder „Management“.

[5] Information Security (ohne „Management“) kann selbstverständlich auch bottom up implementiert werden; man kann zwar sicher sein, dass man alles richtig macht („do things right“) – aber nicht, dass man auch das Richtige macht („do the right things“).

[6] Diese sind zu unterscheiden von den (ebenfalls sechs) Zielsetzungen auf operativer Ebene (siehe weiter unten).

[7] Diese sind zu unterscheiden von den (ebenfalls sechs) Zielkategorien auf strategischer Ebene (siehe weiter oben).

[8] „MAG“ und „MAP“ sind eigene Abkürzungen und stammen nicht aus [COB12].

[9] MAGs wurden in früheren Ausgaben von COBIT als KGIs bezeichnet.

[10] MAPs wurden in früheren Ausgaben von COBIT als KPIs bezeichnet.

[1]

[2]

[3]

[4]

[5]

[6]

[7]

[8]

[9]

[10]

Informationssicherheitsmanagement - Gesamt

Information Security Management – Aufbau

Grundlagen

Sicherheits-Risikomanagement

Informationssicherheitsmanagementsystem - ISMS

Definition

Products

Konzepte

Information Security Management

Information Security Program

Bausteine eines ISMS

Information Security Risk Management

Enterprise Information Security Architecture

Steuerungsmaßnahmen (controls)

Analyse der Projektrisiken

Business Impact Analysis

External Security Service Providers

Technische Maßnahmen (technical controls)

Rahmenbedingungen

Informations-Infrastruktur und -Architektur

People

Rollen und Verantwortlichkeiten

Information Security Risk Management

Information Security Management

Organisationsübergreifende Verantwortungen

Wiederholungsaufgaben

Information Security Management – Ablauf

Process

Information Security Risk Management

Information Security Management

Results

Ergebnis

Metriken

Metrik-Entwicklung

Security Baseline

Akkreditierung und Zertifizierung

Wiederholungsaufgaben

Information Security Incident Management – Aufbau

Incident Management & Incident Response

Products

Konzepte

Benötigte Ressourcen

Konzepte und Technologien

Incident Management Systeme

Richtlinien (Policies) und Standards

Personal und Verantwortlichkeiten

Fähigkeiten - Skills

Awareness und Ausbildung

Audits

People

Rollen und Verantwortlichkeiten

Senior Management Commitment

Information Security Manager*in

Incident Response Team

Incident Management Team und Incident Response Team

Kenntnisse und Training

Wiederholungsaufgaben

Information Security Incident Management – Ablauf

Process

Aktivitäten

Bestimmung der bestehenden Möglichkeiten, um auf Incidents zu reagieren

Entwickeln eines Incident Response Plans

Entwickeln von Detailplänen für Recovery und Response

Organisation, Training und Ausrüsten des Response Personals

Wiederherstellungsstrategien

Planung der Wiederherstellung und Business Recovery Prozesse

Recovery Sites

Grundlagen für die Auswahl einer Recovery Site

Incident Management und Response Teams

Voraussetzungen für Benachrichtigungen

Betriebsmittel

Versicherungen

Regelmäßige Anpassung des Recovery Plans

Wiederherstellungspläne und Informationssicherheit

Umsetzung der Detailpläne für Response und Recovery

Eskalationsprozess

Policies und Prozesse für Intrusion Detection (ID)

Service Desk Prozesse für die Identifizierung von Security Incidents

Benachrichtigungsprozess

Dokumentieren von Ereignissen