Qu’est-ce qu’un test d’intrusion et quand une entreprise en a-t-elle besoin

Un scan, un audit et un test d’intrusion sont trois travaux distincts, à trois prix distincts. Lequel répond à votre question, et ce que le droit français exige réellement.

Vous demandez un devis pour la sécurité de votre site web et vous en recevez trois qui diffèrent d’un facteur dix ; l’un porte « scan de sécurité », le deuxième « audit de sécurité », le troisième « test d’intrusion », mais les trois portent le même mot « sécurité », qui ne dit rien de ce qui diffère vraiment. Ce n’est pas un même travail en trois niveaux, ni trois prix pour la même prestation ; ce sont trois travaux distincts, qui répondent à trois questions distinctes, si bien que la première étape n’est pas de comparer les prix, mais de comprendre à laquelle de ces trois questions vous voulez réellement une réponse.

Cet article répond à deux d’entre elles : ce qu’est un test d’intrusion, et s’il est nécessaire pour votre entreprise, concrètement. La seconde question est la plus importante, parce que pour la plupart des petites et moyennes entreprises aucun texte n’impose un test d’intrusion sous ce nom, et un devis qui passe cela sous silence vous vend la bonne prestation au mauvais moment.

Nous l’écrivons en vendant un audit de sécurité de site web, et il n’y a là aucune contradiction, parce qu’un audit qui laisse de la place à un contrôle manuel, et un test d’intrusion qu’un règlement exige, ne sont pas le même travail ; l’entreprise qui achète le second alors qu’il lui fallait le premier paie davantage et apprend moins.

Trois prestations vendues sous des noms voisins

La terminologie du métier est ici trouble, mais dessous il y a une frontière nette, qu’une autorité de normalisation nomme le mieux : NIST SP 800-115 définit le test d’intrusion comme un test de sécurité dans lequel des évaluateurs imitent de véritables attaques afin de trouver des chemins autour de la protection du système, et précise qu’il cherche des combinaisons de vulnérabilités, non des constats isolés. La même publication décrit le scan de vulnérabilités comme une technique qui identifie des ressources et les vulnérabilités connues qui leur correspondent.

En pratique, cela donne quatre travaux distincts, qu’il vaut la peine de nommer chacun à part. Le scan de vulnérabilités est automatique ; un outil compare votre système à une base de vulnérabilités connues et renvoie une liste. L’analyse de vulnérabilités est cette même liste, qu’une personne a vérifiée et classée, en général sans exploiter aucune des vulnérabilités trouvées. Le test d’intrusion est un travail conduit par un humain, dans lequel les faiblesses trouvées sont exploitées et reliées en chaîne, pour établir jusqu’où un attaquant va réellement. L’audit de conformité répond à une tout autre question : le système satisfait-il une norme ou un texte nommé.

La frontière entre les trois premiers est tracée le plus clairement par la norme des cartes de paiement, qui le fait non par une définition mais par un but : les lignes directrices du PCI Security Standards Council distinguent le test d’intrusion du scan par l’objectif : le scan identifie, classe et signale les vulnérabilités ; le test cherche des moyens de les exploiter pour contourner la protection du système. Le même conseil, dans sa norme, ajoute les deux bords : un scan à lui seul n’est pas un test d’intrusion, et un test qui se borne à tenter d’exploiter les constats du scanner n’est pas non plus suffisant.

C’est pourquoi la question « avez-vous besoin d’un test d’intrusion » n’est pas une question de budget, mais de ce à quoi vous voulez une réponse : votre système a-t-il des faiblesses connues, ou quelqu’un peut-il réellement en faire quelque chose.

Ce que chacun d’eux répond, et ce qu’il ne dit pas

Le scan répond vite et à bas coût, et sa faiblesse est le contexte, parce que l’outil ne sait pas laquelle des cent lignes signalées se trouve sur votre formulaire de paiement et laquelle est dans un environnement de test que personne n’atteint depuis Internet, et il ne sait pas non plus que deux erreurs séparément inoffensives donnent ensemble accès à la base de données : la liste est donc le début du travail, non son résultat.

Le test d’intrusion répond plus lentement et plus cher, et sa valeur est précisément dans la chaîne, parce que le testeur ne cherche pas « y a-t-il une vulnérabilité ici » mais « que puis-je en faire » : d’un formulaire public, peut-on arriver jusqu’aux droits d’administrateur ; du compte d’un client, peut-on voir les données d’un autre ; d’un environnement de test, peut-on atteindre la base de production. La réponse à cette question est celle qu’un dirigeant comprend sans traduction.

L’audit de conformité ne fait ni l’un ni l’autre, parce qu’il vérifie si le système satisfait une norme, et son résultat est un jugement de conformité, non une liste de faiblesses techniques ; c’est exactement pour cela qu’une entreprise peut réussir un audit de conformité et se faire pirater la même semaine, et il n’y a là aucune contradiction, parce que deux documents répondent à deux questions différentes.

Aucun de ces travaux ne remplace les autres et aucun n’est « meilleur » que les autres, si bien que la seule question qui ait un sens est de savoir lequel, en ce moment, répond à ce que vous avez réellement besoin de savoir.

La confusion des noms n’est pas seulement un problème français, et on le voit en comparant les marchés : en Finlande, en Suède et en Norvège, le marché vend deux prestations — le scan et le test d’intrusion — et la voie du milieu n’a pas de nom ; on la tient pour le résultat d’un scan, non pour un service à part. En Allemagne c’est l’inverse, parce qu’un même mot y recouvre souvent les trois travaux, y compris le test lui-même, et c’est précisément pour cela que, pour comparer des devis, le nom est le plus faible des repères possibles, tandis que la seule question sûre reste celle-ci : les vulnérabilités trouvées seront-elles exploitées.

La loi l’exige-t-elle de vous en particulier

Mieux vaut ici être précis, parce que c’est l’endroit où les devis exagèrent le plus souvent : en France, aucun texte actuellement en vigueur n’impose un test d’intrusion, sous ce nom, à toute entreprise qui a un site web.

La loi n° 2018-133 du 26 février 2018, qui transpose la directive 2016/1148 de l’Union européenne, fixe des obligations aux opérateurs de services essentiels : appliquer des règles de sécurité, notifier les incidents. Le test d’intrusion n’est nommé dans aucun article de la loi elle-même.

L’arrêté du 14 septembre 2018 fixant les règles de sécurité des opérateurs de services essentiels, en vigueur depuis le 1er octobre 2018, exige un audit de sécurité (architecture, configuration, organisation et mesures physiques) dans le cadre de l’homologation de chaque système d’information essentiel. La validité de l’homologation est réexaminée au moins tous les trois ans et lors de chaque événement de nature à modifier le contexte. Cela ne s’applique que si vous êtes un opérateur de services essentiels désigné et que le système concerné est un système d’information essentiel. La loi n° 2018-133 permet en outre de soumettre un opérateur désigné à un contrôle sur pièce et sur place.

Ce sont deux conditions ensemble, non une seule : une entreprise qui n’est pas un opérateur désigné ne tire de ce point aucune obligation, et un opérateur dont le système n’est pas un système d’information essentiel non plus, si bien que la première étape n’est pas de demander un devis, mais de savoir si vous êtes seulement concerné.

Comment savoir si vous êtes concerné

La loi n’énumère pas les entreprises par leur nom ; elle décrit des services essentiels et la gravité d’un incident, et la désignation d’un opérateur de services essentiels relève du Premier ministre. En pratique, deux questions aident à s’orienter : votre activité entre-t-elle dans l’un des services essentiels visés, et un incident affectant vos réseaux aurait-il des conséquences graves au sens du décret. C’est précisément pour cela que la première dépense, dans ce domaine, est en général un conseil juridique, non une prestation technique.

Si la réponse est « non », les points suivants sur les systèmes d’information essentiels ne vous concernent pas du tout, et si la réponse est « oui », vient la seconde question : à quel système l’exigence s’attache. L’audit exigé pour l’homologation est lié au système d’information essentiel, non au statut d’opérateur comme tel, et une entreprise peut être désignée sans qu’aucun de ses systèmes n’y soit soumis.

Il existe aussi un troisième chemin, qui ne suppose pas qu’un système soit un système d’information essentiel : l’ANSSI peut, dans un cas particulier, soumettre un opérateur désigné à un contrôle sur pièce et sur place, ou lui demander les informations dont elle a besoin pour évaluer la sécurité. Ce n’est pas une obligation que l’on planifie, mais une raison de savoir qui, de votre côté, répondrait à une telle demande.

Les autres seuils nomment des tests, pas un test d’intrusion

L’article 32 du règlement général sur la protection des données (RGPD) exige de tester, d’analyser et d’évaluer régulièrement l’efficacité des mesures de sécurité, et l’ampleur de l’exigence est liée au risque. Ce n’est pas la même chose qu’une obligation de commander un test d’intrusion une fois par an, et un devis qui présente l’article 32 comme telle reformule le règlement plus librement qu’il n’est écrit. L’obligation de prouver que des tests ont lieu est réelle ; l’obligation de choisir précisément cette forme de test ne découle pas de l’article 32.

La norme des cartes de paiement PCI DSS, en son exigence 11.4, nomme le test d’intrusion explicitement, tous les douze mois et après des changements importants, mais c’est une obligation contractuelle et elle porte sur la façon dont vous acceptez les cartes. Une boutique en ligne qui oriente entièrement les paiements vers un prestataire de services de paiement et ne traite pas elle-même les données de cartes, et tous les autres dont l’environnement voit transiter des données de cartes, répondent à cette exigence différemment. C’est une question à laquelle répond votre banque acquéreuse, non un article.

Dans le secteur financier, le règlement 2022/2554 exige des tests réguliers, et il ne prévoit des tests de pénétration fondés sur la menace (TLPT) que pour les établissements que le superviseur a particulièrement désignés. La norme ISO/IEC 27001 exige une gestion des vulnérabilités et des tests de sécurité, sans nommer le test d’intrusion ; l’affirmation selon laquelle, sans lui, la certification est refusée, est répandue et ne se trouve pas dans la norme.

Si aucun de ces seuils ne vous concerne, vous n’avez pas d’obligation réglementaire de commander un test d’intrusion, et cela ne signifie pas qu’il n’y a rien à faire, mais que le travail à faire est autre.

Si aucun seuil n’est franchi

Pour une entreprise qui n’est pas un opérateur désigné, ne traite pas de données de cartes et n’exerce pas dans le secteur financier, le travail qui a du sens est en général celui qui a lieu régulièrement, non une fois tous les trois ans. Ce sont des mises à jour qui ont un responsable et une échéance ; des sauvegardes que quelqu’un a déjà restaurées une fois, en s’assurant qu’elles se restaurent vraiment ; l’authentification multifacteur (MFA) pour les comptes d’administration, que l’ANSSI recommande et qui est tout aussi utile aux autres ; et un scan régulier dont quelqu’un lit réellement les résultats.

Ce n’est pas une réponse au rabais, mais une autre sorte de travail. La plupart des piratages sur lesquels nous intervenons ne commencent pas par une attaque raffinée, mais par un composant non mis à jour ou par un mot de passe qui valait aussi ailleurs, et un test d’intrusion qui a lieu une fois tous les trois ans n’en protège pas. Si votre site a déjà été atteint, la séquence est autre, et un article distinct décrit comment récupérer un site piraté.

Le test d’intrusion devient justifié lorsqu’il y a quelque chose à perdre, et lorsque l’ampleur de la perte dépasse le prix du test : un système qui porte les données d’autres personnes, une intégration qui touche à l’argent, ou un donneur d’ordre qui exige une preuve. Jusque-là, c’est le bon travail dans le mauvais ordre.

Ce qui se passe pendant le test

Le travail commence par la définition du périmètre et s’achève par un rapport, et entre les deux il y a trois étapes qu’il vaut mieux comprendre avant de comparer des devis, parce que ce sont précisément elles qui expliquent pourquoi un test coûte ce qu’il coûte, et pourquoi un autre, pour le même système, coûte dix fois moins.

La première étape est la reconnaissance, dans laquelle le testeur rassemble tout ce que l’on peut apprendre du système depuis l’extérieur : quelles adresses sont publiques, quelles technologies et versions sont visibles, où sont les formulaires de connexion, quels fichiers sont accessibles sans autorisation. Rien n’est encore exploité à ce stade, mais c’est précisément ici que se trouvent le plus souvent les constats que personne n’attendait : un environnement de test oublié, un listing de répertoires ouvert, une sauvegarde qui se trouve à une adresse prévisible.

La deuxième étape est le test lui-même, dans laquelle on lance les outils automatiques pour ne pas manquer le connu, mais les décisions sont prises par une personne qui vérifie si un constat est réel, tente de l’exploiter et regarde ce qu’elle en gagne. C’est ici que naît la chaîne : l’accès à un compte, de là l’accès à une fonction qui n’aurait pas dû être joignable, de là l’accès aux données. Séparément, aucune des étapes n’est dramatique ; ensemble, elles font un récit.

La troisième étape est de prouver et d’écrire, parce que chaque constat doit laisser une preuve que l’on peut répéter : quelle requête a été envoyée, quelle a été la réponse, ce qui a changé. Sans cela le rapport est un avis, et le développeur qui le reçoit passe une journée à tenter de comprendre ce que le testeur a réellement vu.

C’est aussi pourquoi les délais sont ce qu’ils sont : le test d’un petit site prend quelques jours, mais un système à plusieurs rôles, intégrations et paiements prend des semaines, et un devis qui promet un test d’intrusion complet en une journée décrit non un test, mais un scan.

Pourquoi les devis diffèrent d’un facteur dix

Quand deux devis pour le même site diffèrent d’un facteur dix, l’écart n’est presque jamais dans la marge, et il est presque toujours dans le périmètre et la méthode : l’un propose un scan automatique avec un outil qu’on lance en une heure et dont le même outil génère le rapport, l’autre propose une semaine de travail humain dans laquelle les outils ne sont qu’un début, et c’est précisément cet écart que le nom « contrôle de sécurité » dissimule dans les deux cas.

Le deuxième facteur de prix est la complexité du système, et on peut l’évaluer avant que la conversation commence : un site public sans comptes utilisateurs est un travail, mais un système à plusieurs rôles, des paiements, une intégration externe et des données qui appartiennent à des clients en est un tout autre, parce que chaque rôle est une frontière distincte à tester et chaque intégration un endroit où deux systèmes se font plus confiance qu’il ne faudrait.

Le troisième est ce que vous recevez après le test et combien de temps le prestataire reste présent : un rapport sans priorités, sans preuves et sans contre-test coûte moins parce que c’est moins de travail, et pour l’entreprise qui doit ensuite corriger les constats, ce sont précisément ces trois choses qui décident si le document devient une liste de tâches ou un dossier que plus personne n’ouvre.

Comparer des devis sur le prix n’est donc possible que lorsque le périmètre a été écrit de la même façon, et le moyen le plus simple d’y parvenir est d’écrire le périmètre vous-mêmes et de demander à tous de chiffrer là-dessus, plutôt que de laisser chaque prestataire définir le sien.

Quand un test devient caduc

Le résultat d’un test d’intrusion décrit un système précis à une date précise, ce qui est évident, et c’est pourtant précisément ici que naît l’essentiel des malentendus entre prestataire et client, parce qu’un rapport vieux d’un an décrit un code qui, depuis, a changé des dizaines de fois.

Les délais écrits le reconnaissent eux-mêmes : dans l’arrêté, à côté de l’intervalle de trois ans, se trouve l’exigence d’auditer au moment de l’homologation, et dans la norme des cartes de paiement, à côté de l’intervalle annuel, se trouve « après des changements importants », si bien que dans les deux cas le calendrier n’est qu’un minimum, et la vraie raison de tester est un changement.

En pratique, cela signifie qu’une nouvelle raison de tester est un changement qui modifie la surface d’attaque : une nouvelle fonction publique, une nouvelle intégration avec un système externe, un changement d’authentification, un passage à un autre hébergement, un nouveau rôle utilisateur aux droits plus larges. Un changement de couleurs ou une correction de texte ne devient pas une telle raison, si visible soit-il.

L’autre raison, c’est que c’est l’entourage qui a changé, non votre code : une vulnérabilité dans un framework que vous utilisez est divulguée après le test, et un test qui ne la mentionnait pas ne s’est pas trompé, parce qu’à ce moment-là elle n’existait pas encore. C’est pourquoi le scan régulier et le processus de mises à jour sont ce qui a lieu entre les tests, et le test ne les remplace pas.

Sans l’autorisation du propriétaire, les mêmes actes sont illicites

Un test d’intrusion ne se distingue pas techniquement d’une attaque, et la seule chose qui les sépare est un document : l’autorisation du propriétaire, dans laquelle sont nommés le périmètre, le temps et les limites, et qu’il vaut mieux formaliser par écrit même lorsque la loi n’exige pas cette forme. Sans elle, les mêmes actes sont les mêmes actes, et cela a des conséquences pénales : en France, l’accès ou le maintien frauduleux dans un système de traitement automatisé de données est puni par l’article 323-1 du code pénal.

Concrètement, cela signifie que l’autorisation est donnée par celui à qui le système appartient, non par celui qui l’entretient. Si votre site tourne chez un hébergeur, le prestataire d’hébergement doit aussi savoir que le test aura lieu, faute de quoi ses défenses l’arrêteront ou bloqueront votre compte. Si le système contient un composant tiers que vous ne contrôlez pas, il n’entre pas dans le périmètre.

Les limites du périmètre s’écrivent avant, non après, et cette liste comprend quelles adresses sont dans le périmètre et lesquelles n’y sont pas, si l’on teste l’environnement de production ou une copie, ce qui se passe si le test interrompt le service, et qui, de votre côté, est joignable la nuit ; cette conversation prend une heure et règle la plupart des différends qui, autrement, naissent au milieu du test.

Ce qu’un test n’est pas : équipe rouge, bug bounty et contrôle de conformité

À côté du test d’intrusion existent plusieurs travaux que l’on tend à appeler de même, et les différences entre eux ne sont pas académiques, mais pratiques : elles décident ce que vous commandez et ce que vous recevez.

L’exercice d’équipe rouge ne vérifie pas le système, mais la défense : vos personnes et vos processus voient-ils l’attaque, et que font-ils. Le périmètre est plus large, la durée plus longue, et une part de la valeur est précisément que ceux qui défendent ne savent pas qu’un exercice a lieu. Pour une entreprise qui n’a rien à remarquer, parce que personne ne lit les journaux, ce travail est prématuré.

Le bug bounty est un modèle, non un test : vous publiez des règles et vous payez les constats à ceux qui les envoient. Cela peut trouver ce qu’un seul testeur a manqué, mais cela ne donne ni garantie de périmètre, ni délai, ni rapport que l’on puisse joindre à un dossier d’appel d’offres.

Les tests de pénétration fondés sur la menace (TLPT) sont un travail distinct, réglementé, dans le secteur financier, et ils sont définis par un règlement de l’Union européenne. Si votre entreprise n’est pas un établissement financier désigné par le superviseur, ce terme n’a pas sa place dans votre devis.

Une autre frontière que l’on tend à effacer est celle entre « boîte noire », « boîte blanche » et « boîte grise » : combien le testeur sait déjà du système au départ. C’est une convention du métier, non une exigence réglementaire, et elle a un effet direct sur le prix et sur ce que le test trouvera. Un testeur sans accès imite un inconnu ; un testeur muni d’un compte et de la documentation va plus loin dans le même temps. Aucune des variantes n’est la plus correcte ; la question est de savoir de quoi vous avez peur.

Ce que vous recevez et comment le lire

Le résultat d’un test est un rapport, et sa valeur est dans les priorités, non dans le nombre de constats, parce qu’un rapport de cent lignes qui ne dit pas par laquelle commencer est exactement aussi inutilisable qu’une sortie de scanner. Un bon rapport dit, pour chaque constat, ce qu’un attaquant peut en faire, avec quelle facilité, et quoi changer concrètement.

La deuxième chose à demander est un contrôle après les correctifs, parce qu’un constat qui a été corrigé, et un constat dont quelqu’un croit qu’il a été corrigé, diffèrent l’un de l’autre, et le seul moyen de le savoir est de vérifier encore. Nous le faisons dans les trente jours après les correctifs, et ce délai mérite d’être exigé de tout prestataire.

Le troisième est ce que votre développeur fera du rapport. Un constat décrit par un numéro CVE et sans contexte, pour le développeur, signifie une recherche ; un constat auquel sont joints la requête précise et l’endroit dans le code signifie un correctif. Si un prestataire fait le développement et un autre le test, c’est cet écart qui décide si les correctifs seront faits en une semaine ou en un trimestre.

Le quatrième est ce qui ne doit pas figurer dans le rapport : l’affirmation que le système est désormais sûr. Un test montre ce que, dans le périmètre convenu à la date convenue, on a réussi à faire. Il ne prouve pas qu’il n’y a rien d’autre, et un prestataire qui le promet vous vend un réconfort.

Il y a encore une raison de commencer cette conversation plus tôt qu’il ne paraît nécessaire : un test qui a lieu une semaine avant la mise en production trouve la même chose qu’il aurait trouvée trois mois plus tôt, mais il ne reste plus ni le temps ni le budget pour corriger les constats, et dans la pratique cela s’achève par une liste qu’on accepte comme un risque, non par des correctifs, c’est pourquoi tester avant la mise en production vaut la peine pour cette raison, y compris pour ceux qu’aucun texte ne lie.

Et le dernier point qu’il faut dire nettement : un test d’intrusion n’est pas l’attestation que le système est sûr, mais l’attestation que, à une date précise, dans un périmètre précis, une compétence connue n’a pas trouvé de chemin au-delà de quelque chose de précis, et c’est pourquoi la partie la plus précieuse du rapport est souvent non la liste des constats, mais la description de ce qui a été tenté et n’a pas abouti, parce que c’est précisément cette partie qui dit au prochain testeur, dans trois ans, où il n’est pas utile de repartir de zéro.

Ce qu’il faut préparer avant la conversation

Pour qu’un devis soit seulement comparable, le prestataire doit connaître le périmètre : préparez donc une liste des adresses et des systèmes qui y entrent, indiquez si l’on teste l’environnement de production ou une copie, dites ce qui, dans le système, ne doit pas être touché, et nommez une personne qui peut autoriser l’arrêt du test.

Environnement de production ou copie

C’est la question qui tranche à la fois le prix et le risque, parce qu’un test en production montre ce qui est réellement joignable, et c’est précisément pour cela qu’il peut casser quelque chose : saturer, remplir la base de données d’enregistrements de test, envoyer aux clients de vrais courriels, ou rester coincé dans un système de défense qui bloque le testeur puis bloque aussi une partie de vos utilisateurs.

Un test sur une copie est plus sûr et en même temps moins complet, parce qu’une copie est rarement identique : il y manque souvent les intégrations réelles, le volume réel de données et la configuration réelle, et c’est souvent dans la configuration que se trouve le problème. Si vous choisissez une copie, consignez en quoi elle diffère de la production, parce que cette liste est aussi la liste de ce que le test n’a pas vérifié.

La voie du milieu, que nous employons le plus souvent : les opérations de lecture en production, l’écriture et ce qui peut détruire, sur une copie, avec une fenêtre convenue à l’avance et une personne qui peut arrêter. Ce n’est pas un compromis pour le prix, mais une façon d’obtenir les réponses des deux variantes sans interrompre l’activité.

La liste inverse est également utile, à savoir ce qui n’est pas dans le périmètre, parce que les limites admises en silence sont celles dont on se dispute ensuite. Les services de tiers que vous n’entretenez pas n’y entrent pas, et les tester sans l’autorisation de ces tiers est le même problème que la section précédente. Si votre site utilise une fenêtre de paiement externe, une fenêtre de conversation externe ou une analytique externe, ce sont les biens d’autrui, et un devis qui promet de « les vérifier aussi » promet ce qu’il n’a pas le droit de faire.

Dites enfin ce qu’il adviendra des constats ensuite : qui les corrigera, dans quel délai, et si le prestataire vérifiera encore après les correctifs. Un test sans cet accord s’achève souvent par un document que personne n’ouvre, et c’est la version la plus chère possible : on a payé un savoir dont on ne se sert pas.

Dites aussi à quelle réponse vous cherchez, parce que « nous devons satisfaire une exigence » et « nous voulons savoir si quelqu’un peut atteindre les données des clients » sont deux travaux distincts, à deux prix distincts, et un prestataire qui ne demande pas lequel est le vôtre proposera celui qui l’arrange.

Si vous n’êtes pas sûr de quel côté du seuil vous vous trouvez, mieux vaut commencer par là. L’audit automatique répond en général à la question des faiblesses connues à moindre coût et plus vite qu’un travail manuel d’expert, et son résultat dit aussi si un test d’intrusion est l’étape suivante. Une conversation sur le périmètre mérite d’être commencée par la description du processus, non par une liste de technologies, parce que le périmètre est fixé par ce que vous perdez si le système fait défaut.