Tests d'intrusion
Les tests d’intrusion, parfois appelés audits techniques, ou encore pentests (pour penetration testing), constituent des simulations d’attaques informatiques au plus proche des cas réels.
Nos auditeurs techniques, spécialisés en cybersécurité offensive, tenteront de compromettre le périmètre audité afin d’en desceller les vulnérabilités effectives, à portée d’un attaquant malveillant.
Un test d’intrusion permet de gagner en visibilité sur les vecteurs d’attaques possibles, pour les rendre inopérants. Un contre audit, validant la bonne implémentation des mesures de sécurité, vient souvent compléter la démarche de sécurisation.
Les modes de tests d’intrusion
BlackBox : aucune information n’est transmise à l’auditeur, ce dernier aura à collecter les informations relatives au périmètre cible en effectuant de la recherche opérationnelle, directe ou indirecte. Il s’agit d’un excellent moyen de prendre conscience des informations disponibles pour les attaquants potentiels, et de limiter au mieux la fuite d’information stratégique.
GreyBox : peu d’informations sont transmises à l’auditeur. Un compte « utilisateur » est souvent communiqué, pour tester la ségrégation des droits et l’élévation de privilège. Ce mode de test d’intrusion est souvent retenu des commanditaires : il permet d’ajouter un périmètre restreint à tester, dans le cas où il n’y aurait pas de vulnérabilités sur les mires d’authentification.
WhiteBox : le maximum d’informations est transmis à l’auditeur. Documentation, routes d’API, comptes de différents niveaux de droits… Ce mode de test d’intrusion permet de tester le maximum de vulnérabilités, la surface d’attaque étant à son maximum dès le démarrage de l’audit. Ce mode est souvent retenu par les commanditaires mûrs et ayant déjà avancé sur leur cybersécurité.
RedTeam : test d’intrusion incluant la dimension physique. Sont alors également testés les vulnérabilités propres à la protection des locaux : portée WiFi, badges d’accès, processus d’entrée dans les bâtiments… à ne pas confondre avec « LA red team » (équipe offensive, réalisant les tests d’intrusion), souvent opposée à la blue team (équipe de protection et surveillance du système d’information).
Les types de tests d’intrusion
Les tests d’intrusion peuvent porter sur divers
environnements cibles, appelés périmètres.
Audit Web : concerne un ou plusieurs sites web : URL directe ou nom de domaine avec ses sous-domaines.
Audit serveur : concerne un ou plusieurs serveurs, accessibles ou non depuis Internet. Les auditeurs effectueront une analyse minutieuse des ports ouverts, des services en écoute et des vulnérabilités logiques, techniques, ou de versions.
Audit infrastructure : concerne un environnement de travail, souvent interne au système d’information du commanditaire.
Audit logiciel : concerne un logiciel ou application mobile et peut inclure les serveurs avec lesquels communique ledit logiciel.
Audit d’API : concerne une API. Les auditeurs testeront alors les routes accessibles, leurs niveaux de sécurisations par rapport aux besoins des droits, les éventuelles injections, etc.
Audits de systèmes industriels : concerne un environnement industriel (Information Technology + Operational Technology).
Nos conseils
Un test d’intrusion est un excellent moyen de détecter des vulnérabilités présentes sur un périmètre à éprouver. Nous souhaiterions toutefois porter à votre attention les points suivants :
Un test d’intrusion peut faire des dégâts. Ne choisissez que des prestataires assurés précisément pour cette activité. Bien que la plupart des professionnels le soient, cela reste un point à vérifier avec attention. Aussi, une sauvegarde de l’environnement et / ou des données associées est pertinente : il se peut qu’une manœuvre offensive n’ait pas les résultats escomptés.
Privilégier une communication riche et claire avec le prestataire. Des rapports quotidiens et une disponibilité à l’échange en cours de mission seront des facteurs de réussite de l’audit technique.
Le périmètre doit être réfléchi. Demander un test d’intrusion sur un périmètre incomplet revient à ne pas tester toutes les vulnérabilités que pourrait contenir votre projet final. Le meilleur moment est souvent avant la mise en production, ou après l’implémentation d’une nouvelle fonctionnalité.
