Ausgangslage: Standardbenutzer können mehr Code starten als sie benötigen

Auf vielen Windows-Arbeitsplätzen entscheidet allein der Benutzer, welche ausführbare Datei gestartet wird. Softwareverteilung, Endpoint Protection und eingeschränkte lokale Rechte schaffen zwar Leitplanken, verhindern aber nicht jede portable Anwendung, jedes Skript oder jeden Installer aus einem beschreibbaren Verzeichnis. Ein Download, ein entpacktes Tool unter %LOCALAPPDATA% oder eine Datei auf einem Netzlaufwerk kann damit Teil der ausführbaren Fläche werden, obwohl sie nie freigegeben wurde.

AppLocker dreht dieses Modell für definierte Dateitypen um. Sobald eine Regelkollektion Regeln enthält und erzwungen wird, bewertet AppLocker Dateien gegen die enthaltenen Allow- und Deny-Regeln. Bei Executables, Installern, DLLs und Packaged Apps werden nicht erlaubte Dateien abgewiesen. Bei Skripten setzt dagegen der jeweilige Script-Host die AppLocker-Entscheidung um, sodass die konkrete Wirkung abweichen kann. Regeln lassen sich nach Publisher, Pfad oder Dateihash aufbauen und über Gruppenrichtlinien an Domänencomputer verteilen. Die Entscheidung kann zusätzlich auf Benutzer oder Gruppen begrenzt werden.

Das klingt einfacher, als es im Betrieb ist. Eine zu breite Pfadregel lässt weiterhin beliebigen Code zu. Eine zu enge Hash-Regel bricht beim nächsten Update. Eine ungetestete Aktivierung kann Softwareverteilung, Anmeldeskripte oder Supportwerkzeuge blockieren. AppLocker ist deshalb kein einzelner GPO-Schalter, sondern ein Application-Control-Projekt mit Inventar, Regelpflege, Telemetrie und einer getesteten Rückfalloption.

Auch die Schutzwirkung braucht eine klare Grenze. AppLocker reduziert die Ausführung nicht freigegebener Anwendungen für verwaltete Benutzer und Systeme. Es ersetzt weder EDR noch Patchmanagement, Makroschutz, Browserkontrollen oder sichere Administratorpfade. Lokale Administratoren und bereits erlaubte, missbrauchbare Programme bleiben ein eigenes Risiko. Wenn eine stärkere, systemweite Code-Integrity-Grenze gefordert ist, gehört App Control for Business in die Zielarchitektur.

Zielbild: Die Benutzer-Ausführungsfläche folgt erklärten Vertrauensquellen

Ein belastbarer Zielzustand ist konkret:

  1. Geräteklassen besitzen getrennte Policies. Standard-Clients, Entwicklerarbeitsplätze, Admin-Systeme, Member Server und Domain Controller teilen nicht blind dieselbe Allowlist.
  2. Jede Regelkollektion hat einen expliziten Modus. Audit only und Enforce rules werden bewusst gesetzt; Not configured bleibt nicht als vermeintlich neutraler Zustand stehen.
  3. Publisher-Regeln sind der Normalfall für signierte Software. Sie binden Vertrauen an einen konkreten Herausgeber, ein Produkt und bei Bedarf eine Datei oder Versionsgrenze.
  4. Pfadregeln gelten nur für administrativ geschützte Verzeichnisse. Standardbenutzer können in keinem freigegebenen Pfad Dateien anlegen oder ersetzen.
  5. Hash-Regeln bleiben die begrenzte Ausnahme. Sie decken stabile, nicht signierte Dateien ab und besitzen einen Owner für jedes Update.
  6. Die Application-Identity-Funktion ist Teil der Baseline. Der Dienst AppIDSvc startet auf den Zielsystemen zuverlässig, damit Regeln nicht nur verteilt, sondern auch ausgewertet werden.
  7. Dienste sind bewusst aus- oder eingeschlossen. Standardmäßig erfasst AppLocker nur Code im Benutzerkontext. Die optionale Service-Enforcement-Erweiterung wird nur mit vollständiger Windows-Systemcode-Freigabe und gesondertem Test aktiviert.
  8. Audit-Ereignisse werden zentral gesammelt und bewertet. Ein Event wird nicht automatisch zur neuen Allow-Regel; Anwendung, Owner, Quelle und geschäftlicher Bedarf werden geprüft.
  9. Enforcement erfolgt in Ringen und je Regelkollektion. Executables, Installer, Skripte, Packaged Apps und DLLs werden nicht gleichzeitig und ohne Messphase scharf geschaltet.
  10. Rollback und Notfalladministration sind getestet. Ein fehlerhaftes Regelwerk kann über einen kontrollierten GPO-Pfad zurück auf Audit gesetzt werden, ohne unkontrollierte lokale Ausnahmen zu verteilen.

Der Kern ist nicht eine möglichst lange Regelliste. Das Ziel ist eine kleine Zahl nachvollziehbarer Vertrauensentscheidungen, die normale Updates übersteht und Abweichungen sichtbar macht.

Umsetzung: aus Laufzeitdaten eine wartbare Policy bauen

1) Scope und Betriebsmodell vor den Regeln festlegen

Beginne nicht mit einer generierten Default-Policy für die gesamte Domäne. Lege zuerst fest, welche Systemgruppen denselben Softwarebestand und dieselbe Betriebsweise haben. Ein sinnvoller erster Scope sind standardisierte Büro-Clients mit zentraler Softwareverteilung. Entwicklergeräte, OT-Systeme, Kiosks, Citrix- oder RDS-Hosts und Server erhalten eigene Bewertungen.

Für jede Geräteklasse braucht es mindestens:

  • einen technischen Policy-Owner,
  • einen fachlichen Freigabeprozess für neue Anwendungen,
  • eine Pilotgruppe mit realen Benutzerprofilen,
  • einen Kanal für AppLocker-Events und Supportfälle,
  • ein Wartungsfenster für Updates am Regelwerk,
  • einen dokumentierten Rollback-Pfad.

Domain Controller gehören nicht in die erste Client-Welle. Auf ihnen ist die ausführbare Fläche klein, die Auswirkung eines Fehlers aber hoch. Falls AppLocker dort eingesetzt wird, braucht es eine separate Server-Policy, vollständige Abdeckung der Verwaltungs- und Sicherungswerkzeuge sowie getesteten Konsolen- oder Out-of-Band-Zugriff.

Standardmäßig bewertet AppLocker nur Code im Kontext eines Benutzers, nicht Dienste und andere Nicht-Benutzerprozesse wie SYSTEM. Die optionale Services-Enforcement-Erweiterung gilt nur für EXE- und DLL-Kollektionen und wird direkt im Policy-XML konfiguriert. Sie muss zusammen mit der System-Apps-Erweiterung geplant werden, damit sämtlicher Windows-Systemcode erlaubt bleibt. Auf Servern ist das ein eigener Design- und Testschritt, kein beiläufiger Zusatz zur Client-GPO.

2) Eine dedizierte GPO im Audit-Modus aufbauen

Lege eine klar benannte GPO an und verknüpfe sie zunächst nur mit der Pilot-OU oder einer eng gefilterten Pilotgruppe. Die AppLocker-Einstellungen liegen unter:

Computerkonfiguration
  Richtlinien
    Windows-Einstellungen
      Sicherheitseinstellungen
        Anwendungssteuerungsrichtlinien
          AppLocker

Setze die benötigten Regelkollektionen in den AppLocker-Eigenschaften ausdrücklich auf Audit only. Der Zustand Not configured ist riskant missverständlich: Enthält eine Kollektion Regeln, können diese abhängig von der wirksamen GPO-Reihenfolge trotzdem erzwungen werden. Der gewünschte Modus muss deshalb sichtbar konfiguriert sein.

Konfiguriere in derselben oder einer eindeutig gekoppelten GPO unter Systemdienste den Dienst Application Identity auf automatischen Start. AppLocker nutzt AppIDSvc, um die Identität von Dateien zu bestimmen. Eine verteilte Policy ohne laufenden Dienst ist kein wirksamer Kontrollzustand.

Prüfe nach dem ersten Policy Refresh auf einem Pilotsystem nicht nur die GPMC, sondern das Ergebnis:

Get-Service -Name AppIDSvc
Get-AppLockerPolicy -Effective -Xml

Der Export der wirksamen Policy gehört auch in die Change-Dokumentation. Regeln aus mehreren verknüpften GPOs werden zusammengeführt, während der Enforcement-Modus der GPO-Priorität folgt. Eine einzelne GPO-Ansicht beweist deshalb nicht, welche Policy der Client tatsächlich anwendet.

3) Default Rules nur als Bootstrap behandeln

AppLocker kann für jede Kollektion Default Rules erzeugen; die Regelsets unterscheiden sich jedoch. EXE-, Script- und DLL-Defaults erlauben typischerweise Everyone Inhalte unter %WINDIR% und %PROGRAMFILES% sowie alle passenden Dateien für lokale Administratoren. Die Windows-Installer-Defaults erlauben Everyone zusätzlich alle digital signierten Installer und %WINDIR%\Installer; die Packaged-App-Default-Regel erlaubt Everyone alle signierten Pakete und Paketinstaller.

Diese Regeln sind ein Startpunkt, keine fertige Sicherheitsbaseline. Vor einer Pfadfreigabe muss geprüft werden, ob Standardbenutzer oder ein von ihnen steuerbarer Prozess Dateien in diesem Verzeichnis schreiben, umbenennen oder ersetzen kann. Eine Allow-Regel für einen beschreibbaren Ordner ist praktisch eine Freigabe für jeden dort abgelegten Code. Prüfe deshalb ACLs, Installer-Verhalten, Updater-Verzeichnisse und Junctions statt nur den sichtbaren Pfadnamen.

Auch die breite Administratorregel muss zum Ziel passen. AppLocker ist nicht dafür ausgelegt, einen bereits lokalen Administrator zuverlässig einzuschließen. Wenn administrative Konten Teil des Bedrohungsmodells sind, braucht es zusätzliche Kontrollen und gegebenenfalls App Control for Business; eine kosmetisch engere AppLocker-Regel ändert diese Grenze nicht.

4) Regeltypen nach Wartbarkeit auswählen

Für EXE-, Windows-Installer-, Script- und DLL-Kollektionen stehen Publisher-, Pfad- und Hashbedingungen zur Verfügung; Packaged-App-Regeln unterstützen ausschließlich Publisher-Bedingungen. Nutze sie bewusst:

  • Publisher: geeignet für digital signierte Standardsoftware. Begrenze nach Möglichkeit auf Herausgeber, Produkt und Dateiname. Eine pauschale Regel für alle signierten Dateien oder alle Produkte eines Publishers ist oft breiter als der Geschäftsbedarf. Definiere Versionsgrenzen so, dass Sicherheitsupdates weiterhin laufen, alte verwundbare Versionen aber nicht dauerhaft freigegeben bleiben.
  • Path: geeignet für administrativ kontrollierte Installationsverzeichnisse und klar geschützte interne Shares. Vermeide Benutzerprofile, Temp-Verzeichnisse, Download-Ordner, beschreibbare Netzpfade und breite Wurzeln wie C:\*.
  • File hash: geeignet für eine stabile, nicht signierte Einzeldatei. Nach jedem Update ändert sich der Hash. Ohne Owner, Paketprozess und Ablaufdatum entsteht schnell eine Sammlung veralteter Ausnahmen.

Explizite Deny-Regeln haben Vorrang vor Allow-Regeln. Sie sind sinnvoll, wenn eine eng umrissene Datei aus einer sonst benötigten Publisher- oder Pfadfreigabe ausgeschlossen werden muss. Als primäre Blockliste sind sie ungeeignet: Dateiname, Pfad oder Hash ändern sich, während die gesamte übrige ausführbare Fläche offen bleibt. Eine Allowlist entsteht durch definierte Allow-Regeln und implizites Verweigern, nicht durch tausende Deny-Einträge.

5) Regelkollektionen getrennt pilotieren

AppLocker verwaltet fünf Kollektionen:

  • Executables für PE-Dateien, typischerweise .exe und .com, wobei die Endung für die Prüfung nicht maßgeblich ist,
  • Windows Installer für .msi, .msp und .mst,
  • Scripts für .ps1, .bat, .cmd, .vbs und .js,
  • Packaged Apps und deren Installer,
  • DLLs für .dll und .ocx.

Beginne meist mit Executables und Windows Installer. Vor dem Erzwingen der EXE-Kollektion muss die Packaged-App-Kollektion jedoch explizit geregelt sein: Sind EXE-Regeln erzwungen und fehlen Packaged-App-Regeln, blockiert AppLocker alle Packaged Apps und deren Installer. Soll ihre Einschränkung später erfolgen, erstelle zunächst die Default-Allow-Regel für alle signierten Packaged Apps und Paketinstaller und verschärfe sie erst nach dem Pilot.

Die Script-Kollektion braucht einen eigenen Test für Logon-Skripte, Softwareverteilung, Management-Agenten und administrative Automatisierung. Die Durchsetzung übernimmt der jeweilige Script-Host. Ein von AppLocker nicht erlaubtes Windows-PowerShell-Skript wird als blockiert protokolliert, läuft jedoch im Constrained Language Mode weiter. AppLocker deckt außerdem nicht jede Form interpretierten Codes ab; Office-Makros und Script-Hosts ohne AppLocker-Integration benötigen eigene Richtlinien.

DLL-Regeln sollten zuletzt und separat betrachtet werden. Jede geladene Bibliothek muss zu einer Allow-Regel passen. Das erhöht Komplexität, Eventvolumen und auf ressourcenarmen Systemen möglicherweise den Aufwand. Eine unvollständige DLL-Allowlist kann Anwendungen an Stellen brechen, die im reinen EXE-Pilot nicht sichtbar waren.

6) Auditdaten mit Geschäftskontext auswerten

Die relevanten Kanäle liegen unter Microsoft-Windows-AppLocker, insbesondere EXE and DLL, MSI and Script sowie die Kanäle für Packaged Apps. Eine lokale Stichprobe für die letzten sieben Tage ist rein lesend:

$start = (Get-Date).AddDays(-7)

Get-WinEvent -FilterHashtable @{
  LogName   = 'Microsoft-Windows-AppLocker/EXE and DLL'
  StartTime = $start
} | Select-Object TimeCreated, Id, LevelDisplayName, Message

Für das Projekt gehören diese Daten zentral in Windows Event Forwarding, EDR oder SIEM. Aggregiere mindestens Dateipfad, Publisher, Hash, Benutzer, Gerät, Regelkollektion, Häufigkeit und bisherige Entscheidung. Priorisiere Ereignisse aus Benutzerprofilen, Temp-Pfaden, Wechselmedien und nicht verwalteten Shares.

Audit-Telemetrie zeigt, was ausgeführt wurde, nicht was vertrauenswürdig ist. Ein automatisch aus jedem Event erzeugtes Regelwerk würde auch unerwünschte portable Tools, alte Installer und einmalige Supportdateien legitimieren. Vor einer Allow-Regel müssen Softwarekatalog, Paketquelle, Signatur, Owner, Lizenzstatus und benötigter Scope geklärt sein.

Teste kritische Dateien zusätzlich gegen die wirksame Policy und einen repräsentativen Benutzer:

$policy = Get-AppLockerPolicy -Effective

Test-AppLockerPolicy -PolicyObject $policy `
  -Path 'C:\Program Files\Vendor\Application\app.exe' `
  -User 'CORP\PilotUser'

Der Test ersetzt keinen echten Start mit Abhängigkeiten, liefert aber eine reproduzierbare Vorprüfung für Change und Rollback.

7) Enforcement in Ringen freigeben

Ein praxistauglicher Rollout verläuft über mehrere Ringe:

  1. Referenzsysteme und IT-Lab,
  2. Security- und Workplace-Team,
  3. repräsentative Fachanwender je Gerätekategorie,
  4. einzelne Abteilungen oder Standorte,
  5. breite Client-Fläche,
  6. getrennte Servergruppen mit eigener Policy.

Jeder Ring muss mindestens einen normalen Patch- und Softwareupdate-Zyklus sehen. Messe blockierte und nur auditierte Dateien, Supporttickets, Startfehler, Policy-Laufzeit und Geräte ohne aktuelle GPO. Erst wenn bekannte Geschäftssoftware, Updatepfade und Recovery-Werkzeuge abgedeckt sind, wechselt die betreffende Kollektion von Audit only auf Enforce rules.

Schalte nicht alle Kollektionen gleichzeitig um. Ein blockierter Installer ist anders zu behandeln als ein blockiertes Logon-Skript oder eine fehlende DLL. Getrennte Changes verkleinern den Fehlerraum und machen die Ursache im Betrieb erkennbar.

8) Updates, Ausnahmen und Rollback als Dauerbetrieb planen

Application Control endet nicht mit dem Go-live. Neue Software, geänderte Signaturen, Herstellerwechsel, interne Builds und Self-Updater verändern die Policy. Jede Ausnahme braucht daher Anwendung, Regeltyp, Scope, Owner, Begründung, Genehmigung und Review-Datum. Temporäre Hash-Regeln sollten automatisch in eine Review-Liste laufen.

Sichere vor Änderungen die GPO und exportiere die AppLocker-Policy als XML. Bearbeite eine erzwungene Produktionskollektion nicht spontan. Änderungen werden auf einer Kopie beziehungsweise im Audit-Scope getestet und anschließend versioniert übernommen.

Zur unmittelbaren Entschärfung kann eine vorbereitete, höher priorisierte Recovery-GPO die gesamte wirksame, aus allen GPOs zusammengeführte Kollektion auf Audit only setzen. Sie entfernt keine fehlerhaften Regeln. Bevor die Recovery-GPO zurückgenommen wird, müssen die betroffenen Regeln oder Links korrigiert, der Policy Refresh erfolgreich durchgeführt und Get-AppLockerPolicy -Effective geprüft sein. Offline-Geräte behalten bis zur erfolgreichen Aktualisierung ihren bisherigen Zustand. Das Abschalten von AppIDSvc oder lokale Einzeländerungen sind kein sauberer Rückfallprozess.

Vorteile

  • Kleinere ausführbare Fläche: Nicht freigegebene portable Programme und Installer werden in erzwungenen Kollektionen standardmäßig abgewiesen; für unterstützte Skripte greift die hostabhängige Einschränkung.
  • Nutzt bestehende AD-Verteilung: Gruppenrichtlinien, OUs, Security Filtering und bestehende Change-Prozesse können für den Rollout verwendet werden.
  • Liefert konkrete Telemetrie: Audit-Ereignisse zeigen reale Softwarepfade, Schatten-IT und fehlende Paketprozesse.
  • Erlaubt abgestufte Einführung: Jede Regelkollektion und Gerätegruppe kann separat beobachtet und erzwungen werden.
  • Unterstützt wartbare Vertrauensregeln: Publisher-Regeln überstehen Updates besser als reine Hashlisten.
  • Ergänzt Endpoint-Schutz: Application Control begrenzt, was starten darf; EDR bewertet weiterhin Verhalten und Folgeschritte.

Nachteile und Grenzen

  • Hoher Pflegebedarf bei heterogener Software: Viele interne, portable oder unsignierte Anwendungen erzeugen Regel- und Testaufwand.
  • Kein Schutz vor jedem erlaubten Programm: Ein freigegebenes, missbrauchbares Werkzeug bleibt ausführbar; AppLocker kontrolliert nicht dessen vollständiges Verhalten.
  • Lokale Administratoren bleiben eine harte Grenze: Wer das System administrativ kontrolliert, kann lokale Zustände und erlaubte Ausführungspfade beeinflussen.
  • Keine vollständige Script- oder Makrokontrolle: Nicht jeder Interpreter und keine Office-Makros werden durch die Script-Kollektion abgedeckt.
  • DLL-Regeln erhöhen Komplexität: Vollständigkeit, Performance und Updateverträglichkeit müssen separat getestet werden.
  • GPO-Latenz beeinflusst Recovery: Offline-Geräte und langsame Standorte erhalten Korrekturen nicht sofort.
  • Stärkere Ziele benötigen andere Technik: Für eine robustere, systemweite Code-Integrity-Policy ist App Control for Business die passendere Zielplattform.

Typische Stolperfallen

  • Direkt mit Enforce rules starten: Ohne Auditdaten werden legitime Anwendungen und Recovery-Werkzeuge erst im Ausfall sichtbar.
  • Not configured für wirkungslos halten: Vorhandene Regeln können dennoch erzwungen werden; jeder Modus muss explizit gesetzt sein.
  • Application Identity vergessen: Eine GPO ohne zuverlässig laufenden AppIDSvc erzeugt nur einen scheinbaren Kontrollzustand.
  • Default Rules ungeprüft übernehmen: Besonders breite Pfad- und Administratorregeln können dem eigentlichen Ziel widersprechen.
  • Benutzerbeschreibbare Pfade erlauben: Eine Allow-Regel auf %LOCALAPPDATA%, Temp oder einen schwach berechtigten Share erlaubt faktisch beliebige Dateien.
  • Signiert mit vertrauenswürdig gleichsetzen: Eine breite Publisher-Regel kann mehr Produkte und Werkzeuge freigeben als beabsichtigt.
  • Nur Hash-Regeln verwenden: Sicherheitsupdates und Versionswechsel erzeugen dann laufend neue Ausfälle und Ausnahmen.
  • Audit-Events automatisch erlauben: Beobachtete Ausführung ist kein Freigabenachweis.
  • Deny-Liste statt Allowlist bauen: Varianten und neue Pfade umgehen die Liste, während unbekannte Software grundsätzlich weiterläuft.
  • Alle Gerätegruppen gleich behandeln: Entwickler, Kiosks, RDS-Hosts und Server haben unterschiedliche ausführbare Baselines.
  • Alle Kollektionen gemeinsam erzwingen: Fehler lassen sich schwer zuordnen und der Rollback wird unnötig breit.
  • Nur die bearbeitete GPO prüfen: Zusammengeführte Regeln und GPO-Priorität können auf dem Client ein anderes Ergebnis erzeugen.
  • Keinen Updatezyklus pilotieren: Erst ein Herstellerupdate zeigt, ob Publisher-, Pfad- und Hash-Entscheidungen wartbar sind.
  • AppLocker als EDR-Ersatz betrachten: Erlaubte Anwendungen, Makros, Browserinhalte und Verhalten nach dem Start brauchen weiterhin eigene Kontrollen.

Projekt-Checkliste

  • [ ] Geräteklassen, Pilotgruppen und einen getrennten Server-Scope definieren.
  • [ ] Policy-Owner, Application-Owner und Freigabeprozess festlegen.
  • [ ] Dedizierte AppLocker-GPO erstellen und nur mit der Pilotgruppe verknüpfen.
  • [ ] AppIDSvc über GPO auf automatischen Start setzen und Laufzustand prüfen.
  • [ ] Entscheiden, ob nur Benutzerkontext oder zusätzlich Services Enforcement für EXE und DLL im Scope liegt.
  • [ ] Jede verwendete Regelkollektion explizit auf Audit only setzen.
  • [ ] Wirksame Policy auf Pilotsystemen mit Get-AppLockerPolicy -Effective exportieren.
  • [ ] Default Rules erstellen, anschließend Pfade, ACLs und Administratorausnahmen prüfen.
  • [ ] Publisher-Regeln auf Herausgeber, Produkt, Datei und passende Versionsgrenze begrenzen.
  • [ ] Pfadregeln nur für nicht durch Standardbenutzer beschreibbare Verzeichnisse verwenden.
  • [ ] Hash-Regeln mit Owner, Paketprozess und Review-Datum dokumentieren.
  • [ ] Executables, Installer, Scripts, Packaged Apps und DLLs getrennt bewerten.
  • [ ] Vor EXE-Enforcement eine explizite Packaged-App-Regelbasis bereitstellen.
  • [ ] AppLocker-Eventkanäle zentral sammeln und mit Geräte- und Benutzerkontext anreichern.
  • [ ] Audit-Funde gegen Softwarekatalog, Paketquelle, Signatur und Geschäftsbedarf prüfen.
  • [ ] Kritische Anwendungen und Recovery-Werkzeuge mit repräsentativen Benutzern testen.
  • [ ] Rollout-Ringe mindestens über einen normalen Softwareupdate-Zyklus beobachten.
  • [ ] Regelkollektionen einzeln und mit freigegebenem Change auf Enforcement umstellen.
  • [ ] GPO-Backup und XML-Export vor jeder produktiven Policy-Änderung erstellen.
  • [ ] Recovery-GPO, Out-of-Band-Zugang und Verhalten offline befindlicher Geräte testen.
  • [ ] Temporäre Ausnahmen regelmäßig entfernen oder in wartbare Regeln überführen.
  • [ ] AppLocker-Wirkung gemeinsam mit EDR, Makroschutz, ASR-Regeln und Patchmanagement bewerten.