Dal mito alla realtà

Una nuova legge sulla sicurezza informatica spaventa la Thailandia

La richiesta di dati sulla cybersecurity da parte dei consigli di amministrazione e del top management è il segnale che la sicurezza informatica non è più solo un problema IT

I membri del consiglio di amministrazione e i direttori di funzione di un’impresa o di una grande organizzazione sono abituati a confrontarsi con numeri e sintesi, quindi una naturale conseguenza è trasformare i concetti di cybersecurity in una forma “assimilabile” e “trasmissibile”.

TI PIACE QUESTO ARTICOLO?

Iscriviti alla nostra newsletter per essere sempre aggiornato.

La strategia di impresa si ritrova quindi a “fare i conti” con i concetti di cybersecurity. Una classica banca online o una startup finanziaria online hanno il proprio core business ormai indissolubilmente radicato nella tecnologia. La massima espressione della security governance (dove per security governance si intende l’interesse/responsabilità di board of directors e top management per la cybersecurity) può diventare quindi una “CyberSecurity Dashboard” (CSD), in altre parole un sistema per misurare la cybersecurity. Ecco una panoramica basata su esperienze reali nell’applicare questi concetti.

PERCHÉ, COME, COSA

Simon Sinek ha scritto “Start With Why”. Lasciando al lettore l’opportunità di approfondire il pensiero di Simon Sinek, si procederà ora ad applicarlo al contesto della CSD illustrando:

  1. Perché esiste: qual è lo scopo della CSD.
  2. Come costruirla: come ottenere i primi risultati.
  3. Cosa si ottiene: qual è il risultato finale, dopo aver percorso i punti 1 e 2.

PERCHÉ ESISTE

La CSD può nascere per diverse ragioni più o meno attinenti alla realtà quotidiana della cybersecurity. Può essere richiesta da requisiti di audit oppure può essere una scelta del management.

In entrambi i casi, solo dopo avere il primo prototipo si può capire il perché serve. Si parte con un’idea di ottenere KPI o grafici di molteplici forme che descrivono i requisiti di sicurezza principali, ma il punto di arrivo, appena si ha un prototipo, è ben diverso. La CSD esiste perché consente di comprendere cose nuove, semplici ma molto spesso nascoste dall’operatività quotidiana, come ad esempio:

  1. Lato tecnologico: come è possibile che nel perimetro di applicazione dell’antivirus non si siano inseriti alcuni sistemi?
  2. Lato organizzativo: come è possibile che il tempo medio di remediation per le vulnerabilità stia crescendo anno dopo anno?
Leggi anche:  Akamai fornisce un connettore nativo per l'analisi del traffico delle API

Sovente si è impegnati in sforzi di compliance verso normative, per esempio quelle sulla privacy, o nella gestione dei requisiti di sicurezza richiesti dal management, magari trascurando alcuni aspetti semplici ma fondamentali.

COME COSTRUIRLA

L’approccio deve essere semplice, rapido e conclusivo. Evitare “castelli nel deserto” deve essere un imperativo in ogni fase del progetto:

  1. Non focalizzarsi solo su quale tecnologia usare o comprare. Possono andare bene i tool di business intelligence presenti in azienda dove peraltro già si trovano dati interessanti da correlare.
  2. Affidarsi a una struttura logica consolidata e diffusa come “armadio dei KPI” senza reinventarsi la ruota, partendo ad esempio dalla ISO/IEC 27001 o la PCI-DSS.
  3. Ideare KPI che esprimono rischi e sono fattibili da realizzare; KPI che non esprimono rischi o richiedono un lavoro tecnico ampio non sono probabilmente lo starting point migliore.
  4. Creare un ritmo costante per sviluppare la CSD facilitando i rapporti fra chi possiede gli input e chi crea il software. Ritardi? Non ammetterli dall’inizio è un semplice principio, da seguire.

Ne consegue il monitoraggio dei KPI, inserendoli in un processo disciplinato di planning&control, come si usa fare nel controllo di gestione. Lo scopo ultimo del monitoraggio è usare le leve a disposizione per migliorare i KPI, non il monitoraggio fine a se stesso.

COSA SI OTTIENE

La risposta che tutti si aspettano è un ennesimo “tool di analytics” più o meno frequentemente guardato dai diversi stakeholder coinvolti. Può essere una prospettiva. Non sbagliata, ma non completa. Se il lavoro viene svolto accuratamente, durante il percorso e sino all’arrivo, la deliverable principale che si ottiene è intangibile quanto utile: “la consapevolezza” che misurando la governance della security bisogna fare muovere i valori dei KPI, giorno dopo giorno.

Leggi anche:  Direttiva NIS2 e organizzazioni italiane: le risposte di Sangfor Technologies

CONCLUSIONI

Questo scritto si è posto l’obiettivo implicito di creare curiosità nei lettori al fine di chiedersi se si sta misurando in modo esaustivo e con chiarezza lo stato della propria cybersecurity. Meglio essere consapevoli dei propri numeri e allenarsi a migliorarli che trovarsi a rispondere del proprio operato, in modo qualitativo, al board of directors. Se una visione quantitativa della cybersecurity vi suscita interesse saremo entusiasti di rispondere alle vostre domande o di condividere schemi di Cybersecurity Dashboard basati sull’esperienza maturata negli anni.

Thomas Castagna docente e Fabio Guasconi membro del direttivo di CLUSIT