Fase · Budget · Sbloccare la trattativa

Costo del penetration test per startup

La maggior parte delle startup non compra un penetration test perché l'ha deciso. Lo compra perché la verifica di sicurezza di un cliente enterprise sta bloccando un contratto, oppure perché si avvicina un round e sta arrivando la due diligence. Questo cambia quanto dovreste spendere e cosa il test deve produrre.

Cosa spinge davvero l'acquisto

Prima di parlare di budget conviene essere precisi sul perché state comprando, perché determina il perimetro e quindi il prezzo. In pratica ci sono quattro inneschi.

  • La verifica di sicurezza di un cliente enterprise. Un questionario di procurement o di rischio fornitori chiede un penetration test indipendente recente. È l'innesco più comune e il più urgente, perché dietro c'è un contratto.
  • Un round di finanziamento. La due diligence tecnica dal Serie A in poi chiede spesso quali test indipendenti siano stati fatti e cosa ne sia seguito.
  • Un framework. SOC 2, PCI DSS o un regime regionale pone un requisito con una data. Le pagine compliance trattano cosa si aspetta ciascuno.
  • Un incidente. È successo qualcosa e dovete sapere cos'altro è esposto.

Solo il quarto è aperto. Gli altri tre hanno una controparte esterna precisa il cui requisito è leggibile, e quel requisito è di solito più stretto di quanto il panico suggerisca. Ottenetelo prima per iscritto.

Budget realistici per fase

Questi sono i perimetri che tendono ad avere senso, non un'affermazione su quanto dobbiate spendere.

Pre-seed e seed

Dimensionate sul singolo prodotto che vendete, autenticato, con la sua API se ce l'ha. È un incarico di applicazione web da 500 $, tipicamente tre-cinque giorni lavorativi. In questa fase non serve quasi mai il test di rete o Active Directory, perché quasi certamente non avete un dominio aziendale che valga la pena attaccare. Spendete la differenza nel correggere ciò che il test trova.

Serie A

Il prodotto è più grande, di solito ci sono più ruoli utente, e l'isolamento fra tenant è diventato una domanda reale perché ora avete clienti a cui interessa. Resta un perimetro applicativo, ma dimensionato sul numero di ruoli e sulla superficie di API anziché sull'impronta più piccola possibile. Se vi siete spostati su un ambiente cloud con infrastruttura rilevante, aggiungete il test cloud da 1.500 $.

Serie B e oltre

A questo punto avete tipicamente una rete aziendale, un identity provider e personale con portatili, il che significa che la superficie di attacco non è più solo il prodotto. Il test di rete e Active Directory da 1.500 $ diventa davvero rilevante, e un programma annuale su prodotto e infrastruttura ha più senso di un singolo incarico. È anche la fase in cui phishing e social engineering iniziano a contare, perché avete abbastanza persone da essere un bersaglio.

Dimensionare un primo test perché sblocchi la trattativa

Un primo test comprato sotto pressione commerciale ha un compito: produrre evidenze che il cliente accetti. Tre cose decidono se ci riesce.

Il perimetro deve corrispondere a quanto richiesto. Se il cliente compra il vostro prodotto SaaS, testate il prodotto SaaS, autenticato, incluso il confine fra due account cliente. Un test del vostro sito vetrina non soddisfa nessuno e la lettera di attestazione lo dirà.

Le evidenze devono essere complete. La maggior parte delle verifiche vuole un report con perimetro, risultati valutati per gravità, remediation documentata, evidenza di retest, e una lettera che attesti cosa è stato testato e quando. Se uno di questi è un acquisto separato, lo scoprirete nel momento peggiore. Tutti e quattro sono inclusi per impostazione predefinita nei miei incarichi.

I tempi vanno calcolati a ritroso dalla scadenza. Il test è tre-cinque giorni lavorativi per un'applicazione piccola, poi i vostri ingegneri hanno bisogno di tempo per correggere, e poi arriva il retest. Due settimane dall'inizio alla fine è un minimo realistico. Iniziare la conversazione un mese prima costa come iniziarla una settimana prima e produce un risultato molto migliore.

Cosa fare prima del test per ricavarne di più

Ogni ora che il tester passa su qualcosa che avreste potuto correggere in dieci minuti è un'ora non spesa sulle parti interessanti della vostra applicazione. Prima di un primo test conviene attivare l'autenticazione multifattore sugli accessi amministrativi, rimuovere gli account di chi se n'è andato, aggiornare le dipendenze con vulnerabilità critiche note e assicurarsi che i dati di test e staging non siano dati di produzione. Niente di tutto ciò è glamour e tutto alza il valore di quello che state comprando. C'è un elenco più lungo in come prepararsi al primo penetration test.

Decidete anche in anticipo chi correggerà i risultati. Il fallimento più comune del primo test di una startup non è un report cattivo, è un buon report che nessuno ha tempo di affrontare, il che vi lascia con evidenza di problemi e nessuna evidenza di remediation. Per un cliente si legge peggio che non aver testato.

Quanto costa da me

Test applicativi da 500 $, rete e Active Directory o cloud da 1.500 $, a prezzo fisso contro un perimetro scritto e senza fatturazione a ore. Supporto alla remediation, retest e lettera di attestazione sono inclusi. Trattate dall'inizio alla fine con un singolo tester OSCP+, il che a questa dimensione è di solito un vantaggio: chi ha dimensionato il lavoro conosce il vostro prodotto quando scrive il report.

Il modello di prezzo generale è nella pagina sul costo del penetration test, il report di esempio mostra il deliverable, e se la fascia di prezzo che vedete altrove confonde, cosa compra un penetration test economico spiega la dispersione.

Domande di prezzo per startup

Solo se qualcosa lo impone. Se nessun cliente, investitore o framework lo chiede, i vostri soldi rendono di più prima sulle basi: autenticazione multifattore ovunque, scansione delle dipendenze in CI, accessi a privilegio minimo, backup da cui avete davvero ripristinato, e log con cui potreste indagare un incidente. Un test sopra niente di tutto questo produrrà un lungo elenco di cose che già sapete. Nel momento in cui entra in gioco una trattativa o una due diligence, questo calcolo si ribalta all'istante.
Di solito un test con perimetro sul singolo prodotto che sta comprando, con lettera di attestazione ed evidenza che i risultati sono stati corretti e ritestati. Tipicamente è un perimetro applicativo da 500 $ e non un programma infrastrutturale completo. Quello che quasi mai accettano è l'output di uno scanner, un'autovalutazione, o un report più vecchio di dodici mesi. Chiedete al cliente il requisito reale per iscritto prima di dimensionare, perché spesso è più stretto di quanto suggerisca la prima email.
In seed raramente come requisito rigido. Dal Serie A in poi, soprattutto se trattate dati di clienti o vendete a enterprise, la due diligence tecnica chiede spesso se c'è stato un test indipendente e cosa ne è seguito. L'evidenza di remediation conta più del numero di risultati. Un report con dodici risultati tutti corretti e ritestati si legge molto meglio di un report magro con due.
Annualmente è la base comune, e dopo qualsiasi cambiamento architetturale significativo. Se c'è di mezzo un framework, sarà lui a fissare la frequenza. Fra un test e l'altro, la scansione continua di dipendenze e vulnerabilità copre a basso costo la categoria dei CVE noti, il che mantiene il test annuale concentrato su ciò che solo una persona trova.
Sì, e di solito è la scelta giusta per un primo test. Dimensionate sulla parte che porta il rischio reale: l'applicazione autenticata, il confine di isolamento fra tenant, e i flussi di pagamento o di esportazione dati. Quello che non dovete fare è dimensionare così stretto che il report non possa più descrivere onestamente cosa è stato testato, perché la lettera di attestazione deve indicare il perimetro e un cliente esperto la leggerà.

Trattativa bloccata da una verifica di sicurezza?

Ditemi cosa ha chiesto davvero il cliente e vi dirò il perimetro minimo che lo soddisfa.

Contatti