integriertes Kontrollsystem (iIKS)

Einsatz einer zentral gepflegten „Corporate Control Datenbank“

Neben der Verankerung der Governance-Vorgaben in die Abläufe der Organisation stellt die Einführung einer zentral gepflegten „Corporate Control Datenbank“ ein weiteres wesentliches Handlungsfeld – im Sinne einer stetigen Verbesserung der Managementsysteme dar.

In den meisten Organisationen haben die verantwortlichen Manager eines Managementsystems derzeit noch ihre eigenen Kontroll-Sets definiert, was dazu führt, dass viele Steuerungsmaßnahmen, z. B. sichere Entsorgung von Informationen, doppelt, wenn nicht drei- oder vierfach – an verschiedenen Stellen in der Organisation gepflegt werden, inklusive aller Folgemaßnahmen, wie z. B. Erhebung Umsetzungsstatus, Auditierung, Prüfung Wirksamkeit etc.

Dies führt unweigerlich zu einem Mehraufwand und insbesondere beim fachlich für das Thema Verantwortlichen zu einem Unverständnis, da er quasi dieselben Fragestellungen von oft bis zu vier Stellen gestellt bekommt.

Durch die harmonisierte Struktur aller Managementsysteme (nach Anhang SL) wurden viele Managementsystem-Normen vereinheitlicht. Prominente Beispiele sind die ISO/IEC 27001, die ISO / IEC 9000, die ISO 22301, aber auch weitere Managementsysteme, wie z. B. Arbeitsschutz, Umweltschutz etc. folgen mittlerweile der neuen Struktur, weshalb es Zeit ist, den seitens der Normen zugespielten Ball anzunehmen und – in Form eines GELEBTEN integrierten Managementsystems - ins Ziel zu bringen.

Während im Beispiel „Datenschutztonnen“ nämlich maximal das Facility Management aufgrund der ständigen Nachfragen ("rechte Hand weiß nicht, was die linke macht") genervt ist, besteht allgemein die Bedrohung, dass es im Asset-Verzeichnis zu unterschiedlichen Auswertungen und damit zu Inkonsistenzen kommt.

Ziel der angepassten Vorgehensweise ist deshalb die Verwendung von CLUSTERN/TOPICS oder in manchen Fällen auch FOCUS AREAS genannt, um die Steuerungsmaßnahmen nicht mehr an Normen, sondern nach Themen auszurichten.

Die Normen werden dann unter eine Metaebene gepflegt (verlinkt), was den Vorteil bringt, dass man auf Grund des dann für - die gesamte Organisation konsolidiert vorliegenden - Kontroll-Sets per Knopfdruck die Antworten zu anderen – vorher nicht betrachteten "Standards/Gesetzen/BestPractices" – liefern kann, selbst wenn man sich vorher nie mit der neuen Compliance-Anforderung auseinandergesetzt hat.

Als Grundlage nutzen entsprechende Tools– ähnlich wie beim Virenschutz – ein Pattern, die die Informationen zu Verlinkungen der verschiedenen Quellanforderungen liefern und somit z. B. auch eine Aktualisierung, wenn es mal wieder irgendwo ein neues Gesetz oder Anforderung zu bewerten gibt.

Beispielhaft sei das derzeit viel diskutierte Chinese Cyber Law genannt.

Ausrichtung der „Central Corporate Controls“ an Sicherheitsdomänen

In der Praxis hat es sich als sinnvoll erwiesen, die in der Organisation zu steuernden Aspekten in Clustern, oft auch Domänen genannt, zu gruppieren.

Die Nutzung des freien SCF ist dabei eine gute Idee, wobei zunächst auch nur die Verwendung der dort verwendeten Domains und nicht zwingend alle 750 Kontrollen des Standards verwendet werden müssen.
Auch wäre z. B. der Einsatz von COBIT denkbar.

Die Wahl der Control-Frameworks ist hierbei allerdings zweitrangig und sollte von der Organisation für ihre Zwecke, die letztendlich auch durch externe Vorgaben oder des Geschäftsmodells variieren können, angemessen gewählt werden.

Bei einem SaaS-Anbietet bietet sich z. B. eher die CCM der CSA an, wobei im behördlichen Umfeld eventuell das BSI Kompendium dienlich sein könnte.

Wie auch immer sich die Organisation entscheidet, mittels entsprechender Software-Unterstützung oder manuellem Fleiß kann der letztendlich gewählte Standard über eine Metaebene gepflegt werden, so dass letztendlich viele weitere Standards – zu großen Teilen – ausgewertet werden können, wobei – wie gesagt – jeder Standard seinen Fokus leicht anders setzt, weshalb nicht zwingend für jedes Control eines verlinkten Standards direkt ein Umsetzungsstatus ableitbar ist. Die Qualität der Datenbank wächst aber zunehmend, und zwar mit jeder neuen Bewertung eines Standards bzw. einer Norm.

Anpassung der Organisationsstruktur

Optimalerweise erfolgt vor der Umstrukturierung der Controls nach TOPICS auch eine entsprechende Anpassung der Zuständigkeiten. So sollten die Controls, welche das WAN/LAN betreffen z. B. durch ein Netzwerkteam verwaltet werden. Dies wird sich aber nicht immer 1:1 über die vorhandene Organisationsstruktur abbilden lassen, da in vielen Organisation die Zuständigkeiten oft über verschiedene Bereiche verteilt sind. Sehr deutlich wird das Beispiel IAM. Hier wird für die Steuerung des Themas – wenn man es richtig machen will - HR gebraucht, weshalb z. B. die IT-Abteilung das TOPIC IAM nicht alleine verantworten sollte. Da HR allerdings ebenfalls die IT-Abteilung zur Umsetzung benötigt, geht hier die Tendenz dazu – in Form einer Matrixorganisation - RESORTS auf Basis von ORG-EINHEITEN zu bilden, die dann über diese virtuelle Organisation gemeinsam für das Thema verantwortlich sind. Im Falle IAM wäre das Resort dann also bestückt aus Personen des Bereichs HR und IT.

Hinweis: Ein Thema liegt immer genau bei einem "RESORT", wobei ein "RESORT" aber durchaus mehrere Themen (TOPICS) zugeordnet haben kann.

Neben dem RESORT ITENDITY gibt es einige weitere Themen, bei denen die Notwendigkeit von ORG-übergreifenden RESORTS deutlich wird. Denken wir z. B. im Themenbereich SAP an "dolose-Handlungen", also Wirtschaftsbetrug auf Grund fehlender prozessintegrierter Kontrollen oder eines schwaches SAP Security Konzepts. Hier bietet sich z. B. ein Resort FRAUD an, welche neben den Einheiten FINACE & SAP-Security auch noch den ISB beinhalten sollte.

Wie oben bereits vorgschlagen bietet sich für alle Themen rund um WAN/LAN & Netzwerksicherheit ein RESORT CNSEC (= Corporate network security) an. Wenn der ISMS Verantwortliche nun Anforderungen hinsichtlich Netzwerk-Security-Maßnahmen hat, dann muss er diese künftig an das Resort CNSEC kommunizieren, welches als verantwortliches Referat dann ein Stakeholder-Management abbilden muss, inklusive Auflösung eventuell sich widersprechender Anforderungen, so dass diese nicht mehr – wie derzeit oft der Fall – über unterschiedliche – vom jeweiligen System-Verantwortlichen – über eine Richtlinie in seinem Bereich – publizierten Regelungen beim „Endkunden“, also i.d.R. dem Business, aufschlagen.
Das RESORT CNSEC hat – um in diesem Beispiel zu bleiben - dann also die Hoheit über die Steuerungsmaßnahmen (Controls) in diesem Bereich, muss aber - nach Möglichkeit - die Anforderungen der Stakeholder [control objectives] (in diesem Fall mindestens der RESORTS ISMS, DSMS etc.) umsetzen.

Falls eine Umsetzung von Anforderungen oder eine Auflösung von Konflikten, z. B. auf Grund widersprüchlicher Anforderungen, nicht möglich ist, dann muss der Sachverhalt über das RESORT RISK bewertet werden. Das RESORT RISK trifft dann risikobasiert eine Entscheidung, auf Grundlage der Bewerung welcher "Need" für die gesamte Organisation als wichtiger zu beachten ist.

MEHR (z. B. Richtlinien für ihre Organisation, Tool-Unterstützung etc.) GERNE AUF ANFRAGE!!