Pentest PME : cadrer le test et prioriser les corrections

Que démontre réellement un pentest ?

Un pentest, ou test d’intrusion, cherche à vérifier si certaines faiblesses peuvent être exploitées dans un périmètre convenu. Il répond à une question précise : « Sur ce portail, ce réseau ou cet accès distant, quel chemin d’attaque plausible peut être démontré sans mettre l’activité en danger ? » L’ANSSI décrit les modes boîte noire, grise et blanche ainsi que les tests depuis l’intérieur ou l’extérieur du système d’information dans le référentiel PASSI.^[1]

Le résultat n’est pas un certificat de sécurité. Un test couvre des actifs, une période, des accès et des techniques autorisées. Il peut démontrer un problème important sans découvrir toutes les faiblesses possibles ; inversement, l’absence de découverte critique pendant la mission ne prouve pas qu’aucune attaque future n’est possible.

Exemple PME. Le portail client permet de déposer des documents commerciaux. Le test peut établir qu’un compte ordinaire voit un dossier qui ne lui appartient pas. La décision n’est pas seulement de « corriger une faille » : il faut identifier les données accessibles, bloquer l’accès, vérifier les autres fonctions qui utilisent le même contrôle et prévoir un retest. Il s’agit d’un scénario illustratif, pas d’un constat sur un système réel.

Quand le pentest est-il le bon outil ?

Choisissez un pentest lorsqu’une décision dépend de la résistance concrète d’un système identifié : mise en ligne d’une application métier, ouverture d’un accès partenaire, migration d’un portail, évolution majeure d’une API ou vérification d’un correctif important. La mission doit pouvoir nommer l’actif, l’usage métier et la conséquence que l’on cherche à prévenir.

Si l’entreprise ne sait pas quels systèmes elle exploite, qui dispose d’accès administrateur ou quelles obligations s’appliquent, commencez plutôt par un audit cybersécurité ou un cadrage des risques. Le pentest vérifie une hypothèse technique sur un périmètre ; il ne remplace pas l’inventaire ni la gouvernance.

La comparaison aide à choisir l’outil, mais le présent article se concentre ensuite sur la conduite du pentest et l’usage de ses résultats. Le NIST distingue également les techniques d’évaluation et leurs limites dans son guide SP 800-115.^[2]

Quel périmètre tester en priorité dans une PME ?

Partez d’une activité, pas d’une liste d’adresses IP. Pour une PME qui reçoit des commandes via un portail, demandez quels composants permettent de se connecter, de passer commande, de consulter des factures et de gérer les comptes. Le périmètre peut comprendre l’application web, son API, l’identité utilisée et les interfaces avec le logiciel de gestion. Une exclusion telle que « le prestataire d’identité n’est pas testé » doit figurer dans le rapport.

Un test externe examine les actifs accessibles depuis Internet. Un test interne part d’un accès déjà présent, par exemple un compte ou un poste de travail fourni pour le scénario. Un test applicatif se concentre sur les fonctions et les droits d’un site, d’une API ou d’un logiciel. Ces catégories peuvent se combiner : elles ne désignent pas des niveaux de qualité.

Avec la boîte noire, le testeur reçoit peu d’informations. En boîte grise, il dispose d’accès ou d’éléments ciblés pour couvrir certains usages. En boîte blanche, davantage d’informations techniques sont fournies. Le choix dépend de la question à résoudre : fournir un compte client et un compte gestionnaire peut être plus pertinent que consacrer toute la mission à retrouver seul la page de connexion. Le référentiel PASSI reconnaît ces trois modes.

Décision pratique. Si le budget ne permet de tester qu’un seul périmètre, choisissez celui dont la compromission arrêterait une activité critique, exposerait des données sensibles ou donnerait un accès privilégié. Expliquez ce choix et ce qui restera non testé. Aucun montant universel ou retour sur investissement chiffré ne peut être déduit sans périmètre.

Comment cadrer les règles d’engagement sans risquer la production ?

Avant le premier test, l’entreprise et le prestataire doivent valider par écrit les cibles, les exclusions, les horaires, les accès fournis, les techniques permises, la gestion des preuves et les conditions d’arrêt. Le NIST appelle ces contraintes les « rules of engagement » : elles encadrent l’exécution des tests de sécurité.^[2] Elles protègent autant l’entreprise que les intervenants.

• Objectif : quelle décision le rapport devra-t-il éclairer ?
• Frontière : quelles applications, plages réseau, comptes, filiales ou prestataires sont inclus ou exclus ?
• Continuité : quelles plages horaires, limites de charge, sauvegardes et procédures d’arrêt sont prévues ?
• Contacts : qui peut autoriser un changement, répondre à une alerte ou interrompre le test ?
• Preuves : quelles données peuvent être observées, copiées, conservées puis détruites ?
• Restitution : à qui signaler immédiatement une vulnérabilité critique et comment protéger le rapport ?

Un pentest comporte un risque opérationnel, surtout en production. Le réduire ne signifie pas promettre un risque nul : il faut rendre explicites les tests interdits, l’usage éventuel d’un environnement de préproduction, le protocole d’urgence et la personne habilitée à arrêter la mission. Le devis qui se contente de « tester le site » sans ces règles n’est pas un cadrage suffisant.

Comment se déroule une mission de pentest ?

Le déroulement varie selon le système, mais une mission utile relie les travaux techniques à une décision finale. Le guide NIST SP 800-115 organise les évaluations autour de la planification, de l’exécution et de l’analyse des constats avec des stratégies de mitigation.^[2]

1. Cadrage et autorisation : l’entreprise valide le périmètre, les contraintes et les interlocuteurs.
2. Reconnaissance autorisée : le testeur identifie les fonctions et surfaces pertinentes dans ce périmètre.
3. Vérification contrôlée : les faiblesses plausibles sont confirmées dans la limite des règles convenues, sans rechercher une démonstration plus intrusive que nécessaire.
4. Qualification : chaque constat est rapproché des actifs, des droits obtenus, des données concernées et des contrôles existants.
5. Restitution : direction et équipes reçoivent les informations dont elles ont besoin pour décider et corriger.
6. Correction et retest : les responsables traitent les priorités, puis font vérifier les changements importants.

Il ne faut pas confondre la fin des manipulations et la fin de la mission. Sans restitution exploitable, responsable nommé et plan de retest, une démonstration technique impressionnante peut ne produire aucune réduction vérifiée du risque.

Que doit contenir le rapport remis à la direction et à l’équipe it ?

L’OWASP recommande un rapport compréhensible par la direction comme par les équipes techniques, qui expose les risques et les corrections.^[3] Pour une PME, cela signifie deux niveaux de lecture cohérents : une synthèse qui permet de décider, puis des fiches de constat assez précises pour corriger et vérifier.

• Synthèse dirigeant : périmètre, principaux scénarios démontrés, conséquences plausibles, décisions urgentes et limites du test.
• Méthode et exclusions : dates, accès fournis, fonctions parcourues, techniques permises et ce qui n’a pas été testé.
• Constat vérifiable : actif concerné, preuve protégée, conditions nécessaires, effet observé, gravité motivée et confiance dans le résultat.
• Remédiation : action attendue, propriétaire, dépendances, contrôle compensatoire éventuel et moyen de confirmer la correction.
• Suivi : registre des décisions, échéances, statut des corrections et périmètre du retest.

Un rapport réduit à des captures d’écran et des scores ne suffit pas. Il doit dire, par exemple, si une faiblesse sur un compte de support permet de voir des factures clients, quel contrôle empêche aujourd’hui une exploitation plus large et quelle action ferme le chemin démontré. Les éléments sensibles du rapport doivent être diffusés à un cercle restreint.

Comment prioriser les corrections après le pentest ?

Le score CVSS décrit des caractéristiques d’une vulnérabilité, mais la priorité de votre entreprise dépend aussi du système touché, de son exposition, des privilèges nécessaires, des contrôles existants et de l’impact sur l’activité. FIRST précise que la spécification CVSS version 4 prévoit des métriques de menace et d’environnement pour contextualiser l’évaluation.^[4] Un score élevé n’est donc pas, à lui seul, une décision de calendrier.

Exemple de décision. Une faiblesse notée élevée sur un serveur de démonstration isolé peut passer après un accès moins sévèrement noté au portail de facturation exposé à des partenaires. Si ce dernier permet de consulter des données clients, la confidentialité et les obligations contractuelles peuvent justifier une action immédiate. Ce scénario illustre la méthode : il ne prétend ni chiffrer une perte ni décrire un incident réel.

Pour le portail de facturation, nommez le responsable du contrôle d’accès et conservez la preuve du test après correction. Si la correction doit attendre la prochaine version de l’application, restreignez provisoirement l’accès à la fonction concernée, indiquez qui vérifie cette mesure et fixez la date du retest. Décrivez l’effet possible sur les factures et la relation client sans inventer un coût d’incident.

Quand faut-il faire un retest ?

Le retest vérifie une correction sur les constats retenus ; il n’équivaut pas automatiquement à un nouveau pentest complet. Pour le portail client de notre exemple, il doit confirmer que le compte ordinaire ne peut plus ouvrir le dossier d’un autre client après le déploiement de la nouvelle version. La demande précise la fonction concernée, la version déployée et les environnements concernés.

Exemple. Après une correction du portail client, l’équipe peut montrer que le contrôle d’autorisation est appliqué à la fonction initialement touchée. Le retest doit également vérifier les variantes prévues dans le périmètre : un correctif local qui ferme seulement l’écran visible ne résout pas nécessairement le défaut partagé par une API. Le compte rendu nomme la version testée et les fonctions encore exclues.

Les modifications importantes du système après la mission — nouveau module, migration d’identité, ouverture à un partenaire — peuvent justifier un autre test ciblé. Un rapport ancien ne décrit pas indéfiniment l’état actuel d’une application qui évolue.

Comment choisir le prestataire et lire sa proposition ?

Comparez les propositions à périmètre et livrables égaux. Une qualification PASSI peut être pertinente selon les exigences applicables et le type de mission, mais elle ne dispense pas d’examiner les compétences réellement mobilisées. L’ANSSI distingue les tests d’intrusion des autres activités d’audit dans son référentiel de qualification.^[1]

• Demandez qui réalisera le test et sur quel type de systèmes cette personne a déjà travaillé, sans exiger de divulguer les données d’anciens clients.
• Faites écrire les hypothèses de départ : nombre d’applications, comptes fournis, environnements, exclusions et disponibilité des équipes.
• Vérifiez la méthode de signalement immédiat d’un risque critique et de protection des preuves sensibles.
• Exigez une restitution aux décideurs et aux équipes techniques, avec un plan de correction et des limites explicites.
• Demandez si le retest est inclus, optionnel ou exclu, et dans quel délai il pourra être réalisé.

Le service de tests de sécurité et de pentest Mobhitech détaille les modalités de prestation. Le rôle de cet article est différent : vous donner les questions à poser avant de commander et les décisions à prendre après le rapport. Une mission plus large de pilotage peut relever d’un RSSI externalisé lorsque plusieurs corrections doivent être coordonnées dans la durée.