Die häufigsten Fehler bei einer ISMS Einführung

• bereits anderen in der Organisation bzw. zumindest auf dem Organisationsdiagramm etablierten Managementsystemen, inklusive deren Controls-Sets,

• generell gewachsenen, nicht immer optimal geplanter IT- und/oder Organisationsstrukturen, inklusive ggfs. ungeeigneter Berichtwege und/oder verteilte Aufgabenbereiche müssen wir uns in der Regel auch mit

weiteren - in der Regel nicht einfach korrigierbaren Gegebenheiten – arrangieren.

Die hier nur beispielhaft als Vertreter - für viele weitere (in der Praxis öfters anzutreffenden) Herausforderungen - gelisteten Aspekte, zeigen auf, dass die unreflektierte Verwendung von „ISMS Musterlösungen“ selten zu allseits zufriedenen Stakeholdern führt, sondern dass immer – wie in der Norm sinnvollerweise auch gefordert – eine Umfeld- und Stakeholder-Analyse als (direkt nach dem Kaffee kochen) zweites Handlungsfeld bearbeitet werden muss.

Die Ergebnisse dieser Phase stellen eine zentrale Basis für die weitere Planung und somit ein Fundament des ISMS dar und sind kriegsentscheidend für die spätere Akzeptanz des Systems und seiner Prozesse in der Organisation.

In diesem bzw. dem nachfolgenden Abschnitt sollen einige in den Unternehmen oft wiederkehrenden Herausforderungen, samt einiger eventuell dann sinnvoller Reaktionen, andiskutiert werden, wohlwissen, dass es – eine fits4all-Lösung maximal zufällig geben wird.

Der Abschnitt adressiert hierbei aber explizit nicht nur neu einzuführende Managementsysteme, sondern soll auch als Denkansatz für eventuelle Verbesserungspotentiale etablierter Systeme dienen, denn auf Grund der in den letzten Jahren immens gestiegenen Cyber Security Bedrohungen sowie auf Grund der – gefühlt exponentiell wachsenden Compliance-Anforderungen, insbesondere bei international tätigen Organisationen, müssen sich auch bereits etablierte Systeme hinterfragen, ob die derzeitig vorgesehenen Regelungen / Prozesse noch zeitgemäß sind, um nicht nur effektiv, sondern auch effizient den wachsenden Aufgaben gerecht zu werden.

Anfragen wie, bitte prüfe

• die Relevanz des „Chinese Cyber Security Laws“ sowie

• den Patchlevel des neuerdings (zur einfacheren Ablese) mit dem CN vernetzten - im Rahmer der Produktion zur Steuerung eingesetzten Windows XP Rechners, bitte bis 11 Uhr indische Winterzeit, da die Kollegen aus Indien Rückmeldung benötigen, ob die rdp-Freigabe des Rechners wirklich zusätzlich mittels MFA abgesichert werden muss oder ob nicht die Berücksichtigung des OT Standards xyz ausreichend ist,

sind mittlerweile in ISMS-Abteilungen an der Tagesordnung.

Während der letztgenannte Aspekt eher spaßig auf die dennoch ernste und auch zunehmende Bedrohung, welche durch die zunehmende netzwerktechnische Anbindung von oft initial nicht dafür vorgesehenen Komponenten - insbesondere im medizinischen und produzierenden Bereich - anspielt, deutet Aspekt 2 ebenfalls auf eine zentrale neu hinzukommenden Herausforderung hin, nämlich den „Need“ zeitnah zu immer mehr Compliance-Anforderungen Stellung nehmen können zu müssen, die – was man aber leider in der Regel erst nach einer Prüfung des Sachverhalts weiß – im Wesentlichen oft dieselben Dinge wollen, als die uns eher geläufigen Standards auch, aber leider dazu nicht selten komplett andere Methoden, Scope-Verständnisse oder Vorkabeln einsetzen, zu Deutsch „Raiders heißt jetzt Twix“.

Als logische Konsequenz wachsen – sozusagen als Bugwelle der Compliance-Anforderungslisten – auch die Mapping Tabellen, in denen wie wild die jeweiligen Controls, Benchmarks etc. miteinander in Bezug gesetzt werden, um so bereits bewertete Umsetzungsstatus auch in anderen Kontexten nutzen zu können.

Der Need war/ ist so groß, dass aus diesen XLS-Listen mittlerweile ein nicht nur ernstzunehmender Software-Markt entstanden ist, sondern auch in vielen Unternehmen der Trend zur Überdenkung der „Corporate Control Strategie“ inklusive Anpassung der Organisationsstrukturen erkennbar ist.

Ein wesentlicher Treiber ist hierbei sicherlich auch schlichtweg der Fakt, dass manch ISMS „Elfenbeinturm“ - im Kontext dieser Entwicklung - gelernt hat, dass es nicht nur auf der Welt mannigfaltig Control- und Maßnahmenlisten zu entdecken gibt, sondern auch in der eigenen Organisation und dass man derzeit den „Willi aus dem Facility Management“ halbjährlich von vier Abteilungen zu nahezu den gleichen Fragestellungen kontaktiert. Was Willi schon lange wissen wollte, fragen nun folglich auch zunehmend die Controller, alles ehemalige Berater, die es wissen müssen, und so kommt immer mehr Bewegung in die Idee der Controller.

Im Folgenden Abschnitt findet sich eine Beschreibung der wesentlichen Herausforderung die CISOs und/oder deren Berater im Rahmen von ISMS Projekten antrafen sowie die derzeit in der Praxis diesbezüglich oft gewählten Lösungs-Strategien.

Herausforderungen im Rahmen von ISMS Einführungen in gewachsenen Umgebungen

Getreu dem Motto, es gibt’s nichts, was es nicht gibt, haben wir CISOs nach den ihres Erachtens größten Herausforderungen im Rahmen der ISMS Einführung gefragt. Neben einigen Klassikern, wie z. B. lfd. Nr. 1 „Falsche organisatorische Einbindung“, wurden im Folgenden auch einige neue Punkte genannt, wobei hierbei derzeit insbesondere der lfd. Punkt 2 die ISMS Abteilungen zu beschäftigen scheint. Aber der Reihe nach …

Spitzenreiter auf der Liste der „ISMS Hausauforderungen“ ist – wie bereits erwähnt - immer noch der Klassiker:

1. Falsche organisatorische Eingliederung des ISMS auf Grund eins falschen Verständnisses innerhalb der Organisation, speziell wurde wiederholt genannt:

• ISMS wird nicht als Governance, sondern als IT-Thema angesehen.

• Nicht sinnvolle Berichtswege, z. B. Report an CIO und nicht an oberste Leitungsebene.

• Fehlende Richtlinien-Kompetenz seitens CISO/ISB.

• Management Support nur auf dem Papier und weniger durch konkrete Maßnahmen.

Ebenfalls oft erwähnt wurde eine starke organisatorische Verteilung von thematisch zusammengehörenden Themen sowie dadurch teilweise sich ergänzende, Willi würde sagen, „überlappende“ Verantwortungsgebiete, wie z. B. – sofern nicht sauber definiert - im Kontext Geheimschutz, Geheimnisschutz, CISO, Cyber Security Officer, Corporate Security, OT, Safety, RISK, SAP FRAUD („DO-lose Handlungen“), HR etc. denkbar.

2. An zweiter Stelle findet sich die in der Einleitung bereits angedeutete Tatsache, dass in vielen Organisationen, viele Control- und Maßnahmenlisten parallel gepflegt werden, allerdings ohne gemeinsam verwendete Metaebene, so dass die Nutzung von Synergieeffekten - trotz Annex SL offensichtlich auch im Jahre 2022 eher die Ausnahme bleibt. Dies führt unweigerlich zu einem erhöhtem Ressourcenbedarf sowohl in den ISMS Abteilungen als auch in den operativen Abteilungen, z. B. auf Grund zunehmender Compliance-Anfragen und daraus resultierender Prüfungen von Standards / Best Practice (GAP-Analysen), z. B. in Form von GAP-Analysen für Controls, die innerhalb der Organisation – an anderer Stelle - eigentlich schon beantwortet aber eben auf Grund der fehlenden zentralen Control- Datenbank – nicht – im Sinne eines integrierten Ansatzes - zentral verwendet werden.

Damit einhergehend wurde des Öfteren lfd. Nr. 3., nämlich die fehlende einheitliche Ansprache des Business durch die Managementsystem-Verantwortlichen (2LoD), als noch zu lösende Herausforderung, genannt.

3. Fehlende einheitliche Ansprache der Business-Verantwortlichen (Prozess Owner) durch die Managementsystem-Verantwortlichen (2LoD).

Bei den Punkten 4 und 5 handelt es sich wieder um einen Klassiker, wohin gehend Punkt 6, also wie verankert man nachhaltig Governance-Vorgaben in die Organisationsprozesse – in dieser Form zwar sicherlich nicht neu ist - , aber dennoch immer noch ein aktuelles Thema in den ISMS Abteilungen zu sein scheint.

4. Unzureichendes Alignment des unternehmensweiten Asset-Management (insbesondere Primary Assets, also Prozesse) mit dem IT oder OT-Asset Verzeichnis dere Organisation sowie fehlende Verpflichtung der Prozess Owner (durch das Top Management) auf Informationssicherheits-Ziele im von ihnen zu verantwortenden Prozess

5. Unzureichender Blick in die Organisation und fehlende systematisch sichergestellte Absicherung der Prozesse, z. B.

1. in Form einer IT-Security Actions Baseline (ITSAB) entlang der Wertschöpfungskette, oder anlog dazu

2. OTSAB, womit wir beim nächsten zentralen Punkt wären:

6. Fehlende Verankerung der Governance-Vorgaben im Prozess- und Qualitätsmodell (PROMO und QUAMO) sowie generell unzureichende Messung von Vorgaben (Kennzahlen).

Das in der nachfolgenden lfd. Nr. 7 bemängelte Fehlen eines OT Security Konzepts scheint ebenfalls noch eine weit verbreitete Herausforderung zu sein, insbesondere die oft leichtfertige Anbindung entsprechender Komponenten ohne vorherige Klärung der Verantwortlichkeiten, allem voran der Wartung.

7. Fehlendes OT Security Konzept

8. Unzureichende IT-Lösungen auf Grund von Risiko-Fragmentierung

Unter dem Begriff „Risiko-Fragmentierung“ wird die unzureichende Priorisierung von IT-Risiken auf Grund fehlerhafter Bewertung verstanden. In nicht wenigen Organisationen werden Risiken immer noch nach Organisation-Einheiten gemeldet und bewertet und es fehlt eine konsolidierte Sicht bzw. Bewertung bezogen auf den Impact auf das Business, also konkret die Prozesse der Wertschöpfungskette. Dies führt nicht selten dazu, dass z. B. Cyber Security Bedrohungen nicht die Einstufung haben, welche sie eigentlich haben sollten und der dann falschen Priorisierung folgenden, in den IT-Abteilungen die Budgets fehlen, um angemessene IT-Lösungen, die zum Erkennen professioneller Cyber Security Angriffe unabdingbar sind, zu beschaffen. (No risk, no budget).

Hinweis: Einige der CISOs gehen mittlerweile sogar davon aus, dass ihr CN bereits durch professionelle Angreifer, ggfs. zwecks Wirtschaftsspionage, unterwandert ist, sie dies aber derzeit – auf Grund fehlender technischen Möglichkeiten - nicht nachweisen können, letztendlich wegen der fehlenden Risk-Awareness in der Leitungsebene, eventuell als Folge der beschrieben Risiko Fragmentierung.