La modernità ama i numeri. Li produce con una facilità quasi liturgica. Dashboard illuminate, grafici colorati, percentuali che scorrono sugli schermi dei Security Operation Center come il battito cardiaco di un organismo tecnologico globale. In ogni organizzazione contemporanea la sicurezza informatica è raccontata attraverso numeri. Vulnerabilità aperte, patch installate, incidenti rilevati, accessi revocati. Una grammatica numerica che promette controllo.
Ma la promessa del numero è spesso più fragile di quanto sembri.
La storia della misurazione, in fondo, è la storia della civiltà . Quando nel XVII secolo gli Stati europei iniziarono a censire la popolazione e a calcolare la ricchezza delle nazioni, nacque la statistica moderna. La parola stessa deriva dal latino status, lo stato delle cose. Michel Foucault osservava che il potere moderno si esercita attraverso la conoscenza numerica delle società . Contare significa governare. Ma soltanto quando il numero genera decisione.
La cybersicurezza del XXI secolo vive una tensione simile. Le organizzazioni misurano tutto, ma raramente governano attraverso ciò che misurano.
Un numero può descrivere. Più raramente può comandare.
La differenza è sottile ma radicale.
In molte aziende i report di sicurezza si presentano come un atlante statistico della vulnerabilità . Percentuali di patch installate entro quattordici giorni, percentuali di backup completati con successo, percentuali di utenti rimossi dai sistemi dopo l’uscita dall’organizzazione. Numeri precisi, spesso eleganti. Ma sospesi.
Il problema non è il numero. Il problema è ciò che accade quando il numero cambia.
Nella maggior parte delle organizzazioni non accade nulla.
Questo fenomeno non appartiene soltanto alla sicurezza informatica. È una costante della burocrazia contemporanea. Nel 1968 lo storico del management Laurence J. Peter formulò il celebre principio secondo cui le strutture gerarchiche tendono a promuovere l’incompetenza sistemica. In ambito organizzativo moderno potremmo parafrasarlo in un’altra forma. Le organizzazioni tendono a produrre metriche che non obbligano nessuno a decidere.
Il risultato è una forma di simulazione del controllo.
Un indicatore di performance senza una soglia operativa è soltanto statistica. Una soglia senza conseguenze è retorica amministrativa.
La sicurezza informatica vive spesso in questo spazio ambiguo. Gli indicatori vengono presentati nei comitati di governance, scorrono nelle slide dei board meeting, vengono archiviati nei report trimestrali. Ma quando il valore scende sotto l’obiettivo dichiarato, l’organizzazione non reagisce. Si limita a registrare la deviazione.
Con il tempo, la deviazione diventa abitudine.
Il KPI continua a esistere, ma ha perso la sua funzione disciplinante. È diventato un elemento decorativo dell’apparato di controllo.
Questo paradosso è particolarmente visibile nel vulnerability management. Una delle attività più classiche della sicurezza informatica consiste nel monitorare le vulnerabilità dei sistemi e chiuderle entro un determinato tempo. Molte organizzazioni stabiliscono obiettivi ambiziosi, ad esempio la chiusura del novantacinque per cento delle vulnerabilità critiche entro quattordici giorni.
Il numero appare rassicurante.
Ma raramente viene posta la domanda fondamentale. Cosa succede quando il risultato reale scende all’ottantuno per cento.
Per comprendere la differenza tra osservazione e governo, immaginiamo un’organizzazione con i seguenti dati trimestrali.
Nel periodo considerato sono state identificate centottanta vulnerabilità critiche. Di queste, centoquarantasei sono state chiuse entro lo SLA previsto di quattordici giorni, mentre trentaquattro sono rimaste aperte oltre il limite.
Il risultato è una percentuale di chiusura pari all’81%.
Il target dichiarato dall’organizzazione è ≥95%.
La deviazione è quindi pari a –14%.
Nella maggior parte delle strutture aziendali questo dato verrebbe semplicemente registrato. Inserito in un grafico. Commentato in una riunione. Poi dimenticato.
In un sistema realmente governato, invece, il numero attiva un meccanismo.
Perché una metrica diventi uno strumento di governo è necessario introdurre una soglia operativa. La soglia non è un dettaglio statistico. È la traduzione numerica della tolleranza al rischio.
Se definiamo tre zone operative, verde ≥95%, giallo tra 90% e 94%, rosso <90%, il valore osservato dell’81% entra immediatamente nella zona rossa.
Questo passaggio modifica la natura del numero.
Non è più una fotografia del passato. Diventa un segnale operativo.
La soglia attiva escalation. Non un dibattito, ma una procedura. La zona gialla può generare una notifica al responsabile del controllo con l’obbligo di produrre un piano correttivo. La zona rossa può attivare una revisione del backlog di vulnerabilità , una riallocazione di risorse tecniche, un intervento diretto del CIO.
Il dato smette di essere informazione. Diventa decisione.
Se analizziamo lo stesso scenario in termini di esposizione cumulativa al rischio, emerge un’altra dimensione numerica spesso ignorata. Le trentaquattro vulnerabilità chiuse oltre lo SLA sono rimaste aperte in media ventuno giorni oltre la soglia prevista.
Questo significa che l’organizzazione ha accumulato settecentoquattordici giorni di esposizione oltre il limite accettabile.
Il numero cambia prospettiva. Non stiamo più parlando di trentaquattro anomalie statistiche. Stiamo parlando di quasi due anni di esposizione cumulativa.
La sicurezza informatica inizia a diventare una questione economica.
Lo stesso ragionamento può essere applicato al controllo degli accessi. Supponiamo che in un trimestre sessantadue dipendenti abbiano lasciato l’organizzazione. Cinquanta account sono stati revocati entro ventiquattro ore, mentre dodici sono rimasti attivi oltre il limite.
La percentuale di conformità è pari all’80,6%.
Il target dichiarato è 100%.
La deviazione è –19,4%.
In un sistema senza escalation questo valore diventa una tolleranza implicita. Il processo HR-IT continua a funzionare come prima. Gli account rimangono attivi per giorni o settimane. L’organizzazione registra il dato ma non modifica il comportamento.
Quando invece la soglia è collegata a una revisione automatica del processo, la metrica diventa uno strumento di miglioramento. Può attivare un audit sull’integrazione tra sistemi HR e IAM, una revisione dei flussi di offboarding, oppure un intervento tecnologico sull’automazione delle revoche.
La matematica della soglia è sorprendentemente semplice.
Una soglia operativa efficace può essere formalizzata come la differenza tra l’obiettivo dichiarato e la deviazione tollerabile.
Se l’obiettivo di chiusura delle vulnerabilità è 95% e la deviazione tollerabile è 3%, la soglia rossa diventa 92%.
Qualsiasi valore inferiore a 92% genera escalation automatica.
Senza questa formalizzazione, la soglia rimane interpretativa. Dipende dall’umore del meeting, dalla pressione del budget, dalla capacità retorica dei responsabili.
Ma la vera domanda riguarda la reattività complessiva dell’organizzazione.
Possiamo definire un indicatore sintetico, una sorta di indice di reattività organizzativa, che misura quante metriche generano effettivamente decisioni operative.
Immaginiamo un sistema con venticinque controlli di sicurezza. Diciotto hanno una metrica primaria definita. Dodici possiedono una soglia formale. Sette sono collegati a un meccanismo automatico di escalation. Solo quattro producono decisioni operative tracciate.
Il calcolo diventa:
Indice di reattività ≈ (metriche con soglia × soglie con escalation × escalation con decisione)
(18/25) × (12/18) × (4/12)
≈ 0,72 × 0,66 × 0,33
≈ 0,16
Il risultato è circa il 16%.
In altre parole, soltanto il sedici per cento dei controlli di sicurezza produce una reazione completa.
Il resto è osservazione.
La cybersicurezza contemporanea rischia quindi di trasformarsi in una gigantesca macchina di osservazione statistica. Produce numeri con straordinaria precisione, ma spesso non riesce a trasformarli in decisioni.
La tecnologia ha perfezionato la capacità di misurare. La governance deve ancora imparare a reagire.
Alla fine la differenza tra sicurezza reale e sicurezza apparente è sorprendentemente semplice.
La sicurezza non migliora osservando numeri. Migliora reagendo ai numeri.
La metrica primaria è il battito del controllo.
La soglia è la linea che separa stabilità e rischio.
L’escalation è il meccanismo che trasforma il dato in decisione.
Senza escalation, la metrica rimane un grafico.
E i grafici non proteggono nessuno.
Raffaele Di Marzio
Executive Cybersecurity Consultant
raffaele.dimarzio@cyberium.limited
Sull’autore / À propos de l’auteur :
🇮🇹 https://www.amazon.it/stores/Raffaele-DI-MARZIO/author/B0FB47T6Q4
🇫🇷 https://www.amazon.fr/stores/Raffaele-DI-MARZIO/author/B0FB47T6Q4
📘 Metodo completo nel libro / Méthode complète dans le livre :
🇮🇹 https://www.amazon.it/dp/B0F5WV9WMF
🇫🇷 https://www.amazon.fr/dp/B0FMJQ4FFM