Cet article fait partie de notre guide: Dossier SDN : la virtualisation réseau pour les datacenters

Gartner : manque de contrôle de sécurité sur les SDN

Selon Gartner, les réseaux à définition logicielle devraient s’avérer inévitables et apporter une transformation en profondeur des infrastructures. Mais le manque actuel de contrôles de sécurité et de capacités d’administration fait des SDN un risque concret pour la sécurité des entreprises.

Selon Gartner, les réseaux à définition logicielle (SDN) devraient s’avérer inévitables et apporter une transformation en profondeur des infrastructures. Mais le manque actuel de contrôles de sécurité et de capacités d’administration fait que les SDN constituent un risque concret pour la sécurité des entreprises.

A l’occasion d’une session, la semaine dernière, lors de l’édition 2014 du Gartner Security & Risk Management Summit, Greg Young, vice-président recherche et analyste sécurité réseau en chef du cabinet, a longuement évoqué les implications de sécurité des SDN. Décrivant les SDN comme une technologie permettant de séparer la couche de contrôle du réseau de la couche de transport, Young explique qu’elle constitue une forme de virtualisation permettant de centraliser les décisions de routage dans un serveur de contrôle dédié. Et en matière de sécurité, selon Young, les SDN sont truffés de questions encore sans réponse : capacités de sécurité immatures et diverses d’un produit à l’autre, contrôleur SDN constituant un point de défaillance unique, et caractère optionnel de la sécurité dans certains protocoles SDN. Pour Young, les SDN « sont bons, si l’on adopte le point de vue des fonctionnalités, mais ils inquiètent les responsables de la sécurité, et à juste titre. »

Là où pèchent les SDN

Et Young d’expliquer que peu de fournisseurs SDN investissent réellement dans la sécurité de leurs solutions. Pire, selon lui, ils essaient de s’arroger le contrôle des fonctions de sécurité de leurs produits, n’encourageant finalement que peu la collaboration avec des spécialistes tiers de la sécurité pour la création de produits de sécurité SDN interopérables. Et pour Young, sans la participation des spécialistes de la sécurité, il est peu probable que des standards de sécurité émergent rapidement pour les SDN : « nous sommes actuellement à un point bas en matière de coopération et de collaboration autour de la sécurité des SDN. »

En outre, les produits SDN actuels sont, selon Young, un rêve devenu réalité pour les pirates. Car dans un SDN, toutes les décisions de routage sont prises par le contrôleur : si un attaquant en prend le contrôle, il peut mettre la main sur tout le réseau. Certes, citant une récente étude sur la vulnérabilité des SDN conduite par d’université A&M du Texas, Young reconnaît que les technologies SDN ne sont pas faciles à détecter. Mais elles n’en sont pas moins vulnérables aux attaques exploitant de grandes quantités de ressources, comme les attaques en déni de service. « Et dans un environnement réseau conçu pour être hautement disponible, ces attaques sont celles contre lesquelles il est le plus difficile de se défendre », souligne Young, ajoutant que « les entreprises vont devoir superviser leurs réseaux pour détecter ce type d’attaques, intentionnelles comme non-intentionnelles, parce que c’est quelque chose qui n’a pas encore été discuté. »

Et c’est sans compter avec les risques de sécurité associés avec le contrôle de la configuration des SDN et du changement. Les produits SDN disposent de leurs propres consoles d’administration. Et celles-ci ne sont généralement pas interopérables avec d’autres consoles d’administration du réseau et de la sécurité, ajoutant une couche de complexité aux processus d’administration de la sécurité réseau. En outre, selon Young, il pourrait s’avérer difficile de gérer et d’auditer les changements de configuration SDN parce qu’un éventail plus d’utilisateurs est susceptible d’avoir besoin de privilèges d’administration de la configuration SDN : « pensez à toutes les mains qui vont venir piocher là et qui sont susceptible de modifier le réseau. Il s’agira d’une communauté plus vaste, utilisant plus de consoles. Et cela signifie une surface d’attaque plus large. »

Les apports des SDN pour la sécurité

Toutefois, certains aspects des SDN devraient être bénéfiques à la sécurité, dont en particulier une base de code simplifiée.  Selon Young, alors la plupart des commutateurs réseau ont jusqu’à 35 millions de lignes de code, mais les produits SDN utilisent généralement une version allégée de Linux, avec seulement 1 à 2 millions de lignes de code, réduisant d’autant la surface d’attaque. En outre, les SDN pourraient être une bénédiction pour l’administration des politiques de sécurité réseau, car le contrôleur SDN constitue le point central d’application des règles.

Et plus le déploiement de SDN n’impliquera pas l’abandon de toutes les technologies réseau actuelles, relève Young. Pour lui, il est tout à fait acceptable, sinon encouragé, d’utiliser des pare-feu traditionnels pour segmenter une infrastructure SDN : la séparation physique réduit les risques et pourrait même accélérer les déploiements.
Et Young de recommander plusieurs bonnes pratiques de sécurité SDN, à commencer par la protection du contrôleur SDN. Même si cela constitue un important défi aujourd’hui, ne serait-ce qu’en raison de l’absence de produits viables pour cela, les équipes de sécurité devraient envisager le chiffrement des communications entre le contrôleur et les commutateurs réseau. Mais cela laissera le contrôleur SDN vulnérable aux attaques en déni de service - entre autres. Young recommande alors de « durcir » le contrôleur avec des cheminements réseau redondants qui aideront à garantir la qualité de service. Mais l’analyste suggère également le recours à des systèmes de prévention des intrusions, à l’authentification entre commutateurs, ainsi qu’aux contrôles intégrés au contrôleur.
Enfin, Young suggère de revoir les politiques de gestion des configurations de sécurité réseau, car des technologies telles que les SDN font souvent peser un poids supplémentaire sur les processus de workflow traditionnels : « vous ne pouvez pas utiliser des workflows historiques avec une infrastructure radicalement nouvelle. Il faut changer les processus ou changer la manière dont les changements sont implémentés. Si cela contrevient aux règles pour lesquelles vous êtes actuellement audité, cela doit être corrigé. »

Enfin, malgré tous les défis associés au passage aux SDN, Young a recommandé aux RSSI d’adopter cette technologie dès qu’elle fera ses premiers pas dans leurs organisations, parce que cela leur offrira l’opportunité de non seulement pousser la sécurité comme une priorité dès le début, mais également de jouer un rôle dans la conception et la mise en oeuvre : « vous pouvez faire le lien pour les communications techniques entre les équipes du centre de calcul, et celles de l’exploitation réseau. »

Adapté de l’anglais par la rédaction.

Soyez le premier à commenter

M'envoyer une notification dès qu'un autre membre commente.

Merci de créer un identifiant pour pouvoir poster votre commentaire.

- ANNONCES GOOGLE

Close