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,…).
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.
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é.
Aucun commentaire:
Publier un commentaire