LE DÉROULEMENT DU PENTEST

24 Septembre 2020
image_en_tete
Dans le précédent article nous avons pu définir ce qu’était un pentest et le moment opportun pour en réaliser un, comment bien le cibler pour augmenter sa valeur ajoutée et comment le préparer en interne avant les échanges avec le prestataire de services qui va l’exécuter.

Dans ce second article (cliquez ici pour accéder à la première partie) nous allons développer plus en détail quelles sont les différentes approches possibles, donner quelques exemples de questions qui seront probablement posées par le prestataire en charge du pentest, présenter les 7 étapes du pentest selon la méthodologie “PTES” et pour terminer, parler des livrables.

Tout comme dans le premier article, les exemples utilisés ici vont surtout porter sur les pentests orientés web, mobile et infrastructure mais les notions peuvent s’appliquer à d’autres types de cibles. De même, les échanges contractuels et financiers sont exclus de l’article.

 

Préparer le démarrage :

Nous allons partir du postulat qu’en lisant le premier article vous avez correctement identifié le besoin et la raison d’être de votre projet de pentest. De même, vous avez défini les cibles les plus pertinentes pour ce pentest et vous êtes assurés que les attentes de tous les acteurs internes (décideurs ou techniques) soient alignées. 

Il est donc temps de choisir l’approche que les pentesteurs vont adopter. La première question à se poser est : « quelle couleur de boîte choisir ? ».

Il existe 3 principales stratégies de pentest, définies par trois couleurs de boîtes, qui dépendent de vos besoins et des scénarios d’attaque que vous souhaitez tester. Ces scénarios vont être définis compte tenu du niveau d’information que vous communiquerez aux pentesteurs au début du test d’intrusion. 

 

box_image

 

Boite Noire

Les pentesteurs ne disposent d’aucune - ou de très peu - d’informations sur les cibles de l’audit. 

L’objectif est alors de simuler l’approche qu’un acteur malveillant externe va avoir pour cibler et attaquer l’entreprise. Cette approche va nécessiter de la part des pentesteurs de procéder dans un premier temps à la recherche d’informations et à l’identification des cibles via des moyens passifs (données open-sources, etc.) ou actifs (scans de ports, requêtes DNS, etc.).

Cette approche peut être intéressante si l’objectif défini pour le pentest est d’analyser l’exposition générale de l’entreprise aux menaces extérieures ou lors des approches type “Red Team” (nous allons voir la définition plus bas). 

Cependant, une prestation de pentest étant souvent limitée dans le temps, cette phase de recherche et d’identification sera forcément aussi restreinte. Une contrainte qu’un attaquant réel n’a pas forcément car il peut passer des semaines ou des mois à amasser les informations pertinentes avant une attaque. Cette approche n’est donc pas forcément optimale si le pentest est très ciblé ou très limité dans le temps.

 

Boite Grise 

Par exemple, ils peuvent avoir accès à des comptes internes (de préférence appartement à des profils d’utilisateurs différents) ou à un PC, fourni par le client avec des droits d’accès et configurations standards. Il est également possible de partager des informations sur l’architecture interne. 

L’objectif ici est d’avoir une approche plus ciblée et donc plus optimisée en terme de temps du pentest. Avec les informations fournies, les pentesteurs peuvent concentrer leurs efforts sur les cibles ayant les niveaux de criticité les plus importants ou consacrer plus de temps aux tests plus complexes techniquement.

De même, en fournissant les comptes utilisateurs, il est possible de simuler deux types de scénarios d’attaque :

  • Un premier, où l’attaquant réussit à compromettre un compte légitime
  • Et un second, où un utilisateur interne malveillant veut porter atteinte à l’entreprise.

 

Boite Blanche

Les pentesteurs disposent du maximum d’informations techniques (architecture, code source, identifiants, etc.) avant de démarrer le pentest. Il est également possible de mettre en place des canaux de communication entre les pentesteurs et les équipes d’administration ou de développement pour analyser et échanger sur les questions techniques.

L’objectif de cette approche est de fournir une analyse détaillée des vulnérabilités aussi bien externes qu’internes. Cependant elle pose plusieurs challenges :

  • La quantité des données en entrée augmente de façon exponentielle avec la taille et le nombre de cibles. L’analyse de toutes ces informations demande forcément plus de temps, et la durée du pentest sera rallongée.  
  • Des compétences spécifiques pour ce type de pentest sont nécessaires, allant de l’analyse de code statique à la maîtrise des bonnes pratiques de configurations d’équipements réseau. AUSY, grâce à la mutualisation des compétences et au savoir-faire de sa communauté, est en mesure de répondre à ce challenge.
  • Etant donné que les pentesteurs disposent d’un niveau d’informations élevé auquel les attaquants externes n’auront pas accès, il est possible de passer à côté de scénarios qui reposent sur des niveaux de connaissance plus faibles, lors de l’étude des différentes pistes d’attaques.

Pour résumer, si l’objectif du pentest est d’analyser de façon exhaustive un faible nombre de cibles (ex : une nouvelle application mobile, le nouveau serveur mail ou la nouvelle montre connectée), une approche en “boîte blanche” semble la plus appropriée tandis que si l’objectif est de simuler une attaque réaliste, la “boite noire” sera la plus proche de la réalité.

Il est également possible, si la durée du pentest le permet, de mixer les approches, ce qui permet une meilleure couverture des différents types de risques, en commençant par une analyse en boîte noire depuis l'extérieur puis, avec les informations fournies d’étudier les scénarios d’attaques internes en boite grise et pour finir étudier le code source et les configurations en boîte blanche pour identifier les vulnérabilités restantes. C’est d’ailleurs l’approche que nous recommandons à nos clients chez AUSY.

 

Les équipes de pentesteurs

Quelle que soit la couleur de boîte choisie, trois équipes de pentesteurs interviendront sur le test, représentées par trois couleurs différentes.

  • Les équipes rouges ou “Red Team”, constituées de membres externes à l’entreprise : leur objectif est de tester l’efficacité des défenses d’une entreprise en simulant les différentes techniques et tactiques des acteurs malveillants et ce de façon continue et évolutive.
  • Les équipes bleues ou “Blue Team”, constituées de membres internes à l’entreprise (DSI interne) : leur objectif est de défendre l’entreprise des attaquants réels (aussi bien externes que internes) et de faire évoluer les systèmes de protection en fonction de leurs modes opératoires.
  • Les équipes violettes ou “Purple Team” : leur objectif est de garantir l’efficacité des échanges entre les équipes rouges et bleues au sein d’une organisation. Ça peut d’ailleurs ne pas vraiment être une équipe mais simplement des procédures et exercices réguliers pour encourager le dialogue et améliorer les méthodes de travail des deux groupes.

 

Préparer les infos :

Une fois le niveau de connaissances défini et la couleur de la boîte choisie il peut être intéressant d’anticiper et préparer les réponses aux questions qui seront posées par le prestataire lors de la première réunion technique. 

Ci-dessous quelques exemples (liste non exhaustive) :

  • Pour les pentests applicatifs :
    • Une description fonctionnelle de la cible (A quoi sert l’application, qui l’utilise, à quelle fréquence, son niveau de criticité pour l’entreprise, quelles sont les fonctionnalités clés ? …)
    • Une description technique de la cible (Quel âge a l’application, est-elle souvent mise à jour, quel est le langage/framework utilisé pour le développement, comment l’application s’interface avec d’autres outils ? …)
    • Une estimation de la taille de l’application (Nombre de rôles différents, nombre et type d'interactions avec les utilisateurs, nombre d’écrans statiques/dynamiques ? ...)
  • Pour des pentests infrastructure :
    • Le nombre d’IP actives dans le périmètre de tests
    • Le type d’environnements présents (postes utilisateurs, serveurs Linux, équipements industriels …)
    • Présence d’équipements atypiques/legacy (MainFrames, AS400 …)
    • Les mesures de sécurité en place (FW / IPS / Equipe SOC …)
  • Pour les conditions du pentest :
    • Y a-t-il une possibilité d’utiliser des environnements de test ?
    • Y a-t-il une possibilité d’accéder aux applications/infrastructures à distance ?
    • Quels sont les entrants fournis par le client ?
    • Les équipes de sécurité internes seront-elles prévenues ?
    • Quels sont les types de tests autorisés / interdits ?
    • Quelles sont les limites du périmètre ou de la profondeur du pentest ?
    • Y a-t-il une possibilité de consulter et valider les éventuels pentests précédents ?
  • Pour l’organisation du pentest :
    • Quelles sont les dates éventuelles de début du test ?
    • Quelles sont les contraintes spécifiques sur les horaires / jours de travail ?
    • Quelles sont les contraintes vis à vis des équipes business ?
    • Quels sont les accords des fournisseurs tiers le cas échéant.

En fonction des cibles et du niveau de connaissance définis, l’échange peut devenir assez technique, il est donc important d’impliquer aussi bien des acteurs business que back-office afin d’apporter les réponses les plus précises possibles. 

Chez AUSY, nous proposons à nos clients des formulaires et questionnaires qui peuvent aider à la préparation de ces premiers entretiens techniques, tout en favorisant le gain de temps.

 

Le déroulement du pentest :

Chaque pentest et contexte client est spécifique, il est donc important d’adopter une méthodologie de travail assez générique pour la majorité des cas. Une des références dans le domaine est le ‘Penetration Testing Execution Standard’ - PTES.

 

Le PTES, qu’est-ce que c’est ?

Le PTES est un ensemble générique de bonnes pratiques qui établissent les principes fondamentaux pour la bonne réalisation d’un test d’intrusion. Le mot “générique” est important ici car le PTES peut aussi bien être appliqué lors d’un pentest d’une application mobile que lors d’un test d’intrusion dans les locaux d’une entreprise.

Le PTES décompose chaque pentest en 7 grandes étapes :

1 - Les interactions avant le pentest

Cette phase regroupe l’ensemble des échanges décrits ci-dessus, les accords contractuels et financiers, l’établissement des canaux de communication sécurisés ainsi que la préparation du pentest. 

L’objectif est d’établir un cadre légal, technique et organisationnel, validé par le client et le prestataire et ainsi garantir une réalisation à hauteur des attentes des deux parties.

Chez AUSY nous proposons à nos client un ensemble de documents contractuels :

  • Des accords cadrant la prestation de pentest avec les engagements, les limites et les responsabilités de chaque acteur ;
  • Des accords de confidentialité ;
  • Les accords commerciaux en fonction du type de mission (AT / Forfait …).

2 - La collecte d’informations

C’est une phase très importante pour chaque pentest car elle permet d’identifier les cibles potentielles, d’amasser des informations utiles lors des étapes postérieures et d’identifier dès le départ des possibles pistes d’attaque.

On parle souvent de 2 types de reconnaissances :

  • La reconnaissance passive :
    • OSINT (Open Source Intelligence) - les données accessibles publiquement. Le “OSINT Framework” (https://osintframework.com/) donne un bon aperçu du type de données exploitables.
    • Les données accessibles via une utilisation normale (en naviguant sur l’application, en analysant le trafic réseau par exemple ou via des recherches Google spécifiques).
  • La reconnaissance active via des outils dédiés :
    • Scans de ports
    • Enumeration DNS et SMTP
    • Services exposés (serveur mail, ssh, web, …)
    • Documents et dossiers accessibles ou cachés…

Chez AUSY et si la prestation le prévoit, nos pentesteurs profitent également de cette phase pour vérifier les différentes sources publiques ou le darkweb pour identifier d’éventuelles données sensibles du client (documents accessibles, comptes utilisateurs compromis, sous-domaines connus, etc …) et fournir un rapport condensé.

3 - Modélisation des menaces

L’objectif de cette phase est d’identifier les principales cibles au sein d’une entreprise (aussi bien en termes d’actifs qu’en termes de processus) et les sources de menaces les plus probables (leur origine et leur capacités techniques).

Le déroulement est en général découpé en 4 étapes :

  • La collecte d’informations (schémas d’architecture, diagrammes d’organisation interne, les employés, les données clients …) ;
  • L’identification des actifs principaux et secondaires (logiciel ERP, site web vitrine, la base de données clients…) ;
  • L’identification des sources de menace (hacktivistes, organisations étatiques, groupes de crime organisé, employés internes …) ;
  • La cartographie des menaces vis à vis des actifs identifiés.

Pour prendre l’exemple d’une entreprise travaillant dans la pétrochimie :

  • Ses actifs les plus critiques peuvent être les outils industriels de production et les informations techniques associés, les brevets et R&D, les informations financières et le site vitrine.
  • Et en vecteurs de menaces les organisations étatiques, le crime organisé et les hacktivistes semblent les plus probables. 

Avec les deux premiers possédant les connaissances techniques et les moyens pour viser les actifs les plus sensibles tandis que les hacktivistes vont plutôt utiliser des outils publiquement accessibles pour tenter de défacer le site web vitrine.

Bien qu’applicable pour tous types d’approches, les conclusions de cette phase seront les plus pertinentes lorsque le pentest est conduit en “boîte blanche” car l’analyse sera plus précise avec les informations internes fournies.

4 - Analyse des vulnérabilités

Bien que les techniques utilisées puissent fortement varier en fonction du type de cibles du pentest, l’objectif principal de cette phase reste l’identification et la validation de vulnérabilités exploitables.

Les techniques, aussi bien actives (scanners de vulnérabilités, énumération de répertoires, récupération des entêtes …) que passives (analyse du trafic réseau, analyses métadonnées), automatisées ou manuelles, sont utilisées. Les informations recueillies sont ensuite corrélées et validées. 

Les pentesteurs vont par exemple chercher des failles connues dans les versions logicielles relevées, déterminer les identifiants par défaut ou encore analyser les erreurs de configurations les plus communes sur les systèmes ciblés. 

Toutes ces informations vont permettre la création d’arbres d’attaques (une liste d'attaques possibles en fonction de la cible et des informations récoltées) pour la phase d’exploitation.

Chez AUSY, nos pentesteurs disposent des outils et logiciels dédiés et sont encouragés au sein de la communauté cyber/pentest interne à rester à l’affût de nouvelles techniques et vulnérabilités pour pouvoir ensuite les appliquer dans le cadre de nos prestations.

5 - Exploitation

La variété de scénarios d’exploitations est très large. Elle dépend du type de pentest et des cibles et peut aller des attaques sur les acteurs humains (phishing, usurpation d’identité) jusqu’à la recherche de failles “0 day” si toutes les autres méthodes ont échoué en passant par de la rétro-ingénierie, la manipulation de requêtes, la mise en place de scénarios “Man in the Middle” ou le fuzzing (injections de données erronées). Le tout en essayant d’éviter les moyens de protection et détection en place si les conditions du pentest l’exigent.

Le pentesteur doit toujours vérifier que les techniques d’exploitations utilisées correspondent au périmètre et aux conditions d’engagement convenues avec le client. 

Lors de cette phase, nos pentesteurs peuvent s’appuyer sur la mutualisation des compétences techniques de la communauté pentest AUSY.

6 - Post Exploitation

Cette phase (parfois optionnelle), qui n’est applicable que si l’étape précédente a été un succès, a plusieurs objectifs :

  • La mise en place de canaux d'accès malveillants et permanents (persistence en anglais) ;
  • L’identification des informations sensibles accessibles ;
  • La récupération des preuves du succès du pentest pour le rapport final (en général des captures d’écran) ;
  • La récupération des accès et comptes utilisateurs supplémentaires, permettant de compromettre d’autres éléments du SI. 

Les règles d’engagement validées lors de la réunion technique au démarrage du projet sont très importantes ici : 

  • Est-il autorisé d’accéder à des informations et fichiers personnels ?
  • Est-il autorisé de désactiver les mesures de protection en place ?
  • Est-il autorisé/demandé de cacher les actions réalisées en supprimant les logs ?
  • Comment réagir en cas de découverte d’une attaque passée ou en cours ?
  • Quelles informations sensibles inclure dans le rapport et sous quelle forme ?
  • Comment seront stockées et transmises les informations sensibles identifiées ?

Toutes ces règles visent à protéger aussi bien le client que le pentesteur et garantissent la sécurité des données ainsi que la conformité légale des actions réalisées.

7- Reporting

La dernière étape du pentest consiste à rédiger et remettre des rapports sous trois formats différents :

  • Une présentation de restitution :
    Souvent au format PowerPoint, plus ou moins technique en fonction des interlocuteurs présents et qui rappelle le contexte et les objectifs du pentest puis présente la posture générale vis à vis des risques de sécurité ainsi que les principales vulnérabilités identifiées avec les remédiations associées. Cette présentation est souvent suivie par une session de questions / réponses entre le client et les pentesteurs.
  • Un rapport pour le management :
    Un résumé qui rappelle le contexte et les objectifs, décrit succinctement le déroulement du pentest, présente les résultats sous la forme  d’indicateurs chiffrés ou graphiques (tableaux résumés, graphiques …), l’analyse des risques et d’impact des différentes vulnérabilités identifiées avec les remédiations associées ainsi qu’une suggestion de planning pour leur application en fonction de leur priorité.
  • Un rapport technique détaillé :
    Ce rapport reprend les informations présentes dans le rapport au management tout en apportant des informations techniques additionnelles. Ainsi pour chaque vulnérabilité peuvent être fournis : les références OWASP & CWE, des indicateurs de risque et d’impact et de facilité d’exploitation, une explication détaillée de la vulnérabilité et du chemin d’exploitation, des outils utilisés, des conseils pour la remédiation, et pour terminer, les preuves associées.

Toutes ces informations doivent offrir au client la possibilité d’analyser et comprendre les vulnérabilités, les reproduire si nécessaire puis appliquer les correctifs adaptés et de les présenter au management ou à des auditeurs si nécessaires. 

Une fois le rapport du pentest remis, le projet ne doit pas s’arrêter. Il est important de s’assurer de l’appui du management pour valider le planning ainsi que les ressources techniques nécessaires à la mise en place des correctifs. 

S’ils sont complexes ou nécessitent des profondes modifications il peut être également pertinent d’ajouter à la prestation du temps additionnel pour les valider.

 

Conclusion:

Pour conclure, le pentest est une méthode d’évaluation de la sécurité informatique d’une entreprise qui peut aider une société à améliorer sa protection numérique. Cependant, pour être efficace le pentest doit être préparé, suivi et si possible régulier.

Le choix d’un prestataire capable de vous accompagner, dès les premiers échanges et jusqu’après la remise des rapports joue donc un rôle très important.

Nos experts s’appuient sur le savoir-faire et les compétences de la communauté AUSY pour vous accompagner de A à Z sur toute la durée de votre pentest, et vous garantir des moyens de protection informatique qui répondront à vos besoins.

 

A propos de l'auteur, Pavel Chvets : 

 

photo_pavel
Après plusieurs expériences dans des secteurs critiques et exigeants tels que la production industrielle et le bancaire, dont une partie réalisée à l'étranger, j’emploie aujourd’hui mes compétences hétéroclites et complémentaires en sécurité informatique, gestion de projets et gouvernance pour relever les défis de la cybersécurité au sein d’AUSY mais également développer cette offre auprès de nos clients.

 

 

 

Aussi n’hésitez pas à visiter notre offre Cybersécurité

Parlons ensemble de vos projets.

contactez-nous