Application allow-listing : implémentation pragmatique en PME suisse

Un antivirus ne suffit plus

En 2024, plus de 60 % des incidents traités par le NCSC impliquaient des binaires légitimes détournés — PowerShell, msiexec, certutil — que l'antivirus n'a pas bloqués, parce qu'il ne le pouvait pas. L'application allow-listing (ou whitelisting applicatif) renverse la logique : au lieu de bloquer le connu-mauvais, on n'autorise que le connu-bon. Tout le reste est refusé par défaut. C'est le contrôle n°2 des CIS Controls v8 et l'une des mesures prioritaires recommandées dans le cadre du NIST Cybersecurity Framework. Pourtant, la grande majorité des PME romandes de 20 à 150 postes ne l'ont pas activé — essentiellement par crainte de bloquer la production.

Cet article démontre que l'implémentation est faisable en moins de quatre semaines sur un parc hétérogène, à condition de suivre une méthode rigoureuse.

Ce que l'allow-listing couvre réellement

Périmètre technique

L'allow-listing ne se limite pas à un blocage par nom de fichier. Les implémentations modernes s'appuient sur plusieurs vecteurs d'identification :

• Hash cryptographique (SHA-256) : identifier un binaire précis à un instant T. Fragile aux mises à jour fréquentes.
• Signature de code (code signing certificate) : autoriser tout binaire signé par un éditeur de confiance (Apple, Microsoft, Adobe…). Robuste, mais expose aux binaires légitimes détournés.
• Chemin d'exécution : autoriser uniquement les exécutions depuis C:\Program Files ou /Applications. Simple, mais contournable si l'utilisateur a des droits d'écriture sur ces chemins.
• Combinaison chemin + signature : le mode recommandé pour une PME. Équilibre entre maintenabilité et robustesse.

Plateformes concernées

La gestion diffère sensiblement selon l'OS :

• Windows 10/11 : AppLocker (gratuit, GPO, limité aux éditions Enterprise/Education) ou Windows Defender Application Control (WDAC), plus puissant, supporté sur toutes les éditions depuis Windows 10 1903. WDAC est la voie recommandée par Microsoft pour les nouveaux déploiements.
• macOS 13/14 (Ventura/Sonoma) : la combinaison System Integrity Protection (SIP), Gatekeeper et les profils MDM com.apple.applicationaccess ou des solutions tierces exploitant les extensions système (SEXT). Apple Business Manager (ABM) permet de pré-approuver les apps via VPP avant toute installation.
• Android (Enterprise) : le profil Managed Device avec kiosk mode ou la politique installUnknownSourcesAllowed: false couplée à une liste d'apps approuvées via Managed Google Play.
• iOS/iPadOS : par construction, seules les apps signées par Apple ou distribuées via ABM peuvent s'exécuter. Le vrai enjeu est la gestion des profils de configuration et des certificats de développeur d'entreprise.

Architecture de déploiement : la méthode en trois phases

Phase 1 — Inventaire et cartographie (semaine 1-2)

Avant d'écrire une seule règle, il faut savoir ce qui tourne. Sur un parc Windows, WDAC en mode Audit (sans blocage) génère des événements dans le journal Microsoft-Windows-CodeIntegrity/Operational (ID 3076 pour les blocages en mode enforcement, 3089 en audit). Laissez tourner 10 jours ouvrés minimum pour couvrir les usages mensuels (facturation, bilan, outils de backup). Sur macOS, des outils comme FleetDM ou osquery permettent de collecter la liste des processus en cours avec leur chemin et leur signature :

SELECT name, path, signature FROM processes WHERE on_disk = 1;

En sortie, vous obtenez typiquement :

• 30 à 60 binaires système (Windows, macOS, runtimes .NET, Java)
• 10 à 25 applications métier (ERP, CRM, outils comptables)
• 5 à 15 outils IT (agent de backup, VPN, monitoring)
• 2 à 8 applications personnelles non sanctionnées (Spotify, Steam, outils de compression douteux)

C'est ce dernier groupe qui justifie la démarche : il est souvent la porte d'entrée.

Phase 2 — Construction de la politique de référence (semaine 2-3)

Construire la politique depuis une image golden (poste fraîchement déployé via Windows Autopilot ou ABM) plutôt que depuis un parc existant réduit le bruit de 40 à 60 %. Pour WDAC, l'outil New-CIPolicy (PowerShell) génère une politique XML depuis le golden master :

New-CIPolicy -Level Publisher -Fallback Hash -FilePath C:\Policies\BasePolicy.xml -UserPEs

Le paramètre -Level Publisher privilégie la signature éditeur, -Fallback Hash prend le hash pour les binaires non signés. Cette politique couvre 80 à 90 % du parc sans règle manuelle. Les exceptions (scripts PowerShell internes, outils maison non signés) sont ajoutées manuellement via des règles de hash ou en signant les binaires avec un certificat interne.

Phase 3 — Déploiement en mode enforcement (semaine 3-4)

Déployer d'abord sur un groupe pilote de 5 à 10 postes (volontaires IT + un power user métier). Monitorer les événements ID 3077 (blocage enforcement) pendant 5 jours. Chaque blocage légitime donne lieu à une règle d'exception documentée. Puis extension à l'ensemble du parc via Intune (WDAC policy déposée comme profil de configuration) ou via ABM/MDM pour macOS.

Le processus d'exception doit être formalisé dès le départ : formulaire interne, validation DSI ou RSSI, délai de traitement ≤ 24h en journée ouvrable. Sans ce processus, les utilisateurs contournent (clé USB bootable, WSL, macOS Recovery) et la politique perd toute valeur.

Gestion des exceptions et gouvernance

Workflow d'exception

Un workflow simple suffit pour une PME :

1. L'utilisateur signale un blocage via le helpdesk (ticket avec capture de l'événement EventID).
2. L'équipe IT vérifie la légitimité du binaire : origine, éditeur, hash sur VirusTotal (hors périmètre allow-listing, mais utile pour le triage).
3. Si légitime : ajout à la politique via la console MDM, déploiement automatique dans les 15 minutes sur le poste concerné.
4. Si douteux : escalade au RSSI, analyse statique rapide, décision sous 4h.
5. Documentation de la règle dans le registre des exceptions (tableur ou CMDB légère).

Révision périodique

Toute règle d'exception doit être revue trimestriellement. Un binaire autorisé dont l'éditeur n'a pas publié de mise à jour depuis 12 mois ou dont le certificat a expiré doit être reconsidéré. C'est aussi l'occasion d'épurer les hashes obsolètes après migration d'une version logicielle.

Lien avec la nLPD

La loi fédérale sur la protection des données (nLPD), en vigueur depuis le 01.09.2023, impose des mesures techniques et organisationnelles appropriées pour protéger les données personnelles (art. 8 nLPD). L'allow-listing est précisément ce type de mesure : il réduit la surface d'attaque sur les endpoints qui traitent des données de clients ou d'employés. En cas de violation de données, l'absence de contrôles d'exécution documentés peut aggraver l'évaluation du risque lors d'une notification au Préposé fédéral à la protection des données (PFPDT).

Cas pratique : fiduciaire vaudoise, 45 postes

Contexte : Cabinet fiduciaire à Morges, 45 employés, 38 postes Windows 11 23H2 (domaine Azure AD, Intune) et 7 Mac (macOS 14 Sonoma, ABM). Traitent des données financières de 200 PME clientes. Pas de RSSI dédié — le DSI assume la fonction. Budget IT annuel : CHF 85 000. Incident déclencheur : tentative d'exécution d'un loader déguisé en plugin Excel, bloqué par chance par la vigilance d'un collaborateur.

Objectif : déployer WDAC sur le parc Windows et renforcer le contrôle applicatif sur macOS en 4 semaines, sans interruption de service pendant les périodes de clôture mensuelle (éviter les semaines 1 et 4 du mois).

Semaine 1 (audit, hors clôture) : déploiement de la politique WDAC en mode Audit via Intune sur les 38 postes. Collecte des journaux CodeIntegrity pendant 8 jours. Résultat : 1 247 événements uniques, réduits à 89 binaires distincts après dédoublonnage et exclusion des processus Windows natifs. Parmi eux, 6 outils non sanctionnés (dont un client torrent et un outil de compression russe inconnu de l'IT). Coût : 3h de travail DSI.

Semaine 2 (construction de la politique) : génération de la politique de base depuis le golden master Autopilot. Ajout manuel de 12 règles d'exception (outils comptables Abacus, logiciel de gestion des mandats, agent de backup Veeam, client VPN Fortinet). Revue par le DSI + test sur 3 postes pilotes. Correction de 4 faux positifs (DLL tierces signées avec un certificat éditeur différent du binaire principal). Coût : 6h DSI + 1h helpdesk.

Semaine 3 (déploiement enforcement, groupe pilote) : enforcement sur 8 postes pilotes (dont le comptable senior). 3 tickets helpdesk en 5 jours : un add-in Excel maison non signé (résolu par signature avec certificat auto-généré en interne, coût CHF 0), un script de reporting PowerShell (ajout de règle hash), un outil de PDF tiers (éditeur vérifié, règle Publisher ajoutée). Coût : 4h IT total.

Semaine 4 (rollout complet) : déploiement sur les 38 postes Windows via Intune, hors semaine de clôture. Zéro incident de production. Sur macOS, activation du profil MDM restreignant l'installation aux apps ABM + activation de Gatekeeper en mode strict (autoriser uniquement App Store et développeurs identifiés via profil com.apple.systempolicy.control). 2 tickets supplémentaires résolus en moins de 2h.

Résultat chiffré : surface d'exécution réduite de 91 % (de ~1 200 binaires potentiels à 89 autorisés). Coût total de déploiement : CHF 2 800 (environ 22h de travail interne valorisé à CHF 120/h + 2h de support externe). Aucune licence logicielle supplémentaire (WDAC est inclus dans Windows, Intune déjà en place). Durée de vie estimée de la politique sans refonte majeure : 18 à 24 mois avec révisions trimestrielles.

Récapitulatif opérationnel

1. Démarrer en mode Audit, jamais en Enforcement direct. Collectez au moins 8 à 10 jours ouvrés de données avant d'écrire une règle bloquante.
2. Construire depuis le golden master. Un poste fraîchement déployé (Autopilot ou ABM) génère une politique plus propre qu'un parc vieillissant.
3. Prioriser la signature éditeur (Publisher) sur le hash. Plus robuste aux mises à jour, moins de maintenance. Utilisez le hash uniquement pour les binaires internes non signés.
4. Formaliser le workflow d'exception avant le déploiement. Définir le délai (24h), le responsable (DSI/RSSI), et le registre de documentation. Sans cela, les utilisateurs contournent.
5. Déployer sur un groupe pilote de 5 à 10 postes pendant 5 jours ouvrés. Inclure au moins un power user métier pour couvrir les usages atypiques.
6. Intégrer macOS et mobile dans le périmètre. WDAC seul ne couvre pas un parc mixte. ABM + profils MDM Gatekeeper pour macOS, Managed Google Play pour Android.
7. Réviser les exceptions trimestriellement. Supprimer les hashes obsolètes, vérifier les certificats éditeurs, éliminer les logiciels non renouvelés.
8. Documenter pour la nLPD. Chaque exception acceptée et chaque révision trimestrielle constituent une preuve de mesure technique appropriée en cas de contrôle ou d'incident.
9. Ne pas négliger les scripts. PowerShell, VBScript et macros Office doivent être couverts séparément (AMSI, stratégie d'exécution PowerShell signée, Protected View Office).
10. Mesurer, pas juste déployer. Exporter mensuellement le nombre de blocages, le ratio faux positifs/vrais positifs, et le délai moyen de résolution des exceptions. Ces métriques justifient l'investissement en comité de direction.

SynGuard accompagne les PME romandes dans la conception et la supervision de politiques d'allow-listing sur parcs hétérogènes Windows, macOS et mobiles, depuis l'audit initial jusqu'au monitoring continu.

Sources

• Centre national pour la cybersécurité (NCSC) — Recommandations et alertes pour les entreprises suisses, signalement d'incidents.
• Loi fédérale sur la protection des données (nLPD) — fedlex.admin.ch — Texte consolidé de la nLPD en vigueur depuis le 01.09.2023, art. 8 sur les mesures techniques.
• Préposé fédéral à la protection des données et à la transparence (PFPDT) — Autorité de surveillance, procédure de notification en cas de violation de données.
• CIS Controls v8 — Center for Internet Security — Référentiel de contrôles de sécurité, dont le contrôle n°2 sur l'inventaire et le contrôle des logiciels.
• NIST Cybersecurity Framework — nist.gov — Cadre de gestion du risque cybersécurité, fonctions Protect/Detect applicables à l'allow-listing.