Prendre tout le bénéfice des évaluations de sécurité

La gestion des vulnérabilités dans les complexes environnements informatiques modernes comporte de nombreux aspects. Les évaluations de sécurité constituent un moyen populaire d’identification des vulnérabilités existantes ; de quoi ensuite prendre les mesures d'atténuation appropriées.

Dans cet article, nous examinons les différences entre la recherche de vulnérabilités, les tests d'intrusion et les exercices de « red teaming », trois types d’évaluation de sécurité populaires, mais qui doivent être effectués avec soin, afin d'en obtenir les meilleurs résultats.

Le choix de l'évaluation à réaliser dépend en grande partie du niveau de maturité de l'organisation en matière de sécurité. Mais les meilleurs résultats sont obtenus en les effectuant précisément dans l'ordre indiqué – voyons pourquoi.

La recherche de vulnérabilités est une chose que chaque organisation devrait faire régulièrement. C'est la première et la plus élémentaire des activités de gestion des vulnérabilités : il s’agit de trouver les vulnérabilités connues et les défauts de configuration. Les outils de recherche de vulnérabilités feront un excellent travail d'énumération des correctifs installés, de recherche des comptes par défaut et des erreurs de configuration. Les plus modernes de ces outils peuvent également s'authentifier sur les systèmes cibles afin de confirmer la liste des correctifs installés, et réduire ainsi les faux positifs.

Il est recommandé de procéder régulièrement à des recherches de vulnérabilités, de préférence avec des outils internes. Les outils les plus populaires sont Rapid7 Nexpose, Tenable Nessus et Qualys. Gardez simplement à l'esprit que ceux-ci sont à utiliser pour des recherches sur les hôtes du réseau. D’autres outils, spécialisés, existent pour la recherche de vulnérabilités au niveau applicatif (c'est-à-dire pour les applications Web).

Les tests d'intrusion devraient constituer l’étape suivante. Au moment de se décider pour un tel test, la définition de sa portée est très importante : le but d'un test d'intrusion est de trouver toutes les vulnérabilités (ou du moins autant que possible) dans la cible. Le périmètre cible peut être un ensemble d'adresses IP ou de réseaux (lorsqu'il s'agit d'un test d’intrusion sur le réseau), une application Web, des services Web, etc.

Un « pentester » est normalement limité dans le temps – un test d'intrusion dure généralement de 5 à 15 jours ouvrables. Il est donc évident que l'ensemble du processus doit être aussi efficace que possible. Cela implique une définition aussi claire et précise que possible du périmètre considéré et que tout obstacle potentiel soit éliminé. Par exemple, si vous testez une application mobile, il serait bénéfique de fournir une build sans masquage : nous savons que le masquage peut être contourné, mais en fournissant une tel build, le testeur ne perdra pas de temps à cela, et pourra se concentrer sur la recherche des vulnérabilités.

De plus, un test d'intrusion permet de débusquer des vulnérabilités qu'un outil de recherche de vulnérabilités automatisé ne peut pas trouver – par exemple, les vulnérabilités logiques. Les vulnérabilités dans la logique métier sont pratiquement impossibles à identifier de manière automatique – du moins pour les outils actuels –, mais elles peuvent s’avérer dévastatrices. Un bon exemple en est, pour une banque - avec une application banque en ligne - le cas où un attaquant se connecte et tente de créer une transaction de -100 EUR : celui qui devrait être débiteur des fonds les reçoit, au lieu du destinataire.

Une autre catégorie de vulnérabilités très courante est la référence directe à un objet (DOR, Direct Object Reference) : des attaquants tentent d'accéder à des objets – par exemple, des enregistrements de transactions – appartenant à des utilisateurs arbitraires, simplement en modifiant des références d'objet. Comme ces références ne sont généralement que des nombres (ID), la modification est facile. Mais de nombreux scanners sont aveugles à ces vulnérabilités, car ils ne comprennent pas le contexte ; c'est-à-dire le fait qu'en changeant une ID et en récupérant l'enregistrement de transaction d'une autre personne, nous avons trouvé une vulnérabilité critique.

Le résultat d'un test d'intrusion est un rapport qui devrait détailler toutes les vulnérabilités identifiées, avec des recommandations sur la façon de les corriger. Toutes les vulnérabilités répertoriées doivent être vérifiées par le testeur – il ne doit pas y avoir de faux positifs ! Les tests d'intrusion exigent beaucoup de travail manuel ; c'est pourquoi ils prennent beaucoup de temps et sont généralement plus coûteux qu'une recherche de vulnérabilités.

Vient enfin l’exercice offensif, dit de red teaming. C’est le test ultime des défenses d'une organisation. Dans un tel exercice, les attaquants se voient attribuer un objectif et ils peuvent généralement utiliser tous les moyens qu'ils veulent pour l’atteindre. Il peut s'agir d'écrire de nouveaux exploits, d'utiliser l'ingénierie sociale, de se déplacer latéralement, etc.

La principale différence entre un exercice offensif et un test d’intrusion est qu'avec le premier, il n'y a qu'un objectif, tandis qu’avec le second, il s’agit de trouver toutes les vulnérabilités dans le cadre défini. Un exercice offensif peut passer à côté de certaines vulnérabilités, mais il vous montrera comment vous résistez à un véritable attaquant. Et très souvent, un exercice offensif constitue un bon entraînement pour l’équipe bleue [équipe défensive] d'une organisation : il montrera à quel point elle est efficace pour détecter les attaques et potentiellement les contenir pendant qu'elles se produisent.

Bien que ce qui précède soit le processus idéal pour gérer les vulnérabilités au sein d'une organisation, le choix de la méthode d'évaluation de la sécurité dépend également du niveau de maturité de l'organisation. Si, par exemple, l'organisation concernée n’applique pas régulièrement les correctifs sur ses serveurs, il ne sert à rien de faire un test d’intrusion ou un exercice offensif, puisque l’hygiène de base fait défaut. Il faut donc d'abord s'attaquer à ce problème. Ce n'est qu’une fois que l'on s’est occupé des problèmes les plus simples qu'une évaluation de la sécurité plus sophistiquée peut être effectuée.

De même, si une organisation lance une nouvelle application, par exemple, un test d'intrusion pourrait être plus approprié, puisque le but sera de trouver toutes les vulnérabilités de la nouvelle application. Et, si vous avez déjà testé la majorité de vos services et que vous avez une équipe bleue entraînée, un exercice offensif vous aidera à montrer à quel point l'organisation est prête à faire face à une attaque bien réelle.