Tests d'intrusion : comment se déroule le process et que doit préparer l'entreprise ?

Pour présenter à un grand compte, demandez directement un test d'application web en boîte grise. Le test en boîte noire simule un attaquant externe mais passe à côté des failles d'élévation de privilèges dans la logique métier. Pensez à fournir à l'équipe d'audit au moins deux comptes avec des niveaux de droits différents.

Faites un doc dès maintenant listant toutes vos IP publiques, l'URL de connexion à l'appli web et le nombre de services d'arrière-plan. En joignant ça direct à vos demandes, les prestataires comprendront le périmètre d'un coup et vous aurez vos devis en trois jours.

Ne faites pas l'impasse sur ces 4 points pendant la prépa : 1) Sauvegarde complète de vos serveurs (snapshot). 2) Whitelister les IP de l'équipe d'audit sur votre pare-feu. 3) Brider ou couper les envois d'e-mails et de SMS sur l'environnement de test. 4) Prévenir votre hébergeur cloud des dates du pentest.

si vous faites le test sur la prod faites super gaffe à la base de données. quand les pentesters injectent des payloads dans les formulaires ça peut vite spammer des centaines de fausses factures ou des sms aux vrais clients. genre coupez temporairement les services de notification pendant le test.

Votre client grand compte demande uniquement le test de votre appli web, ou il a aussi imposé un test de votre réseau local interne et des campagnes de phishing sur vos employés ? Si le périmètre se limite à votre appli SaaS, un budget de 70.000 TL sera largement suffisant.

Le mois dernier, pour une intégration retail similaire, on a fait tester 1 appli web et 6 IP externes. Ça a pris 5 jours, le rapport préliminaire est ressorti avec 2 failles critiques et 4 moyennes. Entre la correction des failles et le retest de validation, ça nous a pris 20 jours en tout.

Sur le marché, il y a des boîtes qui se contentent de lancer un scanner de vulnérabilités automatique sortent un PDF générique de 100 pages et appellent ça un pentest. Quand vous demandez des devis, faites impérativement acter par écrit qu'il y aura une validation manuelle et que les failles de logique métier seront bien auditées.

En résumé, dressez l'inventaire de vos IP et URL, partez sur une méthode en boîte grise, montez un environnement de test avec des sauvegardes et assurez-vous bien que le retest de validation est inclus dans le prix. En général, tout le process est bouclé en un mois.

J'y pensais aussi. Si vous obtenez trois réponses différentes sur un sujet, la question est mal posée.

Je suis aussi curieux de savoir si d'autres font autrement.

Laissez-moi détailler l'aspect technique. Si le chemin de notification est long, la notification n'arrive pas ; une notification manquante signifie un événement détecté tardivement.

Bon courage.

C'est globalement vrai, mais il manque un point. L'erreur commise du côté de déroulement d'un test d'intrusion est généralement réversible, mais coûteuse.

La plupart des pertes de temps s'accumulent sur les tâches en attente de validation. C'est confirmé par l'expérience.

C'est noté, merci.

Enregistré.

Nous avons vécu presque la même chose l'année dernière. N'hésitez pas à demander, celui qui ne demande pas paie toujours plus cher.

Je le note au cas où.

Ne manquez rien : Une sauvegarde non testée n'est pas une sauvegarde.

Voilà, désolé si je me suis étendu.

J'ai travaillé longtemps sur ce sujet. Ce qui nous faisait perdre le plus de temps, c'était l'absence de clarté sur qui prenait les décisions.

Le point le plus souvent négligé concernant déroulement d'un test d'intrusion est : La plupart des pertes de temps s'accumulent sur les tâches en attente de validation.

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

Absolument. Si j'ajoute quelque chose : Le temps que vous mettez à détecter un problème détermine directement son coût.

Aucun processus sans suivi ne s'améliore, car vous ne savez pas quoi corriger.