La definizione di politiche di sicurezza e la gestione del rischio cyber rappresentano oggi due capisaldi indispensabili per qualunque organizzazione soggetta a obblighi normativi in materia di dati e di resilienza digitale.
Tali attività, se ben integrate coi processi aziendali, non solo rispondono alle richieste regolatorie, ma contribuiscono in modo sostanziale alla governance dell’impresa, alla sua crescita, e alla protezione del suo valore nel tempo. Eppure, resta ben radicato il pregiudizio che l’impegno richiesto non sia ripagato, e che anzi possa portare a ostacoli o spese inutili.
Così, mentre in tema NIS, i più staranno terminando la risoluzione degli obblighi di natura più “burocratica” verso l’ACN, prendiamo invece spunto dalle linee guida ENISA sull’attuazione della Direttiva NIS2, per sviluppare qualche riflessione sulle buone prassi in materia di politiche di sicurezza e su come rendere efficace l’attività di valutazione dei rischi.
[ved. anche NIS 2: Tutto quello che serve sapere (e fare) entro il 31 maggio – scadenza prorogata al 31 luglio]
Indice
La politica di sicurezza come strumento di governance
Una prima ovvietà, utile ribadirla, è che all’interno di qualsiasi organizzazione, le politiche di sicurezza non dovrebbero mai ridursi a un documento statico, redatto unicamente per soddisfare un adempimento formale. Limitarsi a questo, è il primo passo per togliervi credibilità e valore. In un certo senso, “forzare” il passaggio delle valutazioni sulla cybersecurity per i tavoli dei vertici aziendali, è uno dei modi con cui la NIS2 tenta di guidarci affinché le politiche di sicurezza informatica siano finalmente viste come reali linee di indirizzo strategiche.
Per chi guarda all’efficacia e intende assumere un approccio proattivo, è comunque fondamentale fare propria questa visione: se ben realizzato, un “documento quadro” sulle politiche di sicurezza (che copra tutti i sistemi, gli asset e le procedure) consente di definire priorità, responsabilità, metodi e criteri. Permetterà di dimostrare consapevolezza del proprio contesto e prontezza nel reagire ai cambiamenti – normativi e tecnologici. Porrà le basi per essere in grado di identificare le proprie lacune e concretizzare l’ambìto continuous improvement.
Come documentare il coinvolgimento dei vertici nelle politiche di sicurezza? Atti formali di approvazione, tracciabilità di log e revisioni, note di aggiornamento sono alcuni esempi. Ma l’attività può essere valorizzata anche da segnali più dinamici: richieste scritte di applicare quanto previsto, interventi in sede di audit, allocazione di risorse finalizzate ad attuare specifiche misure.
Dar vita alle politiche di sicurezza: dalla visione all’attuazione
Mancanza di tempo, risorse o competenze specifiche, rischiano di portare a definire politiche di sicurezza informatica generiche, non calate nella realtà aziendale od obsolete. Talvolta, qualche documento esiste ma nessuno lo conosce o lo controlla. Nel peggiore dei casi, contiene prescrizioni rigide e non applicate, che espongono l’organizzazione a un rischio ancora maggiore di non conformità. Come rendere allora questi documenti vivi, accessibili e utili?
- Essere realistici e partire dal proprio contesto. La policy deve avere senso per chi la applica, ed è inutile mutuare modelli troppo complessi o costruiti su standard irraggiungibili. D’altra parte, i requisiti della NIS2 rappresentano un livello minimo di contenuti (es. ruoli interni, gestione della catena di approvvigionamento, business continuity, consapevolezza del personale, ecc.) di cui è bene tenere conto per una politica di sicurezza. Forse non tutti i punti saranno o sembreranno sempre pertinenti in qualsiasi contesto, ma partire da quello scheletro è probabilmente il modo migliore per sviluppare ogni altra riflessione più specifica.
- Presidiare il processo di aggiornamento. Nessun documento è utile se non si sa chi debba aggiornarlo, quando e in base a cosa. Su questo fronte, è importante cercare soluzioni per coniugare due esigenze apparentemente opposte: da un lato, legare il riesame a eventi reali (incidenti, cambiamenti organizzativi, audit), secondo una logica dinamica e adattiva; dall’altro, prevedere revisioni formali periodiche che garantiscano un controllo sistematico anche in assenza di eventi scatenanti. In entrambi i casi, gli aggiornamenti andrebbero documentati, anche solo con un registro delle modifiche o una nota interna.
- Migliorare la comunicazione. Come spesso accade, la comunicazione è un elemento critico: una policy efficace ha l’effetto desiderato sui suoi destinatari. L’ENISA ricorda che l’obiettivo non è che tutti conoscano ogni dettaglio di ogni documento aziendale, bensì che i ruoli identificati comprendano cosa ci si aspetta da loro. Diventa quindi decisivo comprendere le differenze tra politiche (strategiche), procedure (organizzative) e istruzioni (operative). In modo da riuscire ad adattarne efficacemente metodi di gestione, comunicazione e trasmissione. Analogamente, sarà decisiva la coerenza tra i processi, assicurandosi che anche altri moduli, contratti e documenti aziendali siano coerenti con la politica di sicurezza stessa (es. attraverso clausole nei contratti coi fornitori, sottoscrizione di vincoli di adesione ai regolamenti aziendali da parte dei dipendenti, ecc.).
Ruoli e responsabilità nella sicurezza informatica
Chiarezza organizzativa e segregazione dei compiti sono i pilastri di ogni sistema di gestione efficace. Eppure, quando si parla di sicurezza informatica, in molte realtà permane una cultura organizzativa in cui tutto ricade sull’IT o dove le responsabilità restano ad un livello implicito, senza che vi seguano reali assunzioni dell’incarico.
Adottare semplici matrici di ruoli è un primo modo, semplice e concreto, per chiarire chi fa cosa, su quali sistemi e con quale grado di autonomia. Specie se si decide di integrare i ruoli per la sicurezza nell’organigramma aziendale e formalizzare l’assegnazione. Non parliamo unicamente o necessariamente delle persone formalmente individuate come Punti di Contatto NIS. In base alle caratteristiche dell’azienda, resta la libertà di decidere se attribuire compiti di sicurezza a ruoli dedicati o integrarli in altre mansioni già esistenti. Ci sono però alcuni aspetti importanti da considerare in tutti i contesti.
Innanzitutto, il fatto di poter disporre di una persona in grado di riferire direttamente agli organi di gestione sulla sicurezza delle reti e dei sistemi.
Altro punto fondamentale, forse più complicato, è il tentativo di prevenire conflitti di interesse, ad esempio assicurando che chi svolge controlli su un sistema non appartenga all’area oggetto del monitoraggio. In alcune situazioni, affidarsi a consulenti esterni e terze parti per supervisionare le attività di monitoraggio potrebbe ad esempio essere il modo migliore per garantire la necessaria indipendenza.
Infine, tutti devono sapere a chi rivolgersi e quando, soprattutto in caso di incidente. Quando si parla di business continuity si tende a pensare soprattutto a sistemi e tecnologie. Ma nella “continuità della governance”, le persone fanno (ancora!) la differenza. Non si sottovaluti, quindi, l’importanza di designare i rilevanti sostituti, se non altro per i ruoli chiave.
Nei contesti meno strutturati, una mappatura iniziale dei pochi ruoli chiave può già costituire una base solida da cui partire con un’evoluzione graduale. Evoluzione, peraltro, assolutamente coerente con l’esigenza di rivedere, riesaminare e aggiornare periodicamente le responsabilità. Attività questa da svolgere, si ricorda, basandosi sempre su formazione, esperienza e qualifiche adeguate delle persone individuate.
[Per un approfondimento sui ruoli della cybersecurity, scopri anche i profili descritti da ENISA]
Gestione del rischio cyber: oltre l’adempimento formale
Ripetiamo l’ovvietà anche per il processo di risk-management: non si tratta di una mera formalità né di realizzare documenti da mostrare in sede di audit. Per rendere utile il processo e strutturare concretamente la gestione dei rischi informatici, proviamo allora a individuare qualche indicazione pratica. Le linee guida ENISA non rivoluzionano quanto già previsto da altri framework e standard consolidati, ma nella guida all’implementazione della NIS si trovano alcuni spunti particolarmente interessanti, ad esempio:
- l’invito ad associare ciascun rischio identificato a specifici asset, assicurandosi che vi siano abbinate delle misure di mitigazione, i responsabili e le scadenze operative;
- modalità chiare per definire la propria tolleranza al rischio, esplicitando i tempi massimi di interruzione del servizio, il massimo impatto economico sostenibile, la disponibilità a investire in sicurezza una certa percentuale del proprio fatturato;
- soluzioni su come definire anticipatamente i propri criteri di accettazione dei rischi, tra cui l’individuazione a priori di casistiche particolari (es. la possibilità di accettare vulnerabilità di sistemi non critici) o elementi misurabili (come il rapporto tra costo di mitigazione e impatto potenziale del rischio) su cui orientare le scelte.
Qualsiasi approccio venga scelto, alcuni principi guida appaiono ricorrenti.
Primo tra tutti, l’importanza di documentare, attentamente e formalmente, attività e scelte in materia di sicurezza. Ad esempio, quando si stabilisca di accettare un determinato rischio senza investire in nuove misure di sicurezza, o di posticipare l’implementazione di una misura tecnica, o di preferire un’opzione migliorativa rispetto a un’alternativa equivalente. L’ideale è che ogni decisione possa essere spiegata e tracciata. A ricordarci che accountability non è fare tutto alla perfezione, bensì poter dimostrare in modo ragionato ciò che è stato fatto.
E, ancora una volta, l’attenzione al contesto: una stessa tecnologia può essere irrilevante in una realtà e critica in un’altra. La consapevolezza delle proprie reali necessità rappresenta un vantaggio concreto, perché consente di ottimizzare le risorse. Non tutti i rischi richiedono investimenti onerosi o misure complesse. Al contrario, in certi casi, sarà sufficiente e ragionevole un’accettazione consapevole, purché documentata.
Verso un sistema di risk-management integrato
Politiche di sicurezza, gestione dei rischi, definizione dei ruoli e responsabilità non sono elementi isolati, ma parti integranti (e integrabili!) di un unico sistema di governance dei rischi. Un sistema ben progettato di questo tipo può essere esteso anche oltre l’ambito della cybersecurity. Infatti, è adatto a essere replicato per far fronte alle richieste non solo della Direttiva NIS2, ma anche di tutte le altre normative settoriali che condividono la logica del risk-based approach.
Si va dalla protezione dei dati personali (GDPR), alla regolazione dell’intelligenza artificiale (AI Act), dalla progettazione sicura di prodotti e servizi in contesti specifici (es. DORA per il panorama finanziario), ad altri strumenti regolatori in arrivo. Pur con declinazioni diverse, la posizione europea sembra trasversalmente chiedere alle imprese di basare le proprie strategie considerando i contesti operativi, tecnologici e umani. Cambiano le finalità – privacy, sicurezza dei sistemi, resilienza, affidabilità – ma non l’impianto logico di fondo.
La vera sfida, forse, sarà proprio questa: non tanto mitigare ogni singolo rischio, ma riuscire a costruire modelli organizzativi che consentano di gestire ogni forma di rischio in modo coerente, efficiente e continuativo.
