App Control: Managed Installer, ISG, ergänzende Richtlinien

Der Grundlagenleitfaden zu App Control for Business endet mit einer Richtlinie, die Windows, von Microsoft signiertem Code und einem gescannten Schnappschuss Ihrer Software vertraut. Diese Richtlinie ist am ersten Tag korrekt und am dreißigsten falsch, wenn das erste Anwendungsupdate ein neues unsigniertes Hilfsprogramm mitbringt oder ein Hersteller sein Signaturzertifikat wechselt. Die meisten App-Control-Projekte, die scheitern, scheitern nicht an der Sicherheit, sondern daran, dass die Allowlist mit den Änderungen nicht Schritt hält.

Drei Funktionen lösen dieses Problem: der Managed Installer, der allem vertraut, was Ihr Verteilungswerkzeug installiert; der Intelligent Security Graph (ISG), der Dateien mit guter Microsoft-Reputation vertraut; und ergänzende Richtlinien, mit denen Anwendungsverantwortliche eine gesperrte Basisrichtlinie erweitern können, ohne sie anzufassen. Dieser Leitfaden zeigt, wie jede davon intern funktioniert, wie Sie sie konfigurieren und wo sie Ihr Sicherheitsmodell jeweils schwächt.

Wie der Managed Installer funktioniert

Ein Managed Installer ist ein Prozess, den Sie als vertrauenswürdig für die Installation von Software festlegen. Schreibt dieser Prozess oder einer seiner Kindprozesse eine ausführbare Datei auf den Datenträger, versieht Windows die Datei mit einem erweiterten Kernelattribut (einem „Herkunftsnachweis“, gespeichert als $KERNEL.SMARTLOCKER.ORIGINCLAIM). Wird die Datei später ausgeführt, erkennt App Control den Nachweis und lässt sie zu, sofern die Richtlinie die Regeloption 13 Enabled:Managed Installer enthält.

Zwei Komponenten arbeiten zusammen:

• AppLocker legt den Installer fest. Eine spezielle Regelsammlung, ManagedInstaller, benennt die vertrauenswürdigen Binärdateien. Der Dienst Anwendungsidentität (AppIDSvc) und sein Treiber übernehmen die Kennzeichnung.
• App Control wertet die Kennzeichnungen zur Ausführungszeit aus.

Diese Aufteilung ist wichtig. Ist AppIDSvc gestoppt, werden keine neuen Dateien gekennzeichnet, und Software, die Ihr Verteilungswerkzeug ab diesem Zeitpunkt installiert, wird auf Geräten mit Erzwingung blockiert.

Schritt 1: den Installer wählen

Wählen Sie pro Gerät ein Werkzeug. Mehrere festgelegte Installer vervielfachen das, was implizit vertrauenswürdig ist, und jede festgelegte Binärdatei wird zu einem lohnenden Ziel: Wer sie dazu bringt, eine Payload auszuführen, bekommt diese Payload zugelassen.

Der Intune-Schalter gilt nur für Win32- und andere Apps, die nach seiner Aktivierung über die Intune Management Extension ausgeliefert werden. Store-Apps und alles, was ein Benutzer selbst installiert, sind nicht abgedeckt.

Schritt 2: die AppLocker-Seite manuell bereitstellen (ohne Intune)

Microsoft veröffentlicht in der App-Control-Dokumentation eine Beispielrichtlinie für Managed Installer; beginnen Sie damit, statt XML von Hand zu schreiben. Sie besteht aus einer ManagedInstaller-Regelsammlung mit Herausgeberregeln für Ihre Installer-Binärdateien sowie EXE- und DLL-Regelsammlungen im Modus AuditOnly mit aktivierter Diensterweiterung, damit die Kennzeichnung auch für Prozesse funktioniert, die als Dienst laufen.

Wenn Sie AppLocker bereits einsetzen, führen Sie zusammen statt zu ersetzen, sonst überschreiben Sie Ihre bestehenden Regeln:

Set-AppLockerPolicy -XmlPolicy .\ManagedInstaller.xml -Merge
sc.exe config appidsvc start= auto
appidtel.exe start -mionly

appidtel.exe start startet die Kennzeichnungskomponenten der Anwendungsidentität; der Schalter -mionly aktiviert die Kennzeichnung durch den Managed Installer, ohne den ISG einzuschalten. Auf einem Gerät, das AppLocker noch nicht erzwingt, belassen Sie die EXE- und DLL-Sammlungen im reinen Überwachungsmodus; es geht um die Kennzeichnung, nicht um die Erzwingung durch AppLocker.

Schritt 3: Option 13 in der App-Control-Richtlinie aktivieren

Die Basisrichtlinie muss sich ausdrücklich dafür entscheiden:

Set-RuleOption -FilePath .\Base.xml -Option 13      # Enabled:Managed Installer
Set-RuleOption -FilePath .\Base.xml -Option 17      # Enabled:Allow Supplemental Policies
Set-RuleOption -FilePath .\Base.xml -Option 3       # Enabled:Audit Mode, während des Pilotbetriebs
ConvertFrom-CIPolicy -XmlFilePath .\Base.xml -BinaryFilePath .\Base.cip

Verteilen Sie dann eine Anwendung über den Installer und prüfen Sie, ob ihre Dateien den Nachweis tragen:

fsutil file queryEA "C:\Program Files\Contoso\Agent\agent.exe"

Eine gekennzeichnete Datei zeigt ein erweitertes Attribut namens $KERNEL.SMARTLOCKER.ORIGINCLAIM. Fehlt das Attribut, wurde die Datei nicht vom Prozessbaum des Installers geschrieben, oder AppIDSvc lief zu diesem Zeitpunkt nicht.

Schritt 4: über den Einsatz des ISG entscheiden

Option 14 Enabled:Intelligent Security Graph Authorization lässt Dateien zu, die der Cloud-Reputationsdienst von Microsoft als bekannt gut einstuft. Option 15 Enabled:Invalidate EAs on Reboot sorgt dafür, dass Windows die Reputation von durch den ISG autorisierten Dateien nach einem Neustart erneut prüft, damit eine Datei, deren Reputation sinkt, nicht für immer vertrauenswürdig bleibt.

Der ISG lässt Dinge zu, die Sie nie geprüft haben. Auf einem Vertriebslaptop ist genau das der Zweck, auf einem Server ist es das Problem. Wenn Sie ihn aktivieren, führen Sie zusätzlich appidtel.exe start ohne -mionly aus und betrachten Sie ihn als Zwischenschritt: Erfassen Sie aus den Überwachungsprotokollen, was er zugelassen hat, und ersetzen Sie dieses Vertrauen nach und nach durch explizite Herausgeberregeln.

Schritt 5: mit ergänzenden Richtlinien delegieren

Eine ergänzende Richtlinie fügt einer bestimmten Basisrichtlinie, identifiziert über deren Richtlinien-ID, Zulassungsregeln hinzu. Die Basis benötigt Option 17 (oben gesetzt). Erstellen Sie die Ergänzung aus dem Installationsordner der Anwendung:

New-CIPolicy -Level Publisher -Fallback Hash -UserPEs `
  -ScanPath "C:\Program Files\LineOfBusiness" -FilePath .\Supp-LOB.xml
Set-CIPolicyIdInfo -FilePath .\Supp-LOB.xml -PolicyName "Supp - LOB app" `
  -BasePolicyToSupplementPath .\Base.xml
ConvertFrom-CIPolicy -XmlFilePath .\Supp-LOB.xml -BinaryFilePath .\Supp-LOB.cip
CiTool.exe --update-policy .\Supp-LOB.cip

Ein praxistaugliches Betriebsmodell:

• Die Security verantwortet die Basis: Microsoft-Beispielrichtlinie, empfohlene Blockierregeln, die Sperrliste für anfällige Treiber, Option 13 und Verweigerungsregeln. Sie ändert sich selten und wird signiert, sobald sie stabil ist.
• Die Anwendungsteams verantworten die Ergänzungen: eine pro Anwendung oder Geschäftsbereich, geprüft über einen Änderungsprozess, ausschließlich Zulassungsregeln.
• Regeln bleiben nach Möglichkeit auf Herausgeberebene. Hashregeln in einer Ergänzung bedeuten eine neue Ergänzung für jedes Release.

Ist die Basisrichtlinie signiert, müssen auch die Ergänzungen signiert sein, sonst werden sie nicht geladen. Planen Sie Ihren Signaturprozess, bevor Sie die Basis signieren.

Was dabei kaputtgeht

• Sich selbst aktualisierende Anwendungen. Browser, Collaboration-Tools und Agents, die sich selbst aktualisieren, schreiben neue Binärdateien über ihren eigenen Updater, nicht über den Managed Installer. Die neuen Dateien tragen keinen Herkunftsnachweis. Decken Sie diese Hersteller mit Herausgeberregeln in einer Ergänzung ab, statt sich auf den Installer zu verlassen.
• Installationsprogramme pro Benutzer. Alles, was außerhalb Ihres Verteilungswerkzeugs nach %LOCALAPPDATA% installiert wird, ist konstruktionsbedingt nicht gekennzeichnet. Meist wollen Sie genau das blockieren, rechnen Sie aber mit Tickets.
• Kopierte statt installierte Dateien. Tools, die ein Anmeldeskript oder ein Admin an ihren Platz kopiert, wurden nie vom Prozessbaum des Installers geschrieben und haben daher keinen Herkunftsnachweis. Geben Sie ihnen eigene Herausgeber- oder Hashregeln.
• Der Installer als Angriffspfad. Wer eine App in Intune oder ein Paket in Configuration Manager veröffentlichen kann, kann nun beliebigen Code auf jedem Gerät mit Erzwingung zulassen lassen. Die Adminrollen Ihres Verteilungswerkzeugs werden Teil Ihrer Grenze der Anwendungssteuerung; behandeln Sie sie als privilegierte Konten.
• AppIDSvc deaktiviert durch eine Baseline oder ein „Debloat“-Skript. Die Kennzeichnung hört stillschweigend auf.

Überprüfen

1. Dienste: Get-Service AppIDSvc zeigt auf jedem Gerät mit Erzwingung Running und den Starttyp Automatic.
2. AppLocker-Seite: Get-AppLockerPolicy -Effective -Xml enthält eine ManagedInstaller-Regelsammlung, die Ihren Installer benennt.
3. App-Control-Seite: CiTool.exe --list-policies zeigt die Basis und jede Ergänzung als aktiv; Ereignis 3099 unter Microsoft > Windows > CodeIntegrity > Operational bestätigt die Aktivierung jeder Richtlinie.
4. Kennzeichnung: fsutil file queryEA auf einer frisch verteilten Binärdatei zeigt den Herkunftsnachweis.
5. Blockierungen: Ereignis 3076 (Überwachung) oder 3077 (Erzwingung) listet auf, was ausgeführt worden wäre bzw. gestoppt wurde. Die Diagnoseereignisse 3090 bis 3092 erklären, wann eine Datei durch Managed Installer oder ISG zugelassen oder blockiert wurde; 3090 (ausschließlich durch Managed Installer oder ISG zugelassen) ist optional und erfordert reg add HKLM\SYSTEM\CurrentControlSet\Control\CI -v TestFlags -t REG_DWORD -d 0x300 plus Neustart, wodurch auch 3091/3092 aktiviert werden, wo sie inaktiv sind. Mit einem Managed Installer kann 3091 sehr viel Rauschen erzeugen; filtern Sie es, bevor es einen kostenpflichtigen Log-Speicher erreicht.

Checkliste

• Ein Verteilungswerkzeug pro Gerät als Managed Installer festgelegt
• AppLocker-Regel ManagedInstaller zusammengeführt, ohne bestehende AppLocker-Regeln zu überschreiben
• AppIDSvc automatisch und laufend; appidtel.exe start ausgeführt
• Basisrichtlinie mit Optionen 13 und 17; Option 14 nur dort, wo der ISG eine bewusste Entscheidung ist
• Herkunftsnachweis im Pilotbetrieb mit fsutil file queryEA bestätigt
• Sich selbst aktualisierende Apps durch Herausgeberregeln in Ergänzungen abgedeckt
• Ergänzungen im Besitz der Anwendungsteams, nur Zulassungsregeln, signiert, wenn die Basis signiert ist
• Adminrollen des Verteilungswerkzeugs als privilegierter Zugriff behandelt
• Ereignisse 3076, 3077 und 3099 an Ihre Log-Pipeline weitergeleitet

Mit Managed Installer und Ergänzungen wird App Control vom Projekt zum Prozess. Der nächste Schritt schließt die Kernelseite mit der Treiber-Sperrliste, und der übrige Bereich Anwendungssteuerung behandelt die benutzerbezogenen Kontrollen mit AppLocker.