Penetration test e NIS2: quando serve, ogni quanto farlo e cosa preparare

In breve

Perché

Per sapere che la tua app regge e poterlo dimostrare a clienti, GDPR, NIS2 e ISO 27001.

Ogni quanto

Una buona regola pratica: una volta l'anno, più ogni volta che l'app cambia in modo importante.

Cosa preparare

Il perimetro scritto, la firma di chi è titolare dei sistemi, il posto dove si prova e le regole sui risultati.

Come funziona un test lo spiega la guida Penetration test: cos'è.

Perché le aziende fanno un penetration test?

Per sapere che la propria app regge e per poterlo dimostrare: a sé stesse, ai clienti e alle regole su dati e sicurezza.

Le aziende soggette alla NIS2, la direttiva europea sulla sicurezza informatica, devono tenere conto della sicurezza dei propri diretti fornitori, comprese le loro procedure di sviluppo sicuro (art. 24 del d.lgs. 138/2024). Per questo un cliente può chiederti un test recente.

Il GDPR (il regolamento europeo sulla protezione dei dati personali), la NIS2 e la norma ISO 27001 chiedono, ognuno a modo suo e dove si applica, di verificare che le misure di sicurezza funzionino.

Penetration test e NIS2: a chi si applica?

La NIS2 non vale per tutti. Secondo l'Agenzia per la cybersicurezza nazionale (ACN) riguarda medie e grandi imprese, in alcuni casi anche piccole e microimprese, e pubbliche amministrazioni di 18 settori elencati negli allegati del decreto. Le aziende e gli enti a cui si applica, i soggetti NIS, si dividono in essenziali e importanti, in base a quanto è critica la loro attività. Se non sai se ti riguarda, guarda il sito dell'ACN.

Le regole che chiedono di verificare la sicurezza

1. 25 maggio 2018

   GDPR, art. 32. Tra le misure adeguate al rischio, il GDPR indica, «se del caso», «una procedura per testare, verificare e valutare regolarmente l'efficacia delle misure tecniche e organizzative».

2. Ottobre 2022

   ISO/IEC 27001:2022. È la norma internazionale per i sistemi di gestione della sicurezza delle informazioni. Il suo controllo A.8.8 riguarda la gestione delle vulnerabilità tecniche; secondo l'ente di certificazione DQS, tra i modi per trovarle ci sono penetration test pianificati e fatti da persone autorizzate.

3. 16 ottobre 2024

   D.lgs. 138/2024. Entra in vigore il decreto che porta in Italia la direttiva NIS2. L'art. 24 chiede ai soggetti NIS «politiche e procedure per valutare l'efficacia» delle misure di sicurezza.

4. 15 gennaio 2026

   Determinazione ACN 379907/2025. Si applica la determinazione dell'ACN con le misure di sicurezza di base, che sostituisce quella del 14 aprile 2025. Per i soggetti essenziali, almeno sui sistemi rilevanti: vulnerability assessment e/o penetration test periodici e comunque prima della messa in esercizio, cioè prima che i sistemi entrino in funzione, documentati con una relazione.

5. Ottobre 2026

   Misure di base, il termine. Per chi è entrato nell'elenco NIS nel 2025, l'ACN indica ottobre 2026 come fine dei 18 mesi, dalla comunicazione di inserimento, per adottare le misure di sicurezza di base.

6. 31 luglio 2027Scadenza

   Nuovi soggetti NIS. Per chi è entrato nell'elenco NIS nel 2026, la determinazione ACN 127434/2026 fissa al 31 luglio 2027 il termine per adottare le stesse misure di sicurezza di base.

Ogni quanto si fa un penetration test?

Le regole generali non fissano un numero: il GDPR dice «regolarmente», dove serve; le misure ACN per i soggetti essenziali dicono «periodicamente» e comunque prima della messa in esercizio. Una buona regola pratica: una volta l'anno, più ogni volta che l'app cambia in modo importante.

Il NIST, l'istituto americano che pubblica gli standard tecnici, la mette così: per reti e sistemi un penetration test all'anno può bastare, e le applicazioni vanno provate di nuovo quando arrivano modifiche importanti o quando cambiano le minacce intorno a loro.

Tra un test e l'altro, scansioni regolari tengono d'occhio i difetti noti.

Cos'è il perimetro e chi deve dare l'autorizzazione?

Il perimetro è l'elenco scritto di cosa si prova e di cosa resta fuori. L'autorizzazione la firma chi è titolare dei sistemi; se i server sono di qualcun altro, serve anche il suo consenso.

Perimetro e regole finiscono in un documento che si chiama regole d'ingaggio: per il NIST, le istruzioni e i limiti del test, fissati prima di cominciare. Cosa scriverci, secondo il modello del NIST:

• Cosa si prova. App, API (le porte da cui passano i dati), indirizzi, ambienti. E un elenco a parte di ciò che non si tocca.
• Quando. Giorni e fasce orarie.
• Cosa è vietato. Per esempio creare o modificare file, scritto in modo da non lasciare dubbi.
• Chi chiamare se qualcosa va storto, e quando fermarsi.
• Come si trattano i dati raccolti durante il test, fino alla loro cancellazione.
• Le firme: almeno di chi guida il test e della direzione dell'azienda, per esempio il responsabile della sicurezza o dei sistemi informativi.

Se la tua app gira sui server della software house che l'ha costruita, la tua firma non basta: serve anche la sua. Se gira presso un fornitore di hosting o di cloud, valgono le sue regole: leggile prima di cominciare. Restano fuori anche i servizi di altri che la tua app usa, come i pagamenti o l'invio delle email, se il loro titolare non ha dato il consenso.

Si prova in produzione o in un ambiente di prova?

Se hai una copia fedele dell'app, conviene partire da lì: si prova senza disturbare i clienti e senza dati veri. La produzione, l'app vera che usano i tuoi clienti, si prova quando la copia non c'è o non è uguale, con orari e limiti scritti.

Dove si fa il test?

Se hai una copia fedele dell'app

Ambiente di prova

• Niente dati veri. Il NIST suggerisce, quando un test potrebbe esporre dati personali delicati, di provare su un sistema che non è quello di produzione, con dati di prova.

Se la copia non c'è o è diversa

Produzione

• Con limiti scritti. Fasce orarie tranquille, niente prove che possono bloccare il servizio, un contatto pronto a intervenire.
• Con un freno. Un penetration test si può impostare per fermarsi prima di un'azione che causerebbe danni.

Invece di copiare i dati di produzione si possono generare dati sintetici, per esempio con Eleven Synth.

Di chi sono i risultati del test?

Devono essere tuoi, e conviene scriverlo: il rapporto e i dati raccolti appartengono a chi ha commissionato il test, e non si pubblicano né si danno a terzi senza il suo consenso scritto.

Un rapporto di penetration test è una mappa dei punti deboli. Il NIST raccomanda di considerare sensibili i risultati di qualunque test di sicurezza, perché indicano vulnerabilità che un attaccante potrebbe sfruttare.

Per chi sviluppaCosa preparare per un test grey box

Un utente di prova per ogni ruolo, la documentazione delle API (per esempio in formato OpenAPI), una versione di prova delle app mobili, gli indirizzi da cui arriverà il test e l'elenco di ciò che resta fuori.

Domande frequenti

Il penetration test è obbligatorio?

Non per tutti, e non sempre con questo nome. Il GDPR indica, dove è adeguato al rischio, di testare regolarmente le misure di sicurezza; le misure ACN per i soggetti essenziali NIS2 chiedono vulnerability assessment e/o penetration test; e un cliente può chiederlo nel contratto.

Un penetration test può bloccare la mia app?

Può succedere, ed è per questo che le regole d'ingaggio fissano orari, prove vietate e chi chiamare. Un test si può impostare per fermarsi prima di un'azione dannosa, e un ambiente di prova tiene i clienti al riparo.

Cosa mostro a un cliente che mi chiede il test?

Scegli tu cosa condividere: per esempio una sintesi con la data, il perimetro e l'esito del retest, la nuova prova dopo le correzioni.

Si può testare un'app costruita da un'altra software house?

Sì. Serve l'autorizzazione scritta di chi è titolare dell'app e dei server: se l'app gira sui server della software house, firma anche lei.