Sensibilité au contexte et au contenu : la clé vers l'efficacité des solutions locales de DLP
Les stratégies de protection de l’information axées sur le risque développées par les entreprises ces dernières années ont entraîné une migration en matière de sécurité informatique d’un modèle centré réseau vers un modèle orienté sur les données.
La fin du clivage
Entre 2002 et 2004 que les premiers serveurs monofonctionnels de prévention contre la fuite de données (DLP) ont fait leur apparition sur le marché, avec le but d'analyser le contenu des communications réseau. Ces systèmes filtraient les données échangées sur le réseau, notamment via le Web, les e-mails et les messages instantanés, pour prévenir les risques de fuite de données confidentielles liés aux agissements indélicats d'employés peu scrupuleux. Parallèlement, l'augmentation du risque de fuites de données via les ports et les périphériques locaux a fait naître une forte demande pour des solutions de contrôle des points d'extrémité du poste de travail, puis ensuite, pour des solutions locales de DLP dotées de fonctionnalités étendues en matière de contrôle contextuel.
Comme les serveurs de DLP en réseau et les solutions de contrôle des terminaux ciblaient le même marché, mais en utilisant pour l'essentiel des technologies différentes (filtrage de contenu d'un côté, méthodes basées sur le contexte, de l'autre), la concurrence entre les fournisseurs a généré une fracture "idéologique" entre le filtrage de contenu et l'analyse contextuelle.
Les partisans du filtrage de contenu faisaient valoir que seules ces technologies hautement intelligentes étaient capables de résoudre intégralement le problème des fuites de données, car elles le traitaient directement en analysant le contenu significatif des données : l'information. Par opposition, ils "accusaient" les technologies de contrôle de périphériques d'être incapables de "comprendre" l'objet de la protection, et d'utiliser des méthodes indirectes, donc inefficaces.
En réponse, les fournisseurs de solutions de contrôle de périphériques mettaient en avant (de manière assez justifiée d'ailleurs), le pourcentage élevé de "fausses alertes" des solutions de filtrage de contenu, ainsi que leur incapacité totale à prévenir les fuites de données locales au niveau du poste de travail.
Mais la situation a évolué. Les performances des terminaux informatiques se sont améliorées de façon considérable, ce qui a permis à la fois aux tenants des solutions locales de DLP et à certains fournisseurs de serveurs de DLP de transférer des composants d'analyse de contenu vers leurs agents locaux. Faut-il pour autant voir en l'accélération du déploiement de solutions locales de filtrage de contenu un aveu de l'inefficacité des technologies de DLP sur base contextuelle, et leur condamnation à court terme ?
Certainement pas ! Avec la maturité des solutions de DLP et les exigences des utilisateurs, il paraît désormais évident que le clivage entre technologies de DLP basées sur le contexte et le contenu était purement artificiel.
Pour comprendre pourquoi, il convient de prendre en considération les interdépendances fondamentales associées aux systèmes informatiques terminaux.
Vers une fusion du contexte et du contenu
Dans la mesure où les solutions locales de DLP sur base contextuelle n'assurent ni détection, ni analyse de contenu, mais utilisent plutôt des méthodes indirectes (comme le contrôle d'accès aux périphériques), elles sont essentiellement incomplètes aux fins de protection de l'information, et doivent donc s'associer au filtrage de contenu pour offrir une solution complète.
Néanmoins, sans comprendre qui transfère les données, d'où elles proviennent, par l'intermédiaire de quel canal ou support et où elles sont censées aller, il est impossible de déterminer quelle information elles contiennent, dans quelle mesure elles sont sensibles, si le transfert est légitime ou s'il enfreint les règles de sécurité de l'entreprise. En d'autres termes, aucune méthode de DLP sensible au contenu n'est viable si elle n'est pas en mesure de détecter intégralement le contexte d'une opération sur des données et à l'utiliser dans le cadre d'un raisonnement à base de règles. C'est la raison pour laquelle toute règle de filtrage de contenu valable doit combiner des spécifications de contenu avec des paramètres et des conditions de contexte associés.
La dépendance de l'analyse locale de contenu vis-à-vis de l'exhaustivité des contrôles contextuels apparaît clairement vu la complexité de l'anatomie structurelle de la DLP. Au niveau des terminaux informatiques, les quatre voies de fuite de données les plus dangereuses sont le canal du réseau et les trois canaux locaux que sont les périphériques de stockage et les accessoires amovibles "plug-and-play" ; les opérations de synchronisation de données avec des smartphones et des PDA connectés localement ; et le canal d'impression. Chaque canal est un agrégat multicouche de ses interfaces physiques et logiques, des types de périphérique spécifiques auxquels il peut se connecter, des applications ou des services qui y sont exécutés, des types de données utilisés par ces applications, et enfin, du contenu transporté par ces données.
La caractéristique essentielle de tout processus de DLP au niveau local tient à ce que, avant que le moteur de filtrage de contenu puisse commencer à analyser les données sur un canal, le périphérique ou la connexion réseau spécifique doit être identifié et autorisé au niveau de la couche d'interfaces. L'agent DLP doit ensuite détecter l'application ou le service en charge de la connexion pour identifier le type de canal et, si nécessaire, contrôler son comportement. Une autre couche de contrôle contextuel de l'architecture DLP doit procéder à l'opération suivante : la détection du type de données transférées (format de fichier, par exemple), qui est indispensable pour extraire le contenu textuel à filtrer. Ce n'est qu'alors que le moteur de filtrage de contenu peut commencer son travail.
Toute brèche dans le puzzle "sous-jacent" de contrôles de contexte locaux limite immédiatement l'efficacité de la "surcouche" de filtrage de contenu lors de scénarios de fuite de données qui ne sont pas affectés par la brèche, puisqu'elle crée des incohérences graves dans l'application globale des règles de DLP, et peut déboucher sur une incapacité totale à prévenir des fuites de données.
Prenons pour exemple le cas de contrôles contextuels incomplets sur le canal d'impression, lorsque la règle DLP spécifie que "les documents classés comme confidentiels ou secrets ne doivent pas être imprimés sur des imprimantes réseau ou locales". Si l'agent DLP ne peut détecter que des imprimantes connectés par ports USB (comme c'est le cas de nombreuses solutions locales de DLP), les imprimantes connectées via des ports LPT ou FireWire, ou par l'intermédiaire d'une connexion réseau, ne seront pas reconnues comme des "périphériques d'impression". En conséquence, l'agent DLP appliquera à tort sur ces connexions des règles d'accès à des ports, qui n'ont rien à voir avec ce qui est attendu en matière de contrôle de transfert de données via le canal d'impression.
En outre, il sera impossible de détecter le format d'impression ou d'extraire les données textuelles pour filtrage de contenu. Une autre conséquence de cette erreur de "détection non-USB" est que l'agent ne sera pas en mesure de comprendre si l'imprimante est connectée localement ou en réseau. Au final, cette "brèche" au niveau du contrôle contextuel empêchera l'agent d'appliquer de manière cohérente la règle de DLP spécifiée pour l'impression. Pire encore, elle débouchera sur une carence désastreuse de la solution DLP : les utilisateurs pourront imprimer sans aucun contrôle n'importe quel document sur des imprimantes connectées via des ports LPT ou FireWire, ainsi que sur des imprimantes réseau, à moins que tous les ports locaux non-USB de l'ordinateur soient entièrement verrouillés, et que les connexions réseau soient protégés par un pare-feu.
Lors du choix d'une solution DLP, les entreprises doivent évaluer leurs besoins de façon réfléchie, en fonction des menaces intérieures qui pèsent réellement sur leur organisation. Avant toute chose, elles doivent s'assurer que les contrôles DLP sur base contextuelle des solutions qu'elles envisagent d'installer couvrent l'intégralité des scénarios de fuite de données possibles en ce qui les concerne. Ce n'est qu'après avoir trouvé le juste équilibre au niveau contextuel qu'elles pourront commencer à établir les critères des composants de filtrage de contenu. Il existe un large éventail de techniques disponibles : formes de mots, expressions standard, prise d'empreintes de données, analyses lexicales conceptuelles et adaptatives, mise en grappes, etc. Comme les prix de ces solutions varient considérablement, l'approche la plus rationnelle consiste à ne déployer que les méthodes qui répondent aux menaces réelles, et à veiller à une stricte application des politiques de protection de données de l'entreprise.
En conclusion, ce n'est pas l'opposition, mais la fusion entre les technologies de filtrage de contenu et de contrôle contextuel qui fera des solutions DLP des produits réellement fiables, efficaces, complets et néanmoins abordables pour les entreprises de toute taille.