Loup Gronier

Dans un système d’information de plus en plus étendu et donc de moins en moins maitrisé, la sécurité périmétrique a longtemps été présentée comme une mesure de base permettant de sécuriser les accès aux informations. Sans revenir sur les multiples raisons pour lesquelles cette mesure de sécurité n’est pas une fin en soit et qu’elle doit être intégrée dans une approche plus globale de sécurisation, des initiatives (forum Jericho par exemple) se développent pour dé-périmètriser et donc faire disparaitre ces équipements qui empêchent le bon fonctionnement des réseaux et la réactivité attendue par les métiers.

Ces initiatives prennent partie des limitations des dispositifs de filtrages pour en demander la suppression. Il est en effet fréquent d’identifier en particulier sur des réseaux internes des dispositifs de filtrage comportant de nombreuses règles inattendues voir la célèbre « any any permit ». D’autres au fur et à mesure de leur évolution comprennent plusieurs milliers de lignes et apparaissent comme difficilement maitrisables voir maitrisés. Il est également clair qu’une bonne exploitation d’une politique de filtrage est coûteuse en administration mais également en délai avant la mise en place de l’ensemble des règles sur l’ensemble des équipements entre l’émetteur et le destinataire. Enfin les flux temps réel se développent et amènent des contraintes souvent antinomiques avec la traversée de nombreux équipements de filtrage.

L’approche de dé-périmétrisation consiste donc à ne plus sécuriser au niveau du réseau mais à réaliser les contrôles à la source sur le poste de l’utilisateur et au niveau de la destination, le service applicatif demandé. Les firewalls et autres équipements filtrants perturbant le trafic sont alors désactivés ou remplacés par des équipements de détection d’attaques assurant une réaction temps réel pour limiter la portée d’une menace. Cette approche est certe élégante mais nécessite des pré-requis dont les coûts et la gestion ne sont que rarement évalués, quelques exemples :

. Les postes de travail doivent tous être sécurisés.

En effet, l’heuristique consistant à prétendre que les postes de travail ne sont, somme toute, pas critiques dans leur ensemble se heurte d’une part au stockage local d’informations sensibles et d’autre part à la responsabilité juridique de l’entreprise qui ne protègerait pas ses postes et pourrait ainsi devenir un réseau de bots. Il est donc indispensable de garantir la protection des postes de travail. Les solutions de NAC ont d’ailleurs été conçues dans ce sens. Un poste de travail ne peut accéder au réseau dé-périmetrisé que s’il est conforme à la politique de protection de l’entreprise (firewall personnel, antivirus, patchs installés, authentification forte et non rejouable pour tous les moyens d’accès au poste…). Il est assez amusant (et peut être pas très économique et administrable) de devoir mettre en place et gérer des firewalls sur des milliers d’équipements dans l’entreprise pour limiter la complexité de gestion de quelques équipements de filtrage réseau. Il est également important de noter que dans un réseau “sûr”, l’heuristique tendant à ne pas gérer précisément les couches réseau sur les postes clients mais uniquement d’interdire les couches les plus dangereuses est acceptable. A contrario, dès lors que le réseau n’est plus sûr, l’analyse des flux sur le poste devient nécessaire si l’on veut sécuriser correctement le système d’information.

. les applications doivent toutes êtres sécurisées en fonction de leurs enjeux

Une analyse des enjeux doit être réalisée pour l’ensemble des applications et des mesures de sécurité adaptées aux enjeux mises en place. Ceci va nécessiter de remettre en cause les applications existantes et d’y intégrer des mesures de sécurité mais également une certification du code. En effet, une majorité des applications web internes sont sensibles à des attaques au travers des saisies dans les champs comme des injections SQL par exemple. Comment certifier qu’une application est éligible à être mise en ligne sur un réseau non sûr ? Comment prendre en compte une application ancienne qui ne est incapable de garantir le niveau de sécurité attendu ? en la protégeant derrière un firewall ? autant de problématiques qu’il faudra régler avant de mettre en place une véritable dé-périmétrisation.

. Le réseau et les service associés assurant la communication (DNS…) doivent se protéger contre les dénis de service et ceci passera également par des mesures de protection au niveau du réseau qui risquent de s’appuyer sur du filtrage (filtrage, filtrage quel vilain mot).

Ceci étant dit, une rationalisation des moyens de filtrage en particulier au sein d’une entreprise de taille importante est indispensable. Si les outils comme le NAC sont vus comme des outils et pas comme une fin en soi (comme l’ont été les firewalls en leur temps), il est en effet possible de limiter les mesures de sécurité au niveau du réseau pour les reporter au niveau des postes et des applications. N’oublions par contre jamais la loi des nombres et des proportions. Dans des entreprises mondiales, multi-sites, multi-DSI, multi-métiers, on peut décompter un millier de réseaux qu’ils soient LAN, MAN ou WAN mais on leur fait correspondre des dizaines de milliers de postes de travail. Le ROI d’une mesure tendant à déplacer les mesures de sécurité vers la multitude risque d’être complexe à garantir. Il est d’ailleurs significatif que le business case du forum JERICHO n’insiste que sur les gains et pas sur les coûts. A contrario, la tombée des barrières sans garantie de sécurité des extrémités risque d’être catastrophique en cas d’infection inconnue ou de temps de réaction long pour la mise en place du correctif en cas de détection d’un nouveau bug.