Revue du nouveau guide d’hygiène informatique de l’ANSSI (2/3)

Avant-propos

Dans un article précédent, nous nous étions intéressés aux 3 premiers chapitres du nouveau guide d’hygiène informatique de l’ANSSI. Nous poursuivons ici l’analyse sur les 3 chapitres suivants :

IV – Sécuriser les postes
V – Sécuriser le réseau
VI – Sécuriser l’administration

On s’intéressera ici aux matériels sur lesquels repose le système d’information : les postes de travail, les serveurs et les équipements réseaux et bien sûr les bonnes pratiques de gestion.

IV – Sécuriser les postes – protéger chaque maillon du système

#14 : Mettre en place un niveau de sécurité minimal sur l’ensemble du parc informatique

Alors qu’il était auparavant aisé de se conformer à un niveau de sécurité « homogène » (« je n’ai aucune sécurité, nulle part : j’ai un niveau de (in)sécurité homogène »), l’agence préconise cette fois un niveau de sécurité « minimal ». C’est déjà mieux, mais cela fait toujours abstraction du contexte et besoins de sécurité dans lequel évolue le système d’information. Le fait est qu’au sein d’un même SI, plusieurs zones (et donc niveaux) de sécurité sont à considérer : la zone d’administration SI, la zone de production, la zone des données RH, etc. De la même manière que des zones de sécurité physique sont établies (publiques, accueil, lieux communs, restreints, …), les mesures de sécurité sont en conséquence adaptées.

Le référentiel passe outre ce détail et recommande :

• La limitation au strict nécessaire des applications, logiciels et modules ; chaque composant installé est potentiellement vulnérable. Réduire leur nombre revient donc à réduire les possibilités de faille sur le poste.
• La mise en œuvre d’une pare-feu local et antivirus ; autant l’antivirus peut être installé « les yeux fermés » pour garantir un niveau de sécurité satisfaisant, autant la configuration efficace d’un pare-feu local peut tourner au vrai casse-tête ; d’où les explications de la règle #17.

#15 : Se protéger des menaces relatives à l’utilisation des supports amovibles

Rares sont les entreprises ayant trouvé l’équilibre entre sécurité, productivité et flexibilité sur l’utilisation des supports amovibles. La menace de clé USB infectée servant de point d’entrée à une propagation malveillante reste une crainte légitime des DSI. Pour y répondre, l’ANSSI conseille d’allier sensibilisation des utilisateurs et contrôle des périphériques. Bien que des solutions dédiées existent pour gérer une flotte de clés USB, elles diminuent mais ne pallient pas les risques de compromission (volontaire ou non) des clés par un utilisateur. Et leur gestion des smartphones (comme périphérique de stockage) n’est pas encore aboutie.

Au niveau renforcé, il s’agit de contrôler le lancement d’applications à partir du media, comme les navigateurs web portables (histoire de contourner la politique de sécurité de l’entreprise) ou les scripts malveillants.

#16 : Utiliser un outil de gestion centralisée afin d’homogénéiser les politiques de sécurité

Très peu de changements dans la réédition de cette règle sur le fond. Sur la forme, on passe de 4 à 15 lignes de texte explicatif, sans apporter grand-chose de nouveau. La règle se focalise sur les facilités de déploiement des politiques de sécurité et sur la réactivité des administrateurs en cas de crise. Elle omet par contre les aspects de maîtrise du SI en inventoriant les machines dans l’outil centralisé et les réductions de risques liés aux mesures de sécurité parfois contradictoires d’un poste à l’autre. Elle renforce ainsi la règle #4.

#17 : Activer et configurer le pare-feu local des postes de travail

Le paramétrage du pare-feu local nécessite une connaissance avancée des flux réseaux sur le SI. La liste exhaustive des services d’infrastructure n’étant déjà pas évidente pour tout le monde (ldap, ntp, dns, kerberos, smb, …), l’administrateur doit ensuite comprendre le fonctionnement des applications métiers qui, quand elles ne se basent pas sur des protocoles Web (http & HTTPS), s’appuient sur des ports réseaux dynamiques.

Idem pour les connexions entrantes qui ne doivent pas handicaper le support utilisateur (VNC, RDP, etc.). En réalité, si on considérait plutôt le durcissement des serveurs d’infrastructure et le bannissement des données sensibles sur un poste local, la gestion des flux serait grandement simplifiée. La configuration d’un pare-feu local sur les terminaux ne devrait être demandée qu’au niveau « renforcé ». A ne pas confondre avec l’activation/configuration d’un HIPS, non mentionné dans le référentiel, mais vivement recommandé (disponible dans la plupart des solutions antivirales récentes).

#18 : Chiffrer les données sensibles transmises par voie Internet

La fuite des données sensibles sur les réseaux externes (tiers, Internet) est un enjeu sur lequel les directions informatique et générale portent de plus en plus d’attention. Pourtant cette fuite s’effectue quotidiennement, à travers les processus internes de transfert de l’information à des tiers : envoi de facture ou de données bancaires, transmission de documents stratégiques par mail ou encore communication de données relevant de l’intelligence économique ou industrielle. Ces ressources sont généralement envoyées sur un canal non sécurisé, en pièce jointe de mail ou encore sur des hébergeurs cloud bien pratiques pour les gros fichiers (Dropbox & Cie). Certes le destinataire reçoit bien les données, mais peut-on être sûr qu’il est le seul à les avoir ?

C’est pourquoi il est recommandé d’apporter une couche de sécurité supplémentaire aux données envoyées sur des réseaux non maitrisés, Internet étant le parfait exemple. Des solutions libres et gratuites existent, mais il est souvent compliqué de convaincre les utilisateurs d’utiliser de tels outils, ajoutant une couche de travail supplémentaire à leur labeur quotidien. A défaut d’utiliser des outils basés sur des certificats, clés ou autre module cryptographique, il peut être intéressant de commencer par protéger par un mot de passe la ressource concernée, soit nativement sous certains outils (Microsoft Office), soit à travers une archive protégée (WinZip, WinRar, etc.).

La communication des mots de passe doit s’effectuer sur un mode de communication alternatif (par téléphone, SMS, courrier, …) palliant les risques liés à la compromission du canal d’échange de données (mail, Web).

V – Sécuriser le réseau – Sans impacter les performances

#19 : Segmenter le réseau et mettre en place un cloisonnement entre ces zones

Les VLAN ont encore du mal à se démocratiser dans le milieu professionnel, et pour cause. De nombreux DSI ne considèrent la sécurité que sur la partie applicative, au mieux au niveau des droits d’accès Active Directory. Pourtant les risques d’intrusion et de compromission ne nécessitent pas forcément de s’introduire sur cette couche applicative (couche 7 OSI), les couches liaison de données et réseau (couches 2&3 OSI) étant suffisantes. Le principe de défense en profondeur s’applique non seulement sur l’architecture globale du système d’information, mais aussi au travers des technologies et protocoles réseau qu’il utilise.

Un poste RH a-t-il besoin de communiquer avec un automate dans l’atelier ? Le serveur de mise à jour système nécessite-t-il d’être accessible depuis la base de données cliente ? Les placer dans des sous-réseaux différents (à des fins d’inventaire ou de gestion facilitée) n’est qu’une première étape nécessaire mais non suffisante. Le cloisonnement (deuxième étape) vise à réguler les communications entre ces sous-réseaux et à n’autoriser que ceux explicitement utiles et légitimes.

#20 : S’assurer de la sécurité des réseaux d’accès Wi-Fi et de la séparation des usages

La nouvelle règle portant sur les usages Wi-Fi précise les usages des accès visiteurs et personnels. Les connexions 4G ne suffisent pas à répondre aux besoins internes ou des tiers externes et les administrateurs sont soumis à la pression de la direction ou des utilisateurs pour mettre en place un tel service, comme si la mise en place d’un service Wi-FI revenait à appuyer sur un bouton (comme à la maison). Dans l’empressement, il arrive que les paramétrages de sécurité soient minimaux voire inexistants. L’agence rappelle donc les bonnes pratiques dans ce cas. Cette précision mise à part, il est toujours aussi déconseillé d’activer le Wi-Fi en entreprise si d’autres solutions filaires existent.

#21 : Utiliser des protocoles réseaux sécurisés dès qu’ils existent

La description des besoins de chiffrement n’évolue pas depuis le dernier référentiel. La nouvelle règle supprime même les recommandations quant au développement sécurisé des applications métiers. L’ajout d’une couche « sécurité » dans les échanges est certes une bonne idée, mais il est important de faire attention aux modules cryptographiques sur lesquels ils reposent car l’obsolescence et les vulnérabilités touchent aussi les algorithmes et tailles de clés.

#22 : Mettre en place une passerelle d’accès sécurisé à Internet

Plutôt que de simplement renvoyer le lecteur au référentiel de sécurisation des passerelles d’interconnexion avec Internet, comme c’était le cas dans la version précédente, le guide 2017 explicite le besoin d’implémenter un pare-feu réseau ainsi qu’un proxy, répondant au besoin d’authentification et de traçabilité des accès au niveau standard.

Au niveau renforcé, l’activation des autres fonctions du serveur proxy (filtrage Web, antivirus, cache, etc.) est recommandé pour ajouter un niveau de contrôle supplémentaire entre Internet et le poste utilisateur.

#23 : Cloisonner les services visibles depuis Internet du reste du système d’information

Si le filtrage des connexions provenant du système d’information interne vers Internet est fortement recommandé, les connexions établies depuis Internet vers tout ou une partie du système d’information interne doit être aussi sécurisées. Le cas typique étant l’hébergement en interne d’un site web ou encore d’un extranet à destination des clients/fournisseurs/nomades. De par leur visibilité sur Internet, ces services ne doivent pas être interconnectés avec le reste du système d’information (LAN), et nécessitent d’être cloisonnés dans une zone dédiée, une DMZ. En cas de compromission d’un service en DMZ, le LAN resterait « étanche » aux attaques et poursuivrait ses missions sans problème, si tant est que le filtrage entre la DMZ et le LAN est correctement effectué. C’est généralement là que le bât blesse : la DMZ sert de machine de rebond aux hackers, et peuvent poursuivre leur intrusion grâce au manque de cloisonnement entre les différentes zone du SI (WAN, DMZ, LAN).

La préconisation va plus loin en suggérant la mise en place d’un serveur mandataire inverse (reverse proxy) qui se chargera d’intermédiaire entre les requêtes d’Internet et les services hébergés en interne. A l’image du serveur proxy (cf. règle #22), il offre une couche de sécurité supplémentaire mais ne doit pas se substituer au durcissement des serveurs hébergés en interne.

L’hébergement externalisé offre généralement des garanties de disponibilité et d’intégrité des données supérieures, mais la confidentialité de ces dernières est rarement aussi bien assuré. Il appartient donc à l’entreprise de blinder ses clauses et exigences de sécurité dans les contrats avec les hébergeurs tiers.

#24 : Protéger sa messagerie professionnelle

Cette règle fait son apparition dans le nouveau guide d’hygiène. Il faut dire que la multiplication des attaques provenant d’un défaut de sécurisation de la messagerie nécessitait de clarifier les choses quant aux bonnes pratiques à implémenter sur ce service stratégique pour toute entité. La première partie de cette règle se focalise sur la sensibilisation des utilisateurs, déjà abordée en début de guide.

Le deuxième aspect de sécurisation tient aux mesures techniques (chiffrement, antivirus, antispam) qu’il appartient aux administrateurs de configurer. En cas d’hébergement externalisé, comme dans la règle précédente, il est nécessaire de revoir avec le prestataire la liste des couches de sécurité implémentées pour assurer la confidentialité et l’intégrité de la messagerie d’entreprise.

#25 : Sécuriser les interconnexions réseau dédiées avec les partenaires

Là encore, nouvelle règle. Les services d’infogérance tendant à se démocratiser au détriment d’une administration/exploitation interne, le nombre d’interconnexions réseaux avec les sous-traitants augmente inévitablement. Ces réseaux distants sont souvent considérés, à tort, comme de confiance. Or, dans la majorité des cas, le client n’a aucune idée du niveau de sécurité interne du prestataire, mais lui offre un accès distants 24/24h 7/7j à une bonne partie de son système d’information, sans contrôler les utilisateurs ni les flux réseaux.

Il convient donc dans un premier temps de dédier un canal sécuriser entre ces deux acteurs (via un tunnel VPN) et de considérer le tiers externe comme étant aussi peu sûr qu’Internet : un filtrage réseau, applicatif et des utilisateurs doit donc être mis en place et les accès régulièrement revus en interne afin de s’assurer du respect des clauses de sécurité édictées contractuellement et l’absence d’abus ou d’utilisation anormale du lien d’interconnexion (transfert de données massives, connexions à des heures improbables, etc.). La désignation d’un référent sécurité chez le tiers est un plus en cas de litige.

#26 : Contrôler et protéger l’accès aux salles serveurs et aux locaux techniques

Sécuriser le réseau signifie aussi de protéger le matériel supportant le réseau. A ce titre, il convient de restreindre l’accès aux équipements informatiques d’infrastructure (commutateurs, routeurs, bornes Wi-Fi, etc.) généralement regroupés dans un baie. On observe encore trop souvent une mutualisation de la salle réseau & serveur avec les salles de stockage et d’archivage. La criticité des équipements d’infrastructure dans l’accomplissement des missions de l’entreprise doit se traduire par un renforcement des accès physiques à ces matériels, et n’être accessible qu’aux personnes en ayant le besoin (DSI + éventuels gardiens).

Inutile pour autant de recourir à des mécanismes biométriques, une gestion fine des clés suffira dans un premier temps. Par la suite, une authentification forte (ex : badge + code PIN) sera préférée. Et les accès physiques révoqués de la même manière que les accès logiques suite à un départ d’un salarié.

En complément, les prises réseaux, qu’elles soient situées dans une zone de passage (couloir) ou dans des bureaux, doivent être protégées contre les accès illégitimes. Il est donc recommander de désactiver ces prises lorsqu’elles sont inutilisées.

En marge de cette règle, la sécurité des salles techniques ne se résume pas uniquement au contrôle d’accès : des mesures doivent être prises contre les risques environnementaux susceptibles d’affecter physiquement le matériel (chaleur, humidité, poussière, etc.).

VI- Sécuriser l’administration – Fort Alamo

#27 : Interdire l’accès à Internet depuis les postes ou serveurs utilisés pour l’administration du système d’information

Les postes d’administration ont la particularité d’avoir généralement accès à la totalité des ressources IT à portée d’un simple clic et login/mot de passe. Du point de vue d’une personne malveillante, c’est la machine idéale à s’emparer pour faire un maximum de dégâts à partir d’un simple point d’accès. En limitant l’interconnexion des postes d’administration au reste du système d’information et d’Internet, les possibilités de connexion à distance à ces postes stratégiques sont fortement réduites. De la même manière, les équipements administrés n’ont généralement pas besoin d’être connecté à Internet.

Et pour les mises à jour ? Les serveurs mandataires (type WSUS ou console de management antivirus) servent parfaitement d’intermédiaire avec Internet.

Il est important de dissocier les opérations d’administration (configuration, mises à jour, supervision) des autres opérations  « métiers » ou bureautique (messagerie, navigation Web, transfert de fichiers). Cette différenciation se traduit par la fourniture de deux machines différentes, garantissant un cloisonnement physique entre les deux activités.

#28 : Utiliser un réseau d’administration dédié et cloisonné pour l’administration du système d’information

Suite logique de la règle #27. Si le cloisonnement physique entre les postes de travail est respecté, il faut poursuivre cette logique avec l’établissement d’un réseau physique (compliqué) ou virtuel (VLAN, plus simple) où seuls les flux d’administration (SSH, HTTPS, etc.) seront autorisés. Sur des consoles d’administration moins récentes, seuls les flux non sécurisés (http, TELNET) sont possibles. Si les identifiants et mots de passe sont transmis en clair sur le réseau, autant que ce réseau ne soit pas accessible des utilisateurs et prestataires. De plus en cas d’intrusion sur le réseau utilisateur, ce cloisonnement permet de garder le réseau d’administration intègre.

#29 : Limiter au strict besoin opérationnel les droits d’administration sur les postes de travail

Il s’agit ici de bien distinguer les usages d’un PC personnel d’un PC professionnel. Les usages des suites bureautiques, Internet ou accès aux applications Web ne nécessitent pas de droits d’administration locaux. Par contre dès qu’il s’agit de modifier la configuration de l’ordinateur (ajout, modification, suppression), il en va de la responsabilité de la DSI et du maintien en conditions de sécurité du système d’information tout entier. Ces modifications doivent donc être réservées aux administrateurs système, afin qu’ils contrôlent la légitimité et la conformité du besoin utilisateur.

Par ailleurs, ces derniers sont beaucoup plus sensibilisés au fait de télécharger et installer des composants à partir de sites de confiance plutôt qu’au premier exécutable trouvé sur le moteur de recherche, et généralement vecteur de logiciels malveillants. Il permet aussi de s’assurer que les utilisateurs n’entrent pas en conflit avec la propriété intellectuelle (installation de programme sans licence ou piraté), qui pourrait mettre en défaut la responsabilité morale de l’entreprise en cas de contrôle.

La pression des utilisateurs pour plus de libertés ne doit pas se faire au détriment de la sécurité du système d’information. En particulier pour les utilisateurs aux postes importants (directions, managers, responsables) manipulant des données plus sensibles, dont les postes de travail devraient être encore plus durcis que les postes utilisateurs standards.

Conclusion

Ces 3 chapitres techniques reprennent les éléments essentiels de la version précédente et ajoutent de nouvelles mesures en adéquation avec les nouvelles menaces. La conformité à ce référentiel peut sérieusement remettre en question l’architecture du système d’information actuelle. Certaines mesures nécessitent même un gros travail de préparation, migration et vérification. C’est pourtant un effort que chaque DSI doit initier pour garantir la résilience et la robustesse de son système. Plus tôt les actions seront engagées, plus facile sera la transition vers une architecture sécurisée.

Sources

Guide d’hygiène informatique

Je partage