MenloSecurity, ou le principe de RBI

Petite présentation du Remote Browser Isolation

Quand on parle de cybersécurité, on entend (trop ?) souvent parler de Red Team, de pentest, d’exploits… alors je ne dis pas qu’il ne faut pas s’y intéresser loin de là, mais il est toujours bon de parler un peu Blue Team, et de voir quelles sont les mesures actuelles / à venir pour se prémunir des différentes attaques informatique.

Aujourd’hui j’ai décidé de vous parler de RBI, comprenez Remote Browser Isolation, une technique assez peu connue mais diablement efficace. On va décortiquer ça ensemble, puis je vous parlerai de MenloSecurity, une société proposant un outil de RBI.

Comme pour mon précédent article sur MobaXterm et sûrement tous les articles à venir, quand je parle d’un outil ou d’une solution, sachez qu’il n’y a aucun placement de produit !

Auquel cas je me ferai une immense joie de vous le dire, croyez-moi 😅

Et si certaines sociétés seraient intéressées… et beh sachez que moi aussi.

Le navigateur web en entreprise

Voilà quelque chose de souvent pénible à gérer. Le surf Internet et les Mails étant les deux plus gros vecteurs d’attaque informatique, rajoutez à cela que les navigateurs Internet sortent des correctifs à foison, difficile de toujours maintenir son parc à jour… et si vous rajoutez en plus le fait que les utilisateurs, même sans droits administrateur, peuvent installer des browsers portables… vous obtenez un savant mélange d’emmerdements 😮‍💨

Alors bien sûr il existe des “browsers made for enteprise“, comme Island par exemple, mais je n’en parlerai pas ici pour la bonne et simple raison que je n’ai pas encore pu tester ces solutions, même si celles-ci seraient sûrement à essayer !

En bref, vous avez déjà un peu de contexte.

Le remote browser isolation en action

Il y a pléthore de risques à surfer sur Internet, on peut citer :

• Les failles 0-Days ;
• Les sites de phishing ;
• Le téléchargement de malwares ;
• . . .

Là où notre solution de sécurité devient intéressante, et je parlerai surtout pour MenloSecurity, c’est qu’elle va nous permettre globalement d’agir comme suit :

Source: MenloSecurity on Youtube

Notre utilisateur va démarrer son Google Chrome de manière classique, mais un proxy système/proxy au niveau du navigateur va être activé, ce qui fait que l’entièreté de son trafic web sera redirigé vers une sorte de navigateur dans le Cloud. De cette manière, mille et une actions sont possibles !

• Tout le contenu actif de n’importe quel site web (sauf exceptions que l’on peut définir) est retravaillé en temps réel. C’est-à-dire que si le site héberge un 0-Day en Javascript ou autre, le contenu de la page étant retravaillé, l’utilisateur n’est pas impacté ! Le seul bémol que l’on peut noter ici est éventuellement une faible latence lors du chargement des pages web ;
  
• Si le site sur lequel l’utilisateur se rend est un domaine récemment loué, ou non-catégorisé, le site web passe en mode Read-Only, impossible donc de rentrer ses credentials dessus par exemple… et hop, on se prémunit des attaques par phishing ;
  
• Si l’utilisateur télécharge un fichier ZIP, un document Word, un PDF… qu’importe, le fichier va être analysé. Au niveau de son hash tout d’abord, mais plus encore via l’exécution dans une sandbox. Protection supplémentaire contre les malwares donc ;

Et ce n’est qu’une maigre liste des possibilités offertes par le Remote Browser Isolation ! Comme vous pouvez le voir, c’est une couche de sécurité supplémentaire non négligeable en entreprise.

Par ailleurs, en traînant sur LinkedIn j’ai vu passer des solutions se ventant d’être locales, c’est-à-dire qu’ici ce serait du Browser Isolation, sans le Remote. Pourquoi pas ! Mais n’ayant pas les connaissance suffisantes, je ne m’étalerai pas davantage ici.

Et comme d’habitude en sécu’ cependant, ce n’est là qu’un maillon d’une longue chaîne… même avec les meilleurs défenses, si Catherine de la compta (qu’on embrasse) donne son mot de passe par téléphone ou publie par erreur des informations confidentielles sur son Facebook, toute la chaîne est brisée.

Tu parlais de l’entièreté du trafic… vers un SaaS ?

Alors oui, ça peut faire grincer des dents, moi le premier… mais effectivement, le principe ici c’est que via un proxy (directement au niveau OS) ou bien au niveau du navigateur, le flux web soit redirigé vers une application dans le Cloud. Plusieurs choses à prendre en compte ici :

• On va réaliser ce qu’on appelle de l’interception SSL, et légalement vos utilisateurs doivent être mis au courant de cela, cf cet article de LinuxFr.org. Alors c’est une pratique plus que courante, mais (à juste titre ?) vous aurez toujours plusieurs réfractaires à cette méthode ;
  
• Bien choisir sa solution et donc son prestataire… que ce soit au niveau légal (si votre prestataire se trouve en dehors de l’UE) et vérifier sa réputation, car n’oubliez pas que tout votre trafic web passe par chez lui. Là aussi, vaste débat mais toujours bon de le rappeler ;
  
• Qui dit trafic sortant par l’application SaaS, dit vérifier les nœuds sortant. Résidant par exemple en Belgique, à l’heure actuelle MenloSecurity ne propose en sortie que des IP allemandes ou françaises… rien d’alarmant me direz-vous, mais certains utilisateurs pourraient s’en plaindre (recherches Google légèrement biaisées notamment) ;

En bref, cette pratique de sécurité a beaucoup d’avantages, mais doit bien être étudiée, surtout au niveau de l’impact utilisateur. Il faudra aussi s’armer de patience lors du déploiement d’un tel outil car il vous faudra sûrement whitelister bon nombre de sites web un peu capricieux, comme :

• Les sites avec protection DDoS, comme Cloudflare pour ne citer qu’eux, peuvent vous mettre des bâtons dans les roues ;
  
• Les sites utilisant nombre de sous-domaines, comme des sites gouvernementaux où il faut se connecter avec certaines applications (It’sMe en Belgique par exemple) ;
  
• Google Maps, ou autres sites du genre avec une tonne de Javascript… étant donné que la page est retravaillée constamment, bonjour les lenteurs ;

Comme je disais, ces désagréments peuvent être évités, mais sont à prendre en compte au moins au début, car le whitelisting/fine-tuning ne va pas se faire en un claquement de doigts.

Pour finir~

Et bien je pense avoir tout dit, j’ai essayé de résumer cela du mieux possible, sans trop faire de la pub’ pour la solution proposée, mais en essayant de parler des problématiques globales et des contre-mesures possibles. Comme d’habitude en Cybersécurité, tout est critiquable, et ce qui est vrai aujourd’hui ne le sera sans doute plus demain !

Je vous remercie donc d’avance de donner votre avis/vos retours d’expérience en commentaire, en sachant que je n’ai pas (encore) la science infuse 🧐

Bonne journée/bonne soirée, ciao !