Récemment, de nouveau cas de transfert de fichier malveillant par un fournisseur auprès de PME ont été remontés à l’ANSSI. Ce type d’incident n’est pas isolé : il illustre une menace constante où la confiance accordée à un partenaire ou à un logiciel devient le maillon faible de votre sécurité.
Définition
Tout d’abord, qu’est ce qu’un logiciel malveillant ?
Un logiciel malveillant est un programme développé dans le but de nuire à un système informatique, sans le consentement de l’utilisateur dont l’ordinateur est infecté. Il peut voler des informations, crypter ou supprimer des fichiers, espionner les activités ou détourner des fonctions du système.
Quels sont les signes courants indiquant que votre ordinateur est potentiellement infecté ?
Les signes courants peuvent être un ralentissement des performances, l’apparition de fenêtres contextuelles, des plantages, une activité réseau inhabituelle ou des modifications des paramètres.
Certains domaines d’entreprises peuvent imposer l’utilisation de logiciels spécifiques. Bien que techniquement leur installation ne pose pas de problème, ces logiciels peuvent poser de sérieux risques de sécurité mettant en danger votre structure.
Si ces outils semblent légitimes, ils peuvent dissimuler des fonctionnalités redoutables :
- Des « portes dérobées » (backdoors) : Des codes cachés qui permettent à un attaquant de prendre le contrôle d’un ordinateur à distance.
- Une exécution silencieuse : Le logiciel malveillant s’installe et communique avec des serveurs externes sans aucune alerte pour l’utilisateur.
- Une persistance invisible : Même si vous désinstallez le logiciel principal, le code malveillant peut rester actif sur votre système.
Deux grands cas concrets pour comprendre :
- L’affaire GoldenSpy (2020): Lié à un logiciel de gestion de la TVA en Chine, ce code s’installait silencieusement avec des privilèges administrateur, permettant d’exécuter n’importe quelle commande sur le réseau de l’entreprise.
- Beijing One Pass (2021) : Un logiciel destiné à faciliter les démarches administratives municipales qui présentait des caractéristiques de logiciel espion.
Que faire pour vous protéger ? Quelques recommandations
Au-delà des situations illustrées par les codes malveillants précités, l’installation d’un « logiciel de moindre confiance » peut exposer les actifs métiers et le système d’information (SI) d’une entité à de nombreuses menaces. Afin de limiter l’impact de ces menaces, il convient de respecter plusieurs recommandations pour contenir le logiciel dans une zone isolée et dédiée à cet usage. Ces recommandations portent sur les thèmes suivants :
- Infrastructure
- Accès au logiciel
- Maintien en conditions de sécurité
- Détection
Il est recommandé de mettre à jour la cartographie du SI pour faciliter le contrôle de la zone cloisonnée et l’identification des chemins de compromission potentiels.
1. Infrastructure
- Installer le logiciel dans une zone isolée : Il est recommandé d’installer le logiciel dans une zone isolée du SI de l’entité et de préférence avec des équipements dédiés et affectés à cet usage.
- Filtrer les flux réseau « depuis » et « vers » la zone isolée au juste besoin opérationnel : Les flux réseaux depuis et vers la zone isolée doivent être filtrés par un pare-feu afin de limiter au juste besoin opérationnel les communications à des adresses ou plages d’adresses IP définies. À noter que les flux de la zone isolée vers le SI de l’entité sont dans la mesure du possible à prohiber.
- Filtrer les flux avec un équipement pare-feu distinct de la machine sur laquelle le logiciel est installé : Un pare-feu autre que celui de la machine sur lequel le logiciel est installé doit être utilisé pour filtrer les flux. L’objectif est d’éviter que le logiciel soit en capacité de désactiver le pare-feu s’il parvient à élever ses privilèges.
Isoler une zone dans un SI « on-premise » est une tâche qui peut s’avérer chronophage ou complexe si l’urbanisation du SI n’a pas prévu ce cas. Lorsque qu’une connexion vers le SI interne n’est pas nécessaire, l’externalisation (par exemple usage d’un service Cloud) dans une zone isolée et dédiée est une option envisageable lorsque la sensibilité de la donnée manipulée le permet. Les recommandations suivantes doivent être observées.
- Utiliser un compte Cloud dédié pour isoler la zone de moindre confiance : Si l’usage d’un Cloud est retenu pour mettre en place une zone isolée, il est recommandé d’utiliser un compte dédié. L’objectif est de limiter les risques d’élévation de privilège depuis la zone d’installation du logiciel pouvant affecter d’autres ressources, mais aussi d’éviter tout déplacement latéral sur d’autres ressources instanciées sans rapport avec le logiciel. La zone isolée ne doit pas utiliser les services d’infrastructure communs (système d’authentification, DNS, etc.).
L’objectif est d’éviter une compromission ou un potentiel déni de service en prohibant tout accès aux services du SI interne de l’entité.
- Appliquer le principe de moindre privilège sur l’ensemble des services et équipements :
Les comptes utilisés doivent posséder des privilèges les plus réduits possibles, adaptés à chaque opération d’exploitation et d’administration de la zone isolée. Dans la mesure du possible, le logiciel
ne doit pas s’exécuter avec un compte possédant les droits administrateurs. De façon générale, les
comptes utilisateurs et administrateurs doivent s’appuyer sur des comptes locaux.
2. Accès au logiciel
L’accès au logiciel se fait par un accès direct à la machine sur laquelle le logiciel est installé. Dans les cas où l’utilisateur doit interagir à distance avec la zone isolée, il est préférable d’utiliser une solution d’accès à distance (qui peut être un service Cloud) avec les précautions suivantes.
- Désactiver le partage du presse-papier et la redirection de disque : Le partage du presse-papier et la redirection de disques dans les solutions de déport d’affichage
doivent être désactivés. Lorsque l’échange de fichiers entre le SI interne et la machine hébergeant le logiciel est nécessaire, alors une zone de stockage partagée peut être envisagée si elle est hébergée dans la zone isolée. - Configurer un partage de fichier dédié et isolé : Lorsqu’une zone de stockage entre le SI interne et la zone isolée est nécessaire, elle doit être mise en place dans la zone isolée. Une alternative possible est l’usage d’un service SaaS dans un Cloud, qui rend de fait la zone de stockage séparée du SI interne.
- Configurer un partage de fichier dédié et isolé : Lorsqu’une zone de stockage entre le SI interne et la zone isolée est nécessaire, elle doit être mise en place dans la zone isolée. Une alternative possible est l’usage d’un service SaaS dans un Cloud, qui rend de fait la zone de stockage séparée du SI interne.
3. Maintien en conditions de sécurité
Bien que la zone soit isolée du SI de l’entité, le maintien en condition de sécurité des composants logiciels et matériels s’avère important. L’administration de cette zone isolée, limitée à un faible nombre d’équipements, se fera manuellement, directement sur les équipements ou depuis un poste dédié à cet usage.
- Réaliser le maintien en condition de sécurité depuis Internet : Les dépôts nécessaires au maintien en condition de sécurité (MCS) de la zone isolée ne doivent pas communiquer avec le SI de l’entité, mais doivent accéder aux mises à jour directement sur Internet.
Les règles de pare-feu doivent autoriser les flux réseaux nécessaires au MCS de façon stricte.
Lorsque le besoin d’utilisation du logiciel est peu fréquent, des mesures complémentaires peuvent être mises place pour limiter l’exposition de la zone isolée. - Eteindre le service lorsqu’il n’est pas utilisé : Il est recommandé d’éteindre le service lorsqu’il n’est pas utilisé.
4. Détection
La journalisation des événements est un prérequis pour mettre en œuvre une capacité de détection et d’analyse post-incident. Pour plus d’information sur les bonnes pratiques de journalisation en fonction de la confiance entre plusieurs zones, se reporter au guide ANSSI portant sur les « recommandations de sécurité pour l’architecture d’un système de journalisation ».
- Activer et configurer la journalisation : La journalisation des composants systèmes et réseau de la zone isolée doit être activée et configurée afin de détecter et d’analyser les incidents de sécurité. Cette journalisation est complétée par l’analyse des événements des pare-feu situés en bordure de la zone isolée.
- Mettre en place un collecteur de logs dédié dans la zone isolée : Il est recommandé de centraliser les logs via un collecteur dédié en zone isolée et de régulièrement récupérer ces journaux depuis le SI interne de l’entité. Ainsi, seul le SI interne initie des connexions vers la zone de moindre confiance, et non l’inverse.
L’essentiel à retenir : La confiance n’exclut pas le contrôle. Qu’il s’agisse d’un outil imposé ou d’un fichier envoyé par un fournisseur habituel, le traitement dans un environnement isolé reste votre meilleure défense contre l’espionnage et le sabotage.