Cybersicurezza e rischi tecnologici nel settore pubblico

Perché è importante per il valore pubblico

Quando i sistemi di un ospedale sono cifrati da un aggressore, i clinici non possono vedere le storie dei farmaci, le ambulanze sono deviate e gli interventi sono annullati. Quando i sistemi di controllo di un'azienda idrica sono compromessi, il valore pubblico in gioco non è un'interruzione del server ma la sicurezza dell'acqua potabile. Quando il database di un'agenzia di prestazioni subisce una violazione, le persone più esposte sono spesso quelle meno in grado di assorbirne le conseguenze: un pagamento ritardato, un'identità rubata, una famiglia che non riesce a provare chi sia allo Stato che le deve sostegno. La sicurezza informatica, comunemente detta cybersicurezza, è la pratica di proteggere sistemi informatici, reti e dati da accesso non autorizzato, interruzione o danno. Nelle istituzioni pubbliche, quella pratica sta direttamente sul percorso fra lo Stato e il cittadino che serve.

È per questo che l'argomento inquadra il rischio informatico come una questione di valore pubblico, non solo tecnica. Legittimità e sostegno dipendono dal fatto che i cittadini credano che le istituzioni che detengono i loro dati e gestiscono i loro servizi essenziali sappiano mantenerli al sicuro entrambi (vedi Argomento 1.2 — Il triangolo strategico: legittimità, valore e capacità). Una singola violazione ampiamente pubblicizzata può fare un danno duraturo a quella fiducia, nello stesso modo di un'emergenza gestita male, perché i cittadini giudicano le istituzioni da come si comportano sotto attacco tanto quanto da come rendono giorno per giorno (vedi Argomento 3.12 — Gestione delle crisi, delle emergenze e della resilienza, che tratta gli incidenti informatici come una categoria entro la più ampia disciplina della resilienza). La cybersicurezza è anche inseparabile dalla governance dei dati: un'istituzione non può proteggere ciò che non sa di detenere, e l'interoperabilità e l'apertura che creano valore pubblico dai dati allargano anche la superficie che un aggressore può sfruttare (vedi Argomento 5.4 — Dati, interoperabilità e dati aperti nel settore pubblico).

Il problema delle risorse è acuto e specifico dei settori pubblico e sociale. Le grandi agenzie nazionali hanno sempre più gruppi di sicurezza dedicati e bilanci aziendali; l'azienda idrica che serve una piccola città, il fondo ospedaliero regionale e la non profit locale che gestisce un rifugio per vittime di violenza domestica tipicamente non li hanno, nonostante detengano dati la cui sensibilità rivaleggia con o supera quella di qualsiasi banca. Gli aggressori lo sanno. Gli enti pubblici sottodotati non sono un caso marginale di questo argomento; ne sono vicini al centro, perché l'istituzione pubblica mediana che affronta oggi questo rischio non è un ministero nazionale ma un piccolo ente locale, un'azienda regionale di servizio pubblico o un ente di beneficenza con una manciata di personale informatico e nessuno specialista di sicurezza.

Infine, questo è un problema vivo e in peggioramento, non ipotetico. Le campagne di ransomware prendono sempre più di mira amministrazioni locali, ospedali, scuole e organizzazioni del terzo settore proprio perché combinano dati sensibili, servizi essenziali, bassa tolleranza all'inattività e difese comparativamente deboli – una combinazione che le rende più propense a pagare e meno propense ad aver prevenuto l'attacco in primo luogo. Trattare la cybersicurezza come un'aggiunta specialistica anziché come un impegno di valore pubblico a livello di governance è, per questa classe di organizzazioni, quasi un invito.

Concetti chiave

L'infrastruttura critica è l'insieme di sistemi e beni – energia, acqua, trasporti, sanità, finanza, comunicazioni – così essenziali che la loro incapacità o distruzione avrebbe un effetto debilitante su sicurezza, economia o fiducia pubblica. La protezione dell'infrastruttura critica è la disciplina di metterla al sicuro contro minacce fisiche e digitali insieme; conta qui perché molti degli incidenti informatici del settore pubblico più consequenziali non sono attacchi a dati astratti ma attacchi alla tecnologia operativa che mantiene in funzione l'infrastruttura fisica, distinta dalla tecnologia dell'informazione che tiene i registri ed elabora le transazioni.

Un attore della minaccia (threat actor) è qualsiasi individuo, gruppo o Stato che possa tentare di compromettere un sistema; nel settore pubblico spaziano da gruppi criminali motivati finanziariamente ad attori sponsorizzati da Stati che perseguono spionaggio o interruzione, e la stessa istituzione può affrontare entrambi simultaneamente con obiettivi molto diversi. Il ransomware è un software malevolo che cifra i dati o i sistemi di un'organizzazione e chiede un pagamento per il rilascio; è diventato la minaccia dominante per gli enti pubblici proprio perché i servizi essenziali non possono tollerare un'inattività prolungata, il che aumenta la pressione a pagare. Il phishing è una forma di ingegneria sociale in cui gli aggressori ingannano il personale per fargli rivelare credenziali o installare software malevolo, tipicamente tramite email ingannevoli, e resta il modo più comune in cui un aggressore ottiene per la prima volta un punto d'appoggio, perché prende di mira le persone anziché la tecnologia.

Una violazione di dati è l'accesso, la divulgazione o la perdita non autorizzati di informazioni, che sia per un attacco esterno, un interno o un semplice errore umano come un database mal configurato lasciato aperto a internet. Un attacco alla catena di fornitura compromette un'organizzazione indirettamente, prendendo di mira un fornitore, un produttore di software o un fornitore di servizi gestiti meno sicuro di cui l'organizzazione bersaglio si fida; sono particolarmente pericolosi per il settore pubblico perché così tanti enti pubblici condividono la stessa manciata di fornitori di software, il che significa che una compromissione di un fornitore può propagarsi a centinaia di istituzioni simultaneamente.

L'igiene informatica (cyber hygiene) è l'insieme di pratiche di routine – aggiornare tempestivamente il software, imporre un'autenticazione forte, limitare chi può accedere a che cosa, fare copie di riserva dei dati e verificare il ripristino di tali copie – che prevengono la grande maggioranza degli attacchi riusciti senza richiedere strumenti esotici. La maggior parte delle violazioni sfrutta vulnerabilità note e non corrette o credenziali deboli anziché tecniche nuove, per cui il divario fra la reale igiene informatica di un'organizzazione e la sua politica dichiarata è di solito un miglior predittore del suo rischio della sofisticazione delle minacce che nomina nel proprio registro dei rischi.

L'architettura zero trust è un principio di progettazione della sicurezza per cui nessun utente o dispositivo dovrebbe essere considerato affidabile per impostazione predefinita, nemmeno dentro la rete dell'organizzazione stessa, e ogni richiesta di accesso deve essere verificata a prescindere da dove origini. È diventata influente negli orientamenti del settore pubblico perché si adatta a come il lavoro di governo avviene davvero oggi – personale, appaltatori e cittadini che accedono ai servizi da molti dispositivi e luoghi – meglio di un modello più vecchio che si fidava di qualsiasi cosa già dentro il perimetro.

La gestione degli incidenti di sicurezza informatica, di solito detta risposta agli incidenti, è il processo organizzato di rilevare, contenere, eradicare e riprendersi da un incidente di sicurezza, seguito da un riesame di ciò che ne ha permesso il verificarsi. Un obbligo di divulgazione è un dovere giuridico o regolatorio di notificare le persone interessate, i regolatori o il pubblico quando dati personali o servizi critici sono stati compromessi, entro un tempo specificato e a uno standard specificato, sulla logica che cittadini e organi di vigilanza hanno il diritto di sapere quando i loro dati o i loro servizi essenziali sono stati messi a rischio e che una divulgazione tempestiva permette alle persone di proteggersi.

Buone pratiche

1. Trattate la cybersicurezza come responsabilità dell'organo di governo, non come funzione tecnica delegata. Consigli, giunte e gruppi esecutivi dovrebbero ricevere regolari relazioni in linguaggio semplice sul rischio informatico e approvarne direttamente il bilancio, anziché lasciare che sia negoziato dentro una più ampia voce di tecnologia dell'informazione dove è la cosa più facile da tagliare.
2. Inventariate ciò che detenete e ciò che ne dipende prima di decidere come proteggerlo. Un'organizzazione non può mettere al sicuro dati o sistemi che non ha mappato; un inventario aggiornato di beni e dati, incrociato con il lavoro su interoperabilità e governance dei dati trattato altrove (vedi Argomento 5.4 — Dati, interoperabilità e dati aperti nel settore pubblico), è la precondizione di ogni altra pratica in questo elenco.
3. Applicate le basi ovunque prima di spendere per qualsiasi cosa avanzata. Gestione degli aggiornamenti, autenticazione a più fattori, copie di riserva verificate e controllo degli accessi a minimo privilegio fermano la stragrande maggioranza degli attacchi reali; un ente pubblico privo di queste non dovrebbe dare priorità ad abbonamenti di intelligence sulle minacce o a strumenti di monitoraggio su misura.
4. Adottate un quadro riconosciuto anziché inventarne uno su misura. Quadri come il Cybersecurity Framework del National Institute of Standards and Technology danno un vocabolario condiviso e una struttura – identificare, proteggere, rilevare, rispondere, riprendersi – che un'organizzazione piccola può adottare in forma semplificata e una grande in forma piena, senza reinventare la tassonomia di base.
5. Mettete in comune le risorse fra le organizzazioni piccole anziché acquistare ciascuna da sola. Un servizio condiviso di operazioni di sicurezza, un fondo regionale di risposta agli incidenti informatici o un quadro di appalto a livello di settore possono dare a un gruppo di piccoli enti locali o non profit una protezione che nessuno di loro potrebbe permettersi individualmente – la risposta più diretta al problema di sottodotazione al centro di questo argomento.
6. Scrivete il piano di risposta agli incidenti prima dell'incidente e provatelo. Un piano redatto per la prima volta durante un attacco in corso è un piano redatto male, nel panico, da persone che non hanno mai verificato se funzioni davvero; un piano esercitato almeno annualmente trasforma una prima ora caotica in una sequenza provata di passi noti (vedi Argomento 3.12 — Gestione delle crisi, delle emergenze e della resilienza per la più ampia disciplina da cui attinge).
7. Decidete in anticipo la politica di divulgazione e di pagamento, non durante l'incidente. Se l'organizzazione considererà di pagare un riscatto, chi abbia l'autorità di decidere e come e quando le persone interessate saranno informate dovrebbero essere una politica approvata dal consiglio, non una decisione improvvisata sotto la pressione di una richiesta di estorsione in corso.
8. Segmentate le reti così che una compromissione non possa diventare ogni compromissione. Tenere la tecnologia operativa che controlla l'infrastruttura fisica separata dalla generale tecnologia dell'informazione d'ufficio, e separare i sistemi ad alta sensibilità da quelli a più bassa sensibilità, limita fino a dove possa viaggiare un intruso entrato da un solo punto debole.
9. Gestite il rischio dei terzi e della catena di fornitura con lo stesso rigore del rischio interno. Richiedete garanzie di sicurezza, clausole di diritto di audit e obblighi di notifica degli incidenti nei contratti con fornitori di software e fornitori di servizi gestiti, poiché una quota crescente dei maggiori incidenti del settore pubblico origina da un fornitore fidato anziché da un attacco diretto.
10. Investite nelle persone, non solo negli strumenti. Una formazione regolare e realistica – compresi esercizi di phishing simulato – riduce in modo misurabile gli attacchi di ingegneria sociale riusciti, e trattenere anche solo uno o due addetti alla sicurezza qualificati in una piccola organizzazione vale di solito più di una spesa equivalente in ulteriori licenze software.
11. Riferite gli incidenti con onestà e usate i quasi-incidenti come lezioni gratuite. Una cultura che punisce il personale per aver segnalato una sospetta violazione garantisce che la prossima sia riferita in ritardo o per niente; le organizzazioni che migliorano più in fretta sono quelle che trattano ogni quasi-incidente come evidenza da cui imparare anziché come motivo per attribuire colpe.
12. Incorporate la resilienza informatica negli appalti e nelle condizioni delle sovvenzioni, non solo nella politica interna. Finanziatori ed enti committenti possono richiedere un livello di base di pratica di sicurezza alle organizzazioni che finanziano o con cui contrattano, estendendo la portata della buona pratica ai partner di erogazione più piccoli che altrimenti non avrebbero alcuna pressione esterna a investirvi (vedi Argomento 3.7 — Appalti pubblici e affidamento dei servizi).

Domande da discutere con il vostro team

Sappiamo quali dati e sistemi deteniamo davvero e quali di essi farebbero male a qualcuno se compromessi? Molte organizzazioni scoprono la vera estensione dei propri patrimoni di dati solo durante un'indagine su una violazione, che è il momento peggiore per saperlo. Ripercorrete i vostri servizi principali e chiedetevi, per ciascuno, quali dati personali od operativamente sensibili tocchi e che cosa accadrebbe a una persona reale se quei dati fossero rubati, alterati o resi non disponibili. Se la risposta onesta è "non ne siamo sicuri", quell'incertezza è di per sé la risultanza, e colmarla è la prima voce della vostra agenda. Questa domanda conta di più per le organizzazioni cresciute per acquisizione, fusione o sistemi ereditati accumulati, dove la memoria istituzionale di ciò che esiste si è assottigliata.

Se domani fossimo colpiti da ransomware, potremmo ripristinare da una copia di riserva senza pagare? Il valore di una copia di riserva non è che esista ma che sia stata verificata nel ripristinare davvero, abbastanza in fretta, da una versione abbastanza recente da contare. Chiedetevi quando le copie di riserva siano state verificate per l'ultima volta con un vero esercizio di ripristino, non solo con un registro di completamento, e quanto richiederebbe un ripristino completo rispetto a quanto la vostra organizzazione possa tollerare un'interruzione. Se quei numeri non coincidono, avete una decisione di risorse da prendere ora, non durante un incidente. È anche il momento di discutere se le copie di riserva stesse siano isolate dalla rete che un aggressore che raggiunga i vostri sistemi principali potrebbe raggiungere a sua volta.

Chi ha l'autorità di decidere se pagare un riscatto, e ne abbiamo mai discusso prima che ci venisse chiesto? È una delle decisioni a più alta posta che un gruppo esecutivo possa affrontare, spesso richiesta entro ore e con informazioni incomplete su ciò che l'aggressore abbia effettivamente. Decidere in anticipo il processo, le persone che autorizzano e i principi – anche se la decisione finale dipenderà ancora dalle specificità dell'incidente – previene una decisione improvvisata sotto la pressione dell'estorsione. Discutete che cosa dicano la legge della vostra giurisdizione e le condizioni dei vostri finanziatori sul pagamento di un riscatto e chi dovreste notificare.

I nostri partner e fornitori più piccoli sono un rischio maggiore per noi di quanto lo siamo noi stessi? Un'organizzazione centrale ben protetta può comunque essere compromessa attraverso un fornitore, appaltatore o partner di erogazione mal protetto con accesso legittimo ai suoi sistemi o dati. Mappate i terzi che possono raggiungere i vostri sistemi o detenere i vostri dati e siate onesti su quanta garanzia abbiate effettivamente sulle loro prassi di sicurezza rispetto a quanta presumiate di averne. Decidete quale standard minimo richiederete loro in futuro e come lo verificherete anziché limitarvi a chiedere una garanzia scritta.

Sapremmo di essere stati violati, e con quale rapidità? Alcuni degli incidenti più dannosi non sono quelli che avvengono in fretta ma quelli che restano non rilevati per mesi, durante i quali un aggressore ha silenziosamente esplorato, escalato i privilegi ed esfiltrato dati. Discutete come rilevereste effettivamente oggi un'attività insolita, chi la stia osservando e se quel monitoraggio funzioni anche fuori orario d'ufficio, poiché molti attacchi sono lanciati deliberatamente di notte o in un fine settimana festivo quando la risposta è più lenta. Se la rilevazione dipende interamente da un cittadino o da un'organizzazione partner che vi dice che qualcosa non va, è una lacuna critica.

Il nostro consiglio o organo di governo comprende questo rischio abbastanza bene da governarlo, o abbiamo silenziosamente esternalizzato quel giudizio al gruppo di tecnologia dell'informazione? Le decisioni sul rischio informatico comportano reali compromessi fra costo, continuità del servizio e protezione dei cittadini che sono propriamente affari dell'organo di governo, non una questione tecnica delegata da approvare per formalità. Discutete come il rischio informatico sia attualmente riferito al vostro consiglio o alla vostra giunta, se sia in un linguaggio su cui un non specialista possa effettivamente agire e se il bilancio per esso sia deciso con lo stesso rigore di qualsiasi altro rischio importante. Se il vostro organo di governo non potesse attualmente spiegare con parole proprie i tre principali rischi informatici della vostra organizzazione, quella è la lacuna da colmare per prima.

In pratica: un esempio di valore pubblico

Un'autorità regionale di trasporto pubblico di medie dimensioni – immaginaria, illustrativa di uno schema anziché un resoconto di un'organizzazione reale – gestiva sistemi invecchiati di programmazione e di pagamento che erano stati aggiornati a pezzi per un decennio anziché modernizzati. Il suo gruppo di tecnologia dell'informazione era di tre persone, responsabili di tutto dai ticket dell'assistenza alla sicurezza di rete, e la cybersicurezza non aveva mai avuto una propria voce di bilancio; viveva dentro una generale allocazione di "manutenzione dei sistemi" che non cresceva in termini reali da anni.

Un aggressore ottenne l'accesso tramite un'email di phishing inviata a un addetto alla contabilità, usando una fattura contraffatta di un fornitore che l'autorità usava davvero. Una volta dentro, l'aggressore trascorse sei settimane a muoversi silenziosamente nella rete prima di dispiegare un ransomware che cifrò il sistema di programmazione, la piattaforma di pagamento delle tariffe e le copie di riserva dell'autorità, che non erano mai state isolate dalla rete principale. Gli autobus continuarono a circolare il primo giorno sulla memoria dei percorsi da parte degli autisti, ma le tariffe non potevano essere riscosse elettronicamente, gli schermi di informazione in tempo reale si spensero e i sistemi finanziari dell'autorità erano inutilizzabili per le paghe.

Il gruppo esecutivo affrontò la decisione sul riscatto senza una politica concordata in anticipo: nessuno aveva deciso prima chi avesse l'autorità di approvare un pagamento, quale fosse la posizione giuridica o che cosa dire ai passeggeri. Il ripristino dalle copie di riserva non era un'opzione, perché le copie erano cifrate insieme a tutto il resto. Dopo nove giorni di interruzione, un ripristino parziale del servizio e un pagamento che il consiglio dell'autorità descrisse poi come l'opzione meno cattiva disponibile al momento, l'autorità commissionò una revisione indipendente.

Le risultanze della revisione furono prive di fascino e del tutto coerenti con lo schema che questo argomento descrive: nessuna autenticazione a più fattori sui sistemi finanziari, nessuna segmentazione di rete fra i sistemi d'ufficio e l'infrastruttura di pagamento, nessun ripristino da copia di riserva verificato da oltre due anni e nessuna visibilità a livello di consiglio sul rischio informatico prima dell'incidente. La risposta dell'autorità fu altrettanto priva di fascino – un piano graduale per correggere le basi, un assetto condiviso di monitoraggio della sicurezza con due autorità di trasporto vicine per dividere il costo di una copertura specialistica che nessuna di loro poteva permettersi da sola e un punto permanente all'ordine del giorno del consiglio sul rischio informatico. Nulla di ciò era costoso secondo gli standard di un grande programma di tecnologia dell'informazione; tutto era stato saltato per anni perché non era mai stato compito chiaramente assegnato a qualcuno di insistervi.

Quattro prospettive settoriali

Amministrazione locale

Gli enti locali stanno a un'intersezione scomoda: detengono dati altamente sensibili – cartelle di assistenza sociale, informazioni su abitazione e prestazioni, registri elettorali – e gestiscono servizi di cui i cittadini non possono facilmente fare a meno, ma hanno tipicamente i bilanci di sicurezza più piccoli e il personale specialistico minore di qualsiasi livello di governo. Un grande ministero nazionale può costruire un centro interno di operazioni di sicurezza; un piccolo consiglio distrettuale di solito non può, il che rende servizi condivisi, messa in comune regionale e programmi di sostegno nazionali la via pratica a una protezione adeguata anziché un extra facoltativo. I funzionari eletti locali sono anche spesso i meno attrezzati, di qualsiasi livello di governo, a interrogare una relazione tecnica sul rischio, il che rende la rendicontazione in linguaggio semplice ai membri eletti una distinta sfida di governance a questo livello.

Amministrazione nazionale

I governi nazionali hanno in genere le risorse per costruire agenzie dedicate alla cybersicurezza e quadri nazionali – organismi come il National Cyber Security Center (Regno Unito) o la Cybersecurity and Infrastructure Security Agency degli Stati Uniti esistono per fissare standard, coordinare la risposta e sostenere gli enti pubblici meno dotati di risorse entro la propria giurisdizione. La sfida distintiva a livello nazionale riguarda meno l'igiene di base e più gli attori della minaccia sponsorizzati da Stati e altamente capaci, l'interdipendenza dell'infrastruttura nazionale critica fra settori e operatori privati e le dimensioni diplomatiche e giuridiche dell'attribuzione e della risposta, che raramente compaiono a livello locale o organizzativo.

Terzo settore e non profit

Le organizzazioni non profit e le ONG detengono spesso alcuni dei dati più sensibili di qualsiasi settore – cartelle sanitarie, registri di sopravvissuti a violenza o persecuzione, casistica di rifugiati e richiedenti asilo – operando con i bilanci di sicurezza più sottili di qualsiasi tipo di organizzazione in questo libro, perché i finanziatori raramente destinano denaro alla sicurezza e le condizioni delle sovvenzioni raramente la richiedono. Molte organizzazioni del terzo settore dipendono anche da volontari e da alto avvicendamento del personale, il che rende la formazione coerente sulla sicurezza e il controllo degli accessi più difficili da sostenere che in un'organizzazione stabile e dotata di personale professionale; un incidente di sicurezza può essere esistenziale per un piccolo ente di beneficenza in un modo in cui raramente lo è per un ministero, perché il danno reputazionale e la perdita di fiducia dei donatori possono porre fine all'organizzazione (vedi Argomento 3.8 — Gestione del terzo settore e del non profit).

Livello multilaterale e internazionale

Gli organismi multilaterali e internazionali operano attraverso giurisdizioni con leggi di divulgazione diverse, definizioni diverse di infrastruttura critica e diversi livelli di capacità informatica nazionale, il che rende il coordinamento stesso un problema distinto: i sistemi propri di un organismo internazionale possono essere ben protetti mentre le sue agenzie nazionali membre variano enormemente, e un organismo come l'Organizzazione per la cooperazione e lo sviluppo economico o l'Agenzia dell'Unione europea per la cybersicurezza svolge un ruolo tanto di fissazione di standard e di rafforzamento delle capacità quanto operativo. La prospettiva multilaterale è anche quella in cui contano di più la risposta transfrontaliera agli incidenti e gli assetti di condivisione delle informazioni, poiché un attacco che inizia nell'infrastruttura di un paese può propagarsi a quella di un altro in poche ore, più in fretta di quanto la maggior parte dei meccanismi internazionali di coordinamento sia costruita per muoversi.

Modalità di fallimento comuni

Teatro della sicurezza senza sostanza operativa. Un'organizzazione adotta un documento di politica dall'aspetto impressionante, un certificato di conformità o un singolo strumento costoso e tratta la casella come spuntata, mentre l'igiene di base – aggiornamenti, autenticazione a più fattori, copie di riserva verificate – resta incoerente. Ciò costa denaro reale per l'apparenza della sicurezza anziché per la sicurezza stessa ed è spesso scoperto come teatro solo dopo che un incidente espone il divario fra politica e pratica.

Il rischio senza proprietario. La cybersicurezza è presunta compito di qualcun altro – del gruppo di tecnologia dell'informazione, di un fornitore, di un regolatore – e non esiste alcun responsabile unico a livello di organo di governo. Ciò produce un rischio discusso ovunque e deciso da nessuna parte, ed è proprio lo schema che lascia le organizzazioni incapaci di rispondere a domande basilari sulla propria esposizione quando gliele si pongono.

Sottoinvestimento giustificato dall'assenza di un incidente precedente. Poiché un programma di sicurezza ben gestito non produce alcun evento visibile quando riesce, è facile definanziarlo in un ciclo di bilancio stretto a favore di qualcosa con un output visibile, e l'assenza finora di una violazione è scambiata per evidenza di protezione adeguata anziché per evidenza non ancora messa alla prova. Rispecchia la stessa logica di bilancio che mina più in generale l'investimento in resilienza (vedi Argomento 3.12 — Gestione delle crisi, delle emergenze e della resilienza).

Sistemi ereditati tenuti in funzione oltre la loro vita sostenibile. Gli enti pubblici fanno spesso girare software o hardware molto dopo che un fornitore ha smesso di emettere patch di sicurezza per esso, perché la sostituzione è costosa, dirompente o politicamente impopolare e il sistema "funziona ancora". Un sistema non aggiornato e non supportato non è un'incomodità ereditata; è una porta aperta che non costa nulla a un aggressore attraversare.

Cultura degli incidenti che parte dalla colpa. Quando il personale che segnala una sospetta violazione o un errore è sanzionato anziché sostenuto, gli incidenti futuri sono segnalati in ritardo, minimizzati o per niente, e l'organizzazione perde il segnale di allarme precoce che la segnalazione tempestiva fornisce. Questo fallimento aggrava ogni altro in questo elenco, perché nessuna delle correzioni sopra funziona se l'organizzazione non riesce a vedere onestamente i propri problemi.

Modello di maturità

Lista di controllo

• Una persona o un comitato nominati a livello di organo di governo possiedono il rischio informatico e ne riferiscono regolarmente, in linguaggio semplice.
• Esiste un inventario aggiornato di quali dati e sistemi l'organizzazione detiene e quali siano i più sensibili o i più critici per un servizio.
• L'autenticazione a più fattori è imposta su tutti i sistemi che detengono dati sensibili o controllano servizi critici.
• Le copie di riserva sono fatte regolarmente, conservate isolate dalla rete principale e il ripristino è stato verificato negli ultimi dodici mesi.
• Software e sistemi sono aggiornati a una scadenza definita e qualsiasi sistema che non può più essere aggiornato ha un piano documentato per sostituirlo o isolarlo.
• Esiste un piano scritto di risposta agli incidenti, che nomina chi abbia l'autorità di prendere le decisioni chiave, ed è stato provato con un esercizio realistico nell'ultimo anno.
• Esiste una politica approvata dal consiglio sul pagamento di un riscatto e su come e quando le persone interessate, i regolatori e il pubblico saranno informati.
• I contratti con fornitori di software e fornitori di servizi gestiti includono garanzie di sicurezza e obblighi di notifica degli incidenti.
• Il personale riceve formazione regolare e realistica sulla sicurezza, compresi esercizi di phishing simulato.
• Segnalare un sospetto incidente o un quasi-incidente è trattato come informazione preziosa, non motivo di colpa.
• Assetti di sicurezza condivisi o messi in comune sono stati esplorati con organizzazioni pari di dimensioni e bilancio simili.
• Il rischio informatico compare esplicitamente nella più ampia pianificazione di crisi e di resilienza dell'organizzazione, non come piano separato e scollegato.

Fonti chiave

Questo argomento attinge al Cybersecurity Framework del National Institute of Standards and Technology come principale quadro strutturato per organizzare la pratica di cybersicurezza; alla missione pubblicata dell'Agenzia dell'Unione europea per la cybersicurezza e alle sue indicazioni per raggiungere un livello comune di cybersicurezza nell'Unione europea; al lavoro dell'Organizzazione per la cooperazione e lo sviluppo economico sulla politica di sicurezza digitale, che inquadra la sicurezza digitale come questione di gestione del rischio economico e sociale anziché puramente tecnica; e agli orientamenti operativi pubblicati da agenzie nazionali di cybersicurezza come il National Cyber Security Center del Regno Unito e la Cybersecurity and Infrastructure Security Agency degli Stati Uniti, entrambe le quali forniscono orientamenti gratuiti rivolti specificamente agli enti pubblici sottodotati.

Riferimenti

1. Computer security — Wikipedia — https://en.wikipedia.org/wiki/Computer_security
2. Critical infrastructure — Wikipedia — https://en.wikipedia.org/wiki/Critical_infrastructure
3. Ransomware — Wikipedia — https://en.wikipedia.org/wiki/Ransomware
4. Phishing — Wikipedia — https://en.wikipedia.org/wiki/Phishing
5. Data breach — Wikipedia — https://en.wikipedia.org/wiki/Data_breach
6. Supply chain attack — Wikipedia — https://en.wikipedia.org/wiki/Supply_chain_attack
7. Zero trust architecture — Wikipedia — https://en.wikipedia.org/wiki/Zero_trust_architecture
8. Computer security incident management — Wikipedia — https://en.wikipedia.org/wiki/Computer_security_incident_management
9. National Cyber Security Center (United Kingdom) — Wikipedia — https://en.wikipedia.org/wiki/National_Cyber_Security_Centre_(United_Kingdom)
10. Cybersecurity and Infrastructure Security Agency — Wikipedia — https://en.wikipedia.org/wiki/Cybersecurity_and_Infrastructure_Security_Agency
11. Cybersecurity Framework — National Institute of Standards and Technology — https://www.nist.gov/cyberframework
12. Who we are — European Union Agency for Cybersecurity (ENISA) — https://www.enisa.europa.eu/about-enisa/who-we-are
13. Digital security — Organisation for Economic Co-operation and Development (OECD) — https://www.oecd.org/en/topics/digital-security.html
14. What we do at the NCSC — National Cyber Security Center (United Kingdom) — https://www.ncsc.gov.uk/section/about-ncsc/what-we-do
15. About CISA — Cybersecurity and Infrastructure Security Agency (United States) — https://www.cisa.gov/about