Penetration test as a service (PTaaS): cos'è e quando serve

Il penetration test as a service (PTaaS) è un modello di erogazione del penetration test: il test resta un'attività offensiva autorizzata condotta da persone, ma cambia il modo in cui viene acquistato e consegnato. Non un progetto isolato che finisce con un PDF, ma un servizio continuativo, con i risultati che arrivano in piattaforma mentre il test procede e il retest già previsto.

È una differenza di modello, non di tecnica. Chi valuta un PTaaS di solito non cerca un test diverso: cerca di uscire dal ciclo del test annuale che invecchia dopo il primo rilascio. Vediamo cosa comprende il modello, cosa cambia rispetto al pentest tradizionale, quando conviene, quando conviene meno e cosa chiedere prima di firmare.

Che cos'è il penetration test as a service

Il PTaaS non è una nuova categoria di test: è il penetration test, con la cornice contrattuale e operativa di un servizio. La struttura generale dell'attività (mandato scritto, perimetro definito, regole d'ingaggio, sfruttamento verificato delle vulnerabilità) resta quella descritta nella guida al penetration test.

Nelle offerte che si trovano sul mercato ricorrono tre elementi, e sono questi a definire il modello più di qualsiasi acronimo:

• un impegno continuativo, a periodo o a consumo, invece di un ordine singolo per un singolo test;
• una piattaforma di consegna, in cui i finding compaiono man mano che il tester li verifica, con stato, severità e traccia della remediation, invece di un documento consegnato a fine progetto;
• il retest incluso, cioè la verifica delle correzioni dentro il perimetro dell'accordo, non come attività da negoziare a parte.

Molti fornitori affiancano al test manuale una scansione periodica tra un ciclo e l'altro: è utile, purché sia chiaro cosa copre la scansione (le debolezze note, in ampiezza) e cosa copre il tester (tutto il resto).

Una precisazione terminologica: PTaaS non compare nel NIST SP 800-115 né nei testi normativi che chiedono attività di testing, dal D.Lgs. 138/2024 a DORA. È un termine di mercato, quindi il contenuto lo definisce il contratto: due offerte con la stessa etichetta possono contenere cose molto diverse.

PTaaS e pentest tradizionale: cosa cambia davvero

La cadenza

Il punto di partenza è un limite riconosciuto da tempo. Il NIST SP 800-115, la Technical Guide to Information Security Testing and Assessment pubblicata nel settembre 2008, lo scrive parlando di frequenza delle valutazioni: poiché una valutazione fornisce "a snapshot of security at a given point in time", una fotografia della sicurezza in un dato momento, un'organizzazione può decidere di eseguirne di più frequenti (paragrafo 6.2). Non è una critica al pentest, è la sua natura: una misura puntuale su una superficie che poi cambia.

Il modello a servizio distribuisce l'attività nel tempo: cicli più corti, test incrementali sui rilasci, perimetro rivisto quando cambia. Il pentest tradizionale concentra lo stesso impegno in una finestra unica, di solito più profonda.

La consegna dei risultati

Nel modello classico il finding esiste per il cliente quando arriva il report. Nel PTaaS compare in piattaforma quando il tester lo verifica, e questo cambia i tempi della correzione: un difetto critico trovato al terzo giorno entra nella coda di sviluppo il terzo giorno, non tre settimane dopo. Con le integrazioni verso i sistemi di ticketing diventa un'attività tracciata invece di una riga in un allegato.

Il rovescio della medaglia: un flusso continuo di finding senza una sintesi finale leggibile da chi decide vale meno di un report ben scritto. La sintesi va chiesta esplicitamente, soprattutto se il documento serve a un cliente o a un auditor.

Il retest

È la differenza più concreta sul piano operativo. Nel modello a progetto la verifica delle correzioni è un'attività separata, con un suo ordine e i suoi tempi, e per questo talvolta non viene fatta. Nel PTaaS è parte del ciclo: si corregge, si richiede la verifica, il finding si chiude solo quando la correzione regge.

Cosa non cambia

Il metodo. Le fasi restano quelle descritte dal NIST SP 800-115 (pianificazione, discovery, attacco, reporting, con il reporting che corre in parallelo alle altre tre) e la metodologia applicativa resta la OWASP Web Security Testing Guide, la cui versione stabile è la 4.2. Restano anche gli obblighi preliminari: autorizzazione scritta del titolare dei sistemi, perimetro dichiarato, finestre concordate, gestione dei dati raccolti. Un servizio continuativo non rende superfluo lo scoping, lo rende ricorrente.

Cosa il PTaaS non è

Tre confusioni frequenti, tutte e tre costose se ci si accorge troppo tardi.

• Non è un vulnerability assessment con un nome nuovo. Se l'offerta consegna solo output di scanner in un cruscotto, quello che stai comprando è una scansione ricorrente: utile, ma diversa. Il confine è spiegato nel confronto tra penetration test e vulnerability assessment, e cosa copre davvero la scansione periodica sta nella scheda sul vulnerability assessment.
• Non è un bug bounty. Nel bug bounty il perimetro è aperto a una comunità di ricercatori e si paga per risultato; nel PTaaS il team è identificato e la copertura è sistematica e verificabile. Sono modelli complementari, non intercambiabili.
• Non è un red team. Un esercizio guidato dalla minaccia, costruito su scenari realistici e condotto senza avvisare il team difensivo, ha obiettivi e regole diverse: un abbonamento a test ricorrenti non lo sostituisce.

Come si svolge un ingaggio PTaaS

1. Scoping iniziale. Asset nel perimetro, ruoli applicativi, ambienti (produzione o staging), finestre operative, canale di allerta immediata per i finding critici, chi autorizza cosa.
2. Test di baseline. Il primo ciclo completo costruisce la fotografia di partenza: da lì in poi ogni ciclo misura una differenza.
3. Finding in corso d'opera. Ogni verifica confermata entra in piattaforma con severità, evidenza riproducibile e indicazione di remediation.
4. Remediation e retest. La correzione viene verificata dal tester, e il finding si chiude solo se la verifica passa.
5. Cicli successivi e revisione del perimetro. È il passaggio che più spesso viene saltato: se l'elenco degli asset non si aggiorna, il servizio continua a testare bene ciò che è già coperto e ignora ciò che è comparso nel frattempo.

Quando il PTaaS conviene

Il modello dà il meglio quando la superficie cambia più in fretta di quanto un test annuale riesca a seguire.

• Rilasci frequenti. Se l'applicazione cambia ogni due settimane, un test all'anno descrive una versione che non esiste più. Vale soprattutto per le applicazioni esposte, dove perimetro e metodologia sono quelli del web application penetration test.
• Più asset da coprire nell'arco dell'anno. Con dieci applicazioni e un solo budget di test, un piano distribuito copre più di un singolo progetto concentrato.
• Richieste ricorrenti dei clienti. Nel mid-market è il caso più frequente: un cliente strutturato chiede l'esito di un test recente prima di firmare o rinnovare, e una verifica aggiornata evita di trasformare ogni trattativa in un progetto d'urgenza.
• Team piccolo che deve dare priorità. Un flusso ordinato di finding con severità e stato è più gestibile di duecento pagine consegnate una volta l'anno.

Quando conviene meno

Ci sono casi in cui il modello a progetto resta la scelta più sensata.

• Perimetro piccolo e stabile. Un'infrastruttura che cambia poco non ha bisogno di un impegno continuativo.
• Una singola verifica prima del go-live. Qui serve profondità in una finestra, non copertura distribuita.
• Obblighi che chiedono un esercizio specifico. Per le entità finanziarie tenute al TLPT, il test di penetrazione guidato dalla minaccia previsto da DORA ha requisiti propri e non si soddisfa con un servizio ricorrente.
• Ambienti con vincoli operativi stretti. Dove le finestre di test sono rare e concordate mesi prima, come in molti contesti industriali, la continuità è difficile da mettere a terra.

PTaaS e conformità: cosa chiedono davvero le norme

Nessuna norma nomina il PTaaS, ma diverse chiedono qualcosa che il modello continuativo aiuta a dimostrare: che le verifiche siano un processo, non un episodio.

La NIS2, recepita in Italia con il D.Lgs. 138/2024, elenca all'articolo 24, comma 2, le misure minime per i soggetti essenziali e importanti. Due lettere sono pertinenti: la e) chiede la "sicurezza dell'acquisizione, dello sviluppo e della manutenzione dei sistemi informativi e di rete, ivi comprese la gestione e la divulgazione delle vulnerabilità"; la f) chiede "politiche e procedure per valutare l'efficacia delle misure di gestione dei rischi per la sicurezza informatica". Valutare l'efficacia significa verificarla, e una verifica ripetuta lascia più tracce di una sola: il quadro completo è nella guida alla NIS2.

L'Allegato A della ISO/IEC 27001:2022 contiene il controllo 8.8 sulla gestione delle vulnerabilità tecniche e il controllo 8.29 sui test di sicurezza in fase di sviluppo e accettazione, entrambi attività ricorrenti legate al ciclo di vita dei sistemi (i requisiti dell'Annex A).

Per il comparto finanziario, il Regolamento (UE) 2022/2554 (DORA) chiede alle entità finanziarie diverse dalle microimprese un programma di test della resilienza operativa digitale (articolo 24), che comprende fra gli strumenti i test di penetrazione (articolo 25), e riserva il TLPT, il test di penetrazione guidato dalla minaccia, alle entità individuate dalle autorità competenti, con cadenza almeno triennale (articolo 26): il perimetro degli obblighi è nella guida a DORA.

La lettura pratica: l'evidenza che conta per un auditor non è l'abbonamento, è la sequenza documentata di finding, correzioni e verifiche.

Cosa chiedere prima di firmare

Le offerte con la stessa etichetta variano molto. Sei domande separano un servizio di testing da un cruscotto con dentro uno scanner.

• Chi esegue il test. Team interno o subappaltato, con quali competenze e quante ore di lavoro manuale per ciclo.
• Quale metodologia viene dichiarata. NIST SP 800-115, OWASP Web Security Testing Guide, PTES, e come si legge nel report quali verifiche sono state eseguite e quali no.
• Cosa comprende il canone. Quanti cicli, su quali asset, con quale profondità, e cosa viene fatturato a parte.
• Come si contano gli asset. Per dominio, per applicazione, per indirizzo IP, per endpoint API: è la voce che fa divergere due preventivi apparentemente uguali.
• Come e quando arrivano i finding critici. Serve un canale di allerta immediata, non l'attesa della fine del ciclo.
• Cosa esce dalla piattaforma e come sono trattati i dati. Formato del report per clienti e auditor, esportabilità, dove sono conservate le evidenze, chi vi accede e cosa resta accessibile alla cessazione del contratto.

Cosa incide su impegno e tempi

I fattori che spostano l'impegno di un servizio continuativo sono pochi: il numero e il tipo di asset nel perimetro e quanto spesso cambiano, il numero di ruoli applicativi da verificare (ogni ruolo moltiplica le combinazioni di autorizzazione), la frequenza dei cicli e la quota di lavoro manuale in ciascuno, l'ambiente su cui si opera (la produzione impone più cautele di uno staging fedele), il retest e le integrazioni verso ticketing e pipeline di sviluppo. Sono gli stessi elementi che vanno fissati nello scoping: un preventivo che non li nomina sta stimando alla cieca.

Dal test al presidio

Un servizio di testing continuativo riduce il tempo in cui una debolezza resta sfruttabile. Non dice però se qualcuno la sta sfruttando adesso: a quella domanda rispondono i log raccolti e correlati dentro un presidio operativo. Il testing abbassa la superficie, il monitoraggio abbassa il tempo di scoperta.

AmagisTech affianca il mid-market italiano su entrambi i fronti. Se stai valutando un modello continuativo e vuoi capire quale perimetro, quale cadenza e quale profondità hanno senso nel tuo caso, parliamone in una call di scoping.