Più che in passato, oggi la ricerca di vulnerabilità da parte di analisti esterni, ethical hacker e red teamer costituisce uno strumento imprescindibili per misurare il livello di cyber security di un organizzazione. Detto ciò, tema estremamente delicato è quello dei pericoli che corre il professionista quando la scoperta di una falla critica avviene al di fuori di un perimetro contrattuale definito.
E’ bene sottolineare infatti come diventa molto sottile il confine tra supporto tecnico disinteressato – il cosiddetto “soccorso istruito” – ed illecito penale. Quando è assente un consenso preventivo, la modalità di segnalazione, e come viene eventualmente avanzata una richiesta di compenso, possono esporre l’analista al rischio di incriminazione e la società colpita di fronte a complessi dilemmi su come agire a propria tutela.
A rendere delicata la quesione è innanzitutto la formulazione dell’articolo 615-ter c.p., che punisce l’accesso abusivo a un sistema informatico o telematico. Questa disposizione, nel proteggere il c.d. domicilio informatico, sanziona sia l’intromissione totalmente non autorizzata, sia il mantenimento all’interno del sistema contro la volontà del titolare. Secondo l’orientamento della Corte di Cassazione, consolidatosi con le pronunce delle Sezioni Unite, l’abusività della condotta si configura non solo nell’ipotesi di effrazione digitale diretta, ma anche quando un soggetto acceda con credenziali valide travalicando i limiti, le prescrizioni o le finalità imposte dal gestore. Stando a questa ormai pacifica interpretazione un diritto d’accesso incondizionato non è riconosciuto neanche a chi si trova in possesso di funzioni apicali o direttive aziendali, rimanendo in capo al datore di lavoro il potere di perimetrare l’uso delle banche dati.
C’è da dire che gli esperti di sicurezza sovente tendono a sottovalutare – mentre nella mia esperienza professionale nei processi emerge puntualmente con conseguenze drammatiche per gli imputati – l’assoluta irrilevanza del movente ai fini della punibilità. Poiché l’accesso abusivo è un reato a dolo generico, si richiede unicamente la consapevolezza di introdursi o trattenersi in un sistema protetto senza autorizzazione. Non potrebbero giustificare la condotta, né rappresentare causa di giustificazione alcuna la finalità altruistica di voler segnalare un bug per consentirne la bonifica, la dimostrazione della propria perizia o il desiderio di tutelare la collettività. In mancanza di una causa di non punibilità espressa, la condotta di scansione o penetrazione non autorizzata perfezionerebbe integralmente il reato. Il quadro normativo è oggi più severo in virtù della Legge 90/2024, che ha raddoppiato le pene per le fattispecie aggravate legate a sistemi critici o di interesse pubblico.
Abbiamo visto come la ricerca non autorizzata può finire con l’integrare il delitto di accesso abusivo. Superata tale fase, ovvero della scoperta di una vulnerabilità, altro momento delicato è quello della comunicazione del problema con contestuale richiesta di denaro o altre utilità , poiché tale comportamento potrebbe integrare il delitto di estorsione in quanto, il terzo comma all’articolo 629 c.p., introdotto a Legge 90/2024, punisce con la reclusione da sei a dodici anni , e pene fino a ventidue anni nelle ipotesi aggravate, chiunque, mediante la commissione di reati informatici o con la minaccia di compierli, costringa taluno a fare o omettere qualcosa, procurando a sé o ad altri un ingiusto profitto.
Per comprendere la linea di demarcazione tra il legittimo modello del Bug Bounty e la cosiddetta “Bounty Extortion” occorre verificare l’esistenza di un accordo preventivo. Di regola, proprio per evitare qualsiasi inconveniente , l’organizzazione fissa ex ante le regole d’ingaggio, perimetra gli asset analizzabili e si impegna contrattualmente a riconoscere una ricompensa al verificarsi di determinate condizioni. Se questa è l’impostazione corretta, al contrario, quando la segnalazione giunge improvvisa e chi ha rilevato la falla condiziona la consegna dei dettagli tecnici, la mancata divulgazione del problema o la non vendita delle informazioni sul Dark Web al pagamento di una somma non pattuita, ci si trova pienamente di fronte alla condotta estorsiva. E’evidente che in questo caso la pressione esercitata sulla società, unita all’assenza di un diritto del ricercatore a pretendere un compenso per un’attività mai commissionata, o almeno non in quei termini, trasforma il “soccorso” in una vera e propria estorsione.
Questo mutamento di prospettiva investe direttamente anche la governance aziendale. Con le modifiche apportate al Decreto Legislativo 231/2001, il reato di estorsione informatica è stato inserito tra i delitti-presupposto della responsabilità amministrativa degli enti. Di conseguenza, qualora un dipendente o un collaboratore di una società di cybersecurity utilizzi metodi coercitivi o minacce di leak per forzare un potenziale cliente a stipulare contratti di consulenza, bonifica o manutenzione, la responsabilità penale del singolo travolgerà la società stessa con sanzioni pecuniarie e misure interdittive bloccanti.
A rendere più complessa la situazione sono le recenti normative europee e nazionali sulla segnalazione delle vulnerabilità – la Direttiva NIS 2 e il relativo Decreto Legislativo 4 settembre 2024, n. 138- , che asseegnano allo CSIRT Italia, presso l’Agenzia per la Cybersicurezza Nazionale, il compito di fare da intermediario e proteggere l’anonimato di chi segnala una falla.
Chi ha scoperto il problema non riceve una sorta di “scudo penale” automatico dalle nuove norme. Infati, con l’invio della segnalazione allo CSIRT si evita che il nome del ricercatore venga diffuso, ma questo non vuol dire che l’eventuale delitto di accesso abusivo commesso per trovare quella falla sia cancellato o considerato inesisente. Laddove l’azienda colpita riesca a risalire da sola all’identità di chi ha fatto la scansione o si è introdotto nei sistemi, la segnalazione tramite i canali ufficiali non basterà a salvare il ricercatore da un processo penale.
Patti chiari, amicizia lunga. Questo è l’approccio che deve tenere un’azienda per evitare di subire condotte illecite da soggetti da lei impiegati e per disinnescare sul nascere potenziali tentativi di estorsione. Per ottenere ciò le imprese devono dotarsi di una struttura di compliance dinamica ed efficace dove al primo posto come strumento difensivo si pone la redazione e pubblicazione di una Vulnerability Disclosure Policy (VDP) chiara, configurata come un’offerta al pubblico con valore legale vincolante. Per quanto mi riguarda consiglio sempre alle imprese che assisto di definire in modo tassativo l’ambito dell’autorizzazione, chiarendo che tutto ciò che non è espressamente elencato deve considerarsi vietato.
Ecco perché è fondamentale che la policy fissi stringenti regole d’ingaggio, mettendo al bando attacchi di tipo Denial of Service, tecniche di ingegneria sociale ed estrazione o conservazione di dati personali e segreti commerciali. Se è vero che l’azienda sta chiedendo un certo tipo di verifica, bisogna comunque puntualizzare che la dimostrazione tecnica del bug deve fermarsi alla minima Proof of Concept (PoC) indispensabile per provare la falla. Personalmente faccio sempre inserire una clausola che escluda qualsiasi compenso per le segnalazioni unsolicited giunte fuori dai canali ufficiali, affiancata da un “Safe Harbor condizionato”: l’impegno dell’azienda a non adire le vie legali ex art. 615-ter c.p. a patto che il ricercatore si sia attenuto scrupolosamente alle regole, non abbia arrecato danni e abbia mantenuto il massimo riserbo durante la fase di correzione.
Per quanto concerne l’altro momento critico, ovvero quello dove l’azienda riceve una comunicazione informale contenente richieste economiche a fronte della mancata pubblicazione di una vulnerabilità, l’organizzazione deve essere in grado di gestire l’incidente secondo uno schema ben preciso. Immediatamente il team legale ed IT si preccupa di cristallizzare da un punto di vista forense gli elementi di prova, conservando messaggi, header delle e-mail e log di sistema. Per altro verso, ma momento certo non meno importnte, occorre procedere ad un triage tecnico riservato per verificare l’effettiva portata della falla e accertare se vi sia stata un’esfiltration di dati che imponga la notifica di data breach al Garante Privacy. Se ci si trova innanzi a termini perentori o richieste di pagamento in criptovalute, l’esperienza sul campo insegna che l’azienda non deve cedere a trattative informali, ma sporgere tempestiva denuncia-querela e segnalare contemporaneamente l’evento allo CSIRT Italia.
Quanto evidenziato dimostra come certe attività possono rivelarsi insidiose tanto per i professionisti della sicurezza informatica e delle società d’attacco simulato, tanto per le aziende. Per i ricercatori indipendenti che operano nell’ambito della sicurezza etica, l’esigenza primaria è verificare preventivamente l’esistenza di una VDP pubblica o operare esclusivamente all’interno di piattaforme certificate di Bug Bounty, rispettandone ogni singolo limite di perimetro.
E’ fondamentale che nell’attività di ricerca si faccia quello che serve e niente di più. Verificare un’esecuzione di codice remota, eseguendo un comando innocuo come whoami è sufficiente a dimostrare l’esistenza del problema; scaricare interi database o file di configurazione esula dal soccorso istruito e può finire per costituire una violazione penale.
Quanto alle segnalazioni, le stesse devono essere trasmesse attraverso i canali ufficiali previsti dal target e, qualora l’organizzazione si dimostri sorda o priva di contatti dedicati, occorre scegliere il percorso che dia più garanzie ovvero l’instradamento tramite la procedura di CVD dello CSIRT Italia, richiedendo formalmente l’applicazione delle tutele sull’anonimato.
Ogni qual volta ho dovuto assistere società di cybersecurity che erogano servizi di Penetration Testing e Red Teaming per conto di clienti, suggerisco di curare con estrema pignoleria la fase propedeutica proprio perché la prevenzione del rischio penale e della responsabilità amministrativa 231, si gioca infatti prima dell’invio del primo pacchetto di rete.
E’ essenziale che ogni attività sia coperta da un contratto dettagliato e da formalizzate Rules of Engagement (RoE), accompagnate dall’autorizzazione scritta del legale rappresentante del cliente – la cosiddetta “Get Out of Jail Free Letter”. Perché sia “ blindato” il documento deve identificare con precisione gli indirizzi IP target, le finestre temporali di test e i referenti da contattare in caso di emergenza.
L’importanza di muoversi in modo corretto dall’inzio e secondo contratto trova riscontro diretto in un caso giudiziario di cui mi occupai circa 15 anni fa. In quell’occasione difesi in appello un ricercatore impiegato presso una società di penetration testing, il quale in primo grado era stato condannato per accesso abusivo a sistema informatico. La condanna era giustificata dal fatto che il test condotto nei confronti di una banca, cliente abituale dell’azienda, era stato avviato prima che il contratto formale venisse ufficialmente sottoscritto dalle parti.In appello, fortunatamente, riuscimmo ad ottenerne l’assoluzione perché il fatto non cosituisce reato per difetto del dolo richiesto dalla norma.
La mia tesi fu quella che l’imputato aveva agito nella ragionevole convinzione di muoversi in un perimetro autorizzato, alla luce dei precedenti incontri preliminari che davano per certa la firma imminente, dei consolidati rapporti commerciali tra la sua società e l’istituto di credito e, soprattutto, del fatto che il giovane analista aveva immediatamente inviato alla propria azienda un report tecnico interno sulle falle individuate, senza mai avanzare alcuna pretesa economica né verso la banca, né verso terzi.
Ciò detto , se si vogliono evitare potenziali guai è meglio continuare a seguire il detto “patti chiari,amicizia lunga”.
Betti RHC, la prima graphic novel al mondo dedicata alla cybersecurity awareness, ha finalmente il suo sito ufficiale. Uno spazio tutto suo dove scoprire il progetto, sfogliare le copertine degli episodi e immergersi nel mondo di Betti: la giovane laureanda in informatica che, dopo la morte misteriosa del padre, si trasforma nell'hacker più potente del mondo. Una storia avvincente che, episodio dopo episodio, affronta una minaccia digitale diversa — dal phishing al ransomware, fino al cyberbullismo — e insegna a riconoscerla e a difendersi, senza che sembri mai una lezione.
Sul sito trovate tutto ciò che rende Betti un progetto diverso dal solito: la sua filosofia, le anteprime delle tavole e il racconto di come nasce ogni volume. Perché dietro Betti RHC c'è solo lavoro umano: ogni tavola è disegnata interamente a mano dagli artisti del Gruppo Arte di Red Hot Cyber, senza alcun uso di intelligenza artificiale. E a garantire che ogni storia sia realistica e tecnicamente corretta c'è la supervisione degli hacker etici del gruppo HackerHood, che mantengono il racconto fedele al mondo reale della sicurezza informatica.
C'è spazio anche per le aziende, che possono usare Betti come strumento di awareness diverso dai soliti corsi: acquistare i volumi, personalizzarli con il proprio brand o sponsorizzare nuovi episodi. E come primo regalo, l'episodio "Byte the Silence", dedicato al cyberbullismo, è scaricabile gratuitamente per uso personale.
Perché la miglior difesa, in fondo, è una bella storia. 👉 Scopri tutto su https://betti.redhotcyber.com/