Intégration de logiciels non maîtrisés : les bonnes pratiques de sécurité

« Au-delà de la Russie, l’ANSSI regarde vers la Chine. » Ainsi rebondissions-nous, en début d’année, sur la publication du « panorama de la menace informatique 2021 » du CERT-FR.

Le CSIRT gouvernemental français y évoquait, entre autres, le risque de détournement de cadres juridiques étrangers liés à la cybersécurité. Et mentionnait, en exemple, le logiciel GoldenTax, imposé à certains clients de banques chinoises. Une portée dérobée s’était retrouvée dans plusieurs versions.

Il est à nouveau question de GoldenTax dans un rapport publié récemment. Le sujet : les problématiques liées à l’intégration de logiciels maîtrisés. Le contenu : des recommandations pour l’installation de ces logiciels.

En tête de liste, installer le logiciel dans une zone isolée du SI. De préférence avec des équipements dédiés et affectés à cet usage.
Puis filtrer les flux réseau entrants et sortants, en évitant dans la mesure du possible les flux dirigés de la zone isolée vers le SI.
Le pare-feu sera distinct de la machine sur lequel se trouve le logiciel, pour éviter que ce dernier soit en mesure de le désactiver.

Si la sensibilité de la donnée manipulée le permet et qu’une connexion vers le SI interne n’est pas nécessaire, on peut tout à fait externaliser la zone. Dans ce cas, on utilisera un compte cloud dédié. Autant éviter la latéralisation que les risques d’élévation de privilèges pouvant affecter d’autres ressources. Et on n’exploitera pas de services d’infrastructure communs (authentification, DNS…).

Sur l’ensemble des services et équipements, on appliquera le principe du moindre privilège. Pour les opérations d’exploitation comme d’administration. En s’appuyant systématiquement sur des comptes locaux.

Limiter les capacités des outils d’accès à distance

Dans le cas d’une interaction à distance avec la zone isolée, on désactivera, sur la solution d’accès, le partage du presse-papiers et la redirection de disque.

En cas de nécessité d’échanger des fichiers entre le SI interne et la machine hébergeant le logiciel, on envisagera un espace de stockage partagé hébergé dans la zone isolée.
Même emplacement s’il est nécessaire de communiquer entre le SI interne et la zone isolée ; ou bien on pourra utiliser un service SaaS, opérant une séparation de fait.

Si vous n’utilisez pas, éteignez

Pour ce qui est du maintien en conditions de sécurité, on administrera manuellement la zone isolée. Directement sur les équipements ou depuis un poste dédié à cet usage. Les dépôts nécessaires ne doivent pas communiquer avec le SI de l’entité : ils doivent accéder aux mises à jour directement sur Internet.

L’ANSSI conseille aussi… d’éteindre le service lorsqu’on ne l’utilise pas. Histoire de limiter l’exposition de la zone isolée.

Les logs aussi en zone isolée

On activera – et configurera – la journalisation des composants système et réseau de la zone isolée. Données qu’on complétera par l’analyse des événements des pare-feu situés en bordure.
La centralisation des logs s’effectuera préférentiellement par l’intermédiaire d’un collecteur dédié en zone isolée. Le SI interne pourra ouvrir des connexions vers la zone de moindre confiance, mais pas l’inverse.

Photo d’illustration © monsitj – Adobe Stock