Beim vorliegenden Artikel handelt es sich um einen Auszug aus dem vollständigen Konzept. Für die vollständige Übersicht, Analyse und Konklusion wird auf das registrierungspflichtige Dokument verwiesen.

** Slides - Typische Problemstellen im Informationssicherheits-Management

Ausgangslage

Gibt es ein IT Sicherheitsmodell, das allen Anforderungen gerecht wird und funktioniert? Einige der folgenden typischen Problemstellungen sind bekannt – gesucht sind praktikable Lösungsansätze.

Viele Unternehmen verwenden zur Sicherstellung der Informationssicherheit ein Sicherheitsmodell oder stehen vor der Herausforderung, ein solches zu entwickeln und einzuführen. Leider Informationssicherheit eine vielschichtige Angelegenheit, welche praktisch die gesamte Organisation und alle (wichtigen) Prozesse durchdringt. Gefragt ist also ein strukturiertes und geplantes Vorgehen.

Verbreitetes Sicherheitsmodell

Das Sicherheitsmodell ist hier nicht abgebildet – siehe hierzu das registrierungspflichtige Dokument.

Aber auch mit einem solchen Modell ist der Erfolg noch keineswegs garantiert. Typischerweise entstehen bei der Anwendung des Modells immer wieder gleichen Problemstellen (in der Grafik markiert).

Problemstellen

Sicherheitsprozess und Sicherheitsorganisation

Da das Sicherheits-Framework ein starres Gebilde ist, braucht es einen Sicherheitsprozess, der dieses institutionalisiert. Bestandteil des Sicherheitsprozesses ist ein Ablaufverfahren, z.B. nach dem PDCA-Modell (Plan – Do – Check – Act). Daraus lassen sich folglich die damit verbundenen Aufgaben, die erst eine Sicherheitsorganisation notwendig machen, ableiten. Fragen:

• Existieren Sicherheitsprozess & -organisation in effizienter und effektiver Form?
• Sind Aufgaben, Kompetenzen & Verantwortungen definiert?
• Kann die Sicherheitsorganisation die damit verbundenen Aufgaben abdecken?

Grundschutz-Problematik

Die vorhandenen Standardwerke (ISO, GSHB, Cobit und andere) sind sehr umfangreich. Die Informationssicherheitsbezogenen Anforderungen von Unternehmen unterscheiden sich aber von Fall zu Fall. Die Standardwerke müssen also an die eigenen Bedürfnisse angepasst werden. Dies umso mehr, wenn man sich vor Augen führt, dass eine theoretische Bedrohung nicht gleichbedeutend mit einem Risiko sein muss. Für eine Bedrohung muss es ein realistisches Szenario geben. Aus diesem, gepaart mit einer veritablen Eintrittswahrscheinlichkeit und Schadensausmass, ergibt sich das Risiko. Fragen:

• Welches Mass an Grundschutz und wo benötigt ein Unternehmen?
• Wie lassen sich die vorhandenen Standardwerke adaptieren?

Erweiterter Grundschutz

Das ermittelte Mass an Grundschutz ist u. U. nicht für alle Bereiche ausreichend. Spezielle Bereiche benötigen, abhängig von den Anforderungen der Businessprozesse, sowie der Klassifizierung der Daten und Informationen, einen erhöhten Schutz. Das zusätzliche Mass an Schutzbedarf ergibt sich aus der erweiterten Risikoanalyse. Fragen:

• Wie funktioniert eine erweiterte Risikoanalyse und was ist Bestanteil davon?
• Wann lohnt sich die erweiterte Risikoanalyse?

Kongruenz und Anzahl der Sicherheitsvorgaben

Das vorgestellte Sicherheitsmodell funktioniert nach dem „Top-Down“ Prinzip – dabei gilt: „Je tiefer die Ebene im Sicherheitsmodell, desto detaillierter und umfangreicher die Sicherheitsvorgaben, also auch die Anzahl der Dokumente“. Fragen:

• Wie wird die Kongruenz der verschiedenen Dokumente sichergestellt?
• Wie lassen sich die Flut der Vorgaben sowie die Anzahl der Dokumente begrenzen?

Sicherheit in Projekten

Aufgrund des Sicherheitsmodells existieren jetzt viele Sicherheitsvorgaben in verschiedenen Dokumenten, eventuell auf unterschiedlichen Ebenen und aus verschiedenen Bereichen. Es gilt nun, die Sicherheitsvorgaben auch in Projekten anzuwenden. Fragen:

• Wie lassen sich die Sicherheitsvorgaben in Projekten umsetzen?
• Lässt sich Sicherheit in Projekten automatisieren?
• Wie werden die Sicherheitsvorgaben kontextgerecht an den Projektleiter vermittelt?

Bildung und Klassifizierung von Schutzobjekten (SO)

Primäres Anwendungsgebiet der Sicherheitsvorgaben sind die SO. Die Sicherheitsvorgaben werden durch eine Klassifizierung auf die SO vererbt. Primäres Objekt der Klassifizierung ist generell das Schutzobjekt „Informationen“. Fragen:

• Nach welchen Kriterien werden SO gebildet und sinnvoll gruppiert?
• Welches sind die Kriterien für die Klassifizierung?

Anwendung von Sicherheitsvorgaben

Wie vorgehend erwähnt sind die Schutzobjekte das primäre Anwendungsgebiet der Sicherheitsvorgaben. Typische Problemstellen sind:

• Nach welchem Modell werden die Vorgaben auf die SO angewendet?
• Kann die Menge der Sicherheitsvorgaben durch das Modell gesteuert werden?

Lösungsansätze

In diesem Kapitel werden Lösungsansätze vorgestellt, die helfen sollen, die Auswirkungen der erkannten Problemstellen zu vermindern oder im Idealfall zu vermeiden.

Problemstelle 1: Sicherheitsprozess und Sicherheitsorganisation

Das Sicherheits-Framework benötigt ein ablaufbezogenes Verfahren.

Das Sicherheitsmodell ist hier nicht abgebildet – siehe hierzu das registrierungspflichtige Dokument.

Die vier Phasen des Sicherheitsprozesses bilden einen geschlossenen Kreislauf und sollen dadurch die Nachhaltigkeit der Informationssicherheit sicherstellen. Aus dem Sicherheitsprozess lassen sich folglich die damit verbundenen Aufgaben ableiten, die durch eine Sicherheitsorganisation bearbeitet werden müssen. Die nächste Grafik (nicht dargestellt) zeigt eine mögliche Aufbau-Sicherheitsorganisation für eine KMU. In einem Grossunternehmen sind häufig „spezielle“ Einheiten wie Risk Management, Business Kontinuität (BCP), ein zentraler Datenschutzbeauftragter und mehrere Security Officers zu finden. Der Grundaufbau der Sicherheitsorganisation und die Idee dahinter sind aber bei einem KMU und einem grossen Unternehmen nahezu identisch.

Die Sicherheitsorganisation agiert auf den Ebenen der organisatorischen, physischen, operativen und logischen Sicherheit. Die Aufgaben, Kompetenzen und Verantwortungen sind definiert. Innerhalb der Organisation im Bereich der logischen Sicherheit sind auch die Schutzobjektverantwortlichen bestimmt.

Problemstelle 2: Grundschutz-Problematik

Die Aufgabe des Grundschutzes ist es, in einem ersten Schritt ein minimales Mass an Sicherheit in alle Bereiche des Unternehmens auszubreiten. Die vorhandenen Standards müssen aus den genannten Gründen an die eigenen Bedürfnisse adaptiert werden. Zudem muss sich auch Sicherheit rentieren und einen (messbaren) Nutzen bringen.

Das Sicherheitsmodell ist hier nicht abgebildet – siehe hierzu das registrierungspflichtige Dokument.

Dabei werden nicht zutreffende Haupt- und Unterkapitel entfernt. Bei Bedarf können eigene Kapitel hinzugefügt werden. Dann wird die Struktur des Katalogs definiert sowie anschliessend die System- und Vorgehenszielen festgelegt. Nächster Schritt ist die Operationalisierung und zuletzt die Erstellung und Anwendung der Sicherheitsvorgaben

Problemstelle 3: Erweiterter Grundschutz

Wo bestehende Massnahmen nicht ausreicheoder nicht wirtschaftlich sind, müssen spezielle Sicherheitsvorgaben erarbeitet werden.

Das Sicherheitsmodell ist hier nicht abgebildet – siehe hierzu das registrierungspflichtige Dokument.

Der Schutzbedarf eines Schutzobjekts ergibt sich aus seiner Klassifizierung. Weiteren Einfluss auf die Gewichtung der Klassifizierung können ferner z.B. die Ergebnisse einer Business Impact Analyse haben. Erweiterte Massnahmen können die Grundschutzmassnahmen entweder ergänzen oder aber auch ersetzen.

Problemstelle 4: Kongruenz und Anzahl der Sicherheitsvorgaben

Man kann sich vorstellen, dass, abhängig von der Grösse und dem Umfeld, in dem sich ein Unternehmen bewegt, eine mehr oder wenige grosse Anzahl an Sicherheitsvorgaben notwendig ist. Leider ist es so, dass eine grosse Menge an Sicherheitsvorgaben nicht mit mehr Sicherheit gleichzusetzen ist. Umstände wie ein komplexes und unverständliches Sicherheitsmodell, fehlende Adaptierung, dezentrale Sicherheitsorganisation, fehlende Zuständigkeiten etc. verschärfen diese Problematik noch.

Der Lösungsansatz in diesem Bereich ist vor allem durch Pragmatismus und strukturiertes Vorgehen geprägt. Will heissen:

• Klar formulierte Sicherheitsziele
• Nur so viel Sicherheit wie es die Umstände erfordern (Adaptierung)
• In der Aufbau-Sicherheitsorganisation muss klar definiert sein, wer Sicherheitsvorgaben erstellen darf und welche Umstände neue Vorgaben erfordern

Dieser Ansatz kann auch in dezentralen Sicherheitsorganisationen funktionieren.

Das Sicherheitsmodell ist hier nicht abgebildet – siehe hierzu das registrierungspflichtige Dokument.

Die Sicherheits-Strategie auf der Stufe Konzern definiert die wichtigsten Rahmenbedingungen und Sicherheitsziele für alle Unternehmen. Die zuständige Person ist der Corporate Security Officer (CSO).

In jedem Unternehmen gibt es einen Chief Information Security Officer (CISO), der durch spezialisierte Einheiten wie Risk Management, BCM, Facility und einen Datenschutzbeauftragten unterstützt wird. Jedem CISO stehen zudem Security Officers zur Verfügung.
Die Security Officers (Writer Sicherheitsvorgaben) folgen bei der Erstellung und Verwaltung der Sicherheitsvorgaben definierten Richtlinien.

Problemstelle 5: Sicherheit in Projekten

Besondern problematisch ist die Anwendung der Sicherheitsvorgaben in Projekten. Vor allem in grossen Unternehmen sind umfangreiche Massnahmenkataloge im Umlauf, die den Grundschutzkatalog und erweiterte Kataloge beinhalten. Sie sollen dem Zweck dienen, die notwendigen Sicherheitsanforderungen, die in einem Projekt zu beachten sind, mehr oder weniger automatisch zu generieren und in einer Massnahmenliste darzustellen. Dieser Ansatz ist durch mehrere Schwachpunkte geprägt. Eine Methode, die sich bewährt hat, ist der nachfolgende „Sign-Off“-Prozess:

Das Sicherheitsmodell ist hier nicht abgebildet – siehe hierzu das registrierungspflichtige Dokument.

Während der „First Cut Risk Analyse“ wird das Projekt einer Finanz- und Businessanalyse unterzogen.
Während des Specification Sign-Off werden unter anderem auch die Sicherheitsanforderungen an das Projekt definiert und anschliessend überprüft. Der Projektleiter wird dabei fachtechnisch durch den Security Officer unterstützt und muss daher kein Fachspezialist sein.
Während des Production Sign-Off wird überprüft, ob die Sicherheitsvorgaben während der Umsetzung eingehalten worden sind.

Positive Aspekte des „Sign-Off“ Prozesses sind:

• Projektrisiken werden frühzeitig während der FCRA ermittelt
• Der Projektleiter wird von Anfang an durch einen Fachspezialisten unterstützt
• Die projektspezifischen Sicherheitsanforderungen werden phasen- und kontextgerecht adressiert
• In jeder Phase wird Überprüfung der Auflagen der vorhergegangenen Phase
• Kein Versuch der „automatisierten Sicherheit“

Problemstelle 6: Bildung und Klassifizierung von Schutzobjekten (SO)

Schutzobjekte (SO) werden gebildet, um die Sicherheitsvorgaben auf eine überschaubare Menge von Objekten anwenden zu können. Die Bildung von SO erleichtert zudem Audits und vermindert in effizienter Weise den dafür notwendigen Aufwand. Im Prinzip können technische und prozessgetriebene SO unterschieden werden.

Technische SO sind Systeme, Anwendungen, Applikation, Netze aber auch anderweitige technische Einrichtungen (Facilities). Die Anwendung der Sicherheitsvorgaben erfolgt schlussendlich über die Klassifizierung direkt auf die technischen SO.

In den prozessgetriebenen SO (Businessprozesse) fallen folglich die relevanten Daten und Informationen des Unternehmens an. Die prozessgetriebenen SO steuern die Klassifizierung der technischen SO.

Das Sicherheitsmodell ist hier nicht abgebildet – siehe hierzu das registrierungspflichtige Dokument.

Für technische SO wird vorteilhaft zuerst die IT-Landschaft visualisiert. Die wichtigen Businessprozesse werden zusammen mit Businessfachleuten ermittelt und gruppiert (z.B. nach Produkten, Marktangebot etc.) Die SO können dann z.B. einem Impact Rating unterzogen werden.

Die Klassifizierung der technischen SO wird durch die Klassifizierung der zugehörigen Daten und Informationen beeinflusst, aber auch durch die Ergebnisse der Impact Ratings sowie den Resultaten zusätzlicher Risikoanalysen.

Problemstelle 7: Anwendung von Sicherheitsvorgaben

Informationssicherheit ist von sehr vielen verschiedenen Aspekten geprägt. Dies geht von der Inventarisierung und Klassifizierung zur personellen und organisatorischen Sicherheit, zur physischen Sicherheit, betriebliche Aspekte, Zugriffskontrolle, S&E (Entwicklung und Beschaffung), Incident-, Problem- und Releasemanagement (ITIL), Kontinuitätsplanung und der Sicherstellung gesetzlicher Vorgaben.

Abhängig von der Grösse und dem Umfeld eines Unternehmens sind auch die Anzahl und Komplexität der Schutzobjekte unterschiedlich ausgeprägt. Diese Problemstelle ist weiter von der Kongruenz und Menge der Sicherheitsvorgaben betroffen.

Das Sicherheitsmodell ist hier nicht abgebildet – siehe hierzu das registrierungspflichtige Dokument.

Auf der linken Seite finden sich die verschiedenen Themengebiete (adaptiert), die Informationssicherheit in einem Unternehmen ganzheitlich sicherstellen sollen.

Auf der rechten oberen Seite sind die Schutzobjekte (SO) aufgelistet. Die SO werden nun, wenn immer möglich, mit horizontal gelagerten, übergeordneten Richtlinien (Sicherheitsvorgaben) konfrontiert. Übergeordneten Richtlinien sind allgemein gültig formulierte Sicherheitsvorgaben, die keinen SO spezifischen Charakter haben. Die übergeordnete Richtlinie beinhaltet aber trotzdem alle wichtigen Aspekte für den Bereich.

Übergeordnete Richtlinien haben die folgenden Vorteile:

• Beinhalten alle wichtigen Aspekte trotz allgemein gültiger Formulierung
• Starke Reduzierung (Anzahl) der benötigen Sicherheitsvorgaben
• Dadurch auch einfachere Sicherstellung der Kongruenz der Sicherheitsvorgaben

Konklusion

Viele Sicherheitsvorgaben und ein komplexes Sicherheitsmodell sind nicht gleichbedeutend mit mehr Sicherheit – oftmals wird genau das Gegenteil erreicht. Es lohnt sich auf jeden Fall für jedes Unternehmen, sich genau zu überlegen, wie viel Sicherheit denn eigentlich das eigene Umfeld erfordert. Ein guter Ansatz ist meist, Informationssicherheit zwar in allen Aspekten, aber pragmatisch und den eigenen Bedürfnissen entsprechend zu betreiben. Dies kann auch in mehreren Schritten erfolgen. Ein gutes Sicherheitsmodell lässt sich jederzeit ausbauen und neuen Erfordernissen anpassen. Somit erfolgen auch Investitionen in die Informationssicherheit in effizienter und effektiver Weise.

Merksätze

• Den eigenen Bedürfnissen entsprechend adaptieren (weniger ist mehr)
• Pragmatismus und gesunder Menschenverstand walten lassen
• Systematisch vorgehen
• Reale Bedrohungen ermitteln und Risiken einschätzen

Begriffserklärungen

Sicherheitsmodell

Wesentliche Bestandteile sind der Sicherheitsprozess und das Sicherheits-Framework.

Sicherheits-Framework

Es definiert die verschiedenen Ebenen zum Thema Sicherheit. Die erste Ebene beantwortet das „Warum“, die zweite Ebene das „Was“ und die dritte Ebene das „Wie“ zur Informationssicherheit. Das Informationssicherheits-Framework umfasst die Gesamtheit der Dokumente zur Informationssicherheit.

Sicherheitsprozess

Institutionalisiert das Sicherheits-Framework. Das Sicherheits-Framework gibt den Inhalt und die Ziele für den Sicherheitsprozess vor, der Sicherheitsprozess bereichert das Framework um die ablaufbezogene Komponente.

Sicherheitsdispositiv

Es definiert die Grenzen, innerhalb dessen ein Unternehmen Informationssicherheit in sämtlichen Aspekten durch Anwendung eines Sicherheitsmodells betreibt.

ISMS

Das Information Security Management System dient als Steuerungssystem, mittels dessen Hilfe sich eine konsistente Informationssicherheits-Politik und eine schlagkräftige Informationssicherheitsorganisation aufbauen lassen. Mit Hilfe des ISMS wird das starre Informationssicherheits-Framework institutionalisiert.