AppLocker in der Praxis: Warum Anwendungssteuerung mehr schützt als jeder Virenscanner

Wie Virenschutz arbeitet

Ein Virenscanner arbeitet im Kern wie ein Türsteher mit einer Fahndungsliste. Jede Datei wird mit bekannten Merkmalen von Schadsoftware verglichen: Prüfsummen, Muster im Code, verdächtiges Verhalten. Steht die Datei auf der Liste oder ähnelt sie einem bekannten Muster, wird sie blockiert.

Das funktioniert gut für alles, was bereits bekannt ist.

Das Problem: Die Fahndungsliste ist immer eine Momentaufnahme von gestern. Angreifer bauen ihre Schadsoftware für jede Kampagne neu, versehen sie mit gültigen digitalen Signaturen frisch gegründeter Firmen und bündeln sie mit einer Anwendung, die tatsächlich funktioniert.

Ein Beispiel aus unserer eigenen SOC-Praxis: Ein Mitarbeiter sucht nach einem kostenlosen PDF-Editor, klickt auf die oberste Suchanzeige und installiert ein Programm, das gültig signiert ist und wie versprochen PDFs bearbeitet, während es im Hintergrund einen dauerhaften Zugang für die Angreifer einrichtet. Der Virenschutz meldete zu diesem Zeitpunkt nichts. Breit erkannt werden solche Varianten erfahrungsgemäß erst Wochen bis Monate später. Da ist die Software längst installiert.

Wie Anwendungssteuerung arbeitet

Anwendungssteuerung dreht das Prinzip um. Statt einer Fahndungsliste gibt es eine Gästeliste.

Nicht: "Alles darf starten, außer was ich als böse kenne."

Sondern: "Nichts darf starten, außer was ich als notwendig freigegeben habe."

Der Unterschied ist fundamental. Ein Türsteher mit Fahndungsliste muss den Angreifer kennen. Ein Türsteher mit Gästeliste muss ihn nicht kennen, er steht einfach nicht drauf.

Praktisch heißt das: Die Programme, die Ihr Unternehmen für seine Arbeit braucht – Office, Branchensoftware, Browser, ERP-Client – laufen wie gewohnt. Alles andere startet nicht. Auch dann nicht, wenn es der Benutzer heruntergeladen hat. Auch dann nicht, wenn es als Mail-Anhang kam. Auch dann nicht, wenn es gültig signiert ist und der Virenschutz es nicht kennt.

Warum das gerade den kritischen Moment abfängt

Schadsoftware, die über einen Benutzerklick ins Unternehmen kommt, landet fast immer an denselben Orten: im Download-Ordner, im Temp-Verzeichnis des Benutzerprofils, im Anhangs-Cache des Mailprogramms. Also in Verzeichnissen, in die der Benutzer schreiben darf, denn Administratorrechte hat er ja üblicherweise nicht.

Und genau das ist der weit verbreitete Trugschluss: "Ohne Adminrechte kann doch niemand etwas installieren." Systemweit installieren – richtig. Aber im eigenen Benutzerkontext ausführen? Das geht problemlos. Der Großteil moderner Schadsoftware braucht überhaupt keine Adminrechte mehr, um Zugangsdaten abzugreifen, sich dauerhaft einzunisten und Daten abzuziehen.

Eine korrekt konfigurierte Anwendungssteuerung sagt schlicht: Aus Verzeichnissen, in die Benutzer schreiben dürfen, darf nichts ausgeführt werden. Damit ist der Doppelklick auf die heruntergeladene .exe, .msi, .bat, .cmd, .ps1 oder .vbs ein Klick ins Leere, noch bevor irgendeine Erkennung greifen müsste.

Was AppLocker nicht ist

Damit die Erwartung stimmt:

• Kein Ersatz für Virenschutz/EDR. Anwendungssteuerung greift bei der Ausführung von Dateien. Angriffe, die ausschließlich im Arbeitsspeicher ablaufen, Exploits gegen laufende Software oder der Missbrauch legitimer Anwendungen laufen daran vorbei. Beides ergänzt sich, keines ersetzt das andere.

• Kein Ersatz für Monitoring. Sie brauchen weiterhin jemanden, der hinsieht – auch und gerade weil AppLocker-Blockmeldungen ein hervorragendes Frühwarnsignal sind (dazu unten mehr).

• Kein Projekt für einen Nachmittag. Ein sauberes Regelwerk erfordert eine Bestandsaufnahme und eine Testphase. Der Aufwand liegt in der Einführung, nicht im Betrieb.

• Keine Schutzmaßnahme gegen Administratoren. Wer lokale Adminrechte hat, kann die Richtlinie aushebeln. Anwendungssteuerung schützt den Normalbetrieb, nicht vor dem eigenen Domänenadmin.

Die Einordnung in einem Satz

Das australische Cyber Security Centre führt Application Control als eine der acht Basismaßnahmen seiner "Essential Eight" und bewertet die Wirksamkeit als sehr hoch. Auch die CIS Controls v8 fordern in Control 2 explizit Allowlisting für Anwendungen, Bibliotheken und Skripte. Anwendungssteuerung ist keine exotische Zusatzmaßnahme, sie ist international als eine der wirksamsten Einzelmaßnahmen anerkannt und in Windows bereits enthalten.

Ab hier wird es technisch.

Lizenz- und Systemvoraussetzungen

Ein wichtiger Punkt, der sich 2023 geändert hat und noch immer falsch kolportiert wird: AppLocker ist nicht mehr an die Enterprise-Edition gebunden. Mit KB 5024351 gilt laut Microsoft-Dokumentation:

> "As of KB 5024351, Windows 10 versions 2004 and newer and all Windows 11 versions no longer require a specific edition of Windows to enforce AppLocker policies."

Damit lässt sich AppLocker auch auf Windows 10 Pro (ab Version 2004) und Windows 11 Pro durchsetzen – für den Mittelstand der entscheidende Unterschied. Für ältere Stände gilt weiterhin: Durchsetzung per Gruppenrichtlinie nur auf Enterprise- und Server-Editionen, per MDM auf allen Editionen. Windows Server 2016, 2019, 2022 und 2025 unterstützen AppLocker vollständig, ebenso Windows Server 2012 R2.

Zwingende Betriebsvoraussetzung: Der Dienst Anwendungsidentität (AppIDSvc) muss laufen. Ohne ihn wird keine Regel ausgewertet – und zwar ohne Fehlermeldung, die Richtlinie greift schlicht nicht. Der Startmodus lässt sich auf modernen Windows-Versionen nicht mehr über services.msc ändern, sondern muss per Gruppenrichtlinie gesetzt werden:

Computerkonfiguration → Richtlinien → Windows-Einstellungen → Sicherheitseinstellungen → Systemdienste → Anwendungsidentität → Automatisch

Das ist der mit Abstand häufigste Grund für "AppLocker tut nichts". Prüfen Sie diesen Punkt zuerst.

Die fünf Regelsammlungen

AppLocker unterteilt in fünf getrennte Regelsammlungen, die einzeln aktiviert und einzeln in den Erzwingungsmodus gesetzt werden:

| Sammlung | Abgedeckte Dateitypen |

|---|---|

| Ausführbare Dateien | .exe, .com |

| Windows Installer | .msi, .msp, .mst |

| Skripte | .ps1, .bat, .cmd, .vbs, .js |

| Verpackte Apps | .appx (Store-Apps) |

| DLL | .dll, .ocx |

Der klassische Fehler: Nur die Sammlung "Ausführbare Dateien" zu aktivieren. Dann ist der Doppelklick auf rechnung.exe blockiert, der auf rechnung.bat oder install.ps1 aber nicht. Für den Schutz vor genau dem Szenario aus der Einleitung müssen mindestens EXE, Windows Installer und Skripte aktiv sein.

Die DLL-Sammlung ist ein Sonderfall: Sie erhöht die Schutzwirkung deutlich – DLL-Sideloading, also das Unterschieben einer manipulierten Bibliothek neben eine legitime Anwendung, ist bei aktuellen Kampagnen ein Standardbaustein. Sie kostet aber spürbar Performance, weil jede geladene Bibliothek geprüft wird, und erzeugt den mit Abstand größten Pflegeaufwand. Empfehlung: erst aktivieren, wenn die anderen Sammlungen stabil im Erzwingungsmodus laufen und dann zuerst nur auf besonders exponierten Systemen.

Die drei Regelbedingungen

Jede Regel basiert auf einer von drei Bedingungen:

1. Herausgeberregel (Publisher) – bewertet die digitale Signatur: Herausgeber, Produktname, Dateiname, Version. Überlebt Updates, wenn sie auf Herausgeber- oder Produktebene formuliert ist. Der Standardweg für kommerzielle Software.

2. Pfadregel (Path) – erlaubt oder verbietet alles unterhalb eines Verzeichnisses. Einfach zu pflegen, aber nur so sicher wie die Schreibrechte auf diesem Pfad. Für Erlaubnisregeln nur zulässig, wenn Benutzer dort nachweislich nicht schreiben dürfen.

3. Hashregel (Hash) – bindet die Erlaubnis an die exakte Prüfsumme. Maximal präzise, muss aber bei jedem Update erneuert werden. Sinnvoll für unsignierte Alt- und Branchensoftware, die sich selten ändert.

Wichtige Einschränkung zur Herausgeberregel: Eine gültige Signatur allein ist kein Vertrauensbeweis. Angreifer beschaffen sich regulär Code-Signing-Zertifikate über eigens gegründete Wegwerf-Firmen, inklusive Extended Validation. Und sobald ein Zertifikat widerrufen wird, beginnt der Zyklus mit der nächsten Firma. Eine Regel im Sinne von "alles, was signiert ist, darf laufen", ist praktisch wertlos. Herausgeberregeln müssen auf konkrete Herausgeber lauten – auf Ihre Softwarelieferanten, nicht auf die Eigenschaft "signiert".

Erzwingungsmodi

Pro Regelsammlung wählbar:

• Nicht konfiguriert – keine Auswertung (Achtung: wird eine Sammlung in einem verknüpften GPO befüllt, greift sie trotzdem)

• Nur überwachen (Audit) – nichts wird blockiert, jede Verletzung wird protokolliert

• Regeln erzwingen – blockiert

Der Audit-Modus ist kein optionaler Zwischenschritt, sondern der Kern eines geordneten Rollouts.

Phase 0 – Bestandsaufnahme

Ohne Inventar kein Regelwerk. Ziel dieser Phase: Welche Programme laufen tatsächlich, aus welchen Pfaden, von welchen Herausgebern?

Auf einem repräsentativen Referenzsystem:

powershell # Alle relevanten Dateien eines Verzeichnisbaums erfassen Get-AppLockerFileInformation -Directory 'C:\Program Files\' -Recurse -FileType Exe,Script,Windowsinstaller | Export-Clixml -Path .\inventar-programfiles.xml Get-AppLockerFileInformation liest zu jeder Datei Pfad, Herausgeberinformationen aus der Signatur und den Hash aus – also genau die drei Bedingungstypen. -FileType grenzt auf die Sammlungen ein, für die Sie Regeln bauen wollen.

Ergänzend lohnt der Blick auf das, was tatsächlich ausgeführt wurde, statt nur auf das, was installiert ist – dafür eignen sich die Prozessdaten aus Ihrem EDR oder SIEM deutlich besser als eine Dateisystem-Inventur.

Phase 1 – Basisregelwerk erzeugen

Zuerst die Standardregeln erzeugen lassen (in der GPO-Konsole per Rechtsklick auf die Regelsammlung → Standardregeln erstellen). Diese erlauben:

• allen Benutzern die Ausführung aus %PROGRAMFILES%

• allen Benutzern die Ausführung aus %WINDIR%

• der Gruppe Administratoren alles

Diese drei Regeln sind ein Startpunkt, kein fertiges Regelwerk – siehe Phase 4.

Für eigene Regeln aus dem Inventar:

powershell Get-AppLockerFileInformation -Directory 'C:\Program Files\' -Recurse -FileType Exe | New-AppLockerPolicy -RuleType Publisher,Hash -User 'Everyone' -RuleNamePrefix 'PF' -Optimize -Xml | Out-File .\applocker-basis.xml -Encoding utf8

Zu den Parametern: -RuleType Publisher,Hash erzeugt bevorzugt Herausgeberregeln und fällt für unsignierte Dateien automatisch auf Hashregeln zurück – die gewünschte Priorisierung. -User legt fest, für wen die Regel gilt (in deutschsprachigen Umgebungen entsprechend 'Jeder'). -Optimize fasst Regeln desselben Herausgebers zusammen und hält das Regelwerk klein. -RuleNamePrefix ist Kosmetik, macht die spätere Pflege aber erheblich einfacher.

Prüfen, bevor irgendetwas ausgerollt wird:

powershell Test-AppLockerPolicy -XmlPolicy .\applocker-basis.xml ` -Path 'C:\Users\mmustermann\Downloads\PDF-Editor-Setup.exe' ` -User 'CONTOSO\mmustermann' Test-AppLockerPolicy beantwortet für eine konkrete Datei und einen konkreten Benutzer, ob die Richtlinie sie erlauben oder blockieren würde – ohne die Richtlinie irgendwo aktiv zu schalten. Nutzen Sie das systematisch: einmal gegen eine Liste bekannter Geschäftsanwendungen (muss "Allowed" ergeben) und einmal gegen typische Angriffspfade im Benutzerprofil (muss "Denied" ergeben).

Phase 2 – Audit-Modus ausrollen

Verknüpfen Sie das GPO mit einer kleinen, repräsentativen Pilotgruppe und setzen Sie alle aktivierten Regelsammlungen auf Nur überwachen.

Computerkonfiguration → Richtlinien → Windows-Einstellungen → Sicherheitseinstellungen → Anwendungssteuerungsrichtlinien → AppLocker

> ACHTUNG: Verknüpfen Sie AppLocker-GPOs niemals initial mit der Domänenwurzel oder der OU der Domänencontroller. Ein Regelwerk, das versehentlich im Erzwingungsmodus landet und Standard-Systemprozesse nicht abdeckt, macht Systeme unbenutzbar – auf einem Terminalserver mit 50 aktiven Sitzungen sofort und für alle gleichzeitig. Pilotgruppe, dann Wellen.

Laufzeit der Audit-Phase: mindestens vier Wochen. Sie brauchen mindestens einen Monatsabschluss, einen Patchday und einen Urlaubsvertretungszyklus im Datenbestand, sonst fehlen Ihnen genau die Anwendungen, die selten laufen – und die dann im Erzwingungsmodus als Störung auflaufen.

Phase 3 – Audit-Ergebnisse auswerten

AppLocker protokolliert in eigene Ereignisprotokolle:

Anwendungs- und Dienstprotokolle → Microsoft → Windows → AppLocker ├── EXE and DLL ├── MSI and Script ├── Packaged app-Deployment └── Packaged app-Execution

Die relevanten Ereignis-IDs:

| ID | Protokoll | Bedeutung |

|---|---|---|

| 8002 | EXE and DLL | Ausführung erlaubt |

| 8003 | EXE and DLL | Im Audit-Modus zugelassen – wäre im Erzwingungsmodus blockiert worden |

| 8004 | EXE and DLL | Blockiert |

| 8005 | MSI and Script | Ausführung erlaubt |

| 8006 | MSI and Script | Im Audit-Modus zugelassen – wäre blockiert worden |

| 8007 | MSI and Script | Blockiert |

Die 8003er und 8006er sind Ihre Arbeitsliste. Auswertung über alle Pilotsysteme hinweg:

powershell Get-WinEvent -FilterHashtable @{ LogName = 'Microsoft-Windows-AppLocker/EXE and DLL' Id = 8003 StartTime = (Get-Date).AddDays(-30) } | ForEach-Object { $x = [xml]$_.ToXml() [pscustomobject]@{ Zeit = $_.TimeCreated Datei = $x.Event.UserData.RuleAndFileData.FilePath Hash = $x.Event.UserData.RuleAndFileData.FileHash User = $x.Event.UserData.RuleAndFileData.TargetUser } } | Group-Object Datei | Sort-Object Count -Descending | Select-Object Count, Name -First 50

Der Umweg über ToXml() ist bewusst gewählt: Die AppLocker-Ereignisse legen ihre Nutzdaten strukturiert im Knoten UserData/RuleAndFileData ab. Ein Auswerten des reinen Meldungstextes ist sprach- und formatabhängig und bricht bei der nächsten Windows-Version.

Jeder Treffer wird einer von drei Kategorien zugeordnet:

1. Legitim und notwendig → Regel ergänzen, bevorzugt als Herausgeberregel.

2. Legitim, aber am falschen Ort → Software korrekt nach %PROGRAMFILES% ausrollen, statt eine Ausnahme für einen Benutzerpfad zu bauen. Dieser Punkt entscheidet über die Qualität des gesamten Regelwerks.

3. Weder legitim noch notwendig → nichts tun. Genau dafür ist das Projekt da.

Phase 4 – Das Regelwerk härten

Hier trennt sich funktionierendes von wirksamem AppLocker. Die Standardregeln erlauben pauschal %WINDIR%. Das Problem: Unterhalb von C:\Windows existieren Verzeichnisse, in die auch normale Benutzer schreiben dürfen. Wer sie nicht ausnimmt, hat eine dokumentierte Umgehung im eigenen Regelwerk stehen – der Angreifer kopiert seine Datei einfach dorthin.

Nehmen Sie diese Pfade als Ausnahme in die %WINDIR%-Erlaubnisregel auf:

%SYSTEM32%\spool\drivers\color %SYSTEM32%\spool\PRINTERS %SYSTEM32%\spool\SERVERS %SYSTEM32%\Tasks %SYSTEM32%\FxsTmp %SYSTEM32%\com\dmp %SYSTEM32%\Microsoft\Crypto\RSA\MachineKeys %WINDIR%\Tasks %WINDIR%\Temp %WINDIR%\tracing %WINDIR%\debug\WIA %WINDIR%\Registration\CRMLog %WINDIR%\SysWOW64\FxsTmp %WINDIR%\SysWOW64\com\dmp %WINDIR%\SysWOW64\Tasks %WINDIR%\SysWOW64\tracing

Prüfen Sie zusätzlich mit einem Werkzeug wie accesschk aus den Sysinternals, ob in Ihrer Umgebung weitere beschreibbare Verzeichnisse unterhalb der erlaubten Pfade existieren – etwa durch schlecht paketierte Branchensoftware, die ihr Verzeichnis unter %PROGRAMFILES% mit Schreibrechten für "Jeder" anlegt:

cmd accesschk.exe -w -u -s "Benutzer" "C:\Program Files" > schreibbar-pf.txt -w prüft auf Schreibzugriff, -u unterdrückt Fehlerausgaben, -s arbeitet rekursiv. Jeder Treffer in dieser Datei ist eine potenzielle Umgehung Ihres Regelwerks und gehört entweder rechtekorrigiert oder als Ausnahme aufgenommen.

Zweite Härtungsebene: mitgelieferte Windows-Programme, die fremden Code ausführen. Ein erlaubtes %WINDIR% erlaubt auch die Werkzeuge, mit denen sich Anwendungssteuerung aushebeln lässt. Microsoft pflegt dazu eine offizielle Blockliste ("recommended block rules"). Praktisch immer sperren sollten Sie unter anderem:

mshta.exe – führt HTML-Anwendungen samt Skriptcode aus msbuild.exe – kompiliert und startet beliebigen C#-Code aus XML-Projektdateien installutil.exe – startet Code über .NET-Installer-Klassen regsvr32.exe – lädt Code über Scriptlets, auch aus dem Netz wmic.exe – Ausführung über XSL-Transformationen presentationhost.exe – startet XBAP-Anwendungen cdb.exe, kd.exe, ntsd.exe, windbg.exe – Debugger, führen beliebigen Code aus csi.exe, rcsi.exe, dnx.exe, fsi.exe – interaktive Compiler/Skripthosts bash.exe, wsl.exe, wslconfig.exe – Ausführung außerhalb des Windows-Regelwerks

> ACHTUNG: Diese Liste ist nicht folgenlos. regsvr32.exe und msbuild.exe werden von Softwareverteilung, Entwicklungsumgebungen und manchen Setup-Routinen legitim genutzt. Sperren Sie diese Programme deshalb zuerst im Audit-Modus und werten Sie die 8003er-Ereignisse aus, bevor Sie erzwingen – und nehmen Sie Ihre Verteilungskonten gezielt als Ausnahme auf.

Dritte Ebene: Skripte. Sobald die Skript-Sammlung im Erzwingungsmodus läuft, schaltet Windows PowerShell für nicht erlaubte Skripte automatisch in den Constrained Language Mode. Damit fallen genau die Sprachfeatures weg, die für dateilose Angriffe genutzt werden – etwa das direkte Ansprechen von .NET-Klassen und Windows-API-Aufrufen. Dieser Nebeneffekt ist einer der stärksten Sicherheitsgewinne der gesamten Maßnahme und wird regelmäßig übersehen.

Phase 5 – Erzwingen, in Wellen

Reihenfolge, die sich in der Praxis bewährt hat:

1. Terminalserver und RDS-Umgebungen zuerst. Höchstes Risiko (viele Benutzer, ein System), gleichzeitig das homogenste Softwareprofil – dort ist das Regelwerk am schnellsten stabil.

2. Standardarbeitsplätze nach Abteilungen, in Wellen von jeweils 10–20 % der Systeme, mit mindestens einer Woche Abstand.

3. Sonderfälle zum Schluss: Entwicklung, Konstruktion, Labor. Diese Gruppen brauchen fast immer eigene Regelwerke und manchmal dauerhaft den Audit-Modus mit engmaschiger Überwachung.

4. Administrative Systeme nicht vergessen – die Standardregel "Administratoren dürfen alles" ist bequem, hebelt aber genau auf den kritischsten Systemen den Schutz aus. Für Admin-Workstations lohnt ein eigenes, engeres Regelwerk.

Vor jeder Welle die wirksame Richtlinie auf einem Zielsystem gegenprüfen:

powershell Get-AppLockerPolicy -Effective -Xml | Out-File .\effective.xml

Das liefert die tatsächlich am Client zusammengesetzte Richtlinie aus allen wirkenden GPOs. Achtung, häufige Fehlerquelle: AppLocker-GPOs werden nicht zusammengeführt wie andere Richtlinien – die Regelsammlungen mehrerer GPOs werden vereinigt, aber der Erzwingungsmodus kommt aus dem GPO mit der höchsten Priorität. Arbeiten Sie deshalb möglichst mit einem führenden AppLocker-GPO pro Systemklasse.

Lokal lässt sich der aktuelle Stand außerdem hier verifizieren:

HKLM\SOFTWARE\Policies\Microsoft\Windows\SrpV2\{Exe|Dll|Msi|Script|Appx}

Phase 6 – Betrieb und Ausnahmeprozess

Anwendungssteuerung scheitert selten an der Technik und häufig am fehlenden Prozess. Klären Sie vor dem Erzwingen:

• Wer darf eine Ausnahme genehmigen? Nicht der Helpdesk im Einzelfall, sondern eine benannte Rolle mit Sicherheitsverantwortung.

• Wie lange dauert eine Freigabe? Verbindliche Zusage, idealerweise unter vier Stunden. Wird die Ausnahme zum Nadelöhr, entsteht Druck, das ganze Regelwerk aufzuweichen.

• Wie sieht die Standardantwort aus? In den allermeisten Fällen lautet sie nicht "Ausnahme für den Download-Ordner", sondern "wir paketieren die Software und verteilen sie korrekt".

• Wer prüft das Regelwerk turnusmäßig? Hashregeln veralten mit jedem Update, Herausgeberregeln überleben Firmenübernahmen nicht immer. Ein halbjährlicher Review ist das Minimum.

Ein Aspekt, der in reinen Härtungsprojekten fast immer verschenkt wird: Jedes AppLocker-Blockereignis ist ein sicherheitsrelevantes Signal.

Ein Ereignis 8004 aus dem Download-Ordner eines Sachbearbeiters bedeutet: Diese Person hat gerade versucht, ein nicht freigegebenes Programm auszuführen. Das ist im günstigen Fall ein Prozessproblem und im ungünstigen Fall die erste Meldung eines laufenden Angriffs, Minuten nach dem Klick und Wochen bevor irgendeine Signatur die Datei kennt.

Deshalb gehören die AppLocker-Protokolle in Ihr SIEM und zwar nicht als Archiv, sondern mit ausgewerteten Regeln darauf. Besonders lohnend sind drei Blickwinkel:

• Blockereignisse aus Benutzer-Schreibpfaden (\Downloads\, \AppData\Local\Temp\, \AppData\Roaming\) – hier wird genau das Szenario aus der Einleitung sichtbar.

• Häufungen über Systeme hinweg – derselbe Dateiname, kurz hintereinander auf mehreren Rechnern blockiert, deutet auf eine laufende Kampagne hin, nicht auf einen Einzelfall.

• Systeme, die plötzlich still werden – liefert ein Client gar keine AppLocker-Ereignisse mehr, ist möglicherweise der AppIDSvc gestoppt. Das ist selbst ein Alarm.

Der Nebeneffekt ist erheblich: Aus einer präventiven Maßnahme wird zusätzlich ein Sensor, der ohne weitere Lizenzkosten genau an der Stelle sitzt, an der Angriffe beginnen. In unseren SOC-Mandaten übernehmen wir genau diese Auswertung. Wer AppLocker selbst betreibt, sollte die Protokolle mindestens nicht ungelesen lassen.

Damit die Erwartungshaltung im Projekt stimmt – das sind die Punkte, an denen AppLocker nicht hilft:

• Missbrauch erlaubter Anwendungen. Ein Makro in einem erlaubten Office, ein bösartiges Add-in, ein Angriff über eine Schwachstelle im erlaubten Browser – all das läuft innerhalb der Gästeliste ab.

• Reine In-Memory-Angriffe. Code, der nie als Datei auf die Platte kommt, wird nicht geprüft.

• Signierte, aber bösartige Software bei zu breit gefassten Herausgeberregeln (siehe oben).

• Lokale Administratoren. Wer Adminrechte hat, kann Regeln ändern oder den Dienst stoppen.

• Schlecht gepflegte Regelwerke. Eine Erlaubnisregel für einen benutzerbeschreibbaren Pfad, in einer stressigen Woche als "temporäre Lösung" eingetragen, hebelt die gesamte Maßnahme aus. Der größte Feind der Anwendungssteuerung ist nicht der Angreifer, sondern die schleichende Aufweichung.

Und der strategische Ausblick: Microsoft positioniert App Control for Business (früher WDAC) als die weitergehende Technologie – kernel-nah durchgesetzt, deutlich schwerer zu umgehen, dafür aufwendiger in Einführung und Pflege. AppLocker bleibt unterstützt und ist für den Mittelstand in aller Regel der pragmatische Einstieg. Wer heute mit einem sauberen AppLocker-Regelwerk arbeitet, hat die eigentliche Vorarbeit – das Softwareinventar und den Ausnahmeprozess – für einen späteren Umstieg bereits geleistet.

| Rahmenwerk | Bezug |

|---|---|

| ISO/IEC 27001:2022 | Anhang A, 8.19 "Installation von Software auf Systemen im Betrieb"; 8.7 "Schutz vor Malware" |

| CIS Controls v8 | Control 2 – 2.5 Allowlisting Anwendungen, 2.6 Bibliotheken, 2.7 Skripte |

| ACSC Essential Eight | "Application Control" als eine der acht Basismaßnahmen |

| BSI IT-Grundschutz | SYS.2.2.3 (Clients unter Windows), SYS.1.9 (Terminalserver) |

| NIS2 | Maßnahmen der grundlegenden Cyberhygiene nach Art. 21 |

Für Auditsituationen praktisch: Der Audit-Modus liefert nicht nur die Grundlage für das Regelwerk, sondern auch den Nachweis, dass die Maßnahme wirksam ist – protokolliert, auswertbar und mit Zeitstempel.

Virenschutz beantwortet die Frage "Kenne ich diese Datei als bösartig?". Bei professionell betriebenen Kampagnen mit gültigen Signaturen und laufend neu gebauten Binaries lautet die Antwort für Wochen bis Monate: nein.

Anwendungssteuerung beantwortet eine andere Frage: "Brauchen wir diese Datei für unsere Arbeit?" Und die Antwort darauf ist stabil, unabhängig davon, wie neu, wie gut getarnt oder wie schön signiert die Schadsoftware ist.

Deshalb ist AppLocker in unseren Projekten kein Zusatzmodul, sondern Grundschutz, gerade dort, wo mehrere Benutzer auf denselben Systemen arbeiten. Unser SOC erkennt einen Vorfall schnell. Ein sauberes AppLocker-Regelwerk sorgt dafür, dass es gar nicht erst einer wird.

Wenn Sie wissen möchten, ob und mit welchem Aufwand sich Anwendungssteuerung in Ihrer Umgebung einführen lässt: Der erste Schritt ist eine Bestandsaufnahme im Audit-Modus – ohne Eingriff in den laufenden Betrieb und mit einem belastbaren Bild nach wenigen Wochen. Sprechen Sie uns gerne an.