Chi sorveglia chi? Il breach del Consiglio d'Europa e le zone grigie del perimetro cyber europeo

A giugno 2026 il gruppo ShinyHunters ha rivendicato un attacco al Consiglio d'Europa: secondo gli stessi attaccanti, oltre 429.000 documenti e 297 GB di dati — buste paga, fascicoli del personale, CV, dati fiscali, bancari e medici — esfiltrati sfruttando una vulnerabilità zero-day in Oracle PeopleSoft. Ma il dettaglio più interessante non è la dimensione del bottino: è che questo bersaglio cade in una zona grigia della governance cyber europea.

Il fatto

La vulnerabilità e la campagna PeopleSoft sono un fatto accertato; il coinvolgimento specifico del Consiglio d'Europa resta invece una rivendicazione degli attaccanti non confermata dalla vittima. CVE-2026-35273 è una falla di esecuzione di codice remoto non autenticata in Oracle PeopleSoft (componente Environment Management, CVSS 9.8): Oracle ha pubblicato un advisory straordinario il 10 giugno 2026, segno che era già sfruttata come zero-day. Il Google Threat Intelligence Group / Mandiant attribuisce la campagna al cluster che traccia come UNC6240 (ShinyHunters), con attività osservata tra il 27 maggio e il 9 giugno e oltre 100 organizzazioni notificate — circa il 68% delle quali università.

Sul Consiglio d'Europa, invece, siamo nel campo delle rivendicazioni. Il gruppo sostiene — dichiarazioni rese a The Register e pubblicate sul proprio sito di leak — di aver esfiltrato 297 GB e 429.000 file: buste paga di oltre 10.000 dipendenti (2011-2026), più di 14.000 CV, dati fiscali, bancari e medici. Il Consiglio d'Europa si è limitato a dichiarare di "stare indagando e valutando la situazione". I numeri, quindi, vanno trattati come presunti.

Ma anche al netto delle cifre, il caso è istruttivo per una ragione che ha poco a che fare con la dimensione del furto: mostra una crepa nella governance cyber europea.

La trappola dei nomi

Sgombriamo un equivoco diffuso. Il Consiglio d'Europa (Council of Europe) non è un'istituzione dell'Unione Europea. È un'organizzazione internazionale autonoma con sede a Strasburgo, 46 Stati membri, nata nel 1949, custode della Convenzione europea dei diritti dell'uomo. Non va confuso con il Consiglio dell'Unione Europea né con il Consiglio europeo, che sono invece organi dell'UE.

Sembra una pedanteria. Non lo è: dal "club" a cui un'organizzazione appartiene dipende quale rete di sicurezza la copre.

I tre perimetri — e dove cade il Consiglio d'Europa

L'Europa ha costruito due perimetri normativi distinti per la cybersicurezza:

NIS2 (Direttiva UE 2022/2555) — copre i soggetti essenziali e importanti negli Stati membri: energia, trasporti, sanità, finanza, PA, infrastrutture digitali. È il perimetro di imprese e amministrazioni nazionali.
Regolamento (UE, Euratom) 2023/2841 — in vigore dal 7 gennaio 2024, è l'equivalente della NIS2 per le istituzioni, organi e agenzie dell'Unione (EUIBA): Commissione, Parlamento europeo, Consiglio dell'UE, agenzie. Ha rafforzato CERT-EU e creato l'Interinstitutional Cybersecurity Board (IICB) che ne vigila l'attuazione.

CERT-EU è proprio l'organo che verrebbe in mente pensando "ma chi sorveglia la sicurezza delle istituzioni europee?". La risposta, però, vale solo per gli EUIBA. Il Consiglio d'Europa non rientra in nessuno dei due perimetri:

non rientra nel perimetro ordinario NIS2 in quanto organizzazione internazionale autonoma, non ente nazionale individuato da uno Stato membro né entità dell'Unione;
non è coperto dal Reg. 2023/2841 né da CERT-EU (non è un'istituzione dell'UE);
provvede alla propria sicurezza per conto suo, fuori dalla rete di sicurezza cyber dell'Unione.

In altre parole: CERT-EU e IICB non hanno un mandato ordinario di vigilanza sul Consiglio d'Europa — il loro perimetro riguarda le entità dell'Unione. Restano possibili forme di cooperazione, ma non una copertura automatica come per gli EUIBA. Un'organizzazione paneuropea che custodisce dati sensibilissimi di 46 Stati cade fra le crepe di NIS2 e del regolamento sulle istituzioni UE.

Cosa direbbe NIS2 a chi invece è dentro il perimetro

Qui sta il valore del caso per imprese e amministrazioni che la NIS2 riguarda eccome. Lo stesso attacco — zero-day su un ERP/HR di terze parti — proietta quattro obblighi NIS2 molto concreti:

Gestione delle vulnerabilità — Art. 21(2)(e). Il vettore è una falla in un prodotto di terze parti. NIS2 impone misure in acquisizione, sviluppo e manutenzione sicura, inclusa la gestione delle vulnerabilità: chi usa quel software deve avere un patch management che reagisce in ore, e deve poterlo dimostrare.
Sicurezza della supply chain — Art. 21(2)(d). Una sola vulnerabilità ha (secondo le rivendicazioni) aperto 100+ organizzazioni. È il rischio-fornitore che NIS2 chiede di governare e documentare.
Detection e tempi. Tra l'inizio dello sfruttamento e la minaccia di pubblicazione passano settimane. NIS2 (Art. 21) richiede monitoraggio, logging e incident handling: il punto debole non è solo la patch mancante, ma il tempo di rilevamento.
Obbligo di notifica — Art. 23. Per i soggetti colpiti scatta la catena verso il CSIRT: early warning entro 24 ore, notifica entro 72 ore, relazione finale entro un mese — in parallelo con gli obblighi GDPR (Art. 33/34), qui pesantissimi vista la natura dei dati.

La lezione

Per i decisori: il perimetro normativo non coincide con il perimetro del rischio. Esistono organizzazioni — e dati — che restano fuori da NIS2 e dal regolamento sulle istituzioni UE pur essendo bersagli di prima grandezza. Sapere in quale "club" si è, e quale rete di sicurezza si applica, è il primo atto di governance.

Per chi nella NIS2 c'è dentro: essere soggetti a un obbligo non significa essere sicuri. La policy di patching nel cassetto non avrebbe fermato questo attacco. Serve la prova continua che i controlli siano davvero attivi — patch applicate, monitoraggio funzionante, supply chain mappata. È la differenza tra compliance documentale e sicurezza verificata.