Étape · Budget · Débloquer le contrat

Coût d'un test d'intrusion pour startups

La plupart des startups n'achètent pas un test d'intrusion parce qu'elles l'ont décidé. Elles en achètent un parce que la revue de sécurité d'un grand compte bloque un contrat, ou parce qu'une levée de fonds approche et que la due diligence arrive. Cela change ce que vous devriez dépenser et ce que le test doit produire.

Ce qui motive réellement l'achat

Avant de parler budget, il vaut la peine d'être précis sur la raison de l'achat, car elle détermine le périmètre et donc le prix. En pratique, il existe quatre déclencheurs.

  • La revue de sécurité d'un grand compte. Un questionnaire achats ou risque fournisseur réclame un test d'intrusion indépendant récent. C'est le déclencheur le plus fréquent et le plus urgent, parce qu'un contrat est derrière.
  • Une levée de fonds. La due diligence technique à partir de la série A demande fréquemment quels tests indépendants ont eu lieu et ce qui en est ressorti.
  • Un référentiel. SOC 2, PCI DSS ou un régime régional pose une exigence avec une date. Les pages conformité traitent de ce qu'attend chacun.
  • Un incident. Quelque chose s'est produit et vous devez savoir ce qui est exposé par ailleurs.

Seul le quatrième est ouvert. Les trois autres s'accompagnent d'une partie externe précise dont l'exigence est lisible, et cette exigence est généralement plus étroite que la panique ne le laisse croire. Obtenez-la d'abord par écrit.

Budgets réalistes par étape

Voici les périmètres qui ont généralement du sens, et non une affirmation sur ce que vous devez dépenser.

Pré-amorçage et amorçage

Cadrez sur l'unique produit que vous vendez, authentifié, avec son API s'il en a une. C'est une mission application web dès 500 $, généralement trois à cinq jours ouvrés. À ce stade, vous n'avez presque jamais besoin de tests réseau ou Active Directory, car il est quasi certain que vous n'avez pas de domaine d'entreprise qui vaille la peine d'être attaqué. Dépensez la différence à corriger ce que le test trouve.

Série A

Le produit est plus grand, il y a généralement plusieurs rôles utilisateurs, et l'isolation entre locataires est devenue une vraie question parce que vous avez désormais des clients qui s'en soucient. Toujours un périmètre applicatif, mais cadré sur le nombre de rôles et la surface d'API plutôt que sur l'empreinte la plus petite possible. Si vous êtes passé à un environnement cloud avec une infrastructure significative, ajoutez des tests cloud dès 1 500 $.

Série B et au-delà

À ce stade, vous avez généralement un réseau d'entreprise, un fournisseur d'identité et des collaborateurs avec des portables, ce qui signifie que la surface d'attaque n'est plus seulement le produit. Les tests réseau et Active Directory dès 1 500 $ deviennent réellement pertinents, et un programme annuel couvrant produit et infrastructure a plus de sens qu'une mission isolée. C'est aussi l'étape où le phishing et l'ingénierie sociale commencent à compter, car vous avez assez de personnes pour constituer une cible.

Cadrer un premier test pour qu'il débloque le contrat

Un premier test acheté sous pression commerciale a une seule mission : produire des preuves que le client accepte. Trois éléments décident du résultat.

Le périmètre doit correspondre à la demande. Si le client achète votre produit SaaS, testez le produit SaaS, authentifié, y compris la frontière entre deux comptes clients. Un test de votre site vitrine ne satisfait personne et la lettre d'attestation le dira.

Les preuves doivent être complètes. La plupart des revues veulent un rapport cadré, des constats notés en gravité, une remédiation documentée, des preuves de contre-test, et une lettre attestant de ce qui a été testé et quand. Si l'un de ces éléments est un achat séparé, vous le découvrirez au pire moment. Les quatre sont inclus par défaut dans mes missions.

Le calendrier doit se calculer à rebours depuis l'échéance. Le test prend trois à cinq jours ouvrés pour une petite application, vos ingénieurs ont ensuite besoin de temps pour corriger, puis vient le contre-test. Deux semaines de bout en bout est un minimum réaliste. Engager la conversation un mois avant coûte la même chose qu'une semaine avant et produit un bien meilleur résultat.

Quoi faire avant le test pour en tirer plus

Chaque heure que le testeur passe sur quelque chose que vous auriez pu corriger en dix minutes est une heure qu'il ne passe pas sur les parties intéressantes de votre application. Avant un premier test, il vaut la peine d'activer l'authentification multifacteur sur les accès d'administration, de supprimer les comptes des personnes parties, de mettre à jour les dépendances présentant des vulnérabilités critiques connues et de vérifier que les données de test et de préproduction ne sont pas des données de production. Rien de tout cela n'est glorieux et tout cela augmente la valeur de ce que vous achetez. Une liste plus longue figure dans comment préparer votre premier test d'intrusion.

Décidez aussi à l'avance qui corrigera les constats. L'échec le plus fréquent du premier test d'une startup n'est pas un mauvais rapport, c'est un bon rapport que personne n'a le temps de traiter, ce qui vous laisse des preuves de problèmes et aucune preuve de remédiation. Cela se lit plus mal pour un client que de ne pas avoir testé.

Ce que cela coûte chez moi

Tests applicatifs dès 500 $, réseau et Active Directory ou cloud dès 1 500 $, au forfait contre un périmètre écrit et sans facturation horaire. L'accompagnement à la remédiation, le contre-test et la lettre d'attestation sont inclus. Vous traitez du début à la fin avec un unique testeur OSCP+, ce qui à cette taille est généralement un avantage : la personne qui a cadré le travail connaît votre produit au moment de rédiger le rapport.

Le modèle tarifaire général figure sur la page coût d'un test d'intrusion, le rapport type montre le livrable, et si la fourchette de prix que vous voyez ailleurs vous déroute, ce qu'achète un test d'intrusion pas cher explique la dispersion.

Questions tarifaires des startups

Seulement si quelque chose l'impose. Si aucun client, investisseur ou référentiel ne le demande, votre argent est mieux employé d'abord sur les fondamentaux : authentification multifacteur partout, analyse des dépendances dans la CI, accès au moindre privilège, sauvegardes depuis lesquelles vous avez réellement restauré, et des journaux permettant d'enquêter sur un incident. Un test posé par-dessus rien de tout cela produira une longue liste de choses que vous savez déjà. Dès qu'un contrat ou une due diligence est en jeu, ce calcul s'inverse immédiatement.
En général un test cadré sur le seul produit qu'il achète, avec une lettre d'attestation et la preuve que les constats ont été corrigés et contre-testés. C'est typiquement un périmètre applicatif dès 500 $ et non un programme d'infrastructure complet. Ce qui n'est presque jamais accepté : une sortie de scanner, une auto-évaluation, ou un rapport de plus de douze mois. Demandez au client son exigence réelle par écrit avant de cadrer, car elle est souvent plus étroite que ne le suggère le premier courriel.
En amorçage, rarement comme exigence ferme. À partir de la série A, surtout si vous traitez des données clients ou vendez aux grands comptes, la due diligence technique demande fréquemment si un test indépendant a eu lieu et ce qui a été fait des constats. Les preuves de remédiation comptent davantage que le nombre de constats. Un rapport montrant douze constats tous corrigés et contre-testés se lit bien mieux qu'un rapport maigre en montrant deux.
Annuellement est la référence habituelle, et après tout changement d'architecture significatif. Si un référentiel est en jeu, il fixera la fréquence pour vous. Entre deux tests, l'analyse continue des dépendances et des vulnérabilités couvre à moindre coût la catégorie des CVE connues, ce qui garde le test annuel concentré sur ce que seul un humain trouve.
Oui, et c'est généralement le bon choix pour un premier test. Cadrez sur la partie qui porte le risque réel : l'application authentifiée, la frontière d'isolation entre locataires, et les parcours de paiement ou d'export de données. Ce qu'il ne faut pas faire, c'est cadrer si étroitement que le rapport ne puisse plus décrire honnêtement ce qui a été testé, car la lettre d'attestation doit indiquer le périmètre et un client averti la lira.

Contrat bloqué par une revue de sécurité ?

Dites-moi ce que le client a réellement demandé et je vous indiquerai le plus petit périmètre qui y réponde.

Contact