- Les applications installées sur les équipements professionnels représentent une surface d'attaque dynamique : chaque application est un vecteur potentiel de compromission via ses vulnérabilités, ses permissions, ou son comportement réseau.
- LastPass (2022) : le terminal d'un développeur compromis via une application vulnérable (Plex Media Server) a servi de vecteur initial pour l'exfiltration des coffres-forts clients — illustrant que des applications non professionnelles installées sur des terminaux avec accès aux ressources d'entreprise sont des risques organisationnels.
- La gestion des applications via un catalogue approuvé (Application Catalog/Store d'entreprise) réduit l'exposition aux applications non vérifiées tout en maintenant l'autonomie des utilisateurs pour les applications validées.
- Les permissions demandées par les applications mobiles doivent être auditées : une application accédant aux contacts, à la localisation et aux fichiers d'un terminal professionnel peut exfiltrer des données sensibles sans qu'un malware soit impliqué.
- L'allowlisting d'applications (liste blanche) est plus efficace que le blocklisting : autoriser explicitement les applications approuvées et bloquer tout le reste est plus sécurisé que tenter de bloquer les applications malveillantes connues.
Les applications installées sur les terminaux professionnels constituent une surface d'attaque dynamique et en permanente évolution. Un parc de 1 000 postes de travail avec en moyenne 50 applications chacun représente 50 000 vecteurs d'attaque potentiels, dont chacun peut être mis à jour (introduisant de nouvelles fonctionnalités ou vulnérabilités), compromis dans sa chaîne de distribution (supply chain attack), ou exploité via ses permissions excessives. Gérer cette surface d'attaque applicative requiert une approche structurée : inventaire des applications, qualification sécuritaire, et contrôle des autorisations d'installation.
La distinction entre applications métiers (essentielles à l'activité) et applications de productivité personnelle (installées par les utilisateurs pour leur confort) est la première étape. Les premières font l'objet d'un processus de qualification IT ; les secondes sont souvent installées sans contrôle. L'enjeu est de maintenir la flexibilité pour les applications légitimes tout en contrôlant les risques liés aux applications non vérifiées.
Les vecteurs de risque applicatif
Les applications exposent les terminaux à plusieurs catégories de risques. Les vulnérabilités applicatives : chaque application contient du code susceptible de présenter des failles exploitables — CVE publiées sur des composants open source inclus dans l'application, vulnérabilités propriétaires identifiées lors d'audits, ou bugs de sécurité dans les mises à jour. Les attaques supply chain : la compromission du processus de développement ou de distribution d'une application légitime permet d'introduire un code malveillant qui sera installé de manière transparente lors d'une mise à jour — SolarWinds (2020) est l'exemple canonique de ce type d'attaque à l'échelle enterprise. Les permissions excessives : des applications légitimes demandant des permissions non nécessaires à leur fonction (accès aux contacts, localisation, fichiers, microphone) peuvent collecter et transmettre ces données à des tiers. Les comportements réseau non documentés : des applications légitimes communiquant avec des serveurs tiers non déclarés peuvent constituer des canaux d'exfiltration involontaires.
Le catalogue d'applications approuvées
La mise en place d'un catalogue d'applications approuvées est l'approche la plus efficace pour gérer les risques applicatifs sans bloquer la productivité. Ce catalogue liste les applications validées par le processus de qualification sécuritaire IT, disponibles depuis un store d'entreprise (Microsoft Intune, Jamf App Catalog, VMware Workspace ONE). Les utilisateurs peuvent installer librement les applications du catalogue ; les applications hors catalogue requièrent une demande de qualification ou sont bloquées selon la politique. La qualification d'une nouvelle application inclut : vérification des permissions demandées, analyse du comportement réseau de l'application, vérification de l'éditeur et de sa politique de mise à jour de sécurité, et test dans un environnement isolé avant déploiement général.
Le backdoor inséré dans la mise à jour SolarWinds Orion illustre parfaitement l'attaque supply chain : une application légitime, dans son canal de distribution habituel, contenant du code malveillant signé par les certificats officiels de l'éditeur. Aucun outil de détection par signature ne pouvait identifier ce code comme malveillant avant que la compromission soit découverte. Ce cas illustre les limites de l'allowlisting classique — SolarWinds était sur toutes les listes blanches — et l'importance de la surveillance comportementale : l'activité réseau anormale de l'agent malveillant (connexions DNS avec encodage de données) était détectable par une analyse comportementale, mais pas par une vérification statique de l'application elle-même.
La gestion des permissions applicatives mobiles
Sur les plateformes mobiles (iOS et Android), les permissions applicatives sont gérées par le système d'exploitation et consenties explicitement par l'utilisateur lors de la première utilisation. La MDM peut cependant forcer certaines configurations : interdire l'installation d'applications hors App Store (iOS) ou d'applications non signées (Android), configurer les applications avec des permissions prédéfinies en mode silencieux, et signaler les applications ayant accès à des permissions sensibles (localisation, contacts, microphone, caméra). Un audit régulier des permissions accordées aux applications sur les terminaux du parc — extrait depuis la console MDM — permet d'identifier les applications avec des accès excessifs et de déclencher une revue : est-ce que ces permissions sont nécessaires à la fonction de l'application ? Si non, l'application doit être reconfigurée, remplacée, ou retirée du parc.
L'allowlisting comme mesure de contrôle applicatif
L'allowlisting (liste blanche) d'applications est la mesure de contrôle la plus rigoureuse : seules les applications explicitement approuvées peuvent s'exécuter sur le terminal, tout le reste est bloqué par défaut. Sur Windows, Windows Defender Application Control (WDAC) ou AppLocker permettent d'implémenter cette logique. Sur macOS, Gatekeeper et le MDM permettent des approches similaires. L'allowlisting élimine mécaniquement l'exécution de malwares classiques — qui ne sont pas sur la liste blanche — mais doit être maintenu : chaque nouvelle application approuvée doit être ajoutée, chaque mise à jour d'une application existante doit être vérifiée avant de permettre son exécution avec la nouvelle version. Cette maintenance est plus exigeante que le blocklisting, mais significativement plus efficace pour un parc dont les applications sont relativement stables.
La compromission de Target a débuté via des malwares installés sur les terminaux de point de vente, permettant la capture des données de cartes bancaires au moment de la transaction. L'introduction du malware s'est réalisée via les accès réseau d'un prestataire HVAC. Ce cas illustre que les terminaux spécialisés — points de vente, terminaux industriels, kiosques — sont des cibles autant que les postes de travail classiques, et doivent faire l'objet d'une politique de gestion des applications au moins aussi rigoureuse.
Les attaquants présents depuis 2014 dans l'infrastructure Starwood avaient installé des outils de surveillance et d'exfiltration sur des systèmes internes sans déclencher d'alertes. La présence prolongée non détectée pendant quatre ans illustre l'absence de surveillance des applications et processus s'exécutant sur les systèmes — un inventaire des processus actifs comparé à une baseline connue aurait pu détecter des processus non autorisés bien avant quatre ans.
La fuite de données d'Air India touchant 4,5 millions de passagers s'est produite via la compromission du prestataire SITA, fournisseur du système de gestion des passagers. Le logiciel SITA, installé sur les systèmes Air India, constituait un vecteur de compromission tiers. Ce cas illustre que les applications de prestataires ont le même niveau de risque que les applications internes — leur installation sur les systèmes d'entreprise doit suivre le même processus de qualification que les applications développées en interne.