Le fardeau du pentesteur

La sécurité informatique a fait du chemin ces dernières années. Désormais, toute entreprise de taille respectable dispose de sa politique de sécurité des systèmes d’information. Des sessions de sensibilisation des utilisateurs à la sécurité sont réalisées. Une gouvernance sécurité s’est même mise en place : le RSSI pilote, définit des KPI, analyse ses tableaux de bords SSI. Mais la technique n’est pas non plus oubliée ; on sait désormais que rien ne vaut un test d’intrusion pour vérifier, en imitant les méchants hackers, le niveau de sécurité d’une application ou d’un SI. Et ils vécurent heureux et ne subirent aucune attaque ? Pas si sûr...

Le test d’intrusion n’est pas une science exacte

Non, malheureusement, le test d’intrusion n’est pas une science exacte. C’est une démarche qui relève plus de la pratique que de la théorie. Et c’est tant mieux. Pourquoi ? Le test d’intrusion n’est pas un audit. L’objectif du test d’intrusion est d’avoir une vision réaliste, “terrain”, du niveau de sécurité d’une application, d’un environnement ou d’un système. Le pentesteur dispose alors d’informations limitées sur sa cible, et doit faire appel à ses connaissances et compétences pour essayer de comprendre les rouages de son fonctionnement, afin d’identifier les éventuelles vulnérabilités. C’est en cela qu’un test d’intrusion automatique est un non-sens ! L’automatisation ne permet pas cette compréhension fine du fonctionnement de la cible, et se contente de dérouler des scénarii de tests prédéfinis.

Par ailleurs, même si le pentesteur vise l’exhaustivité dans ses tests, les conditions de réalisation jouent souvent contre lui ! Le test a forcément une durée limitée, qui ne permet d’explorer qu’un nombre limité d’options. De plus, l’environnement sur lequel se déroulent les tests est rarement identique à 100% à l’environnement de production, que ce soit par des différences de configuration, des fonctionnalités non-disponibles, ou des comptes utilisateurs

Une première frustration pour le pentesteur : savoir que son travail, même dévoué, n’est jamais totalement complet.

Des tests d’intrusion souvent mal exploités

Les tests d’intrusion sont de plus en plus fréquemment gérés par “campagne”, mission d’une durée plus longue et qui regroupe plusieurs audits, réalisés souvent par le même prestataire. On peut ainsi assurer une certaine homogénéité dans les audits, profiter d’un contexte client mieux connu, et proposer des recommandations plus adaptées.

Malheureusement, une fois cette information obtenue, il convient de traiter les risques (ou de les accepter, pourquoi pas...). Force est de constater que cette étape n’est pas la plus maîtrisée, dans la plupart des cas. Les campagnes d’audit menées de manière récurrente sur des périmètres comparables font souvent apparaître des rapports d’audit grandement similaires, voir identiques.

Pourquoi cette situation ? Malheureusement, si les budgets SSI permettent les audits, ils sont rarement dimensionnés pour absorber le coût de la mise en œuvre des recommandations. De plus, les équipes projets sont bien trop souvent réfractaires aux changements, d’autant plus qu’ils sont à appliquer globalement (problématiques de contrôle d’accès, de filtrage des entrées,…).

Par ailleurs, au-delà des querelles sur la réelle nécessité d’implémenter tel ou tel mécanisme de sécurité (d’autant plus vigoureuse que l’application est “interne”), c’est très souvent l’implémentation des mécanismes de sécurité qui fait défaut. Les risques sont identifiés, des mesures de protection identifiées et validées, et pourtant, le jour du test d’intrusion, les illusions volent en éclat.

C’est bien là le regret du pentesteur : découvrir que son travail n’a servi à rien; qu’un an plus tard, les vulnérabilités sont toujours présentes et que d’autres sont même venues s’ajouter.

Quelles conclusions pour la réalisation de tests d’intrusion ?

Faut-il stopper la réalisation de tests d’intrusion ? Non, sans doute pas. En revanche, il convient peut-être de modifier la manière dont on utilise ces ressources.

D’abord, il faut savoir choisir ses cibles : inutile de tester le même périmètre que l’an dernier tant que l’on n’a pas obtenu la confirmation que les recommandations existantes ont été appliquées !

Ensuite, il faut tenter de traiter le problème à la racine : il est inefficace d’empiler les recommandations sur les failles XSS tant que les développeurs ne savent pas correctement traiter les entrées utilisateurs ! Et pour cela, le pentesteur peut apporter plus qu’une liste de vulnérabilités à la Prévert. Il doit s’assurer de l’adhésion des équipes techniques aux recommandations, ainsi que de leur implémentation technique. Pour cela, la réalisation d’ateliers avec les équipes techniques, visant à identifier dans le détail l’implémentation des recommandations, est un vrai plus ! En complément de cet accompagnement sur la mise en œuvre de moyens de protection, les résultats du test d’intrusion doivent également permettre la fiabilisation des mécanismes de supervision sécurité. Pour cela, un travail main dans la main avec les équipes de supervision est nécessaire, ainsi qu’un bilan à froid des actions qui ont été menées, celles qui ont été détectées et celles ne l’ayant pas été. On initie ainsi un cercle vertueux d’amélioration de la détection au cours du temps, concentré sur des éléments « terrain ».

Cette collaboration plus étroite entre les équipes de sécurité et les pentesteurs est sans doute la clé pour un meilleur ROI sur les tests d’intrusion. On trouve des références à cette approche sous le nom de “purple team”, une référence aux notions de “blue team” (défense) et de “red team” (attaque) utilisée dans le domaine militaire.

Le salut du pentesteur pourrait donc résider dans cette approche : offrir plus qu’un rapport et des slides, et avoir une démarche plus intégrée pour, enfin, améliorer la sécurité.

Arnaud SOULLIE