L’approche adoptée pour les tests intrusifs est conforme aux meilleures pratiques de l’industrie telles que l’OWASP, le NIST SP 800-115 ou encore le PASSI (Chapitre IV.4.4, IV.5 et IV.6). Elle suit les étapes suivantes :


Définition du cadre et réunion de lancement

Même si le périmètre de l’évaluation est décrit lors de la phase d’avant-vente, il est habituel de redéfinir le périmètre lors de la réunion de lancement avec le client, et si possible, avec ses équipes techniques.

C’est également le moment pour comprendre le contexte de l’évaluation ainsi que les principaux risques de sécurité redoutés par le client. Cela permet de se concentrer sur certaines vulnérabilités spécifiques, certaines fonctionnalités de l’application ou de mettre en avant un scénario spécifique dans le rapport.

En outre, lorsque cela est pertinent, un profil d’attaquant sera défini afin d’orienter les tests réalisés et de démontrer la faisabilité d’un scénario redouté.

Enfin, il est vérifié que toutes les conditions préalables aux tests ont été fournies, que le planning de l’évaluation est défini et que les points de contact sont connus.

Par défaut et sans indication contraire de la part du client, aucun test destructif n’est réalisé. A ce titre :

  1. Aucune attaque par déni de service n'est réalisée

  2. Les vulnérabilités qui peuvent avoir un impact destructif sont relevées sans être exploitées

  3. Les fonctions de suppression de données sont testées uniquement sur des jeux de tests

En cas de doute, un accord préalable est demandé au client.


Reconnaissance & Collecte d’Informations

La prestation commence par une phase de reconnaissance passive, au cours de laquelle sont recueillies des informations disponibles publiquement concernant chaque composant du périmètre. Les sources d’information publique peuvent être les registrars de domaine, les enregistrements DNS, les moteurs de recherche, les informations publiques de l’organisation (site web, blogs, etc.), les documents publiés, les bases de données divulguées, le code source des applications disponibles sur des plateformes publiques (GitHub, SourceForge, etc.), etc.

Commence ensuite la phase de reconnaissance active, qui inclut des scans réseau et des techniques de reconnaissance des services. Lorsqu’un service est identifié, toutes les informations disponibles telles que la technologie utilisée, sa version, les composants tiers utilisés, etc. sont recueillies.

Dans le cas de tests d’intrusion internes, le réseau peut également être écouté afin d’identifier certaines informations techniques (IP, adresses MAC, requêtes de diffusion, etc.). Cependant, aucune attaque active de type Man-in-the-Middle n’est réalisée sans l’autorisation explicite du client.

A l’instar des tests destructifs (i.e. Déni de service - DOS), les attaques de l’homme du milieu (ou Man-In-The-Middle) peuvent avoir des impacts non maitrisés sur une infrastructure.

Par exemple, ce type de technique peut interrompre une communication avec une authentification SSL / TLS, et ainsi perturber une application ou un flux de traitement de données.

A ce titre, aucune attaque active de type Man-in-the-Middle telle que l’usurpation ARP, l’empoisonnement ARP, le LLMNR ou l’empoisonnement NBT-NS n’est réalisée sans l’autorisation explicite du client.


Évaluation

L’évaluation peut être réalisée selon trois méthodes : les tests en boîte noire, en boîte grise ou en boîte blanche, c’est-à-dire sans information, avec un niveau d’information partiel ou avec toutes les informations que nous souhaitons, y compris le code source de l’application évaluée.

Quelle que soit la méthode choisie, tous les tests commencent dans un contexte en boîte noire afin de simuler le comportement d’un véritable attaquant sur le périmètre ciblé.

Les tests sont réalisés de manière à identifier les défauts de sécurité qui pourraient affecter toutes les couches du périmètre ciblé, notamment :

  1. La couche réseau

  2. L'architecture réseau / mécanisme de filtrage de flux

  3. Les protocoles utilisés

  4. Les systèmes d'exploitation

  5. La couche de chiffrement SSL / TLS

  6. Les composants middleware

  7. L'application

  8. Tout composant tiers

Dans le cas de tests d’intrusion d’une application web, les tests sont menés afin d’identifier toutes les vulnérabilités web, y compris celles répertoriées par le TOP10 de l’OWASP.

Lorsque le périmètre de l’évaluation inclut un mécanisme d’authentification, le client est interrogé sur la présence d’un mécanisme de verrouillage de compte. En fonction de la réponse, les tests incluront des tentatives d’authentification avec les comptes par défaut, avec des mots de passe faibles connus ou même une attaque par force brute.

L’approche exclut certains tests spécifiques qui pourraient altérer les performances d’un service ou entraîner un déni de service, sauf si le client le demande.

Une attention particulière est accordée aux tests susceptibles d’altérer les données telles que :

  1. La création/modification/suppression de comptes

  2. Les injections SQL dans une requête UPDATE ou une requête DELETE

  3. La création/modification/suppression de fichiers, etc.

D’une manière générale, le consentement du client est toujours demandé avant d’exploiter toute vulnérabilité de sécurité pouvant avoir un impact sur le composant du périmètre.

La plupart des tests sont réalisés manuellement. Cependant, des outils (tels que Nmap, WFuzz, Patator, Metasploit, Burp, etc.) sont également utilisés. Ces outils sont connus et maîtrisés par nos consultants et validés au niveau de l’entreprise. En cas d’utilisation d’un code d’exploitation public, celui-ci est évalué avant d’être utilisé. En cas de doute, le consentement du client est demandé avant son utilisation.

Une évaluation est toujours limitée dans le temps. Dans le cas où nous ne pourrions pas identifier les vulnérabilités de manière exhaustive, nos efforts seraient concentrés sur l’identification des vulnérabilités majeures.


Rapport d’audit

À la fin de l’évaluation, un rapport est produit. Ce dernier peut prendre différentes formes. Par défaut, un rapport d’évaluation complet au format PDF est produit. Ce dernier comprend :

  1. Le contexte de l'évaluation (périmètre, planning, prérequis, etc.)

  2. Une synthèse managériale

  3. Une synthèse technique

  4. La liste de toutes les vulnérabilités avec les détails techniques

  5. Le plan de remédiation

  6. Une liste de tous les hôtes et services identifiés

  7. Les limites de l'évaluation

Les vulnérabilités sont classées en fonction de leur gravité. La gravité d’une vulnérabilité est évaluée en fonction des paramètres suivants :

  1. Les prérequis pour exploiter la vulnérabilité (authentification, information spécifique, etc.)

  2. La complexité de l'attaque

  3. L'impact sur le périmètre ou sur l'entreprise

La gravité d’une vulnérabilité est classée en quatre catégories : Critique, Élevée, Moyenne et Faible.

De la même manière, les recommandations sont classées en fonction de :

  1. La complexité de la correction

  2. L'amélioration du niveau de sécurité induite par la correction

Cela permet de définir un plan d’action global et aide le client à prioriser la correction des failles identifiées.


Réunion de restitution / Soutenance (Optionnelle)

La méthodologie d’évaluation peut inclure une présentation formelle des résultats de l’évaluation aux équipes de direction et/ou qu’aux équipes techniques.

Les soutenances sont accompagnées d’un support de présentation PowerPoint.


Contre-audit (Optionnel)

Une fois les corrections mises en œuvre, il est proposé d’évaluer ces dernières afin de garantir que les failles de sécurité sont corrigées.

Cela permet également d’assurer qu’aucune nouvelle vulnérabilité n’a été introduite par la correction.