Lo standard PTES (Penetration Testing Execution Standard)

Quando acquirenti e provider non sono d’accordo su cosa includa un “penetration test”, il problema raramente è la malafede—è l’ambiguità. Il Penetration Testing Execution Standard (PTES) è stato creato per dare all’industria una struttura condivisa, end-to-end, su come deve svolgersi un engagement professionale: dal pre-engagement al reporting.

Questo articolo spiega cos’è PTES, attraversa le sue sette fasi e mostra come i team di sicurezza possono usarlo per definire meglio i test e ottenere outcome più actionable—soprattutto quando abbinano test periodici al monitoraggio continuo.

Cos’è PTES e perché conta

PTES è uno standard community-driven che definisce un ciclo di vita completo del penetration testing. Non sostituisce guide tecniche (ad esempio OWASP per le web app) e non è un sistema di scoring delle vulnerabilità. Risponde piuttosto a: Cosa dovrebbe includere un engagement di pentest professionale, in quale ordine e con quali artefatti?

Perché conta:

• Qualità dello scope. Le aspettative di pre-engagement diventano esplicite: target, vincoli, criteri di successo e elementi out-of-scope.
• Coerenza. Team diversi (o vendor diversi) possono comunque seguire un processo confrontabile.
• Reporting pronto alle decisioni. Lo standard spinge verso finding che supportano remediation e decisioni di rischio—non solo output grezzo degli tool.

Per le organizzazioni bloccate in test annuali “a checkbox”, PTES è un modo pratico per alzare la qualità dell’engagement. Rende anche evidenti i gap: se il provider salta threat modeling o analisi di post-exploitation, puoi chiedere perché—usando un vocabolario condiviso.

Le sette fasi PTES

1. Pre-engagement Interactions

Questa fase copre contratti, rules of engagement, definizione dello scope, piani di comunicazione e logistica. Se fatta bene, previene i fallimenti più costosi: testare gli asset sbagliati, perdere sistemi critici o violare vincoli legali/operativi.

Checklist pratiche:

• IP, domini, app, identity e ambienti in scope
• Finestre di test, rate limit e contatti di emergenza
• Gestione dei dati per evidenze e PII
• Obiettivi (evidenza di compliance vs. simulazione realistica di breach)

2. Intelligence Gathering

Chiamata anche OSINT e ricognizione. I tester raccolgono informazioni pubbliche e autorizzate per comprendere la superficie di attacco dell’organizzazione: domini, dipendenti, tecnologie, presenza cloud e relazioni con terze parti.

È qui che i programmi di esposizione continua e i test puntuali si incontrano. La discovery esterna della attack surface che gira tutto l’anno può alimentare intel più ricca in un engagement PTES pianificato—così il test parte dalla realtà corrente, non dall’inventario dell’anno scorso.

3. Threat Modeling

Il threat modeling traduce l’intelligence in narrative di attacco prioritizzate: chi potrebbe attaccare, cosa vuole e quali percorsi sono più plausibili. Concentra lo sforzo su asset ad alto valore e obiettivi avversariali realistici, piuttosto che sulla sola scansione esaustiva a basso impatto.

4. Vulnerability Analysis

Qui i tester identificano debolezze tramite scanning, review manuale, analisi di configurazione e research. L’enfasi è sulla comprensione della exploitability nel contesto—non sul trattare ogni finding dello scanner come uguale.

5. Exploitation

Lo exploitation valida quali vulnerabilità possono essere usate per ottenere accesso o impatto significativi sotto le regole concordate. Un engagement responsabile include controlli di sicurezza: evitare payload distruttivi se non esplicitamente autorizzati e documentare l’impatto con cura.

6. Post Exploitation

Spesso la fase più preziosa per i difensori. Dopo l’accesso iniziale, cosa può fare un attaccante? Pivotare? Escalare privilegi? Accedere a dati sensibili? Abusare relazioni di fiducia? Il post-exploitation rivela impatto di business e gap di controllo che un report “abbiamo trovato XSS” può mancare.

7. Reporting

Il reporting PTES dovrebbe collegare i finding tecnici a rischio, evidenze e guida di remediation. Report solidi tipicamente includono:

• Executive summary con impatto di business
• Scope, metodologia e limitazioni
• Finding con severità, evidenze e note di riproduzione
• Raccomandazioni di remediation e criteri di verifica
• Narrative di attacco opzionali o storie in stile kill chain

Usare PTES per definire engagement migliori

I leader della sicurezza possono operazionalizzare PTES senza diventare pedanti metodologici:

1. Metti le aspettative di fase in RFP/SOW. Chiedi ai vendor come gestiscono threat modeling e post-exploitation—non solo scanning.
2. Separa discovery e validazione. Monitoraggio continuo e feed TPRM/esposizione migliorano la Fase 2; il pentest valida ancora i percorsi di exploit.
3. Definisci il successo oltre il “numero di finding”. Preferisci outcome come “validare lateral movement da compromissione VPN” o “valutare percorsi di abuso admin SaaS”.
4. Richiedi artefatti pronti per la remediation. Screenshot, coppie request/response e guida chiara alle fix riducono il rework.
5. Pianifica i retest. Un programma allineato a PTES include la verifica che le fix abbiano funzionato—un altro motivo per cui gli snapshot da soli non bastano.

PTES insieme ad altri framework

• OSSTMM — forte su misurazione operativa e verifica basata sui canali.
• OWASP Testing Guide / ASVS — copertura approfondita per sicurezza di applicazioni e API.
• MITRE ATT&CK — mappa le tecniche usate in exploitation e post-exploitation in un linguaggio avversariale comune.
• NIST SP 800-115 — guida tecnica complementare usata in molti contesti USA.

I programmi più maturi li mischiano: PTES per la struttura dell’engagement, ATT&CK per fedeltà avversariale e guide di dominio per la profondità.

Monitoraggio continuo e cicli PTES ricorrenti

Un engagement PTES è più forte quando non è isolato. Exposure esterne e di terze parti cambiano più in fretta dei calendari di test annuali. Alimentare inventory live e cambiamenti dei trust boundary nella intelligence gathering—e pianificare retest mirati dopo remediation importanti—trasforma PTES da artifact di compliance in un feedback loop operativo. Le fasi dello standard restano valide; cambia semplicemente la cadenza, da puramente calendariale a continua.

Takeaway pratici per i team di sicurezza

• Tratta il pre-engagement come un controllo di sicurezza, non come burocrazia.
• Alimenta intelligence di attack surface e terze parti continua nella raccolta intel.
• Insisti sull’analisi di post-exploitation per target ad alto valore.
• Usa tag ATT&CK nei report così i purple team possono riusare il lavoro.
• Traccia remediation e cicli di retest; non archiviare il PDF e andare avanti.

Concetti correlati

• Rules of engagement e autorizzazione
• Red teaming vs. penetration testing
• Continuous exposure / attack surface management
• Vulnerability management e SLA di remediation

Conclusione

PTES dà ad acquirenti e tester una mappa condivisa di come dovrebbe apparire un vero penetration test. Usalo per alzare la disciplina di scoping, richiedere insight significativi di post-exploitation e collegare i test periodici alla realtà di monitoraggio continuo delle superfici di attacco moderne. La metodologia è un mezzo; la riduzione del rischio verificata e remediabile è il fine.