Sulla base della ricerca del Dr. iur. Dr. rer. pol. Fabian M. A. Teichmann

Un team di esperti di sicurezza IT attacca i propri sistemi. Non per sabotaggio, ma per commissione. Assumono il ruolo di veri attaccanti, cercano vulnerabilità, testano password, provano a penetrare nelle reti e documentano tutto. Quello che sembra un esercizio paradossale è oggi uno dei metodi più efficaci di cyberdifesa: il penetration test. E per molte aziende non si tratta più di una scelta volontaria, ma di un obbligo di legge.

Nella sua ricerca, Teichmann ha analizzato con precisione sia i requisiti normativi sia i limiti del diritto penale di tali test. La domanda su cosa le aziende possano, debbano e debbano assolutamente evitare di fare durante i penetration test e il red teaming ha una risposta, ma è più complessa di quanto molti pensino (Teichmann & Boticiu, An Overview of the Benefits, Challenges, and Legal Aspects of Penetration Testing and Red Teaming, International Cybersecurity Law Review 2023, pp. 1–11).

Cosa sono il Penetration Testing e il Red Teaming

Un penetration test è un attacco simulato e autorizzato a sistemi IT, reti o applicazioni con l'obiettivo di identificare le vulnerabilità prima che lo facciano i veri attaccanti. Il penetration tester agisce per conto dell'azienda, con la sua esplicita autorizzazione scritta, all'interno di un perimetro definito e in un momento concordato.

Il Red Teaming fa un passo avanti. Mentre un penetration test classico si concentra spesso su sistemi specifici, un Red Team simula un attacco realistico e completo contro l'azienda, spesso senza che il team interno di sicurezza IT ne sia a conoscenza. L'obiettivo non è solo l'identificazione di vulnerabilità tecniche, ma la verifica dell'intera capacità di rilevamento e reazione dell'organizzazione (Teichmann & Boticiu, ICLR 2023, pp. 1–11).

La differenza è significativa: un penetration test risponde alla domanda "Quali vulnerabilità tecniche abbiamo?". Un intervento del Red Team risponde alla domanda "Un vero attaccante potrebbe compromettere la nostra azienda, e ce ne accorgeremmo?"

Perché i penetration test sono obbligatori oggi – o lo saranno presto

Il regolamento DORA obbliga esplicitamente i principali istituti finanziari a condurre regolari penetration test basati sulle minacce, i cosiddetti Threat-Led Penetration Tests (TLPT). Questi esercizi del Red Team devono essere eseguiti almeno ogni tre anni da tester indipendenti e qualificati, secondo un quadro armonizzato a livello dell'UE. I risultati devono essere comunicati all'autorità di vigilanza e le vulnerabilità critiche devono essere corrette entro termini stabiliti. Il modello è il framework TIBER-EU, che in Germania era già stato stabilito come TIBER-DE (Teichmann, Digital Operational Resilience Act – regole di sicurezza IT uniformi a livello UE per gli istituti finanziari, BB 2025, pp. 2760–2770).

La direttiva NIS-2 richiede ai soggetti essenziali e importanti di adottare misure tecniche e organizzative adeguate. I penetration test regolari sono considerati parte integrante dello stato dell'arte e sono quindi implicitamente richiesti. Chi non li esegue rischia, in caso di incidente, di dover dimostrare che era comunque in linea con lo stato dell'arte senza tali misure; una dimostrazione difficile da fornire (Teichmann, Obbligo di formazione NIS2 per la direzione aziendale, Computer und Recht 2025, pp. 718–725).

La legge tedesca sulla sicurezza IT 2.0 (IT-Sicherheitsgesetz 2.0) obbliga gli operatori KRITIS da maggio 2023 a utilizzare sistemi di rilevamento degli attacchi che monitorano continuamente e in modo automatizzato i parametri operativi. I penetration test sono lo strumento utilizzato per verificare se questi sistemi di rilevamento funzionano effettivamente (Teichmann, IT-Sicherheitsgesetz 2.0 in pratica: rilevamento degli attacchi e componenti critici, BB 2025, pp. 1993–1998).

Il limite del diritto penale: quando l'ethical hacker diventa un criminale?

L'art. 202a del codice penale tedesco (StGB) punisce l'intercettazione di dati con una pena detentiva fino a tre anni per chiunque ottenga l'accesso non autorizzato a dati particolarmente protetti. L'art. 202c StGB (il cosiddetto paragrafo sugli hacker) punisce già la preparazione di tali atti, ovvero il reperimento o la creazione di strumenti di attacco. E l'art. 303b StGB sul sabotaggio informatico si applica se i sistemi IT vengono interrotti dalle attività di test.

La scusante decisiva è il consenso della parte lesa. Chi, in qualità di proprietario o gestore, concede espressamente l'autorizzazione a un penetration tester, elimina l'illiceità di azioni altrimenti punibili.

Ma questo consenso deve soddisfare determinati requisiti. Deve essere concesso dalla persona che ha effettivamente il potere di disporne. Deve essere concesso prima dell'inizio del test; un'approvazione successiva non sana un reato. Deve coprire l'ambito specifico del test: le azioni al di fuori del perimetro concordato perdono la tutela del consenso. E deve essere documentato per iscritto, poiché in caso di controversia deve essere dimostrato che esisteva un consenso valido (Teichmann & Boticiu, ICLR 2023, pp. 1–11).

Cosa deve contenere il contratto

Un contratto di penetration testing giuridicamente sicuro deve contenere diversi elementi chiave. Il perimetro (scope) deve essere definito con precisione: quali sistemi, reti, applicazioni e intervalli di indirizzi IP possono essere testati? Cosa è espressamente escluso? Deve essere stabilito il periodo temporale. Devono essere descritti i metodi consentiti: è lecito utilizzare il social engineering? L'accesso fisico? Simulazioni di Denial-of-Service? Esfiltrazione di dati per testare il rilevamento?

Le disposizioni per le emergenze sono una componente obbligatoria: cosa succede se il tester si imbatte in attacchi reali e non simulati? È obbligatorio un numero di hotline tramite il quale interrompere immediatamente il test. E gli accordi di riservatezza devono garantire che i risultati del test non finiscano nelle mani sbagliate (Teichmann & Boticiu, ICLR 2023, pp. 1–11).

Fornitori terzi e cloud: il problema legale sottovalutato

Nel moderno panorama IT, quasi tutte le aziende utilizzano servizi cloud, applicazioni SaaS e provider di hosting esterni; e questi fornitori terzi hanno le proprie condizioni d'uso che possono limitare o vietare i penetration test sulla loro infrastruttura. I principali provider di cloud consentono i test sull'infrastruttura noleggiata, ma richiedono una notifica preventiva o escludono determinati metodi di test. Chi ignora queste regole rischia non solo la risoluzione del contratto cloud, ma anche conseguenze legali.

Il regime NIS-2 affronta questo problema attraverso la responsabilità della catena di fornitura: le aziende devono gestire attivamente la sicurezza dei loro fornitori di servizi IT e hanno il diritto di richiedere audit di sicurezza. Questo diritto di ispezione dovrebbe essere sancito già alla firma del contratto con i fornitori di servizi IT; un penetration test che non copre l'infrastruttura di terze parti fornisce solo un quadro incompleto della superficie di attacco reale.

Il Red Teaming e la particolare diligenza

Gli esercizi del Red Team condotti all'insaputa del Blue Team comportano rischi particolari. Il team di sicurezza IT interno può reagire all'attacco simulato come se fosse reale: spegnere i sistemi, informare enti esterni, attivare piani di emergenza. Teichmann raccomanda pertanto una chiara struttura di escalation: un piccolo gruppo di persone di fiducia (solitamente il CISO e la direzione) è a conoscenza dell'esercizio e può intervenire in caso di emergenza. Una hotline immediatamente raggiungibile è obbligatoria. E la documentazione legale deve essere predisposta in modo tale da poter essere presentata immediatamente alle autorità o alle forze dell'ordine in caso di emergenza (Teichmann & Boticiu, ICLR 2023, pp. 1–11).

Prendere sul serio i risultati – un obbligo di legge

La ricerca di Teichmann dimostra che molte aziende fanno eseguire penetration test senza sfruttarne realmente i risultati. Un test i cui risultati finiscono in un cassetto non rappresenta solo un budget sprecato, ma crea una situazione giuridicamente pericolosa. Chi sa che esistono vulnerabilità e non le corregge agisce con colpa. Ai sensi del regolamento DORA, gli istituti finanziari sono espressamente obbligati ad affrontare i risultati critici dei test TLPT entro termini stabiliti e a riferirne all'autorità di vigilanza (Teichmann, BB 2025, pp. 2760–2770).

Conclusioni: l'attacco come migliore difesa – legalmente protetta

I penetration test e le esercitazioni del Red Team sono oggi lo strumento più efficace per misurare l'effettiva resilienza di un'azienda contro i cyberattacchi. Nessun concetto tecnico e nessun audit di sicurezza può sostituire ciò che un attacco simulato in modo etico porta alla luce.

La ricerca di Teichmann dimostra che le basi legali per tali test sono chiare, ma impegnative. Consenso valido, perimetro preciso, contratti legalmente sicuri e un processo di remediation strutturato sono i requisiti fondamentali. E per un numero sempre maggiore di aziende, questo test non è più un'opzione, ma un obbligo.

Tutti i riferimenti bibliografici si riferiscono a contributi scientifici pubblicati dal Dr. iur. Dr. rer. pol. Fabian M. A. Teichmann. La bibliografia completa è documentata nell'elenco delle pubblicazioni (aggiornato a maggio 2026).