Corriger les constats d’un test d’intrusion avant une vente à une grande entreprise : guide pour les entreprises SaaS canadiennes

Corriger les constats d’un test d’intrusion est souvent la dernière étape entre une entreprise de logiciels et un contrat signé avec une grande entreprise. L’équipe de sécurité du client demande un test d’intrusion récent, lit les constats et met la transaction en attente jusqu’à ce que vous montriez qu’ils sont corrigés. Pour les entreprises SaaS canadiennes qui vendent à des banques, des hôpitaux, des universités, des gouvernements et de grandes entreprises américaines, c’est maintenant une étape normale du cycle de vente. Voici comment y répondre rapidement et honnêtement, et ce qu’il faut demander à votre équipe ou à votre firme de développement.

Ce que le client veut vraiment voir

La plupart des responsables de la sécurité ne s’attendent pas à un rapport parfait. Toute application réelle a des constats. Ce qu’ils veulent, c’est la preuve que vous les prenez au sérieux :

1. Les constats critiques et élevés corrigés, et confirmés par un nouveau test.
2. Un plan écrit, avec des dates, pour les constats moyens.
3. Une décision claire sur les constats faibles et informatifs : les corriger, ou accepter le risque et expliquer pourquoi.
4. Des réponses à leur questionnaire de sécurité qui concordent avec le rapport.

Vérifiez que le test couvrait bien le produit que le client achète et qu’il date de moins d’un an. Beaucoup de responsables refuseront un rapport ancien ou trop limité, si propre soit-il. Les clients acceptent souvent un résumé ou une lettre de la firme de test au lieu du rapport complet, qui peut rester sous entente de confidentialité. Demandez ce dont ils ont besoin avant d’envoyer quoi que ce soit.

Certains clients ont leurs propres règles derrière ces demandes. Les banques et les autres institutions financières sous réglementation fédérale au Canada suivent la ligne directrice B-10 du BSIF, qui leur demande de gérer les risques liés à leurs fournisseurs, et la ligne directrice B-13 sur les risques liés à la technologie et au cyberespace. Elles examineront donc de près la façon dont leurs fournisseurs trouvent et corrigent les problèmes de sécurité. Leur contrat peut aussi fixer des délais de correction selon la gravité. Lisez les clauses de sécurité avant de promettre des dates.

Lire le rapport comme un ingénieur, pas comme une liste à cocher

Un rapport de test d’intrusion présente ce que le testeur a trouvé dans le temps dont il disposait. Avant que quiconque commence à corriger, examinez-le avec soin :

1. Vérifiez que chaque constat est réel. Les testeurs signalent parfois de faux positifs, ou des problèmes qu’un autre contrôle bloque déjà. Si vous en contestez un, expliquez pourquoi par écrit et demandez au testeur de le confirmer.
2. Regardez au-delà de la cote de gravité pour planifier le travail. Un constat moyen sur une page qui contient des données de clients peut compter davantage qu’un constat élevé sur une page d’administration interne. Ne modifiez toutefois pas vous-même les cotes du testeur. Si vous pensez que l’une d’elles est erronée, demandez au testeur de la réviser par écrit, parce que le client se fiera aux cotes du testeur.
3. Regroupez les constats par cause. Cinq constats sur des utilisateurs qui accèdent à des données qu’ils ne devraient pas voir viennent souvent d’un seul contrôle manquant dans la gestion des autorisations de l’application.
4. Supposez que le testeur n’a vu qu’un échantillon. Si un point d’accès omet une vérification d’autorisation, d’autres le font probablement aussi.

Corriger la cause, pas seulement le constat

L’erreur la plus courante est de corriger exactement l’adresse indiquée dans le rapport et rien d’autre. Le nouveau test marque alors ce seul élément comme corrigé, alors que la même faille se trouve encore sur vingt autres points d’accès. Une bonne correction va à la source :

1. Le contrôle d’accès défaillant, qui arrive en tête du Top 10 de l’OWASP, se corrige le mieux avec une seule vérification d’autorisation centrale par laquelle passe chaque requête, et non avec un correctif sur chaque page.
2. Les failles d’injection se corrigent en utilisant partout des requêtes paramétrées et des moteurs de gabarits sûrs, et non en filtrant une seule entrée.
3. Les bibliothèques désuètes ou vulnérables se corrigent en les mettant à niveau, puis en ajoutant des vérifications automatiques des dépendances à la compilation, pour que le problème ne revienne pas.
4. Les secrets exposés, comme des clés dans le code ou les journaux, exigent de changer le secret et de vérifier si quelqu’un l’a utilisé, et pas seulement de supprimer la ligne.
5. Les en-têtes de sécurité manquants, les paramètres de session faibles et les messages d’erreur trop détaillés se règlent habituellement par une configuration rapide. Faites-les tôt parce qu’ils coûtent peu, mais ne les laissez jamais retarder les éléments critiques et élevés.

Ajoutez un test automatisé pour chaque correction importante, afin qu’une modification future ne puisse pas l’annuler sans qu’on s’en aperçoive.

Obtenir le nouveau test et conserver les preuves

Déployez les corrections en production, ou dans l’environnement qui a été testé, puis demandez à la firme de test initiale de tester de nouveau les constats corrigés. La plupart des firmes offrent ce service, parfois inclus dans le prix initial. Le résultat est habituellement un rapport mis à jour ou une lettre qui indique, pour chaque constat, s’il est corrigé, partiellement corrigé ou toujours ouvert. Ce document, produit par un testeur indépendant, est celui auquel l’équipe de sécurité du client fait confiance. Ne modifiez jamais vous-même le rapport du testeur.

Tenez aussi votre propre registre : le constat, la cause, la correction, la modification du code, le test qui le prouve et la date. Le prochain questionnaire, votre auditeur SOC 2 et vos futurs clients demanderont les mêmes preuves.

Répondre honnêtement au questionnaire

Lorsqu’un questionnaire de sécurité accompagne la demande de test d’intrusion, les deux doivent concorder. Si le rapport montre une faiblesse dans la gestion des sessions, ne répondez pas « oui, entièrement en place » à la question sur les contrôles de session. Les responsables comparent les deux. Une réponse honnête comme « en partie, correction prévue le mois prochain », avec une date, préserve votre crédibilité. Une réponse optimiste qu’un nouveau test contredit plus tard peut vous coûter la transaction et la relation.

Éviter que le prochain rapport soit pareil

Beaucoup de grandes entreprises s’attendent à un nouveau test d’intrusion chaque année ou après des changements importants. La façon la moins coûteuse d’obtenir un rapport court la prochaine fois est d’intégrer la sécurité au travail courant :

1. Une revue de code qui vérifie les autorisations et le traitement des entrées, pas seulement le style.
2. Une analyse automatique des dépendances et des secrets dans le pipeline de compilation.
3. Des tests qui vérifient qu’un client ne peut pas accéder aux données d’un autre client.
4. Un processus simple pour corriger les nouveaux constats selon leur gravité, avec des dates.

Dix questions à poser à votre équipe ou à votre firme de développement

1. Quels constats sont critiques ou élevés, et quand chacun sera-t-il corrigé et testé de nouveau?
2. Avons-nous confirmé que chaque constat est réel, et noté par écrit pourquoi nous en contestons certains?
3. Quels constats ont une même cause, et corrigeons-nous la cause ou seulement l’adresse?
4. Avons-nous cherché la même faille dans le reste de l’application, et pas seulement à l’endroit où le testeur l’a trouvée?
5. Y a-t-il un test automatisé pour chaque correction importante?
6. La firme de test a-t-elle accepté de faire un nouveau test, et quand recevrons-nous la lettre?
7. Quels constats faibles acceptons-nous, et avons-nous noté pourquoi?
8. Nos réponses au questionnaire de sécurité concordent-elles avec le rapport et le nouveau test?
9. Que dit le contrat du client sur les délais de correction (vérifiez avec votre avocat si les clauses ne sont pas claires)?
10. Qu’est-ce qui empêchera les mêmes constats de revenir dans le test de l’an prochain?

Si plusieurs réponses sont floues, voilà votre liste de travail.

Notre approche

NorthSight Technologies est une firme de développement logiciel en Ontario, au Canada. Nous ne sommes pas la firme qui effectue votre test d’intrusion. Nous sommes les ingénieurs qui corrigent ce qu’il trouve. Des ingénieurs seniors lisent le rapport et le code, trouvent les causes, écrivent et testent les corrections, cherchent les mêmes failles dans le reste du code, et préparent les preuves que votre firme de test et l’équipe de sécurité de votre client demanderont. Nous travaillons avec votre firme de test et votre responsable de la sécurité ou de la conformité.

Si votre contrat avec une grande entreprise attend la correction des constats d’un test d’intrusion et que vous voulez une réponse franche sur le temps qu’il faudra, nous offrons un appel gratuit de 20 minutes. Vous pouvez lire comment nous travaillons et réserver l’appel sur notre page sur la revue de code sécurisée et la sécurité applicative.

Aussi publié sur LinkedIn (en anglais) →