Metriche di sicurezza: guida pratica per CISO e responsabili IT

Le metriche di sicurezza informatica sono misure quantificabili che valutano l’efficacia dei controlli, la maturità dei processi e il livello di protezione degli asset nel tempo. Secondo l’Agenzia per la cybersicurezza nazionale (ACN), i KPI rappresentano la categoria più importante di metriche: misurano il progresso rispetto a target prefissati e sintetizzano informazioni per diversi livelli decisionali. La distinzione è operativa: ogni metrica diventa KPI solo quando le si associa una soglia e un obiettivo verificabile.

I riferimenti normativi di partenza sono tre:

• ACN: definisce metriche e KPI come strumenti centrali del monitoraggio della strategia di cybersicurezza, con attributi obbligatori quali identificativo, cadenza e livello di affidabilità.
• ISO 27004: fornisce linee guida per il monitoraggio, la misurazione, l’analisi e la valutazione delle prestazioni dell’ISMS, con circa 35 esempi pratici di misurazioni applicabili.
• MTTD e MTTR: tempo medio di rilevazione (Mean Time to Detect) e tempo medio di risposta (Mean Time to Respond) agli incidenti, le due metriche tempo-centriche più diffuse nei SOC.

Indice

• Cosa sono le metriche di sicurezza: definizione estesa e differenze dai KPI
• Perché le metriche di sicurezza contano: decisioni operative, tattiche e strategiche
• Quali sono le principali tipologie di metriche di sicurezza per ambienti enterprise
• Come si calcolano MTTD, MTTR e MTTC: approfondimento operativo
• Quali attributi deve avere una metrica per essere affidabile in produzione
• Esempi di metriche mappati su NIST e ISO 27004: checklist operativa
• Come raccogliere i dati: strumenti, integrazioni e buone pratiche tecniche
• Errori comuni e raccomandazioni di governance nella misura della sicurezza
• Roadmap in 6 passi per avviare un programma di metriche di sicurezza
• ISO 27004, linee guida ACN e NIST: dove trovare i riferimenti normativi
• Punti chiave
• Misurare per governare, non per rassicurare
• Securityhub affianca le organizzazioni nella definizione di metriche conformi a ISO 27001
• Fonti utili e letture consigliate

Cosa sono le metriche di sicurezza: definizione estesa e differenze dai KPI

Una metrica di sicurezza è qualsiasi grandezza misurabile che descrive lo stato o il comportamento di un controllo, processo o programma di sicurezza. Il termine «indicatore» è spesso usato come sinonimo, ma nella pratica professionale si distinguono tre livelli:

• Metriche operative: misurano attività quotidiane (numero di alert gestiti, tempo di chiusura ticket, percentuale di sistemi con agente EDR attivo).
• Metriche tattiche: valutano l’avanzamento di programmi specifici (tasso di patching mensile, completamento dei corsi di formazione, copertura degli asset inventariati).
• Metriche strategiche: comunicano il rischio residuo e il ritorno degli investimenti alla dirigenza (costo medio per incidente, indice di maturità del programma di sicurezza).

Un KPI è una metrica tattica o strategica a cui si aggiunge un target numerico e una soglia di accettabilità. Senza target, una metrica resta un dato descrittivo; con il target diventa uno strumento di governo. Questa distinzione è esplicita nelle linee guida ACN: i KPI «indicheranno il grado di attuazione delle misure, espresso in termini percentuali, sulla base di una media ponderata dei valori dei singoli indicatori».

Ogni metrica affidabile deve avere almeno sei attributi:

• Identificativo univoco: codice o nome che la distingue nel catalogo.
• Unità di misura: percentuale, ore, numero assoluto, rapporto.
• Fonte dati: sistema o processo da cui il dato viene estratto.
• Owner: responsabile della raccolta e della qualità del dato.
• Cadenza: frequenza di raccolta (giornaliera, settimanale, mensile).
• Livello di affidabilità: alta (dato automatico e univoco), media (dato parzialmente soggettivo), bassa (da evitare in produzione).

Un consiglio: Prima di adottare una nuova metrica, verificate che abbia tutti e sei gli attributi. Una metrica senza owner non viene aggiornata; una senza fonte definita produce dati incoerenti.

Perché le metriche di sicurezza contano: decisioni operative, tattiche e strategiche

Un sistema di monitoraggio basato su metriche ben definite consente di valutare le attività in corso rispetto agli obiettivi, misurare l’efficacia delle azioni di mitigazione e analizzare il ritorno degli investimenti in sicurezza. Senza dati misurabili, le decisioni di budget e priorità si basano su percezioni, non su evidenze.

A livello operativo, metriche come MTTD e MTTR guidano il SOC nel migliorare i tempi di rilevazione e contenimento degli incidenti. Un rapporto anomalo tra alert segnalati e incidenti reali, per esempio, segnala la necessità di riconfigurare i sistemi di rilevazione prima che il problema si aggravi.

Sul piano tattico, il tasso di patching e il completamento della formazione mostrano se i programmi di sicurezza avanzano secondo piano. Sul piano strategico, le metriche traducono i controlli tecnici in indicatori di impatto sul business comprensibili dal consiglio di amministrazione: costo per incidente, indice di rischio residuo, percentuale di sistemi conformi alle policy.

L’ACN sottolinea che la mancata tracciabilità delle metriche, o un monitoraggio non accurato, «potrebbero compromettere l’efficacia delle misure in essere, aumentando il rischio cyber e disperdendo risorse economiche e temporali». Il ruolo delle metriche di sicurezza è quindi duplice: strumento di controllo interno e linguaggio comune tra team tecnici e dirigenza.

Quali sono le principali tipologie di metriche di sicurezza per ambienti enterprise

Le metriche si raggruppano in tre famiglie funzionali. Conoscere la famiglia di appartenenza aiuta a scegliere la fonte dati giusta e il pubblico corretto per il report.

Metriche tempo-centriche

• MTTD (Mean Time to Detect): tempo medio tra l’inizio di un incidente e la sua rilevazione.
• MTTR (Mean Time to Respond): tempo medio tra la rilevazione e il contenimento o la risoluzione.
• MTTC (Mean Time to Contain): tempo medio per isolare l’incidente e impedirne la propagazione.

Metriche tecniche su vulnerabilità e patching

• Numero e gravità delle vulnerabilità aperte (per asset, per sistema critico).
• Tasso di conformità delle patch: percentuale di sistemi aggiornati entro la finestra di patching definita.
• Ricorrenza delle vulnerabilità: quante vulnerabilità già corrette ricompaiono dopo un ciclo.
• Tentativi di intrusione bloccati per periodo.

Metriche su processi e comportamento umano

• Tasso di completamento della formazione obbligatoria in sicurezza.
• Tasso di clic su simulazioni di phishing.
• Tempo medio di chiusura dei ticket di sicurezza.
• Copertura degli asset: percentuale di dispositivi presenti nell’inventario e monitorati attivamente.

Questo elenco operativo è allineato alle metriche chiave raccomandate per ambienti enterprise, che includono MTTD, MTTR, MTTC, tasso di conformità delle patch, ricorrenza delle vulnerabilità, tasso di clic phishing e completamento della formazione.

Come si calcolano MTTD, MTTR e MTTC: approfondimento operativo

Le tre metriche tempo-centriche si calcolano come medie aritmetiche su un insieme di incidenti in un periodo definito.

Tre limiti pratici da tenere presenti:

• Outlier: un singolo incidente complesso può distorcere la media. Affiancare la mediana alla media riduce questo effetto.
• Qualità della fonte dati: se i timestamp nei log non sono sincronizzati (NTP non configurato), i valori calcolati sono inaffidabili.
• Alert non filtrati: un SIEM che genera migliaia di falsi positivi abbassa artificialmente il MTTD perché gli analisti smettono di investigare ogni alert con la stessa attenzione.

Per definire target realistici, conviene partire dalla baseline storica dei propri incidenti prima di confrontarsi con benchmark di settore. Un MTTD di 24 ore può essere eccellente per una PMI con un SOC interno di due persone, mentre sarebbe inaccettabile per un operatore di infrastrutture critiche.

Un consiglio: Automatizzate la raccolta di MTTD e MTTR direttamente dal ticketing o dal SOAR. Calcolarle manualmente su fogli di calcolo introduce errori sistematici e non scala oltre una decina di incidenti al mese.

Quali attributi deve avere una metrica per essere affidabile in produzione

Una metrica adottata senza criteri di qualità produce dati che nessuno usa. L’ACN raccomanda di definire attributi rigorosi per ogni indicatore, distinguendo tre livelli di affidabilità: alta, media e bassa. Gli indicatori a bassa affidabilità non vengono considerati nel Manuale Operativo della Strategia Nazionale.

Gli attributi minimi obbligatori sono:

• Identificativo univoco nel catalogo delle metriche.
• Descrizione chiara e non ambigua dell’oggetto misurato.
• Unità di misura esplicita.
• Fonte dati certificata e documentata.
• Owner nominato con responsabilità formale.
• Cadenza di raccolta definita.
• Livello di affidabilità dichiarato.

Criteri di accettabilità per adottare una metrica in produzione:

1. Ripetibilità: misurazioni successive nelle stesse condizioni producono risultati coerenti.
2. Non ambiguità: la definizione non lascia spazio a interpretazioni diverse tra team diversi.
3. Misurabilità automatizzabile: il dato può essere estratto da un sistema senza intervento manuale continuativo.
4. Azionabilità: il valore della metrica porta a una decisione o a un’azione concreta.
5. Pertinenza: la metrica è collegata a un obiettivo di sicurezza dichiarato.

Un consiglio: Prima di inserire una metrica nel cruscotto, chiedete: «Se questo valore peggiora, chi fa cosa?». Se la risposta non è immediata, la metrica non è ancora azionabile.

Esempi di metriche mappati su NIST e ISO 27004: checklist operativa

Il NIST Cybersecurity Framework organizza le attività di sicurezza in cinque funzioni: Identificare, Proteggere, Rilevare, Rispondere, Recuperare. ISO 27004 richiede che le misurazioni coprano sia l’implementazione dei controlli sia la loro efficacia. La tabella seguente mostra esempi pratici per ciascuna funzione NIST, con indicazione del tipo di misura ISO 27004 corrispondente.

Per adattare questi esempi a contesti diversi, considerare:

• PMI con risorse limitate: priorità alle metriche di implementazione (patching, MFA, inventario asset) che richiedono meno automazione e producono valore immediato per un audit ISO 27001. Le misure di sicurezza ISO per PMI offrono un punto di partenza concreto.
• Enterprise con SOC strutturato: aggiungere metriche di efficienza (MTTD, MTTR, MTTC) e di impatto (costo per incidente, rischio residuo per dominio).
• Ambienti cloud: integrare metriche specifiche su configurazioni errate, accessi privilegiati e conformità alle policy cloud, mappabili verso ISO 27017 e ISO 27018.

Come raccogliere i dati: strumenti, integrazioni e buone pratiche tecniche

La qualità delle metriche dipende dalla qualità delle fonti dati. Ogni strumento nel perimetro di sicurezza produce un tipo specifico di dato.

• SIEM (Security Information and Event Management): aggrega log da sistemi eterogenei, calcola MTTD e fornisce correlazioni per rilevare pattern anomali. Esempi: Microsoft Sentinel, IBM QRadar, Splunk.
• SOAR (Security Orchestration, Automation and Response): automatizza i flussi di risposta e registra i tempi di ogni fase dell’incidente, alimentando MTTR e MTTC.
• EDR (Endpoint Detection and Response): fornisce dati su copertura degli endpoint, alert per host e tempi di contenimento a livello di dispositivo.
• Scanner di vulnerabilità: producono conteggi per gravità (CVSS), tasso di remediation e ricorrenza. Esempi: Tenable Nessus, Qualys.
• CMDB e inventario asset: fonte per la metrica di copertura degli asset e per verificare che ogni sistema sia monitorato.
• Sistemi di ticketing: Jira, ServiceNow o equivalenti registrano i tempi di apertura e chiusura, base per MTTR e tempo di chiusura ticket.

Per una pipeline dati affidabile, tre pratiche sono non negoziabili: sincronizzazione NTP su tutti i sistemi che producono log, normalizzazione dei formati prima dell’ingestion nel SIEM, e definizione di una policy di conservazione dei dati coerente con i requisiti di audit. Per ambienti cloud, la guida sui servizi di sicurezza informatica cloud illustra quali strumenti forniscono i dati più utili per le metriche operative.

Il cruscotto aggregato è il punto di arrivo: un’unica vista che mostra lo stato delle metriche prioritarie, con semafori per soglie e trend storici. Senza automazione nella raccolta, il cruscotto diventa obsoleto in pochi giorni e perde utilità per il management.

Un consiglio: Iniziate con un cruscotto minimo: tre o quattro metriche critiche aggiornate automaticamente valgono più di venti metriche calcolate manualmente ogni mese.

Errori comuni e raccomandazioni di governance nella misura della sicurezza

Il problema più diffuso non è la mancanza di dati, ma la scelta delle metriche sbagliate. Cesare Gallotti, esperto di ISO 27004, osserva che molti professionisti sbagliano cercando di misurare l’assenza di attacchi: è preferibile misurare processi, resilienza e capacità di controllo. «Zero incidenti nel trimestre» non dimostra che i controlli funzionano; dimostra solo che non si è stati attaccati con successo, o che non si è rilevato nulla.

Le vanity metrics più comuni da evitare:

• Numero totale di alert generati (misura il rumore, non l’efficacia).
• Numero di firewall rule attive (misura la complessità, non la protezione).
• Numero di scansioni antivirus eseguite (misura l’attività, non i risultati).

Rischi legati a fonti manuali e reporting inconsistente:

• Dati raccolti manualmente da persone diverse producono serie storiche non confrontabili.
• Senza un owner formale, la metrica non viene aggiornata nei periodi di picco operativo.
• Report prodotti con metodologie diverse tra un trimestre e l’altro rendono impossibile il confronto.

Raccomandazioni di governance:

1. Definire una policy di misurazione che specifichi per ogni metrica: fonte, owner, cadenza, soglie e processo di escalation.
2. Condurre una review trimestrale del catalogo delle metriche: eliminare quelle che non producono decisioni, aggiungere quelle che coprono nuovi rischi.
3. Separare i report operativi (per il SOC) dai report dirigenziali (per il board): stessi dati, livelli di aggregazione diversi.
4. Documentare le variazioni metodologiche: se si cambia la formula di calcolo di una metrica, annotarlo nel catalogo per non invalidare il confronto storico.

Roadmap in 6 passi per avviare un programma di metriche di sicurezza

ISO 27004 promuove un processo ciclico di misurazione: identificazione dei bisogni informativi, creazione delle misure, monitoraggio, analisi e valutazione continua. Tradotto in una roadmap operativa:

1. Identificare bisogni informativi e stakeholder: quali decisioni devono essere supportate dai dati? Chi riceve i report (SOC, CISO, board, auditor)? Le risposte determinano quali metriche hanno priorità.
2. Selezionare le metriche candidate e definire gli attributi: per ogni metrica candidata, compilare la scheda con i sei attributi obbligatori. Scartare quelle senza fonte dati affidabile o senza owner disponibile.
3. Stabilire la baseline e configurare gli strumenti di raccolta: misurare lo stato attuale senza target per almeno un ciclo completo. La baseline è il punto di partenza per definire target credibili. Un assessment di sicurezza ISO 27001 aiuta a strutturare questa fase.
4. Definire target e KPI: sulla base della baseline e degli obiettivi di business, fissare soglie realistiche. Target troppo ambiziosi demotivano; target troppo facili non producono miglioramento.
5. Costruire il cruscotto e il ciclo di report: automatizzare la raccolta, configurare il cruscotto con semafori e trend, definire la cadenza dei report per ciascun pubblico.
6. Revisione periodica e miglioramento continuo: ogni trimestre, verificare se le metriche adottate rispondono ancora ai bisogni informativi. Aggiornare il catalogo, rivedere i target e incorporare le lezioni apprese dagli incidenti.

Per le PMI, i passi 1 e 2 sono spesso i più critici: la tendenza è selezionare troppe metriche senza verificare la disponibilità delle fonti dati. Meglio partire con cinque metriche ben definite che con venti mal documentate. Gli esempi di misure di sicurezza per PMI offrono un catalogo di partenza già testato in contesti con risorse limitate.

ISO 27004, linee guida ACN e NIST: dove trovare i riferimenti normativi

I tre riferimenti principali per chi implementa un programma di metriche in Europa centrale sono complementari, non alternativi.

ISO 27004 definisce il ciclo di misurazione dell’ISMS e la struttura delle misure. La norma si integra direttamente con ISO 27001: i requisiti di monitoraggio e misurazione del capitolo 9 di ISO 27001 trovano in ISO 27004 le istruzioni operative. I circa 35 esempi pratici contenuti nella norma coprono misure di implementazione, efficacia, efficienza e impatto.

ACN e Strategia Nazionale di Cybersicurezza: la Strategia Nazionale include un manuale con 261 indicatori suddivisi in 82 misure per valutare la maturità nazionale. La misura n. 82 riguarda specificamente la definizione di metriche e KPI. Il Manuale Operativo ACN introduce tre livelli di affidabilità degli indicatori (alta, media, bassa) e prevede l’introduzione di target numerici a partire dal 2023. Per le organizzazioni italiane, questo framework nazionale è il riferimento istituzionale diretto.

NIST Cybersecurity Framework: fornisce la struttura funzionale (Identificare, Proteggere, Rilevare, Rispondere, Recuperare) su cui mappare le metriche. Il glossario NIST definisce la «security posture» come lo stato complessivo di prontezza e capacità di risposta di un’organizzazione, concetto direttamente misurabile attraverso le metriche descritte in questo articolo.

Per approfondire l’implementazione pratica, i passi per la certificazione ISO 27001 illustrano come integrare il sistema di metriche nel ciclo di vita dell’ISMS.

Punti chiave

Le metriche di sicurezza sono strumenti di governo, non solo di monitoraggio: senza attributi rigorosi, owner definiti e automazione nella raccolta, producono dati che nessuno usa per decidere.

Misurare per governare, non per rassicurare

C’è una tensione reale nei programmi di metriche di sicurezza che raramente viene discussa apertamente: la tentazione di scegliere metriche che fanno sembrare il programma più maturo di quanto sia. Un tasso di patching al 95% comunicato al board è rassicurante, ma se quel 5% non patchato include i sistemi più critici, il dato è tecnicamente corretto e operativamente fuorviante.

La vera utilità delle metriche emerge quando si accetta di misurare anche ciò che non va bene. MTTD elevato, ricorrenza delle vulnerabilità, basso completamento della formazione: questi dati scomodi sono esattamente quelli che giustificano investimenti e cambiamenti organizzativi. Un programma di metriche che produce solo buone notizie non sta misurando la realtà; sta costruendo una narrativa.

Per le PMI, il rischio opposto è altrettanto concreto: misurare troppo, senza priorità, e finire con cruscotti pieni di dati che nessuno interpreta. La scelta di tre o cinque metriche davvero azionabili, collegate a obiettivi di business dichiarati, vale più di un catalogo di venti indicatori aggiornati con fatica ogni mese. ISO 27004 e le linee guida ACN convergono su questo punto: la qualità del sistema di misurazione dipende dalla chiarezza degli obiettivi, non dalla quantità degli indicatori.

Securityhub affianca le organizzazioni nella definizione di metriche conformi a ISO 27001

Per chi deve strutturare un programma di metriche di sicurezza in linea con ISO 27001 e ISO 27004, il punto critico non è la teoria, ma la traduzione operativa: quali metriche scegliere, come automatizzarne la raccolta, come presentarle in un audit. Securityhub lavora con PMI e organizzazioni mid-market italiane per definire KPI verificabili, integrare le fonti dati esistenti (SIEM, EDR, ticketing) in un cruscotto coerente e preparare la documentazione richiesta per la certificazione.

Il percorso tipico parte da un assessment dello stato attuale, prosegue con la selezione delle metriche prioritarie e la configurazione degli strumenti, e si conclude con la produzione dei report per il management e per l’ente di certificazione. Per chi è già in fase di implementazione ISMS, la guida alla certificazione ISO 27001 illustra come integrare il sistema di metriche nel ciclo di audit. Per iniziare, contattate Securityhub per un assessment preliminare senza impegno.

Fonti utili e letture consigliate

Riferimenti istituzionali e normativi:

• ACN: Monitoraggio della strategia di Cybersecurity Governance (Metriche e KPI): definizioni operative, attributi delle metriche e distinzione metriche/KPI.
• ACN: Strategia Nazionale di Cybersicurezza, Manuale con indicatori di misurazione: 261 indicatori suddivisi in 82 misure, con livelli di affidabilità e target.
• ISO 27004: Information security management — Monitoring, measurement, analysis and evaluation: norma di riferimento per il ciclo di misurazione dell’ISMS, con circa 35 esempi pratici.
• NIST: Glossario security posture: definizione ufficiale di postura di sicurezza come base per le metriche di impatto.

Approfondimenti tecnici e operativi:

1. SentinelOne: Metriche e KPI di sicurezza informatica: panoramica operativa delle metriche più usate in ambienti enterprise.
2. Cesare Gallotti: ISO 27004:2016 sulle misurazioni: analisi critica della norma con raccomandazioni pratiche su cosa misurare e cosa evitare.
3. Ethercom: Guida pratica su hardening e monitoraggio sistemi IT: esempi tecnici su raccolta dati e integrazione con strumenti di sicurezza.

Risorse interne Securityhub per l’implementazione:

• Ruolo delle metriche di sicurezza: guida pratica: selezione e validazione delle metriche per contesti professionali.
• Assessment sicurezza ISO 27001: strutturare la fase di baseline prima di definire i target.
• Elenco misure di sicurezza ISO 27001:2022: catalogo delle misure tecniche e organizzative mappabili a metriche e KPI.

Raccomandati

• Ruolo delle metriche di sicurezza: guida pratica 2026 – Security Hub
• Misure di sicurezza ISO: guida pratica per PMI e certificazione – Security Hub
• Esempi di misure di sicurezza per PMI: guida 2026 – Security Hub
• Cos’è la valutazione della sicurezza: guida pratica IT – Security Hub