Nous réalisons des tests d’intrusion (pentest) sur des périmètres très variés :
Le test d’intrusion vous apporte une évaluation du risque concrète, sur le périmètre de votre choix, aux sources de menace que nous simulons.
Le test d’intrusion est un instrument de mesure du risque utile dans plusieurs phases du cycle de vie d’un actif ou d’un système d’information.
L’analyse de risque, quel que soit la méthodologie ou le formalisme utilisé, est un processus essentiel pour éclairer une organisation sur les risques qui pèsent sur son activité et ses biens essentiels.
Le test d’intrusion vient en support de ce processus en simulant des scénarios d’attaques et des sources de menace sur les actifs de l’entreprise, biens essentiels et biens de support.
De la sorte, il permet de mesurer précisément le risque et aussi d’évaluer l’efficacité des mesures de traitement.
L’objectif ultime est d’aider l’organisation à prendre les bonnes décisions : protection des processus et des données métier, et choix de mesures de sécurité adéquates et avec un ratio coût/efficacité optimal.
Une approche mature consiste à prendre en compte la cybersécurité très tôt dans les phases de développement d’un nouvel actif (infrastructure, application ou produit).
Dans l’optique où plus les failles sont corrigées tôt, plus l’effort et le coût de correction sont faibles, les tests d’intrusion permettent d’éprouver la sécurité de composants avant une mise en production.
Le test d’intrusion peut faire parti des points de contrôle réguliers menés sur le système d’information, afin de s’assurer que les menaces comme les vulnérabilités n’ont pas évoluées.
Le test est aussi généralement déclenché à chaque changement majeur opéré sur le système d’information : nouveau projet, ouvertures de flux, migration d’application ou changement de version, Etc.
Lors d’un test en boîte noire, l’auditeur ne dispose d’aucune information sensible ou accès sur la cible.
Dans cette optique, la source de menace simulée est l’attaquant externe, peu informé au départ ou ne ciblant pas spécifiquement l’organisation, mais plutôt ses ressources techniques : criminel, hacker, activiste, concurrent, etc.
En boîte grise, l’auditeur dispose d’informations sensibles et d’accès, plus ou moins privilégiés selon le contexte, afin de mener ses tests.
La source de menace cette fois simulée est plutôt interne (stagiaire, collaborateur, prestataire), puisque l’attaquant dispose de ressources.
Il peut s’agir par exemple d’éprouver la robustesse d’une application face à un utilisateur cherchant à augmenter ses privilèges, pour par exemple passer administrateur. Ce type d’audit est plus long, proportionnellement à la complexité de l’application et aux comptes à tester.
L’enjeu de la boîte blanche est de fournir toutes les informations et les accès possibles à l’auditeur, incluant des documents d’architecture, des comptes d’accès ou encore le code source.
Ce type de test vise à donner toutes les clés à l’auditeur pour réaliser les tests les plus exhaustifs possibles, potentiellement au détriment du réalisme de la phase de recherche.
La démarche technique est similaire à l’audit en boîte blanche, à la différence qu’un audit du code source de l’application sera mené de manière concomitante.
L’approche est différente, dans la mesure où le code source n’est plus simplement en support pour vérifier des hypothèses : il occupe au contraire une place centrale, car l’auditeur l’analyse en profondeur à la recherche de la plus grande exhaustivité possible.
Le test d’intrusion a pour objectif de permettre une mesure réaliste du niveau de risque porté par le périmètre audité.
Concrètement, l’auditeur tend vers l’exhaustivité dans sa recherche de vulnérabilités, surtout pour celles dont le risque résiduel ne saurait être acceptable.
L’objectif attendu par l’audité peut également être précisé, par exemple : accéder aux données bancaires stockées sur un serveur. L’auditeur mènera ainsi le test d’intrusion en ayant pour objectif final celui précisé par l’audité.
Au-delà de cette découverte de faiblesses, le test d’intrusion doit proposer les mesures de traitement du risque les plus adaptées et efficaces.
L’audit se déroule en plusieurs phases :
La réalisation du test d’intrusion est une succession d’étapes logiques et potentiellement cycliques jusqu’à l’atteinte de l’objectif :
Reconnaissance : l’auditeur cartographie le périmètre, découvre les technologies, s’approprie le fonctionnement d’une application, etc. Il construit notamment une liste de cibles et de points d’entrées potentiels.
Recherche de vulnérabilités : cette phase se base sur les résultats de la reconnaissance, pour rechercher d’éventuelles vulnérabilités parmi les cibles retenues.
Exploitation : à ce stade, l’auditeur tente d’exploiter les potentielles vulnérabilités identifiées. Le but est de les qualifier, c’est-à-dire de confirmer que la vulnérabilité est bien réelle. Seule la réalisation complète de cette chaîne d’exploitation, de la recherche jusqu’au gain d’accès, permet de mesurer le risque.
Appréciation du risque : lorsqu’une vulnérabilité est avérée, l’auditeur en évalue l’impact : gain d’accès, impact technique et métier, etc. Selon le niveau de gravité, une procédure d’urgence avec le commanditaire peut être déclenchée. Dans tous les cas, le niveau de risque sera présenté en compte-rendu et dans le rapport d’analyse.
Au-delà de l’exploitation unitaire de vulnérabilités, l’auditeur réalise une phase d’analyse lors de laquelle il prend du recul sur son travail.
Il doit par exemple réfléchir à des scénarios d’exploitation combinant plusieurs vulnérabilités, car une attaque peut très bien combiner plusieurs vulnérabilités de risque faible pour aboutir à un scénario de risque élevé.
Il va aussi travailler aux recommandations de traitement du risque, avec deux préoccupations :
sélectionner les plans de traitement du risque au meilleur rapport coût/efficacité dans le contexte de l’organisation ;
proposer des recommandations compréhensibles, applicables et détaillées.
Lors de cette dernière phase, l’auditeur synthétise ce travail dans un rapport d’audit qui comprend :
Notre calcul du risque se base sur un standard, le score CVSS v3.1, que nous utilisons pour évaluer toutes les composantes techniques du risque, mais aussi l’impact métier.
Nous garantissons naturellement la parfaite confidentialité de l’ordre de mission, des traces d’audit et des rapports émis.
Cet engagement est concrétisé par notre charte d’éthique, appliquée sur notre organisation et nos analystes, ainsi que par les mesures techniques que nous mettons en œuvre (chiffrement, infrastructure isolée, stricte gestion des droits, politique de rétention des données, etc.).
D’autre part, le cadre technique, notamment les conditions et la durée de rétention de l’information, est contractualisé dès avant l’audit.
Un compte-rendu de clôture de l’audit vous sera également remis, avec les indications de retour à la normale des systèmes audités (éventuels comptes de test et fichiers à supprimer, ou autres actions).
N’hésitez pas à nous contacter, nous nous ferons un plaisir de partager avec vous plus de précisions à ce sujet.