Trusted Ownership: Wie Ivanti Application Control über Allowlisting hinaus skaliert

Anwendungskontrolle ist eines dieser Sicherheitsthemen, bei denen viele Menschen an überholten Annahmen festhalten. Klassisches Allowlisting wirkt sicher, wird aber schnell zum Wartungsaufwand. Blocklisting wirkt reaktiv und unvollständig. Und obwohl Tools wie Microsoft AppLocker viele zu der Annahme verleitet haben, dass striktes Allowlisting der Goldstandard sei, haben moderne Angriffe das Gegenteil bewiesen. Angreifer setzen zunehmend auf legitime, signierte Tools – die im falschen Kontext verwendet werden –, um listenbasierte Kontrollen vollständig zu umgehen.

Wenn Unternehmen also Ivanti Application Control oder Ivanti Neurons for App Control evaluieren und dabei auf Trusted Ownership stoßen, kann dies zunächst wie Blocklisting wirken, da explizite Sperren möglich sind. Tatsächlich ist Trusted Ownership ein deutlich breiteres und operativ wesentlich schlankeres, inspiriertes Durchsetzungsmodell, das die Ausführung auf Basis der Herkunft steuert – nicht nur anhand der Identität.

Statt wachsende Listen zu verwalten, setzt es Sicherheit auf Basis der Frage durch, wer Software auf dem System abgelegt hat, und fügt sich damit nahtlos in moderne Verfahren der Softwareverteilung und Zero-Trust-Prinzipien ein. Am besten versteht man es nicht als weiteren Listenmechanismus, sondern als provenienzorientiertes Durchsetzungsmodell, das die Ausführung auf Basis der Herkunft steuert – nicht nur anhand der Identität.

Dieser Perspektivwechsel führt zu einer besseren Frage für moderne Anwendungskontrolle: nicht nur, was eine Datei ist, sondern wie sie dorthin gelangt ist.

Über Listen hinaus: Warum Provenienzsteuerung heute wichtig ist

Die Frage, wie eine Datei auf das System gelangt ist, steht im Mittelpunkt der Provenienzsteuerung. Statt Dateien ausschließlich anhand von Herausgeber, Pfad oder Hash zu vertrauen, bewertet die Provenienzsteuerung Herkunft und Prozess, durch die sie eingeführt wurden. Wer hat die Datei auf den Datenträger geschrieben? Über welchen Mechanismus? Folgte die Installation einem kontrollierten IT-Workflow? Diese Bewertung verlagert die Anwendungskontrolle vom Objektvertrauen zum Prozessvertrauen und schafft damit eine wesentlich stärkere Sicherheitsgrenze.

In Ivanti Application Control wird Provenienzsteuerung als Trusted Ownership umgesetzt. Jede Datei, die von einem vertrauenswürdigen Eigentümer abgelegt wurde, wird zugelassen; alles, was von einem Benutzer eingebracht wurde, wird standardmäßig abgelehnt. Dies gilt konsistent für ausführbare Dateien, DLLs, Installer und Skripte. Da Identitäten wie SYSTEM, TrustedInstaller und Administrators standardmäßig vertrauenswürdig sind, läuft Software, die über Standard-Bereitstellungskanäle wie MS Intune, MECM, Ivanti Endpoint Manager (EPM) oder andere Enterprise-Tools bereitgestellt wird, sofort – ohne Regelpflege oder Ausnahmen.

Das ist ein grundlegender Bruch mit klassischem Allowlisting. AppLocker-Regeln stehen und fallen mit exakten Definitionen von Herausgeber, Pfad oder Hash. AppLocker bewertet die Installationsherkunft nicht und vertraut Ihren Bereitstellungsmechanismen nicht automatisch. Über Intune bereitgestellte Software erfordert weiterhin eine bereits vorhandene Allow-Regel, häufig gestützt auf breite Standardeinstellungen, die die Verzeichnisse „Program Files“ oder Windows zulassen.

Diese Unterscheidung ist wichtig, weil moderne Angriffe legitime Tools zunehmend in ungeeigneten Kontexten missbrauchen. Provenienzsteuerung neutralisiert einen großen Teil dieses Risikos, indem sie Vertrauen daran knüpft, wie Software ankommt – nicht nur daran, was sie ist. Sie entspricht Zero-Trust-Prinzipien, reduziert Risiken in der Lieferkette und begrenzt standardmäßig die Möglichkeiten für Living-off-the-Land-Missbrauch (LotL) erheblich.

Wenn Sie die Bedeutung der Herkunft verstanden haben, stellt sich als Nächstes die Frage: Wie lässt sich dies in großem Maßstab durchsetzen?

Die Antwort: Provenienz konsequent auf alle Arten anwenden, wie Software ausgeführt und bereitgestellt wird.

Über Blocklists hinaus: Breite Abdeckung für moderne Softwarebereitstellung

Provenienzsteuerung verlagert Anwendungssicherheit weg von der Verwaltung endloser Listen hin zur Validierung des Prozesses, über den Software auf das System gelangt. Aus dieser Perspektive wird klar, dass Trusted Ownership kein Blocklist-Ansatz ist. Es handelt sich um eine herkunftsbasierte Vertrauensgrenze, die sich deutlich anders verhält als klassisches Allowlisting.

Ein häufiges Missverständnis ist, dass Trusted Ownership dem Blocklisting ähnelt, weil Administratoren mitunter gezielte Deny-Regeln für bekannte Windows-Tools hinzufügen. In der Praxis sind diese Deny-Regeln Maßnahmen zur defensiven Härtung gegen Living-off-the-Land-Techniken. Jede ernstzunehmende Methode der Anwendungskontrolle nutzt solche gezielten Einschränkungen. Der Kern von Trusted Ownership ist das Gegenteil von Blocklisting: Software, die über einen kontrollierten und vertrauenswürdigen Prozess bereitgestellt wird, ist standardmäßig erlaubt, während von Benutzern eingebrachte Inhalte standardmäßig abgelehnt werden.

Ein wichtigeres Unterscheidungsmerkmal ist die Abdeckung. Viele Unternehmen, die sich auf klassische Allowlists verlassen, konzentrieren sich am Ende fast ausschließlich auf ausführbare Dateien. Sie vermeiden es häufig, dieselbe Durchsetzung auf DLLs, Skripte und MSI-Pakete anzuwenden, weil diese Dateitypen die Regelpflege erheblich komplexer machen. Dadurch entstehen Lücken, die moderne Angreifer häufig ausnutzen.

Trusted Ownership vermeidet diese Lücken, indem dieselbe herkunftsbasierte Durchsetzung auf die gesamte Ausführungskette angewendet wird. Ausführbare Dateien, DLLs, Skripte, MSI-Installer und zugehörige Komponenten werden nach demselben Vertrauensmodell bewertet. Da Vertrauen davon abhängt, wer die Datei eingebracht hat, benötigen Sie keine separaten Richtlinien für jeden Dateityp. Ein Skript im Downloads-Ordner, eine in einem temporären Build-Verzeichnis erstellte DLL oder eine aus einem Benutzerprofil ausgeführte EXE werden alle standardmäßig abgelehnt, wenn sie außerhalb eines kontrollierten Installationsprozesses entstanden sind.

Dieses Vertrauensmodell passt auch auf natürliche Weise dazu, wie moderne Endpoint-Management-Plattformen Software bereitstellen. Lösungen wie Intune, MECM, Ivanti Neurons for MDM, Ivanti Endpoint Manager und ähnliche Systeme installieren Anwendungen in der Regel über die SYSTEM-Identität oder ein anderes vertrauenswürdiges Dienstkonto.

Da diese Identitäten bereits Trusted Owners sind, läuft über diese Kanäle bereitgestellte Software sofort, ohne Allow-Regeln zu erstellen, Dateipfade zu pflegen oder Richtlinien zu aktualisieren. Nur wenn Sie bewusst alternative Installationskonten verwenden, etwa benutzerdefinierte DevOps-Agents oder skriptgesteuerte Installationen im Benutzerkontext, müssen Sie diese Identität als Trusted Owner festlegen.

Das Ergebnis ist ein Modell mit breiter und konsistenter Abdeckung über alle relevanten Dateitypen hinweg. Es arbeitet nahtlos mit modernen Softwareverteilungen zusammen und vermeidet den operativen Aufwand klassischer Allowlists, die sich hauptsächlich auf ausführbare Dateien konzentrieren.

Trusted Ownership setzt Vertrauen nicht in einzelne Objekte, sondern in die kontrollierten Prozesse, über die Software bereitgestellt wird. So entsteht ein skalierbarerer und sichererer Ansatz für Anwendungskontrolle.

Wo WDAC (App Control for Business) einzuordnen ist

Microsoft unterhält zwei Technologien für die Anwendungskontrolle: AppLocker und App Control for Business (früher WDAC). Obwohl beide weiterhin existieren, ist Microsoft hinsichtlich ihrer Rollen klar. AppLocker hilft dabei, Benutzer an der Ausführung nicht genehmigter Anwendungen zu hindern, erfüllt jedoch nicht die Wartungskriterien für moderne Sicherheitsfunktionen und wird daher als Defense-in-Depth-Mechanismus und nicht als strategische Sicherheitskontrolle eingestuft.

Microsofts Zukunftspfad für Anwendungskontrolle ist App Control for Business; Microsoft erklärt ausdrücklich, dass AppLocker – abgesehen von wichtigen Sicherheitsupdates – funktional abgeschlossen ist und nicht mehr aktiv weiterentwickelt wird. Das bedeutet, dass alle neuen Funktionen nur in WDAC und nicht in AppLocker bereitgestellt werden.

App Control for Business führt das Konzept Managed Installer ein. Dadurch kann Windows Anwendungen automatisch vertrauen, die über bestimmte Bereitstellungsplattformen wie Intune oder MECM installiert wurden. Vertrauen wird aus dem Verteilungskanal statt aus einzelnen Dateien abgeleitet, was die Regelpflege erheblich reduziert.

Dies steht in enger Übereinstimmung mit dem Trusted-Ownership-Modell von Ivanti Application Control. Beide Ansätze vertrauen Software auf Basis des kontrollierten Prozesses, der sie installiert hat, statt auf diskrete Dateiattribute. Trusted Ownership wendet dieses Konzept jedoch einfacher und im Betrieb zugänglicher an. Ivanti vertraut Identitäten wie SYSTEM und festgelegten Dienstkonten, ohne komplexe Richtlinienebenen, XML-Definitionen oder tiefgehende WDAC-Expertise zu erfordern.

Ivanti hört von vielen Unternehmen, dass sie Schwierigkeiten haben, WDAC operativ umzusetzen. WDAC-Richtlinien erfordern sorgfältiges Design, umfangreiche Tests im Audit-Modus, Treiber- und Kernel-Ausnahmemanagement sowie die laufende Pflege mehrerer Richtliniensätze. Dies führt häufig dazu, dass Unternehmen WDAC mit AppLocker kombinieren, um sowohl Low-Level-Durchsetzung als auch alltägliche Kontrolle im Benutzerbereich abzudecken – und am Ende zusätzlichen Verwaltungsaufwand haben.

Ivanti Application Control bietet eine einheitliche Alternative. Durch Trusted Ownership, Trusted Vendors und die Validierung digitaler Signaturen stellt es ein provenienzbasiertes Default-Deny-Modell mit konsistenter Abdeckung über ausführbare Dateien, DLLs, Skripte und MSI-Pakete hinweg bereit.

Statt zwei Microsoft-Steuerungsebenen mit unterschiedlichem Umfang zu pflegen, verwalten Unternehmen eine einzige, optimierte Richtlinie, die Vertrauen danach durchsetzt, wie Software in das System eingebracht wird. Dies erfüllt viele der praktischen Ziele, die Kunden mit einer kombinierten WDAC- und AppLocker-Bereitstellung erreichen möchten – jedoch mit geringerer operativer Komplexität und einem einheitlichen Vertrauensmodell.

LOLBins und Steuerung auf Argumentebene

Nachdem eine breite Abdeckung etabliert ist, stellt sich als Nächstes die Frage, wie mit den legitimen Tools umzugehen ist, die bereits auf jedem Computer vorhanden sind und die Angreifer gerne missbrauchen.

Moderne Angreifer verzichten häufig auf klassische Malware und nutzen stattdessen die Tools, die bereits auf jedem Windows-Gerät vorhanden sind. Diese Living-off-the-Land-Tools (LOLBins) sind legitim und für den normalen Betrieb erforderlich, wodurch sie schwer zu blockieren sind, ohne die Produktivität zu beeinträchtigen. Klassisches Allowlisting stößt hier an Grenzen, weil breit angelegtes Blockieren Workflows unterbricht, während breit angelegtes Zulassen gefährliche Lücken offenlässt.

Ein provenienzbasiertes Modell wie Trusted Ownership verändert diese Dynamik. Selbst wenn ein Angreifer versucht, ein integriertes Tool zu verwenden, stammt der Inhalt, den er ausführen möchte, in der Regel nicht aus einem vertrauenswürdigen Installationsprozess. Da Ivanti die Herkunft dieses Inhalts bewertet, scheitern die meisten Missbrauchsversuche automatisch. Das Tool mag legitim sein, der Inhalt, den es ausführen soll, ist es nicht – und Trusted Ownership stoppt ihn vor der Ausführung.

Wichtig ist außerdem, nicht nur zu verstehen, welche Tools ausgeführt werden, sondern auch, wozu sie aufgefordert werden. Viele Interpreter und Laufzeitumgebungen wie PowerShell, Python oder Java können in einem Kontext vollkommen sicher und in einem anderen riskant sein. Eine Geschäftsanwendung kann auf Java angewiesen sein, um einen bestimmten, genehmigten Prozess zu starten, während eine von einem Benutzer heruntergeladene JAR-Datei ein völlig anderes Szenario darstellt.

Ivanti löst dies mit einem mehrschichtigen Ansatz. Eine JAR-Datei wird zunächst mithilfe von Trusted Ownership bewertet und sofort blockiert, wenn sie von einem Benutzer und nicht über einen kontrollierten Bereitstellungsprozess eingebracht wurde. Darüber hinaus können Administratoren einfache Allow-Regeln erstellen, die genau festlegen, welche Java-Befehle erlaubt sind. So wird sichergestellt, dass nur legitime Java-basierte Anwendungen ausgeführt werden, während Versuche, nicht genehmigte JAR-Dateien zu starten, unauffällig abgelehnt werden.

Dasselbe Prinzip gilt auch für andere Tools. Richtlinien können genau das Verhalten genehmigen, das Ihr Unternehmen benötigt, und gleichzeitig Aktivitäten blockieren, die außerhalb dieser Grenzen liegen. Dadurch werden breite, anfällige Regeln vermieden, und die tägliche Arbeit läuft reibungslos weiter.

Das Ergebnis ist ein ausgewogener und moderner Ansatz. Trusted Ownership stoppt nicht vertrauenswürdige Inhalte standardmäßig. Gezielte Härtung entspricht Best Practices von Behörden und Community zur Reduzierung von Living-off-the-Land-Missbrauch, und absichtsorientierte Kontrollen stellen sicher, dass legitime Prozesse weiterhin funktionieren, ohne Angreifern Türen zu öffnen.

Dieser Ansatz steht in enger Übereinstimmung mit aktuellen Empfehlungen von Community und Behörden zur Eindämmung von Living-off-the-Land-Techniken. Behörden wie CISA, NSA, FBI und das Australian Cyber Security Centre betonen, dass Angreifern weniger Möglichkeiten gegeben werden sollten, integrierte Tools zu nutzen, indem deren Verwendung kontrolliert und die nicht vertrauenswürdigen Inhalte eingeschränkt werden, auf die sie zugreifen. Die gemeinsamen Leitlinien heben hervor, dass LOTL-Angriffe auf dem Missbrauch nativer Tools beruhen, und unterstreichen die Notwendigkeit von Kontrollen, die diesen Missbrauch begrenzen, ohne legitime Systemprozesse zu blockieren.

Das Modell von Ivanti spiegelt diese Empfehlungen wider. Trusted Ownership blockiert automatisch die nicht vertrauenswürdigen Inhalte, auf die Angreifer angewiesen sind, während eine kleine Zahl gezielter Einschränkungen die wenigen Tools adressiert, die besondere Aufmerksamkeit erfordern.

Trusted Ownership in der Praxis: Szenarien aus der realen Welt

Hier einige operative Beispiele dafür, wie Ivanti Application Control und Trusted Ownership in der Praxis funktionieren.

1. Eine portable Anwendung wird in das Benutzerprofil kopiert. Ivanti blockiert sie, weil sie im Besitz des Benutzers ist. AppLocker blockiert nur, wenn passende Regeln vorhanden sind. Ohne die richtigen Pfad- oder Herausgeberregeln kann sich das Verhalten unterscheiden.
2. Ein E-Mail-Anhang startet ein PowerShell-Skript aus „Downloads“. Ivanti lehnt es aufgrund des Benutzerbesitzes ab. AppLocker hängt von Skriptregeln ab und versetzt PowerShell bei Blockierungsereignissen in den Constrained Language Mode, der das Skript dennoch ausführt.
3. Missbrauch von Betriebssystem-Tools wie rundll32 oder mshta. Beide Modelle benötigen gezielte Deny-Härtung. Ivanti kombiniert dies mit Provenienzsteuerung, wodurch sich die Anzahl der benötigten Ausnahmen in der Regel reduziert. AppLocker stützt sich auf kuratierte Deny-Sets und erfordert regelmäßige Feinabstimmung.
4. Ein Hersteller-Update liefert neue signierte Dateien aus. Ivanti lässt das Update zu, wenn es aufgrund von Trusted Ownership über den vertrauenswürdigen Bereitstellungskanal ankommt. AppLocker kann dies mit Herausgeberregeln abbilden, doch die Wiederverwendung von Signaturen über mehrere Produkte hinweg oder ungewöhnliche Installationspfade führen häufig zu zusätzlicher Wartung und breiterem Vertrauen als beabsichtigt.
5. Ein Benutzer lädt eine JAR herunter und versucht, sie mit Java auszuführen. Ivanti blockiert den Versuch, weil die JAR vom Benutzer eingebracht wurde und Trusted Ownership nicht erfüllt. Bei Bedarf können Administratoren nur den exakt genehmigten Aufruf zulassen, indem sie die vollständige Befehlszeile abgleichen. AppLocker kann keine Argumente abgleichen und stützt sich auf Herausgeber-, Pfad- oder Hash-Regeln.

Fazit

Provenienzsteuerung verlagert Anwendungskontrolle von einem Verwaltungsproblem hin zu einem Vertrauensmodell. Statt einzelnen Dateien zu vertrauen, vertraut sie dem Prozess, über den Software auf ein System gelangt. So wird Sicherheit sowohl skalierbar als auch praktikabel.

Trusted Ownership passt genau in diesen Ansatz. Es ist weder eine Blocklist noch eine klassische Allowlist, sondern ein Modell, bei dem Software, die über einen kontrollierten IT-Prozess ankommt, standardmäßig erlaubt wird, während alles außerhalb dieses Prozesses standardmäßig abgelehnt wird. Durch die Durchsetzung auf Basis von Herkunft und Besitz statt auf Basis einzelner Ad-hoc-Dateien sind Ivanti Application Control und Ivanti Neurons for App Control deutlich besser auf moderne Angriffstechniken und die heutige Softwareverteilung ausgerichtet.

Wenn Sie Anwendungskontrolle weiterhin als Listenverwaltung behandeln, werden Sie den administrativen Aufwand spüren. Wenn Sie sie als Vertrauensgrenze betrachten, gewinnen Sie Skalierbarkeit, Sicherheit und operative Umsetzbarkeit.