Cybersecurity, 10 KPI che un CISO dovrebbe monitorare

Quali sono i KPI che un CISO dovrebbe utilizzare per definire le priorità, prendere decisioni informate, monitorare i progressi e garantire che l’organizzazione rimanga protetta contro le minacce informatiche? Come sostiene la società Balbix in un suo documento, il problema è che la cybersecurity riguarda una vasta gamma di aree e che ciascuna area ha tipi specifici di dati e metriche.

Da dove partire quindi?

Come viene “misurata” la cybersecurity

La sfida per i CISO è che spesso business e security parlano lingue diverse. Ad esempio, se il direttore di una line of business chiedesse al CISO le metriche di cybersecurity relative alla sua area, probabilmente riceverebbe un rapporto su asset cloud e dispositivi on-premise. Queste metriche operative non sempre sono in grado di mostrare i rischi economici per il business.

Sia chiaro, avere metriche operative è positivo. Tuttavia, queste non si traducono direttamente in costi e ricavi e non sono sempre di supporto al processo decisionale aziendale.

Questo richiede un cambio di mindset del CISO che implica concentrarsi su metriche che possano tradurre il linguaggio tecnico della sicurezza in termini comprensibili per il business.

I CISO dovrebbero iniziare a parlare più di costi e rischi in termini economici. Concentrarsi sui risultati, rende anche possibile anche comunicare più chiaramente come gli investimenti in sicurezza portino a riduzioni misurabili del rischio. Questo può avvenire parallelamente all’uso delle metriche più operative.

Scegliere tra metriche operative e aziendali è quindi una falsa scelta. Non sono in alternativa. Piuttosto, è importante identificare metriche che colleghino i risultati operativi della sicurezza alla mission aziendale.

Le 10 principali metriche da considerare

Cominciamo col dire che la gestione delle cybersecurity posture (lo stato di sicurezza delle reti, delle informazioni e dei sistemi di un’azienda basato su risorse come persone, hardware, software, policy… e sulle competenze disponibili, secondo la definizione del National Institute of Standards and Technology) tipicamente include tre aree principali:

1. Inventario degli asset digitali

2. Gestione delle vulnerabilità (configurazioni errate, vulnerabilità software, password deboli)

3. Quantificazione del rischio informatico

Le 10 metriche che seguono sono state raggruppate secondo questa divisione. Gli analisti di Balbix hanno scelto questi KPI per la loro utilità nel collegare le security operations alla mission aziendale.

Per ciascuna metrica, i CISO dovrebbero determinare gli SLA (Service Level Agreements) allineati alle esigenze della loro organizzazione in base sia alla maturità della loro postura di sicurezza sia agli obiettivi futuri. Ad esempio, un CISO potrebbe avere un buon inventario software per solo il 10% degli asset aziendali al momento della valutazione, ma fare uno sforzo mirato per raddoppiare tale percentuale nei sei mesi successivi.

Inventario degli asset

1. Copertura dell’inventario degli asset

• Metrica. Percentuale di asset aziendali per i quali sono disponibili informazioni accurate e dettagliate sugli attributi, inclusa la categoria (server, container, notebook, dispositivi IoT, bucket S3, istanza EC2, ecc.), la posizione, gli utenti e così via.

• Considerazioni aggiuntive. I CISO non possono sapere esattamente quanti asset non sono visibili al team di sicurezza. D’altro canto, i CISO possono e dovrebbero mettere in atto pratiche per migliorare la loro visibilità sugli asset aziendali (arrivando a una copertura molto buona, di oltre il 95%). Ad esempio, il team di sicurezza sa quando viene creato un nuovo asset cloud? Monitora costantemente l’ambiente DNS alla ricerca di nuovi dispositivi?

• Risultati di sicurezza. Identificare asset non gestiti, determinare l’adeguatezza della posizione e dell’accesso degli asset, realizzare una base per la valutazione delle vulnerabilità e dei rischi.

• Risultati di business. Ridurre i costi identificando dispositivi e asset inutilizzati, sotto-utilizzati o mal utilizzati, limitare il rischio attraverso una gestione più completa delle vulnerabilità.

2. Copertura dell’inventario software

• Metrica. Percentuale di asset per i quali è disponibile l’inventario software, comprese le differenti versioni.

• Risultati di sicurezza. Identificare CVE (Common Vulnerabilities and Exposures) basate sul sistema operativo installato e sulle versioni delle applicazioni.

• Risultati aziendali. Ridurre i costi di abbonamento o delle tariffe di manutenzione identificando software obsoleti, ridurre i tempi di inattività non programmati a causa dello sfruttamento delle vulnerabilità (con misurazioni su base trimestrale o annuale), ridurre il rischio attraverso una gestione più completa delle vulnerabilità.

3. Copertura dei controlli di sicurezza

• Metrica: Percentuale di asset coperti dai controlli di sicurezza richiesti dall’azienda (EPP/EDR, IAM, VPN/ZTNA, DLP, backup, eccetera) per quegli asset.

• Considerazioni aggiuntive: Questa metrica potrebbe essere misurata separatamente per controlli specifici, ad esempio per la protezione degli endpoint o l’autenticazione multifattore, o come una singola metrica su un set più ampio

• Risultati di sicurezza. Incrementare la percentuale di asset oggetto dei check di sicurezza richiesti dall’azienda, ridurre il numero di asset che hanno subito degli incidenti di sicurezza

• Risultati di business. Ridurre il downtime dovuti a incidenti di sicurezza

Gestione delle vulnerabilità

La gestione delle vulnerabilità si è tradizionalmente concentrata sulle vulnerabilità software (CVE). Negli ultimi anni, il focus si è esteso per includere anche problemi di accesso e configurazioni errate (crittografia debole, servizi non sicuri, problemi con i certificati TLS/SSL, configurazioni errate del cloud). Le configurazioni errate del cloud sono particolarmente importanti poiché molte organizzazioni nel loro percorso di migrazione alla nuvola trascurano il fatto che i sistemi cloud non hanno le stesse protezioni del firewall aziendale.

4. Copertura della valutazione delle vulnerabilità

• Metrica. Percentuale di asset coperti dai tool di vulnerability assesment.

• Considerazioni aggiuntive. Oltre alla copertura di base, ci sono altre domande da porsi. Ad esempio, quanti asset hanno scansioni autenticate rispetto a quelle non autenticate? Qual è la frequenza con cui le informazioni sulle vulnerabilità vengono aggiornate?

• Risultati di sicurezza: Migliorare la visibilità delle vulnerabilità (CVE, configurazioni errate, password riutilizzate, crittografia debole, problemi di accesso, eccetera).

• Risultati aziendali: Identificare le aree di business con vulnerabilità. Gli asset possono essere raggruppati per mappare il rischio per line of business, area geografica, tipo di asset, data center e via dicendo

5. Periodo temporale durante il quale le vulnerabilità rimangono aperte

• Metrica. Durata media (in giorni) di tutte le vulnerabilità aperte.

• Risultati di sicurezza. Ridurre il tempo disponibile per lo sfruttamento delle vulnerabilità critiche.

• Risultati aziendali: Ridurre il tempo di inattività non programmato causato dallo sfruttamento delle vulnerabilità critiche (periodo di tempo: mensile, trimestrale).

6. Mean Time to Patch (MTTP)

• Metrica. MTTP per le vulnerabilità software critiche che vengono attivamente sfruttate.

• Risultati di sicurezza: Ridurre l’intervallo di tempo in cui le vulnerabilità critiche possono essere sfruttate.

• Risultati aziendali: Ridurre il tempo di inattività non programmato causato dallo sfruttamento delle vulnerabilità critiche (periodo di tempo: mensile, trimestrale).

7. Mean Time to Remediate (MTTR)

• Metrica: Tempo medio per la remediation (MTTR, in giorni).

• Considerazioni aggiuntive: Questa metrica viene tipicamente monitorata separatamente per vulnerabilità ad alta, media e bassa gravità. È una metrica simile a MTTP, ma dovrebbe includere anche vulnerabilità risolte con mezzi diversi da una patch. Per le vulnerabilità software, il tempo di recupero include anche il riavvio del sistema e la conferma che una patch sia stata applicata correttamente (inclusi anche i test).

• Risultati di sicurezza: Ridurre la percentuale di tempo disponibile per lo sfruttamento delle vulnerabilità software.

• Risultati aziendali: Ridurre la percentuale di esiti negativi per l’azienda (dati esposti, interruzioni non programmate, ecc.) causati dallo sfruttamento delle vulnerabilità (cadenza: trimestrale, annuale). Ridurre il tempo (in giorni) per soddisfare i requisiti di auditing.

Quantificazione del rischio informatico

Calcolare i costi economici dei rischi informatici non è facile, ma si possono fare alcuni ragionamenti

8. Probabilità di violazione

• Metrica. Probabilità (%) di una violazione.

• Considerazioni aggiuntive. Questa metrica richiede un inventario dettagliato degli asset di un’organizzazione e delle vulnerabilità di quegli asset. Deve essere considerata la gravità e il livello di minaccia di ciascuna vulnerabilità, nonché l’esposizione e i controlli di sicurezza dell’asset sottostante.

• Risultati di sicurezza. Ridurre la frequenza delle violazioni.

• Risultati aziendali: Migliorare la fiducia di clienti, dipendenti, fornitori, stakeholder.

9. Impatto della violazione

• Metrica. Impatto della violazione (in euro).

• Considerazioni aggiuntive. Devono essere considerati sia i costi primari che secondari di una violazione. I costi primari includono i costi per rilevare, investigare e fare la remediation. I costi secondari includono i costi di business persi, le notifiche di violazione, eventuali multe.

• Risultati di sicurezza: Dare priorità alla remediation delle vulnerabilità business critical.

• Risultati aziendali: Dare priorità agli asset business critical per applicare livelli appropriati di controlli di sicurezza informatica.

10. Rischio di violazione

• Metrica. Rischio di violazione (euro).

• Considerazioni aggiuntive. Il rischio di violazione può essere calcolato moltiplicando la probabilità di una violazione (%) per l’impatto di una violazione (euro). Ad esempio, un’organizzazione con una probabilità di violazione del 70% e un potenziale impatto di violazione di 1 milione di euro ha un rischio di violazione di 700k euro. Queste considerazioni dovrebbero poi guidare la classificazione dei rischi in 4 categorie: rischio intrinseco, rischio mitigato (a causa degli investimenti in controlli e programmi di sicurezza), rischio accettato (a causa delle accettazioni del rischio e delle politiche SLA concordate con gli stakeholder aziendali) e rischio residuo da gestire con contratti assicurativi o altre procedure. Questi livelli di rischio possono quindi essere confrontati con i livelli accettabili di rischio da un punto di vista aziendale e finanziario.

• Risultati di sicurezza. Arrivare a una gestione della vulnerabilità basata sul contesto aziendale e non solo sulla gravità delle vulnerabilità e sul livello di minaccia. Calcolare il rischio di violazione per asset, tipo di asset, sito (fornitore/sito cloud, data center) e non solo. Calcolare il ROI degli investimenti in sicurezza e acquisire la capacità di giustificare investimenti presenti e futuri.
• Risultati aziendali: Ridurre il rischio di violazione. Calcolare il rischio di violazione per unità aziendale (linea di business, area geografica, ecc.). Acquisire la capacità di comunicare il rischio a management e stakeholders. Ridurre i costi assicurativi legati al rischio informatico. Migliorare la compliance, e, naturalmente, comparare il rischio residuo e il rischio accettabile.