Un penetration test risponde alla domanda scritta nel suo scope, e a nient'altro. Se lo scope dice "testare la nostra applicazione web", riceverà un report su ciò che i tester hanno trovato più interessante nel tempo a disposizione, che potrebbe non coincidere con ciò che Lei aveva bisogno di sapere.
La soluzione è la preparazione. Prima di chiedere i preventivi, stabilisca la domanda, le regole, gli accessi, la gestione dei dati e la definizione di "completato".
Parta dalla domanda, non dal target
Un elenco di indirizzi IP e URL è una lista di target, non un obiettivo. L'obiettivo è la decisione che il test deve supportare. NIST SP 800-115 afferma che i test tecnici di sicurezza hanno diverse finalità, come individuare vulnerabilità in un sistema o in una rete e verificare la conformità a una policy o ad altri requisiti. Sono compiti diversi e richiedono test diversi.
Formuli l'obiettivo in una frase che uno sponsor non tecnico possa leggere. Alcuni esempi:
- Un cliente autenticato può leggere le fatture di un altro cliente nel nuovo portale?
- Un attaccante privo di account può raggiungere l'interfaccia di amministrazione del sistema di prenotazione?
- L'applicazione soddisfa i requisiti di controllo degli accessi citati nel questionario di sicurezza del nostro cliente?
Ciascuno di questi obiettivi implica uno scope diverso, account diversi e un report diverso. Se non riesce a scrivere una sola frase, non è ancora pronto ad acquistare. Prima di chiedere i preventivi vale la pena fare una breve call di scoping con i tester o con un consulente, come il nostro team di consulenza.
Scelga un riferimento per "testato"
"Testato completamente" non significa nulla finché non si indica rispetto a cosa è stato testato. Per le applicazioni web, due progetti OWASP offrono un vocabolario condiviso.
L'OWASP Application Security Verification Standard (ASVS) è una base per testare i controlli tecnici di sicurezza delle applicazioni web e fornisce agli sviluppatori un elenco di requisiti per lo sviluppo sicuro. La pagina del progetto indica la 5.0.0 come ultima versione stabile. Ogni requisito ha un identificativo numerato e il progetto raccomanda di citarlo insieme alla versione, ad esempio v5.0.0-1.2.5. La versione conta perché gli identificativi possono cambiare da una release all'altra.
L'OWASP Web Security Testing Guide descrive come condurre i test. La sua pagina indica la v4.2 come release attuale, con la 5.0 ancora in sviluppo. Indichi nel contratto la versione che si aspetta, altrimenti ciascuna parte darà per scontata una versione diversa.
Poi specifichi quali parti dell'ASVS rientrano nello scope, per capitolo e sezione come compaiono nella versione scelta. L'identificativo v5.0.0-1.2.5, ad esempio, indica il quinto requisito della sezione "Injection Prevention" del capitolo "Encoding and Sanitization". Scelga le sezioni coerenti con il Suo obiettivo e chieda che i finding siano mappati sugli identificativi dei requisiti. Questo semplifica molto i retest e il follow-up da parte degli sviluppatori.
Regole d'ingaggio
Le regole d'ingaggio sono i limiti scritti di ciò che i tester possono fare. Si tratta di nostre raccomandazioni e non di prescrizioni delle fonti, ma ogni documento di scope dovrebbe definire questi punti:
| Voce | Da stabilire |
|---|---|
| Ambiente | Produzione, staging o entrambi. Lo staging è più sicuro, ma è utile solo se replica la configurazione di produzione. |
| Finestra | Date e orari, e se il test può svolgersi fuori dall'orario di lavoro. |
| Indirizzi sorgente | Gli IP che i tester useranno, così che il Suo team di monitoraggio possa distinguerli da un attaccante reale. |
| Tecniche escluse | Denial of service, social engineering e accesso fisico sono esclusioni comuni. Le metta per iscritto in ogni caso. |
| Condizioni di stop | Che cosa fa sospendere i tester: un disservizio, l'accesso a dati personali inattesi, un finding critico. |
| Referenti | Due persone nominate per parte, con numeri di telefono raggiungibili anche di notte. |
Decida in anticipo se il Suo SOC sarà informato del test. Informarlo mette alla prova il processo, mentre non dirgli nulla mette alla prova il rilevamento. Entrambe le scelte sono valide, ma va fatta in modo deliberato.
Account di test e gestione dei dati
Fornisca degli account, perché un tester senza credenziali non può esaminare ciò che sta dietro il login. Ne serve uno per ogni ruolo previsto dall'applicazione, più due account con lo stesso ruolo appartenenti a clienti o tenant diversi. Senza questa coppia nessuno può verificare se un utente riesca ad accedere ai dati di un altro.
Crei gli account in anticipo, verifichi che l'accesso funzioni e indichi come verrà gestita l'autenticazione a più fattori.
Concordi nel contratto la gestione dei dati:
- Usi dati sintetici in staging, ovunque possibile. Se la produzione rientra nello scope, specifichi quali record reali i tester possono visualizzare e quali no.
- Indichi dove verranno conservate le evidenze, come screenshot, log delle richieste e dati estratti, chi può accedervi e per quanto tempo i tester le conservano.
- Richieda che il report stesso viaggi cifrato. È un elenco delle Sue debolezze.
- Stabilisca la regola per i rinvenimenti sensibili: se i tester si imbattono in dati personali, si fermano, annotano dove si trovano senza copiarne il contenuto e chiamano il Suo referente.
Criteri di successo e reportistica
"Nessun finding critico" non è un criterio di successo. Premia un test superficiale. Definisca il completamento come copertura più qualità dell'output: i requisiti concordati sono stati esaminati e ogni finding è corredato di dettagli sufficienti per riprodurlo e correggerlo.
NIST descrive la propria guida come un aiuto sia per eseguire i test sia per analizzare i risultati e sviluppare strategie di mitigazione. Chieda lo stesso. Ogni finding dovrebbe includere i passi di riproduzione, il componente interessato, una valutazione di severità con un metodo dichiarato, così da poterla verificare in autonomia, e una remediation concreta. Aggiunga al preventivo un retest dei finding corretti e concordi chi accetta il report e quando.
Se acquista da un fornitore come il nostro servizio di penetration testing, inserisca questi punti nello statement of work, non solo nella call di kick-off.
Da dove iniziare
- Scriva l'obiettivo in una frase e lo faccia approvare dal responsabile di business.
- Elenchi le applicazioni, gli ambienti e i ruoli nello scope e indichi esplicitamente ciò che ne è escluso.
- Scelga il riferimento: i capitoli e le sezioni ASVS nello scope e una versione del Web Security Testing Guide, il tutto con i numeri di versione.
- Compili la tabella delle regole d'ingaggio, inclusi referenti, finestra e indirizzi sorgente.
- Crei e verifichi gli account di test, comprese due utenze con lo stesso ruolo per tenant diversi, e definisca le regole di gestione dei dati.
- Inserisca nel contratto i criteri di successo: formato dei finding, metodo di severità, mappatura sugli identificativi dei requisiti e un retest.
