Histoires effrayantes à raconter sur le réseau

Halloween approche : voici une véritable histoire d’horreur en matière de politique de pare-feu. (Pour l’effet, imaginez-la racontée d’une voix rauque et inquiétante… ou par Morgan Freeman si vous préférez.)

En tant qu’ingénieur avant-vente, je passe beaucoup de journées à faire des démonstrations de nos produits et à échanger avec des ingénieurs sécurité, des responsables conformité, des DevOps Managers et des CISOs au sujet des pare-feux et de la sécurité réseau. Les récits de ceux qui sont sur le terrain sont parfois incroyables, et parfois carrément effrayants. Voici l’histoire récente d’un client qui empêchera tout ingénieur pare-feu de dormir.

Scénario :
L’entreprise avait récemment adopté une philosophie « zero trust » et avait consacré un temps considérable à se rapprocher de cet objectif. Au cours de l’année écoulée, elle s’était concentrée sur le nettoyage de ses politiques de pare-feu en rédigeant des règles propres au besoin métier – rien de plus – uniquement les IP et les réseaux spécifiques nécessitant un accès. Les progrès avançaient lorsque l’un de leurs ingénieurs fit une découverte terrifiante : une redoutable règle « Any – Any – Any – Accept » enfouie au milieu de la politique.

L’équipe s’est empressée de comprendre pourquoi cette règle existait. Elle a fini par découvrir qu’un ingénieur réseau junior, cherchant simplement à faire fonctionner quelque chose, l’avait créée. Cette seule règle annulait tous les progrès réalisés vers l’objectif zero trust et exposait le réseau à un risque considérable.

Il était clair que la règle devait être supprimée. Mais elle figurait dans la politique – sans avoir été détectée – depuis au moins 6 mois et autorisait certainement du trafic critique pour l’activité. De fait, les journaux indiquaient qu’il s’agissait d’une règle extrêmement sollicitée. Bien entendu, elle autorisait probablement bien plus que le seul trafic critique : elle laissait vraisemblablement aussi passer du trafic malveillant. Il fallait remédier rapidement à ce problème.

Dans un premier temps, l’équipe a organisé des réunions avec les équipes réseau et tenté de deviner la nature d’une partie du trafic, en recensant les applications critiques et les flux dont les connaisseurs du réseau soupçonnaient qu’ils empruntaient cette règle. Mais au bout du compte, elle a décidé de prendre son mal en patience, de supprimer la règle et de voir qui se plaindrait.

L’équipe a donc informé les responsables de toutes les unités opérationnelles de cette erreur. Non sans gêne, elle a annoncé la mise en place d’une « hotline » avec des opérateurs en attente, et a finalement dû faire tester par des collaborateurs l’ensemble des fonctions critiques pour s’assurer que leurs produits, leurs applications, tout ce dont ils avaient besoin pour travailler et pour permettre à leurs clients, partenaires et fournisseurs de faire affaire avec eux, ne resteraient indisponibles que le temps de tout reconfigurer. Oui, des services sont tombés, et oui, l’équipe était prête à créer de nouvelles règles pour corriger les problèmes, mais quel cauchemar.

—

Vous n’êtes peut-être pas confronté à un scénario cauchemardesque comme celui décrit ci-dessus, mais FireMon peut tout de même vous faciliter la tâche en vous aidant à nettoyer vos politiques de pare-feu. Voici quelques façons dont FireMon aurait pu empêcher le scénario ci-dessus. Et si vous découvrez un jour une règle inquiétante et trop permissive dans votre politique, consultez le point n° 6 ci-dessous pour une solution sans douleur.

1) Alertes et rapports de conformité :
Nous aurions immédiatement averti l’équipe si une règle aussi permissive était passée en production. Vous pouvez pour ainsi dire « régler le curseur » du niveau de permissivité accepté, par exemple « Règles autorisant l’accès à plus de 60 000 destinations » ou « Règles dont les sources dépassent un réseau /16 ».

2) Alertes de changement :
Cette règle aurait figuré dans notre vue normalisée – quel que soit l’éditeur du pare-feu – et son ajout aurait été clairement visible. Elle n’aurait donc pas pu passer en douce. Certains ingénieurs et responsables reçoivent automatiquement par e-mail des rapports de modification de politique à chaque changement – ou simplement un instantané sur 30 jours de tout ce qui a changé.

3) Avec notre outil d’automatisation, FireMon Policy Planner, la règle à risque aurait été stoppée net – avant même d’être déployée. Grâce à notre « analyse préalable au changement », la règle aurait été identifiée et signalée avant d’être poussée en production, sans laisser passer le moindre paquet. C’est pourquoi les équipes conformité apprécient que nous ne nous contentions pas de recommander la création de règles en fonction du besoin : comme dans un environnement sandbox, nous exécutons nos algorithmes de conformité avant de pouvoir pousser les règles automatiquement. Certains clients adoptent Policy Planner UNIQUEMENT pour cette fonctionnalité – et utilisent nos API pour y accéder.

4) Toujours avec les alertes de changement, l’équipe aurait su avec certitude qui avait effectué quelles modifications et à quel moment. Dans ce cas précis, puisqu’il s’agissait d’un ingénieur junior, un responsable aurait pu filtrer ou trier rapidement les modifications réalisées par cet utilisateur au cours de la dernière semaine, ou au moins du dernier mois, afin de voir quels types de changements il avait effectués. L’équipe conformité, voire l’utilisateur lui-même, aurait également pu le consulter.

5) Du point de vue de la documentation, FireMon peut constituer la source unique de vérité pour des éléments tels que « qui a formulé la demande, qui est le propriétaire de l’application, quand cette règle a-t-elle été revue pour la dernière fois, etc. ». En filtrant et en triant les règles à l’aide de leur documentation, le problème aurait lui aussi été identifié plus rapidement.

6) J’ai gardé le meilleur pour la fin. Si vous avez effectivement une règle trop permissive – par exemple parce que vos prédécesseurs appliquaient un « style de création de règles » plus ouvert et plus souple que le vôtre – nous disposons d’un moyen simple de nettoyer ces règles. Grâce à l’analyse des flux de trafic, notre outil examine chacune des adresses IP qui transite par la règle et décompose un any/any/any en flux spécifiques. Vous pouvez exporter ces flux et créer des règles précises à partir de ceux-ci.