In meinen nahezu 30 Jahren der Beratung von Unternehmen im IT-Sicherheitsbereich stelle ich häufig fest:
- Projekte kommen zu spät auf die Agenda (meist drohen schon Strafen der Aufsicht und Fristen sind gesetzt)
- Man kennt das grobe Ziel des Projektes, aber berücksichtigt viele Nebenschauplätze nicht adäquat oder gar nicht
- Eine konkrete Projektvorbereitung ist zu ungenau im Bezug auf Ressourcen
- Etappenziele werden meist überlagert und vom Endziel verdrängt
- Es herrscht Druck, und Feuerlöschen anstatt Projektplanung ist an der Tagesordnung
Einer Organisation, die sich mit dem Thema Funktionstrennung beschäftigt sei geraten das Thema nicht auf die leichte Schulter zu nehmen. Es ist keine kleine Änderung eines Rollen- und Berechtigungskozeptes und eine Einführung von einem Vier-Augen-Prinzip. Vielen denken, dass Segregation of Duties doch nur das Prinzip der Funktionstrennung ist. Es ist nur ein Geschäftsprozess innerhalb einer Organisation. Es besteht nur aus ein paar Richtlinien, die meist in ein Softwareprodukt geladen werden und von diesem überwacht werden. Das Vier-Augenprinzip hat fast jedes Unternehmen ohnehin schon eingeführt. Ein Zugriffsbestellsystem hat auch fast jedes Unternehmen. Wo ist das Problem?
Weit gefehlt. Das Problem ist, dass man sich vor dem Projekt Gedanken machen muss, was das Projekt alles affektiert. Falls Sie folgendes im Scope haben, dann gehören Sie zu den 2% meiner Kunden.
- Ziele von SoD
- Geltungsbereiche
- Informieren der Organisation über das Projekt und die Ziele und was sie erwartet (Intranet, Handout)
- Richtlinien und Guidelines (Personal, ITSec, Audit, Compliance)
- SoD-Verantwortlichkeit, und die Rollen von ITSec, Revision, Compliance, externen Prüfungsgesellschaften und Aufsicht
- Erstellung einer SoD-Matrix (Einbezug aller Organisationseinheiten und Doku der Matrix)
- Namenskonventionen (bei IAM, Prozessen, Berechtigungskonzepten und Entitlements!)
- Organisationsstrukturen (vollwertige HR-Systeme)
- Bestellsystem(e)
- Risikomanagement und risikobasierter Ansatz für SoD (Nach BaFin)
- Systeme, Strategien und Technologien zur Unterstützung von Berechtigungsmanagement
- Einbindung klassischer Berechtigungstechnologien (Omada, IIQ, One IM…)
- Einbindung moderner Cloud Berechtigungstechnologien (Okta, MS365, Zimbra, SecureAuth, Ping Identity, Azure, Teamwork….)
- Harmonisierung und Einbindung von Technologien auf verschiedenen Plattformen
- Festlegung der Business und IT-Application Rollen
- Readiness der Berechtigungskonzepte (World Rights, Businessfunktion, IT-Funktion
- Zuordnung der Rollen und Entitlements der SoD-Matrix
- Prozesse (Standard Prozesse der Organisation und eigenen Kontrollprozesse)
- Prozessanalysen
- Onboardinganalysen mittels Vorabsimulation und Onboardingplanung
- Aktivierung von SoD-Regeln im SoD-Tool
- Korrekturen von Berechtigungssystemen nach der Aktivierung von SoD-Regeln
- Parametrisierbarkeit von Entitlements für Entwickler, die übergreifend über mehrere Organisationseinheiten entwickeln
- System- und Architekturschnittstellenaufbau und -anbindung
- Zielidentitäten (Businessrolle, IT-Rolle, Technischer User, Started Task, etc.)
- Workflows und Workflow-Synchronisation über die affektierten Plattformen hinweg
- Rollenmanagement
- Simulation von SoD
- Einbindung von vorhandenem Privileged Access Management oder Neuplanung PAM
- Die Unterpunkte von PAM alleine sind ein eigenes Projekt
- SoD-Konfliktmanagement (Max. Konflikte bei Aktivierung, Strategie zur Eliminierung von Konflikten, Berichte…)
- Governance
- Compliance
- Berichte
- Dokumentation
- Metatasks wie Schulungen, Verantwortung, Monitoring, Audits
- Simulation von SoD
- etc…
Die oben dargestellten Punkte sind nur der Grobschnitt eines SoD-Projektes. Hinter fast jedem Punkt verbirgt sich ein Haufen Arbeit, Vorbereitung, Änderung, Harmonisierung und neue Gewerke, die sich leider quer durch die gesamte Organisation ziehen. Die meisten Projekte schaffen es nicht, alleine die Liste der obigen Punkte zu berücksichtigen. Damit wäre man schon gut unterwegs. Leider läuft es meist anders.
Organisationseinheiten streiten sich über Kompetenzen und Aufgaben. Know-How zum Thema ist sehr unterschiedlich verfügbar. Systeme, die vorher von Abteilungen gekauft wurden, die nicht zu den Kontrollorganen gehören, werden als Kontrollsysteme per SoD-Matrix deklariert, und in einer Abteilung können über Nacht hunderte bis tausende von Konflikten entstehen. Bei welcher Konfliktanzahl hört man auf zu Aktivieren und gibt der Organisation eine Atempause?
Berechtigungskonzepte werden nicht auf das Projekt getrimmt. Meist überlässt man die Sachen den Fach- und Technikverantwortlichen des Bereiches ohne Kontrolle. Manche Projekte ordnen Rollen der SoD-Matrix zu aber nicht die Entitlements. Andere wiederum bauen Entitlement für Rollen und für Infrastrukturkomponenten. So gab es gleich große Kunden, die 200.000 Entitlements verwendeten und welche, die 1.2 Mio Entitlements verwendeten. Diese BulK-Loads muss man behandeln können (Vorabscheck, Syntax, Logik, Integrität, Zuordnung, Simulation, Konfliktauflösung). Meist sind die Projekte aber nicht derart mit Personal versehen, dass das mühelos möglich ist, und so verlässt sich der eine auf die andere, und damit kann das Kind schon einmal schnell in den Brunnen fallen.
Quelle: Microfocus: Novell
User aller Level bis zum Vorstand sind meist nicht genügend informiert. Bei einer Aktivierung von SoD-Regeln und dem Konfliktmanagement kommen die ersten Beschwerden nach dem Motto „was soll ich damit?“.
Eine Dokumentation ist meist nicht ausreichend um später den Übergang vom Projekt in das Business as Usual weich zu gestalten. Meist kommen die ersten Audits intern und extern, schreiben böse Berichte, so dass die Geschäftsleitung denkt: „was haben sie denn all die Zeit gemacht?“. Auch das liegt meist am Personal im Projekt, da man denkt, Doku sei ja nicht wichtig.
Sehr oft fehlt Anfangs auch das Gefühl, wie lange toxische oder tolerierbarer, rote oder gelbe, kritische oder nicht kritische Konflikte leben dürfen. Die Range variiert im Projekt für das Konfliktmanagement von einer Woche bis zu 6 Monaten, Aufsichtsbehörden fordern im Business as Usual meist 24h bis 14 Tage. Von einer Woche auf einen Tag und von 6 Monaten auf 14 Tage erfordert der Organisation extrem viel ab. Es werden meist Übergangsphasen vergessen, in denen man die Organisation adaptieren lässt an strengere Regeln.
Das sind nur einige Faux-pas, die im SoD Projekt Ärger machen.
Eine gute Planung ist das A und O eines SoD-Projektes. Und auch wenn man zu spät ist, kann man schon vorab mit den Aufsichtsbehörden sprechen um nicht unnötig die Organisation und das gesamte Projekt unter Druck zu halten, da unter diesem Druck das meiste abgekürzt und nicht richtig durchgeführt ist.
Wir haben viel Erfahrung mit SoD-Projekten und können der Geschäftsleitung bei Verzug schon gute Tipps geben und Beratend zur Seite stehen, wie man und was man mit der Aufsicht besprechen kann bei Verzug, wir haben bei der Aufsicht einen guten Ruf und gute Beziehungen. Natürlich können wir mit unseren Partnern auch ihr komplettes SoD-Projekt erfolgreich umsetzen, wie wir das schon oft erfüllt haben.
