IAM ist eine lose definierte Sammlung von Funktionen, die auch als Konto- und Passwortverwaltung bekannt sind. Es umfasst Identity Governance and Administration (IGA), Access Management (Authentifizierung und Autorisierung) mit den Untergruppen Privileged Access Management (Zugang für sensible Konten) und Public Key Infrastructure (Verwaltung und Verwendung von kryptografischen Schlüsseln).

IGA ist ein hybrider Satz von regelbasierten und anforderungsbasierten Provisioning-Workflows für Verzeichnisse und Anwendungen, die lokale Kontenspeicher nutzen und durch regelmäßige Bestätigungsflüsse unterstützt werden: Haben Sie als zuständiger Manager dies genehmigt? Typischerweise bietet Identity Governance ein Webportal und verfügt über eine Provisioning-Engine, die Warteschlangen von Aufgaben bei der Erstellung und Änderung von Benutzerkonten, Passwörtern und Berechtigungen ausführt. Konzeptionell deckt sie das Prozess-Frontend der Kontosicherheit ab, während Access Management, Privileged Access Management und PKI das technische Back-End bilden, wo alle Echtzeit-Operationen stattfinden.

Als Vertrauensanker des Unternehmens, insbesondere in einer modernen Zero-Trust-Architektur, steht die Identität an der Spitze der Nahrungskette der Sicherheit. In Anbetracht der Tatsache, dass sie ein gefundenes Fressen für Angreifer ist, sollte sie stark gegen eine Kompromittierung geschützt und (mit Verfahren und Übungen) für eine frühzeitige und schnelle Wiederherstellung und Wiederherstellung im Falle eines größeren Cybervorfalls vorbereitet werden. Traditionell gilt die IGA nicht als unternehmenskritisch, da sie asynchron ist und das Onboarding neuer Mitarbeiter nicht als wesentliche Fähigkeit angesehen wird. Das Onboarding von Notfallverstärkungen ist jedoch geschäftskritisch, wie jede Übung zeigen wird. Dies ist ein guter Ausgangspunkt: Machen Sie einen Pen-Test als Auftakt.

Der wahrscheinlichste Anwendungsfall in einer Cyber-Krise ist die Einbindung zusätzlicher Mitarbeiter, wie z. B. Forensiker, zusätzliche technische Unterstützung und verschiedene Krisen- und Kommunikationsspezialisten. Dies sollte nichts Ungewöhnliches sein, sondern während des Einfrierens einer angegriffenen Umgebung möglich sein. Es kann die Verteidigung beeinträchtigen, da der Angreifer höchstwahrscheinlich auch an den Konten herumspielt. Wenn Sie jedoch wissen, welche Änderungen bekanntermaßen gut sind (da sie aus der IGA kommen – zumindest solange diese sicher ist), können Sie alles andere als bekanntlich schlecht einstufen. Und wenn Sie IGA Reconciliation haben, können Sie automatisch aufräumen.

Der wichtigste aller Anwendungsfälle bei einer Sicherheitsverletzung ist das Zurücksetzen aller Passwörter», wobei dies im weiteren Sinne alles Gleichwertige einschließt, wie statische Schlüssel (wie in MDM, API, SSH und PKI) und für zusätzliche Faktoren in MFA (wie TOTP). Sie sollten auch auf Faktoren achten, die Sie nicht zurücksetzen können – biometrische Daten und Gerätefingerabdrücke. Die Aktualisierung von Anmeldeinformationen ist von entscheidender Bedeutung, da eine Kompromittierung sehr schwer zu erkennen ist und sie sich perfekt als Persistenz-Vektoren eignen.

Dieser komplexe Anwendungsfall liegt irgendwo zwischen IGA und Access Management, je nach den verwendeten Produkten und den getroffenen Entscheidungen. Das Zurücksetzen aller Passwörter hört sich einfach an – was es auch sein mag -, birgt aber einige Herausforderungen. Aber nichts, worauf man sich nicht vorbereiten könnte; eine Simulation (Trockenübung) ist hilfreich, um die größten Hindernisse aus dem Weg zu räumen. Wenn ein Angreifer jedoch ein paar Wochen Zeit hatte und Mimikatz verwendet, was für jede APT oder jeden orchestrierten Angriff Standard ist, ist dies wahrscheinlich unvermeidlich.

In diesem Anwendungsfall geht es in erster Linie darum, zu wissen, wo und wie. Natürlich sollten Sie mit der Bereitstellung von Kern- und zentralen Systemen beginnen, die Single Sign On bieten, wie Azure Active Directory und das traditionelle AD. Solange Ihr Netzwerk nicht riesig ist und von Latenz und Warteschlangen geplagt wird, ist die Durchführung des großen Reset machbar. Natürlich werden Sie verwirrte Benutzer haben und verwaiste und ruhende Konten finden, und der Helpdesk wird überflutet werden, aber das ist alles vorhersehbar.

Aber was ist mit nicht integrierten Plattformen? Häufig handelt es sich auch hier um privilegierte Konten, wie z. B. lokale Konten in der Linux-Schicht unter den Java-Servern oder die lokalen Administratorkonten auf Windows-Clients. Da sie nicht integriert sind, fallen sie aus Sicht der IT-Abteilung in der Regel nicht in den Anwendungsbereich. Da diese Konten bei Angreifern sehr beliebt sind, können sie aus der Sicherheitsperspektive für das Identitätsmanagement nicht außer Acht gelassen werden. Daraus ergibt sich der dritte Anwendungsfall von «Resilience meets Identity», und zwar ein wirklich schwieriger: die Verwaltung eigenständiger Konten.

Es sollte zumindest Transparenz herrschen, d. h. der Prozessverantwortliche sollte darüber informiert sein, wo sich solche Konten befinden. In Krisenzeiten ist es unabdingbar zu wissen, welche Konten manuell zurückgesetzt oder zumindest überwacht werden müssen (und wie).

Der schwierigste Teil dieses Anwendungsfalls ist die Verwaltung aller Peripheriekonten, einschließlich derjenigen, die von Mitarbeitern Dritter verwendet werden. Dazu gehören Konten in der Lieferkette (wie Kundensupportkonten bei IT-Anbietern und Voicemail – die sich als erfolgreicher Angriffsvektor erwiesen haben), SaaS-Konten (Github, ChatGPT usw.), einschließlich sozialer Medien und Konten, die als Schatten-IT gelten. Als letzte Kategorie sollten wir die privaten Konten von Administratoren und Entwicklern erwähnen, da diese selten wirklich getrennt sind. Ihre Workstations sind in der Regel eine Fundgrube für zwischengespeicherte Anmeldedaten und ein häufiger Ausgangspunkt für Sicherheitsverletzungen.

„Area Denial“ ist der Teil der Eindämmung von Sicherheitsverletzungen, bei dem es darum geht, interne Grenzen zu verschieben, Daten und Systeme abzuschotten und so hoffentlich eine Kompromittierung zu verhindern. Die Effektivität dieser Maßnahme hängt davon ab, wie gut Sie wissen, was der Angreifer tut und vorhat zu tun. Wenn Sie sich im blinden Bereich befinden, kann die Verweigerung dennoch nützlich sein, um die Gefährdung zu begrenzen, indem beispielsweise sensible Dateien ausgelagert werden oder der Zugriff auf Datenbanken unterbrochen wird. Dies kann mögliche zusätzliche Verluste verringern oder den Angreifer einfach nur frustrieren. Letzteres ist vielleicht nicht besonders nützlich, aber es kann den Angreifer dazu bringen, aufzugeben – oder zumindest wird sich das Verteidigungsteam dadurch besser fühlen.

Weniger einschneidend, aber bei einem größeren Vorfall möglicherweise wirksam ist die Verstärkung der Abwehrmaßnahmen durch die Erhöhung der Regeln für die Passwortkomplexität, die Senkung des Zählers für die Rücksetzung falscher Passworteingaben und/oder die Verkürzung der Gültigkeitsdauer des Passworts. Dies wird dazu beitragen, die Ausbreitung einer Sicherheitsverletzung einzudämmen, zumindest die Wiederherstellungskosten zu senken und möglicherweise die Ausfallzeiten zu verringern.

Die Durchsetzung dieser Maßnahmen ist jedoch wahrscheinlich nur in Unternehmenssystemen und möglicherweise in einigen Lieferketten machbar. Und da diese Änderungen große Auswirkungen haben können, können sie nur dann zuverlässig durchgeführt werden, wenn man darauf vorbereitet ist.

Es gibt noch mehr Dinge, die Sie tun können, Dinge, die Sie wahrscheinlich auch hätten tun können, wenn die Änderung genehmigt worden wäre. Um nur einige zu nennen

Dieser Anwendungsfall zielt im Wesentlichen darauf ab, die Berechtigungen zu reduzieren, und sollte Teil der Prävention sein – dennoch wird er dazu beitragen, laufende Sicherheitsverletzungen einzudämmen. Obwohl «Least Privilege» mindestens seit den späten 1970er Jahren ein Mantra in der Informationssicherheit ist, ist die Realität in vielen Netzwerken, dass gemeinsam genutzte Netzlaufwerke immer noch weit verbreitet sind und als so unverzichtbar für den täglichen Betrieb angesehen werden, dass sie in einem Lift-and-Shift-Ansatz in die Cloud verlagert werden.

Viel zu oft sind die Rechte für diese Freigaben auf praktisch jeden im Unternehmen festgelegt. Solche Dateifreigaben neigen dazu, im Laufe der Zeit eine Vielzahl von Dokumenten anzusammeln, darunter auch sensible Daten. Das Problem sind nicht nur Dateifreigaben, sondern alle Daten, die nicht zentral gespeichert und verwaltet werden, denn alles, was Sie über einen Browser öffnen, wird in Ihrem Download-Ordner gespeichert, und alles, was Sie drucken, wird auf der internen Festplatte des Druckers zwischengespeichert. Das sind alle MS-Office-Daten, E-Mail-Nachrichten, PDF-Dateien, aber auch so ziemlich alles, was Ihr Telefon in der Cloud sichert. Als regelmäßiger Nutzer haben Sie wahrscheinlich Zugang zu mehr Daten, als Sie vermuten würden, was mit KI-gesteuerten Chatbots wie CoPilot, der alle Daten anzeigt, die er für relevant hält und auf die Sie Zugriff haben, immer deutlicher wird. Erwarten Sie also, dass dieses Thema bald auftaucht.

In der realen Welt der Sicherheit sind unstrukturierte Daten tendenziell ein großer blinder Fleck: Es gibt keinen Eigentümer, kein quantifizierbares Risiko und keine einfache Lösung in Form eines allmächtigen Tools. Identitätsmanagement kann helfen, aber es gibt keine einfachen Lösungen oder schnellen Erfolge, so dass es oft eine niedrige Priorität erhält. «Big-Data-Experten schätzen, dass unstrukturierte Daten 90 % aller neuen Unternehmensdaten ausmachen. Dieser Trend zeigt, dass unstrukturierte Daten jedes Jahr um 55-65 % zunehmen – eine Rate, die dreimal schneller ist als das Wachstum strukturierter Daten.

Angreifer, insbesondere Ransomware-Angreifer, lieben unstrukturierte Daten, da sie sich viel leichter verschlüsseln lassen als eine Datenbank, die «in Gebrauch» ist und die Verschlüsselung verweigert. Das absolute Minimum ist das Entfernen von Rechten, die «Jedem» zugewiesen sind, mindestens aber den «authentifizierten» Benutzern. Die Gruppe «Authentifizierte Benutzer» umfasst alle Benutzer, deren Identitäten bei der Anmeldung authentifiziert wurden. Die Gruppe «Jeder» umfasst das integrierte Gastkonto und integrierte Sicherheitskonten wie SERVICE, LOCAL_SERVICE, NETWORK_SERVICE und andere. Auf diese Weise wird der Zugriff auf menschliche Benutzer beschränkt, wobei Angreifer in der Regel integrierte Konten bevorzugen, da diese eher unauffällig sind.

Und wenn Sie schon dabei sind – Dateifreigaben werden auch zum Ausführen von Anwendungen verwendet, als bequeme Möglichkeit, kleine Anwendungen, «portable» Versionen regulärer Anwendungen und/oder Schatten-IT auszuführen. Diese Eigenschaft wird häufig von Malware missbraucht, die sich in Ihren Netzwerken ausbreitet, und kann leicht durch Entfernen des ausführbaren Bits im Dateisystem überwunden werden. Beachten Sie, dass dadurch alle ausführbaren Dateien gestoppt werden und es sich um ein vererbtes Recht handelt, also probieren Sie es aus, bevor Sie es in größerem Umfang anwenden.

Zu diesem Thema kann – und muss – noch viel mehr gesagt werden, aber das würde den Rahmen dieses Dokuments sprengen.

Eine Grundvoraussetzung für ein ausgereiftes Identity Management-Stack ist die Abgleichsfunktion. Sie berechnet das Delta zwischen den Konten, die welche Berechtigungen haben (IST), und den Berechtigungen, die sie haben sollten (SOLL), wodurch Sie verwaiste Konten (vorübergehend) deaktivieren können, wodurch ein häufiger Dreh- und Angelpunkt bei Sicherheitsverletzungen und eine gängige Methode der Persistenz beseitigt wird.

AM-Systeme bieten Echtzeit-Zugang für die von IGA verwalteten Konten. AM ist der Ort, an dem sich die Passwörter befinden, und daher sind sie das wahrscheinlichste Ziel oder Sprungbrett für jeden Angriff. Daher müssen Sie zunächst sicherstellen, dass Sie über Hochverfügbarkeit und Disaster Recovery für AM verfügen. Wie der viel beachtete Fall von Maersk gezeigt hat, sollten Sie sicherstellen, dass Sie auch für jedes Verzeichnis wiederherstellbare Backups haben. Bedenken Sie, dass ein kompromittiertes System vielleicht noch funktioniert, aber nicht mehr für Sie; Sie brauchen eine Datenwiederherstellung von sauberen Daten, nicht nur eine Systemwiederherstellung.

Der erste Anwendungsfall, für den Sie AM-Funktionen einbauen sollten, wenn Sie belagert werden, ist die Durchsetzung strengerer Zugriffsrichtlinien – fügen Sie MFA-Faktoren hinzu und – wenn Sie über die entsprechende Technologie verfügen – die Verschärfung zusätzlicher Richtlinien, wenn Zugangskontrollen vorhanden sind (Plattformen, Patch-Levels usw.). Solche Funktionen sind oft die Produktmerkmale, die während des Implementierungsprojekts nicht ausgewählt wurden, aber sie könnten bei einem Angriff ein gutes Back-up sein. Eine flexible Konfiguration der Authentifizierung kann ein nützliches Instrument in Ihrem Cyber-Arsenal sein.

Der wichtigste Anwendungsfall für identitätsbasierte Ausfallsicherheit ist das Zurücksetzen aller Anmeldeinformationen (Passwörter, Geheimnisse wie SSH- und PKI-Schlüssel usw.), um ein mögliches erneutes Eindringen des Angreifers zu verhindern. Es gibt einen Vorbehalt: offene Sitzungen – auch bekannt als die Gültigkeit des Vertrauens. Kurz gesagt: Wie und wie oft überprüfen Sie eine Benutzersitzung? Und wie schließt man eine bestehende Sitzung, wenn etwas Verdächtiges auftaucht?

Dies ist der Bereich des Access Managements, der mittels Authentifizierung prüft, ob der Nutzer, der etwas anfordert, auch der ist, für den er sich ausgibt. Das gebräuchlichste Mittel ist die Abfrage von Benutzername und Kennwort, aber es gibt auch immer mehr Alternativen, wie z. B. «passwortlose» Verfahren, die sich auf gespeicherte geheime Schlüssel und PIN oder biometrische Daten stützen. Nach erfolgreicher Authentifizierung erhält der Kunde ein Zugangs-Token. Mit diesem Token ist der Zugang für einen bestimmten oder unbestimmten Zeitraum möglich, je nach Einsatz und Protokoll. Solange das Token gültig ist, ist der Client vertrauenswürdig. Wenn die Netzwerksitzung abläuft, reicht das Token aus, um eine neue Sitzung zu erhalten. Und das gilt auch für jeden anderen, der eine Kopie des Tokens hat – es ersetzt die echte Authentifizierung für die Dauer der Sitzung, die ewig dauern kann. Aus diesem Grund ist der Schutz des Session-Tokens von entscheidender Bedeutung, wie es die bewährte Sicherheitspraxis vorschreibt, indem es nicht auf einem Datenträger, sondern im Speicher des Clients gespeichert wird. Insbesondere wenn die Speicheradressen randomisiert sind, ist es schwierig, Schlüssel aus dem Speicher zu stehlen. Das bedeutet auch, dass, wenn eine Sitzung einen Neustart überlebt (d. h. Sie müssen sich nicht erneut anmelden), etwas auf der Festplatte gespeichert werden muss, was sie weniger sicher macht.

Die Erzwingung einer Revalidierung durch Begrenzung der Dauer der Validierung eines Clients zur Erhöhung der Sicherheit wäre machbar, ist aber nicht üblich. Wahrscheinlich, weil es benutzerunfreundlich ist, da sich der Benutzer oft neu authentifizieren müsste, was das Single Sign On Erlebnis stört. Wir opfern also etwas Sicherheit, und gestohlene Token sind eine große Sache.

Und nun zum großen «Reset»-Use Case. Sie werden versuchen, die Gültigkeit offener Sessions zu begrenzen, um sicherzustellen, dass nur legitime Benutzer und Systeme weiterhin Zugang haben. Leider lassen die meisten Session-Token-Mechanismen keine serverseitige Sitzungsbeendigung zu; nur der Client kann sich abmelden. So kann z. B. http, das am weitesten verbreitete Protokoll, eine User Session nur dann beenden, wenn es persistente Cookies verwendet, indem es die Verfallszeit ändert. Persistente Cookies sind Dateien, die auf der Festplatte gespeichert werden; eine Methode, die als unsicher gilt, da sie bei Diebstahl Zugriff auf die Nutzer-Session geben.  Dies erklärt, warum das Ändern des Passworts oder Schlüssels einer REST- oder SOAP-API nichts bewirkt – APIs melden sich nicht ab.

Ähnliche – aber andere – Vorbehalte gibt es bei Kerberos, dem anderen verbreiteten Protokoll, das von lokalen aktiven Verzeichnissen verwendet wird. Kerberos-Tickets, die nach erfolgreicher Authentifizierung empfangen werden, bleiben so lange gültig, wie sie als gültig angesehen werden, es gibt keinen Widerrufsmechanismus. Kerberos-basierte Dienste validieren die empfangenen Tickets «offline», ohne einen Domänen-Controller oder eine andere zentrale Instanz zu kontaktieren – solange das Ticket mit dem Schlüssel des Dienstes (keytab) entschlüsselt wird, gilt es als gültig. Es gibt keine Möglichkeit, Tickets zentral zu widerrufen, sobald sie ausgestellt wurden.

Das bedeutet, dass ein Benutzer, der nur ein «krbtgt»-Ticket besitzt, dieses am Domänen-Controller (KDC) «widerrufen» kann, indem das Benutzerkonto deaktiviert wird. Auf diese Weise weigert sich das KDC, weitere Tickets auszustellen. Wenn der Benutzer jedoch bereits Tickets für andere Dienste besitzt, bleiben diese Tickets gültig, und es obliegt den einzelnen Diensten, das Konto zu validieren, wenn sie dies wünschen. Das bedeutet, dass das Deaktivieren eines gehackten Kontos – oder das Ändern des Passworts oder das Reduzieren von Berechtigungen – den Angreifer nicht aussperrt.

Bei Diensten, die keinen zusätzlichen Autorisierungs-Server verwenden (z. B. APIs oder SSH-Hosts, die nur ein Ticket benötigen), haben Sie Pech – das Ticket bleibt so lange gültig, wie es gültig ist. Das ist in vielen Fällen unbegrenzt. Viel Glück also, wenn Sie den Angreifer loswerden wollen.

Selbst wenn die Tickets durch Ablauf ungültig werden, führt dies nicht zum sofortigen Abbruch der Sessions. Kerberos-authentifizierte RDP- oder SSH- Sessions können auf unbestimmte Zeit aktiv bleiben. RDP- und SSH- Sessions sind in der Regel privilegierte User Sessions – der bevorzugte Weg für Angreifer, sich an Ihren Systemen und Daten zu vergreifen. Kerberos-authentifiziertes Web SSO (http) bleibt ebenfalls aktiv, solange die SSO-Cookies gültig sind. Hacker haben gelernt, sich niemals abzumelden – eine Erkenntnis, die für Incident Responder von entscheidender Bedeutung ist. Wenn Sie dies ignorieren, sind Ihre Chancen, das Chaos zu beseitigen, minimal.

Dies gilt generell für jeden Authentifizierungsmechanismus, nicht nur für Kerberos. Wenn Sie sich beispielsweise per SSH mit einem Pubkey bei einem Server anmelden, bleibt Ihre Sitzung auch dann bestehen, wenn dieser Schlüssel später aus authorized_keys entfernt wird. Wenn Switches und Router neben der Kerberos-Authentifizierung zusätzliche Mittel wie RADIUS- oder TACACS-AAA-Server für die Autorisierung verwenden, und wenn sie mit einer Autorisierung pro Befehl über AAA eingerichtet sind (im Gegensatz zu einer einfachen Überprüfung bei der Anmeldung), dann werden sie die Sitzungen wahrscheinlich schließen, sobald der nächste Befehl ausgegeben wird und der AAA-Server sagt: «Das Konto scheint laut LDAP gesperrt zu sein». Andernfalls bleibt die Session offen, und die Angreifer können unbegrenzt weitermachen.

In der Regel ist die große Reset-Funktionalität in einer Standardkonfiguration nicht verfügbar, da Identitätssysteme nicht verpflichtet sind, diese Funktionen bereitzustellen. Das heißt aber nicht, dass nichts getan werden kann – zu wissen, was möglich ist und was nicht, ist von entscheidender Bedeutung, insbesondere bei einem Einbruch. Zero Trust lehrt die Bedeutung von «never trust, always verify», doch wir sehen hier, dass beim Thema der Dauer von «Validated Trust» noch eine Menge wichtiger Arbeit zu leisten ist, die häufig übersehen wird.

PAM ist die Absicherung der Nutzung von Accounts mit höheren Privilegien, den Berechtigungen zum Ändern von Rechten, die Benutzer haben – einschließlich seiner eigenen. Dies sind Administratoren- und Root-Konten sowie deren Äquivalente. Für einen erfolgreichen Angreifer sind sie unerlässlich, um sich lateral durch ein Netzwerk zu bewegen. Privilegierte Konten sind daher die häufigsten Ziele, und der Einsatz einer PAM-Lösung zentralisiert das, was Sie verteidigen, wodurch Sie einen besseren Überblick erhalten und leichter reagieren können. Sie bietet Ihnen die Möglichkeit, an einer Stelle die Logging-Ebenen zu erhöhen und alle Benutzersitzungen zurückzusetzen (anstatt auf jedem Host einzeln!), sie bietet die Funktionalität, Admin-Sitzungen aufzuzeichnen und einen einzigen Weg, um privilegierte Notfall-Accounts für zusätzliche Support-Mitarbeiter zu erstellen. Dies alles sind Vorteile des PAM-Konzepts, aber kaum das, was man im Falle eines vermuteten Angriffs tut.

Die erste Maßnahme, die Sie mit PAM ergreifen sollten, ist ein globales Zurücksetzen der lokalen Administratorkennwörter und ein Entfernen zusätzlicher lokaler Accounts. Dies ist wahrscheinlich eine Mischung aus IGA-, AM- und PAM-Tools, so dass es sich lohnt, sich vorzubereiten und sogar Probeläufe durchzuführen.

Je nach Tool und Einsatzgebiet stehen Ihnen weitere Funktionen zur Verfügung, die bei der Abwehr eines Angriffs sehr nützlich sein können:

• Zurücksetzen von Service-Accounts (NPAs) mit privilegiertem Zugriff
• Einrichten eines Freigabeworkflow für hochprivilegierte Aktionen, Aktivieren von (strengeren) Freigabeabläufen/ Business Justification Controls (Integration mit ITSM) (für PASM, PEDM, Lieferantenzugang)
• Minimierung der Anzahl der Assets, für die Accounts verwendet werden können
• Einführung neuer privilegierter Konten für bestimmte rollenbasierte Aktivitäten/Assets (Segmentierung)
• Nutzung von PAM-spezifischen Threat-Analysen, die auf integrierten Hosts verfügbar sind
  • Erkennung von ungewöhnlichen Logins, Aktivitäten in Sessions, Zugriff auf Assets ohne Verwendung von PAM, Golden Tickets / PTH-Angriffe
  • Auflistung aller jüngsten Privilegienerweiterungen (UAV-Umgehungen, Token-Impersonation & Diebstahl u.a.)
• Strengere RBAC- und PoLP-basierte privilegierte Konten
• Ersetzen von Konten mit ständigem Zugang durch ephemere Konten

Verschlüsselung ist die am weitesten verbreitete Technologie für Schutz und Vertrauen und als solche das Herzstück der Cybersicherheit. Trotz ihrer weiten Verbreitung wird sie im Allgemeinen übersehen und nur selten aktiv verwaltet oder in Risikoanalysen berücksichtigt. Die öffentliche PKI ist der Anker der Sicherheit für den Public Namespace, was im Zeitalter der Cloud bedeutet, dass Ihre gesamte Sicherheit davon abhängt. Das bedeutet, dass Sie alle Ihre Daten, Anwendungen und die Kontrolle über Ihre Geräte – IT, OT und IoT – verlieren können.

Wirklich?

Das ist der schlimmste Fall, kann aber durchaus passieren. Lassen Sie uns das genauer untersuchen. Um sich bei der Cloud anzumelden und Ihren Tenant zu verwalten, meldet sich Ihr Administrator mit seiner E-Mail-Adresse an. Dieser Benutzer-Account ist für den Benutzer-Service, wie z. B. die Geräteanmeldung, die MFA-Einrichtung und die Abläufe bei vergessenen Passwörtern, auf E-Mail angewiesen. Die im DNS-Eintrag festgelegte Identität des E-Mail-Servers ist durch ein von einer vertrauenswürdigen Zertifizierungsstelle bereitgestelltes Zertifikat «gesichert». Wenn dieses Zertifikat kompromittiert wird, ist auch der Account, der Ihre Cloud kontrolliert, gefährdet, da er die Kontrolle über alle E-Mails an den Angreifer weitergibt, einschließlich der Passwortwiederherstellung. Dadurch könnte der Angreifer die Kontrolle über das Konto erlangen, das Ihre Cloud verwaltet.

Das heißt, wenn Sie «alles» in die Cloud stellen und Ihr öffentlicher Zertifikatsanbieter kompromittiert wird, können Sie alles verlieren; dar Root Account Ihres Mandanten ist ein SPOF (single point of failure) in der Lieferkette. Natürlich gibt es noch einige weitere Schritte für den Angriff, aber so einfach könnte es sein. Aus diesem Grund hat der EU-Gesetzgeber sowohl den DNS-Anbietern als auch den Zertifizierungsstellen große Aufmerksamkeit geschenkt. Aber das wird Kompromisse nicht verhindern; bestenfalls macht es eine fragile Position etwas weniger angreifbar. Und jeder sollte seinen Teil dazu beitragen, nicht nur die Regierung und die DNS- und PKI-Unternehmen.

PKI und Cyber Resilience bedeutet also, den Use Case so vorzubereiten, dass man auf die Kompromittierung einer Public CA vorbereitet ist. In Anbetracht der Tatsache, dass NIS2 diese Themen ausdrücklich erwähnt, wäre dies der beste Ansatzpunkt. Weitere Anwendungsfälle, die berücksichtigt werden sollten, sind:

• Root-Kompromittierung von externen Vertrauensankern
  • Wechsel zu einem anderen Anbieter
• Root-Kompromittierung von internen Vertrauensankern
  • Zurücksetzen des CA Trust für DNS
  • Zurücksetzen des CA Trusts für Code Signing
  • Zurücksetzen des CA-Vertrauens für Deep Packet Inspection
• (Alle) Benutzerschlüssel widerrufen
  • Notfall-Neuausstellung von PKI-Schlüsseln
    • MDM / AD / AAD
    • TLS/DNS (DANE)
    • X802.1x
    • S/MIME
    • DLP
    • Code-Signierung
    • SSH-Schlüssel

Dieser Post hilft Ihnen hoffentlich, dieses riesige und meist unerforschte Gebiet zu verstehen. Um Cyber-Resilienz zu erreichen ist es eine gute Idee, Hilfe für Ihre Identity-Systeme durch Spezialisten in Anspruch zu nehmen. Führen Sie zumindest einen Workshop durch. Und wenn Sie Unterstützung brauchen, sind wir für Sie da. Rufen Sie uns an oder mailen Sie uns.

Resilienz bezeichnet die Fähigkeit einer kritischen Entität, einem Vorfall vorzubeugen, sich dagegen zu schützen, darauf zu reagieren, ihm zu widerstehen, ihn abzumildern, ihn zu absorbieren, zu bewältigen und sich davon zu erholen.

Wie der Überblick über die neuen Rechtsvorschriften zu Themen der Cybersicherheit in der EU deutlich zeigt, fordern die Regulierungsbehörden mehr Aufmerksamkeit für die Krisenbewältigung. Damit soll das Gleichgewicht in der Sicherheitspraxis wiederhergestellt werden, die sich in erster Linie auf die Prävention konzentriert und die Reaktion vernachlässigt hat. Die Bemühungen sind Teil einer umfassenderen Entwicklung, wie wir sie auch beim amerikanischen NIST-Rahmenwerk beobachten können (siehe unten). Die neue Version, die 2.0, wird 2024 fertiggestellt und formalisiert.

Wenn Sie das NIST-Bild aufzeichnen, was im Bereich der Cyberverteidigung üblicherweise getan wird, werden Sie feststellen, dass der größte Teil der Industrie, des Budgets und der Aufmerksamkeit auf den Bereich «Protect» gerichtet ist, in dem präventive Tools angesiedelt sind. Das ist unausgewogen. Der Gesetzgeber fordert mehr Aufmerksamkeit auf Identify, Incident Response und Recovery. Die andere auffällige Ähnlichkeit ist die Aufmerksamkeit für die Lieferkette, sowohl in NIS2 als auch in NIST 2.0. Dies wird wahrscheinlich zu einer tektonischen Verschiebung in den Zuständigkeitsbereichen führen und die Verantwortung für Cybersicherheit von der traditionellen IT-Abteilung weg verlagern.

Dies ist ein aktueller Strategiewechsel – der Gamechanger ist die harte und teure Lektion von Ransomware, dass, sobald die Prävention umgangen wird, die Reaktionsfähigkeiten (Response) sich als weitgehend unterentwickelt erweisen und sich Vorfälle unnötigerweise zu ausgewachsenen Katastrophen entwickeln.

Dieses strukturelle Ungleichgewicht ist ein logisches, aber unbeabsichtigtes Ergebnis des risikobasierten Ansatzes, bei dem der Schwerpunkt auf der Identifizierung von Risiken im Zusammenhang mit bekannten Werten liegt, bevor eine spezielle Reaktion festgelegt wird. Dies führt dazu, dass unwahrscheinliche Risiken übersehen werden, die Lieferkette vergessen wird und es zu einer Voreingenommenheit gegenüber der Prävention und einer Zersplitterung der Bemühungen durch punktuelle Lösungen kommt.

Im Finanzrisikomanagement wird dies als » Black Swan-Effekt» bezeichnet, der dazu führt, dass Unternehmen auf unvorhergesehene Ereignisse oder sogar auf eine Kombination von erwartbaren Ereignissen zur gleichen Zeit nicht vorbereitet sind. Mit NIST 2.0 in den USA und NIS2 in der EU (und dem derzeit in Vorbereitung befindlichen Nachfolgeprojekt) fordern die Gesetzgeber nicht, dass man bei der Prävention nachlässt oder die risikobasierte Vorgehensweise vergisst, aber sie fordern mehr Ausgewogenheit. Daher lenkt er die Aufmerksamkeit auf die Reaktion auf Vorfälle (incident response), die Kommunikation und die Krisenbewältigung – in Zusammenarbeit mit der Lieferkette und den Behörden. Themen, die für die Cyber-Resilienz von zentraler Bedeutung sind.

Incident Response ist das, was Organisationen tun, wenn etwas schiefläuft. Feuerwehrleute löschen Brände, Sanitäter versorgen Verletzte, Soldaten schießen auf den Feind – vorbereitete und organisierte Reaktionen von spezialisierten und benannten Personen, den Incident Responders. Auch im Bereich der Cybersicherheit gibt es Vorfälle, die sich zu ausgewachsenen Katastrophen entwickeln können, wenn sie unbeachtet bleiben. Deshalb gibt es CSIRTs, Computer Security Incident Response Teams für Cyber-Vorfälle. Besser gesagt, viele Unternehmen behaupten, sie hätten «CSIRT-Fähigkeiten», da sie ein Security Operating Centre haben. Oder sie haben die IT an einen Anbieter ausgelagert, der über ein SOC verfügt. Oder es handelt sich um einen virtuellen Prozess eines virtuellen Teams, das der IT untersteht. Oft ist der IT-Helpdesk in der Praxis das CSIRT, während sich der Rest in der Semantik und der Büropolitik verliert. Die meisten Unternehmen haben kein CSIRT und tun sich schwer, die «Gleichwertigkeit» dessen, was sie haben, zu erklären.

Der Begriff «Incident Response» ist für die Cybersicherheit vielleicht auch nicht die glücklichste Wahl, da es im IT-Support einen Prozess gibt, der fast den gleichen Namen trägt – Incident Management – mit einer marginalen und meist optischen Überschneidung. Dies führt häufig dazu, dass die IT-Abteilung in einen Topf geworfen wird und für den großen Bereich der Business Resilience verantwortlich gemacht wird, für den sie eigentlich gar nicht gerüstet ist.

Wesentlich für ein gutes Verständnis von NIS2 ist, dass die in diesem Gesetz geforderten Maßnahmen zum Management von Cybersecurity-Risiken auf einem «All-Hazard-Ansatz» zur Reaktion auf Vorfälle beruhen sollten und nicht auf identifizierbare IT-Vorfälle innerhalb der eigenen IT-Infrastruktur beschränkt sind: «Die von der Einrichtung ergriffenen Maßnahmen des Cybersicherheitsrisikomanagements sollten nicht nur die Netz- und Informationssysteme der Einrichtung, sondern auch die physische Umgebung dieser Systeme vor Ereignissen wie Sabotage, Diebstahl, Brand, Überschwemmung, Telekommunikations- oder Stromausfällen oder unbefugtem physischen Zugriff schützen, die die Verfügbarkeit, Authentizität, Integrität oder Vertraulichkeit gespeicherter, übermittelter oder verarbeiteter Daten oder der von Netz- und Informationssystemen angebotenen oder über diese Systeme zugänglichen Dienste beeinträchtigen können».

Wenn man darüber nachdenkt, hat eine Organisation, die auf die Bewältigung von Vorfällen wie dem Tonermangel eines Druckers zugeschnitten ist, nur wenig mit dem gemein, was Sie für den Umgang mit einem ausgewachsenen Ransomware-Angriff oder einem Brand im Rechenzentrum Ihres Cloud-Anbieters benötigen.

Wir haben es hier mit einem Thema zu tun, das manche als «War Room» bezeichnen; ein Ausnahmezustand, bei dem alle Mann an Deck sein müssen. Der Begriff fasst die Relevanz, die Dringlichkeit und die chaotische Natur dieses Themas treffend zusammen. Der War Room ist das Herzstück von NIS2; wir müssen aus dem IT-Sicherheitsbereich in die reale Welt heraustreten und den Beschränkungen des Paradigmas der Cyberverteidigung entkommen.

Wie oben in der Übersicht über die Reaktion auf Vorfälle ersichtlich, gibt es drei Hauptgruppen von Prozessen, die kohärent funktionieren sollten, um eine Chance auf Erfolg zu haben:

• Erkennen (detect) – die Prozesse und Akteure, die als Stolperdraht fungieren und Sie alarmieren, wenn etwas vor sich geht. Hier ist die Cybersicherheit in der Regel angesiedelt, entweder als internes SOC (Security Operating Center) oder bei einem Managed Security Provider als Outsourcing-Partner. Da alle Arten von Störungen in den Anwendungsbereich der NIS2 fallen, nicht nur solche, die als Cyber- oder IT-Störungen betrachtet werden, muss das, was heute vorhanden ist, wahrscheinlich neu geplant und gestaltet werden.
• Handeln – das eigentliche Krisenmanagement; kontinuierliche Analyse alias Triage (im Wesentlichen Risikobewertung dessen, was vermutlich vor sich geht, und Abwägung der Reaktionsmöglichkeiten), Forensik, Geschäftskontinuität und Eindämmung und Beseitigung von Angreifern. Dies ist der Bereich des Blue Teams, der IT-Ingenieure, die den Sicherheitsanalysten erklären, was die Systeme tun und wie sie funktionieren (um zu entscheiden, was zu tun ist), die Dinge im Handumdrehen reparieren und Daten und Systeme verschieben – harte Arbeit, die allzu häufig übersehen und unterbewertet wird. Sie ist auch nicht in einer Dienstleistungsvereinbarung geregelt. Dies ist die Fähigkeit, die im Allgemeinen durch Outsourcing und technische Tiefe am schwächsten ist – eine Grenzlinie zu verteidigen, die man kennt, ist viel einfacher als eine, die man nicht kennt. Hier geht es darum, den Heimvorteil zu haben – oder eben nicht.
• Kommunizieren – Stakeholder und Shareholder auf dem Laufenden halten und schwierige Fragen beantworten, ein weiterer unterentwickelter Teil, der in der NIS2 hervorgehoben wird. Es ist verpflichtend, die Behörden, die Kunden und die Lieferketten zu informieren. Hier werden harte Fragen gestellt werden – alles geheim zu halten ist keine Option mehr.

Dieses Post hat nicht den Anspruch, ein vollständiges Bild der Reaktion auf Cybervorfälle zu zeichnen, denn das würde ein ganzes Buch füllen. Es dient jedoch als Hintergrund für den kommenden Post, in dem es um die Überschneidungen mit den Themen und Möglichkeiten des Identitätsmanagements geht und darum, wie Sie diese nutzen können, um Ihre Erfolgschancen in der nächsten Cyber-Krise zu verbessern.

Das Schwierigste bei Cyber-Vorfällen ist nicht die Erkennung (detection), sondern die Erkenntnis, dass die Erkennung schwierig ist und die Tools nur sehr begrenzt einsetzbar sind. Wie von IBM berichtet, entdeckte nur ein Drittel der Unternehmen Datenschutzverletzung durch ihre eigenen Sicherheitsteams, erstaunliche 67 % der Verstöße wurden von einer gutartigen dritten Partei oder von den Angreifern selbst gemeldet. Es unmöglich zu sagen, wie viele Unternehmen völlig unbemerkt angegriffen und kompromittiert wurden, und wir wissen aus anekdotischen Beweisen (APT1, Sellafield, Buckshot Yankee), dass Verstöße jahrelang andauern können; daraus müssen wir schließen, dass die Erkennung in den meisten Fällen fehlschlägt und dass der Gesetzgeber mit seiner Forderung nach einer effektiveren Incident Response Recht hat.

Noch schwieriger ist es, angemessen zu reagieren und zu wissen, wie und wann die Sicherheitsverletzung beendet ist. Wie und wann kann man das Vertrauen wiederherstellen und sagen, dass der Geschäftsbetrieb wieder sicher ist, wenn man nur unvollständige und indirekte – und wahrscheinlich zweideutige – Informationen über das Ausmaß und die Mittel der Sicherheitsverletzung hat? Die zentrale Herausforderung besteht darin, wie ein Angreifer abgewehrt werden kann, einschließlich aller Arten von möglichen «Persistenzen» (Hintertüren), die in dem riesigen Heuhaufen Ihrer Infrastruktur versteckt sind. Vor allem, wenn man bedenkt, dass man wahrscheinlich nicht weiß, wie lange der Angriff andauerte und wie groß der Heuhaufen ist. Häufig gehen die Opfer von Sicherheitsverletzungen davon aus, dass die Angriffe «vorbei» sind, wenn kein verdächtiges Verhalten mehr beobachtet wird.  Da Sie beim ersten Einbruch praktisch blind waren, bedeutet dies ein großes Maß an blindem Vertrauen; Sie sollten zumindest nach Wegen suchen, die ein Angreifer möglicherweise geschaffen hat. In der Cybersicherheit wird dies als Persistenz bezeichnet.

Häufige Vektoren für Persistenz sind Malware, ungeschützte Zugangspunkte, erhöhte Berechtigungen für normalerweise harmlose Accounts und kompromittierte Anmeldeinformationen, vorzugsweise von der nicht rotierenden Art, wie Systemkonten, dauerhafte Cookies, API- und SSH-Schlüssel und nicht zuletzt PKI-Zertifikate. Die drei letztgenannten Arten von Anmeldeinformationen sind nur allzu häufig in Code-Repositories in der Cloud gespeichert – Github ist voll davon.

Eine besondere Erwähnung verdient die Kategorie der externen Konten wie LinkedIn und Github, bei denen die Mitarbeiter die E-Mail-Adresse des Unternehmens als Benutzernamen verwenden und somit zur Wiederverwendung von Passwörtern verleitet werden, wodurch das Unternehmen Credential Stuffing-Angriffen ausgesetzt ist. Credential Stuffing ist laut OWASP eine der am häufigsten verwendeten Techniken, um Benutzerkonten zu übernehmen.

Auf dieser Grundlage sollte der Wiederherstellungsansatz aus vier Komponenten bestehen: Forensik, Anti-Malware-Tools, Wiederherstellung von Backups, die bekanntermaßen sauber sind, oder Neuaufbau von Grund auf sowie Identitätsmanagementsysteme.

Ein Blick auf das Diagramm macht deutlich, dass eine Ad-hoc-Reaktion nur bedingt erfolgreich sein wird und auch nicht sehr schnell erfolgen kann.

Um eine Chance auf eine rasche Wiederherstellung zu haben, können diese Fähigkeiten nicht unter Zwang improvisiert werden, sondern sollten im Voraus aufgebaut und durch Schulungen und Wissen (einschließlich Partnern) unterstützt werden.

Aber … haben wir das nicht schon, mit unserer Best-of-Breed-IAM-Lösung?

Das ist nicht sehr wahrscheinlich.

Identitätsmanagement-Prozesse und -Systeme sind nur selten für die Wiederherstellung bei Sicherheitsverletzungen ausgelegt – schauen Sie sich die Anwendungsfälle an, und Sie werden feststellen, dass Identitätsmanagement und Incident Response nur selten zusammenkommen. Die Tools, die umfangreiche Literatur, in der bewährte IAM-Verfahren beschrieben werden, und die seit langem etablierten Standards sollten dies abdecken. Das ist kaum der Fall.

Dabei sind sie von grundlegender Bedeutung für den Erfolg. Bedenken Sie, dass die IAM-Systeme auch der Hauptangriffsvektor und der Dreh- und Angelpunkt in den späteren Phasen eines Einbruchs sind, wenn die Privilegien des Angreifers zu Root-Rechten erweitert werden, da Konten die Schlüssel zum Königreich sind. In der Literatur zum Thema Identitätsmanagement wird dieses Thema im Allgemeinen völlig außer Acht gelassen. Dies ist eine große Lücke in der Cyberabwehr. Um diese Lücke zu schließen, werden im nächsten Kapitel die Anwendungsfälle aufgelistet, die in einer Cyber-Krise relevant sein könnten. Mit diesen Informationen sollte der IAM-Prozessverantwortliche in der Lage sein, die von NIS2 angestoßene Phase der Cyber Resilience mit Zuversicht zu betreten.

Kryptografie gilt normalerweise nicht als „sexy“ Thema im komplexen Bereich der Cybersicherheit. Wenn Kryptografie in einer IT-Sicherheits-Roadmap auftaucht, ist sie oft nur ein Kästchen, das abgehakt werden muss; ein Hinweis im Rahmen eines Audits oder ein überfälliges Update für eine Komponente, die nicht zu einem früheren Standard „zurückfallen“ soll. Und immer häufiger stoßen wir in der Cloud auf etwas, das einfach nicht funktionieren will, wenn man die Kryptografie unberücksichtigt lässt. Dieser Fall scheint immer häufiger aufzutreten, und wenn man das Problem heute aufschiebt, wird es nicht verschwinden. Dieses Thema bereitet in allen Ecken der Sicherheitswelt viel Kopfzerbrechen, was zum Teil auf verwirrende Vorschriften und unverständliche technische Anweisungen zurückzuführen ist. Es ist immer eine lästige Pflicht, ohne offensichtlichen Mehrwert, was es nicht einfacher macht, Entscheidungsträger zu überzeugen, dafür Geld locker zu machen.

Das Lamento der Sicherheitsexperten ist meist berechtigt. Aber… Wenn man bedenkt, dass fast jedes moderne Sicherheitsprodukt eine Menge Kryptografie unter der Haube hat – mit all der Komplexität, die das mit sich bringt – dann ist es nur logisch, dass das Thema immer wieder auftaucht. Und jetzt, wo Sie Ihre Infrastruktur in die Cloud verlagert haben, können Sie nicht einfach etwas Unzureichendes zusammenschustern – oder die Kryptografie ganz weglassen, wie früher. Es ist noch gar nicht so lange her, dass Unternehmen Verschlüsselung in ihrem eigenen Netzwerk „aus Sicherheitsgründen“ verboten haben. Bis zum Jahr 2015 war das fast schon gängige Praxis. Der Gedanke hält sich bis heute in einigen Köpfen, denn Verschlüsselung macht eine Überprüfung unmöglich. Das war’s dann mit Ihrem Virenschutz und Ihrer Intrusion Protection.

Es ist ein kompliziertes Puzzle, und wenn man denkt, dass man fertig ist, bleiben immer noch einige Teile übrig. Das Thema ist so universell, dass man es fast als lebenswichtige Technologie bezeichnen kann. Das bedeutet, dass die Kenntnis und Beherrschung der Kryptografie für eine wirksame Sicherheit unerlässlich ist.

Im Bereich der Computersicherheit ist die Kryptographie de facto eines der wichtigsten Themen, weil sie an so vielen Stellen unter der Oberfläche schlummert, es aber nur wenige Organisationen gibt, die ihr einen ausdrücklichen administrativen Verantwortlichen zuweisen. Die Zuständigkeit wird daher häufig zwischen Sicherheit und IT verlagert. Das führt zu Reibung und Trägheit, und die Dinge beginnen zu scheitern.

In Anbetracht dessen ist es jetzt an der Zeit, dass wir alle diese bittere Pille schlucken und uns in das Thema vertiefen.

Was wir dabei beobachten, sind die Nebeneffekte von drei grundlegenden Entwicklungen:

1. Upscaling: Die Zahl der Anwendungsgebiete von Kryptografie nimmt aufgrund von Zero Trust und der Ausweitung von mobilem Arbeiten, Telearbeit und der Cloud ständig zu; Daten, die außerhalb der eigenen Infrastruktur gespeichert werden, müssen für die Speicherung und den Transport verschlüsselt werden (in unserem typischen Fachjargon: Deperimiterisation). Gleichzeitig sind kryptografische Schlüssel für immer kürzere Zeiträume gültig, was eine häufiger erfolgende Rotation und andere Wartungsarbeiten erforderlich macht, allein schon aus Gründen der Verfügbarkeit. Diese wachsende Bedeutung hat dazu geführt, dass das Thema für die Aufsichtsbehörden (und damit für Compliance-Verpflichtungen wie NIS2 und DORA) und für die betriebliche IT (gezwungen durch Störungen und Migrationen) unausweichlich geworden ist.
2. Verlagerung der Sicherheit von der Netz- und Infrastrukturebene (Anwendungen, Verzeichnisse, RBAC, Firewalls und Proxys) zunehmend auf die Datenebene (Speicherung und Transport). Dieser Prozess beschleunigt sich, weil ein größerer Teil der Daten in separaten Ordnern gespeichert wird, anstatt in einer logischen Sammlung in Anwendungen und Datenbanken. Da wir nicht genau wissen, was und/oder wo diese „unstrukturierten“ Daten liegen (und somit die Risiken nicht quantifizieren können), müssen wir die allgemeinen Sicherheitsnetze verstärken: Wir verschlüsseln die Speicherorte der Daten („data at rest“, oder das Dateisystem) und die Orte, durch die sie sich bewegen (das Netz, oder „data in transit“). Noch mehr Komplexität.Die Sicherheitsindustrie verspricht auch eine zukunftsweisende Verschlüsselung von „Data in Use“, manchmal in Kombination mit einer Verschlüsselung auf der Ebene der einzelnen Datei; in DLP, Kapselungen und vor allem der „Sovereign Cloud“ – um ausländische Geheimdienste und Big Tech davon abzuhalten, uns auszuspionieren. Sie sprechen auch gerne über C2PA – eine neue Kryptotechnik zum Nachweis der Authentizität digitaler Inhalte; eine logische Lösung in Zeiten von Deepfakes und KI-Desinformation. Das klingt kompliziert und ist es auch: Es garantiert zusätzliche Komplexität, die Ihr Unternehmen bewältigen muss.
3. Überfällige Wartung. Wir durchlaufen derzeit den Übergang von der ersten Generation der Kryptotechnologie (ab etwa 2000) zur Einführung der zweiten Generation (ab etwa 2015, jedoch bei weitem heute noch nicht abgeschlossen). Der Übergang geht langsam vonstatten, weil er äußerst anspruchsvoll ist, und wir beginnen bereits mit den ersten Migrationen zur dritten Generation der Kryptotechnik. Bei dieser dritten Generation geht es vor allem um kurzlebige Kryptoschlüssel und modernere „Post-Quantum“-Algorithmen. Apropos kompliziert: Der sich abzeichnende Durchbruch von Quantencomputern macht es möglich, die Schlüssel für ältere Algorithmen zu knacken, so dass wir im Grunde alles, was wir heute verwenden, durch die neue Post-Quantum-Kryptografie ersetzen müssen.

Oh Mann.

Noch nicht jeder ist zu der Einsicht gelangt, dass das Management und das Beherrschen von Kryptographie („Krypto-Transparenz“) eine absolute Notwendigkeit für jede sinnvolle kryptographische Anwendung im Sicherheitsbereich ist. Um es ganz klar zu sagen: Wenn man die Kryptographie falsch einsetzt, ist die Sicherheit der eigenen Projekte wahrscheinlich nicht mehr gewährleistet. Sie wird oft als eine wartungsarme Technologie dargestellt, insbesondere von den Tool-Verkäufern. Aber die Sicherheit, die sie bietet, ist in Wirklichkeit das Ergebnis des sicheren Umgangs mit Keys und der richtigen Organisation von Prozessen und Systemen. In dem Maße, in dem der Umfang zunimmt und immer breitere Anwendung findet, ist ein gründliches Verständnis der Technologie von entscheidender Bedeutung. Und das erfordert ein kreatives und spezialisiertes Team, das Improvisationen beherrscht. Leider haben nur die wirklich großen Unternehmen die nötige Kapazität, um dies zu bewältigen. Der Rest muss mit einem Langzeitanbieter zusammenarbeiten, der über ein solches Team verfügt.

Dies ist der wichtigste Faktor, der unseren Kryptodienstleistungen zugrunde liegt: Wir sind ein Sparringspartner für Innovation und Wachstum, mit einer klaren und vertrauten Prozessorganisation, gestützt durch eine geeignete Prozessautomatisierung.

Um die Kryptographie in einer Organisation in den Griff zu bekommen, ist ein struktureller Ansatz erforderlich. Unserer Erfahrung nach besteht dieser Ansatz aus Discovery, Onboarding (Übernahme der Kontrolle) und Governance (gutes Management).

Ohne Einblick in die Bereiche, in denen Sie Verschlüsselung einsetzen (und in denen Sie dies noch nicht tun, aber tun sollten), werden Sie nicht in der Lage sein, eine angemessene, zeitgemäße Sicherheit zu erreichen, geschweige denn aufrechtzuerhalten. Discovery ist ein hybrider Prozess zwischen einem technischen Scan Ihres eigenen Netzes, der Abfrage maßgeschneiderter Internetdienste (die von der OSINT-Welt bereitgestellt werden), der Befragung von IT-Spezialisten und Lieferanten sowie der Analyse von Designs. Discovery hilft Ihnen dabei, Folgendes zu ermitteln:

• Wo Sie Verschlüsselung verwenden – und wie
• Wo Sie keine Verschlüsselung verwenden, dies aber auf der Grundlage Ihrer Sicherheitsrichtlinien und Architekturprinzipien tun sollten

Das Wort „Orchestration“ bei einem SIEM/SOAR kommt nicht von Ungefähr: In einem Orchester arbeiten viele verschiedene Instrumente harmonisch zusammen, um ein beeindruckendes musikalisches Werk zu schaffen. Ähnlich verhält es sich mit der Orchestrierung in der IT-Sicherheit: Hier koordiniert Sentinel die Daten eines SIEM, reagiert per SOAR automatisch darauf und sorgt per Defender sofort für die Gefahrenbeseitigung. Jedes Tool kennt seinen Part und setzt zum richtigen Zeitpunkt an. Und das funktioniert wie folgt:

• Zentralisierte Datenerfassung: Sentinel aggregiert mit SIEM-Funktionen sämtliche Daten (nicht nur Sicherheitsdaten) aus einer Vielzahl von Quellen – von Endpunkten über Cloud-Dienste bis hin zu Log-Dateien von Anwendungen. Beispielsweise überwacht das Microsoft SIEM Anmeldedaten über verschiedene Plattformen hinweg, um ungewöhnliche Zugriffsversuche, die etwa auf Credential Stuffing hindeuten könnten, frühzeitig zu erkennen.
• KI-basierte Erkennungsalgorithmen: Durch die Einbindung von Defender XDR profitiert das Sentinel SIEM von fortgeschrittenen Erkennungsmechanismen, die auf KI und maschinellem Lernen basieren. So identifiziert und priorisiert Sentinel automatisch komplexe Angriffsketten, die herkömmliche Erkennungsmethoden umgehen könnten.

Onboarding umfasst die verschiedenen Schritte, die Sie auf der Grundlage der Erkenntnisse aus der Discovery ergreifen. Je nachdem, was Sie feststellen, kann dies die Registrierung (im Asset Management), die Einbindung in die Monitoring- und Kontinuitätsplanung, das Einleiten von Optimierungsmaßnahmen oder das Hinzufügen von Verschlüsselungsmaßnahmen umfassen – alles Schritte, die auch zum Security Management gehören. Onboarding besteht aus den folgenden Schritten:

1. Aufnahme in das Asset-Inventar – die CMDB, mit dem Status (in use/in management ( oder nicht) /sollte Verschlüsselung verwenden, tut es aber nicht (oder verwendet sie falsch), plus das Datum der Einbindung.
2. Eingabe der Basisdaten.
3. Der Budget-Owner: Wer zahlt?
   1. Der verantwortliche Administrator (und die Organisation): Wer betreut?
   2. Die Funktion des Systems („landscape“): wer und was verwendet es??
4. Abschluss der Verwaltung und Behebung von Schwachstellen.
   1. Behebung von Fehlern und Mängeln
   2. Monitoring und regelmäßige Inspektionen
   3. Automatisieren, wo dies rentabel und machbar ist
   4. Kostenverteilung

Im Idealfall bräuchte man Discovery nicht, da die korrekte Organisation der Nutzung kryptografischer Ressourcen in den Erstellungsprozess der IT-Tools eingebettet ist. Aber in der realen Welt … ist das normalerweise nicht der Fall. Und genau deshalb brauchen Sie Discovery.

In größeren Unternehmen führt angesichts des raschen Anstiegs der Arbeitsbelastung kein Weg daran vorbei, auch kurzfristig einen Factory-Line-Ansatz zu verfolgen. Bei der Optimierung dieses Prozesses gilt es, keine Zeit zu verlieren. Die Festlegung eines Standards für das Onboarding ist ein guter Anfang.

In den Turbulenzen der heutigen Technologie ist es das Wichtigste, für die Kundenorganisation relevant zu bleiben, indem geeignete Produkte, robuste Dienstleistungen und die richtige zukunftssichere Supportleistungen angeboten werden. Der Begriff dafür lautet heute „Krypto-Agilität“: die Fähigkeit, durch Antizipation, Planung und Expertise am Puls der neuen Entwicklungen zu bleiben.

Um Kryptografie in den Griff zu bekommen – und zu behalten – sind alle Serviceebenen gefragt:

Die gängigsten PKI- Betreiber haben sowohl interne als auch öffentliche Zertifizierungsstellen (CAs). Die Erstere bedient den internen Name Space – das LAN – und ist oft ein „Nebenjob“ der IT-Abteilung. Die Letztere befasst sich mit Zertifikaten, die für das Internet beschafft werden, und wird extern vergeben. Das bedeutet aber nicht automatisch, dass es korrekt ausgeführt wird und auch nicht, dass es immer sicher abläuft. Oft machen es Abteilungen und Projektträger nebenbei. Sie nennen das ‹best effort›, was bedeutet, dass es manchmal gut läuft.

Aber meistens klappt das nicht.

Die interne CA ist für die Konsolidierung, Einbettung und Verbesserung zuständig, wo dies erforderlich ist. Ein Austausch ist nur dann erforderlich, wenn eine Verbesserung nicht mehr möglich ist, das Ende der wirtschaftlichen Nutzungsdauer naht oder der Anbieter keinen Support mehr anbietet. Die Konsolidierung zu einer einzigen Infrastruktur kann ein guter Plan sein, wird aber zu oft als Ziel und nicht als Mittel gesehen. Es kann praktischer sein, den verschiedenen CAs ein einziges Frontend in einem Portal zu geben. Dabei kann es sich um eine separate Website handeln, aber Sie könnten auch in Erwägung ziehen, sie zum Bestandteil einer Identity Governance-Anwendung oder eines Helpdesk-Portals zu machen.

Wir bezeichnen die Prozessseite der Kryptografie manchmal als Registrierungsstelle (RA) und den Bereich als Certificate Governance. Die RA ist der Ort, an dem die Security, die IT und das Business für den täglichen Betrieb zusammenkommen – wo Keys angefordert und ausgestellt werden und wo die notwendigen Autorisierungen, wenn möglich, in einem Online-Workflow („Request and Attestation“) verarbeitet werden.
Das Backend der RA sollte so weit wie möglich automatisiert werden. Das bedeutet, dass die kryptografischen Schlüssel nach dem Einschalten eines Client-Systems automatisch und pünktlich ersetzt werden sollten. Das spart eine Menge Zeit und Mühe, besonders jetzt, wo die Gültigkeitsdauer der Schlüssel immer kürzer wird. Leider geschieht diese Integration nicht von selbst, daher sollte sie ein Standardschritt im Onboarding-Prozess sein. Die Unterstützung der verfügbaren Protokolle wird zwar immer üblicher, ist aber sicherlich noch nicht die Normalität. Der kryptografische Dienstleister wird seinen Teil der Arbeit in diesem Bereich übernehmen müssen.
Ein fester Bestandteil des Onboarding-Prozesses ist die Organisation des Monitoring-Service („Red und Blue Teams“ aus IT und Sicherheit) für den Krypto-Nutzer. Auf diese Weise können Sie ein strukturelles Augenmerk auf die aktuelle Nutzung legen, Benutzer benachrichtigen, wenn Zertifikate, die nicht automatisch erneuert werden, ablaufen, und Zertifikate und den Zugang zu Fachwissen zur Unterstützung von SOC-Analysten widerrufen.
Und schließlich – insbesondere im Hinblick auf NIS2 – weist das Onboarding den Kryptographie-Benutzer dem Disaster Recovery und dem Notfallmanagement zu. Das gilt natürlich sowohl für die zentralen internen Systeme (CA und RA) als auch für die angeschlossenen Clients. Das ist alles andere als trivial: Zertifikate gewähren privilegierten Zugang zu Systemen wie APIs, RDP und SSH, sind aber bei vielen Sicherheitsexperten selten im Fokus, was sie zu einem primären Ziel von Angriffen macht. Es ist daher von entscheidender Bedeutung, dass Sie wirksame Notfallverfahren implementieren, sie pflegen und testen.

Es ist offensichtlich, dass wir eine Menge Arbeit vor uns haben. Stellen Sie also einen Plan auf, wählen Sie einen effektiven Verantwortlichen und machen Sie sich darauf gefasst, dass dies eine anspruchsvolle Angelegenheit ist, bei der Sie mit Sicherheit eine Menge Leichen aus dem Keller holen werden. Aber es führt kein Weg daran vorbei, und wenn Sie es heute aufschieben, wird es morgen nur noch dringlicher.

Wenn Sie Hilfe brauchen, scheuen Sie sich nicht, sich bei uns zu melden!

• Identifikationssysteme auf Basis biometrischer Daten bieten eine gute Mischung aus Sicherheit und Komfort.
• Bei der Einführung biometrischer Systeme sind erhöhte Anforderungen an den Schutz personenbezogener Daten zu beachten.
• Biometrische Merkmale sind schwer zu fälschen, sollten jedoch niemals als alleinige Authentifizierung für den Zugang zu kritischen Systemen verwendet werden.

Moderne IT-Sicherheit ist ohne Biometrie nicht mehr denkbar. Ob am Handy oder am PC – biometrische Merkmale wie Fingerabdruck und Gesichtsstruktur werden täglich milliardenfach zur Anmeldung an Geräten genutzt. Sie versprechen Sicherheit und Bequemlichkeit, ersparen sie dem Nutzer doch die umständliche Eingabe komplexer Logins und Passwörter. Doch wie sicher ist die Technik wirklich? Welche Grundlagen sind nötig und was muss beachtet werden, wenn man Biometrie in der IT-Sicherheit einsetzen will? Dieser Post gibt einen Überblick.

Unter dem Begriff Biometrie werden verschiedene Verfahren zusammengefasst. Am bekanntesten ist wohl die Erkennung von Fingerabdrücken, wie sie in vielen Smartphones zum Einsatz kommt. Spätestens seit Apple das FaceID-System in seinen Produkten eingeführt hat, ist auch die Erkennung der Gesichtsgeometrie über Kameras weit verbreitet.

Darüber hinaus gibt es weitere Verfahren, die eine biometrische Erkennung ermöglichen. So können beispielsweise die Iris oder die Netzhaut des Auges zur Identifikation genutzt werden. Ebenso eignet sich das Venenmuster der Hand und auch die Analyse der DNA ermöglicht eine genaue Identifikation.

Neben diesen gängigen Methoden gibt es auch exotischere Ansätze: So gibt es Verfahren, die Menschen anhand ihres Gangs, ihres Körpergeruchs, ihrer Unterschrift oder ihres Tippverhaltens auf einer Tastatur erkennen können.

Egal welches Verfahren angewandt wird – es muss vier Voraussetzungen erfüllen:

• Eindeutigkeit: Die Merkmale dürfen tatsächlich nur bei jeweils einer Person auftauchen.
• Konstanz: Die Ausprägung des Merkmals darf nicht vom Alter oder der Umgebung abhängen.
• Messbarkeit: Es muss klar definierte Messgrößen und -verfahren geben.
• Universalität: Möglichst viele Personen sollen das betreffende biometrische Merkmal aufweisen.

Seit weit über 100 Jahren gilt der Fingerabdruck als ideales Mittel zur eindeutigen Identifizierung von Personen. Die Methode beruht auf der bislang unbewiesenen Annahme, dass jeder Fingerabdruck absolut einzigartig ist.

Eine Studie aus dem Jahr 2024 stellt diese Annahme infrage. Eine KI-basierte Analyse von über 60.000 Fingerabdrücken hat ergeben, dass es signifikante Ähnlichkeiten zwischen den Mustern verschiedener Finger gibt.

Für die Biometrie stellt dies jedoch kein Problem dar. Denn die gefundenen Ähnlichkeiten bestehen zwischen den verschiedenen Fingern ein und derselben Person. Eine Verwechslung zweier Personen anhand eines Fingerabdrucks ist daher nach wie vor praktisch ausgeschlossen.

Grundsätzlich funktioniert jede biometrische Erkennung nach dem gleichen Prinzip.

1. Zunächst muss der Nutzer registriert werden. Bei diesem Enrolment werden alle relevanten Merkmale erfasst, die zu seiner eindeutigen Identifizierung notwendig sind.
2. Aus diesen Daten werden mit einem Algorithmus sogenannte Templates Sie enthalten nicht mehr die vom jeweiligen Sensor erfassten Rohdaten, sondern nur die für den späteren Vergleich notwendigen Informationen. Diese Templates werden verschlüsselt gespeichert.
3. Soll eine Person später biometrisch identifiziert werden, wird beim sogenannten Matching der neue Datensatz (also zum Beispiel der Finger auf dem Sensor) mit den gespeicherten Daten im Template verglichen. Dabei kommt es praktisch nie zu einer exakten Übereinstimmung der Daten. Sie werden also nicht auf absolute Gleichheit, sondern auf hinreichende Ähnlichkeit im Rahmen einer vorher definierten Toleranz geprüft.

Um diese Methode umzusetzen, ist neben einem entsprechenden Scanner, etwa einem Kamerasystem, auch ein leistungsfähiger Computer nötig. Der muss nicht nur fähig sein, das Matching durchzuführen, er muss gleichzeitig auch sensible Daten schnell und sicher verschlüsseln können.

Für den Einsatz biometrischer Verfahren in Unternehmen ist es wichtig, dass die erhobenen Daten tatsächlich nur für den geplanten Zweck ) genutzt werden, beispielsweise zur Zugangskontrolle oder zur Anmeldung an Systemen. Weitere Daten müssen aus den Rohdaten entfernt werden – es dürfen also nur Template-Daten gespeichert werden.

Optimal ist eine Speicherung der biometrischen Daten beim Mitarbeiter, also etwa auf einer Chipkarte oder innerhalb einer Smartphone-App. Müssen biometrische Daten zentral gespeichert werden, sollten sie pseudonymisiert und verschlüsselt werden.

Wichtig: Bei der Einführung biometrischer Verfahren sollten sowohl der Betriebsrat als auch Datenschutzbeauftrage frühzeitig eingebunden werden. Eine verdeckte Erfassung der Mitarbeitenden ist nicht zulässig.

Je nach eingesetztem Verfahren ist das Sicherheitsniveau sehr unterschiedlich. So gibt es Gesichtserkennungssysteme, die nur mit einer Kamera arbeiten. Diese können zum Teil mit einem einfachen Foto überlistet werden. Fortgeschrittene Gesichtserkennungssysteme (wie z.B. FaceID von Apple oder Hello von Microsoft) verwenden daher bis zu drei Kameras und eine damit verbundene Erfassung der Gesichtsgeometrie – und erreichen so ein sehr hohes Sicherheitsniveau.

Ähnlich sieht es bei Fingerabdruck-Scannern aus. Einfache Systeme erkennen nur das Muster der Fingerkuppe, bessere Sensoren messen, ob es sich tatsächlich um einen Finger oder nur um einen Gegenstand mit einem Muster darauf handelt.

Generell bieten biometrische Verfahren einen guten Kompromiss zwischen Sicherheit und Komfort. Die meisten Systeme können umgangen werden, allerdings ist der Aufwand dafür hoch.

Bei kritischen Systemen sollte die Biometrie nie allein, sondern immer in Kombination mit anderen Authentisierungsfaktoren (wie Passwörtern, Schlüsselgeneratoren etc.) eingesetzt werden.

Biometrische Daten ermöglichen die direkte Identifizierung von Personen. Ihre Speicherung unterliegt daher dem Bundesdatenschutzgesetz. Lassen die erhobenen Daten Rückschlüsse auf die ethnische Herkunft oder den Gesundheitszustand zu (z.B. Iris-Scan, Gesichtserkennung etc.), gelten sie als besonders schützenswert. Für ihre Erhebung ist die ausdrückliche Einwilligung der Betroffenen erforderlich. Unabhängig von der Art der erhobenen biometrischen Daten sollten die Informationen nur verschlüsselt und bestenfalls nie zentral auf einem Server, sondern dezentral beim jeweiligen Nutzer gespeichert werden.

Das Bundesamt für Sicherheit in der Informationstechnik rät, biometrische Systeme nur sparsam einzusetzen. Anders als ein verlorenes Passwort können Fingerabdruck, Gesichtsgeometrie & Co. nicht einfach ausgetauscht werden, wenn sie einmal kompromittiert sind. Biometrische Daten sollten daher nur bei vertrauenswürdigen Anbietern hinterlegt werden.

Wichtig bei der Implementierung ist auch: Biometrische Daten sollten nie als alleinige Zugangsinformation hinterlegt werden. Die Kombination mit Passwörtern, PINs etc. erhöht Sicherheit und Zuverlässigkeit der Anmeldung.

Richtig eingesetzt kann Biometrie die Sicherheitsarchitektur einer Organisation sinnvoll erweitern. Die Benutzerakzeptanz ist hoch, die Handhabung einfach und die Erkennungsqualität sehr gut. Dennoch müssen bei der Einführung wichtige Punkte wie Datenschutz, Verschlüsselung, Einwilligungspflicht und eine gründliche Schulung der Mitarbeitenden beachtet werden. Sind diese Faktoren erfüllt, ist die Biometrie sicherer und komfortabler als viele andere Authentifizierungsverfahren.

• PAM erhöht die IT-Security durch die konstante Überwachung sensibler Daten und Just-in-Time- und Just-Enough-Einschränkung von Zugriffsrechten.
• Die Implementierung erfordert Sachverstand und eine umfassende Beurteilung der IT-Systeme und der gesamten Sicherheitsarchitektur.
• Richtig eingesetzt minimiert PAM Risiken, unterstützt beim Reporting, schafft mehr Transparenz und hilft, Compliance-Vorgaben zu erfüllen.

Neben den Zugangsdaten für normale Benutzer gibt es in Unternehmensnetzwerken auch Accounts mit sehr weitreichenden Berechtigungen für Mitarbeitende, die Systeme administrieren oder auf sensible Daten zugreifen müssen. Wird einer dieser Accounts kompromittiert, kann schnell erheblicher Schaden entstehen. Ein Privileged Access Management (PAM) hilft, diese kritischen Accounts umfassend zu schützen. Wie PAM funktioniert, wie es implementiert wird und welche Vorkehrungen ein Unternehmen dafür treffen sollte, erfahren Sie in diesem Post.

PAM ist eine moderne Form des Identitätsmanagements. Es wird im Wesentlich aus zwei Gründen eingesetzt: Zum einen, weil es die Sicherheit kritischer Daten steigert, indem es den Diebstahl von Anmeldeinformationen verhindert, Daten absichert und Angriffe erkennt, bevor Schaden entsteht. Wie wichtig dies ist, zeigt eine Untersuchung von Gartner, nach der rund 70 Prozent aller relevanten Sicherheitsvorfälle auf die Kompromittierung privilegierter Zugänge zurückzuführen sind.

Darüber hinaus kann der Einsatz von PAM notwendig sein, um Compliance-Standards einzuhalten oder entsprechende Vorgaben zu erfüllen. So erstellen PAM-Lösungen auch unveränderliche Audit-Trails, die nachweisen, dass erforderliche Zugriffskontrollen vorhanden und wirksam sind.

Privilegierte Konten sind im PAM-Kontext Nutzer-Zugänge, die weitreichende Zugriffsrechte auf Daten, Systeme und Dienste haben.

Das wohl naheliegendste Beispiel für ein privilegiertes Konto ist der Administrator, der Zugang auf sämtliche Systeme haben muss. Daneben gibt es aber auch Konten, die vollen Datenzugriff haben, weil ihre Nutzer Teil der Geschäftsführung sind, Accounts von Anwendern, die Apps verwalten und dafür Zugriff auf spezielle Administrations-Interfaces brauchen oder Konten von Nutzern, die Zugriff auf sensible Daten wie Zahlungsinformationen, Gesundheitsdaten, etc. haben. Sie alle werden vom Unternehmen mit Credentials ausgestattet, die mehr Rechte haben als Standardnutzer.

PAM kann entweder als Software-as-a-Service oder mit lokalen IT-Mitteln umgesetzt werden. In beiden Fällen ist ein umfassender Ansatz für die Verwaltung und Kontrolle von Konten, Zugängen, Systemen, Diensten und Prozessen erforderlich. Dabei kommt eine Zero-Trust-Architektur zum Einsatz, die Zugriffsrechte nach dem Least-Privilege-Prinzip verteilt. Das bedeutet, dass alle Zugriffe ständig überprüft werden und jeder Nutzer nur auf die Daten zugreifen kann, die er zur Erfüllung seiner Aufgaben tatsächlich benötigt.

Die Implementierung einer PAM-Architektur sollte die folgenden Schritte umfassen:

• Privilegiert Konten identifizieren: Im ersten Schritt wird ermittelt, wer überhaupt Credentials benötigt, die über die Rechte eines Standardnutzers hinausgehen. In der Regel werden hier zwei Gruppen unterschieden: Nutzern, die Zugriff auf sensible Informationen benötigen und IT-Administratoren, die Systeme und Dienste verwalten müssen.
• Risiken bewerten: Wenn die erforderlichen Nutzer definiert sind, sollte für jeden Satz von Rechten eine Risikobewertung durchgeführt werden.
• Kontrollen implementieren: Die Systeme müssen darauf vorbereitet werden, privilegierte Konten einzuschränken und zu überwachen. Mit welchen Mitteln dies geschehen kann, wird im Folgenden erläutert.
• Die Kontrollen beziehen sich nicht nur auf Konten oder Benutzer. Auch Geräte und Dienste müssen mit entsprechenden Privilegien oder Einschränkungen versehen werden können.
• Überwachung und Monitoring: Alle Aktivitäten der Mitarbeitenden im Netzwerk müssen überwacht und protokolliert werden. Diese Log-Daten werden ständig auf ungewöhnliche Aktivitäten oder auffällige Nutzungsmuster überprüft. Um Datenschutzprobleme zu vermeiden, sollten die gesammelten Daten so weit wie möglich pseudonymisiert werden.
• Mitarbeitende schulen: Wenn alle Maßnahmen in Kraft sind, müssen die Mitarbeitenden für die Bedeutung von PAM sensibilisiert und in der Anwendung des Systems geschult werden.

Ein PAM-System muss als Teil einer Sicherheits- und Risiko-Managementstrategie die Möglichkeit bieten, Personen, Dienste und Systeme zu identifizieren, die privilegierte Zugriffsrechte benötigen. Diese Zugriffe müssen gesichert, protokolliert und überwacht werden. Um diese Aufgaben erfüllen zu können, sind folgende Elemente erforderlich:

• Privileged Password Management: Eine automatisierte Passwortverwaltung, die Credentials rollenbasiert mit Zugriffsrechten ausstattet. Optimal sind hier Lösungen, die es erlauben, sensible Zugriffsrechte auch zeitlich begrenzt zu vergeben. Darüber hinaus sollte das System ermöglichen, auch externen Partnern oder Gastbenutzern (zeitlich begrenzte) Berechtigungen zu erteilen.
• Privileged Session Management: Ist ein System, das den Zugriff auf privilegierte Konten überwacht und protokolliert. Es kann auch Audit-Protokolle und Sitzungsaufzeichnungen zur Erfüllung von Compliance-Vorgaben erstellten.
• Nutzungs-Analyse: Ein Analysesystem erfasst alle Aktivitäten und kann so frühzeitig auffällige Nutzungsmuster erkennen.
• Flexible Rechte-Vergabe: Das System erkennt, ob Benutzer mit erweiterten Zugriffsrechten ihre Privilegien aktuell benötigen – und stuft diese Rechte gegebenenfalls auf eine niedrigere Sicherheitsklasse herab, wenn keine sensiblen Daten benötigt werden. Kritische Daten werden «just in time» angeboten und nicht ständig verfügbar gehalten.
• Multi-Faktor-Authentifizierung (MFA): Alle privilegierten Credentials sollten nur mit einer vorherigen MFA-Anmeldung verwendet werden können.
• Konten-Sparsamkeit: Privilegierte Zugriffsrechte sollten nur an die Nutzer vergeben werden, die diese auch wirklich benötigen. Die Liste dieser Nutzer sollte regelmäßig überprüft und die gewährten Rechte entsprechend angepasst werden.

Privileged Identity Management (PIM) hat auf den ersten Blick viele Ähnlichkeiten mit PAM. PIM konzentriert sich jedoch auf die Verwaltung von Accounts, während PAM zusätzlich dazu auch den Zugriff auf Ressourcen überwacht und sichert.

Richtig eingesetzt kann ein PAM nicht nur die Qualität der IT-Sicherheit verbessern, sondern auch die Erstellung von Berichten und Sicherheitsaudits erleichtern. Gleichzeitig steigert die Verwaltung von Zugriffsrechten für das Unternehmen selbst die Transparenz. Die Implementierung eines Preferred Access Managements lohnt sich daher überall dort, wo in Unternehmen mit sensiblen Daten gearbeitet wird und ein Verlust dieser Daten einen signifikanten Schaden für das Unternehmen bedeuten würde.

Single Sign-On, kurz SSO, ist eine Lösung für Unternehmen, die dazu beiträgt, die IT-Sicherheit zu erhöhen, die Benutzerfreundlichkeit zu verbessern und Kosten zu senken. Denn sich unzählige, komplizierte Passwörter zu merken ist nahezu unmöglich und das Hantieren mit Passwort-Managern kostet Zeit. SSO, frei übersetzt „Einmalanmeldung“, bietet einen Ausweg aus diesem Konflikt. Dabei handelt es sich um Sitzungs- und Benutzerauthentifizierungsdienste, der es ermöglicht, mit nur einem einzigen Satz Anmeldedaten aus Nutzernamen und Kennwort auf mehrere Anwendungen zuzugreifen.

Ohne SSO erfolgt die Authentifizierung bei jeder Website oder Anwendung separat. Dazu muss die Website ihre eigene private Datenbank mit Benutzeranmeldeinformationen vorhalten und diese entsprechend gepflegt werden. Für Unternehmen, die Cloud-Anwendungen und lokale Netzwerke kombinieren, stellt die schiere Menge an Benutzerdaten einen erheblichen Verwaltungsaufwand dar. Die IT-Abteilung muss für jeden Account (z. B. Mitarbeitende, Auftragnehmer oder Kunden) separate Anmeldedaten für jede einzelne Website, jedes Programm oder jede Anwendung im System speichern und verwalten. Dies führt zu Sicherheitsrisiken, hohen Verwaltungskosten und Ineffizienz. SSO vereinfacht den Anmelde- und Authentifizierungsprozess. Konkret funktioniert ein SSO-Anmeldevorgang wie folgt:

1. Angestellte rufen die Internetseite oder Anwendung des Service Providers (SP) auf, auf die sie zugreifen möchten.
2. Der Service Providersendet diese Anfrage und leitet den Mitarbeiter an den Identity Provider (IdP) des SSO-Systems weiter.
3. Der Mitarbeiter wird aufgefordert, sich zu authentifizieren, indem er die vom Identity Provider angeforderten Anmeldedaten für das SSO wie Benutzername und Passwort eingibt.
4. Sobald der Identity Provider die Anmeldedaten des Mitarbeiters überprüft hat, sendet er eine Bestätigung an den Service Provider zurück, um die erfolgreiche Authentifizierung zu bestätigen. Der Mitarbeiter erhält daraufhin Zugriff auf die gewünschte Anwendung.
5. Andere Service Provider, auf die der Mitarbeiter zugreift, bestätigen die Authentifizierung des Benutzers beim Identity Provider. Diese Service Providerbenötigen keinen Benutzernamen und kein Passwort.

Jedes Mal, wenn sich ein Nutzer bei einem Dienst anmelden, entsteht ein potenzielles Risiko. Denn Login-Daten gehören zu den beliebtesten Angriffszielen von Cyber-Kriminellen. SSO reduziert die Angriffsfläche, da sich Beschäftige zum Beispiel nur einmal am Tag anmelden müssen und dabei nur einen Satz von Anmeldedaten verwenden. Die Beschränkung der Logins auf einen Satz von Anmeldedaten erhöht somit die Sicherheit der Unternehmen. Denn wenn die Mitarbeitende für jede Anwendung ein eigenes Passwort verwenden müssen, machen sie es häufig gar nicht oder verwenden leicht merkbare Passwörter. Laut einer aktuellen Studie beziehen sich zum Beispiel 32 Prozent aller Passwörter direkt auf das Unternehmen, etwa den Firmennamen oder eine Abwandlung desselben). Single Sign-On reduziert die kognitive Belastung. Durch den Einsatz sinkt zudem die Gefahr, dass Angestellte die gleichen Passwörter wiederverwenden oder aufschreiben, was wiederum das Risiko eines Diebstahls verringert.

In der Regel ist der Einsatz von SSO-Diensten auch technisch sicherer als die „normale“ Anmeldung per Nutzername und Passwort. Denn die Anmeldedaten sind deutlich besser geschützt. SSO basiert auf einer Vertrauensbeziehung zwischen der Partei, die über die Identitätsinformationen verfügt und Logins authentifizieren kann, dem Identity Provider (IdP), und dem Dienst oder der Anwendung, auf die zugegriffen werden soll, dem Service Provider (SP). Anstatt sensible Daten über das Internet hin und her zu schicken, sendet der Identity Provider eine Bestätigung – oft über einen Identitätsstandard wie SAML –, um den Anmeldung gegenüber dem Service Provider zu authentifizieren.

Ein weit verbreiteter Mythos über SSO-Lösungen ist, dass sie die Sicherheit von IT-Systemen gefährden. Dieser Irrglaube beruht auf der Vorstellung, dass bei Diebstahl des Masterpassworts alle zugehörigen Konten zugänglich sind. Das lässt sich allerdings effektiv vermeiden. Eine bewährte Strategie, um eine zusätzliche Sicherheitsebene zu schaffen, ist zum Beispiel die Kombination von SSO mit Multi-Faktor-Authentifizierung (MFA). MFA erfordert, dass ein Mitarbeiter bei der Anmeldung zwei oder mehr Nachweise seiner Identität vorlegt. Dabei kann es sich um einen Code handeln, der zum Beispiel an das Smartphone gesendet wird.

Risikobasierte Authentifizierung (RBA) ist eine weitere erprobte Sicherheitsfunktion zum Schutz von SSO. RBA ermöglicht IT-Verantwortlichen den Einsatz von Tools zur Überwachung der Benutzeraktivitäten und des Kontexts. Dadurch kann sie ungewöhnliches Verhalten erkennen, das auf nicht autorisierte Nutzer oder einen Cyberangriff hindeutet. Wenn beispielsweise mehrere Anmeldungen fehlschlagen oder falsche IPs verwendet werden, kann die IT eine MFA anfordern oder den Benutzer vollständig sperren.

Der Begriff «Schatten-IT» ist in der Welt der Cyber-Sicherheit nicht neu. Sie bezieht sich auf nicht autorisierte Downloads am Arbeitsplatz. In der Vergangenheit beschränkte sich Schatten-IT hauptsächlich auf Angestellte, die nicht lizenzierte oder unautorisierte Software nutzten. Mit der zunehmenden Beliebtheit von Cloud-basierten Downloads steigt auch das Risikopotenzial. Um dieses Problem zu lösen, können IT-Administratoren mithilfe von SSO überwachen, welche Anwendungen die Mitarbeitende verwenden. Auf diese Weise wird das Risiko des Identitätsdiebstahls minimiert, was ein weiteres Plus an Sicherheit darstellt.

Single Sign-On steigert nicht zuletzt die Produktivität der Beschäftigten, da sie weniger Zeit mit der Anmeldung und der Verwaltung von Passwörtern verbringen müssen. Angesichts der Tatsache, dass viele Angestellte mehrmals pro Stunde zwischen verschiedenen Anwendungen wechseln, ist dieser Zeitfaktor nicht zu unterschätzen. Nach Schätzungen von Gartner sind Passwortprobleme für 40 % aller Anrufe beim Helpdesk verantwortlich. Eine weitere Studie von Forrester zeigt, dass das Zurücksetzen von Passwörtern Unternehmen bis zu 70 US-Dollar pro Problemlösung kostet. SSO senkt somit auch die Support-Kosten, da das Verfahren die Anzahl der benötigten Passwörter auf ein einziges reduziert. Darüber hinaus vereinfacht SSO die Arbeit der Administratoren, da sie Benutzerkonten und Zugriffsrechte zentral verwalten können. Nicht zuletzt erhöht es die Arbeitszufriedenheit generell, da die Mitarbeiter unterbrechungsfrei arbeiten und schneller auf alle Dienste zugreifen können, die sie benötigen. Besonders wertvoll ist der einfache Zugang für Mitarbeiterinnen und Mitarbeiter, die im Außendienst tätig sind oder von mehreren Geräten aus arbeiten.

Bei Single Sign-On (SSO) kommen verschiedene Verfahren zum Einsatz. Das derzeit am häufigsten verwendete Verfahren ist das SAML-basierte SSO. Dieses System ist aus verschiedenen Gründen populär:

• Weit verbreitet: SAML ist seit vielen Jahren auf dem Markt und wird von einer Vielzahl von Identity Providern und Service Providern unterstützt. Viele Unternehmen haben bereits in SAML-Infrastruktur investiert und setzen diese erfolgreich ein.
• Sicherheit: SAML bietet robuste Sicherheitsmechanismen für die Übertragung von Authentifizierungs- und Autorisierungsdaten zwischen Identity Providern und Service Providern. Beispielsweise werden digitale Signaturen und Verschlüsselung verwendet, um die Integrität und Vertraulichkeit der übertragenen Daten zu gewährleisten.
• Benutzerfreundlichkeit: SAML ermöglicht es, sich einmal bei einem Identity Provider anzumelden und dann nahtlos auf verschiedene Service Provider zuzugreifen, ohne sich erneut anmelden zu müssen. Dies verbessert die Benutzerfreundlichkeit und reduziert den Anmeldeaufwand.
• Interoperabilität: SAML ist ein offener Standard, den viele Organisationen unterstützen. Dadurch arbeiten Systeme und Anwendungen verschiedener Anbieter nahtlos zusammen, was die Zusammenarbeit erleichtert.

Obwohl SAML das am weitesten verbreitete SSO-Verfahren ist, gewinnen auch moderne Protokolle wie OpenID Connect (OIDC) zunehmend an Bedeutung, insbesondere in Webanwendungen und Cloud-Szenarien. OIDC bietet zusätzliche Funktionen wie die Unterstützung von OAuth 2.0 und eine verbesserte Benutzererfahrung für moderne Anwendungen und APIs.

SSO weist systembedingt auch Nachteile auf. Wenn zum Beispiel das SSO-System ausfällt oder nicht verfügbar ist, können Nutzer den Zugriff auf angeschlossenen Anwendungen und Dienste verlieren. Dies kann zu Beeinträchtigungen und Produktivitätsproblemen führen. Bei der Nutzung von SSO müssen Unternehmen darüber hinaus darauf vertrauen, dass ihr SSO-Anbieter die Anmeldedaten angemessen schützt. Ansonsten besteht das Risiko, dass Angreifer Authentifizierungsdaten kompromittieren oder missbrauchen.

Die Implementierung und Wartung von SSO ist eine komplexe Aufgabe. Sie erfordert sorgfältige Planung, die Integration in bestehende Systeme und die Gewährleistung der Kompatibilität mit verschiedenen Plattformen und Authentifizierungsprotokollen.

Authentifizierungsprozesse spielen eine wichtige Rolle im Ökosystem eines Unternehmens. Je größer die Organisation, desto mehr Authentifizierungsdaten muss es verarbeiten und speichern. Die Vorteile von SSO in diesem Kontext sind beachtlich: erhöhte Sicherheit, verbesserte Benutzerfreundlichkeit, geringere Kosten und Aufwand für die Verwaltung von Passwörtern. Es kann jedoch auch Nachteile geben, wie eine erhöhte Abhängigkeit von externen Diensten. Eine gründliche Bewertung Ihrer geschäftlichen Anforderungen hilft Ihnen zu entscheiden, ob SSO die richtige Wahl für Unternehmen ist.