Comment structurer vos tests d'intrusion ?

Un test d'intrusion, dans la pratique le plus souvent appelé pentest, est une attaque contrôlée contre vos propres systèmes visant à trouver les vulnérabilités avant qu'un véritable attaquant ne le fasse. Un pentest isolé produit un rapport, mais seule une approche structurée apporte une réelle valeur. Dans cet article, vous découvrirez pourquoi vous testez, comment mettre en place une politique de pentest et un calendrier de pentest, ce qui doit figurer dans un bon rapport de pentest et ce que vous faites ensuite des constats.

En bref

• Un pentest reproduit une véritable attaque et montre quelles vulnérabilités sont réellement exploitables dans votre contexte.
• Une politique de pentest précise ce que vous testez, à quelle fréquence, par qui et dans quelles conditions.
• Un calendrier de pentest planifie les tests à l'avance et les relie aux changements et aux nouveaux systèmes.
• Un rapport de pentest n'est utile que lorsque vous donnez suite aux constats, que vous les corrigez et que vous les faites revérifier.
• Vous rendez l'ensemble démontrable en gérant les constats dans un registre relié à votre ISMS.
• Le processus de pentest coïncide avec les quatre phases du modèle Kantyra : détecter, évaluer, résoudre et démontrer.

Qu'est-ce qu'un pentest ?

Un pentest est une tentative autorisée et contrôlée de pénétrer dans vos systèmes, menée par une personne compétente qui pense et agit comme un attaquant. L'objectif n'est pas de causer des dégâts, mais de montrer où vous êtes vulnérable et quelles seraient les conséquences si quelqu'un exploitait cette faiblesse.

La différence avec un scan de vulnérabilités est importante. Un scan est automatisé et trouve les vulnérabilités connues, mais dit peu de chose sur l'impact réel. Un pentest va plus loin. Un testeur combine des faiblesses isolées en une véritable chaîne d'attaque et montre jusqu'où quelqu'un peut aller. Ainsi, vous savez non seulement qu'une vulnérabilité existe, mais aussi ce qu'un attaquant pourrait en faire dans votre environnement.

Pourquoi réaliser des pentests ?

Réaliser des pentests est judicieux pour plusieurs raisons, et parfois même nécessaire.

La principale raison est que vous trouvez les vulnérabilités avant les attaquants. Vous obtenez une vision de faiblesses réelles et exploitables plutôt qu'une liste théorique, et vous pouvez les corriger au moment que vous choisissez vous-même.

Vient ensuite la démontrabilité. La norme ISO 27001 exige que vous maîtrisiez les vulnérabilités techniques et que vous testiez périodiquement vos mesures, et un pentest est la manière courante de le faire. Le devoir de vigilance issu de NIS2 exige lui aussi des mesures appropriées, que vous devez pouvoir justifier. De plus, clients et donneurs d'ordre demandent de plus en plus un rapport de test récent avant de travailler avec vous.

Enfin, un pentest donne à votre direction et à votre équipe de sécurité une image réaliste. Une intrusion réussie dans un environnement de test rend tangible ce qu'une liste de risques ne transmet jamais.

Types de pentests et périmètre

Tous les pentests ne se ressemblent pas. Avant de tester, vous déterminez le périmètre, c'est-à-dire ce qui est examiné précisément et avec quel niveau de connaissance préalable.

En matière de connaissance préalable, il existe trois variantes. Lors d'un test sans connaissance préalable (boîte noire), le testeur part de rien, comme un intervenant extérieur. Lors d'un test avec connaissance préalable complète (boîte blanche), le testeur reçoit de la documentation et des accès, ce qui lui permet de creuser plus profondément. Un test avec connaissance préalable partielle (boîte grise) se situe entre les deux et est le plus courant dans la pratique.

Quant à l'objet, vous pouvez faire tester des éléments très variés, comme une application web, votre réseau externe ou interne, une application mobile, un environnement cloud ou la tromperie des collaborateurs. Cette dernière forme, tester si les collaborateurs sont sensibles à la tromperie, touche à votre sensibilisation et à votre culture de sécurité.

Le choix dépend de ce que vous voulez savoir et de vos risques. Un bon testeur vous conseille sur ce point, mais la responsabilité finale du périmètre vous incombe.

La politique de pentest

Une politique de pentest transforme des tests isolés en une approche cohérente. C'est le cadre dans lequel vous consignez la manière dont votre organisation aborde les pentests. Une bonne politique de pentest décrit au moins les points suivants :

• l'objectif des pentests et le périmètre, autrement dit quels systèmes et services vous testez ;
• la fréquence et les événements qui déclenchent un test ;
• les types de tests que vous utilisez et la manière dont vous déterminez le périmètre pour chaque test ;
• les exigences envers la partie chargée de l'exécution, comme l'indépendance et une compétence démontrable ;
• les accords relatifs à l'autorisation et à la décharge juridique, afin que le test soit licite ;
• le traitement des données que le testeur rencontre, et la confidentialité du rapport ;
• les exigences en matière de rapport, de suivi et de revérification.

Ce dernier point est crucial. Sans accords sur le suivi, un pentest reste un instantané sans suite.

Le calendrier de pentest

Là où la politique constitue le cadre, le calendrier de pentest planifie concrètement les tests. Le calendrier évite que les pentests se déroulent de manière ponctuelle et garantit que vos systèmes critiques soient testés à une régularité fixe.

Dans le calendrier, vous consignez quel système est testé, quand et par qui. En général, vous testez vos systèmes critiques au moins une fois par an, et vous testez en outre à des moments fixes, par exemple avant qu'une nouvelle application ne passe en production, après une modification importante ou lors d'une grande nouvelle version. Ainsi, vous reliez le calendrier à votre gestion des changements et à votre planification des nouvelles versions, et vous testez aux moments où le risque évolue.

Un calendrier aide aussi à planifier votre budget et la disponibilité d'une partie adaptée, car les bons testeurs ne sont pas toujours disponibles à court terme.

Comment se déroule un pentest ?

Un pentest passe généralement par un nombre fixe de phases. Si vous savez à quoi elles ressemblent, vous pouvez mieux accompagner un test.

1. Délimitation. Vous déterminez avec le testeur le périmètre, les objectifs et les règles du jeu.
2. Reconnaissance. Le testeur recueille des informations sur les systèmes cibles et cherche d'éventuels points d'entrée.
3. Exploitation. Le testeur tente réellement d'abuser des faiblesses trouvées et de pénétrer plus avant.
4. Rapport. Le testeur consigne les constats, avec les preuves, l'impact et les recommandations.
5. Revérification. Après la correction, le testeur vérifie si les vulnérabilités ont réellement été résolues.

La revérification est souvent oubliée, alors que c'est elle qui vous donne la certitude qu'un problème est réellement résolu.

Le rapport de pentest

Le rapport de pentest est le résultat tangible, mais sa qualité détermine ce que vous en tirez. Un bon rapport contient les éléments suivants :

• une synthèse de gestion compréhensible sans connaissances techniques ;
• une description du périmètre et de l'approche suivie ;
• les constats, chacun assorti d'une classification du risque, par exemple basée sur le CVSS ;
• pour chaque constat, la preuve et les étapes permettant de le reproduire ;
• l'impact de chaque constat en langage clair ;
• une recommandation concrète par constat et une priorisation pour la correction.

Un rapport qui se contente de fournir une liste de vulnérabilités, sans impact ni priorisation, vous oblige à faire vous-même le vrai travail. Demandez donc ces éléments au préalable, afin de pouvoir utiliser le rapport immédiatement.

Ce que vous faites des résultats

C'est ici que se situe l'étape qui fait la différence entre cocher une case et devenir réellement plus sûr. Un rapport n'a de valeur que lorsque vous donnez suite aux constats.

Pour chaque constat, vous désignez un responsable et fixez un délai de correction en fonction de la gravité. Un constat critique se traite immédiatement, un constat léger peut attendre un moment opportun. Après la correction, vous faites réaliser une revérification pour confirmer que le problème a réellement disparu. Vous escaladez les constats les plus graves vers votre registre des risques, afin qu'ils restent visibles au niveau de la direction jusqu'à leur résolution.

Du rapport isolé à une gestion cohérente

Vous pouvez conserver les rapports de pentest dans un dossier, mais vous perdez alors la vue d'ensemble dès que vous faites réaliser plus de quelques tests par an. La base d'une approche mature est donc un registre des constats, autrement dit un aperçu à jour de chaque constat, avec sa gravité, son responsable, son délai de correction, son statut et sa date de revérification.

Dans Kantyra, vous enregistrez chaque constat d'un pentest avec la source « pentest », ou vous importez l'ensemble du rapport en une fois depuis Excel, avec le rapport lui-même joint comme preuve. À partir de ce registre, les liens se tissent vers le reste de votre dispositif de maîtrise. Vous reliez un constat aux actifs concernés et aux risques qu'il touche, et pour un constat de gravité élevée ou critique, Kantyra crée automatiquement une tâche de réévaluation pour le risque lié, tout comme pour un incident. Ainsi, une vulnérabilité grave s'escalade d'elle-même vers votre registre des risques, au lieu de rester dans un rapport. L'action de correction, vous la consignez sur le constat lui-même, avec un responsable et un délai, et après la correction, vous planifiez la revérification avec sa propre date : lorsque celle-ci approche, la revérification se présente automatiquement comme une tâche, de sorte que l'étape la plus souvent oubliée n'est plus sautée. Les mesures de sécurité qui découlent d'un test, vous les gérez comme des mesures. Ainsi, le pentest se raccorde directement à votre sécurité de l'information et gestion des risques (ISMS) conformément à l'ISO 27001.

Où se situe le pentest dans le modèle Kantyra ?

De tous les sujets de cette série, le pentest commence le plus clairement en bas du modèle, à la détection. Un pentest est en effet avant tout un signal : il met en lumière ce qui peut réellement mal tourner.

Tout commence par détecter : le test trouve les vulnérabilités, et vous enregistrez chaque constat avec la source « pentest ». Vient ensuite évaluer : vous pesez chaque constat selon sa gravité, et vous escaladez les plus graves vers le registre des risques. Dans la phase résoudre, vous planifiez la démarche avec la politique de pentest et le calendrier, vous corrigez selon la gravité avec un responsable et un délai, et vous faites réaliser une revérification ; la date de revérification est alors surveillée. Et dans la phase démontrer, le registre des constats, la preuve de la revérification et le rapport forment ensemble le dossier pour l'auditeur et le client.

C'est précisément pour cela qu'un rapport de pentest est si souvent un document mort : de nombreuses organisations restent bloquées à la détection et ne laissent jamais le signal parcourir le cycle. Un pentest n'apporte de la valeur que lorsque le constat se répercute vers un risque, une action de correction et, à terme, la preuve que le problème a réellement disparu. Le modèle impose ce parcours, de sorte que le test n'est pas un point d'arrivée, mais un point de départ.

Travaillez-vous avec des documents isolés ou avec une plateforme GRC ?

Vous pouvez tenir votre politique de pentest, votre calendrier et vos constats dans des fichiers isolés, et pour commencer, c'est défendable. Mais à mesure que vous testez davantage et que l'autorité ou votre client réclame de la démontrabilité, vous vous heurtez aux mêmes limites que pour tout autre effort de conformité. Les fichiers isolés se désynchronisent, et il vous manque la vue d'ensemble et l'historique dont vous avez besoin.

Dans une plateforme GRC, vous gérez la politique de pentest, la planification et le registre des constats au sein d'un seul environnement. Chaque constat a un responsable, un statut, un délai de correction et une date de revérification, et le lien avec votre registre des risques et vos tâches empêche qu'un risque ouvert ne disparaisse de la vue.

Avec Kantyra, vous gérez votre processus de pentest dans le même environnement que votre ISMS. Vous consignez la politique de pentest comme un document de politique avec gestion des versions et approbation, vous planifiez le test récurrent comme un test d'efficacité sur la mesure concernée (la date de test planifiée, avec un rappel automatique, constitue votre calendrier), et vous traitez le rapport dans le registre des constats. Que vous considériez le pentest comme une activité autonome ou comme un élément de votre sécurité plus large, vos constats, vos risques et vos actions de correction se rejoignent en un seul endroit, conformément à l'ISO 27001. Ainsi, vous rendez votre processus de pentest tout aussi démontrable que le reste de votre sécurité.

Se lancer dans les pentests en cinq étapes

1. Établissez une politique de pentest. Consignez ce que vous testez, à quelle fréquence, par qui et dans quelles conditions.
2. Déterminez le périmètre et choisissez une partie. Choisissez un testeur indépendant et à la compétence démontrable, et déterminez ce qui est testé.
3. Planifiez les tests dans un calendrier. Reliez les tests à vos systèmes critiques, à vos changements et à vos nouvelles versions.
4. Faites réaliser le test. Recevez un rapport avec impact, priorisation et recommandations concrètes.
5. Donnez suite aux constats. Corrigez selon la gravité, faites réaliser des revérifications et gérez le tout dans un registre des constats.

Questions fréquentes sur les pentests

Quelle est la différence entre un pentest et un scan de vulnérabilités ? Un scan est automatisé et trouve les vulnérabilités connues. Un pentest va plus loin et montre si ces vulnérabilités sont réellement exploitables dans votre contexte et quel en est l'impact. Un scan est large et rapide, un pentest est profond et ciblé.

À quelle fréquence faut-il réaliser des pentests ? Pour les systèmes critiques, au moins une fois par an est courant. Vous testez en outre à des moments fixes, par exemple avant qu'une nouvelle application ne passe en production ou après une modification importante. La bonne fréquence dépend de vos risques.

Êtes-vous obligé de réaliser des pentests ? La loi ne prescrit pas littéralement un pentest, mais l'ISO 27001 et le devoir de vigilance issu de NIS2 exigent que vous testiez vos mesures et que vous maîtrisiez les vulnérabilités techniques. Un pentest est la manière courante de le faire, et les clients le rendent souvent obligatoire par contrat.

Qui peut réaliser un pentest ? Une équipe interne peut tester, mais une partie externe indépendante donne une image plus objective et plus de valeur vis-à-vis des clients et des autorités. Dans tous les cas, une autorisation claire et des accords préalables sont indispensables.

Que faites-vous des constats ? Vous désignez un responsable par constat, vous corrigez dans un délai fondé sur la gravité, et vous faites réaliser des revérifications. Vous escaladez les constats les plus graves vers votre registre des risques, et vous consignez le tout dans un registre des constats.

Se lancer dans les pentests avec Kantyra

Vous préférez ne pas gérer votre processus de pentest dans des fichiers isolés, mais dans un seul environnement relié à votre sécurité de l'information ? Avec Kantyra, vous consignez votre politique de pentest comme un document de politique, vous planifiez le test récurrent comme un test d'efficacité sur la mesure concernée et vous traitez le rapport dans le registre des constats, relié à vos risques et à vos tâches, conformément à l'ISO 27001. Ainsi, vous rendez votre processus de pentest démontrable et clair, et aucun constat ne disparaît de la vue. Demandez une démo et découvrez comment bâtir les pentests par-dessus votre ISMS existant.

Kantyra est une plateforme ISMS et GRC qui permet aux organisations de gérer de manière démontrable leur sécurité de l'information, leur gestion des risques et leur conformité, conformément à des normes telles qu'ISO 27001 et ISO 22301 et à des réglementations telles que le RGPD, NIS2 et le règlement sur l'IA.