Si è avuta notizia che, qualche giorno fa, i sistemi di emergenza sanitaria e di pubblica sicurezza della provincia di Treviso sono stati messi sotto stress da un comportamento inconsapevole di un bambino di quattro anni.
Questi, mentre si trovava in un asilo a Oderzo, interagendo con uno smartwatch, ha generato una raffica di chiamate mute ai numeri 112 e 118. La centrale operativa ha ricevuto oltre settanta segnalazioni in un’ora, determinando una saturazione delle linee critiche e costringendo le forze dell’ordine a intervenire fisicamente per identificare la fonte del disturbo.
Questo episodio sembra rivelare una falla di sistema: non serve un attacco informatico coordinato per compromettere un servizio essenziale. Talvolta, basta una combinazione non prevista di tecnologia, accesso inconsapevole e mancanza di barriere logiche. Un evento simile, in un contesto diverso, avrebbe potuto causare ritardi fatali.
L’urgenza è, quindi, duplice: ripensare la progettazione dei sistemi critici e applicare una logica di sicurezza proattiva, come richiesto dalla normativa europea e dagli standard internazionali.
Indice degli argomenti
Un evento, molteplici vulnerabilità
Il caso sembrerebbe sollevare almeno cinque criticità strutturali, che sono:
- l’assenza di meccanismi di rilevamento automatico di comportamenti anomali e ripetitivi (es. 70 chiamate mute da un solo numero);
- la debolezza delle logiche di autenticazione o filtro per dispositivi smart destinati a utenti vulnerabili (bambini, anziani, malati);
- la saturazione dei canali di comunicazione in assenza di una gestione intelligente della priorità degli eventi;
- una reazione solo manuale del sistema, senza strumenti di mitigazione autonoma;
- la dipendenza da dispositivi consumer non progettati per interoperare in contesti di emergenza.
Tuttavia, la criticità più significativa sembra non risiedere tanto nel dispositivo sorgente, quanto nell’architettura di ricezione dei sistemi di emergenza, la cui resilienza si è dimostrata insufficiente di fronte a un flusso anomalo e ripetitivo.
Il vero punto di vulnerabilità sembra essersi manifestato a livello delle interfacce di ingresso (input interfaces) delle centrali operative 112 e 118, ossia nei front-end applicativi incaricati della gestione e del filtraggio iniziale del traffico voce/dati.
È in questa fase di ingresso – e non nella trasmissione dati in uplink dal device – che probabilmente sarebbe stato necessario un sistema di identificazione e contenimento automatico del comportamento anomalo, in linea con i principi di sicurezza proattiva promossi dalla Direttiva NIS 2 e dagli standard di gestione del rischio (ISO/IEC 27005).
Prevenzione: l’origine dei disastri è spesso banale
A monte dell’incidente, emerge una causa scatenante apparentemente semplice, ma strutturalmente significativa: la possibilità per un bambino di accedere liberamente a uno smartwatch con funzionalità di chiamata in un ambiente educativo, come l’asilo, che dovrebbe essere strutturalmente progettato per prevenire l’uso non sorvegliato di tecnologie potenzialmente critiche.
Questo tipo di accesso non controllato, pur non rappresentando un attacco né un errore tecnico in senso stretto, dischiude scenari di vulnerabilità sistemica che dovrebbero essere affrontati a livello di progettazione organizzativa e comportamentale.
Troppe volte, incidenti ad alto impatto nascono da cause minime, talvolta “banali” o sottovalutate, che si innestano su un’assenza di barriere preventive o su una cultura del rischio poco radicata nei contesti non ICT.
È per questo che le misure di sicurezza devono includere anche la prevenzione dei comportamenti anomali involontari, prevedendo policy, filtri logici, controlli fisici e protocolli educativi che impediscano l’insorgere del problema prima ancora che si trasformi in evento.
Nel linguaggio degli standard internazionali, si tratta di risk prevention by anticipation, ovvero l’integrazione di misure organizzative e culturali nei luoghi in cui si interseca l’uso della tecnologia con utenti non consapevoli o non responsabili.
Come previsto dal Decreto di recepimento della NIS 2 (art. 24) e dal framework ISO/IEC 27001, la sicurezza è efficace solo se parte dall’analisi delle condizioni originarie e dei contesti d’uso reali, anche quando appaiono trascurabili.
Inoltre, dal punto di vista del principio di privacy by design, il dispositivo parrebbe essere stato progettato senza l’integrazione di barriere di sicurezza adeguate al profilo di utilizzo da parte di minori, rendendo possibile l’attivazione accidentale di funzionalità critiche, come le chiamate d’emergenza.
La lezione della NIS 2: infrastrutture essenziali e gestione del rischio
La Direttiva (UE) 2022/2555 (NIS 2), recepita in Italia con il D.lgs. 138/2024, impone obblighi stringenti agli enti che gestiscono servizi essenziali. In particolare, l’art. 24 del citato decreto impone:
- misure tecniche e organizzative proporzionate al rischio;
- piani di continuità operativa e gestione degli incidenti;
- sistemi di monitoraggio e mitigazione preventiva.
Il singolare fatto di cronaca evidenzia come nessuno di questi pilastri sia stato attivato preventivamente. Sebbene il fatto sia avvenuto in ambito pubblico e non direttamente coperto dalla normativa per come è strutturata (vds. art. 4, comma 3 del Decreto NIS), tuttavia, lo spirito della NIS 2 – cioè prevenire il collasso dei servizi vitali – dovrebbe guidare tutti gli attori pubblici e privati coinvolti nella catena della risposta, a prescindere dalla loro inclusione nel perimetro di applicazione della normativa.
Standard internazionali: dalla teoria alla prassi mancata
Probabilmente, l’episodio si sarebbe potuto evitare applicando tre principi chiave di altrettanti standard internazionali. Facciamo riferimento a:
- ISO/IEC 22301 – Business Continuity Management: nessuna misura di continuità ha assorbito l’impatto dell’anomalia.
- ISO/IEC 27005 – Gestione del rischio informatico: il rischio derivante da device non certificati o mal configurati non sembra essere stato previsto.
- ISO/IEC 30141 – Architettura di riferimento per IoT: pare assente un controllo funzionale di dispositivi che possono interferire con sistemi critici.
A prima vista, l’applicazione di standard internazionali potrebbe sembrare eccessiva per un evento generato da un bambino in un contesto scolastico.
Tuttavia, è proprio questa apparente innocuità a rendere l’episodio paradigmatico: se in parallelo si fosse verificata una vera emergenza – un arresto cardiaco, un incendio, un’aggressione – la saturazione della centrale operativa avrebbe potuto impedire o ritardare l’intervento, con conseguenze potenzialmente drammatiche.
L’incidente dimostra come l’adozione sistemica degli standard di sicurezza, continuità e gestione del rischio non debba essere riservata solo a scenari estremi o complessi, ma debba estendersi anche ai contesti quotidiani, dove il comportamento imprevedibile degli utenti e l’interconnessione pervasiva dei dispositivi possono costituire una minaccia tanto reale quanto sottovalutata.
Verso una sicurezza “cognitiva” e proattiva
L’episodio di Oderzo è il simbolo di una nuova fase dei rischi digitali: quella degli incidenti non intenzionali, causati da interazioni casuali o inconsapevoli tra dispositivi e sistemi complessi.
Questi eventi non si contrastano solo con barriere tecniche, ma con logiche di riconoscimento intelligente, filtri semantici, sistemi adattivi capaci di apprendere e reagire.
Serve dunque:
- un paradigma di sicurezza dinamica, capace di distinguere tra uso lecito e anomalia involontaria;
- una revisione della progettazione dei dispositivi consumer, soprattutto in ambienti sensibili (scuole, ospedali);
- un’integrazione funzionale tra progettazione dei dispositivi e regole dei sistemi di emergenza, come previsto dal principio di “security-by-interconnection”.
Un’importante lezione
Il caso del bambino di Oderzo ci insegna che non sono solo i criminali informatici a minacciare i servizi critici, ma anche la banale assenza di progettazione resiliente. La sfida non è più soltanto tecnologica, ma culturale, sistemica, anticipatoria.
Chi gestisce servizi essenziali non può più accontentarsi di rispondere agli incidenti: deve prevederli, simularli, neutralizzarli alla fonte. E chi progetta tecnologie deve assumersi la responsabilità delle possibili conseguenze d’uso, anche involontario.
L’interoperabilità tra dispositivi e sistemi deve essere sicura, intelligente e differenziata per contesto. Solo così potremo garantire che l’innocenza di un gesto non si trasformi in un’interruzione del soccorso. E che ogni allarme sia davvero una chiamata d’aiuto.
