Identität trifft Resilience

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.