On a reçu un rapport de test d'intrusion de 40 pages — quelqu'un a un exemple pour comparer ?

S'il n'y a pas de preuve d'exploitation (PoC) dans le rapport, c'est que le test n'a pas été fait. Par exemple, s'ils disent avoir trouvé une injection SQL, ils doivent montrer pas à pas comment ils ont extrait une donnée inoffensive de la base. Ils ne peuvent pas juste balancer la capture d'alerte de l'outil et s'arrêter là.

On s'est fait avoir exactement de la même manière il y a deux ans pour 2.500 livres. L'auditeur sécurité de notre client a rejeté le rapport direct en disant que c'était juste un scan de vulnérabilités et pas un pentest. On a dû repayer un autre expert pour tout refaire.

3.500 livres sur le marché britannique, c'est vraiment très limite comme budget pour un test manuel complet. À ce tarif-là, en général ils lancent juste l'outil et impriment le rapport. Un vrai test demande au moins 3 à 5 jours/homme de travail manuel, et la facture va avec.

Renvoyez le rapport à la boîte et demandez deux choses : d'abord une synthèse d'une page sur l'impact et les risques pour la direction, ensuite les étapes concrètes pour que vos devs puissent valider les correctifs. Si votre contrat mentionnait des tests manuels, ils sont obligés de corriger le tir.

Dans votre contrat de prestation, le type de test est formulé comment exactement ? Scan de vulnérabilités ou test d'intrusion ? Les deux sont malheureusement souvent confondus dans le secteur, et s'il est écrit scan de vulnérabilités sur le contrat vous aurez du mal à contester.

vous fiez surtout pas au nombre de pages puis un rapport de 15 pages propre, rédigé à la main et qui va droit au but a 10 fois plus de valeur qu'un dump auto de scanner de 80 pages.

Vous avez tout intérêt à demander une révision à votre prestataire avant de transmettre ce document à votre client. Un auditeur expérimenté repérera immédiatement un simple export automatique, ce qui nuira grandement à votre crédibilité.

Correction : je me suis trompé sur le chiffre, c'était un peu plus bas.

Pour auditer le rapport que vous avez reçu, vérifiez ces trois points : 1) Les faux positifs ont-ils été filtrés ou est-ce qu'ils ont laissé toutes les alertes ? 2) Les scores de risque sont-ils contextualisés par rapport à votre activité ? 3) Vos développeurs comprennent-ils comment corriger le code en le lisant ?

Sujet très actuel.

Vous avez raison.

il est rare de touver un texte qui explique les choses aussi clairement.

Je suis une petite entreprise, laissez-moi expliquer de mon point de vue. La réponse varie beaucoup selon le secteur, il n'y a pas de règle générale.

Je le note au cas où.

Merci beaucoup, cela m'a été très utile. La plupart des incidents ne viennent pas d'une faille, mais d'un mot de passe divulgué.

C'est mon avis, je ne l'écris pas comme une vérité absolue.

C'est globalement vrai, mais il manque un point. Ce qui nous faisait perdre le plus de temps, c'était l'absence de clarté sur qui prenait les décisions.

Tous ceux qui se pressent sur rapport de test d'intrusion se heurtent au même obstacle.

C'est vrai en théorie, mais ça ne marche pas ainsi en pratique. Le temps que vous mettez à détecter un problème détermine directement son coût.

Bien sûr, cela change si votre situation est différente.

Je suis d'accord.

Mon regard a changé après avoir vécu cela. Si vous grondez les fausses alertes, plus personne ne signalera rien.

J'y pensais aussi. Un rapport de scan automatique n'est pas la même chose qu'un test d'intrusion.