Politica di sicurezza: è classificata come infrastruttura vitale indispensabile per il futuro.

Nei settori bancario e dei servizi di pubblica utilità, gli enti regolatori definiscono alcuni sistemi come critici. Un sistema critico è un sistema il cui malfunzionamento potrebbe causare danni intollerabili a clienti, mercati o sicurezza pubblica. Ad esempio, una piattaforma di pagamento in una banca di compensazione o una rete SCADA in un distributore di energia elettrica comportano i più elevati obblighi di governance, tra cui il monitoraggio continuo, la gestione documentata delle modifiche e la resilienza dimostrabile.

L'ambiente delle policy, ovvero un insieme di regole accumulate tra firewall, controlli cloud e microsegmentazione, determina quali sistemi possono interagire tra loro, quali comunicazioni vengono bloccate e quali eccezioni rimangono attive. Queste regole costituiscono collettivamente il livello di controllo delle policy di sicurezza: il livello di governance che traduce gli obiettivi aziendali in decisioni di accesso tra i punti di esecuzione distribuiti.

Una regola di hashing configurata in modo errato durante una migrazione al cloud può disconnettere un servizio di pagamento dalla sua piattaforma di regolamento; analogamente, una regola temporanea che concede un ampio accesso da una sottorete di sviluppo all'ambiente di produzione può rimanere attiva per mesi dopo l'effettiva messa in funzione a causa dell'assenza di una persona responsabile della sua rimozione.

Le regole del firewall, le politiche di segmentazione e le decisioni di accesso influiscono direttamente sui rischi operativi e, quando l'ambiente delle politiche non funziona correttamente, anche i servizi vitali che lo governano smettono di funzionare.

Ciò rende il contesto politico un'infrastruttura vitale di per sé.

Vengono tuttora gestite come attività di routine.

Nonostante ciò, molte organizzazioni regolamentate continuano a gestire i propri sistemi normativi come semplici attività operative. Le regole vengono aggiunte tramite richieste di modifica e l'effetto cumulativo viene raramente esaminato rispetto all'intento originale. La responsabilità si frammenta con il mutare dei ruoli dirigenziali e la ragione dell'esistenza di una determinata regola si può trovare solo in una richiesta di modifica, ammesso che ne esista una.

Un responsabile della sicurezza informatica (CISO), che non permetterebbe mai a una piattaforma di pagamento di operare senza monitoraggio continuo o dipendenze documentate, potrebbe accettare l'assenza di entrambi nell'ambiente normativo che determina l'accessibilità della piattaforma. Possiamo descrivere questa situazione come avente conseguenze a livello di infrastruttura con una governance a livello di routine.

Nel settore bancario, un malfunzionamento delle policy che interrompa la comunicazione tra i sistemi di regolamento causerebbe un'interruzione dei servizi aziendali essenziali. La Financial Conduct Authority (FCA) monitorerebbe attentamente tali malfunzionamenti, poiché la perdita di un servizio di questo tipo potrebbe provocare danni significativi.

Nei settori sanitario ed energetico, le conseguenze sono diverse, ma il meccanismo è lo stesso: una configurazione errata che consente l'accesso da una rete aziendale ai sistemi clinici di un istituto del Servizio Sanitario Nazionale (SSN) o alla tecnologia operativa di un distributore di energia, crea vulnerabilità nell'erogazione dei servizi essenziali. Non si tratta di rischi ipotetici, ma di reali conseguenze operative derivanti dal considerare la governance delle infrastrutture critiche come un'attività di routine. Per una comprensione più approfondita dell'importanza di una pianificazione proattiva, si veda il nostro articolo "Prima di iniziare: questioni essenziali relative alle infrastrutture".

Le previsioni degli enti regolatori confermano la stessa tendenza.

Nel Regno Unito, le aspettative normative sono in aumento e confermano la stessa conclusione: le politiche di sicurezza che regolano l'accesso ai servizi critici devono essere gestite con un livello di disciplina commisurato all'infrastruttura. Il programma di resilienza operativa della Financial Conduct Authority (FCA) richiede alle aziende regolamentate di identificare i servizi aziendali critici e di dimostrare, in modo continuativo, che l'infrastruttura di supporto rimanga entro i limiti di tolleranza stabiliti per l'impatto.

L'Autorità di regolamentazione del mercato del gas e dell'elettricità (Ofgem) sta valutando i fornitori di servizi essenziali in base al quadro di valutazione della sicurezza informatica del Centro nazionale per la sicurezza informatica (NCSC), verificando se specifici risultati in materia di sicurezza vengano raggiunti in modo continuativo. Il disegno di legge sulla sicurezza informatica e la resilienza, che dovrebbe entrare in vigore entro la fine dell'anno, estenderà obblighi simili ai data center , ai fornitori di servizi gestiti e ai fornitori di servizi critici.

Questi framework non sono prescrittivi e dettagliati; nessuno di essi definisce le regole del firewall che un'organizzazione deve avere o come configurare le sue policy per il settore retail. Ciò che richiedono è una prova: che ciò che l'ambiente delle policy consente corrisponda a quanto previsto e che l'organizzazione sia in grado di dimostrarlo in modo coerente, anziché dover ricostruire le prove per ogni valutazione.

Perché il sistema attuale non è in grado di soddisfare questo standard?

La maggior parte degli ambienti di policy non è mai stata progettata per soddisfare questo standard. Anzi, la maggior parte degli ambienti di policy non è stata nemmeno creata consapevolmente o intenzionalmente. Piuttosto, le policy tendono ad accumularsi come sottoprodotto dei processi di implementazione. Ogni progetto e migrazione aggiunge nuove regole, e pochissime vengono rimosse.

Col tempo, la “superficie delle politiche” – ovvero l’insieme completo di regole e decisioni di accesso attraverso i vari livelli di implementazione – diventa più ampia di quanto il gruppo di persone che la comprendono sia in grado di gestire, e il sistema raggiunge un punto in cui può essere gestito ma non spiegato.

Nei settori regolamentati come quello bancario, energetico e sanitario, questo approccio era sostenibile nell'ambito dei precedenti quadri normativi: valutazioni periodiche, audit basati sui controlli e sistemi di conformità che si concentravano sull'esistenza dei controlli piuttosto che sulla loro efficacia. Ma questo non è più sufficiente. Il nuovo standard richiede prove continue che l'accesso sia intenzionale.

I risultati dell'indagine della Financial Conduct Authority (FCA), condotta dopo un anno di autovalutazioni sulla resilienza operativa, illustrano come ciò si traduca nella pratica. Nei casi in cui le aziende regolamentate hanno segnalato poche o nessuna vulnerabilità di sicurezza rilevante nell'infrastruttura a supporto dei loro servizi aziendali critici, la FCA ha spesso ritenuto le prove insufficienti per stabilire se le vulnerabilità non esistessero effettivamente o se semplicemente non fossero state scoperte.

Questa lezione si applica direttamente alla governance delle politiche di sicurezza: nessuna organizzazione può affermare con certezza che le vulnerabilità di accesso siano sotto controllo senza fornire prove di ciò che le sue politiche consentono, di come sono state testate e se le vulnerabilità sono state risolte.

Requisiti di governance a livello di infrastruttura

Spesso, la risposta è quella di richiedere maggiore trasparenza e documentazione. Ma la documentazione cattura solo un momento specifico nel tempo; non può fornire la garanzia continua che le autorità di regolamentazione si aspettano.

In un'azienda regolamentata, il CISO ha bisogno di qualcosa di più di una semplice documentazione di ciò che l'ambiente normativo consente. Configurazione e accesso effettivo non sono la stessa cosa. I team di sicurezza devono comprendere come interagiscono regole, percorsi, oggetti e livelli di implementazione per determinare cosa può effettivamente comunicare.

Il rispetto di questo standard implica la conciliazione di due aspetti: dimostrare che ciò che l'ambiente effettivamente consente corrisponde a ciò che era stato progettato per consentire, ed essere in grado di provarlo senza preavviso.

Distinguiamo il punto in cui viene definita la policy dal punto in cui viene applicata. La definizione della policy è centralizzata e gestita in modo centralizzato, mentre l'applicazione rimane distribuita tra firewall, controlli cloud e microsegmentazione in ambienti ibridi, multi-cloud e multi-vendor.

Tale intento viene verificato in modo continuo, anziché essere controllato solo in fase di revisione: le modifiche proposte vengono testate rispetto alle policy prima di essere implementate in produzione e l'accesso effettivo viene valutato costantemente per individuare esposizioni non necessarie, incongruenze tra i diversi livelli di implementazione e deviazioni dall'intento aziendale. Ciò che è stato consentito e ciò che è stato modificato viene conservato come prova.

Lo stesso responsabile della sicurezza informatica che non accetterebbe mai una piattaforma di pagamento operante senza monitoraggio continuo, controllo delle modifiche verificato e dipendenze documentate, dovrebbe applicare questo standard all'ambiente normativo che determina se una piattaforma è accessibile o meno.

La Financial Conduct Authority (FCA), il Cyber ​​Assessment Framework del National Cyber ​​Security Center (NCSC) e il Cyber ​​Security and Resilience Bill puntano tutti alla stessa domanda fondamentale: questa organizzazione è in grado di dimostrare in modo coerente che l'infrastruttura a supporto dei suoi servizi critici è gestita secondo gli standard richiesti da tali servizi?

Rispondere a questa domanda significa conoscere (conoscenza reale, non supposizioni né ricostruzioni a seguito di un'analisi approfondita) ciò che il contesto normativo consente in un dato momento e se ciò che consente corrisponde alle intenzioni dell'autore. Queste indispensabili questioni infrastrutturali rappresentano un punto di partenza cruciale in questo contesto.