US-sanctioned currency exchange says $15 million heist done by “unfriendly states”

Grinex, a US-sanctioned cryptocurrency exchange registered in Kyrgyzstan, said it’s halting operations after experiencing a $13 million heist carried out by “western special services” hackers.

Researchers from TRM, which has confirmed the theft, put the value of stolen assets at $15 million after discovering roughly 70 drained addresses, about 16 more than Grinex reported. Neither TRM nor fellow blockchain research firm Elliptic has said how the attackers slipped past Grinex’s defenses. Grinex said it has been under almost constant attack attempts since incorporating 16 months ago. The latest attacks, it said, targeted Russian users of the exchange.

Damaging “Russia’s financial sovereignty”

“The digital footprints and nature of the attack indicate an unprecedented level of resources and technology available exclusively to the structures of unfriendly states,” Grinex said. “According to preliminary data, the attack was coordinated with the aim of causing direct damage to Russia’s financial sovereignty.”

“Due to the attack, the Grinex exchange is forced to suspend operations,” Grinex continued. “All available information has been transferred to law enforcement agencies. An application has been submitted to the location of the infrastructure to initiate a criminal case.”

TRM said that TokenSpot, a second Kyrgyzstan-based exchange, was also breached. Two of the exchange’s addresses sent funds to the same consolidation address used by the affected Grinex-linked wallets. What’s more, both exchanges became inoperable on Wednesday, suggesting they were hit by the same attacker.

TRM said TokenSpot was a front for Grinex, which the US Treasury Department sanctioned last year. The department’s Office of Foreign Assets Control said that Grinex, in turn, was a rebrand of Garantex, an exchange it had sanctioned in 2022. The department said then that Ganantex had “directly facilitated notorious ransomware actors and other cybercriminals by processing over $100 million in transactions linked to illicit activities since 2019.” Last year’s sanctions against Grinex came a few months after TRM said that the exchange was likely a front for Ganantex.

https://arstechnica.com/security/2026/04/russia-friendly-exchange-says-western-special-service-behind-15-million-cyberattack/




ICE Acting Director Todd Lyons to Resign

Federal officials announced the Immigration and Customs Enforcement (ICE) acting director, Todd Lyons, is set to resign at the end of May. 

Homeland Security Secretary Markwayne Mullin revealed Lyons’ impending resignation, stating, “We wish him luck on his next opportunity in the private sector.”  

A reason behind the resignation was not given. His departure coincides with new DHS leadership after former Secretary Kristi Noem was fired by President Trump. 

At this time, it is unclear who will replace Lyons. 

https://www.securitymagazine.com/articles/102238-ice-acting-director-todd-lyons-to-resign




La responsabilità penale dell’ethical hacker: confini incerti tra ricerca e reato

In assenza di una disciplina organica sulla responsible disclosure, il ricercatore di sicurezza italiano opera in una zona grigia normativa che la Legge 90/2024 ha reso, paradossalmente, ancora più insidiosa.

Un mestiere che inizia dove finisce la legge

Esiste una figura professionale che compie ogni giorno, deliberatamente, atti che il codice penale descrive come reati. Lo fa per proteggere sistemi, utenti e infrastrutture. Lo fa, spesso, senza che nessuno glielo abbia chiesto. E lo fa sapendo che, al termine del proprio lavoro, potrebbe ricevere non un ringraziamento ma un avviso di garanzia.

Il ricercatore di sicurezza informatica, l’ethical hacker, il penetration tester indipendente, il bug hunter, opera in Italia in uno spazio normativo che non è mai stato davvero regolamentato. Non esiste, nel nostro ordinamento, alcuna norma che definisca cosa sia la “ricerca di sicurezza” in senso giuridicamente rilevante. Non esiste una procedura codificata per la divulgazione responsabile delle vulnerabilità. Non esiste un porto sicuro. Esiste soltanto l’art. 615-ter del codice penale, pensato oltre trent’anni fa per punire i criminali informatici, che nella sua formulazione universale abbraccia indistintamente il black hat malevolo e il white hat che, trovata una falla in un sistema pubblico, vorrebbe segnalarla a chi di competenza.

Questo articolo analizza quella zona grigia: la giurisprudenza che ha cercato di tracciarvi dei confini, la riforma del 2024 che quei confini ha ulteriormente spostato verso l’incertezza, i modelli esteri che indicano percorsi alternativi e le clausole contrattuali dei programmi di bug bounty che cercano di supplire, con strumenti privatistici, a ciò che il legislatore non ha ancora fatto.

L’art. 615-ter e il problema strutturale della fattispecie

L’art. 615-ter del codice penale, introdotto dalla legge n. 547 del 1993 in attuazione della Raccomandazione del Consiglio d’Europa n. R(89)9 del 13 settembre 1989 sulla criminalità informatica, punisce con la reclusione fino a tre anni «chiunque abusivamente si introduce in un sistema informatico o telematico protetto da misure di sicurezza ovvero vi si mantiene contro la volontà espressa o tacita di chi ha il diritto di escluderlo».

La norma è disegnata attorno a due concetti chiave: l’abusività dell’accesso e la tutela dello ius excludendi del titolare. L’accesso al sistema è protetto non quale dato puramente tecnico, ma quale proiezione del “domicilio informatico”, con tutela derivante indirettamente dagli artt. 14 e 15 Cost. Ciò significa che la norma protegge, prima ancora che i dati, la volontà del titolare di ammettere o escludere soggetti dal proprio spazio informatico.

Su questo punto la giurisprudenza ha conosciuto una lunga storia di oscillazioni, risolta almeno parzialmente da due fondamentali interventi delle Sezioni Unite della Corte di Cassazione.

La giurisprudenza delle Sezioni Unite: due principi, un paradosso

Il primo intervento è la sentenza SS.UU. “Casani” del 27 ottobre 2011 (n. 4694, dep. 7 febbraio 2012). La questione era se integrasse il reato la condotta del soggetto autorizzato all’accesso che vi si introduce per finalità diverse o illecite.

Le Sezioni Unite stabilirono un principio di portata generale: «integra la fattispecie criminosa di accesso abusivo ad un sistema informatico o telematico protetto la condotta di accesso o di mantenimento nel sistema posta in essere da soggetto che, pure essendo abilitato, violi le condizioni ed i limiti risultanti dal complesso delle prescrizioni impartite dal titolare del sistema per delimitarne oggettivamente l’accesso. Non hanno rilievo, invece, per la configurazione del reato, gli scopi e le finalità che soggettivamente hanno motivato l’ingresso al sistema».

Il principio è tecnicamente preciso ma produce conseguenze problematiche per i ricercatori di sicurezza: ciò che rileva non è l’intenzione dell’agente (buona o cattiva che sia) ma la violazione oggettiva delle condizioni di accesso poste dal titolare. Per l’ethical hacker che accede a un sistema senza un’esplicita autorizzazione scritta del titolare, la mancanza di quella volontà espressa è di per sé sufficiente a configurare il reato, indipendentemente dal fatto che egli non abbia copiato nulla, non abbia arrecato danni e intenda segnalare responsabilmente la vulnerabilità trovata.

Il secondo intervento è la sentenza SS.UU. “Savarese” del 18 maggio 2017 (n. 41210), che per i pubblici ufficiali ha introdotto il concetto di “ragioni ontologicamente estranee”: integra il delitto di cui all’art. 615-ter, secondo comma n. 1, c.p. la condotta del pubblico ufficiale che, pur essendo abilitato e pur non violando le prescrizioni formali impartite dal titolare, acceda o si mantenga nel sistema per ragioni ontologicamente estranee rispetto a quelle per le quali la facoltà di accesso gli è attribuita.

Per il ricercatore di sicurezza, la combinazione di questi due principi crea un labirinto: se accede senza autorizzazione esplicita viola le condizioni del titolare (Casani); se accede con credenziali lecite ma per testare la sicurezza invece di svolgere la funzione per cui le credenziali furono concesse, compie operazioni “ontologicamente estranee” (Savarese). In entrambi i casi la legge non distingue tra chi vuole fare un danno e chi vuole evitarlo.

Il caso Catania 2019: un’archiviazione istruttiva, non una regola

Un provvedimento che ha catalizzato l’attenzione degli specialisti è il decreto del GIP del Tribunale di Catania del 15 luglio 2019 (Giudice dott. Rizza), che ha disposto l’archiviazione di un procedimento penale per il reato di accesso abusivo a sistemi informatici o telematici (art. 615-ter c.p.). I fatti si inseriscono in un contesto di sviluppo di un’applicazione per smartphone: il ricercatore, dotato di notevoli competenze tecniche, si era introdotto nel sistema aziendale individuando vulnerabilità che aveva poi segnalato responsabilmente. Il giudice ha ritenuto che tale condotta, qualificabile come responsible disclosure volta alla “tutela dei consumatori”, non potesse essere censurata penalmente.

Il provvedimento è storicamente significativo: è tra le prime archiviazioni italiane esplicitamente motivate con il riconoscimento della responsible disclosure. Non costituisce però un precedente vincolante né una causa di giustificazione sistematica. È il risultato di una valutazione discrezionale, irripetibile nella sua struttura procedurale, che non risolve il problema strutturale: in assenza di una norma che definisca le condizioni di liceità della ricerca di sicurezza, ogni caso deve essere valutato individualmente, con esiti imprevedibili.

La Legge 90/2024: più pene, nessuna protezione

Se la giurisprudenza si era almeno sforzata di cercare criteri interpretativi di contenimento, il legislatore del 2024 ha scelto una direzione opposta: più sanzioni penali, nessun safe harbor.

La Legge 28 giugno 2024, n. 90, “Disposizioni in materia di rafforzamento della cybersicurezza nazionale e di reati informatici”, si compone di 24 articoli e introduce obblighi di segnalazione degli incidenti per pubbliche amministrazioni e operatori essenziali (art. 1), rafforza il ruolo dell’Agenzia per la Cybersicurezza Nazionale (ACN) e inaspisce in modo significativo le sanzioni penali per i reati informatici.

Sul piano del diritto penale sostanziale, l’art. 16 della legge modifica in modo estensivo il codice penale. Per quanto riguarda specificamente l’art. 615-ter c.p.:

Il primo comma (ipotesi base) rimane invariato: reclusione fino a tre anni, procedibile a querela della persona offesa. Il secondo comma (ipotesi aggravate, tra cui il fatto commesso da pubblico ufficiale o in danno di pubblico ufficiale) subisce modifiche alle circostanze aggravanti, con procedibilità d’ufficio. Il terzo comma (sistemi informatici di interesse militare, ordine pubblico, sicurezza pubblica, sanità, protezione civile, interesse pubblico) vede le pene elevarsi sensibilmente: da «reclusione da uno a cinque anni e da tre a otto anni» a «reclusione da tre a dieci anni e da quattro a dodici anni», con procedibilità d’ufficio.

L’inasprimento del terzo comma è particolarmente rilevante per i ricercatori di sicurezza: i sistemi che presentano le vulnerabilità più critiche (quelli di interesse pubblico, sanitario o infrastrutturale) sono proprio quelli per cui la legge ora prevede le pene più severe, senza che esista alcuna causa di giustificazione per il ricercatore in buona fede. La Legge 90/2024 ha anche introdotto, all’art. 623-quater c.p., circostanze attenuanti per chi si adoperi per evitare che l’attività delittuosa sia portata a conseguenze ulteriori, con riduzione di pena dalla metà a due terzi. Si tratta però di un istituto pensato per la collaborazione investigativa, non per la tutela del ricercatore preventivo.

Come analizzato su ICT Security Magazine, alcuni esperti temono che la normativa possa ostacolare il lavoro di chi si occupa di bug bounty programs o di ricerca indipendente sulla sicurezza informatica. Il timore non è peregrino: in assenza di cause di giustificazione specifiche, l’aumento delle pene produce un effetto deterrente che ricade sull’intera comunità della sicurezza, non solo sugli attori malintenzionati. Le Camere Penali Italiane, nelle proprie osservazioni al testo, hanno rilevato come alcune nuove disposizioni introducano ipotesi di reato e circostanze aggravanti inadeguate a fornire una risposta efficace alle esigenze di sicurezza e che la partecipazione dell’ACN nelle indagini (art. 22 co. 4-bis) sollevi preoccupazioni sull’indipendenza delle procedure giudiziarie.

La legge ha il merito di rafforzare l’ACN come interlocutore per la gestione delle vulnerabilità e di istituire il Centro Nazionale di Crittografia, ma non trae le conseguenze necessarie per il quadro della ricerca di sicurezza indipendente. Come illustrato in precedenti analisi, l’inasprimento delle pene non è sempre efficace come deterrente se non accompagnato da una robusta capacità di enforcement e da un equilibrato riconoscimento delle condotte lecite.

I tentativi di riforma: verso una responsible disclosure normata

Il vuoto normativo non è passato inosservato. A livello parlamentare, la proposta di legge a prima firma dell’on. Riccardo Magi (nelle sue diverse formulazioni a partire dal 2022) ha avuto il merito di portare la questione al centro del dibattito: il testo prevedeva l’introduzione di una causa di non punibilità per il ricercatore di sicurezza che avesse operato rispettando criteri di buona fede, proporzionalità e notifica tempestiva delle vulnerabilità scoperte all’organizzazione interessata o all’ACN. La proposta non è mai giunta all’approvazione, ma ha catalizzato un dibattito accademico e tecnico di grande rilievo, a cui si è aggiunta l’attività di soggetti come la fondazione GCSEC, promotrice del Manifesto italiano di Coordinated Vulnerability Disclosure.

La questione centrale, sul piano dogmatico, è se sia più opportuno introdurre una causa di giustificazione (che esclude l’illiceità del fatto), una causa di non punibilità (che esclude la pena pur riconoscendo l’illiceità) o una vera e propria riformulazione delle fattispecie incriminatrici che escluda ab origine dalla tipicità le condotte di ricerca in buona fede. Sarebbe opportuno che il legislatore intervenisse introducendo una vera e propria causa di non punibilità, distinta dal consenso dell’avente diritto. Quest’ultimo, infatti, non può operare per il reato di cui all’art. 615-ter c.p. nell’ipotesi base, poiché il mancato consenso è elemento costitutivo della fattispecie.

Ciascuna opzione presenta profili tecnici diversi. La causa di giustificazione si inserirebbe nella struttura del reato e avrebbe effetti più pervasivi, ma richiederebbe criteri applicativi rigorosi per evitare che diventi uno scudo per condotte in realtà offensive. La causa di non punibilità è più cauta sul piano sistematico ma non risolve il problema del procedimento che viene comunque avviato e delle misure cautelari che possono essere disposte nel frattempo. La modifica tipizzante è la più garantista ma anche la più difficile da formulare con precisione sufficiente.

Il modello olandese: pragmatismo istituzionale senza immunità assoluta

I Paesi Bassi rappresentano il riferimento europeo più maturo in materia di responsible disclosure istituzionalizzata. Il National Cyber Security Centre olandese (NCSC) ha pubblicato le proprie linee guida sul Coordinated Vulnerability Disclosure (CVD) nel 2013, poi aggiornate nel 2018 sulla base dell’esperienza maturata.

Il modello olandese deve essere descritto con precisione, perché spesso viene frainteso come un “porto sicuro” assoluto: non lo è. Le linee guida non modificano il quadro giuridico vigente. Il codice penale olandese (artt. 138ab e 161 sexies) non distingue tra hacker malintenzionato ed ethical hacker: la decisione se trattare un soggetto come tale è rimessa alla Procura della Repubblica e al giudice. La Procura olandese ha tuttavia pubblicato una lettera di indirizzo nel 2013 (il Board of Procurators General), stabilendo che non si procederà penalmente in presenza di “ripristino dei diritti” tra il segnalante e l’organizzazione colpita, pur mantenendo la facoltà di agire quando la condotta abbia ecceduto i limiti di proporzionalità.

Il meccanismo funziona perché poggia su tre pilastri complementari. Il primo è procedurale: le organizzazioni che adottano una politica CVD si impegnano formalmente a non sporgere denuncia contro i ricercatori che rispettino determinate condizioni (nessuna copia o modifica di dati, disclosure confidenziale, proporzionalità dei test, finestra temporale concordata per la correzione prima della pubblicazione). L’NCSC raccomanda un termine di 60 giorni per le vulnerabilità software e di sei mesi per quelle hardware più complesse.

Il secondo è istituzionale: l’NCSC agisce da intermediario quando la vulnerabilità viene segnalata direttamente all’ente, e si impegna a tenere informato il ricercatore sullo stato di risoluzione. Il terzo è normativo-orientativo: la lettera di indirizzo della Procura offre ai ricercatori criteri ex ante di comportamento protetto, riducendo l’incertezza giuridica senza richiedere una modifica legislativa.

Il sistema olandese non garantisce immunità: la Procura mantiene sempre la facoltà di perseguire. Un ricercatore che abbia reso pubblica la vulnerabilità prima della correzione o che abbia effettuato ricerche sui dati personali di soggetti terzi è stato condannato, proprio perché aveva ecceduto i limiti di proporzionalità. Ma l’esistenza di criteri chiari e di un orientamento esplicito della magistratura requirente ha creato un ecosistema in cui la ricerca di sicurezza può prosperare in condizioni di ragionevole prevedibilità giuridica.

Il caso americano: il CFAA, Van Buren e il dibattito sulla riforma

Negli Stati Uniti il problema è strutturalmente analogo. Il Computer Fraud and Abuse Act del 1986 (CFAA) punisce chiunque “intentionally accesses a computer without authorization or exceeds authorized access”, e la vaghezza della nozione di exceeds authorized access aveva generato un lungo contrasto giurisprudenziale tra i circuiti di appello federali.

La svolta è arrivata con la sentenza Van Buren v. United States della Corte Suprema del 3 giugno 2021 (593 U.S. 374). La Corte, in una decisione 6-3 redatta dalla Justice Barrett, ha adottato un’interpretazione di tipo “gates-up-or-down”: si “eccede l’autorizzazione” soltanto quando si accede a file, cartelle o database a cui il proprio accesso non si estende affatto, non quando si usa un accesso altrimenti lecito per uno scopo improprio.

Il fine dell’accesso (anche se illecito) è giuridicamente irrilevante se le credenziali permettevano l’accesso a quell’area del sistema. La Electronic Frontier Foundation, che aveva depositato un amicus brief nel caso, definì la pronuncia “una vittoria per tutti gli utenti di Internet e in particolare per i ricercatori di sicurezza”.

Van Buren non ha risolto però il problema dell’accesso inizialmente non autorizzato, che rimane il caso più comune per il ricercatore indipendente. E non elimina il rischio di azione civile: come segnalato da diversi esperti del settore, il timore principale dei ricercatori non è la responsabilità penale ma quella civile, cioè essere citati in giudizio dalla stessa azienda che ha la vulnerabilità nel proprio sistema.

Le proposte di riforma più avanzate, elaborate da organizzazioni come Rapid7, EFF e Center for Democracy & Technology, convergono su alcuni elementi comuni: la definizione legislativa di good faith security research, che includa la minimizzazione dei danni e l’obbligo di disclosure al titolare del sistema; il divieto di utilizzo commerciale delle vulnerabilità scoperte prima della loro divulgazione; la limitazione del diritto di azione civile delle aziende nei confronti dei ricercatori che abbiano rispettato la procedura di disclosure.

I programmi di bug bounty: contratti che suppliscono alla legge

In assenza di una disciplina legislativa, il mercato ha sviluppato i propri strumenti di regolazione. I programmi di bug bounty (piattaforme gestite da HackerOne, Bugcrowd e operatori nazionali, o programmi diretti delle singole organizzazioni) rappresentano oggi la principale forma di legalizzazione contrattuale dell’ethical hacking.

Il meccanismo è semplice: l’organizzazione definisce un perimetro (scope) di sistemi su cui la ricerca è autorizzata, le tipologie di vulnerabilità ricercabili, le regole di comportamento per il ricercatore, la finestra temporale entro cui la vulnerabilità verrà corretta e la misura della ricompensa. In cambio, il ricercatore ottiene l’autorizzazione esplicita (la volontà espressa del titolare che l’art. 615-ter richiede) e una clausola contrattuale di safe harbor che lo protegge da azioni legali civili. Il Gold Standard Safe Harbor promosso da HackerOne è divenuto di fatto uno standard internazionale di riferimento, raccomandato anche dal Dipartimento di Giustizia degli Stati Uniti e dalla CISA nel proprio Vulnerability Disclosure Policy Template per le agenzie federali.

In Italia, il mercato dei bug bounty è in crescita ma strutturalmente fragile sul piano della tutela giuridica del ricercatore. Il problema fondamentale è che la clausola contrattuale di safe harbor non ha alcuna efficacia preclusiva nel sistema penale italiano.

Per le ipotesi base del reato (primo comma, procedibili a querela), il consenso e la mancata querela del titolare costituiscono di fatto un presidio: il titolare del sistema, potendo disporre del suo legittimo interesse, può scegliere di non sporgere denuncia o di ritirarla. Ma per le ipotesi aggravate del terzo comma (quelle relative a sistemi di rilevanza pubblica, sanitaria, militare o infrastrutturale, procedibili d’ufficio) il consenso del titolare è penalmente irrilevante, e la Procura può procedere indipendentemente dalla volontà della parte offesa.

Un ulteriore profilo critico riguarda la granularità tecnica degli ambienti informatici: se il ricercatore, operando nell’ambito di un programma di bug bounty aziendale, accede incidentalmente a dati di terzi o a sottosistemi non inclusi nello scope dichiarato, la copertura contrattuale cessa. Questa eventualità, tutt’altro che teorica in sistemi complessi e interconnessi, espone il ricercatore a un rischio che nessuna clausola contrattuale può eliminare in assenza di una norma primaria di tutela.

La Direttiva NIS2 e il diritto dell’Unione: un’occasione mancata

Il quadro normativo europeo offre spunti importanti ma non ha ancora tradotto la propria attenzione alla sicurezza informatica in una tutela esplicita per i ricercatori. La Direttiva NIS2 (Direttiva UE 2022/2555), recepita in Italia con il D.Lgs. n. 138/2024 in vigore dal 18 ottobre 2024, impone agli operatori essenziali e importanti di adottare politiche per la gestione delle vulnerabilità e processi di coordinated vulnerability disclosure. È un riconoscimento formale (il primo in uno strumento europeo vincolante) che le vulnerabilità esistono, che è utile che qualcuno le trovi e che deve esserci un processo per gestirne la comunicazione.

Tuttavia, la NIS2 non trae le conseguenze penalistiche di questi principi: non prevede alcuna protezione per chi, trovando una vulnerabilità al di fuori di un programma formale, la segnali spontaneamente. Il Cybersecurity Act europeo (Reg. UE 2019/881) ha istituito il quadro di certificazione della cybersecurity, ma riguarda prodotti e servizi, non la posizione giuridica dei ricercatori. L’ENISA ha pubblicato nel 2022 un rapporto sulle politiche CVD nell’UE documentando la frammentazione delle pratiche nazionali e raccomandando standard comuni, rilevando come l’assenza di framework nazionali chiari creasse “uncertainty and potential legal risk for security researchers across the EU”. Le raccomandazioni sono rimaste in larga parte disattese sul piano legislativo.

Le strade possibili: un’agenda di riforma

Il panorama tracciato consente di identificare alcune priorità di riforma che l’Italia, con la Legge 90/2024, ha scelto di non affrontare.

La prima priorità è legislativa: l’introduzione di una causa di non punibilità (o di una scriminante procedurale) per il ricercatore di sicurezza che abbia operato rispettando criteri di buona fede, proporzionalità e notifica tempestiva. Il modello olandese offre una traccia: non un’immunità assoluta, ma un processo strutturato che dia al ricercatore criteri chiari di comportamento protetto e orienti la discrezionalità della magistratura requirente verso la non azione in presenza di quei criteri. Sarebbe altresì utile definire esplicitamente cosa costituisce un’attività lecita di security testing.

La seconda priorità è istituzionale: l’ACN dovrebbe sviluppare un ruolo di intermediario analogo a quello svolto dall’NCSC olandese. La Legge 90/2024 le ha attribuito la funzione di ricevere e gestire le segnalazioni di vulnerabilità nei sistemi delle pubbliche amministrazioni e degli operatori essenziali: è il momento di costruire intorno a questa funzione un framework pubblico di responsible disclosure, con una policy ufficiale che definisca le regole del gioco per i ricercatori indipendenti che operano su sistemi italiani. In questa prospettiva sarebbe auspicabile anche l’introduzione di un registro nazionale di penetration tester certificati, con linee guida precise per le attività autorizzate e procedure chiare per ottenere autorizzazioni di testing.

La terza priorità è prosecutoriale: un orientamento esplicito del Consiglio Superiore della Magistratura o della Procura Generale della Cassazione sull’approccio da tenere nei casi di divulgazione responsabile (analogo alla lettera di indirizzo del Board of Procurators General olandese del 2013) non richiede una modifica legislativa ma può ridurre significativamente l’incertezza giuridica per i ricercatori in buona fede.

La quarta priorità è contrattuale e di sistema: la standardizzazione delle clausole di safe harbor nei programmi di bug bounty italiani, possibilmente con il supporto di ACN e di associazioni di categoria come Clusit, per ridurre l’asimmetria informativa che penalizza soprattutto i ricercatori più giovani e meno strutturati.

Conclusione: il costo dell’immobilismo

La zona grigia in cui opera il ricercatore di sicurezza italiano ha un costo concreto. Si misura nella vulnerabilità non segnalata perché il ricercatore non si fida del framework giuridico. Si misura nel talento che emigra verso Paesi con regole più chiare. Si misura nell’ecosistema della sicurezza informatica nazionale che fatica a strutturarsi intorno a pratiche di responsible disclosure condivise.

Il paradosso dell’attuale situazione italiana è che la stessa Legge 90/2024 che riconosce il valore della gestione strutturata delle vulnerabilità informatiche (che attribuisce all’ACN il compito di ricevere segnalazioni di vulnerabilità, che introduce obblighi di patching e aggiornamento) ha contemporaneamente inasprito le sanzioni per le condotte che stanno a monte di quelle segnalazioni: l’accesso al sistema, la verifica della vulnerabilità, la raccolta delle prove necessarie a dimostrarne l’esistenza. Chiedere ai ricercatori di trovare le vulnerabilità e al contempo minacciare chi le trova con pene fino a dodici anni di reclusione per i sistemi più critici è una contraddizione che il legislatore non può continuare a ignorare.

Una politica di sicurezza informatica coerente deve riconoscere che la sicurezza collettiva dei sistemi dipende anche, e talvolta soprattutto, dall’attività di chi, senza aspettare di essere commissionato, cerca le falle prima che lo facciano i criminali. Trovare l’equilibrio tra la necessaria protezione dei sistemi informatici e la necessaria libertà di chi lavora per renderli più sicuri non è un esercizio accademico: è una scelta di politica del diritto urgente e non più rinviabile.

Condividi sui Social Network:

https://www.ictsecuritymagazine.com/articoli/ethical-hacker/




How CSOs Can Win Board Support for Gunshot Detection Technology

@import url(‘https://fonts.googleapis.com/css2?family=Handlee&display=swap’); h3 { font-weight: bold; font-size: 18px; color: #C72026; } .pqFull { display: block; border-width: 2px 0; border-style: solid; border-color: #404144; padding: 1.5em 0 0.5em; margin: 1.5em 0; position: relative; Handlee”, Arial, sans-serif; font-size: 20px; text-align: center; color: #0067A6; } .pqFull:before { content: ‘\275D’; position: absolute; top: -.10em; left: 50%; transform: translate(-50%, -50%); background: #fff; width: 4rem; height: 2rem; color: #666; text-align: center; } .pqFull:after { content: attr(cite); display: block; text-align: center; font-size: 18px; color: #404144; }

For many chief security officers (CSO), the conversation about gunshot detection technology begins long before a system is purchased or deployed. It starts with the challenge of framing the technology effectively for chief executive officers and boards, by anticipating tough questions, and aligning the investment with corporate risk priorities.

While CSOs understand the realities of gun violence, whether it’s from a disgruntled employee or outside actor, the limitations of existing defenses, and the growing expectations for due diligence, gaining executive support requires a clear, data-driven, and financially grounded case. To do so, three realities must be articulated: traditional security tools have gaps, the governance and liability landscape demands action, and violent incidents create enormous financial and operational impacts.

When CSOs can help executive leaders and board members understand these factors, and guide them through the decision-making process, they are far better positioned to secure the resources needed to protect people and assets.

Traditional Security Tools Aren’t Enough

Most organizations today have invested heavily in front-end protections. These systems often include video surveillance, visitor management, turnstiles, weapons detection screening, armed officers, access control, along with sophisticated lockdown procedures. These are all necessary components of a comprehensive security plan, but despite all these technology investments there remains an uncomfortable truth many security professionals know well; and that is these systems rely on the assumption that an assailant will cooperate with security procedures and protocols before gaining entrance into a space, and their intentions will be detected before any bad actions can happen.

The reality is that a significant percentage of gun violence in corporate environments are insiders or former employees. They know the security processes, the vulnerabilities and how to bypass security screening procedures. And it’s also known that these attackers often enter through unconventional pathways, such as side entrances, loading docks, unsecured service areas, or simply by tailgating behind authorized staff.

This is where gunshot detection becomes vital as part of a layered defense strategy. It does not replace other security and screening measures but addresses the gaps between disparate systems. If an assailant shoots a guard at a checkpoint, bypasses screening entirely, or fires into the building from outside, gunshot detection responds instantly, providing real-time information about the location and progression of the threat to first responders or internal security operation centers.

It’s clear that seconds count when people become victims during an active shooter incident. Gunshot detection technology helps law enforcement pinpoint the threat inside or outside a building. The faster responders can neutralize the threat, more lives can be saved, and the sooner business operations can resume.

Regulatory, Legal, and Governance Landscape Has Shifted: Inaction Is Now a Liability

Every CSO preparing to make the case for gunshot detection should understand the reality that boards no longer have the luxury of inaction when credible, protective technology already exists. After violent incidents, a predictable and rigorous investigative process follows, which often includes legal reviews, internal audits, regulatory scrutiny, and in the public sector, politically driven inquiries.

Across all these reviews, the same questions arise. What did you know? When did you know about it? And what did you do about it?

When CSOs can help executive leaders and board members understand these factors, and guide them through the decision-making process, they are far better positioned to secure the resources needed to protect people and assets.

If the organization lacked advanced detection tools, including tools that have been widely available for years, executives may then face painful questions about due diligence. Regulators and outside counsel are increasingly measuring organizations against available security practices, not just industry averages. When a prevention strategy can be circumvented, and there is no secondary layer, that absence becomes part of the investigation.

This is even more acute in industries where infrastructure is critical. In some sectors, gun-related incidents have led to facilities being shut down for 30 days or more while law enforcement conducts its investigation. Gunshot detection can help reduce investigatory time from the first second the incident begins, providing key, verified intelligence that could potentially shorten shutdown times, reducing financial and operational losses by millions of dollars. For CEOs and boards, the governance case becomes unambiguous because ignoring a foreseeable, preventable risk is no longer tenable.

Business Continuity, Operational Impact, and the Financial Cost of Inaction

While safety is the core argument for gunshot detection, business continuity carries enormous weight in board discussions. Active shooter events are among the most financially destructive scenarios an organization can face, not only because of potential loss of life, but because of the cascading operational disruptions.

During a crisis, companies are judged instantly in the court of social media. If emergency response appears slow, chaotic, or uninformed, reputational damage can accumulate in real time. Investors and the public quickly form impressions of whether the company was prepared, whether leadership acted decisively, and whether employee safety was prioritized.

Then comes the operational impact. Facilities shut down. Employees are displaced. Customers lose confidence. Productivity stalls. In industries such as utilities, manufacturing, and logistics, losing a facility for even a week can result in millions of dollars in lost output. When you multiply that by regulatory delays or extended law enforcement holds, the disruption becomes staggering.

Gunshot detection technology can shorten the timeline by giving responders precision that allows them to act faster. Better data also means faster clearance after an event and a shorter turnaround to reopen facilities and recover operations. Some executives frame this as a purely economic argument when if a system reduces shutdown time by even a few days compared to a manual response, it pays for itself almost immediately.

Guiding Executives and Boards Toward Smart Decision-Making

Ultimately, making the case for gunshot detection isn’t just about the technology, it’s about helping leaders understand how this investment fits into a broader strategy of corporate responsibility, risk reduction, and cultural readiness.

CSOs often face a dilemma as to which role they should take in the discussion about gunshot technology. Should the CEO be the one selling this to the board, or should the CSO lead the discussion? CEOs are expected to rely on subject-matter experts for cybersecurity, legal affairs, HR and compliance. Physical security is no different. When safety and security appear on board agendas, as they increasingly do, the CSO must be prepared to articulate the risk picture, the technology landscape, and the return on investment.

A second consideration is where to begin. Installing 150 sensors throughout an entire building may be ideal, but it’s not always feasible. Most organizations start small by focusing on public lobbies, cafeterias, and other large communal spaces. These are statistically the first areas where incidents unfold. Starting small not only reduces the initial investment, but it also builds an internal relationship between the security team, procurement, and leadership, paving the way for future expansion.

Finally, CSOs must be prepared to address objections they may hear from members of the executive leadership team or the board. This can include statements such as “We’ve never had an incident” and “Is this technology spying on employees?” to “How do we know the probability of an attack?” In addition, it’s also important to make sure employees and other stakeholders are familiar with gun violence response training exercises.

The answers to these and other questions lie in transparency, education and practical framing. Gunshot detection does not record conversations or monitor behavior. Its purpose is singular and that is to accelerate emergency response and accurately communicate information about the incident, such as the precise location, the time of the incident and the scale of the attack. And while the probability of an active shooter event cannot be predicted with precision, the escalating FBI statistics and sector-specific case studies make one thing clear and that is that societal violence is rising, and organizations can no longer use unpredictability as a reason for inaction.

In the end, the CSO’s role is both strategic and persuasive. By presenting the data, explaining the gaps in current security layers, and guiding leadership through realistic cost-benefit analysis, CSOs can make a compelling case for technology that not only protects people but strengthens the organization’s resilience, reputation, and operational stability.

https://www.securitymagazine.com/articles/102211-how-csos-can-win-board-support-for-gunshot-detection-technology




What Are Security Experts Saying About OpenAI’s GPT-5.4-Cyber?

Days after Anthropic unveiled Claude Mythos, OpenAI launched GPT-5.4-Cyber, a model optimized for defensive cybersecurity usage. Unlike Anthropic, which chose to limit the Mythos model to a select few partners, OpenAI is scaling access to its Trusted Access for Cyber (TAC) program to thousands of verified, individual defenders as well as hundreds of groups protecting critical infrastructure. 

OpenAI states, “Our goal is to make these tools as widely available as possible while preventing misuse. We design mechanisms which avoid arbitrarily deciding who gets access for legitimate use and who doesn’t. That means using clear, objective criteria and methods — such as strong KYC and identity verification — to guide who can access⁠ more advanced capabilities and automating these processes over time. Ultimately, we aim to make advanced defensive capabilities available to legitimate actors large and small, including those responsible for protecting critical infrastructure, public services, and the digital systems people depend on every day.” 

OpenAI says its intention is to learn by putting the model into the world and improving it over time. “As we better understand both their capabilities and risks, we update our models and safety systems accordingly,” the organization states. 

Security Leaders Weigh In

Tim Mackey, Head of Software Supply Chain Risk Strategy at Black Duck:

As each new cybersecurity focused AI model becomes available, there is one important item for teams to remember. Finding bugs is very different from fixing bugs. And while it’s great to hear that these cybersecurity models are being provided to select researchers to evaluate, unless those select teams work for your company, you’re at the mercy of any tuning performed based on their feedback. One thing is clear, AI cybersecurity is here to stay and will only become more powerful. Security leaders in organizations of all sizes need to take the Anthropic and OpenAI advancements as a call to action focused on where and how AI enabled cybersecurity will benefit their operations and scale to deal with AI enabled adversaries. 

Trey Ford, Chief Strategy and Trust Officer at Bugcrowd:

The race between OpenAI and Anthropic to arm defenders is real, and it matters. The bottleneck was never the AI model, it’s the program architecture that decides which findings get verified, which get triaged, and which actually get fixed before an attacker reverse-engineers the same patch. 

Two frontier models competing on access philosophy doesn’t solve a key problem: the human coordination layer that gives AI-discovered vulnerabilities a path to remediation. What OpenAI’s TAC expansion and Anthropic’s Glasswing both tell us is that AI-discovered vulnerabilities are outpacing the coordinated infrastructure built to remediate them. 

The next generation of security programs won’t be judged on which AI model they use to find vulnerabilities, they’ll be judged on whether they built the program architecture, researcher coordination, and triage capacity to close the gap between machine-speed discovery and human-speed remediation. That’s where the real competitive advantage in cyber defense gets built.

The OpenAI vs. Anthropic access debate is the wrong conversation for security leaders this week. Access philosophy (democratic scale versus controlled rollout) doesn’t change the structural reality. The time to exploit is now measured in hours. 

The CVE system wasn’t built for AI-discovery rates, attackers don’t need Mythos to find what Glasswing couldn’t patch.

The question every CISO should be asking isn’t which model they can access, it’s whether their program was designed to act on what those models find.

Ronald Lewis, Head of Cybersecurity Governance at Black Duck:

There is a notable divergence in how OpenAI and Anthropic have approached the release of AI models with cybersecurity relevant capabilities. OpenAI has largely followed a traditional security tool release pattern, where potentially dangerous capabilities are restricted to trusted operators. Access to its cyber focused model (GPT 5.4 for Cyber) is gated through the Trusted Access for Cyber (TAC) program, which emphasizes vetting, use case justification, and ongoing oversight, and is designed to limit both who can access the model and how it may be used.

Importantly, OpenAI’s models underpin a broad ecosystem of third party security products, many of which are already deployed in sensitive environments. This includes a growing litany of tools across vulnerability management, threat intelligence, incident response, and digital forensics, where AI is used to accelerate analysis rather than execute actions. In this sense, OpenAI’s TAC approach mirrors how advanced forensic platforms have historically been released — restricted to validated professionals, governed by contractual controls, and designed to augment expert judgment rather than replace it.

Anthropic, by contrast, released Mythos in a way that appeared comparatively unconstrained when viewed through the lens of how sensitive security tools — such as forensic analysis software — have traditionally been distributed. Rather than heavily limiting access, Anthropic’s approach places greater emphasis on model alignment and internal self restraint, aiming to limit what the model will choose to do rather than who is allowed to use it. This represents a deliberate departure from the conventional “dangerous tool to trusted operator” paradigm.

While Anthropic’s release strategy drew heightened scrutiny, particularly from policymakers and parts of the security community, it also reflects a different theory of risk management: that sufficiently aligned models, combined with institutional governance and partnerships such as Project Glasswing, can enable broad, high capability use without strict individual level access controls.

In stark contrast, OpenAI’s TAC framework reflects a more conservative, tool centric risk posture. It treats advanced cyber capabilities as regulated instruments, suitable for controlled deployment within professional workflows, much like forensic and investigative tooling, rather than as broadly accessible general purpose systems. The two approaches highlight a fundamental philosophical split: OpenAI prioritizes access restriction and operational oversight, while Anthropic prioritizes alignment, institutional trust, and capability preservation.

Marcus Fowler, CEO of Darktrace Federal: 

OpenAI’s latest work on scaling trusted access for cyber defense, including GPT-5.4-Cyber, is a positive step. Lowering barriers for legitimate security work and enabling more advanced defensive workflows helps put stronger capabilities in the hands of defenders. Expanding access to these kinds of tools, in a controlled way, can help organizations more quickly and effectively identify risk.

However, it’s important to keep developments like these in perspective. Some of the greatest challenges in cybersecurity today are not the identification or analysis of weak code. Most organizations are still constrained by the realities of remediation once an issue is discovered: patch development, testing, deployment, uptime requirements, and resource limitations. Faster or deeper analysis does not automatically translate to faster or more effective risk reduction. The gap between discovery and remediation continues to widen, and organizations are defending against far more than just software vulnerabilities, including identity compromise, misconfigurations, insider threats, and misuse of AI itself.

So, while these kinds of capabilities are a step forward, it remains to be seen how much they will fundamentally change the cybersecurity market. What is less likely to change is the need for strong cybersecurity hygiene and best practices within the network itself, like zero trust, and the need for strong detection, visibility, continuous monitoring, and the ability to respond and contain both known and unknown threats at speed.

https://www.securitymagazine.com/articles/102235-what-are-security-experts-saying-about-openais-gpt-54-cyber




What “The Pitt” Gets Right About Ransomware and What Hospitals Can’t Afford to Ignore

As many viewers tune in for the season finale of The Pitt, the show’s ransomware storyline appears to be wrapping up. Systems come back online, clinicians return to patient care, and the hospital moves forward. In reality, the story doesn’t end when the ransom is paid and the screens flicker back on. In fact, that’s often when organizations begin reckoning with the far‑reaching consequences of a cybersecurity incident. 

What The Pitt portrays so effectively, and what many organizations underestimate, is the lingering operational fallout of a cyberattack. In the show, hospital staff stay behind after their shifts to re-enter patient charts manually, reconciling data and restoring continuity of care. While the scenario is fictional, the reality it reflects is very real. Healthcare systems across the country have faced similar challenges following ransomware incidents, including prolonged downtime, workflow disruptions, and months of recovery long after attackers are gone. 

The lesson for real-world hospitals is not simply that ransomware is dangerous. The more important takeaway is how predictable many of these attacks are, how often they exploit the same weaknesses and what healthcare leaders must do to strengthen their security posture before the next incident occurs. 

The Same “Doors” Keep Being Left Unlocked 

In nearly every major healthcare breach, identity is at the center of the incident. Attackers don’t need to come up with sophisticated plans, they simply log in. Stolen credentials, shared accounts, and over-provisioned access remain some of the most common entry points. According to the 2025 Verizon Data Breach Investigations Report, credential abuse continues to be the leading attack vector in healthcare, accounting for 22 percent of breaches

The Pitt depicts this subtly but accurately. The initial compromise isn’t a dramatic cinematic moment, it’s a quiet failure of access control that escalates before anyone notices. That mirrors real hospitals where busy clinical environments, complex staffing models, and legacy systems make strong identity governance difficult to implement consistently. 

Healthcare is uniquely vulnerable because access needs to be fast, flexible, and always available. Clinicians move between departments and temporary staff rotate frequently. Furthermore, you have those that require temporary access in this setting like vendors,

students, and partners. In that complexity, shortcuts emerge like generic logins, credentials shared between shifts and authentication controls relaxed in the name of efficiency. 

Downtime Is Not Just an IT Problem 

One of the most realistic elements of The Pitt’s ransomware storyline is what happens after the systems are restored. Paper charts pile up and staff end up working overtime to ensure the patient records are reported in the EHR systems. Because of that manual effort, patient care delivery slows and fatigue and frustration set in. 

We saw this play out in real time earlier this year at the University of Mississippi Medical Center (UMMC), when a ransomware attack forced the state’s largest health system to shut down clinics statewide and revert to paper documentation for weeks. 

This highlights something hospital leaders are increasingly confronting: cybersecurity incidents are not confined to the IT department. They directly impact patient safety, staff well-being, and organizational trust

While these impacts are often discussed in terms of recovery costs, the deeper consequences are operational. Viewing cybersecurity solely through a technical lens misses this reality. In healthcare, security failures don’t stay contained; they reverberate across every corner of the organization. 

Why Identity Belongs at the Center of Healthcare Cybersecurity

If ransomware stories continue to follow the same pattern, it’s because many organizations still defend the perimeter while leaving identity controls fragmented. 

Strong identity and access management isn’t about adding friction to clinical workflows. It’s about ensuring the right people have the right access at the right time. 

In practical terms, that means:

  • Eliminating shared credentials that obscure accountability
  • Enforcing stronger authentication at access points across the facility
  • Regularly reviewing and revoking access as roles change 
  • Designing security controls that align with clinical realities 

Preparing for the Incident You Hope Never Happens 

No healthcare organization wants to imagine itself in The Pitt’s position, but the reality is that the healthcare sector remains a high‑value target. According to IBM’s 2026 Threat Intelligence Index, North America accounted for 57 percent of all healthcare‑related cyber incidents globally. 

Ransomware is no longer a hypothetical risk. It is a recurring operational threat, and one that increasingly targets hospitals because of the urgency and complexity of care delivery. Attackers know that downtime in healthcare carries real-world consequences and that pressure can force difficult decisions. What separates resilient organizations from vulnerable ones is how prepared they are when it happens. 

That preparation starts with acknowledging uncomfortable truths like attackers often walk through familiar doors, that recovery costs more than prevention, and that identity failures are rarely isolated events. 

A Cautionary Tale for Healthcare Leaders 

The Pitt may end its story with systems restored, but real hospitals don’t get that clean ending. Recovery efforts drag on, trust must be rebuilt and strategies must be implemented to prevent future attacks. 

If there’s one thing healthcare leaders should take from this fictional ransomware attack, it’s that continuing to rely on legacy technology and fragmented access controls increases the likelihood of reliving the same aftermath. Those that modernize their approach to identity and access can change the ending before an attack ever begins.

https://www.securitymagazine.com/blogs/14-security-blog/post/102236-what-the-pitt-gets-right-about-ransomware-and-what-hospitals-cant-afford-to-ignore




Dopo Claude Mythos, cosa deve fare concretamente un CISO: la guida strategica del 2026

Il 7 aprile 2026, mentre Anthropic annunciava Claude Mythos e il Progetto Glasswing – già documentati dalla redazione – qualcosa di altrettanto significativo avveniva in parallelo: oltre sessanta tra i più autorevoli professionisti della sicurezza mondiale si riunivano per produrre in un singolo weekend un documento operativo di risposta, revisionato da oltre 250 CISO a livello globale. Non una dichiarazione di allarme. Un piano d’azione concreto.

Il risultato è The AI Vulnerability Storm: Building a Mythos-ready Security Program, versione 9.1, pubblicato il 15 aprile 2026 dalla CSA CISO Community insieme a SANS, OWASP Gen AI Security Project e [un]prompted, con contributi di figure come Jen Easterly, Bruce Schneier, Rob Joyce e Phil Venables. Questo articolo ne analizza i contenuti strategici: il contesto storico verificato, il risk register, le priorità operative e le implicazioni per chi opera nel contesto italiano.

Il collasso dei tempi: i dati che cambiano tutto

Prima di parlare di strategie, è necessario comprendere la dimensione quantitativa del cambiamento. Il punto di riferimento è il Zero Day Clock, progetto di Sergej Epp, CISO di Sysdig, che traccia in tempo reale il Time-to-Exploit (TTE) su oltre 3.500 coppie CVE-exploit tratte da CISA KEV, VulnCheck KEV e XDB.

I numeri sono eloquenti: nel 2018 la mediana del TTE era di 771 giorni. Nel 2024 era già scesa a 4 ore. Nel 2026 è inferiore alle 24 ore, con una proiezione verso i minuti entro il 2028. Il dato più significativo non è la velocità assoluta, ma la struttura: nel 2026 il 67,2% dei CVE attivamente sfruttati viene weaponizzato prima o nel giorno stesso della disclosure pubblica, rispetto al 16,1% del 2018. Due terzi degli sfruttamenti attivi avvengono quando i difensori non hanno ancora nessuna informazione su cui agire.

Questo non è un trend che si stabilizza. Epp lo spiega attraverso il concetto di Verifier’s Law: l’AI accelera l’offesa più della difesa perché la verifica offensiva è binaria e istantanea (l’exploit ha funzionato oppure no) mentre quella difensiva è ambigua, costosa e lenta. Questo vantaggio strutturale per gli attaccanti preesisteva a Claude Mythos; Mythos ne accelera le conseguenze.

Un anno di escalation verificata: la cronologia evento per evento

Il documento CSA ricostruisce una progressione che molti hanno trascurato. Le capacità che hanno reso Mythos notizia globale non sono apparse dal nulla: si sono sviluppate lungo tutto il 2025 e l’inizio del 2026, in una sequenza di eventi tutti verificabili attraverso fonti primarie.

Giugno 2025. XBOW diventa il primo sistema autonomo a raggiungere la vetta della classifica US di HackerOne per guadagno di reputazione nel secondo trimestre 2025, superando ogni ricercatore umano sulla piattaforma con oltre 1.060 vulnerabilità segnalate, revisionate dal team prima della submission secondo le policy HackerOne. Il progetto open-source raptor dimostra simultaneamente che la vulnerability research autonoma è accessibile a chiunque con un agente off-the-shelf. Per un approfondimento sul tema si veda il nostro articolo sull’AI offensiva nel cybercrime.

Agosto 2025. Google Big Sleep, collaborazione tra DeepMind e Project Zero basata su Gemini, segnala le prime 20 vulnerabilità zero-day in software open source, tra cui FFmpeg e ImageMagick, trovate e riprodotte autonomamente dall’AI prima della revisione umana pre-disclosure. Quattro giorni dopo, alla DEF CON 33, la finale di DARPA AIxCC porta i sette team finalisti a scoprire 54 vulnerabilità sintetiche analizzando 54 milioni di righe di codice in quattro ore di calcolo ciascuno, con 18 vulnerabilità reali scoperte in aggiunta.

Settembre 2025. Heather Adkins, VP Security Engineering di Google, e Gadi Evron, CEO di Knostic, pubblicano un avvertimento formale: gli attaccanti stanno convergendo verso un momento di singolarità, con capacità di vulnerability discovery e exploitation autonome stimate a sei mesi di distanza.

13-14 novembre 2025. Anthropic rende pubblica la disruption della campagna del gruppo GTG-1002, attore state-sponsored cinese che aveva utilizzato Claude Code, jailbreakato attraverso tecniche di role-play, per eseguire autonomamente l’80-90% delle operazioni offensive su circa 30 organizzazioni globali, tra cui tech company, istituzioni finanziarie, agenzie governative e produttori chimici. La campagna era stata rilevata a metà settembre. È il primo caso documentato di attacco informatico in larga scala orchestrato principalmente da AI con supervisione umana ridotta a decisioni strategiche chiave.

Gennaio 2026. AISLE scopre autonomamente tutte e 12 le vulnerabilità del rilascio coordinato di OpenSSL del 27 gennaio 2026, tra cui CVE-2025-15467 (stack buffer overflow in CMS AuthEnvelopedData, CVSS 9.8, un rating critico estremamente raro per OpenSSL) e tre bug risalenti al 1998-2000, alcuni dei quali presenti nel codice da prima della nascita stessa di OpenSSL, ereditati da SSLeay. In cinque casi, AISLE ha proposto le patch accettate nel rilascio ufficiale.

Febbraio 2026. Anthropic, usando Claude Opus 4.6, segnala oltre 500 vulnerabilità ad alta severità in software open source ampiamente utilizzato. Sysdig documenta come un attaccante abbia ottenuto accesso amministrativo completo a un ambiente AWS in meno di 8 minuti, partendo da credenziali esposte in un bucket S3 pubblico e usando LLM per automatizzare ricognizione, generazione di codice malevolo e decisioni in tempo reale. L’attacco era avvenuto il 28 novembre 2025. I report di bug al kernel Linux passano da 2 a 10 alla settimana: inizialmente allucinati, ora tutti verificati come reali.

Marzo 2026. La conferenza [un]prompted introduce il Zero Day Clock pubblicamente. Il progetto curl, che aveva chiuso il proprio bug bounty per eccesso di report AI di bassa qualità, inizia a registrare un’inversione: una quota crescente dei report AI è ora di alta qualità e verificata.

7 aprile 2026. Annuncio di Claude Mythos Preview e Progetto Glasswing. Secondo quanto documentato nel blog del Frontier Red Team, il modello aveva prodotto 181 exploit funzionanti sul motore JavaScript di Firefox 147 nelle stesse condizioni in cui Claude Opus 4.6 ne aveva generati soltanto due. La valutazione indipendente dell’AISI ha misurato un tasso di successo del 73% su task CTF di livello esperto, ovvero task che nessun modello riusciva a completare prima dell’aprile 2025. Il modello ha inoltre abbandonato autonomamente la propria struttura di containment durante i test, connettendosi a Internet.

Perché questo non è solo un problema di patching più veloce

La reazione istintiva di fronte a questa cronologia è tattica: accelerare il patching, rafforzare il perimetro. Il documento CSA argomenta che questa risposta, pur necessaria, manca il punto strutturale.

Ogni patch rilasciata diventa simultaneamente un blueprint per l’exploit: i sistemi di AI accelerano il patch-diffing e il reverse engineering delle correzioni in minuti. Le organizzazioni che non integrano AI nei propri processi difensivi non stanno soltanto rimediando più lentamente: stanno operando in un paradigma diverso da quello degli attaccanti.

Il documento identifica anche un problema di governance sistematicamente sottovalutato. I modelli di rischio cyber di molte organizzazioni sono costruiti su assunzioni pre-AI: finestre di patch in settimane, exploit che richiedono competenze specializzate, incidenti con frequenza gestibile. Questi modelli influenzano le decisioni del board, la reportistica finanziaria, le allocazioni di budget. Un CISO che porta al board metriche calcolate per un mondo che non esiste più espone l’organizzazione a un rischio di governance con ricadute finanziarie dirette.

Il risk register CSA: 13 rischi su framework verificati

Il cuore operativo del documento è un risk register bozza strutturato su quattro framework riconosciuti: NIST CSF 2.0, MITRE ATLAS, OWASP LLM Top 10 2025, OWASP Agentic Top 10 2026. Cinque rischi sono critici, sette alti, uno medio.

Tra i rischi critici, due vanno oltre la dimensione tecnica. Il primo è il gap nelle capacità di automazione difensiva: gli attaccanti usano agenti AI per vulnerability discovery, exploit development e orchestrazione degli attacchi, mentre molti team difensivi non dispongono ancora dei controlli di sicurezza per deployarli con fiducia. L’asimmetria risultante è, come sottolinea il documento, tanto culturale quanto tecnologica. Il secondo è il cybersecurity risk model obsoleto: metriche costruite su assunzioni pre-AI potrebbero non riflettere l’esposizione reale, portando a sottofinanziamento dei controlli e a reportistica aziendale inaccurata.

Tra i rischi alti, due meritano attenzione specifica per le organizzazioni italiane. Il rischio normativo legato all’EU AI Act in applicazione da agosto 2026: quando l’AI trova vulnerabilità a costi accessibili, lo standard di ciò che costituisce un ragionevole sforzo difensivo si sposta, con effetti diretti sulla responsabilità dei board. Il deficit di governance: senza meccanismi cross-funzionali tra Security, Legal e Engineering, ogni nuova capacità difensiva rallenta nell’approvazione, dando agli attaccanti un vantaggio temporale strutturale.

Le 11 azioni prioritarie: da questa settimana a 12 mesi

Il documento traduce il risk register in un piano con orizzonti temporali espliciti, organizzato per urgenza e non per facilità di implementazione.

Questa settimana. Le prime due azioni critiche riguardano l’integrazione degli agenti nei processi di sicurezza. La prima consiste nell’orientare agenti LLM verso il proprio codice e le proprie pipeline, partendo da una security review di qualsiasi codice esistente e costruendo verso un auditing completo del CI/CD. La seconda è la formalizzazione dell’uso degli agenti AI in tutte le funzioni di sicurezza come pratica standard, con oversight obbligatorio: i programmi di adozione volontaria non superano le barriere culturali.

Entro 45 giorni. Costruire capacità di triage e deployment per gestire un potenziale flusso di patch da tutti i vendor dell’early access di Glasswing; aggiornare modelli e metriche di rischio per riflettere le nuove tempistiche; difendere gli agenti interni, che introducono rischi di supply chain e di esposizione interna non coperti dai controlli esistenti; inventariare gli asset con priorità ai sistemi internet-facing. Per un approfondimento sui temi di gestione dei zero-day e patch management si rimanda all’analisi dedicata su questo sito.

Entro 6 mesi. Hardening strutturale: egress filtering, segmentazione profonda, Zero Trust, MFA phishing-resistant per tutti gli account privilegiati, minimizzazione del software. Il documento ricorda un dato spesso dimenticato: l’egress filtering ha bloccato ogni exploit pubblico di Log4j.

Entro 12 mesi. Costruire una funzione VulnOps permanente, modellata sul DevOps ma dedicata alla vulnerability research e remediation autonoma, con scoperta continua di zero-day nella propria codebase e in quella di terze parti, con pipeline di remediation automatizzata progettata attorno alla disciplina di triage fin dall’inizio.

Il costo umano che i CISO devono nominare

Il documento CSA adotta un approccio raro per un testo strategico di questo livello: nomina esplicitamente il costo umano della transizione invece di aggirarlo.

I team di sicurezza si trovano in una morsa reale: l’AI aumenta simultaneamente la frequenza delle vulnerability disclosure a cui devono rispondere, il volume di codice prodotto dalle organizzazioni e la superficie d’attacco complessiva. Questo avviene mentre i professionisti operano sotto incertezza circa l’evoluzione dei propri ruoli, inclusi i vulnerability researcher, che si interrogano sul proprio futuro in uno scenario dove i sistemi AI individuano autonomamente classi di vulnerabilità che richiedevano anni di specializzazione.

Il burnout non è un problema di welfare: è un rischio operativo diretto. Le competenze necessarie per navigare questa transizione richiedono anni per essere sviluppate, non sono sostituibili nel breve periodo e sono scarse a livello globale. Il documento indica esplicitamente che la resilienza del team, intesa come workload sostenibile, supporto alla salute mentale e retention, va trattata come priorità strategica con la stessa urgenza delle sfide tecniche.

La risposta proposta non è rinunciare all’expertise umana: è aumentarla. Ogni ruolo nella sicurezza sta diventando progressivamente un ruolo da “AI builder“. La barriera tecnica per iniziare è oggi più bassa di quanto la maggior parte dei professionisti realizzi: il documento afferma che usare un coding agent è oggi più semplice che usare Excel.

Le implicazioni per le organizzazioni italiane

Le implicazioni del documento per il contesto italiano si articolano su tre dimensioni.

Normativa. L’EU AI Act in applicazione da agosto 2026 introduce requisiti di cybersecurity per i sistemi AI che si sovrappongono parzialmente a NIS2 e DORA. La combinazione crea un quadro in cui le organizzazioni devono non solo dimostrare di avere controlli adeguati, ma di aver utilizzato gli strumenti disponibili, inclusi quelli AI, per la scansione difensiva. Il documento suggerisce che non farlo potrebbe configurarsi come negligenza: un’evoluzione dello standard di ragionevole diligenza che i board italiani non hanno ancora incorporato nella propria gestione del rischio.

Strutturale. La Cyber Poverty Line, concetto di Wendy Nather che identifica le organizzazioni prive delle risorse minime per difendersi efficacemente, è particolarmente rilevante in un paese dove la maggioranza delle imprese è PMI. Per queste organizzazioni, il documento indica come risposta prioritaria l’accesso alle reti di difesa collettiva: CSIRT nazionale, ACN, ISAC di settore, gruppi di condivisione dell’intelligence sulle minacce. Il Progetto Glasswing ha dimostrato che la cooperazione coordinata su scala inedita è possibile.

Operativa. Le organizzazioni italiane con esposizione significativa dovrebbero utilizzare le dieci domande diagnostiche del documento come punto di partenza: qual è la posizione reale dell’organizzazione sull’AI? Gli sviluppatori possono usare coding agent? Esiste un gate di sicurezza reale tra code change e produzione? Quando è stata l’ultima volta che l’organizzazione ha effettuato un cambio produttivo guidato dalla sicurezza in meno di 48 ore? Le risposte rivelano il gap tra policy dichiarata e capacità operativa reale.

La finestra d’azione si sta chiudendo

Il documento si chiude con un parallelo storico preciso: il problema del Y2K era una minaccia sistemica con una scadenza definita, e il settore l’ha affrontata attraverso uno sforzo coordinato e disciplinato. La differenza con la sfida attuale non è nella natura del problema: è nella velocità con cui le scadenze si accorciano.

Claude Mythos ha portato in prima pagina capacità già presenti da mesi in forma meno visibile. Il Progetto Glasswing ha aperto una finestra di vantaggio per i difensori, ma è per definizione temporanea: Anthropic stessa stima che capacità comparabili saranno disponibili da altri lab AI entro sei-diciotto mesi. La finestra non è infinita, e ogni azione descritta nel documento può iniziare questa settimana.

Per i dettagli tecnici sulle vulnerabilità specifiche scoperte da Claude Mythos e sulla struttura del Progetto Glasswing, si rimanda all’articolo: Anthropic lancia il Project Glasswing.

Condividi sui Social Network:

https://www.ictsecuritymagazine.com/notizie/claude-mythos-ciso-guida-2026/




Recovery scam: quando la truffa colpisce due volte


Nel panorama delle minacce informatiche, esiste una categoria di attacchi particolarmente insidiosa di cui si parla poco, ma che gode di pessima fama perché colpisce le vittime nel momento di maggiore vulnerabilità: le recovery scam, ovvero le truffe che promettono di recuperare il denaro già sottratto. Secondo Eset, si tratta di una strategia sempre più diffusa, che sfrutta dati, contesto e stato emotivo delle vittime per mettere a segno un secondo attacco dopo una prima estorsione (o furto) andata a buon fine.

Il principio è tanto semplice quanto efficace: chi è già stato truffato rappresenta un target ad alta probabilità di successo. Non a caso, secondo le stime più recenti, solo negli Stati Uniti si sono registrati oltre 7.000 casi nel 2024, con un danno economico superiore ai 102 milioni di dollari. E come spesso accade nel cybercrime, questi numeri rappresentano probabilmente solo una parte del fenomeno reale.

Le “sucker list”: il mercato nascosto delle vittime e come funziona la seconda truffa

Alla base delle recovery scam c’è un meccanismo ben rodato nel mondo del cybercrime: la condivisione di informazioni tra gruppi criminali. Le cosiddette “sucker list” funzionano come veri e propri database di potenziali vittime, contenenti nomi, contatti e in alcuni casi anche dettagli sul comportamento e sulla propensione a cadere in specifiche truffe.

Questi elenchi includono spesso persone che hanno già subito una frode o che hanno risposto a campagne di spam, rendendole particolarmente appetibili per nuovi attacchi. In pratica, la vittima entra in un circuito in cui viene continuamente esposta a tentativi di frode sempre più mirati.

Le recovery scam seguono schemi ricorrenti, basati su tecniche di social engineering e impersonificazione. Gli attaccanti si presentano come società di recupero crediti, autorità governative, forze dell’ordine o specialisti antifrode, dichiarando di poter recuperare il denaro sottratto.

Spesso dispongono già di informazioni dettagliate sulla truffa subita, elemento che aumenta la credibilità dell’attacco. A questo punto, la richiesta è quasi sempre la stessa: un pagamento anticipato per avviare la procedura di recupero, mascherato da commissione amministrativa, tassa o costo di gestione.

In altri casi, i criminali sostengono di aver già recuperato il denaro e chiedono dati bancari o informazioni su wallet crypto per procedere al rimborso. Questa variante è particolarmente pericolosa perché può portare a furti di identità, accessi non autorizzati ai conti e ulteriori frodi finanziarie.

Il ruolo del social engineering

Uno degli elementi chiave di queste truffe è la componente psicologica. I criminali sfruttano la frustrazione e il desiderio di recuperare il denaro perso, facendo leva su urgenza e pressione emotiva. Le comunicazioni sono spesso non richieste e arrivano tramite email, social network, SMS o telefonate.

Le promesse sono volutamente ambiziose, con garanzie di recupero o affermazioni secondo cui i fondi sarebbero già disponibili. In parallelo, vengono utilizzate tecniche di impersonificazione per simulare l’affidabilità di enti ufficiali, mentre i metodi di pagamento richiesti sono spesso difficili da tracciare, come criptovalute o gift card.

Questo mix di elementi rende la truffa particolarmente efficace, soprattutto nei confronti di utenti già colpiti in precedenza.

Difendersi da un attacco “di ritorno”

Dal punto di vista della sicurezza, le recovery scam rappresentano un’evoluzione delle tradizionali frodi advance fee, con un livello più alto di personalizzazione e targeting. La difesa passa innanzitutto dalla consapevolezza: nessun soggetto legittimo contatterà una vittima senza richiesta per offrire servizi di recupero fondi a pagamento anticipato.

È fondamentale verificare sempre l’identità di chi propone questi servizi attraverso canali indipendenti e diffidare da richieste di pagamento immediate. Allo stesso modo, la condivisione di informazioni personali o finanziarie deve essere evitata, soprattutto in contesti non verificati.

Condividi l’articolo



Articoli correlati

Altro in questa categoria


https://www.securityinfo.it/2026/04/16/recovery-scam-quando-la-truffa-colpisce-due-volte/?utm_source=rss&utm_medium=rss&utm_campaign=recovery-scam-quando-la-truffa-colpisce-due-volte




Democratized Software, Democratized Risk: Who’s Accountable When Everyone Codes?

With the rise of AI-driven coding tools, non-technical teams no longer need to rely on large teams of developers or SaaS companies to generate basic software applications.  

Much has been said of the business ramifications of the shift — its impacts on the SaaS industry in particular — but much less has been said about the vulnerabilities and governance gaps it can introduce. When you reduce the number of human touchpoints in the build process, you can move faster and spend less, but you also have to be intentional about preserving clear ownership, controls, and auditability. As a forward-looking but pragmatic CTO, I see this as a positive shift, and I also recognize the need to modernize how we manage risk when software creation becomes broadly distributed. 

If you’re an IT leader at an organization using AI to develop software, websites, or automations for internal or external use, the priority is to pair that speed with an operating model that makes ownership explicit and enforces guardrails by default. Think of it less as “slowing teams down” and more as shifting risk controls left (into design and build) and right (into runtime) with strong observability throughout. Below are practical steps you can take to do this quickly, efficiently, and at scale. 

Enforce Application Lifecycle Management 

Every application — whether built by professional developers or business users through low-code/no-code platforms — should flow through a managed delivery path. In practice, that usually means a standardized build-and-release workflow with version control, automated testing, and gated promotion across environments. Many organizations achieve this through an internal developer platform that provides “golden paths” for common app types, along with policy-as-code for approvals, secrets handling, provenance, and deployment controls. The goal is consistent traceability (who changed what, when, and why), predictable releases, and the ability to roll back safely when issues emerge. 

Look for capabilities that reduce the operational burden: automatic inventory/registration of apps and environments, consistent identity and access controls, standardized logging, and end-to-end audit trails from source to production. The best implementations make the secure path the easiest path so teams can ship quickly without creating blind spots for security, compliance, or incident response.  

Implement Mandatory Static and Dynamic Code Analysis 

All code — regardless of whether it’s written by humans, generated by AI, or assembled in a low-code tool — should be subjected to automated quality and security checks before release. Static analysis can catch common classes of defects and insecure patterns early; dynamic testing and runtime validation can uncover issues that only appear under real-world conditions. Just as important, modern pipelines should scan dependencies and configurations (including secrets, infrastructure-as-code, and container images), produce an SBOM, and record build provenance so teams can respond quickly when a vulnerability or policy violation is discovered. Results should be tied to accountable owners and stored centrally, so security and compliance teams can track risk over time. 

These safeguards aren’t new, but they matter even more when software is produced faster and by a wider set of contributors. AI-assisted development can accelerate delivery, but it doesn’t change the fundamentals: you still need repeatable engineering standards, automated verification, and clear accountability for what reaches production. 

Establish Real-Time Policy Enforcement  

To keep fast-moving teams from accidentally introducing unmanaged services, organizations should enforce runtime guardrails for the application types that matter most (APIs, data-bearing services, automations, and externally exposed endpoints). API management and service networking controls can help standardize authentication and authorization, rate limiting, and logging. Beyond that, modern policy enforcement includes strong identity, secrets management, data classification controls, and egress restrictions, paired with continuous monitoring for anomalies. Policy changes should be version-controlled, reviewed, and audited so the enforcement layer is as trustworthy as the applications it protects. 

At scale, this works best when teams have a centralized way to define guardrails and a decentralized way to ship within them. That typically means shared policy management, consistent enforcement points (for example at ingress/egress and in build pipelines), and unified telemetry that makes it easy to detect, triage, and document incidents. The emphasis should be on closing visibility gaps — knowing what exists, what it can access, how it’s behaving, and who owns it — without creating a manual approval bottleneck. 

Widespread Software Creation Demands Modern, Automated Accountability 

AI coding tools will continue to be debated, but the trajectory is clear: software creation is becoming faster and more accessible across the business. The organizations that benefit most will be the ones that treat this as an operating-model shift and invest heavily in platforms, controls, and culture that let teams move quickly without compromising safety, reliability, or compliance.  

As with every major technology shift, the winners will be the organizations that operationalize the technology well. Winning teams will combine AI-enabled speed with disciplined engineering: clear product and data ownership, secure-by-default delivery paths, continuous verification, and strong runtime visibility. Put those foundations in place, and you can safely scale software development beyond the traditional engineering org while maintaining the accountability your customers, regulators, and leadership expect.

https://www.securitymagazine.com/blogs/14-security-blog/post/102234-democratized-software-democratized-risk-whos-accountable-when-everyone-codes




Misure di sicurezza NIS2: come il Regolamento UE 2024/2690 e le specifiche ACN definiscono gli obblighi di compliance

La disciplina NIS 2 si presenta, allo stato attuale dell’attuazione europea e nazionale, come un sistema normativo multilivello, nel quale fonti eurounitarie di diverso rango si intrecciano con il recepimento interno e con atti amministrativi a contenuto tecnico-regolatorio adottati dall’autorità nazionale competente.

In tale contesto, la corretta ricostruzione dei rapporti tra direttiva (UE) 2022/2555, Regolamento di esecuzione (UE) 2024/2690, d.lgs. 138/2024 e specifiche di base ACN assume rilievo per delimitare gli obblighi di gestione del rischio, le soglie di notificazione e, più in generale, il modello di compliance richiesto agli enti. Il contributo chiarisce natura, funzione e collocazione delle diverse fonti, evidenziando come, per i soggetti rientranti nel relativo perimetro applicativo, il Regolamento europeo costituisca il parametro armonizzato per la definizione delle misure tecniche e metodologiche di sicurezza e per la qualificazione dell’incidente significativo, mentre la disciplina nazionale conserva un ruolo sul piano organizzativo, documentale e procedurale.

Le misure di sicurezza NIS2 tra requisiti europei e attuazione nazionale

La chiave interpretativa corretta, in un’ottica giuridico-sistematica, è distinguere tra atti normativi eurounitari “di base” (direttive e regolamenti), atti eurounitari “di esecuzione” e atti nazionali di recepimento e attuazione amministrativa. La NIS2, in quanto direttiva, vincola lo Stato membro sul risultato, lasciando margini di scelta quanto a forma e mezzi del recepimento; al contempo, essa contiene clausole abilitative per l’adozione di atti di esecuzione e di atti delegati su profili specifici.

Nello specifico, l’art. 21, par. 5, NIS2 prevede l’adozione di atti di esecuzione della Commissione europea per stabilire requisiti tecnici e metodologici delle misure di gestione dei rischi per determinate categorie di soggetti (tra cui DNS, cloud, data center, servizi gestiti, piattaforme online), prevedendo la procedura d’esame (comitatologia). Accanto a ciò, l’art. 24 NIS 2 contempla un potere di atti delegati per integrare la direttiva in tema di obblighi di utilizzo di categorie certificate di prodotti/servizi TIC, mostrando la distinzione funzionale tra “delegated acts” (integrazione/modifica di elementi non essenziali) e “implementing acts” (condizioni uniformi di esecuzione)[1].

Sul piano nazionale, il decreto legislativo svolge la funzione di recepimento delle previsioni della direttiva, definendo l’architettura istituzionale italiana, la delimitazione soggettiva e settoriale, gli obblighi e il regime sanzionatorio; esso, tuttavia, è anche una disciplina quadro di attuazione che abilita ulteriori fonti secondarie. In particolare, l’attuazione è completata mediante decreti del Presidente del Consiglio dei ministri su aspetti specifici (art. 40), tra cui sono già stati adottati atti attuativi e su criteri di clausola di salvaguardia ex art. 3, commi 4 e 12 (vedi DPCM GU 10 febbraio 2025).

Parimenti, risultano atti di settore che danno attuazione all’art. 11 del decreto, designando la Presidenza del Consiglio dei ministri quale autorità di settore NIS in ambiti determinati (ad esempio gestione dei servizi TIC, spazio, pubbliche amministrazioni, società in house/controllo pubblico). Tale stratificazione nazionale è rilevante perché colloca le determinazioni tecniche dell’autorità competente in un contesto che, sebbene amministrativo, è funzionalmente normativo: esso produce obblighi generalizzati e verificabili verso una pluralità indeterminata di destinatari.

Reg. (UE) 2024/2690: oggetto, ambito e tecnica normativa

Il Regolamento, adottato il 17 ottobre 2024, dichiara nel suo art. 1 un duplice oggetto: fissare requisiti tecnici e metodologici delle misure di gestione dei rischi di cui all’art. 21, par. 2, NIS 2 e specificare ulteriormente i casi in cui un incidente è “significativo” ai sensi dell’art. 23, par. 3, NIS2, limitatamente ai “soggetti pertinenti” individuati dal regolamento stesso. L’ambito soggettivo è dunque funzionale alla ratio dell’atto: coprire il cuore dell’ecosistema digitale europeo, in cui la compromissione o indisponibilità di servizi infrastrutturali (DNS, TLD), di servizi cloud e di data center, di CDN, di managed services e managed security services, e di piattaforme online può produrre effetti a cascata transfrontalieri.

Il regolamento si caratterizza per la tecnica normativa adottata: da un lato, articoli che fissano criteri oggettivi di significatività di un incidente (artt. 3–14) con soglie quantitative; dall’altro, un allegato che organizza requisiti tecnici e metodologici per ciascuna categoria dell’art. 21, par. 2, NIS2, strutturandoli in un impianto altamente analitico.

Assai rilevante, dal punto di vista della proporzionalità e di accountability, che lo stesso regolamento incorpori una clausola di adattabilità metodologica. L’art. 2, oltre a ribadire la necessità di un livello di sicurezza adeguato ai rischi[2] e di considerare esposizione, dimensioni, probabilità e gravità degli incidenti, prevede espressamente che, ove l’allegato richieda l’applicazione di un requisito “se opportuno”, “se applicabile” o “nella misura del possibile”, il soggetto che ritenga non opportuna/applicabile/possibile l’applicazione debba documentare in modo comprensibile le ragioni della decisione.

Con riferimenti ai criteri per la classificazione di un incidente come significativo, l’art. 3, par. 1, fornisce evidenza di una maggiore “oggettivazione” di tali criteri rispetto alle tassonomie nazionali basate su categorie di evento. Si tratta di una scelta che riduce l’area grigia interpretativa: l’incidente “significativo” è perimetrato mediante soglie e condizioni verificabili, includendo anche la disciplina degli “incidenti ricorrenti” (art. 4) e l’esclusione di interruzioni programmate e manutenzioni pianificate.

Confronto giuridico e tecnico tra specifiche di base ACN e Reg. (UE) 2024/2690

Il confronto deve essere condotto lungo assi distinti, perché il rischio di equivoco deriva dal sovrapporre “tecnicità” e “gerarchia”, “ampiezza” e “prescrittività”.

Sotto il profilo della natura giuridica e della collocazione gerarchica, il Reg. (UE) 2024/2690 è un regolamento di esecuzione adottato per assicurare condizioni uniformi di esecuzione di obblighi NIS2, e in quanto regolamento europeo esso è direttamente applicabile. La sua vincolatività non è mediata dal diritto interno: esso entra nel patrimonio normativo applicabile agli operatori dei settori indicati e l’Autorità nazionale è tenuta a farne applicazione nel proprio enforcement, anche come criterio tecnico-giuridico per verificare l’adempimento degli obblighi di gestione del rischio e di segnalazione.

Le “specifiche di base” nazionali, invece, sono state adottate mediante determinazione del direttore generale dell’Agenzia per la cybersicurezza nazionale in attuazione di una base legale nazionale (artt. 31, commi 1 e 2, e 40, comma 5, lett. l, del decreto NIS, richiamati testualmente nella Determinazione n. 379907/2025) sono dotate di efficacia vincolante in base alla “delega” contenuta nel decreto con cui si attribuisce all’autorità il potere di “stabilire” obblighi proporzionati e di fissare, in prima applicazione, modalità e specifiche di base[3].

Passando invece ai contenuti, dal confronto tra l’allegato del Regolamento e le specifiche di base ACN per i soggetti NIS essenziali emerge che i due testi non si pongono sullo stesso piano redazionale né sul medesimo livello di dettaglio. Il Regolamento costruisce un catalogo tecnico-metodologico unitario, articolato in tredici famiglie di controlli, con un livello di prescrittività molto elevato soprattutto sulle modalità di attuazione delle misure; le specifiche di base, invece, traducono tali esigenze in una griglia di requisiti minimi operativi, fortemente orientati alla governance, alla documentazione e alla dimostrabilità organizzativa dell’adempimento.

Sotto il profilo della governance e della compliance interna, la normativa nazionale appare per alcuni aspetti più penetrante. Essa insiste in modo molto marcato sull’adozione formale di politiche per singolo ambito, sull’approvazione da parte degli organi di amministrazione e direttivi, sulla tenuta di registri aggiornati, sulla formalizzazione di piani dedicati e sulla tracciabilità del riesame. Questa impostazione è coerente con il Regolamento, che già pretende una policy di sicurezza dei sistemi informativi e di rete, l’indicazione dei ruoli, degli indicatori di monitoraggio e la revisione periodica con documentazione dell’esito, ma il documento nazionale accentua la dimensione probatoria e organizzativa dell’obbligo, trasformando molti principi in deliverable documentali verificabili.

Sul piano strettamente tecnico la profondità del Regolamento è nettamente superiore in diversi ambiti (ciclo di vita dello sviluppo sicuro, gestione della configurazione, change management, ecc.), mentre le specifiche di base – probabilmente proprio per la loro stessa natura di essere “di base” – coprono questi stessi domini spesso per nuclei essenziali. Ne deriva che il testo nazionale è mediamente meno profondo e meno analitico del Regolamento, il quale richiede un livello di maturità tecnica più sofisticato.

La stessa asimmetria si coglie nella continuità operativa e nella resilienza. A livello nazionale sono richiesti piani distinti di continuità operativa, disaster recovery e gestione delle crisi, con approvazione formale e riesame periodico; a livello europeo è specificato con maggior dettaglio il contenuto di tali adempimenti, includendo obiettivi di ripristino, completezza e correttezza dei backup ecc. Anche qui, dunque, il documento nazionale è più “amministrativo” nella struttura dell’obbligo, mentre il regolamento è più “tecnico” nella sostanza del presidio.

Nell’ambito della supply chain il quadro è più equilibrato, ma con una differenza di accento. Il Regolamento si focalizza di più sulla sicurezza della catena di approvvigionamento, richiedendo criteri di selezione dei fornitori, clausole contrattuali specifiche su notifiche, audit, vulnerabilità, subappalto e cessazione del rapporto, oltre a processi di acquisizione sicura di servizi e prodotti TIC lungo l’intero ciclo di vita. ACN, da parte sua, appare particolarmente attenta all’integrazione della sicurezza nei procedimenti di approvvigionamento, anche pubblicistici, al coinvolgimento dell’organizzazione per la sicurezza informatica già nella fase di definizione della fornitura, all’inventario dei fornitori critici e all’inserimento dei requisiti di sicurezza nella documentazione di gara e nei contratti.

Significativo sul punto, è l’approccio che un ente, soggetto ad entrambe le normative, dovrebbe avere: dato che il Regolamento è direttamente applicabile in tutti i suoi elementi, dovrebbe essere considerato come obiettivo di compliance: le specifiche di base in questo senso vanno considerate come un passaggio intermedio per raggiungerlo. Ne discende che, una volta implementate le misure di sicurezza entro ottobre 2026, il percorso di adeguamento dovrà tendere verso le misure del Regolamento.

L’incidente significativo e l’incidente significativo “di base”

Un punto di frizione potenziale riguarda la qualificazione di “incidente significativo”. Le specifiche di base ACN definiscono per i soggetti importanti tre categorie di incidenti significativi “di base” (IS-1 perdita di riservatezza verso l’esterno; IS-2 perdita di integrità con impatto verso l’esterno; IS-3 violazione dei livelli di servizio attesi, basata sugli SL definiti nella misura DE.CM-01). Per i soggetti essenziali, la tassonomia include le medesime categorie e aggiunge IS-4, relativo all’evidenza di accesso non autorizzato o con abuso dei privilegi a dati digitali.

Le categorie individuate da ACN costruiscono una soglia di emersione dell’incidente significativo particolarmente anticipata e, in termini applicativi, assai bassa: tale soglia non richiede, almeno dal dato letterale, una soglia minima quantitativa di soggetti coinvolti o valutazioni circa l’impatto economico dell’incidente: ne deriva che anche la compromissione riferibile a un solo utente, a un solo dato o a una sola posizione individuale potrebbe integrare l’obbligo di segnalazione, purché ricada nella categoria descritta.

In tal senso la disciplina nazionale introdotta nelle specifiche di base, eliminando i requisiti quantitativi e non offrendo però criteri di valutazione dell’incidente (come, in verità, sembrerebbe richiesto anche dal testo del decreto legislativo NIS2) appare molto più prudenziale e anticipatoria, trasformando in incidente significativo notificabile anche eventi di estensione estremamente circoscritta, senza subordinare la rilevanza dell’evento a parametri dimensionali come invece avviene, in più punti, nel Regolamento.

Nello specifico, infatti, il Regolamento tipizza la dimensione quantitativa e l’impatto, includendo soglie temporali di indisponibilità e criteri economici e di utenza, oltre a definire regole su incidenti ricorrenti e su metriche di calcolo: per i soggetti pertinenti, si considera significativo un incidente per ragioni economiche (perdita finanziaria diretta superiore a 500.000 euro o al 5% del fatturato), per esfiltrazione di segreti commerciali, per eventi con conseguenze su salute o vita, per accesso non autorizzato sospettato malevolo in grado di causare gravi perturbazioni operative, oltre che in base a criteri specifici per tipologia di servizio (artt. 5–14).

A parità di “evento”, quindi, la qualificazione di significatività può divergere.

Entrando nel dettaglio, il problema (in teoria) non si pone in tutte le ipotesi in cui nel sistema delineato dal Regolamento, la perdita di riservatezza o la compromissione dell’integrità dei dati non presuppone necessariamente, ai fini della significatività dell’incidente, un impatto diffuso su una pluralità di utenti. Ciò accade, in particolare, in tutte le ipotesi nelle quali il legislatore unionale descrive la compromissione in termini qualitativi, senza ancorarla a soglie percentuali o numeriche minime, come avviene in presenza di un’azione sospettata malevola.

Diversamente, quando il Regolamento collega la compromissione della riservatezza, dell’integrità o dell’autenticità a un impatto su oltre il 5% degli utenti dell’Unione, o su oltre un milione di utenti, ovvero, per i servizi fiduciari, su oltre lo 0,1% degli utenti o delle relying parties o su oltre 100 soggetti, la significatività non è più compatibile con un pregiudizio riferibile a una sola persona, ma richiede, per definizione normativa, una propagazione dell’effetto lesivo oltre una soglia quantitativa determinata.

Ora, la compresenza, nel sistema NIS 2, della tassonomia nazionale ACN e dei criteri di significatività dettati dal Regolamento impone, soprattutto per i soggetti rientranti nell’ambito di applicazione di quest’ultimo, una lettura coordinata che eviti tanto la disapplicazione integrale della disciplina interna quanto l’attribuzione a quest’ultima di un effetto sostanzialmente derogatorio rispetto alla fonte unionale.

Il giurista attento avrà già compreso che ci si trovi di fronte ad un’antinomia, ossia un conflitto tra norme che dovrebbe essere risolto disapplicando il diritto interno a favore di quello unionale, in virtù del primato del diritto europeo e di gerarchia delle fonti.

Tale approccio potrebbe però risultare semplicistico alla luce del fatto che, in primo luogo, potrebbe esporre l’ente a un contrasto con l’Autorità e, inoltre, trascurare il disposto dell’art. 5 della direttiva NIS 2, il quale garantisce la facoltà per gli Stati membri “di adottare o mantenere disposizioni che garantiscano un livello più elevato di cibersicurezza, a condizione che tali disposizioni siano coerenti con gli obblighi degli Stati membri stabiliti dal diritto dell’Unione”. Sul punto, è possibile fornire due interpretazioni: o si considera la soglia interna come coerente con il diritto unionale in quanto volta ad estendere l’obbligo di notifica, oppure la si considera contraria alla ratio del Regolamento[4].

In tale prospettiva, il fatto che ACN qualifichi espressamente le categorie IS-1, IS-2, IS-3 e IS-4 come “incidenti significativi di base” deve essere inteso nel senso che, sul piano dell’ordinamento nazionale e del circuito procedurale ACN-CSIRT, tali fattispecie sono già di per sé idonee a far emergere l’obbligo di segnalazione e notifica; ciò non esclude, tuttavia, che, per i soggetti disciplinati anche dal Regolamento la nozione di incidente significativo in senso armonizzato resti governata dai criteri unionali, che il Regolamento stesso presenta come ulteriori ed “esaustivi”[5] per il proprio perimetro soggettivo.

Ne consegue che il coordinamento preferibile è quello bifasico: le categorie IS operano come soglia nazionale anticipata di emersione dell’evento e di attivazione cautelativa del procedimento, mentre la soglia unionale opera come parametro di significatività certa in senso pieno; pertanto, ove un incidente ricada in una delle categorie IS ma resti sotto la soglia unionale, la soluzione più prudente non è omettere la notifica, bensì procedere comunque alla comunicazione ad ACN, chiarendo che essa è effettuata in ossequio alla tassonomia nazionale e in chiave conservativa, ferma restando la distinta valutazione della significatività unionale dell’evento[6].

Una simile impostazione consente di conservare entrambe le discipline, attribuendo alla fonte europea la definizione sostanziale e armonizzata della significatività e alla disciplina nazionale una funzione di presidio anticipato e di supporto nella gestione dell’incident in coerenza con le funzioni dello CSIRT Italia. Ne consegue che l’evento sottosoglia unionale non dovrà essere trattato come irrilevante, ma come incidente comunque notificabile sul piano interno anche ai fini della richiesta di intervento del CSIRT Italia a norma dell’art. 24 del Decreto.

È, invece, possibile una lettura coordinata delle normative con riguardo alle ipotesi di indisponibilità di un servizio, che diventa significativa, ai sensi del Regolamento, superata una certa soglia temporale o in caso di impatto su un numero elevato di utenti, mentre la tassonomia nazionale, fondata su “violazione degli SL”, richiede prima la definizione e documentazione dei livelli attesi, con potenziale maggiore rimessione all’autonomia organizzativa della soglia di significatività.

Ne deriva che la categoria IS-3 può rivelarsi, a seconda dei casi, tanto più estesa quanto più restrittiva rispetto alla disciplina unionale: più estesa, ove il soggetto abbia definito SL particolarmente rigorosi e granulari, così facendo emergere come notificabili anche disservizi che non raggiungono ancora la soglia europea; più restrittiva, ove invece gli SL interni siano formulati in termini più generici o meno esigenti rispetto ai criteri fissati dal regolamento.

Proprio per tale ragione, per i soggetti ricadenti nel perimetro applicativo del Regolamento, l’IS-3 non può essere intesa come criterio sostanziale alternativo di significatività dell’incidente, ma soltanto come meccanismo nazionale di rilevazione dell’evento, destinato a cedere ogniqualvolta la sua applicazione conduca a risultati incompatibili con la soglia armonizzata di indisponibilità dettata dal diritto dell’Unione: in altre parole, oltre la soglia unionale l’incidente è sicuramente significativo; al di sotto, non è detto che sia sicuramente non significativo per il sistema nazionale di notifica verso ACN, perché la disciplina italiana opera anche con una logica prudenziale e di emersione anticipata degli eventi.

Conclusioni

In conclusione, la disciplina NIS2, così come oggi si presenta nell’interazione tra direttiva, Regolamento, decreto di recepimento e specifiche di base ACN richiede un’interpretazione sistematica e coordinata, capace di distinguere il piano gerarchico, quello funzionale e quello operativo degli obblighi. Per i soggetti rientranti nel perimetro del Regolamento (UE) 2024/2690, quest’ultimo costituisce il parametro unionale direttamente applicabile per la definizione armonizzata delle misure di gestione del rischio e della significatività degli incidenti; al tempo stesso, le specifiche di base ACN conservano una funzione normativa rilevante sul versante organizzativo, documentale e procedurale, e possono essere lette, nei limiti della coerenza con il diritto dell’Unione, come strumenti di emersione anticipata, presidio prudenziale e rafforzamento dell’accountability.

Ne deriva che l’ente dovrebbe impostare la compliance secondo un modello integrato: il Regolamento quale soglia armonizzata e sostanziale minima inderogabile per i soggetti pertinenti, e la disciplina nazionale quale livello interno di attuazione, presidio e cautela, particolarmente rilevante nei rapporti con l’Autorità nazionale competente. In questa prospettiva, la soluzione più difendibile è dunque quella che assume il diritto unionale come criterio ultimo di qualificazione dell’obbligo, valorizzando al contempo la disciplina nazionale come presidio organizzativo e prudenziale.

Riferimenti primari

Trattato sul funzionamento dell’Unione europea (TFUE);

Direttiva (UE) 2022/2555;

Regolamento di esecuzione (UE) 2024/2690;

D.lgs. 4 settembre 2024, n. 138;

Determinazione ACN n. 164179/2025;

Determinazione ACN n. 379887/2025;

Determinazione ACN n. 379907/2025

Note

[1] Questa distinzione, a livello di diritto primario, deriva dagli artt. 290 e 291 TFUE: l’art. 290 consente di delegare alla Commissione il potere di adottare atti non legislativi di portata generale che integrano o modificano elementi non essenziali dell’atto legislativo, mentre l’art. 291 disciplina gli atti di esecuzione quando sono necessarie condizioni uniformi di esecuzione degli atti giuridicamente vincolanti dell’Unione.

Nel caso del Reg. (UE) 2024/2690, la matrice è precisamente quella dell’art. 291 TFUE, poiché l’atto stabilisce requisiti uniformi per l’attuazione di obblighi NIS2 su un sottoinsieme di operatori transfrontalieri e ad alta concentrazione di rischi sistemici.

[2] In riferimento all’analisi del rischio vale anche qui quanto detto a proposito della normativa italiana, in cui la stessa non serve tanto a determinare le misure di sicurezza, già individuate dal legislatore, quanto a determinarne la portata. Per approfondire si veda quanto scritto in precedenza sul punto: https://www.ictsecuritymagazine.com/articoli/adempimenti-nis2/

[3] Esse si atteggiano, sul piano del diritto amministrativo, come atti generali a contenuto tecnico, idonei a incidere su posizioni giuridiche di una pluralità indeterminata di destinatari.

[4] Tale interpretazione sarebbe avallata inoltre dal fatto che l’art. 24, comma 4, del Decreto, prescrive, riproducendo quanto disposto da NIS2, che l’incidente sia considerato significativo se: a) ha causato o è in grado di causare una grave perturbazione operativa dei servizi o perdite finanziarie per il soggetto interessato; b) ha avuto ripercussioni o è idoneo a provocare ripercussioni su altre persone fisiche o giuridiche causando perdite materiali o immateriali considerevoli. Ne consegue che un’interpretazione volta ad estendere l’ambito di notifica sarebbe contra legem.

[5] l’esaustività emerge dal considerando 30 del Regolamento e riguarda i casi in cui un incidente è considerato significativo ai fini dell’art. 23, par. 3, della direttiva NIS 2, per i soggetti compresi nel suo perimetro. Per completezza si riporta il testo del considerando: “Il presente regolamento deve specificare ulteriormente i casi in cui un incidente dovrebbe essere considerato significativo ai fini dell’articolo 23, paragrafo 3, della direttiva (UE) 2022/2555. I criteri dovrebbero essere tali da consentire ai soggetti pertinenti di valutare se un incidente è significativo, al fine di notificarlo conformemente alla suddetta direttiva.

I criteri fissati nel presente regolamento dovrebbero inoltre essere considerati esaustivi, fatto salvo l’articolo 5 della direttiva (UE) 2022/2555. Il presente regolamento specifica i casi in cui un incidente dovrebbe essere considerato significativo stabilendo casi orizzontali e specifici per tipo di soggetto”.

[6] Un’ulteriore interpretazione, rafforzativa della prevalenza della norma unionale, focalizza l’attenzione anche sulla specialità del Regolamento. Lo stesso, oltre che gerarchicamente superiore, è destinato ad una specifica platea di soggetti, potendo ritenersi che. atteso il principio di prevalenza della legge speciale sulla generale, i soggetti su cui gravano gli obblighi del Regolamento devono intendersi esonerati dal dover svolgere delle comunicazioni in caso di incidente al di sotto della soglia unionale

Profilo Autore

Avvocato, senior partner di Qubit Law Firm & Partners, studio specializzato nella consulenza nel settore digitale. Si occupa di diritto della tecnologia da oltre vent’anni, è Data Protection Officer di società multinazionali e professore a contratto in “Diritto dell’informazione e della IA” presso l’Università della Pace in sede ONU, e di “Diritto e gestione della pubblica amministrazione digitale” presso l’Università Europea di Roma. E’ altresì coordinatore della sezione Privacy e Compliance del Centro di Ricerca Economica e Giuridica nonché Vicepresidente del Comitato Strategico del Centro di Ricerca sull’Amministrazione Digitale presso l’Università degli Studi di Roma Tor Vergata, Dipartimento di Management.

Profilo Autore

Avvocato e Associate presso Qubit Law Firm & Partners, studio specializzato nella consulenza legale nel settore digitale. Supporta le organizzazioni nella definizione di percorsi di compliance integrata, volti a coordinare gli obblighi in materia di sicurezza informatica – con particolare riferimento alle discipline introdotte da NIS2 e DORA – con la normativa sulla protezione dei dati personali e con i modelli organizzativi ai sensi del D.Lgs. 231/2001.

Condividi sui Social Network:

https://www.ictsecuritymagazine.com/articoli/misure-di-sicurezza-nis2/