Hallo zusammen, herzlich willkommen bei unserem Webinar mit dem Titel IGA als Herzstück eines jeden Security-Transformations-Programms. Heute mit mir hier im Webinar Klaus Hild, Principal Identity Strategist von SailPoint.
Hi Klaus, schön, dass du hier bist. Hallo, grüß dich Phillip, danke, dabei sein zu dürfen.
Schön, dich hier zu haben. Und Moritz Anders, Partner Digital Identity Cyber Security Privacy von PwC. Hallo Moritz. Hallo Jello, und ich freue mich natürlich auch dabei zu sein.
Schön, dass du hier bist. Mein Name ist Dr. Phillip Messerschmidt, ich bin Lead Advisor für KuppingerCole. Schauen wir uns die Agenda für heute an. Wir haben vier Punkte auf der Agenda, eine kurze Einleitung, die wir schon gemacht haben und ein kurzes Set the Scenes. Dann werden wir zwei inhaltliche Blöcke haben, wo ich starte mit Identity and Authorization as Drivers for Future Automation. Und dann übernehmen Moritz und Klaus mit dem Thema How PwC Drives Digital Transformation with SailPoint.
Abschließend werden wir noch eine kurze Session Questions and Answers haben, wo wir auch die Polls zeigen. Dann kommen wir zum Housekeeping, und zwar werden wir das Audio zentral steuern.
Sprich, Sie werden stumm geschaltet, Sie müssen sich nicht selber aktiv stumm oder laut schalten, das wird von uns gesteuert. Zweiter Punkt, Umfragen. Wir haben in unser Webinar drei Umfragen eingebaut. Das heißt, da werden hin und wieder mal Fragen an Sie gestellt, die Sie bitte beantworten dürfen. Und die Ergebnisse werden wir am Ende in der Q&A Session mit Ihnen teilen und auch andiskutieren. Fragen und Antworten. Falls Fragen aufkommen sollten, haben wir im Bereich Q&A, im Control Panel, haben Sie die Möglichkeit, Ihre Fragen einzutragen.
Die Fragen werden an uns weitergegeben, und wir werden sie im Q&A am Ende des Webinars diskutieren, solange wir genügend Zeit dafür haben. Last but not least, Aufnahmen und Folien. Wie immer nehmen wir die Webinare auf, stellen sie auf unserer Website zur Verfügung, genauso wie die Folien. Und Sie können in den kommenden Tagen damit rechnen, dass die Folien und die Aufzeichnungen hochgeladen werden. Dann kommen wir zum ersten inhaltlichen Punkt, dem Vortrag Identity and Authorization as Drivers for Future Automation.
Und dann steige ich auch gleich ein mit den Trends, mit den IAM-Trends der IEC 2024. Die IEC ist unsere große IAM-Konferenz, die einmal jährlich stattfindet, dieses Jahr im Juni in Berlin. Und als Abschluss-Keynote fasst Martin Kuppinger die wesentlichen IAM-Trends der Konferenz zusammen. In diesem Jahr haben wir sieben Trends identifiziert, nämlich die Verifiable Credential Wallets and Decentralized Identity. Wir haben als zweiten Punkt den Einfluss von AI auf IAM und Cyber Security gehört.
Der dritte Punkt war Regulatory Pressure, sprich die neuen aufkommenden regulatorischen Vorgaben und wie sie auf Unternehmen wirken, sprich DORA und NIST sind die beiden aktuellsten. AI und Data Protection gehören natürlich aber auch dazu, genauso wie die anderen üblichen Verdächtigen. Dann ein wichtiger Punkt, ein wichtiger Trend für mich, PWAG, AuthZend und der Dynamic Access. Auch da sehen wir einen wesentlichen Trend in den nächsten Jahren.
Trend Nummer 5 auf der Slide, ITDR Fraud Detection, Trend 6, B2B IAM, das sind Themen, die wir zwar schon länger auf der Liste haben, genauso wie Fundamental Enterprise IAM Challenges. Das sind so unsere Sauerbrenner, die an der Stelle immer mal wieder auftauchen und immer noch Herausforderungen darstellen, die nicht vollständig gelöst sind. Besonders interessant für heute für das Webinar finde ich persönlich die Verifiable Credentials, aber auch die Dynamisierung des Accesses an der Stelle, wo PWAG, ABAG für uns relativ wichtig sind in der Automatisierung für die Security Posture.
Und damit kommen wir auch schon zur ersten Poll. Und zwar möchte ich gerne wissen, an der Stelle, was Ihre Meinung ist. Was ist für Sie der wichtigste Trend? Was sind die wichtigsten Trends, die Sie von diesen sieben jetzt in diesem Fall auf dem Schirm haben? Wir haben die Poll geöffnet. Wir geben Ihnen einige Sekunden Zeit und dann würden wir uns freuen, wenn wir am Ende möglichst viele Teilnehmer haben, um dann auf der Basis diskutieren zu können.
Gut, dann würde ich schon mal weitermachen mit der nächsten Folie. Sie haben natürlich noch weiter die Möglichkeit, auf die Poll zu antworten. Treiber für IAM. Das Thema heute soll ja IGA sein und IGA wird in der Regel von drei wesentlichen Treibern getrieben, muss man ja so schön sagen. Und zwar Effizienz, Risiko und Regulations.
Alle drei Aspekte helfen uns, Maßnahmen im IAM-Umfeld zu positionieren und die Vorteile dieser Maßnahmen können in der Regel anhand dieser drei Dimensionen gemessen werden, beziehungsweise die Projekte, die etabliert werden, werden in der Regel aus einer dieser drei Perspektiven beleuchtet. Also entweder Effizienzsteigerung, operative Maßnahmen, die uns schneller, besser, günstiger machen, Risiken, die unsere Gesamtsituation aus der Security-Sicht heraus verbessern oder Regulations, sodass die Maßnahmen uns helfen, die regulatorischen Anforderungen besser zu erfüllen.
Vielleicht mal ein Beispiel, damit man sich das Ganze besser vorstellen kann, wenn wir zum Beispiel über die Rezertifizierung nachdenken, aus Sicht von Effizienz, dann könnten wir die Rezertifizierungsmaßnahmen durch ein technisches Tool zum Beispiel unterstützen, um das Ganze schneller durchzuführen oder den Application-Ownern oder den Role-Ownern die Möglichkeit zu bieten, das Ganze zentral zu machen und nicht pro Applikation.
Wenn wir uns Rezertifizierung aus dem Risiko-Gesichtspunkt angucken, dann schauen wir eher aus der Brille Least Privilege Enforcement darauf, sprich wir wollen die Attack Surface reduzieren, die im Endeffekt verwaiste Rechte oder Rechte, die nicht genutzt werden, bieten. So ähnlich sieht auch die Perspektive der Regulations aus. Dort ist im Endeffekt auch das Least Privilege Enforcement so ein bisschen der Schlüsselpunkt. Da wird auch gefordert, dass Rezertification in Place ist und aber auch das Least Privilege an sich durchgeführt oder beziehungsweise durchgesetzt wird.
Sprich, was wir mitnehmen können ist, egal welche Aktivität wir im IGA-Umfeld durchführen, anhand dieser Main Drivers können wir die Vorteile messen, aber wir können auch eine gewisse Perspektive einnehmen auf die jeweiligen Maßnahmen. Und auch hier setzen wir gleich mit einer Umfrage wieder ein und zwar der Poll Nummer zwei. Was ist für Sie in Ihrer Organisation der wichtigste Treiber für IGA? Es ist die Effizienzsteigerung, also die Operational Efficiency.
Sind es vielleicht die Risiken, das heißt die Risikomitigation, die die Maßnahmen von IGA mitbringen oder führen Sie IGA-Maßnahmen primär durch, um regulatorisch konform zu sein? Das würde mich interessieren, insbesondere vor dem Hintergrund, dass wir eine vergleichbare Umfrage auch schon mal Anfang des Jahres in einem Webinar hatten und da bin ich natürlich gespannt, wie die Ergebnisse ausfallen, ob das vergleichbar ist mit dem Ergebnis von damals.
Gut, auch hier können Sie weiter die Umfrage beantworten. Ich setze meinen Vortrag schon einmal weiter fort und zwar mit der folgenden Folie. Thema ist IGA und die Security Posture. Wie hilft uns IGA, uns im Sicherheitsumfeld weiter zu verbessern? Ich glaube, um das klar zu machen, müssen wir zunächst einmal verstehen, wie funktioniert denn eine Cyber-Attack? Was sind die wichtigsten Elemente bzw. wie funktioniert eine Cyber-Attack, damit wir uns effizient dagegen verteidigen können? Zu dem Zweck habe ich mir von der IBM aus dem Report Cost of a Data Breach einige Zahlen ausgeliehen.
Die sehen Sie hier oben auf der Folie. Die Average Duration, also die durchschnittliche Dauer, bis eine Data Breach entdeckt wird, die beträgt ca. 199 Tage. Die Behebung dieser Data Breach nimmt nochmal weitere 73 Tage in Anspruch, laut dem Report.
Sprich, wir brauchen ungefähr ein Dreivierteljahr, bis wir eine Data Breach entdecken und beheben können. Wenn wir auf Data Breaches gucken, die mit Credentials zu tun hat, ist die Zahl sogar noch einen Ticken höher. Da liegen wir bei 292 Tagen. Anders formulierte Take-away, den wir hier aus diesen drei Zahlen nehmen können, und das ist auch wichtig für unser Verständnis von Cyber-Attacks, ist, dass eine Cyber-Attack nicht ein einmaliges, kurzes Event ist. Es tritt nicht auf und ist dann wieder weg, sondern es ist ein Prozess. Cyber-Attacks sind üblicherweise von langer Hand geplant.
Der Attacker nistet sich ein, exfiltriert Informationen über eine gewisse Dauer hinweg. Das ist nicht so, dass wir von jetzt auf gleich plötzlich alles verloren haben. Das ist insbesondere interessant, wenn wir über die Security Posture nachdenken. Die Security Posture bzw. den Schaden, den wir gegebenenfalls erleiden durch so einen Angriff, setzt sich zusammen aus dem, was wir hier in der Mitte sehen, nämlich einmal der Eintrittswahrscheinlichkeit, der Probability of Occurrence und der Schadenshöhe, dem Amount of Damage oder Amount of Loss, wie man es auch immer bezeichnen mag.
Beide Elemente spielen am Ende des Tages eine wichtige Rolle, wenn wir über den Erfolg einer Cyber-Attack nachdenken. Denn je länger eine Cyber-Attack anbaut, umso wahrscheinlicher ist es, dass der Angreifer entdeckt wird. Und je länger der Angreifer Zeit hat, bis er entdeckt wird, umso mehr Schaden wird er vermutlich anrichten. Nun haben wir die Möglichkeit, über Mitigating Measures es dem Angreifer natürlich schwer zu machen.
Sprich, wir können zum Beispiel bei der Eintrittswahrscheinlichkeit gewisse Maßnahmen treffen. Also als Beispiel, wir können Strong Authentication einführen, MFA, was mittlerweile auch fast überall der Fall ist, würde ich behaupten. Wir können unsere Mitarbeiter schulen, damit nicht auf Phishing-Links geklickt wird. Wir können Awareness schaffen für Social Engineering zum Beispiel und so weiter.
Sprich, wir wollen die Wahrscheinlichkeit für den Erfolg eines solchen Angriffs bzw. die Entdeckungswahrscheinlichkeit für den Attacker bzw. den Erfolg für den Angriff so niedrig wie möglich und die Entdeckwahrscheinlichkeit so groß wie möglich gestalten über unsere Maßnahmen. Das ist die eine Hälfte. Die andere Hälfte ist der Schaden.
Sprich, wir möchten gerne, dass wenn der Attacker aktiv ist, dass er so wenig wie möglich machen kann. Und das Stichwort dort ist natürlich Least Privilege. Wie kommen wir da hin? Zum Beispiel über die Orphaned Entitlements und die Orphaned Accounts.
Sprich, wir wollen die Orphaned Accounts deaktivieren und optimalerweise vielleicht auch löschen. Wir wollen die Orphaned Entitlements entfernen und so im Endeffekt Least Privilege-Enforcing den Spielraum, den dann ein Angreifer hat, so klein wie möglich gestalten. Dann gibt es natürlich hier noch die Maßnahmen in der Mitte.
Sprich, Maßnahmen, die auf beide Seiten einzahlen. Also, sowohl die Wahrscheinlichkeit reduzieren, als auch den Schaden, der hinten raus passiert, reduzieren. Und da finden wir so Sachen wie Regular Audits, also regelmäßige Kontrollen, regelmäßige Audits, die durchgeführt werden. Ein risikobasierter Ansatz, dass wir uns zuerst um die wichtigsten und risikobehaftetsten Objekte kümmern oder aber auch kontinuierliche Kontrollen, kontinuierliches Monitoring.
All das reduziert die Eintrittswahrscheinlichkeit und die Schadenshöhe und hilft uns dann, die Security Posture unserer Organisation zu verbessern. Sprich, mit den Werkzeugen, die wir in unserem IAM Baukasten haben, tragen wir aktiv zur Sicherheitslage im Unternehmen bei. Und zwar so ziemlich an allen Stellen.
So, das war die Idee IAM als Sicherheitswerkzeug. Und nun wollen wir mal schauen, was wir mit IGA und insbesondere mit den Autorisierungsmodellen dort anrichten können oder machen können. Als erstes würde ich dazu gerne vier Statements abgeben. Und zwar ist es wichtig zu verstehen, was ist eigentlich ein Autorisierungsmodell. Und was wir sehen können oder aus der Erfahrung heraus, kann ich sagen, sind die meisten Unternehmen sehr auf Role Based Access Control oder kurz RBAC fokussiert. Insgesamt gibt es aber deutlich mehr Autorisierungsmodelle da draußen.
Also die noch bekannteren Modelle sind beispielsweise ABAC und PBAC. Aber darüber hinaus gibt es bestimmt noch 10 bis zu 15 weitere. Ich habe hier unten ein bisschen Related Research verlinkt. Da kann man sich nochmal anschauen, wie man Autorisierungsmodelle denn clustern kann. Und einhergehend damit möchte ich auch meine Erfahrung teilen. Mein persönlicher Eindruck an der Stelle ist, wenn ich mit Kunden spreche, dass so 70 bis 80 Prozent aller Use Cases über Role Based Access Control gelöst wird heutzutage.
Ungefähr 10 bis 20 Prozent, das hängt ein bisschen davon ab, wie viele von RBAC gelöst werden, werden durch ABAC und PBAC, also Attribute Based und Policy Based Access Control, also die Automatisierung davon gelöst. Und die verbleibenden, ich sage mal, 5 Prozent werden über andere weitere Autorisierungsmodelle gelöst. Ein wichtiger Punkt, den ich auch teilen möchte, vor allen Dingen auch nicht nur in der Ansprache mit Kunden, sondern teilweise auch in Fachkreisen ist, dass oft nicht klar ist, wie die Abgrenzung zwischen ABAC und PBAC ist.
Das heißt, diese Begriffe werden gelegentlich auch in Fachkreisen synonym genutzt. Wichtig zu verstehen, auch wenn wir sie synonym nutzen, ist, dass ABAC und PBAC die Automatisierung von Access Controls über Regeln und Attribute darstellen. Da komme ich gleich auch nochmal darauf zu sprechen. Und das ist insbesondere interessant vor dem Hintergrund, dass wir davon ausgehen können, dass ABAC und PBAC in den nächsten Jahren als Trend im IAM-Umfeld behandelt werden. Warum ist das so?
Wir sehen insbesondere, wenn wir auf Zero Trust gucken und die neuen AI Capabilities, die uns entgegenkommen, dass wir damit davon ausgehen müssen, dass in nächster Zeit die Autorisierungsmodelle auch viel auf Kontext und Context Awareness zurückgreifen und dann Entscheidungen in Echtzeit treffen können und aber auch wollen, um eben insgesamt die Security Posture zu verbessern. Das bringt mich zur nächsten Poll an der Stelle wieder. Und zwar möchte ich gerne von Ihnen wissen, ob mein Eindruck eigentlich richtig ist.
Also, wie viel ABAC nutzen Sie eigentlich, um in Ihrem Unternehmen, in Ihrer Organisation die Use Cases für Access Control zu lösen? Sind Sie eher im unteren Bereich ABAC und haben viel Automatisierung oder sagen Sie, ABAC ist unser Hauptautorisierungsmodell? Wir machen 90 Prozent, 90 Prozent plus über Role Based Access Control. Ich habe gerade schon angekündigt, wir erwarten, dass wir mehr dynamischen Access, dynamische Autorisierung in den nächsten Jahren sehen werden, auch als Trend von der EIC. Deswegen würde ich ganz gerne noch zwei, drei Worte zu dem Thema verlieren.
Und zwar, wie funktioniert ABAC? Wie funktioniert PBAC? Wie automatisiere ich meine Access Controls auf Basis von Regeln, auf Basis von Attributen? Üblicherweise braucht es dazu vier Dimensionen, die wir betrachten müssen. Und das Gute an diesen regelbasierten Zugriffskontrollen ist, dass wir sie, selbst wenn wir keine Ahnung von IAM haben, relativ einfach über das Business formulieren können, solange wir uns an diese vier Dimensionen halten.
Sprich, ich muss wissen, wer, also das Subjekt, was tut die Action, wo es diese Action ausführt, also die Resource oder das Object und in welchem Kontext diese Aktion passiert, sprich die vierte Dimension Kontext. Wenn man das einmal in ein Beispiel überführt, dann kann man auch sehr schön sehen, wo der Unterschied zwischen End-User und Autorisierungsteam Perspektive ist. In der oberen Hälfte sehen wir, wie der Business-User, der End-User so eine Regel formulieren würde. Und zwar am Beispiel, Anna can access the folder Sales for Germany.
Sprich, Anna kann auf den Ordner Sales für Deutschland zugreifen. Wir sehen das Subjekt, die Aktion, die Ressource und den Kontext. Wenn wir das Ganze jetzt in eine Regel übersetzen müssen, dann formen wir oder dann ordnen wir das Ganze leicht anders an. Also aus Autorisierungsperspektive schauen wir uns die Primärobjekte an, die Identity, die Decision oder das Provisioning und die Ressource und das Objekt und ordnen den Kontext entweder der Identity oder der Ressource und dem Objekt zu.
Sprich, wir machen daraus einen Satz, der dann lauten könnte, Anna from Germany, if she is from Germany, she is allowed to access the folder Sales. Oder Anna from Germany is added to the AD Group Sales. Der entscheidende Unterschied hier in diesen beiden Varianten ist aber das Autorisierungsmodell.
Und zwar ist das Autorisierungsmodell hier davon abhängig, ob ich es zu entweder Deploy oder Admin-Time, also im Vorfeld durchführe, indem ich jemanden zu einer AD Gruppe hinzufüge oder ob ich das Ganze als Real-Time Decision-Making auslege und dann, sobald der Zugriff erfolgt, die Bedingungen prüfe, die herrschen müssen. Also in dem Fall ist Anna aus Germany. Am Ende des Tages kann man das wieder runterbrechen auf die beiden Ansätze, ARBAC und ABAC und PBAC.
Aber die wichtige Message, die ich hier eigentlich senden möchte, ist, dass egal welches Autorisierungsmodell ich nehme, es ein Stück weit Use-Case abhängig ist, wie ich das Ganze autorisierungsseitig umsetze. Und dass wir in Zukunft viel mehr ABAC und PBAC sehen werden, auch wenn ARBAC nicht verschwinden wird in dem Sinne. Und damit komme ich dann auch schon zu meiner Conclusion. Den vier Punkten habe ich schnell zusammengefasst, was ich gerade sage.
Sprich, ihr M-Trends EIC24, die fokussieren sich sehr stark auf Identity Security und auf Authorizations. Dann haben wir gelernt, Cyberattacks sind kein Short-Term Event, also passieren nicht einfach von jetzt auf gleich. Es ist ein langwieriger Prozess, der gut vorbereitet wird und der dann über eine gewisse Dauer ausgeführt wird. Was wir auch gelernt haben, dass wir nicht machtlos sind gegen solche Cyberattacks.
Sprich, wir sind in der Lage, mit dem Werkzeugkasten, den IAM und IGA uns bietet, Mitigating Measures aufzustellen, um diesen Angriffen entgegenzuhören. Und last but not least, Automation for IDM, also sprich die Automatisierung von Identity Management und Autorisierung, wird in nächster Zeit deutlich, deutlich zunehmen.
Und mit diesen ganzen Erkenntnissen und den Maßnahmen kann man sicherlich sagen, als Ergebnis dieses ersten Teils des Webinars, dass IAM gute Möglichkeiten bietet, die ganze Cyber Security Posture zu verbessern und dass das ein grundlegendes Element für die digitale Transformation sein kann und wird. Und damit komme ich auch zum Ende meines Vortrags und würde dann an Moritz übergeben für den dritten Teil.
Super, vielen Dank Philipp. Ich fand es ganz interessant. Du sagtest, dass es eigentlich drei Treiber gibt für IGA oder für Identity und wenn ich so 10, 15 Jahre zurückgucke, dann war es immer so, dass es eigentlich zwei Treiber gab, entweder Effizienz oder Compliance. Der eine hat eher Effizienz gemacht und der andere Compliance und Security war nie so wirklich ein Thema. Und das hat sich dann doch jetzt in den letzten Jahren sehr, sehr stark geändert.
Ja, ich kann vielleicht auch mit zwei, drei Worten darauf reflektieren. Das ist also fast wie ein Elfmeter, was du da hingelegt hast im Grunde genommen. Denn gerade diese Dimensionalität des Accesses ist also auch Bestandteil einer neuen Funktion, die wir jetzt zu Navigate mit vorstellen. Wir nennen das dynamische Rollen, aber im Prinzip genau diese Idee wegzukommen von Zertifizierung, also es wird sie nach wie vor geben, aber die Zertifizierung eigentlich als Medium, das in die Vergangenheit schaut, welche Rechte habe ich gehabt.
Im Zweifelsfall habe ich halt zu lange die falschen Rechte gehabt. Hingehend zu Policy-Based Access, wo ich sagen kann, also wenn dieses Konglomerat an Attributen, an Identität stimmt, dann kann er eben diesen Access haben. Ich gucke also mehr nach vorne, aber jetzt ist Moritz wieder da und kann übernehmen. Warum haben wir das Thema auch ausgewählt? Weil in der Tat in den letzten drei, vier, fünf Jahren begleiten wir eine Reihe von größeren Security-Transformationen, die häufig entweder aus einem Cyber-Incident-Vorfall entstanden sind oder halt auch regulatorisch getrieben wurden.
Jetzt fragen sich natürlich die Unternehmen, die regulatorisch getrieben sind, warum kommt der Regulator mit neuen Dingen? Wahrscheinlich, weil es ja valide Vorfälle gibt. Also wenn ich mir die heutige Regulierung angucke im Bereich FS oder auch NIST 2, da werden explizit Dinge gefordert, die auf das Thema Identity einzahlen und wo ich fast bei jedem Thema auch ein Beispiel hätte, was denn da tatsächlich passiert ist. Deswegen gehe ich mal ganz kurz darauf ein, was passiert eigentlich so im Bereich Digital Identity in den letzten Jahren.
Also wir sehen logischerweise immer wieder den Angriff auf Identitäten erstmal über einfache Phishing-Maßnahmen, dass ich dort E-Mails rausschicke und die werden durch Chat-GPT in der Qualität geschickt, die seinesgleichen sucht. Also jeder, der mal von seinem Unternehmen eine neue E-Mail generieren möchte im Namen des Vorstands, der kann das per Chat-GPT mal machen, der kriegt die richtige Corporate Identity wieder und man erkennt kaum noch, dass es eine gefakte E-Mail ist.
Grammatikalisch alles korrekt und dann nehme ich noch aus einem Dark-Web geklauten Passwort von dem gleichen Mitarbeiter und dann habe ich schon die Aufmerksamkeit, dass er auf jeden Fall auf meinen Link klickt. Und so bin ich dann häufig schon auf dem ersten PC und hangele mich dann eigentlich durch die ganze Organisation durch, schaue im Active Directory nach, wer ist der Domain-Admin und so weiter oder in welchem Skript steht, welcher API-Key, um halt privilegierte Berechtigungen zu bekommen.
Und genau diese Angriffsszenarien, die sehen wir halt immer häufiger, dass halt Angreifergruppen zusammenarbeiten, um den Initial Access zu bekommen und dann halt von dort aus den privilegierten Access zu bekommen und das macht es natürlich unweg einfach, Unternehmen zu erpressen, zu kompromittieren etc.
Und wir hatten jetzt in dem letzten, ich glaube, letzten halben Jahr gab es zwei Zero-Day-Exploits bei Firewalls und jedes Mal, als dort ein Problem zwischen dem Kunde und seinem Supplier war, ja, wer patcht denn jetzt eigentlich diese Firewall, war der Angreifer schon häufig drin und hat dann schon angefangen, die ersten Bereiche zu verschüsseln, weil er entweder das Active Directory übernommen hat oder mal den VMware-Cluster oder oder und dann stehe ich natürlich da mit meinem kurzen Hemd und kann eigentlich nichts mehr machen, außer im besten Fall meine verschüsselten Backups anzugucken, wenn ich die nicht offline gebackupt habe oder halt am Ende tatsächlich dann bezahlen.
Deswegen erwarten eigentlich alle Kunden, die jetzt heute Security-Programme mit uns aufsetzen, gewisse Grundprinzipien und ein gewisses Grundprinzip darin lautet dann häufig auch, wir wollen auf jeden Fall Zero-Trust machen, das hört sich immer gut an. Warum hört sich das auch gut an?
Ja, weil ich natürlich hier meinen Reifegrad in den relevanten, in dem Fall NIST-Kategorien häufig sehr, sehr hoch treiben möchte. Ja, ich möchte eigentlich an jeder Stelle stark authentifizieren. Ich möchte auf jeden Fall immer validieren und verifizieren. Und das führt natürlich dann dazu, dass ich grundlegend mir neue Gedanken machen muss, wie baue ich mein IGA, mein Privileged Access, aber auch mein Access Management neu auf.
Und dabei habe ich ja nicht nur die Herausforderung, dass ich auf der einen Seite ein neues Tool einführe, sondern auch, dass ich hier eine richtige Governance aufbaue, wie ich mein Business, die Mitarbeiter enable im Neudeutschen, ja, wie man Berechtigung auch zu einem Minimalkonzept eigentlich vergibt, ja, dass es nicht mehr so läuft, wie der Moritz kommt neu und gibt dem die gleiche Berechtigung wie der Hans, aber der Hans geht jetzt nach 25 Jahren in Rente, sondern dass es immer Job-bezogen vergeben wird.
Und deswegen glaube ich auch so ein bisschen das Thema Roll-Based Access Control oder rollenbasierter Zugriff anhand von HR-Profilen wird weiterhin ein großer Wunsch sein, in Kombination dann mit genau diesem Policy-basierten Zugriff, dass ich dann sagen kann, alles klar, der Moritz ist Mitarbeiter im Personalwesen und kann auf die Daten von Klaus zugreifen. Und das darf der auch mit seinem 4M-PC. Aber alle Mitarbeiter dürfen laut Betriebsrat auch ihre Gehaltsabrechnung mit ihrem privaten Gerät im HR-System abrufen, ja.
Und da muss natürlich dann eine ziemlich schlaue Kette entstehen zwischen der Identität, der Authentifizierung, der Autorisierung und halt auch der Zielanwendung, wenn der Moritz dann aus dem Urlaub mit seinem privaten iPhone aufs Personalsystem zugreifen möchte, ja.
Und genau diese Kombinatorik im Sinne von Zugriffssteuerung wird immer, immer weiter relevant und auch gefordert, führt aber auch dazu, dass wir in genau diesem Security-Programm nicht nur die Herausforderungen haben, die Identitäten auf dem aktuellsten Stand und Berechtigungskonstrukt zu haben, sondern auch eine ganze Reihe von Anwendungen umzustellen, ja. Also das Thema Application Onboarding nicht nur an eine IGA-Lösung, sondern auch an eine Access-Management-Lösung, an eine PAM-Lösung, wird natürlich umwegkomplex.
Denn auch hier treffe ich ja immer auf unterschiedlichste Arten von Protokollen, ja. Care Boss an der Stelle trägt ja immer alle Berechnungen im Bauch, ja. Wohingegen ich mit OAuth zum Beispiel deutlich präziser Berechnungen vergeben kann. Und all diese Systematiken muss ich quasi in meinem Least-Privilege-Konstrukt natürlich auch durchdenken und überlegen, wie arbeiten eigentlich die Mitarbeiter bei uns im Unternehmen mit welchen Zielanwendungen eigentlich zusammen.
Gleichzeitig habe ich natürlich dann mal neben dessen, dass ich regulatorisch konformer werde, weil ich Berechtigungen auf einem minimalen Prinzip vergebe, weil ich regelmäßig Berechtigungen in verschiedenen Dimensionen auch rezertifiziere und vielleicht auch Regelwerke wie SOD einbaue, habe ich natürlich auch häufig die Möglichkeit, in anderen Transformationsprojekten, entweder in einem S4ANA-Transformationsprojekt, das Thema SAP-Lizenzen mal neu zu denken oder halt auch auf den Cloud-System zu schauen, wer nutzt eigentlich, in welcher Art und Weise, welche Lizenzen in mein Software-as-a-Service-Plattform, um halt dort dann auch zu sagen, na ja, vielleicht kann ich auch bei der nächsten Relizenzierung mit Microsoft Service Now, Salesforce und Co.
auf ein anderes Konstrukt umsteigen, weil ich jetzt hier eine ganz andere Transparenz darüber habe, welche Mitarbeiter haben vielleicht nur einen sehr minimalen Zugriff auf unsere, oder Nutzungszweck von unseren SaaS-Anwendungen, welche sind wirklich Heavy-Benutzer und brauchen tatsächlich auch dann die großen Lizenzpakete.
Und deswegen ist es halt auch immer so, dass wir in den Security-Transformationsprojekten, das IGA-Projekt als natürlich eines der komplexeren Themen sehen, ja, sicherlich ist eine Netzwerksegmentierung oder auch eine Einfügung eines EM-Socks ähnlich komplex, ja, aber natürlich hier das ganze Involvement von Fachabteilung, Business, Application-Onboarding und so weiter ist im Bereich IGA natürlich hier immer eine sehr harte Nuss, die man knacken muss.
Und wenn wir uns ansehen, welche Risiken eigentlich der Angreifer eigentlich ausnutzt, und das ist eigentlich aus meiner Sicht auch sehr häufig sehr interessant, ja, also ein Angreifer guckt ja aus verschiedenen Richtungen darauf, wie er jemandem Schaden zuführen möchte. Ja, der Angreifer guckt natürlich erstmal auf den einzelnen Mitarbeiter und sagt, ja, mache ich mal ein bisschen Spearfishing oder schieße erstmal auf die ganze Mitarbeiterklasse und versuche erstmal reinzukommen.
Das hat man ja häufig im Griff, ja, durch starke E-Mail-Security oder halt auch durch MFA bei den Mitarbeitern, da kriege ich das häufig gut in einer gewissen Art und Weise gemanagt. Wenn das aber dann nicht funktioniert für die Attacker, dann gehen sie auch häufig auch gerne auf die Third Parties, entweder auf die IT-Externen, ja, so jemand wie mich, dass sie versuchen, naja, ich versuche mal den Moritz extern anzugreifen und darüber dann den Weg wieder rein in die Unternehmen zu finden.
Oder was wir auch häufig gesehen haben, ist, dass es halt im Rahmen der Supply Chain Angriffe gab, ja, dass ich zum Beispiel den Logistiker angreife, der das große Industrieunternehmen beliefert, und darüber dann wieder technologisch Zugriff auf bestimmte Netzwerkbereiche zu erlangen und Bereiche zu übernehmen. Was wir auch sehr häufig gesehen haben, war der Angriff auf Cloud Service Provider, ja, dass ich dort schaue, wie kann ich eigentlich anhand von den SaaS-Anwendungen erkennen, dass ich Zugriff auf weitere Daten von einem Kunden bekommen kann.
Ja, wir hatten einen Fall, da kam der Kunde zu uns und sagte, naja, im IGA-Projekt sollt ihr eine Salesforce- oder ServiceNow-Instanz anbinden, und dann hat sich herausgestellt, dass der Kunde nicht eine hat, sondern 72, ja, die Anzahl 72 war genau die gleiche Anzahl der 72 Entwickler, die an dem Projekt arbeiten, weil jeder sich regelmäßig eine Produktionskopie mit allen Produktionsdaten gezogen hat, um darauf zu entwickeln und immer den aktuellsten Stand zu haben.
Das Problem dabei war, diese Anwendung war weder an IGA angeschlossen, das heißt, hat der Entwickler das Projekt verlassen, hat man darüber keine Transparenz. Man hat weder gesehen, dass Multifaktor-Authentifizierung durchgeführt worden ist, weil das einfach eine kopierte Cloud-Instanz war, die einfach so rumgedümpelt ist, und auch andere Sicherheitsmaßnahmen wie eine Überwachung, was quasi in diesem System passiert, hat auch nicht stattgefunden.
Das heißt, diese Angreifer mit ihren Tools und Techniken werden immer kreativer und versuchen natürlich immer, initial die Identitäten zu übernehmen. Und wenn jemand von Ihnen auch gerne mit den Kollegen der digitalen Transformation im Unternehmen spricht, der hört dann auch mal wieder, oh, uns ist mal wieder ein Client-ID, Client-Secret ins Dip gerutscht, ja, und dann habe ich direkt sehr privilegierte Berechnungen zwischen zwei Anwendungen, die ich auch nutzen kann.
Und auch hier haben wir häufig das Problem, dass es dann heißt, na ja, der Service Provider sagt Client-ID und Client-Secret-Wechsel dauert bei uns fünf Tage, ja, und fünf Tage mit so einem Risiko durch die Gegend zu laufen, möchte man halt grundsätzlich auch nicht. Das heißt, dieser Ansatz über Identitäten und den Angriff und die Steuerung dieser Zugriffe nachzudenken, ist grundsätzlich zwingend erforderlich und ratsam. Und warum ist das so? Weil wir natürlich hier in einer deutlich verunruhrenden Welt heutzutage leben, ja.
Wir haben auf der einen Seite oder auf der linken Seite jetzt hier früher das System gehabt, wir haben irgendwo ein Corporate-Network, wo man eigentlich allem vertraut hat, was in diesem Netzwerk passiert, ja, ob da ein User auf eine Anwendung geht, ob ich das nachverfolgen möchte, ein User kann direkt Remote-Access auf den Domain-Controller machen, ohne über irgendwelche Jump-Server oder ähnliches zu springen, ja, es gab keine Netzwerk-Segmentierung und sensitive Daten lagen eigentlich alle auf dem Share-Drive, ja, und man kam relativ schnell an sehr, sehr viele Daten, weil man grundsätzlich allen vertraut hat.
Und es gab eigentlich nur relativ wenig Identitäten, die von außen zugegriffen haben, da gab es dann mal ein paar Mitarbeiter, die per VPN zugegriffen haben, oder halt auch Business-Partner, die aber irgendwo in einem Perimeter gehalten worden sind und nie in das vertraute Netzwerk reinkamen.
Und dieses Modell hat sich spätestens seit Corona eigentlich geändert, sodass ich auf der einen Seite sagen muss, die Zugriffspunkte, die im eigenen Netzwerk sind, denen kann man schon häufig nicht mehr vertrauen, weil ich eigentlich immer auf diesem Zero-Trust-Prinzip, Assume-Breach, arbeiten sollte und darüber nachdenke, naja, was ist denn, wenn jemand wieder mir die Spieltags-Ergebnisse vom Fußball geschickt hat und ich klicke auf das Foto und am Ende war es dann gar nicht der Kicker, sondern es war irgendwie durch einen interessanten Wortwechsel oder Buchstabenwechsel eine Fake-Seite und dann ist der Angreifer da auf meinem PC und kann sich weiterentwickeln, sondern muss darüber nachdenken, dass wenn jemand auf meinem einzelnen PC ist, in meiner Kundenumgebung oder in meinem Unternehmensnetzwerk, dass er von dort aus relativ schwierige Wege hat, um irgendwie weitere Informationen zu erhaschen.
Und das kann sein, er kann das Active Directory auslesen, indem er einfach schnell sucht, wo alle Berechnungen sind. Es kann sein, wie gerade angesprochen, er darf nicht durch das ganze Netzwerk durchbrausen, weil er nicht die Berechnung dazu hat, das ganze Netzwerk zu lesen zum Beispiel. Oder auch der Weg in die Cloud, auch dieser kann ja weiter limitiert werden, über bestimmte Produkte, das man hier sicherstellt. Durch reduzierte Berechtigung kann er jetzt auch nicht auf alle Webseiten im Internet gehen, sondern nur auf die, die für das Unternehmen relevant sind.
Weil auch hier stellt sich ja häufig die Frage, warum muss man eigentlich auf alle Internetseiten der Welt aus einem Unternehmen zugreifen, warum reduziere ich die nicht, um halt auch zu überwachen, naja, wer möchte eigentlich wohin Daten schieben? Weil häufig ist es ja genau so, dass der Angreifer der Zukunft erlangt hat, diese dann auch exfiltrieren möchte. Und deswegen braucht es hier einen grundsätzlich neuen Ansatz, der darauf abzielt, Berechtigungen anders zu verwalten.
Wir nutzen da immer eine gewisse Referenzarchitektur, bevor ich gleich zum Klaus rübergebe, der dann darüber spricht, wie wir die Transparenz eigentlich in Unternehmen schaffen. Aber häufig ist es so, dass wir anhand der IGA Capabilities darüber nachdenken, abgeleitet von Prädikatität von Anwendungen.
Wie kriege ich schnell die Transparenz her über viele Anwendungen, 50, 60, 100 Anwendungen, um dann zu sagen, auf dieser Basis kann ich Berechtigungen reduzieren, aber kann auch gleichzeitig dann anfangen, Prozesse aufzubauen, um Rollen zu designen, um Access Reviews durchzuführen, um weitere Intelligence eigentlich rauszuziehen und dann Verbindungen herzustellen, zum Beispiel zum Privileged Access Management, um die privilegierten Rechnungen zu verwalten oder halt auch im Access Management zu sagen, naja, für folgende Anwendungen wollen wir auch ein bestimmtes Set an Berechtigungen nur übergeben oder rausgeben, sodass es nicht immer vorgehalten wird.
Das erstmal so im Groben und Ganzen zum Thema IGA im Bereich der Security Transformation und Klaus, an der Stelle würde ich einmal an dich rübergeben. Danke, Herr Weiß. Es waren jetzt ein paar schöne Stichpunkte dabei und ich habe das einfach mal gemerkt, das hat im Grunde genommen alles das, was jetzt Philipp und auch Moritz angesprochen haben, hat letztlich mit Visibilität zu tun. Also was weiß ich denn? Was ich nicht sehe, kann ich nicht managen. Was ich nicht sehe, was ich nicht weiß, kann ich keine kluge Entscheidung treffen. Also wie komme ich denn dazu?
Das heißt, wir gehen gerne immer davon aus, was könnte man denn machen, wenn alles soweit wäre, aber irgendwie muss ja auch so ein bisschen Futter bei die Fische kommen. Ich brauche die Information ja irgendwoher. Und natürlich interessiert mich die Frage, wer hat denn Access zu was? Aber im Grunde genommen gibt es natürlich eine Million Fragen mehr und wir könnten diese Liste noch weiter machen. Da sind Lizenzfragen dabei, also wer hat welche Lizenz assigned bekommen und wer kümmert sich um was, wie oft werden Berechtigungen benutzt und all diese Dinge.
Mit einem gut aufgebauten IDM-System kann man genau diese Fragen alle beantworten und Sie haben eine Single, eine Golden Source of Truth, wo diese Informationen drin liegen und wo Sie sie rausziehen können. Wie machen wir das? Das heißt, wir haben also schon lange verstanden bei SailPoint, dass letztlich das Application Onboarding ist das A und das O. Das heißt, das ist die Art und Weise, wie IDM-Systeme gefüttert werden. Es müssen Anwendungen anschlossen werden. Morris hat es eben ganz locker gesagt, 10, 50, 60, 100. Ich würde die Zahl weiter nach oben treiben.
Unsere Kunden haben durchaus auch tausend und mehrere tausend Anwendungen angebunden. Das ist okay, wenn das jemand hat, ja. Aber es sind auf jeden Fall mehrere hundert Anwendungen, in allen regelnden Unternehmen. Und wenn ich frage, wie haben Sie angeschlossen? Und ich komme dann als Antwort, ja, wir haben ein System seit fünf Jahren. Wir sind schon bei fünf Anwendungen oder 30 Anwendungen. Seien Sie mir nicht böse, da kann ich nur mit dem Kopf schütteln. Das ist mein einziges Rätsel. Das ist dann immer noch ein riesiger Blindflug.
Und auch wenn Sie vielleicht die Majority der Identitäten in diesen 30 Anwendungen haben, aber Sie haben natürlich die Accounts nicht unter Kontrolle in den restlichen Anwendungen, genauso wenig wie die Berechtigung davon. Also dieser Punkt ist essentiell. Und wir haben das auch verstanden. Wir untermauern das mit entsprechender Connectivity. Das ist für uns ein ganz wichtiger Punkt. Wir haben da auch noch, um Sie nicht alleine zu lassen, damit Sie nach dem Motto, ja, welchen Connector soll ich denn nehmen, gibt es bei uns jetzt ein automatisches Onboarding.
Das heißt überall, wo hier so ein kleiner Zauberstab dran ist, da spielen wir Harry Potter und geben ihn einfach aus unseren Erfahrungen entweder Best Praxis oder auch mit AI-Unterstützung mit rein. Wir finden die Applikation. Also wenn Sie uns einen Punkt zeigen, wo die Applikationen stehen, wie zum Beispiel ein Single Sign-On oder auch eine CSV-Datei, machen wir eine Empfehlung, mit welchem Connector Sie da rangehen können. Es ist nicht immer nur ein Connector. Manchmal können mehrere Connector den Job erledigen.
Und wir geben Ihnen Empfehlungen, wie Sie zum Beispiel die Accounts dann am besten, die wir dort finden, zu den bestehenden Identitäten korrelieren können oder welche Attribute Sie am besten nehmen, um einen Account in der entsprechenden Applikation anzulegen, wenn Sie eben auch professionieren wollen. Also sowas gibt es ab Mitte Oktober bei uns auch kostenlos im Produkt mit bei. Das heißt, dann sind wir an dem Punkt Visibilität. Jetzt werden Sie sich vielleicht fragen, der Typ hat ja Nerven. Ich ziehe hier mehrere hundert Anwendungen.
Ich habe keine Ahnung, ich sage mal anderthalb Accounts in der Anwendung. Wir haben im Schnitt vielleicht hundert Entitlements, die wir aus den Anwendungen rausziehen.
Ich meine, jeder weiß, wie viele Entitlements, sprich AD-Gruppen er hat. Also um die hundert im Schnitt wird vielleicht eher die Regel sein als die Ausnahme. Wenn ich das multipliziere, den ganzen Gramm, da komme ich auf Millionen von Entitlements. Wie glaubt der eigentlich, wie ich das machen soll? Und genau diese Frage haben wir auch bereits beantwortet für Sie. Wir arbeiten nämlich intensiv mit AI. So wie das der Philipp vorhin angesprochen hat. Das machen wir übrigens schon seit 2017. Das ist kein neues Buzzword für uns.
Das heißt, wir finden über Cluster-Analyse die kritischen Menschen bei Ihnen. Wir bilden da sogenannte Peer-Groups draus. Das macht das System alles alleine. Sie müssen dafür nichts tun, außer Anwendungen anschließen. Und wir finden dann in diesen Peer-Groups eben diejenigen, die wir als Outlier bezeichnen. Entweder die mit einer hohen Wahrscheinlichkeit oder Unwahrscheinlichkeit. Hier finden Sie Ihre offenen Accounts. Das ist nicht zwangsweise gut oder schlecht, was hier steht, sondern hier steht nur, dieser Mitarbeiter hat andere Rechte als der Rest in seiner Peer-Group.
Bitte kümmer dich. Ob Sie das jetzt einfach mit einer Zertifizierung machen, die Sie losschießen, oder ob Sie einen Deep Dive machen, wollen das selbst lösen wollen, überlassen bei Ihnen. Aber Sie haben die Informationen, Sie haben das Fädchen in der Hand, wie Sie das Problem lösen können. Also das ist dann die offenen Accounts. Das ist der nächste Weg nach Visibilität, die offenen Accounts zu lösen. Und dann natürlich die Outlier zu identifizieren. Das haben wir gemacht. Aber Moritz hat einen netten Punkt angesprochen, das war Cloud. Cloud ist natürlich ein Riesending.
Und wenn Sie glauben, dass in der Cloud die Regeln oder die Berechtigungen genauso vergeben werden, wie das halt eben in Ihrem Unternehmen passiert, nämlich über Gruppen beispielsweise, dann sind Sie leider falsch gewickelt. Bei AWS beispielsweise funktioniert das alles über die Policies. Das heißt, Sie haben Gruppen, da können Sie wohl Leute reinmachen, aber die Policy bestimmt den eigentlichen Wert. Das heißt, am Ende fragen Sie sich, Access, wo kommt das jetzt her zur Hölle?
Wir haben das aufgelöst, indem wir Ihnen einfach zeigen, wo kommt der Access überall her für einen bestimmten Menschen, wo kommt der Überallberechtigung auf die Ressource her, sodass Sie innerhalb einer Zertifizierung eine qualifizierte Entscheidung treffen können, was muss ich wegnehmen, damit die Berechtigung für diesen Menschen verschwindet an dieser Ecke. Diese Darstellung finden Sie sonst kaum im Grunde genommen, weil diesen Access aufzulösen, macht eben genau dieses System für Sie.
Okay, damit hätten wir das Review von dem Access mit dabei. Das wird mitgedacht, dass wir natürlich in den Access Reviews auch Empfehlungen mit aussprechen, die auch AI-gestützt sind, sprich auf diese Clusteranalyse, also auf Ähnlichkeiten, Unähnlichkeiten und Ihnen dann Empfehlungen aussprechen, welcher Access zu behalten oder zu revoken ist. Das ist eigentlich eine Selbstverständlichkeit. Man muss das nicht tun. Wir zwingen niemanden, AI zu nutzen. Sie können das auch gerne abschalten, wenn Sie mögen, aber in aller Regel sind die Benutzer sehr dankbar, dass es so etwas gibt.
Und dann natürlich das Definieren von Rollen. Dazu gehört auch noch mal AI. Wir finden von alleine im Prinzip auf diese Clusterlösung Rollen, die wir als Common Access bezeichnen würden, wo wir sagen, hier gibt es viele ähnliche Mitarbeiter, die diese Rechte haben. Die könnten zu Rollen umgesetzt werden, aber wir helfen ihnen auch beim Nachschärfen der Rollen.
Jeder, der schon mal ein Rollenmodell aufgesetzt hat, weiß, dass vielleicht in einem halben, dreiviertel Jahr, vielleicht auch erst im Jahr, ist dieses Rollenmodell eigentlich schon wieder obsolet geworden, weil es gibt neue Entitlements in der Firma, es gibt neue Systeme in der Firma oder andere Systeme, die sind neu aufgesetzt worden. Sie müssten eigentlich das Rollenmodell nachschärfen. Das ist aber so ein bisschen eine Strafarbeit.
Das will eigentlich niemand richtig machen, weil jeder in sich denkt, oh, kannst du dir nicht erinnern, die sechs Wochen, die wir da rumgesessen haben und haben uns die Köpfe heiß geredet. Das ist natürlich nicht ganz einfach.
Was die Maschine bei uns für sie macht, ist, sie guckt permanent nach, wer hat welche Rollen und welche Entitlements und wenn sie die gleichen Rollen und gleichen Entitlements an eine Mitarbeiter findet, gibt sie eine Empfehlung und sagt, dieses Entitlement in diese Rolle reinzusetzen, macht vielleicht Sinn, weil da musst du nur noch einmal zertifizieren und sie müssen keine zweite Rolle bauen. Da hängt jetzt noch ein bisschen was dran, weil wir eben jetzt auch dynamische Rollen können. Das reflektiert zudem, was Philipp im ersten Vortrag gesagt hat, diese Dimensionalität in den Rollen.
Genau das bilden wir jetzt auch ab. Das kommt aber hier noch hinzu, auch da wird nachgeschärft, wer hat welchen Entitlement, was kann man in die Rolle noch mit reinnehmen, um das einfach einfacher zu halten. Das heißt also, wir helfen mit wirklich Machine Learning, mit Algorithmen, die da sind einfach, die heute sich bewährt haben. Wie gesagt, wir machen das seit 2017. Helfen wir, die Outliers zu finden in der Review.
Wir helfen bei dem Definieren von Rollen und trotzdem, wie gesagt, die Risikoreduzierung und der schnelle Roll kommt über die Visibilität mit rein, über die schnelle Findung von Open Accounts, die dann eben über die Outliers benannt werden. Wenn Sie da ein bisschen mehr zu wissen wollen, tiefer reintauchen wollen, die Navigate in London kann ich Ihnen nur sehr ans Herz legen dabei. Wir haben noch Platz. Wir haben das ein bisschen aufgestockt jetzt, was die Plätze angeht, weil wir große Nachfrage haben dazu. 19. bis 21. November im schönen London.
Ich verspreche Ihnen spannende Vorträge über zwei Tage. Ich habe selbst zwei davon, wo ich zum Beispiel auch darüber spreche, wie EGA für die Cyber Security tatsächlich dienlich ist. Da gehe ich also auf diese ganzen Thematiken noch ein bisschen näher ein. Und Sie haben jede Menge Ansprechpartner, auch deutsche Ansprechpartner, Firmen, die das schon umgesetzt haben oder auch Prospekts, die vielleicht genauso unsicher sind, wie Sie es manchmal vielleicht sind und fragen, wo fange ich denn am besten an? Und da kann man sich super austauschen dazu. Das war es von meiner Seite.
Besten Dank dafür. Ja, danke, Klaus. Dann gehen wir in die Questions and Answers. Aber bevor wir wirklich in die Fragen eintauchen, haben wir versprochen, wir schauen uns die Ergebnisse der Polls an. Und damit würde ich auch ganz gerne die Ergebnisse der ersten Poll öffnen. Nur noch mal als Erinnerung, was haben wir gefragt? Wir haben nach den Trends gefragt.
Also, was sind die most important Trends? Und wir haben zwar einen Gewinner mit 32 Prozent, aber es ist doch erstaunlich gleich verteilt. Was denkt ihr?
Klaus, willst du anfangen? Was ist deine Meinung zu den Ergebnissen?
Ja, es überrascht mich nicht. Also, ich meine gerade DORA NIST 2 ist momentan in aller Munde. Natürlich auch die Frage, warum hört es nicht auf mit den Regulatoren? Ich habe schon den Leuten gesagt, wir werden sicherlich noch NIST 3 bekommen, egal wie es dann heißen mag. Solange die Firmen sich nicht bewegen, ist der Gesetzgeber natürlich gehalten, die Züge immer enger zu ziehen oder immer straffer zu ziehen, weil er im Zweifelsfall der Steuerzahler derjenige ist, der für irgendwelche Auffangszenarien zuständig sein muss.
Also, das kann so nicht funktionieren. Darum wird das immer weiter angezogen.
Also, mich überrascht das nicht. Und AI damit reinzubringen, ich habe es eben gerade gezeigt, allein über die Menge an Entitlements, die zu bewältigen sind, das ist anders eigentlich nicht machbar. Das ist kein Passwort mehr, sondern es ist tatsächlich eine technische Notwendigkeit geworden, damit zu arbeiten.
Moritz, überrascht es uns, dass dann auch vor dem Hintergrund, was Klaus sagte, nicht so Themen wie dynamischer Access oder beispielsweise auch Fundamental Enterprise, ERM-Challenges noch mehr Prozente bekommen? Jetzt lebe ich ja in einer Beraterblase einer Unternehmensberatung, die hauptsächlich aus regulatorischen Projekten das Geschäft gewinnt. Deswegen ist es für mich schwer zu sagen, dass das jetzt nicht so ist.
Aber in der Tat ist es ja so, dass DORA, die eigentlich nur eine Weiterentwicklung ist, der ganzen FS-Regulatoren, die es seit 15 Jahren gibt, und auch dort sieht man nach wie vor große Themen, eher jetzt auch viel in der Modernisierung der Identity-Lösung, die sie seit 20 Jahren haben. NIST 2 bringt ja in vielen Bereichen auch erstmal den richtigen Start in den Bereich.
So, und wenn ich jetzt mal darüber hinausgehe, dass ich jetzt in 15 Jahren es geschafft habe, wie Klaus es gerade so ein bisschen ketzerisch meinte, ich habe HR bis zum AD angebunden, dann habe ich ja noch nicht viel erreicht. Und mit AI kriege ich ja dann die Möglichkeit, mal neben Application Onboarding, aber auch mit der großen Masse der Daten eigentlich umzugehen. Aber auch da, glaube ich, ist es wichtig, mit dem richtigen Augenmaß ranzugehen.
Ja, dankeschön. Das sind auf jeden Fall spannende Ergebnisse jetzt für die erste Poll. Ich glaube, dann gehen wir auch gleich weiter zu der zweiten Poll. Und da wollten wir wissen, was sind die most prominent drivers for IGA in your company? Und das Spannende daran, ich habe es eben schon mal erwähnt, wir haben die Frage schon mal im Webinar Anfang des Jahres gestellt. Da sahen die Ergebnisse noch ein bisschen anders aus.
Moritz, du kanntest die Ergebnisse von Anfang des Jahres nicht, deswegen nehme ich dich jetzt als erstes. Was ist dein Eindruck? Ich finde interessant, zu meinem Kommentar, bevor mein Zoom ausgefallen ist, dass die Kategorie, die es vorher nicht, eigentlich gar vor 15 Jahren, jetzt die höchste ist. Das Risiko, wenn ich mal auf das Cyber-Risiko und nicht das regulatorische Risiko sehe. Und das ist ja in der Tat so. Man muss ja nur montags die Zeitung aufmachen und sehen, wer am Wochenende gehackt worden ist. Da ist natürlich nicht immer IGA die Heilwaffe, aber es ist immer ein großer Teil.
Und meistens, zumindest das sagen unsere Forensiker und Incident Response Kollegen, ist es immer irgendwie ein Test-User, der gehackt worden ist für den Initial Access oder einer hat drauf geklickt, letztens rufte mir einer an und sagte, Anders, was machen wir? Ich werde hier erpresst um 200 Euro in Bitcoins, weil jemand mein Passwort hatte.
Ich so, wenn er für 200 Euro erpresst, löscht die Mail einfach, weil er einfach aus dem Darknet die E-Mail-Adresse und das Passwort gefunden hat und eine doofe Mail formuliert hat. Also man merkt schon, da ist halt richtig Musik jede Woche drauf. Und das geht halt bis in die private E-Mail-Box. Und deswegen, ja, mich überrascht es nicht. Ich finde es spannend.
Klaus, du hast noch bestimmt vor Augen, wie wir das erste Mal die Umfrage durchgeführt haben und hast noch die Ergebnisse vor Augen. Die Ergebnisse sind nicht exakt, aber ich weiß, dass Operational Efficiency ganz weit oben gestanden hat.
Genau, mit 51% damals. Ja, also die Zahl war deutlich, ja. Aber ich glaube, es hat einfach damit zu tun, weil sich die Wahrnehmung in den Unternehmen verschiebt.
Ich denke, viele denken sich heute, na ja, wenn ich meine Risiken zeitig habe, bin ich natürlich operativ effizienter geworden. Das stimmt ja auch. Die Sachen gehören schon irgendwie zusammen. Wenn ich mich um meine Regularien kümmere, habe ich auch meinen Risiko reduziert. Also man kann das sicherlich so und so formulieren, das ist vielleicht immer auch so ein bisschen dem aktuellen Zeitgeist geschuldet. Aber sicherlich ist es nicht mehr der Haupttreiber. Das ist auch das, was wir momentan sehen.
Wir werden viel öfter danach gefragt, habt ihr da für eine Zertifizierung, gibt es da für eine Zertifizierung, habt ihr da schon mal was gemacht? Die Leute wollen einfach safe sein. Das ist einfach ein Punkt und das ist einfach Risikominimierung. Die gehen wahrscheinlich auch davon aus, dass die Effektivität einfach von selbst kommt damit.
Ja, spannende Ergebnisse an der Stelle in der zweiten Poll. Gehen wir zur dritten Poll. Die Frage nach Airbag an der Stelle. Ich habe meinen Eindruck geteilt, habe die Teilnehmer gechallenged an der Stelle. Finden wir das überraschend? Diesmal fange ich wieder mit dir an, Klaus.
Nein, eigentlich nicht. Es wird sich aber dramatisch ändern. Du hast das schon angesprochen. Dynamic Access ist halt ein ganz wesentlicher Punkt. Wir bringen das momentan mit rein, wo man gerade diese vier Pillars, die du genannt hast, also das Subjekt, die Aktion, den Kontext, das alles in Summe bringen kann. Das ist dieses Ausrichten von der Policy, die ich dann eben zertifizieren kann und abfragen kann. Das wird sich stabil ändern. Also ich erwarte damit, dass unsere Cloud-Kunden zumindest bis Jahresende das massiv umgestellt haben an dieser Ecke. Da brechen wir fest mit.
Das ist ein Game-Changer definitiv mit den dynamischen Rollen. Aber es geht letztlich, wird der eine oder andere vielleicht das auch nur für Airbag halten, auch wenn es dann eher mehr P-Bag ist. Aber es wundert mich. Finde ich auch gut.
Ich meine, in die Richtung kann es ja auch ausgehen. Naja, also man muss ja immer auch schauen, wie ist eigentlich so der Hype-Cycle von der Produktentwicklung. Also der Analyst kommt vor fünf Jahren mit dem Thema, dann kommt der Hersteller, entwickelt etwas und die meisten Unternehmen haben noch nicht mal das letzte Thema adressiert. Und deswegen ist Role-Based-Access-Control jetzt, was ja auch schon seit 15 Jahren Thema ist, auf dem Hype.
Und deswegen glaube ich, ist das für mich absolut nicht überraschend, weil fast bei jedem Kunden, den ich bin, gibt es entweder gerade eine riesige SVH-Transformation, wo ich das Thema Rollenmanagement neu denken muss. Oder ich habe ein regulatorisch getriebenes Thema, Bankenversicherung, Kapitaldienstleister, wo ich das gleiche Thema habe. Deswegen für mich war das null überraschend.
Gut, danke euch beiden. Da würde ich vorschlagen, wir haben noch ein paar Minuten Zeit, schnappen wir uns noch ein, zwei Fragen. Ich würde gleich mal eine in den Raum schmeißen und zwar die Frage, wie trägt IGA zur Einhaltung gesetzlicher Vorschriften und zur Reduzierung von Compliance-Risiken bei? Wir haben es in der zweiten Poll gesehen, dass Risiken und Compliance ein großes Thema sind. Was ist eure Meinung? Wie funktioniert das?
IGA, Compliance? Fangen wir da mit Moritz an. Also ich könnte jetzt wahrscheinlich noch mal eine Stunde darüber erzählen, was es da alles gibt. Aber ich sage mal, wir fangen mal ganz einfach an. Der Lieferprozess bei Banken muss innerhalb von wenigen Stunden durchgeführt worden sein. Habe ich das nicht und kann das auch nicht nachweisen. Da habe ich ein großes Problem. Es gibt bestimmte Systeme, die außerhalb meiner Infrastruktur stehen und komme ich da nicht dran. Mit einer IGA-Lösung brauche ich schon wieder einen manuellen Prozess.
Also dort einen Automatismus zu entwickeln, lohnt sich immer. Das Gleiche, was auch immer wieder das Thema ist, ist das Thema Need to Know and Least Privilege. Auch das steht überall drin. Schon in GDPA vor zehn Jahren oder wann das rausgekommen ist, auch dort war das ein großes Thema. Und hier der Moverprozess ist genau das. Regelmäßig zu überprüfen, wenn jemand im Unternehmen sich weiterentwickelt, dass die Berechnungen reduziert werden oder halt auch regelmäßig zu rezertifizieren.
Aber nicht nur aus der Sicht, der Manager hat noch seine richtigen Mitarbeiter, sondern der Applikationseigner guckt in seine Anwendung. Der Rolleneigner guckt in seine Rollenzusammenstellung und guckt auch noch darauf, wer hat eigentlich Zugriff auf diese Rolle. Also auch dort die richtige Governance zu haben und zu wissen, wer hat eigentlich auch die Verantwortung jetzt, diese Rolle zu überprüfen. Und das sind häufig die Hauptherausforderungen. Technologisch die Daten ins IAM reinzupumpen, wird ja jetzt hier durch Klaus und AI noch einfacher.
Aber darauf aufbauen, die Organisation mitzunehmen und die richtigen Mitarbeiter in die Verantwortung zu bringen, das ist für mich immer essentiell, wenn ich Compliance Risiken reduzieren möchte. Das bringt eigentlich den Punkt raus, wenn man das, sag ich mal anders beschreiben, ganz klein bisschen umformulieren will, hat es eigentlich damit zu tun, viele Firmen haben nicht verstanden. Also ich sag mal andersrum, deine Frage zu beantworten, wie führt es dazu, oder wie führt EDA dazu, dass dann die Compliance besser eingehalten wird, einfach indem EDA tatsächlich ein Programm wird.
Ich sag immer, Identity Management ist eigentlich keine IT. Das ist ein Prozess, der passiert jeden Tag im Unternehmen, ob ich das will oder nicht. Ich habe immer jemanden, der kommt, der geht, der sich bewegt, wo irgendwas verändert wird, der Rechte haben will. Aber so eine IDM Software gibt mir Kontrolle über diese Dinge. Das heißt, das ist der Moment, wo tatsächlich mich Software gestützt, einfach sagen kann, ich lebe diesen Prozess und ich vergleiche das manchmal mit einer Einführung von SAP.
Da mussten auch alle ihre Art, Warenwirtschaft zu denken, umstellen, machen das heute auf SAP, hat funktioniert über weite Teile, das so zu machen. Und so ist das im Prinzip auch, wenn ich ein IGA-System einführe, dann muss ich bestimmte Dinge einfach umdenken und muss sie einfach auch anders vorleben. Dann ist auf jeden Fall IGA ein ganz wichtiger Bestandteil von Cyber Security, weil es halt eben diese Single Source of Truth ist, wo ich alles machen kann.
Am liebsten sind es Firmen, die sagen, wir haben jetzt das System eingeführt, es gibt jetzt eine Betriebsvereinbarung, jedes System, das neu kommt, muss am IDM-System anzuschließen sein. Das wäre ein Traum. Ich kann dir zwei Firmen nennen, die das gemacht haben. Das kommt durchaus vor, zumindest bei unseren Kunden, die das verstanden haben. Die haben allerdings auch 1.200, 1.300 Anwendungen angebunden, die wissen, von was sie reden. Ich glaube, um die zwei Kunden von dir machen wir uns keine Sorgen, wir machen uns eher um die anderen Sorgen. Genau. Damit wir sagen, es geht.
Das ist keine Frage, der Größe der Organisation, sondern es ist wirklich eine Frage, wie viel Rückhalt habe ich von ganz oben, dass ich sowas auch tatsächlich so umsetzen kann und es nicht nur als erweitertes Spielzeug für irgendwelche Administratoren wäre, mit allem Respekt, ich meine das nicht respektierlich, aber das, was ich mit dem IDM-System bewegen kann, ist halt deutlich mehr, als einfach nur ein paar Anwendungen anschließen. Ja, absolut.
Kommen wir doch zur zweiten Frage, wir haben noch ein paar Minuten über und direkt daran anknüpfen, welche spezifischen Herausforderungen seht ihr denn bei der Integration von IGA in bestehende Infrastrukturen? Was seht ihr da bei euren Kunden? Was könnt ihr für Tipps mit auf den Weg geben?
Naja, also, ich weiß nicht, wer fängt an? Fangen wir an, Moos.
Also, ich sage mal, ich habe ja Anwendungen von IBM Host Mainframe bis AWS alles dabei. Also dort das richtige Maß zu finden, wie viel Aufwand stecke ich in welche Systemanbindung, ist, glaube ich, schon mal ein großes Thema. Und natürlich dann auch am besten ein Tool zu haben, was auch mir ein vernünftiges Framework bietet, viele Systeme im besten Fall auch standardmäßig anzuschließen.
Also, wenn ich am Ende nur drei, vier Standard-Konnektoren habe, also, das ist so ein bisschen, ohne jetzt auf die modernsten Hersteller zu schießen, aber es gibt so zwei, drei Hersteller, die sagen, ja, wir können ja skimmen, naja, dann google mal, wie viele Anwendungen skimmen können. Also, da wird einem schnell blass oder Angst und Bange, weil es können am Ende fünf Anwendungen von einem 500, ja. On-Premise kann es gar keine.
So, und da habe ich schon ein Problem, ja. Also, ich muss viele alte Protokolle verstehen und das ist häufig die Herausforderung bei bestehenden IT-Infrastrukturen.
Oder halt, ich setze auf bestimmte Plattform-Systeme wie halt einen Active Directory oder ähnliche, wo die Systeme angebunden sind. Habe dann natürlich andere Herausforderungen, aber das ist so häufig das, wo ich das Problem sehe. Und abgeleitet vielleicht noch einen Satz dazu, ist es häufig so, dass wenn das Projekt rein IT-getrieben ist, dann habe ich das nächste Problem, weil die IT kann sicherlich schnell viele Dinge umsetzen und anbinden.
Aber wenn ich jetzt AI verwende, in der Art und Weise, wie Klaus es beschrieben hat, und ich berechne jetzt mal die Rollen und die Outlier für meine gesamte Vertriebsmannschaft und alle Mitarbeiter im Vertrieb haben die Berechtigung, sich ein Porsche zu bestellen, dann wird am Ende kein Outlier entstehen, dass die Porsche-Bestellung nicht drin sein soll, ja.
Sondern alle Mitarbeiter in dieser Bubble dürfen sich ein Porsche bestellen und deswegen habe ich trotzdem Probleme bei der Berechtigung, weil es jemanden gibt, einen Fachmenschen, der diese Abteilung kennt, und das ist das Business-Involvement und nicht nur das IT-Involvement, der draufkommt und sagt, die Rolle muss da raus. Nur der Chef darf sich hier den Porsche bestellen. Genau. Und das ist genau das eigentliche... Kurze Antwort, Klaus. So viel Zeit haben wir nämlich nicht mehr.
Ja, dann lass gut sein. Also im Grunde genommen hat Moritz das auf den Punkt gebracht. Ich kann das eigentlich nur unterstützen.
Gut, dann machen wir hier das Closing, weil wir nämlich eigentlich nur noch eine Minute haben. Ich danke euch beiden, dass ihr hier wart, dass wir über IGA gesprochen haben und ich hoffe, wir konnten Ihnen weiterhelfen, liebe Zuschauer und Zuhörer, und freuen uns aufs nächste Mal.
Danke, Klaus. Danke, Moritz. Danke. Macht's gut. Mach's gut.
