Ora che la security ha ottenuto l’attenzione da parte del top management, i responsabili IT e i CISO (Chief Information Security Officer) devono imparare a tradurre un programma per la sicurezza delle informazioni in termini che il business è in grado di comprendere.
La prima regola? Focalizzarsi sui risultati, non sui dettagli. “Non raccontate più al top management ciò che sta accadendo nell’ambito della sicurezza“, ha spiegato l’analista di Gartner, Paul Proctor.
Invece di dire quanti incidenti si sono verificati in azienda nell’ultimo anno, i professionisti della sicurezza dovrebbero concentrarsi sul modo in cui hanno gestito tali incidenti. “Quanto valido è il vostro programma? Questo è l’aspetto più rilevante” ha detto Proctor.
Usare gli indicatori di performance e gli indicatori di rischio principali
Le organizzazioni tendono a misurare il rischio della sicurezza individuando le cose che potrebbero andare storte e assegnando un valore monetario agli eventuali danni. Ma questo approccio non considera tutti i modi in cui le cose possono andare male, ha sottolineato Proctor.
Un professionista della sicurezza può dar vita a un convincente business case per un programma di information security, ha spiegato Proctor, collegando di indicatori chiave di performance (KPI dell’organizzazione) con gli indicatori chiave di rischio (KRI).
I KPI – come l’indice di fidelizzazione dei clienti, il time to market o il delivery ontime dei fornitori – sono utilizzati per misurare la salute del business di un’impresa, fornendo una dettagliata visione, per esempio, di come viene gestita la supply chain o quanto stia operando bene la forza vendita.
Quello di cui necessità il business, ha detto Proctor, sono degli indicatori che sappiano anticipare il rischio. E i programmi di sicurezza che mappano i KPI tradurranno i corrispondenti requisiti di sicurezza in un linguaggio comprensibile al business. Una supply chain “lenta” è un indicatore importante che indica che una società potrebbe non raggiungere gli obiettivi previsti per il trimestre.
Uno scarso sistema di patching, che ancora oggi rappresenta un diffuso problema di sicurezza, è un indicatore in grado di anticipare il rischio derivante da una supply chain capace di rallentare l’attività e quindi impedire al business di raggiungere i numeri preventivati. “Non perdete l’occasione di mostrare al management perché state facendo delle cose che sono di suo interesse“, ha detto Proctor.
I KPI variano in funzione del business. Proctor ha raccomandato che i team di sicurezza creino il proprio set di KPI individuando i processi di business critici e supportando le applicazioni. I KPI non dovrebbero essere IT-centrici, perché questa visione tende a rafforzare l’idea che ha il business (e che continua a tormentare i team di security): e cioè, che la sicurezza è un problema dell’IT e, pertanto, va risolto all’interno della stessa IT.
La sicurezza, naturalmente, dovrà creare un set di indicatori chiave di rischio, suffragati dagli innumerevoli dati che raccoglie un team di information security.
Il compito della mappatura è di mostrare come i KRI si connettono ai KPI e li possano cambiare. Proctor ha raccomandato che il team di sicurezza misuri continuamente i KRI nel contesto dei KPI e che comunichi le proprie conclusioni al business, anche se non è stata espressamente richiesta questa analisi. Nel tempo, ha previsto Proctor, i report diventeranno una caratteristica standard nella valutazione del rischio all’interno dell’organizzazione.
Non utilizzate il ROI e parlate il linguaggio dei business manager
I professionisti della sicurezza devono disporre di metriche operative che li aiutino a fare un lavoro migliore, ma Proctor ha affermato che queste metriche non devono essere usate nelle comunicazioni con i dirigenti. “Non perdete tempo“, ha consigliato. Invece, è necessario che la security “crei un layer di astrazione” quando parlate di sicurezza al business.
Ciò significa, per esempio, che non è il caso di non citare il ritorno sugli investimenti in sicurezza perché quando il business sente nominare il ROI pensa immediatamente ai soldi, non alla tranquillità del business. Utilizzate invece termini tipici dei report, come business value. “Usate le loro parole, perché sono stati loro a scrivere queste parole“, ha detto Proctor.
Mappate le iniziative di sicurezza all’interno delle iniziative aziendali; ricavate una formulazione e un linguaggio specifici attingendo dalle voci presenti nel più recente piano strategico e inseriteli nel vostro piano di sicurezza.
Uno schema dei processi di security
Un altro strato di astrazione consiste nel mostrare al business come vengono condotte oggi le operazioni di sicurezza e come invece dovrebbero essere. Proctor ha raccomandato ai responsabili della sicurezza di dar vita a un catalogo che elenchi le decine di processi ad alto livello che rappresentano il programma di information security e quindi di valutare la qualità del livello in cui tali processi operano.
Lo schema da mostrare al business dovrebbe rappresentare, in maniera astratta e con colori con un alto impatto visivo, lo stato attuale di tali processi, lo stato rispetto al target, il risanamento previsto e il periodo di tempo necessario a migliorare tali processi.
Comunicate al top management cosa funziona e cosa no. I responsabili della sicurezza dovrebbero avere in tasca i parametri per queste operazioni – “ma non forniteglieli se non ve li chiedono”, ha detto Proctor.
Un programma formale di rischio
Naturalmente, tutto quanto sopra presuppone di avere un programma formale di rischio. E questo è di grande aiuto quando il venerdì arriva una telefonata in cui viene richiesto al responsabile di information security di preparare per il lunedì successivo una presentazione che in una ventina di minuti illustri al top management una panoramica sul programma per la sicurezza delle informazioni e le relative policy.
Le caratteristiche di un programma di formale di rischio e per la sicurezza sono la responsabilità, la trasparenza e la misurabilità, ha detto Proctor.
Tale programma dovrebbe stabilire:
- chi è responsabile di cosa in materia di sicurezza
- fornire visibilità sui processi core
- offrire una base di partenza per il continuo miglioramento
Il programma dovrebbe poi comprendere anche una struttura formale di governo, ha concluso Proctor, in modo che sia chiaro il modo in cui vengono prese le decisioni di sicurezza.
