Un penetration test è un attacco simulato, autorizzato per contratto, condotto da professionisti che provano a violare i vostri sistemi come farebbe un attaccante reale — e poi vi consegnano un report con quello che hanno trovato e come rimediare. Non è uno scan automatico rivenduto con un logo, e non è un bollino «sicuri per sempre»: fotografa la sicurezza di un perimetro preciso in un momento preciso.
La distinzione più importante da conoscere è quella tra vulnerability assessment e penetration test. Il primo è una scansione strumentale che elenca vulnerabilità note: è rapido e ha senso farlo spesso. Il secondo aggiunge la parte umana — concatenare le falle, aggirare le difese, dimostrare cosa può ottenere davvero un attaccante. Se un fornitore vi propone un «pentest» sospettosamente economico e sbrigativo, quasi certamente è uno scan.
Tutto parte dallo scoping: cosa si testa (l'applicazione web, la rete esposta, la rete interna, le API), con quale approccio (black box senza informazioni, grey box con credenziali di test, white box con accesso al codice) e con quali regole d'ingaggio — finestre orarie, sistemi esclusi, contatto d'emergenza se qualcosa va storto. Serve un'autorizzazione scritta: senza, quel test è un reato.
Sui tempi: un test su un'applicazione web di media complessità richiede tipicamente 5-10 giornate di lavoro, tra esecuzione e reporting. Durante il test l'operatività normale non si ferma; le attività potenzialmente invasive si concordano prima e si eseguono nelle finestre stabilite.
Il report è il vero prodotto, e va saputo leggere. Deve contenere due livelli: un executive summary comprensibile a chi decide, e il dettaglio tecnico per chi corregge — ogni vulnerabilità con la sua gravità (di solito su scala CVSS), le evidenze di come è stata sfruttata e istruzioni di remediation concrete. Diffidate dei report che sono solo l'output di uno strumento: se manca il «come siamo entrati», manca il valore.
Chiedete sempre se il re-test è incluso: dopo che avete corretto le vulnerabilità, il fornitore deve verificare che le correzioni funzionino. Sulla cadenza, la pratica ragionevole per una PMI è un test l'anno sul perimetro critico, più un test straordinario dopo ogni rilascio importante o cambio di architettura.
C'è poi un motivo esterno per muoversi: la direttiva NIS2 e, sempre più spesso, i clienti enterprise. Se fornite aziende medio-grandi, i loro questionari di qualifica fornitori chiedono ormai regolarmente se eseguite test di sicurezza periodici. Arrivarci con un report recente in mano trasforma una domanda scomoda in un punto a favore.
Prima di firmare, quattro domande al fornitore: quale metodologia seguite (OWASP, PTES o equivalenti)? Chi esegue materialmente il test e con quali qualifiche? Possiamo vedere un report di esempio anonimizzato? Il re-test è compreso nell'offerta? Le risposte a queste domande distinguono un partner da un rivenditore di scansioni.