Le scénario est bien connu : un courrier – une proposition commerciale ou une présentation, par exemple – est adressé à un collaborateur de l’entreprise visée, dont l’adresse a été obtenue lors de la phase de repérage de l’attaque. Au format Microsoft Office (Word, Excel, Powerpoint), OpenOffice ou PDF, le document a été en réalité modifié afin d’exploiter une vulnérabilité du lecteur par défaut (la suite Microsoft Office ou Acrobat Reader le plus souvent). Le code d’exploitation y installera alors un code malveillant secondaire, probablement développé pour l’occasion, chargé de surveiller l’activité du poste et d’exfiltrer les données.

Défendre contre une telle attaque n’est pas aisé : les logiciels anti-tout courants sont rarement performants face aux codes malveillants inconnus (la détection générique n’est pas leur plus grande qualité) et les procédures de mise à jour des postes de travail ont toujours du mal avec les applicatifs tiers tel Acrobat Reader. Et puis surtout le périmètre a surveiller est particulièrement important, n’importe quel poste de travail étant susceptible de recevoir et consulter le document piégé sous une multitude de formats.

A l’autre bout du paysage web, des services tels Scribd , DocStoc ou SlideShare gagnent en popularité. Souvent baptisés les « Youtube du document », ces sites permettent la mise en ligne de fichiers aux formats bureautiques les plus courants et leur visualisation via le navigateur à l’aide d’une interface Flash.

Pour le RSSI, l’intérêt est évident : en standardisant sur une telle plate-forme pour la mise à disposition des documents susceptibles d’être piégés, il déporte le risque vers la plate-forme distante et réduit le périmètre à surveiller. L’équipe sécurité doit alors s’assurer essentiellement de la bonne santé du navigateur et de son plugin Flash, et ce quel que soit le document à consulter.

Scribd, probablement le plus générique, supporte ainsi par exemple les formats Microsoft Word (.doc), Microsoft Excel (.xls), Microsoft Powerpoint (.ppt, .pps), texte (.txt), Adobe PostScript (.ps), OpenOffice (.odt, .sxw), OpenOffice Presentations (.odp, .sxi), OpenOffice Spreadsheets (.ods, .sxc), OpenDocument, Rich Text (.rtf), JPEG (.jpg, .jpeg), Portable Network Graphics (.png) et GIF (.gif). Une fois traités par la plate-forme en ligne, tous sont consultables à l’aide d’un vulgaire lecteur Flash, et donc via le premier navigateur venu.

La mise en oeuvre d’une telle stratégie n’est toutefois pas sans contrainte. D’abord parce qu’il sera probablement nécessaire de contrôler les documents bureautiques au niveau de la passerelle email, ce qui est déjà un projet en soi (comme le montre notamment une discussion à ce sujet entre membres de SecurityVibes). Sauf qu’ici, outre intercepter les fichiers, il sera nécessaire de les router vers la plate-forme du service en ligne, les convertir et enfin maintenir l’association entre le document généré (qui sera réduit à une URL à l’issue du processus) et le destinataire du document initial.

Scribd dispose cependant d’une API qui permet d’intégrer le service à diverses technologies, dont des implémentations existent pour PHP, Ruby et .NET (C#). L’aspect technique de la chose semble donc raisonnablement accessible.

Mais il reste que ces services ne sont pas, encore, taillés pour un tel usage en matière de confidentialité et de pérennité. Les clients de feu SlideAware , par exemple, attendent toujours que le service rouvre ses portes depuis son interruption l’an dernier.

Les architectures mises en oeuvre pour stocker les documents dans le nuage de ces services posent également des questions. Bon nombre d’entre eux utilisent ainsi la plate-forme S3 d’Amazon pour stocker les documents. Lorsque celle-ci est tombée l’an dernier, Scribd et DocStock ne répondaient ainsi plus. Or si le modèle du SaaS est aujourd’hui mûr pour l’entreprise, il l’est en étant encore adossé à une infrastructure privée d’envergure plus restreinte. Le PaaS (Platform as a Service) tel qu’offert par les Amazon AWS et autres Google App Engine ne semble pas encore de taille à motoriser une offre SaaS solide destinée aux entreprises.

Le recours à ces services pourrait néanmoins être envisagé ponctuellement, notamment lorsque les impératifs de confidentialité ou de disponibilité ne sont pas élevés. Un serveur dédié sur l’intranet, qui exploiterait l’API de Scribd, pourrait par exemple être mis à disposition pour centraliser, convertir et stocker via le service en ligne les documents Office et PDF reçus par les utilisateurs, avant leur visualisation. Ces derniers n’auraient alors plus besoin de les ouvrir localement, et ils les mettront par la même occasion à la disposition de tous. Le RSSI pourrait ainsi trouver là moyen à ne pas interdire, mais plutôt accompagner de manière sécurisée une pratique devenue courante. Et le tout en soulageant accessoirement le réseau de l’entreprise en lui épargnant l’envoi par email du même document à plusieurs destinataires.

Bien entendu, les spécialistes de la sensibilisation objecteront qu’entre double-cliquer sur une présentation Powerpoint pour la consulter immédiatement et faire la démarche de la mettre en ligne sur un site de l’intranet, il y a un monde (sans oublier ces présentations que personne n’osera jamais partager !). C’est pour cela que l’option de l’automatisation depuis la passerelle email est préférable. Toutefois une mention dans la charte informatique, concernant l’ensemble des documents bureautiques reçus de source externe, pourra aussi avoir son utilité.

Tout le monde n’est cependant pas d’accord avec une telle approche. « Les solutions de partage et de visualisation de documents en ligne déportent le problème. Elles peuvent mettre en péril la confidentialité des documents mais également l’identité des utilisateurs », met en garde Yannick Hamon, consultant sécurité chez Xmco Partners. Et il n’a pas tort : autant l’aspect confidentialité peut être minimisé en encadrant l’usage d’une telle plate-forme et la limitant aux documents reçus de source externe et publique, autant les attaques purement web sont inévitables. « Quel serait l’impact d’une attaque par XSS (cross-site scripting) sur ce type de solution. Pour mémoire, Google Docs a été frappé par une telle attaque, et le SSO de Google permettait alors d’usurper l’identité d’un utilisateur sur l’ensemble des applications, GMail, Calendar, etc… », poursuit Yannick Hamon. Et le consultant d’ajouter que l’entreprise n’aura probablement aucune certitude quant à l’usage des bonnes pratiques de sécurité pour ses serveurs.

« Le risque de phishing est également accru. Un vol d’identifiant sur l’une de ces plate-formes expose tous les documents de l’utilisateur. Et comme avec ces solutions tout document devient une URL, suivre un lien devient une habitude pour les utilisateurs. Ce qui favorise non seulement la vulnérabilité au phishing mais facilite aussi d’autres attaques », poursuit Yannick Hamon. En définitive, le risque est seulement déplacé : il ne faut plus pousser l’utilisateur à ouvrir un document piégé mais plutôt l’inciter à cliquer sur un lien. « Et s’il s’agit d’un lien HTTPS, le trafic sera alors chiffré de bout en bout et ne pourra pas être contrôlé par l’UTM ou le proxy filtrant », conclue Yannick Hamon.

En l’état de ces plate-formes leur usage présente donc au mieux un certain intérêt au prix d’une lourde adaptation à l’existant (via des API) et de nouveaux risques. Il n’est donc pas certain que l’opération soit rentable.

Il y a toutefois là matière à un produit innovant : une plate-forme internalisée qui répliquerait le modèle de Scribd, avec ses API, mais sous contrôle de l’entreprise. La notion de « private cloud » trouve ici tout son sens : une telle centralisation permettrait en outre la mise à disposition d’un plus grand nombre de documents à travers l’entreprise, leur protection et un meilleur contrôle. A notre connaissance, aucun produit répond toutefois encore à ces spécifications.