Benoît Grunemwald, DeviceLock : "les applications doivent intégrer des fonctions de DLP"

Le développement du Cloud Computing et, plus généralement, l’ouverture croissante des systèmes d’information montrent les limites de la sécurité périmétrique. L’occasion de relancer l’intérêt pour la prévention des fuites de données (DLP) ?

Benoît Grunemwald : La DLP se fait soit au niveau du terminal, soit dans le réseau. Mais lorsque l’on regarde le Cloud Computing, on trouve une architecture distribuée où les données peuvent se retrouver un peu partout. Ce qui conduit à une observation : les applications ne sont pas, en elle-mêmes, développées pour intégrer des fonctions de DLP, alors que c’est là que sont traitées les données. On voit donc des données sensibles se promener d’un serveur à l’autre, sans pour autant descendre jusqu’au terminal. Avec des applications qui ne vérifient pas si l’information a effectivement le droit de lui parvenir ou d’aller vers une autre destination. On peut y voir soit une brèche, soit une nouvelle opportunité. 

Mais ces données transitent toujours pas le réseau. N’est-ce pas justement le lieu idéal pour la DLP ?

On peut effectivement imaginer placer des appliances qui vont traiter les données dès que qu’elles sortent des applications, mais c’est comme pour le spam : ce n’est pas parce que l’on filtre dans le réseau qu’il ne faut rien faire au niveau du terminal ou de l’application. Ce qui est d’autant plus vrai dans le cloud que les données sont susceptibles d’être répliquées dans de nombreux endroits. D’où le besoin de bloquer avant.

Au-delà, il y a aussi une question de performances. Si les fonctions de DLP sont assurées directement au niveau du serveur, à la source, on allège les besoins en CPU et en bande passante. Mais l’appliance de DLP peut être une machine virtuelle fonctionnant sur le même hyperviseur que les machines virtuelles des applications... Reste que la gestion des données sera meilleure si la fonction de DLP est intégrée directement à l’application. 

Au final, il y aura peut-être des redondances, mais lorsque l’on parle de données sensibles, deux protections valent mieux qu’une.

Lors des Assises de la Sécurité, au mois d’octobre, à Monaco, le problème de la diffusion de la culture de la sécurité aux équipes de développement a été évoqué. N’est-ce pas là un frein aux perspectives que vous évoquez ?

Si, bien sûr. Dans la conception de sites Web, il y a quelques années, ça se passait comme ça : les développeurs codent puis le code est revu par les spécialistes de la sécurité qui détectent les failles après coup. Dans la DLP, on en est encore là. On dissocie trop souvent le code et son cœur fonctionnel des fonctions annexes. C’est pourquoi des applications comme DenyAll restent très utiles en frontal. Mais c’est peut-être aussi dans le cahier des charges qu’il faut mettre ça. 

Cela dit, l’un des principaux freins à la DLP reste la lourdeur des projets...

Soit l’entreprise a eu, en interne, une prise de conscience et dispose des ressources nécessaires, soit elle va s’appuyer sur ce que font les éditeurs et leur expérience chez d’autres clients. Mais cela reste assez important : il faut connaître ses données et leur format. 

Reste que l’on met en opposition deux types de DLP : une DLP qui va vraiment classifier chaque document quel que soit son contenu - à sa création, avec un niveau de sensibilité déterminé par le créateur de fichier et sa hiérarchie, et qui devra être révisé dans le temps - mais on travaille alors sur l’enveloppe. Soit la DLP se base sur le contenu et le juge sensible ou pas.

Accessoirement, tout cela peut valoir pour un SI interne. Mais y-a-t-il des solutions de DLP pour fournisseurs de services ? Qu’ils puissent « revendre » à leurs clients ou interfacer avec leurs solutions de DLP internes ? 

A ma connaissance, pas encore. La DLP reste aujourd’hui assez centrée sur le terminal qui est certainement le point le plus sensible parce qu’il y a l’utilisateur derrière. Et c’est bien là qu’est le premier risque : un utilisateur qui a la donnée et l’envoie par exemple à un homonyme de son destinataire. Et cette problématique perdure, que l’on soit dans le cloud ou pas. 

Et penser que chiffrer les données, c’est les protéger... cela pose d’autres soucis : il est impossible de vérifier les données chiffrées lorsqu’elles passent sur le réseau. En revanche, sur le terminal, elles sont déchiffrées et peuvent donc être contrôlées.

Vous recentrez la problématique sur le terminal. Mais y-a-t-il des solutions de DLP pour des terminaux mobiles en vogue comme l’iPhone et l’iPad ?

Pas à ma connaissance. Mais oui, il s’agit de terminaux très ouverts au risque lié à l’utilisateur, avec les systèmes de suggestion de destinataire, par exemple. Cela dit, on peut mettre en place les meilleurs systèmes de sécurité au monde ; si l’utilisateur n’est pas éduqué, cela ne servira pas à grand chose.

Si l’utilisateur est formé et que l’on met en place des garde-fous ni trop importants ni démesurés, pour éviter les fuites accidentelles, l’utilisateur doit être capable de limiter les fuites au maximum. 

A mesure que l’on a augmenté les automatismes de productivité, on a renforcé le risque. Ce qui justifie encore plus la DLP. Par exemple, lorsque vous commencez à taper le nom du destinataire : une puce de couleur pourrait préciser le niveau de confiance en rapport avec le contenu du message.