Managed installer, ISG et stratégies supplémentaires

Le guide pilier App Control for Business aboutit à une stratégie qui fait confiance à Windows, au code signé par Microsoft et à un instantané analysé de vos logiciels. Cette stratégie est juste le premier jour et fausse le trentième, quand la première mise à jour d'application livre un nouvel utilitaire non signé ou qu'un éditeur renouvelle son certificat de signature. La plupart des projets App Control qui échouent n'échouent pas sur la sécurité ; ils échouent parce que la liste d'autorisation ne suit pas le rythme des changements.

Trois fonctionnalités existent pour y remédier : le managed installer (programme d'installation géré), qui fait confiance à tout ce qu'installe votre outil de déploiement ; l'Intelligent Security Graph (ISG), qui fait confiance aux fichiers ayant une bonne réputation chez Microsoft ; et les stratégies supplémentaires, qui permettent aux responsables d'applications d'étendre une stratégie de base verrouillée sans y toucher. Ce guide explique le fonctionnement interne de chacune, sa configuration et l'endroit où chacune affaiblit votre modèle de sécurité.

Fonctionnement du managed installer

Un managed installer est un processus que vous désignez comme habilité à installer des logiciels. Quand ce processus, ou tout processus enfant qu'il lance, écrit un fichier exécutable sur le disque, Windows marque le fichier avec un attribut étendu du noyau (une « revendication d'origine », stockée sous $KERNEL.SMARTLOCKER.ORIGINCLAIM). Quand le fichier s'exécute ensuite, App Control voit la revendication et l'autorise, à condition que la stratégie comporte l'option de règle 13 Enabled:Managed Installer.

Deux composants coopèrent :

• AppLocker désigne le programme d'installation. Une collection de règles spéciale, ManagedInstaller, nomme les binaires de confiance. Le service Application Identity (AppIDSvc) et son pilote effectuent le marquage.
• App Control tient compte des marques au moment de l'exécution.

Ce partage a son importance. Si AppIDSvc est arrêté, plus aucun nouveau fichier n'est marqué, et les logiciels que votre outil de déploiement installe à partir de ce moment sont bloqués sur les appareils en application.

Étape 1 : choisir le programme d'installation

Choisissez un seul outil par appareil. Désigner plusieurs programmes d'installation multiplie ce qui est implicitement approuvé, et chaque binaire désigné devient une cible de grande valeur : quiconque parvient à lui faire exécuter une charge utile obtient l'autorisation de cette charge.

L'interrupteur Intune ne s'applique qu'aux applications Win32 et autres livrées par l'Intune Management Extension après son activation. Les applications du Store et tout ce qu'installe un utilisateur ne sont pas couverts.

Étape 2 : déployer manuellement la partie AppLocker (hors Intune)

Microsoft publie un exemple de stratégie de managed installer dans la documentation App Control ; partez de celui-ci plutôt que d'écrire le XML à la main. Sa structure comprend une collection de règles ManagedInstaller contenant des règles d'éditeur pour les binaires de votre programme d'installation, plus des collections de règles EXE et DLL en mode AuditOnly avec l'extension des services activée, afin que le marquage fonctionne pour les processus exécutés en tant que services.

Si vous utilisez déjà AppLocker, fusionnez au lieu de remplacer, sinon vous écraserez vos règles existantes :

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

appidtel.exe start démarre les composants de marquage d'Application Identity ; le commutateur -mionly active le marquage du managed installer sans activer l'ISG. Sur un appareil qui n'applique pas déjà AppLocker, laissez les collections EXE et DLL en audit seul ; l'objectif est le marquage, pas l'application d'AppLocker.

Étape 3 : activer l'option 13 dans la stratégie App Control

La stratégie de base doit y adhérer explicitement :

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, pendant le pilote
ConvertFrom-CIPolicy -XmlFilePath .\Base.xml -BinaryFilePath .\Base.cip

Déployez ensuite une application via le programme d'installation et vérifiez que ses fichiers portent la revendication :

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

Un fichier marqué affiche un attribut étendu nommé $KERNEL.SMARTLOCKER.ORIGINCLAIM. L'absence d'attribut signifie que le fichier n'a pas été écrit par l'arborescence de processus du programme d'installation, ou que AppIDSvc ne tournait pas à ce moment-là.

Étape 4 : décider d'utiliser ou non l'ISG

L'option 14 Enabled:Intelligent Security Graph Authorization autorise les fichiers que le service de réputation cloud de Microsoft considère comme sains. L'option 15 Enabled:Invalidate EAs on Reboot fait revérifier par Windows la réputation des fichiers autorisés par l'ISG après un redémarrage, pour qu'un fichier dont la réputation se dégrade ne reste pas approuvé indéfiniment.

L'ISG autorise des choses que vous n'avez jamais examinées. C'est tout l'intérêt sur le portable d'un commercial, et tout le problème sur un serveur. Si vous l'activez, exécutez aussi appidtel.exe start sans -mionly, et considérez-le comme une étape transitoire : récupérez dans les journaux d'audit ce qu'il a autorisé et remplacez progressivement cette confiance par des règles d'éditeur explicites.

Étape 5 : déléguer avec des stratégies supplémentaires

Une stratégie supplémentaire ajoute des règles d'autorisation à une stratégie de base précise, identifiée par son ID de stratégie. La base a besoin de l'option 17 (définie plus haut). Construisez la stratégie supplémentaire à partir du dossier d'installation de l'application :

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

Un modèle opérationnel qui fonctionne :

• La sécurité possède la base : stratégie d'exemple Microsoft, règles de blocage recommandées, liste de blocage des pilotes vulnérables, option 13 et règles de refus. Elle change rarement et, une fois stable, elle est signée.
• Les équipes applicatives possèdent les stratégies supplémentaires : une par application ou par entité métier, revue via un processus de changement, uniquement des règles d'autorisation.
• Les règles restent au niveau éditeur autant que possible. Des règles de hash dans une stratégie supplémentaire imposent une nouvelle stratégie à chaque version.

Si la stratégie de base est signée, les stratégies supplémentaires doivent l'être aussi, sinon elles ne se chargent pas. Prévoyez votre processus de signature avant de signer la base.

Ce qui casse

• Applications qui se mettent à jour elles-mêmes. Navigateurs, outils collaboratifs et agents qui se mettent à jour seuls écrivent leurs nouveaux binaires depuis leur propre programme de mise à jour, pas depuis le managed installer. Les nouveaux fichiers ne portent aucune revendication d'origine. Couvrez ces éditeurs par des règles d'éditeur dans une stratégie supplémentaire au lieu de compter sur le programme d'installation.
• Installeurs par utilisateur. Tout ce qui s'installe dans %LOCALAPPDATA% en dehors de votre outil de déploiement n'est pas marqué, par conception. C'est généralement ce que vous voulez bloquer, mais attendez-vous à des tickets.
• Fichiers copiés, pas installés. Les outils qu'un script d'ouverture de session ou un administrateur copie en place n'ont jamais été écrits par l'arborescence de processus du programme d'installation : ils n'ont donc pas de revendication d'origine. Donnez-leur leurs propres règles d'éditeur ou de hash.
• Le programme d'installation comme chemin d'attaque. Quiconque peut publier une application dans Intune ou un package dans Configuration Manager peut désormais faire autoriser du code arbitraire sur tous les appareils en application. Les rôles d'administration de votre outil de déploiement font partie de la frontière de votre contrôle des applications ; traitez-les comme des comptes à privilèges.
• AppIDSvc désactivé par un référentiel ou un script d'« allègement ». Le marquage s'arrête sans le moindre signal.

Vérifier

1. Services : Get-Service AppIDSvc indique Running et un type de démarrage Automatic sur chaque appareil en application.
2. Côté AppLocker : Get-AppLockerPolicy -Effective -Xml contient une collection de règles ManagedInstaller qui nomme votre programme d'installation.
3. Côté App Control : CiTool.exe --list-policies montre la base et chaque stratégie supplémentaire comme actives ; l'événement 3099 dans Microsoft > Windows > CodeIntegrity > Operational confirme l'activation de chaque stratégie.
4. Marquage : fsutil file queryEA sur un binaire fraîchement déployé montre la revendication d'origine.
5. Blocages : l'événement 3076 (audit) ou 3077 (application) liste ce qui se serait exécuté ou a été arrêté. Les événements de diagnostic 3090 à 3092 expliquent quand un fichier a été autorisé ou bloqué par le managed installer ou l'ISG ; le 3090 (autorisé uniquement par le managed installer ou l'ISG) est facultatif et nécessite reg add HKLM\SYSTEM\CurrentControlSet\Control\CI -v TestFlags -t REG_DWORD -d 0x300 plus un redémarrage, ce qui active aussi les 3091/3092 là où ils sont inactifs. Avec un managed installer, le 3091 peut être très bruyant : filtrez-le avant qu'il n'atteigne un stockage de journaux payant.

Liste de contrôle

• Un seul outil de déploiement désigné comme managed installer par appareil
• Règle AppLocker ManagedInstaller fusionnée, sans écraser les règles AppLocker existantes
• AppIDSvc en automatique et démarré ; appidtel.exe start exécuté
• Stratégie de base avec les options 13 et 17 ; option 14 uniquement là où l'ISG est un choix délibéré
• Revendication d'origine confirmée avec fsutil file queryEA sur le pilote
• Applications à mise à jour automatique couvertes par des règles d'éditeur dans des stratégies supplémentaires
• Stratégies supplémentaires gérées par les équipes applicatives, règles d'autorisation uniquement, signées si la base l'est
• Rôles d'administration de l'outil de déploiement traités comme des accès à privilèges
• Événements 3076, 3077 et 3099 transférés vers votre chaîne de journalisation

Avec un managed installer et des stratégies supplémentaires en place, App Control cesse d'être un projet pour devenir un processus. L'étape suivante consiste à fermer le côté noyau avec la liste de blocage des pilotes, et le reste du domaine Contrôle des applications couvre les contrôles par utilisateur avec AppLocker.