Balabit : « appliquer l’analyse comportementale à un grand périmètre est très difficile »

Balabit est arrivé, comme beaucoup d’autres, sur le marché alors émergent de l’analyse du comportement des utilisateurs et des entités du système d’information (UEBA) en 2015, avec son outil BlindSpotter. Mais pas question pour lui de chercher à appliquer la technologie à tout va. Pour Marton Illes, son directeur en charge de l’offre gestion des comptes à privilèges (PAM, Privileged Access Management), il convient de cibler précisément le périmètre couvert selon le risque.

LeMagIT : Après avoir attiré à elle toutes les attentions en 2015, l’UEBA apparaît aujourd’hui vouée à disparaître en tant que marché isolé, pour mieux s’intégrer comme simple fonction à de plus en plus de produits. L’observez-vous également ?

Marton Illes : Beaucoup d’éditeurs en recherche de la « next big thing » se sont intéressés à l’UEBA. Certains ont cherché à couvrir là un périmètre trop large pour une seule solution – réseau, e-mail, un peu tout. D’où l’idée de se concentrer sur des périmètres réduits, ciblés.

Et avec la gestion des comptes à privilèges, justement, le périmètre très réduit, très spécifique, bien plus contrôlé que l’environnement de l’utilisateur final.

Tout à fait. Mais il y a aussi la question du risque. Lorsque nous avons commencé notre réflexion sur l’UEBA, nous nous sommes concentrés sur l’idée de viser les utilisateurs à haut risque. Nous avions un produit de PAM, et nous nous sommes dits : « il collecte beaucoup de données. Essayons de les utiliser pour en retirer de l’information pertinente ».

Et puis nous avons pensé à élargir le périmètre. Mais nous avons réalisé, comme d’autres, qu’élargir très largement ce périmètre est très très difficile.

Dès lors, je conseillerais aux entreprises voulant déployer une solution d’analyse comportementale de se concentrer sur ce qui est le plus important à leurs yeux. Et je ne dis pas là que le PAM est le seul domaine qui compte, mais c’est un point important, dans la perspective du risque, pour n’importe quelle organisation.

Dans le contexte du PAM, il y a des sessions textuelles, et d’autres graphiques. Les secondes ne sont-elles pas plus difficiles à traiter ?

C’est effectivement un peu plus complexe. C’est pourquoi nous avons fait le choix d’utiliser plusieurs algorithmes, pour appréhender la question de la modélisation du comportement et de la recherche d’anomalies sous différents angles.

Nous disposons de traitements permettant de convertir une interface graphique en représentations textuelles. Nos outils savent également identifier les applications présentées à l’écran. Et lorsque vous disposez de ces informations, vous avez quelque chose de comparable à des lignes de texte. Ce n’est pas la même chose, mais c’est approchant.

Bien sûr, les environnements graphiques demandent plus de pré-traitement, pour obtenir les données auxquelles appliquer les analyses. Mais ils ont aussi des caractéristiques spécifiques utiles à la modélisation du comportement de l’utilisateur, comme les mouvements de la souris – qui peuvent notamment trahir la nature du périphérique de pointage –, la taille de l’écran généralement utilisé, etc. Ce qui compte, en définitive, c’est de trouver un moyen de modéliser un comportement de référence, et de pouvoir détecter des anomalies.

Cela renvoie un peu aux travaux de certains sur l’authentification continue, n’est-ce pas ?

C’est un peu ce que l’on essaie de faire, en fait. La plupart des mécanismes de contrôle de l’identité se concentrent sur l’ouverture de session, mais laissent de côté ce qui se passe ensuite.

Bien sûr, l’authentification est importante et tout le monde devrait utiliser l’authentification à double facteur pour les systèmes critiques. Mais pour nous, il est aussi important de se pencher sur ce qui se passe après.

Ce que nous faisons, ce n’est pas seulement de l’authentification continue, mais aussi de l’autorisation continue. La question n’est pas seulement de savoir si c’est le même utilisateur : la probabilité que quelqu’un ouvre une session, abandonne son poste, puis qu’une personne malveillante s’en saisisse est relativement faible.

L’idée, c’est surtout de savoir ce que fait l’utilisateur : fait-il quelque chose d’inhabituel, ou hors de son périmètre ?

Avez-vous aidé à identifier, chez des clients, un employé ou un sous-traitant qui serait devenu malveillant ?

Tout d’abord, nous ne collectons rien de nos clients : nous ne savons que ce qu’ils veulent bien nous raconter. Mais oui, nos outils ont identifié des cas avec accès inhabituels aux systèmes.

Je pense par exemple à un cas avec un sous-traitant qui accédait à des systèmes auxquels il n’était pas censé avoir accès, détecté grâce à nos algorithmes. En fait, c’était légitime ; son rôle avait changé. Mais les règles de contrôle n’avaient pas été mises à jour en conséquence.

D’ailleurs, les attaques sont globalement rares. Dans la grande majorité des cas, il s’agit de défauts de configuration. Mais les deux sont susceptibles de coûter de l’argent.