Ottantasette minuti, ricostruiti con una settimana di ritardo

L'intrusione vera e propria è durata circa 87 minuti nelle prime ore del 27-28 luglio 2026. Secondo il direttore tecnico David Simpson, una chiave di accesso AWS era esposta dentro artefatti di compilazione JavaScript serviti direttamente dal sito pubblico di Beacon, cioè proprio il pacchetto che il browser di qualsiasi visitatore scarica senza far scattare alcun allarme.

Beacon non ha rilevato l'intrusione in tempo reale. Secondo Simpson, l'azienda ha ricostruito l'accaduto solo a posteriori, analizzando i report di costo e utilizzo AWS da maggio a luglio 2026, trovando un picco dei costi di trasferimento dati proprio nei due giorni in questione, una prova coerente con l'attività di download piuttosto che con un sistema di rilevamento attivo in tempo reale.

Questo metodo retrospettivo spiega il ritardo nella comunicazione: la violazione è avvenuta il 27-28 luglio, Beacon ha informato i clienti il 4 agosto e ha pubblicato un aggiornamento il 13 agosto che non ha ancora chiarito tutte le domande. Simpson ha detto direttamente ai clienti che ci sono cose che forse non si sapranno mai su questo incidente, promettendo ulteriori dettagli nelle settimane successive.

Chi è davvero esposto

La base clienti di Beacon supera già i 1.500 enti benefici, e l'azienda ha dichiarato esplicitamente di non aver ancora stabilito a quanti siano stati sottratti dati, solo che è stata realizzata una copia completa del database, file allegati compresi, quasi certamente scaricata in chiaro.

Però The Register indica organizzazioni specifiche colpite, tra cui Molly Rose Foundation, Macmillan Cancer Support Jersey, English National Ballet, Sheffield Hospitals Charity, Shrewsbury and Telford Hospital Charity, British Deaf Association e Lincoln Cathedral, un ventaglio che va dal sostegno al lutto alla raccolta fondi ospedaliera, fino alla tutela delle persone sorde e al patrimonio culturale.

Però non si tratta di dati clinici come quelli di un ospedale in senso stretto, ma i dati di donatori e sostenitori di questo tipo di organizzazioni riguardano regolarmente persone in lutto, malattia o crisi, esattamente la popolazione che un titolare del trattamento dovrebbe proteggere con più cura, non meno, rispetto a una semplice lista di indirizzi.

Il vuoto che DORA e NIS2 dovevano colmare, ma non raggiungono

Il regolamento europeo DORA obbliga gli enti finanziari, in base agli articoli da 28 a 30, a tenere un registro di ogni fornitore ICT terzo e a valutarne il rischio, proprio perché la postura di sicurezza di un fornitore venga verificata prima di un incidente, non dopo. Il NIS2 impone obblighi comparabili di sicurezza e segnalazione a soggetti essenziali e importanti nei settori dell'energia, della sanità, delle infrastrutture digitali e della pubblica amministrazione.

Gli enti benefici e i fornitori SaaS che li servono restano completamente fuori da entrambi i regimi. La loro unica rete di sicurezza è il principio generale di responsabilità del GDPR britannico, che rende comunque l'ente responsabile del trattamento anche quando il prodotto di un responsabile esterno fallisce, oltre alla procedura volontaria di segnalazione della Charity Commission, che il regolatore stesso descrive come una definizione delle priorità in base al rischio, non una gestione simultanea di tutte le segnalazioni.

Ecco però la lettura di Servola che non compare in nessun singolo articolo: una chiave dimenticata in un JavaScript pubblico è esattamente il tipo di difetto elementare di igiene dei segreti che il test di intrusione obbligatorio e la tracciabilità degli audit del DORA esistono per intercettare presso un fornitore regolato prima della firma del contratto. Togliete quel regime, come già accade nel terzo settore, e la verifica che sarebbe dovuta avvenire in fase di acquisto avviene ora a posteriori, una segnalazione alla volta presso la Charity Commission.

Cosa dovrebbe chiedere un ente benefico prima di rinnovare

La risposta pratica, però, non richiede una nuova legge. Qualsiasi ente che firma o rinnova un contratto SaaS può chiedere direttamente al fornitore prove di scansione automatica dei segreti nella propria pipeline di compilazione, un impegno scritto sui tempi di risposta agli incidenti, e la conferma di quali campi su donatori o beneficiari siano davvero necessari e quali solo comodi.

Lo schema, però, non riguarda solo Beacon. Le violazioni dei fornitori causate da errori elementari di igiene delle credenziali, dall'incidente di social engineering di RingCentral tuttora inspiegato alla compromissione del fornitore logistico di Trezor e ShipMonk, si ripetono perché le garanzie di sicurezza della catena di fornitura pensate per settori regolati non si estendono automaticamente ai settori adiacenti che acquistano la stessa classe di strumenti con una frazione del budget di sicurezza e senza alcuna leva contrattuale.

Però finché quella leva non esisterà per gli enti benefici come esiste per le banche sotto il DORA, la segnalazione volontaria presso la Charity Commission svolge il lavoro di controllo che nessun regolatore esterno è oggi in grado di assumersi, un'organizzazione sottodimensionata e una segnalazione alla volta.

Da leggere ora: 45.601 falle, solo 171 vengono davvero usate  |  Un solo messaggio ha raggiunto le chiavi SSH