Seit Jahren werden Security-Programme um eine vertraute Frage herum optimiert: Was sollten wir blockieren? Malware, unbekannte ausführbare Dateien, nicht vertrauenswürdige Geräte, verdächtiger Netzwerkverkehr, gefährliche Websites. Dieses Denken bleibt notwendig – reicht aber nicht mehr aus.
Viele der interessantesten Angriffspfade beginnen auf der anderen Seite dieser Grenze. Sie nutzen bereits installierte Software, bestehende Identitäten, aus legitimen Gründen vergebene Berechtigungen und Workflows, auf die Mitarbeitende täglich angewiesen sind.
Anders gesagt: Der Angriff beginnt möglicherweise nicht dort, wo eine Policy versagt. Er kann dort beginnen, wo die Policy ja.
„Freigegeben“ ist eine Entscheidung – keine Garantie
Begriffen wie freigegeben, vertrauenswürdig, verwaltet oder autorisiert geben wir intuitiv eine besondere Bedeutung. Sie klingen nach einem Endzustand. Sobald eine Anwendung freigegeben ist oder eine Identität die richtige Rolle besitzt, wirkt die Security-Diskussion schnell abgeschlossen.
Eine Freigabe beantwortet jedoch meist nur eine sehr enge Frage: Darf dieses Objekt in diesem Kontext existieren oder arbeiten? Sie beantwortet nicht, wozu eine Anwendung gebracht werden kann, welche Ressourcen eine Identität erreicht, wie zwei legitime Fähigkeiten kombiniert werden können oder ob ein vertrauenswürdiger Workflow zweckentfremdet werden kann.
Die Frage lautet nicht mehr nur: „Was haben wir verboten?“ Sondern auch: „Was erlauben wir – und können wir weiterhin kontrollieren, was dadurch möglich wird?“
Die Angriffsfläche besteht zunehmend aus legitimen Fähigkeiten
Ein Angreifer, der über vertraute Werkzeuge agieren kann, gewinnt einen entscheidenden Vorteil: weniger Reibung. Eine signierte Binärdatei, ein vorhandenes Administrationstool, eine erlaubte Scripting-Umgebung oder eine gültige Benutzersitzung sehen nicht wie ein offensichtlicher Verstoß aus. Zumindest zunächst sehen sie nach normaler Arbeit aus.
Das verändert das Security-Problem. Die Herausforderung besteht nicht nur darin, schädliche Objekte zu erkennen. Es geht darum, Fähigkeiten, Kontext und Kombinationen zu verstehen.
Anwendungsvertrauen
Auch eine freigegebene Anwendung kann Funktionen bereitstellen, die für einen Angreifer nützlich werden. Vertrauen sollte deshalb berücksichtigen, was eine Anwendung ausführen, erreichen oder initiieren darf – nicht nur, ob die Binärdatei bekannt ist.
Identitätsvertrauen
Eine gültige Identität beweist, dass eine Sitzung über Credentials verfügt. Sie beweist keine Absicht. Privilegien, Scope, Gerätekontext und ungewöhnliches Verhalten bleiben auch nach erfolgreicher Authentifizierung relevant.
Workflow-Vertrauen
Prozesse, die einzeln legitim sind, können in Kombination gefährlich werden. Security muss verstehen, wie Anwendungen, Identitäten, Geräte, Berechtigungen und Daten miteinander verbunden sind.
Von binärem Vertrauen zu kontrolliertem Vertrauen
Die Alternative besteht nicht darin, allem zu misstrauen. Das würde moderne Organisationen unbenutzbar machen. Das sinnvollere Ziel ist kontrolliertes Vertrauen: legitime Arbeit ermöglichen, die daraus entstehenden Fähigkeiten aber so eng halten, dass sie verständlich und steuerbar bleiben.
Das bedeutet, über ein binäres Allow/Deny-Modell hinauszugehen und präzisere Fragen zu stellen:
- Umfang: Was genau wird erlaubt – die Anwendung, eine Funktion, ein Benutzer, ein Gerät, ein Ort oder eine Kombination daraus?
- Kontext: Ist dieselbe Aktion für diese Identität, auf diesem Endpoint und zu diesem Zeitpunkt sinnvoll?
- Privileg: Ist erhöhter Zugriff dauerhaft – oder kann er nur dann gewährt werden, wenn er tatsächlich benötigt wird?
- Beobachtung: Können wir sehen, was vertrauenswürdige Komponenten tun, nachdem sie freigegeben wurden?
- Widerruf: Kann Vertrauen schnell reduziert oder entzogen werden, wenn sich der Kontext ändert?
Diese Fragen sind unbequemer als das Pflegen einer Blacklist oder Allowlist, weil sie Security zwingen, sich mit realem Betriebsverhalten auseinanderzusetzen. Genau dort wird moderne Kontrolle aber wertvoll.
Gute Security erzeugt sinnvolle Reibung – an der richtigen Stelle
Security-Teams sollen häufig Reibung beseitigen. Das ist nachvollziehbar: Niemand möchte Controls, die normale Arbeit unnötig erschweren. Die Antwort kann aber nicht lauten, überall jede Reibung zu entfernen.
Das bessere Ziel ist, Reibung dort einzubauen, wo das Risiko steigt. Ein Standardnutzer, der eine bekannte Business-Anwendung öffnet, sollte nicht denselben Controls begegnen wie ein Prozess, der einen ungewöhnlichen Child Process startet, eine Identität, die erhöhte Rechte anfordert, oder ein Gerät, das sensible Daten außerhalb seines normalen Kontexts bewegt.
Hier wird Prävention granularer. Statt einer breiten Kategorie dauerhaft zu vertrauen, fragt die Organisation kontinuierlich, ob die nächste Aktion noch zu dem Grund passt, aus dem Vertrauen ursprünglich gewährt wurde.
Ein praktischer Test
Wähle eine Anwendung, die deine Organisation als vollständig vertrauenswürdig einstuft.
Dann frage: Welche Identitäten können sie nutzen? Was kann sie starten? Welche Daten kann sie erreichen? Kann sie Privilegien erhöhen? Lässt sich ihr Verhalten kontextabhängig begrenzen? Und würdest du bemerken, wenn sie sich plötzlich anders verhält?
Der strategische Wandel
Die wichtigste Veränderung ist konzeptionell. Security-Architektur war traditionell sehr gut darin, bekannt Schädliches von erlaubtem Gutem zu trennen. Sobald legitime Tools Teil von Angriffsketten werden, verliert diese Grenze allein jedoch an Aussagekraft.
Organisationen müssen Vertrauen deshalb dynamisch behandeln. Anwendungen, Identitäten, Geräte und Daten sollten nicht einfach „vertrauenswürdig“ werden und anschließend aus dem Blick verschwinden. Ihre Berechtigungen sollten verständlich, beobachtbar und zur Aufgabe verhältnismäßig bleiben.
Das ist ein anspruchsvolleres Modell – aber auch ein realistischeres. Denn der nächste relevante Angriff kündigt sich möglicherweise nicht dadurch an, dass eine Regel gebrochen wird. Er kann damit beginnen, genau das zu nutzen, was die Organisation bereits freigegeben hat.