Ransomware e settore pubblico: il caso municipale che spiega cosa manca davvero a Comuni e servizi essenziali

Un Comune non è un data center. È un sistema di fiducia che vive di scadenze, pagamenti, comunicazioni e servizi al cittadino. Quando un ransomware colpisce, la domanda vera non è “quanto è grave”, è “quanti servizi restano in piedi e con quali tempi di ripristino”.

Il caso New Britain è utile proprio perché il sintomo principale è stato immediatamente percepibile dai cittadini e dagli uffici: connettività e telefonia indisponibili. Questo tipo di impatto racconta una cosa semplice: l’ente perde la sua capacità di coordinarsi e di erogare servizio nel modo ordinario. Se in quel momento non esistono canali alternativi, l’incidente diventa un problema di ordine pubblico comunicativo prima ancora che tecnologico.

Poi c’è l’altro versante, quello che troppo spesso viene sottovalutato nelle PA locali: la supply chain. Nel settore pubblico l’outsourcing non è una scelta accessoria, è un pezzo di architettura. E quando l’outsourcing si concentra su pagamenti e billing, una crisi del fornitore diventa un fermo operativo a cascata.

Abbiamo scelto New Britain per un motivo semplice: è un caso in cui la superficie del problema è stata immediata. Quando internet e telefonia di un municipio vanno giù, l’attacco smette di essere percepito come “questione IT” e diventa questione di servizio. Non stiamo parlando di un ufficio isolato, stiamo parlando della catena che tiene insieme sportelli, comunicazioni e flussi interni.

Sommario dei contenuti

• Cosa sappiamo con certezza e cosa significa
• Il punto cieco: dipendenze interne e servizi che cadono insieme
• Supply chain: il caso pagamenti BridgePay e la lezione più scomoda
• Accessi: dove si rompe la catena e come si riduce il rischio
• Segmentazione: contenere non significa spegnere tutto
• Backup e ripristino: come si accorciano i tempi
• Tempi di ripristino: RTO realistici per enti locali e servizi essenziali
• Checklist operativa pronta all’uso
• FAQ

Cosa sappiamo con certezza e cosa significa

I fatti confermati sono chiari: l’attacco ha reso indisponibili connettività e telefonia del municipio per oltre 48 ore. La macchina amministrativa ha dovuto mantenere attività e servizi anche con procedure manuali. L’intervento ha coinvolto forze dell’ordine e supporto tecnico esterno, con un ripristino dichiarato come graduale.

Il significato operativo è più interessante del fatto in sé. Un fermo così, nel pubblico, non si misura con la domanda “quanti file sono stati cifrati”. Si misura con due domande che un dirigente o un responsabile IT dovrebbe farsi subito: quali servizi restano erogabili in modalità degradata e qual è l’ordine corretto per rimettere online ciò che è critico senza riaprire la porta.

Il punto cieco: dipendenze interne e servizi che cadono insieme

Quando telefoni e rete vanno giù insieme, il sospetto operativo non è “hanno spento un router”. È che il Comune dipenda da una catena unica: rete, identità, servizi di directory, sistemi di comunicazione e server applicativi condividono lo stesso destino. È normale in contesti in cui la rete è cresciuta a strati, ufficio dopo ufficio, senza una segmentazione reale e senza una gestione dei privilegi a livelli.

Qui il ransomware fa quello che sa fare meglio: sfrutta la complessità. Se l’ente usa la stessa identità per accedere a tutto, e se l’amministrazione dei sistemi passa per canali non sufficientemente protetti, l’attaccante ottiene una leva che moltiplica l’impatto. Anche senza sapere il vettore iniziale, il pattern è leggibile: il problema non è una macchina, è una dipendenza.

Supply chain: il caso pagamenti BridgePay e la lezione più scomoda

Il secondo segnale che abbiamo messo in fila in queste settimane riguarda i pagamenti. Un ransomware che colpisce un fornitore di gateway può spegnere in parallelo portali di pagamento e incassi per più enti locali, più utilities e più servizi al cittadino. E il punto, qui, è che il Comune potrebbe anche essere “pulito” dentro, ma resta fermo fuori.

Nel caso BridgePay, il vendor ha confermato un attacco ransomware e un outage prolungato dei suoi servizi. Per diversi enti locali l’effetto pratico è stato immediato: pagamenti con carta e canali online indisponibili, cittadini indirizzati verso alternative come sportelli fisici, drop box o sistemi temporanei. Un dettaglio tecnico che spesso passa inosservato è quello che ci interessa davvero: se il gateway è integrato come back end dentro i sistemi di billing, l’outage non è “un sito giù”, è una funzione che smette di esistere.

Qui la lezione va messa in agenda come priorità: i pagamenti non sono un servizio accessorio. Sono infrastruttura, perché tengono in piedi incassi e perché riducono il carico operativo sugli sportelli. Se non esiste un piano di continuità per l’incasso, si passa in poche ore da un incidente cyber a una crisi organizzativa.

Accessi: dove si rompe la catena e come si riduce il rischio

La prima domanda che ci fanno sempre è “da dove entrano”. La risposta, nel pubblico, cambia meno di quanto si creda: credenziali rubate, accessi remoti gestiti male, account di servizio troppo potenti, fornitori con canali privilegiati e spesso poco visibili. Il ransomware prospera quando l’identità è un passepartout.

Qui la scelta che cambia davvero il gioco non è uno strumento. È un modello: MFA ovunque conti, privilegi a tempo e non permanenti, amministrazione fatta da postazioni dedicate e non dal PC dell’ufficio, logging centralizzato che segnala l’anomalia prima dell’impatto. Sembra teoria finché non ti trovi con la directory sotto pressione e con le credenziali che devono essere ruotate mentre l’ente lavora su carta.

Segmentazione: contenere non significa spegnere tutto

Segmentare non significa costruire un labirinto. Significa impedire che l’attaccante trasformi un punto di ingresso in una corsa laterale. Nei Comuni il rischio classico è la rete piatta: tutto parla con tutto, e quando un account privilegiato cade, cade anche l’illusione che l’incidente resti “in un ufficio”.

Il criterio pratico che proponiamo è quello dei livelli. Primo livello: identità e infrastruttura di gestione, con accessi blindati e separati. Secondo livello: servizi al cittadino e portali. Terzo livello: postazioni e uffici. Quarto livello: ciò che non deve cadere nemmeno in modalità degradata, e qui dentro finiscono spesso servizi essenziali e componenti operative collegate alle utilities.

Quando questa separazione esiste, la risposta cambia: si può contenere senza spegnere la città digitale. Senza separazione, la scelta diventa drastica: si isola tutto e si entra in un blackout totale.

Backup e ripristino: come si accorciano i tempi

Qui smettiamo di parlare di tecnologia e iniziamo a parlare di tempo. Il ripristino veloce nasce da backup puliti, isolati e provati. Non basta avere copie, serve che l’attaccante non possa toccarle e serve che il restore funzioni davvero nel momento peggiore.

Il punto più trascurato è la protezione del sistema di backup. Se il backup vive nella stessa foresta di identità del resto, un dominio compromesso può diventare un backup compromesso. Per questo insistiamo su due idee concrete: credenziali separate e copie immutabili oppure offline. Poi c’è la prova più brutale ma più utile: test di ripristino a tempo, con un cronometro e con una checklist.

Un recovery pulito non è un restauro “completo”. È un ritorno a fasi: prima ciò che permette di autenticare e comunicare, poi ciò che serve per erogare servizi e incassare, infine ciò che è amministrazione interna. In un Comune questo ordine fa la differenza tra un fermo gestibile e una paralisi che dura settimane.

Tempi di ripristino: RTO realistici per enti locali e servizi essenziali

Ogni ente locale dovrebbe avere RTO dichiarati, non generici. Il ransomware trasforma un concetto astratto in domanda urgente: in quante ore torniamo a comunicare, in quante ore riapriamo un canale di pagamento, in quanti giorni torniamo a pieno regime.

Un modello pratico, che si adatta a Comuni medi e a utilities collegate, ragiona per classi. Comunicazioni e canali al cittadino devono rientrare per primi, perché riducono il panico e organizzano il lavoro. Identità e servizi core vengono subito dopo, perché senza identità non ripristini nulla. Pagamenti e billing vanno trattati come mission critical, perché impattano su incassi e su rapporto con la comunità. Il back office interno può rientrare in modo più graduale, ma solo se non trascina con sé i servizi esterni.

Checklist operativa pronta all’uso

Qui mettiamo nero su bianco ciò che consigliamo di avere già pronto, e ciò che va fatto nel momento in cui l’incidente si manifesta. È una lista operativa, non una lezione di principio.

Prima dell’incidente

• Inventario minimo dei servizi: cosa è essenziale, cosa è importante e cosa può fermarsi senza bloccare la città.
• Segmentazione per livelli: identità e gestione separate dai segmenti utenti e dai servizi esposti al cittadino.
• Privilegi ridotti e tracciati: MFA su accessi critici e controllo sui fornitori con accesso remoto.
• Backup con copie immutabili o offline e test di restore ripetuti, con tempi misurati e obiettivi espliciti.

Durante l’incidente

• Isolamento rapido con mandato chiaro: si decide chi può staccare e cosa non può essere staccato.
• Canale di comunicazione alternativo: aggiornamenti frequenti e istruzioni operative per cittadini e uffici.
• Presidio dei servizi essenziali e modalità degradata già prevista: il cartaceo deve essere organizzato, non improvvisato.
• Conservazione delle evidenze e coordinamento con forze dell’ordine e specialisti: serve per bonifica e per responsabilità.

Dopo il contenimento

• Rotazione credenziali e verifica dei privilegi: trattare l’identità come potenzialmente compromessa finché non si dimostra il contrario.
• Ripristino per fasi con gate di sicurezza: log e telemetria prima della riapertura dei servizi.
• Revisione contratti supply chain: clausole di notifica e piani di continuità per pagamenti, billing e servizi esterni.

Il caso New Britain ci ha ricordato una cosa che nel settore pubblico tendiamo a dimenticare finché non brucia: il digitale è ormai un’infrastruttura civica. Quando cade, non cade un software. Cade il coordinamento tra uffici, cade la capacità di rispondere e cade la fiducia se la comunicazione non è pronta.

La seconda lezione è più scomoda perché sposta la responsabilità oltre i confini dell’ente. La supply chain dei pagamenti è una linea di servizio. Se il vendor è a terra, il Comune perde un pezzo di città digitale anche se nessuno ha toccato i suoi server. Per questo insistiamo su contratti che parlano di resilienza e su piani di continuità che non dipendono dalla speranza che “tanto torna su”.

La terza lezione è quella che distingue i Comuni che ripartono da quelli che restano fermi. Segmentazione e identità sono due facce della stessa cosa: ridurre la portata dell’incidente. Backup e test di ripristino sono l’unico modo serio di comprare tempo quando il ransomware prova a vendertelo.

A cura di Junior Cristarella.