Rischi, vulnerabilità e zero trust: termini chiave su cui CISO e consigli di amministrazione devono capirsi

Per attuare programmi di sicurezza informatica efficaci e mantenere il team addetto alla sicurezza radicalmente integrato in tutti i processi aziendali, il CISO deve dimostrare periodicamente il valore di questo lavoro al top management. Ciò richiede di parlare la stessa lingua, ma una trappola pericolosa attende coloro che ci provano.  Professionisti della sicurezza e dirigenti usano spesso le stesse parole, ma intendendo cose completamente diverse. A volte, termini diversi vengono utilizzati in modo intercambiabile. Di conseguenza, il top management potrebbe non capire quali minacce il team di sicurezza sta cercando di mitigare, quale sia il livello effettivo di resilienza informatica dell’azienda o in cosa vengono allocati budget e risorse. Pertanto, prima di presentare dashboard sofisticate o calcolare il ROI dei programmi di protezione, vale la pena chiarire queste importanti sfumature terminologiche.

Chiarendo questi termini e costruendo una terminologia condivisa, CISO e consiglio di amministrazione possono migliorare significativamente la comunicazione e, in ultimo, rafforzare il generale atteggiamento di sicurezza dell’organizzazione.

Perché la terminologia della sicurezza informatica è importante per il management

Le diverse interpretazioni dei termini rappresentano più di un semplice inconveniente; le conseguenze possono essere piuttosto sostanziali. La mancanza di chiarezza riguardo ai dettagli può comportare:

• Investimenti mal allocati. La direzione potrebbe approvare l’acquisto di una soluzione zero trust senza rendersi conto che è solo una parte di un più ampio programma a lungo termine che richiede un budget sensibilmente maggiore. Il denaro viene speso, ma i risultati attesi dal management non arrivano mai. Analogamente, il management può presumere che insieme alla migrazione al cloud venga trasferita automaticamente al provider anche tutta la responsabilità della sicurezza, inducendo a rigettare ogni altro budget per la specifica sicurezza del cloud.
• Accettazione cieca del rischio. I leader delle business unit possono accettare i rischi alla sicurezza informatica senza avere una comprensione completa delle potenziali conseguenze.
• Mancanta governance. Senza conoscere la terminologia, il management non può porre le giuste (e difficili) domande, né assegnare in modo efficace le aree di responsabilità. È stato spesso riscontrato come, al verificarsi di un incidente, i titolari di attività commerciali credessero che la sicurezza dovesse ricadere interamente nelle competenze del CISO, laddove quest’ultimo invece non disponeva dell’autorità per influenzare i processi aziendali.

Rischio informatico e rischio IT

Molti dirigenti ritengono che la sicurezza informatica sia una questione puramente tecnica che può essere trasferita all’IT. Anche se l’importanza della sicurezza informatica per le aziende è indiscutibile e gli incidenti informatici sono da tempo considerati uno dei principali rischi per le aziende, i sondaggi mostrano che molte organizzazioni non riescono ancora a coinvolgere i leader non tecnici nelle discussioni sulla sicurezza informatica.

I rischi per la sicurezza delle informazioni sono spesso accomunati a preoccupazioni dell’IT come i tempi di inattività e la disponibilità dei servizi.  In realtà, il rischio informatico è un rischio aziendale strategico legato alla continuità aziendale, alla perdita finanziaria e al danno reputazionale.

I rischi IT sono generalmente di natura operativa e influiscono sull’efficienza, l’affidabilità e la gestione dei costi. La reazione agli incidenti IT spesso è gestita interamente dal personale IT. I gravi incidenti di sicurezza informatica, tuttavia, hanno una portata molto più ampia; richiedono il coinvolgimento di quasi tutti i reparti e hanno un impatto a lungo termine sull’organizzazione in molti modi anche per quanto riguarda reputazione, conformità alle normative, relazioni con i clienti e stato finanziario.

Conformità e sicurezza

La sicurezza informatica è integrata nei requisiti normativi a ogni livello: dalle direttive internazionali come NIS2 e GDPR alle linee guida di settore transfrontaliere come PCI DSS, oltre a specifici mandati dipartimentali. Di conseguenza, il management spesso intende le misure di sicurezza informatica come voci in una checklist di conformità, ritenendo risolti i problemi una volta soddisfatti i requisiti normativi. Questa mentalità può derivare dal tentativo consapevole di ridurre al minimo le spese per la sicurezza (“non facciamo più del minimo dovuto”) o da un sincero malinteso (“abbiamo superato un audit ISO 27001, quindi siamo inattaccabili”).

In realtà, conformità significa soddisfare i requisiti minimi dei revisori dei conti e delle autorità di regolamentazione in un dato momento. Sfortunatamente, la storia degli attacchi informatici su vasta scala alle principali organizzazioni dimostra che i requisiti “minimi” lo sono di nome e di fatto. Per una protezione reale dalle moderne minacce informatiche, le aziende devono migliorare continuamente le strategie e le misure di sicurezza in base alle esigenze specifiche del loro settore.

Minaccia, vulnerabilità e rischio

Questi tre termini sono spesso usati come sinonimi, il che porta a conclusioni errate dal management: “c’è una vulnerabilità critica nel nostro server? Allora abbiamo un rischio critico!” Per evitare il panico o, al contrario, l’inazione, è fondamentale utilizzare questi termini con precisione e capire come sono correlati tra loro.

Una vulnerabilità è una debolezza: una “porta aperta”. Può essere un difetto nel codice del software, un’errata configurazione del server, una sala server esposta ad accessi non autorizzati o un dipendente che apre ogni singolo allegato e-mail.

Una minaccia è una potenziale causa di incidente. Potrebbe trattarsi di un utente malintenzionato, di un malware o addirittura di una calamità naturale. Una minaccia è ciò che potrebbe “entrare da quella porta aperta”.

Il rischio consiste in perdite. Rappresenta la valutazione cumulativa della probabilità che un attacco vada a buon fine e di ciò che l’organizzazione perderà (l’impatto).

Le connessioni tra questi elementi possono essere spiegate con una semplice formula:

Rischio = (Minaccia × Vulnerabilità) × Impatto

Vediamo un esempio. Supponiamo che venga rilevata una vulnerabilità critica con una classificazione di gravità massima in un sistema obsoleto. Questo sistema è però disconnesso da tutte le reti, si trova in una stanza isolata ed è gestito da tre soli dipendenti controllati. La probabilità che un utente malintenzionato lo penetri è prossima allo zero. Nel frattempo, la mancanza di autenticazione a due fattori nei sistemi contabili crea un rischio reale elevato, derivante sia da un’alta probabilità di attacco che da un significativo danno potenziale.

Risposta agli incidenti, ripristino di emergenza e business continuity

La percezione che il management ha delle crisi della sicurezza è spesso eccessivamente semplificata: “in caso di ransomware basta attivare il piano di Disaster Recovery IT e ripristinare dai backup”. Tuttavia, mescolare questi concetti (e questi processi) è estremamente pericoloso.

La reazione agli incidenti è responsabilità del team di sicurezza o di appaltatori specializzati. Il loro compito è localizzare la minaccia, espellere l’utente malintenzionato dalla rete e arrestare la diffusione dell’attacco.

Il ripristino di emergenza (o Disaster Recovery, DR) è un’attività di ingegneria IT. È il processo di ripristino di server e dati dai backup dopo il completamento della risposta agli incidenti.

La Business Continuity (BC) è un’attività strategica per il top management. È il piano che prevede come l’azienda continuerà a servire i clienti, spedire merci, pagare compensi e parlare con la stampa per il tempo in cui i suoi sistemi primari rimangono offline.

Se la direzione si concentra esclusivamente sul ripristino, l’azienda non avrà un piano d’azione per il periodo di inattività più critico.

Consapevolezza della sicurezza e cultura della sicurezza

I leader di ogni livello talvolta danno per scontato che il semplice svolgimento di una formazione sulla sicurezza garantisca i risultati: “i dipendenti hanno superato il test annuale, quindi non faranno clic su link di phishing”. Purtroppo, fare affidamento esclusivamente sulla formazione organizzata da HR e IT non basta. L’efficacia aziendale richiede la modifica dei comportamenti dei team, operazione impossibile senza il coinvolgimento del management.

Consapevolezza è conoscenza. Un dipendente sa cos’è il phishing e comprende l’importanza delle password complesse.

La cultura della sicurezza riguarda i modelli comportamentali. È ciò che un dipendente fa in una situazione sotto stress o quando nessuno lo vede. La cultura non è plasmata dai test, ma da un ambiente in cui è sicuro segnalare gli errori e dove è consuetudine identificare e prevenire situazioni potenzialmente pericolose. Un dipendente che teme una punizione nasconderà un incidente. In una cultura sana, invece, segnalerà un’e-mail sospetta al SOC o avvertirà un collega che si dimentica di bloccare lo schermo del computer, agendo così da anello attivo nella catena di difesa.

Rilevamento e prevenzione

I dirigenti aziendali spesso pensano in categorie obsolete di “mura della fortezza”: “abbiamo acquistato sistemi di protezione costosi, quindi siamo protetti da hackeraggi e se si verifica un incidente è un fallimendo del CISO”. Nella pratica, prevenire il 100% degli attacchi è tecnicamente impossibile ed economicamente proibitivo. La strategia moderna si basa sull’equilibrio tra sicurezza informatica ed efficacia aziendale. In un sistema equilibrato, i componenti incentrati sul rilevamento e la prevenzione delle minacce lavorano in tandem.

La prevenzione devia gli attacchi di massa automatizzati.

Il rilevamento e la risposta aiutano a identificare e neutralizzare gli attacchi più professionali e mirati che riescono ad aggirare gli strumenti di prevenzione o a sfruttare le vulnerabilità.

L’obiettivo chiave del team di sicurezza informatica oggi non è garantire l’invulnerabilità totale, ma rilevare un attacco in una fase iniziale e ridurre al minimo l’impatto sull’azienda. Per misurare il successo in questo caso, il settore utilizza in genere metriche come Mean Time to Detect (MTTD) e Mean Time to Respond (MTTR).

Filosofia zero trust e prodotti zero trust

Il concetto zero trust implica “non fidarsi mai, verificare sempre” per tutti i componenti dell’infrastruttura IT ed è riconosciuto da tempo come pertinente ed efficace nella sicurezza aziendale. Richiede la verifica costante dell’identità (account utente, dispositivi e servizi) e del contesto per ogni richiesta di accesso, partendo dal presupposto che la rete sia già stata compromessa.

Tuttavia, la sola etichetta “zero trust” nel nome di una soluzione di protezione non significa che un’organizzazione possa adottare questo approccio dall’oggi al domani semplicemente acquistando il prodotto.
Zero trust non è un prodotto che si può “accendere”, bensì una strategia architettonica e un percorso di trasformazione a lungo termine. La messa in atto di zero trust richiede la ristrutturazione dei processi di accesso e il perfezionamento dei sistemi IT per garantire la verifica continua dell’identità e dei dispositivi. L’acquisto di software senza cambiamenti nei processi non avrà effetti significativi.

Sicurezza del cloud e sicurezza nel cloud

Durante la migrazione dei servizi IT a un’infrastruttura cloud come AWS o Azure, spesso c’è l’illusione di un trasferimento totale del rischio: “paghiamo il provider, quindi ora la sicurezza è roba loro”. Si tratta di un pericoloso malinteso e di un’interpretazione errata di ciò che è noto come “modello di responsabilità condivisa”.

La sicurezza del cloud è responsabilità del provider. Protegge i data center, i server fisici e il cablaggio.

La sicurezza nel cloud è responsabilità del cliente.

Le discussioni relative ai budget per i progetti cloud e ai relativi aspetti di sicurezza devono essere accompagnate da esempi reali. Il provider protegge il database da accessi non autorizzati in base alle impostazioni configurate dai dipendenti del cliente. Se i dipendenti lasciano un database aperto o utilizzano password deboli e se l’autenticazione a due fattori non è abilitata per il pannello di amministrazione, il provider non può impedire a persone non autorizzate di scaricare le informazioni, un fatto di cronaca fin troppo comune. Pertanto, il budget per questi progetti deve tenere conto degli strumenti di sicurezza per il cloud e della gestione della configurazione da parte dell’azienda.

Scansione delle vulnerabilità e test di penetrazione

I leader spesso confondono i controlli automatici, che rientrano nell’ambito dell’igiene informatica, con la valutazione della resilienza delle risorse IT contro attacchi sofisticati: “perché pagare gli hacker per un pentest quando eseguiamo scansioni ogni settimana?”

La scansione delle vulnerabilità verifica la presenza di vulnerabilità note in un elenco specifico di risorse IT. Per dirla semplicemente, è come un metronotte che fa il giro per controllare che le porte e le finestre dell’ufficio siano chiuse a chiave.

Il test di penetrazione (pentesting) è una valutazione manuale volta a valutare la possibilità di una violazione nel mondo reale sfruttando le vulnerabilità. Per continuare l’analogia, è come assumere un ladro esperto per tentare effettivamente di scassinare l’ufficio.

Una cosa non sostituisce l’altra; per comprendere il reale atteggiamento di sicurezza di un’azienda sono necessari entrambi gli strumenti.

Risorse gestite e superficie di attacco

Un malinteso comune e pericoloso riguarda l’ambito della protezione e la visibilità complessiva di cui dispongono i reparti IT e di sicurezza. Un ritornello comune durante le riunioni è: “abbiamo un inventario accurato dell’hardware: tutto ciò che possediamo è protetto”.

Le risorse IT gestite sono elementi che il reparto IT ha acquistato, configurato e visualizza nei propri rapporti.

Una superficie di attacco è qualsiasi cosa accessibile agli utenti malintenzionati: qualsiasi potenziale punto di ingresso nell’azienda. Ciò include lo Shadow IT (servizi cloud, app di messaggistica personale, server di prova e così via…), ovvero qualsiasi cosa i dipendenti lanciano di propria iniziativa eludendo i protocolli ufficiali per velocizzare o semplificare il proprio lavoro. Spesso sono queste risorse “invisibili” a diventare il punto di ingresso per un attacco, poiché il team di sicurezza non può proteggere ciò di cui ignora l’esistenza.