Un penetration test, o pen test, è una verifica di sicurezza autorizzata in cui un professionista simula tecniche di attacco reali contro sistemi, reti o applicazioni per capire se una debolezza può essere realmente sfruttata e quale impatto potrebbe produrre. A differenza di una semplice scansione automatica, il penetration testing combina analisi tecnica, verifica manuale, exploitation controllata, valutazione dell'impatto e reporting.
Lo scopo non è “bucare” un sistema a ogni costo, ma produrre evidenze utili: quali percorsi di compromissione sono praticabili, quali asset risultano raggiungibili, quali controlli hanno funzionato e quali remediation riducono davvero il rischio.
In breve
Il vulnerability assessment individua e prioritizza debolezze su un perimetro; il penetration test verifica in modo controllato se determinate debolezze possono essere sfruttate e con quali conseguenze. Il test deve essere espressamente autorizzato, svolto entro uno scope concordato e regolato da Rules of Engagement.
Devi verificare un perimetro reale?
Se l'obiettivo non è solo capire cos'è un pen test ma applicarlo alla tua infrastruttura, consulta il servizio Nexsys dedicato alle aziende.
Cos'è il penetration test
Il penetration test è un'attività di security testing che simula un attacco entro limiti definiti prima dell'esecuzione. Il tester parte da un obiettivo concordato - per esempio un perimetro Internet, una rete interna, un'applicazione web o un insieme di asset - e prova a verificare se vulnerabilità, configurazioni deboli, errori di progettazione o relazioni di fiducia possono essere concatenate fino a ottenere un impatto significativo.
Il valore del test è quindi diverso da quello di uno scanner. Uno scanner può segnalare che una vulnerabilità potrebbe esistere; un penetration test cerca di stabilire se quella condizione è realmente sfruttabile nel contesto specifico, quali prerequisiti richiede e fino a dove può condurre.
Per il confronto completo tra le due attività consulta Vulnerability Assessment vs Penetration Test.
Pen test, penetration testing ed ethical hacking: sono la stessa cosa?
Nel linguaggio comune i termini pen test, penetration testing, test di penetrazione ed ethical hacking vengono spesso usati come equivalenti. È però utile distinguerli: l'ethical hacking è un insieme più ampio di attività e competenze offensive; il penetration test è un incarico con obiettivi, perimetro, tempi, autorizzazioni e deliverable formalizzati.
Questa distinzione è importante anche sul piano operativo: un'attività autorizzata non concede libertà illimitata. Ogni tecnica deve rimanere entro lo scope, i sistemi consentiti, le finestre temporali e i limiti concordati.
Come funziona un penetration test: le fasi principali
Le metodologie possono variare in base al target e al modello di test, ma un incarico professionale segue normalmente una sequenza strutturata. La seguente sintesi è coerente con le pratiche comuni di security testing e con riferimenti come NIST SP 800-115, PTES e, per le applicazioni web, OWASP Web Security Testing Guide.
1. Scoping e Rules of Engagement
Prima di qualsiasi attività vengono definiti asset, esclusioni, finestre operative, contatti di emergenza, tecniche consentite, criteri di stop, modalità di gestione delle credenziali e deliverable. Questa fase riduce il rischio operativo e rende il test ripetibile.
2. Information gathering e mappatura
Il tester raccoglie informazioni sul target e costruisce una mappa della superficie esposta: domini, indirizzi IP, servizi, tecnologie, endpoint, ruoli, flussi applicativi o segmenti di rete, in funzione dello scope.
3. Analisi delle vulnerabilità ed enumeration
Gli strumenti automatici possono supportare la ricerca iniziale, ma i risultati devono essere validati. L'enumeration approfondisce servizi, identità, configurazioni e relazioni che possono trasformare una debolezza isolata in un percorso di attacco.
4. Exploitation controllata e validazione dell'impatto
Quando consentito dalle Rules of Engagement, il tester prova a dimostrare la sfruttabilità con evidenze minime e controllate. L'obiettivo è misurare l'impatto senza introdurre rischi non necessari per produzione, dati e continuità operativa.
5. Post-exploitation, reporting e retest
Se viene ottenuto un accesso, il test valuta entro i limiti concordati quali privilegi, sistemi o dati risultano raggiungibili. Il risultato viene tradotto in report tecnico, executive summary e remediation. Un retest successivo verifica se le correzioni hanno chiuso realmente il percorso di compromissione.
Black Box, Grey Box e White Box: cosa cambia
Black Box, Grey Box e White Box descrivono quante informazioni e credenziali vengono fornite al tester prima dell'attività. Non indicano se il test è “interno” o “esterno”: un Network Penetration Test interno, per esempio, può essere svolto in modalità grey box o white box.
Modello | Informazioni iniziali | Vantaggio | Quando è utile |
Black Box | Minime o nulle | Massimo realismo rispetto a un attaccante senza conoscenza pregressa | Perimetri esterni e verifica della superficie realmente esposta |
Grey Box | Informazioni o credenziali limitate | Buon equilibrio tra realismo, copertura ed effort | Applicazioni autenticate, reti interne, scenari post-compromissione |
White Box | Informazioni tecniche ampie, credenziali o documentazione | Copertura maggiore in tempi definiti | Sistemi critici, review approfondite, obiettivi di assurance |
Cosa si può testare
Il termine penetration test identifica il metodo, non un singolo target. Il perimetro determina competenze, strumenti, metodologia e Rules of Engagement.
Network Penetration Test
Valuta host, servizi, apparati e percorsi di rete. Può partire da Internet oppure da una posizione interna concordata. Per External e Internal Network Pentest, segmentazione, lateral movement e attack path infrastrutturali consulta il Network Penetration Test Nexsys.
Web Application Penetration Test (WAPT)
Verifica applicazioni web, portali e API, includendo autenticazione, autorizzazione, sessioni, input, business logic e configurazioni. L'approfondimento dedicato è il Web Application Penetration Test (WAPT).
Secure Code Review
Quando è disponibile il codice sorgente, il test dinamico può essere affiancato da una revisione statica e manuale delle cause implementative. La Secure Code Review non sostituisce il WAPT: osserva il software da un punto di vista differente e complementare.
Active Directory e identità
Se l'obiettivo principale è misurare privilegi, deleghe, protocolli legacy e attack path verso account Tier 0, il perimetro richiede un'attività verticale. Consulta l'Active Directory Security Assessment & Hardening.
Altri target
A seconda delle competenze del team e delle autorizzazioni, possono rientrare nello scope anche reti wireless, applicazioni mobile, ambienti cloud, API, dispositivi o componenti specifici. Il principio rimane lo stesso: target e tecniche devono essere definiti prima dell'esecuzione e il risultato deve essere documentabile e ripetibile.
Rete, applicazione o codice richiedono test diversi
Lo scope corretto evita attività troppo generiche e rende confrontabili effort, deliverable e retest.
Penetration Test e Vulnerability Assessment: differenze
Vulnerability Assessment e Penetration Test sono complementari ma rispondono a domande diverse. Il VA cerca di individuare e prioritizzare un insieme ampio di vulnerabilità; il Penetration Test concentra più effort sulla validazione manuale, sulla sfruttabilità e sulla concatenazione delle debolezze.
Aspetto | Vulnerability Assessment | Penetration Test | Risultato |
Obiettivo | Individuare e prioritizzare debolezze | Dimostrare sfruttabilità e impatto | Visibilità vs evidenza |
Automazione | Rilevante | Di supporto, con forte validazione manuale | Profondità diversa |
Copertura | Ampia sul perimetro | Più profonda sui vettori selezionati | Scope da definire |
Output | Finding e remediation | Attack path, evidenze, impatto e remediation | Decisioni più contestuali |
Se devi mappare sistematicamente le vulnerabilità di un perimetro, consulta il servizio di Vulnerability Assessment.
Cosa deve contenere un report di penetration test
Il report è il deliverable che trasforma l'attività offensiva in un piano di riduzione del rischio. Deve essere comprensibile dal management ma sufficientemente tecnico da consentire al team IT di riprodurre, correggere e verificare i finding.
- Executive summary con rischio, impatto e priorità decisionali.
- Scope, asset analizzati, esclusioni, limiti e metodologia.
- Finding tecnici con prerequisiti, evidenze e condizioni di sfruttamento.
- Severità tecnica e priorità contestualizzata rispetto al business.
- Attack path o concatenazioni di vulnerabilità quando rilevanti.
- Remediation tecnica con indicazioni pratiche e priorità.
- Limitazioni del test e rischio residuo.
- Esito del retest, se previsto.
È possibile eseguire un penetration test in produzione?
Sì, ma il rischio deve essere gestito. Nessun test offensivo è a rischio zero: per questo lo scoping definisce tecniche vietate, orari, contatti, sistemi critici e criteri di stop. Test distruttivi o potenzialmente degradanti non dovrebbero essere eseguiti in produzione senza un'autorizzazione specifica e una valutazione dell'impatto.
Quando esiste un ambiente di staging rappresentativo, alcune verifiche possono essere spostate fuori dalla produzione. In altri casi il valore del test deriva proprio dal verificare configurazioni e controlli realmente esposti; la scelta dipende dall'obiettivo e dalla criticità del servizio.
Aspetti legali: autorizzazione, scope e Rules of Engagement
Un penetration test deve essere autorizzato dal soggetto che ha titolo sui sistemi interessati e deve restare entro il perimetro concordato. Contratto, Statement of Work e Rules of Engagement dovrebbero definire almeno asset inclusi, sistemi esclusi, finestre temporali, tecniche consentite, gestione delle evidenze, contatti di emergenza e condizioni di interruzione.
Le attività eseguite fuori dallo scope o senza autorizzazione possono assumere rilevanza penale a seconda della condotta concreta. Per questo l'autorizzazione non è una formalità amministrativa: è un prerequisito tecnico e giuridico dell'incarico.
Penetration test e compliance: cosa richiedono davvero gli standard
Il penetration test può fornire evidenze utili alla governance e alla compliance, ma non tutte le normative impongono un pen test con la stessa frequenza o lo stesso perimetro.
Riferimento | Relazione con il security testing | Lettura corretta |
GDPR - art. 32(1)(d) | Richiede un processo per testare, verificare e valutare regolarmente l'efficacia delle misure tecniche e organizzative. | Il penetration test può essere una delle tecniche utilizzate in funzione del rischio e del contesto. |
NIS2 / D.Lgs. 138/2024 | Richiede misure di gestione del rischio e verifica dell'efficacia dei controlli applicabili. | VA e penetration test possono produrre evidenze tecniche; non vanno presentati come obbligo identico per ogni organizzazione. |
PCI DSS v4.0.1 | Prevede requisiti espliciti di penetration testing per gli ambienti in scope, con periodicità e condizioni definite dallo standard. | È il riferimento più diretto quando l'ambiente ricade nel Cardholder Data Environment. |
ISO/IEC 27001:2022 | Il controllo A.8.29 riguarda security testing nello sviluppo e nell'accettazione dei sistemi. | Un penetration test può supportarlo quando pertinente, ma A.8.29 non equivale a un obbligo annuale generalizzato. |
DORA | Prevede Threat-Led Penetration Testing per le entità finanziarie individuate secondo il quadro regolamentare applicabile. | Il TLPT è un regime specifico e non coincide con un normale penetration test annuale. |
Ogni quanto fare un penetration test?
Non esiste una frequenza universale valida per tutte le aziende. Una cadenza annuale è spesso utilizzata come baseline operativa, ma il criterio più utile è risk-based: un nuovo servizio esposto, una migrazione cloud, un'acquisizione, una modifica significativa della segmentazione, un incidente o un requisito contrattuale possono richiedere un nuovo test prima della scadenza annuale.
La frequenza va inoltre distinta dal vulnerability management continuo: scansioni e assessment possono essere eseguiti più spesso, mentre il penetration test concentra effort manuale su obiettivi selezionati.
Quanto costa un penetration test?
Il costo dipende soprattutto da scope, numero e tipologia degli asset, modello black/grey/white box, necessità di test interno o esterno, applicazioni e ruoli da verificare, finestre operative, profondità richiesta, reportistica e retest. Confrontare preventivi senza allineare questi elementi porta facilmente a confrontare servizi diversi.
Per prezzi, variabili di dimensionamento ed esempi di scope consulta la guida dedicata al costo del Penetration Test.
Cosa emerge realmente da un penetration test aziendale
I finding più utili non sono necessariamente zero-day. Nelle infrastrutture reali il rischio nasce spesso dalla concatenazione di condizioni note: segmentazione incompleta, sistemi legacy, privilegi eccessivi, credenziali riutilizzate, interfacce di management raggiungibili o backup non sufficientemente isolati.
Condivisioni di rete e permessi eccessivi
Share accessibili a gruppi troppo ampi possono esporre dati, script, configurazioni o materiali utili al movimento laterale.
Protocolli e configurazioni legacy
SMBv1, NTLM non ridotto, firma SMB non imposta o servizi obsoleti ampliano le possibilità di relay e lateral movement.
Sistemi fuori supporto
Asset non aggiornabili e raggiungibili da reti utente aumentano la probabilità che vulnerabilità note diventino un punto di ingresso.
Interfacce di management esposte
Console di hypervisor, backup, apparati o applicativi amministrativi dovrebbero essere separate dalle reti utente e protette con controlli adeguati.
Credenziali e segreti
Password condivise, account di servizio troppo privilegiati, script o file contenenti segreti possono trasformare una compromissione locale in una compromissione più ampia.
Backup e asset critici non isolati
Se dominio, backup e management condividono identità o percorsi di accesso, un singolo attacco può ridurre anche la capacità di ripristino.
Quando questi percorsi riguardano host, segmentazione e servizi di rete, l'approfondimento corretto è il Network Penetration Test.
Come scegliere un fornitore di penetration test
La qualità del servizio dipende meno dal numero di tool dichiarati e più dalla capacità di definire lo scope, validare manualmente i finding, gestire il rischio operativo e trasformare le evidenze in remediation.
- Metodologia documentata e coerente con il target.
- Competenze tecniche dimostrabili e certificazioni pertinenti.
- Rules of Engagement e gestione delle evidenze definite prima dell'avvio.
- Report sanitizzato di esempio, utile per valutare profondità e chiarezza.
- Separazione tra severità tecnica e priorità di remediation.
- Retest post-remediation disponibile.
- Capacità di spiegare limiti e copertura del test, non solo i finding.
Trasforma i finding in un piano di remediation
Nexsys può dimensionare External/Internal Network Pentest, WAPT e altri test in base agli asset e agli obiettivi concordati.
Domande frequenti sul penetration test
Che cos'è un penetration test?
È una verifica di sicurezza autorizzata che simula tecniche di attacco reali contro sistemi, reti o applicazioni per stabilire se una debolezza è sfruttabile e quale impatto può produrre entro uno scope concordato.
Qual è la differenza tra penetration test e vulnerability assessment?
Il Vulnerability Assessment individua e prioritizza vulnerabilità su un perimetro ampio; il Penetration Test verifica con maggiore profondità se specifiche debolezze possono essere sfruttate, concatenate e trasformate in un impatto reale. Le due attività sono complementari.
Qual è la differenza tra Black Box, Grey Box e White Box?
Indicano quante informazioni e credenziali vengono fornite al tester. Nel Black Box le informazioni iniziali sono minime, nel Grey Box sono parziali, nel White Box sono più ampie. Non equivalgono a External e Internal, che descrivono invece posizione e perimetro del test.
Quanto dura un penetration test?
Dipende da scope, numero di asset, complessità, modello di test e profondità richiesta. Un perimetro circoscritto può richiedere pochi giorni di attività, mentre ambienti complessi, multi-sede o con più applicazioni richiedono un dimensionamento specifico.
Si può fare un penetration test in produzione?
Sì, se il rischio è gestito con Rules of Engagement, tecniche consentite, sistemi esclusi, finestre operative e criteri di stop. Test distruttivi o potenzialmente degradanti richiedono autorizzazione esplicita e una valutazione specifica dell'impatto.
Cosa contiene un report di penetration test?
Normalmente include executive summary, scope e metodologia, finding con evidenze, condizioni di sfruttamento, severità e impatto, attack path quando rilevanti, remediation prioritarie, limitazioni del test e risultato del retest se previsto.
Ogni quanto va eseguito un penetration test?
Una cadenza annuale è una baseline comune, ma la frequenza dovrebbe essere risk-based. Modifiche significative, nuovi servizi esposti, migrazioni, incidenti, acquisizioni o requisiti normativi e contrattuali possono richiedere test aggiuntivi.
Quanto costa un penetration test?
Il costo dipende da perimetro, asset, modalità Black/Grey/White Box, test interno o esterno, applicazioni da verificare, finestre operative, profondità, reportistica e retest. Il preventivo è confrontabile solo quando scope e deliverable sono equivalenti.
Un penetration test è obbligatorio per GDPR o NIS2?
Non in modo generalizzato e identico per ogni organizzazione. Il GDPR richiede di testare, verificare e valutare regolarmente l'efficacia delle misure di sicurezza; NIS2 richiede misure di gestione del rischio e verifica della loro efficacia. Il penetration test può essere uno strumento tecnico utile a produrre tali evidenze in funzione del contesto.
Servizio o formazione: scegli l'intento corretto
Se devi verificare sistemi reali, consulta il servizio Penetration Test per aziende. Se invece l'obiettivo è sviluppare competenze interne, consulta il Corso Penetration Test.
