Sécurité : jusqu’où remonter certains éléments de protection dans le réseau de l’opérateur ?

Akamai le propose, Tata Communications aussi, entre autres : la protection des systèmes d’information contre les attaques en déni de service distribuées (DDoS) trouve sa place en amont des réseaux des entreprises. Tata Communications s’appuie pour cela sur les solutions d’Arbor Networks. Tout comme risquent de le faire d’autres opérateurs, clients d’Alcatel Lucent. De fait, Arbor a récemment noué un partenariat avec l’équipementier pour intégrer sa technologie dans les routeurs multi-services d’extrémité de réseau d’Alcatel Lucent. Arbor revendique déjà 60 % de parts de marché en matière de protection contre les DDoS pour les routeurs de peering des opérateurs. Mais là, c’est l’accès client qu’il s’agit de protéger. 

Eric Michonnet, directeur régional Europe du Sud d’Arbor Networks, explique que l’opérateur a en fait deux possibilités : «traiter au niveau du peering, après détection de l’attaque. On sait en minimiser l’impact à ce niveau-là. Mais au niveau de l’accès client, on peut offrir des services managés et traiter chirurgicalement l’attaque, pour le client concerné.» La détection de l’attaque peut se faire aux deux niveaux mais la protection du niveau de l’accès permet d’identifier les attaques relativement ciblées, «au niveau applicatif», notamment si elles n’ont pas été détectées plus haut dans le réseau. L’ensemble peut même fonctionner conjointement avec des équipements déployés en interne chez le client pour automatiser le traitement de l’attaque dans le réseau de l’opérateur. En outre, Eric Michonnet précise que l’intégration de la protection contre les DDoS peut également s’avérer intéressante pour les petits points de présence excentrés. Et de souligner, à l’heure où la coopération est largement promue à tous les niveaux de l’industrie de la sécurité informatique, que «les opérateurs collaborent entre eux en se fournissant des signatures d’attaques ».

Remonter l’IPS chez l'opérateur : complexe

Quitte à remonter ainsi des éléments de sécurité du SI dans l’infrastructure de l’opérateur, pourquoi ne pas l’appliquer à la prévention d’intrusion, en jouant sur une synchronisation des règles d’analyse et de filtrage du trafic entre équipements internes et équipements managés ? Martin Roesch, fondateur de Sourcefire, reconnaît que «l’idée est séduisante sur le papier ». Mais, selon lui, «ça risque d’être particulièrement compliqué de gérer ainsi les règles. Par exemple, si votre environnement est essentiellement Mac OS X, les règles liées aux vulnérabilités Windows ne sont pas d’un grand intérêt pour vous. Le problème, en définitive, est le niveau d’overhead que l’on risque d’avoir dans le fonctionnement de l’IPS. N’oublions pas que l’IPS analyse tout et utilise de fait beaucoup de mémoire, de ressources processeur, etc. Au final, le risque est de se retrouver avec des IPS - comme ce que l’on voit dans certaines grandes entreprises... - qui se contente d’un travail superficiel de recherche d’expressions régulières. Et là, on est loin de quelque chose de totalement performant. Pour être efficace, l’IPS doit être configuré précisément pour examiner des choses différentes suivant l’environnement en amont duquel il est installé, avec une forte granularité. C’est là que réside tout la complexité ».

Rien d’impossible toutefois, «en adoptant un modèle à la Zscaler, avec un fournisseur de sécurité qui fournisse son propre Cloud de sécurité ». Et même, «ça peut être utile. Je ne dis pas que ce n’est pas possible : c’est juste compliqué ». Mais clairement, il est préférable, pour «certaines attaques, de les mettre en échec au niveau du fournisseur de connectivité ». Autre risque, toutefois : «tout le monde n’aura peut-être pas envie que ce fournisseur se retrouve à analyser des flux contenant des données sensibles...» Possible, donc de remonter l’IPS dans le réseau du fournisseur, séduisant, même, mais complexe et avec de nombreuses questions en suspend.