Contenuto informativo basato su fonti istituzionali. L’applicazione concreta richiede una valutazione del contesto, del rischio e della normativa vigente.
Scrivere scenari comprensibili
NIST IR 8286 Rev. 1 collega il cybersecurity risk register alla gestione del rischio d’impresa. Il rischio deve poter essere compreso anche fuori dall’IT: causa o minaccia, evento, asset o servizio coinvolto e conseguenza sugli obiettivi.
Formule come “rischio ransomware alto” non bastano. È più utile descrivere lo scenario: credenziali privilegiate compromesse consentono cifratura dei sistemi e indisponibilità del servizio oltre il tempo tollerabile. Le evidenze tecniche rimangono collegate, senza trasformare il registro in un vulnerability report.
- Identificativo e scenario di rischio
- Servizio, processo, dati e asset coinvolti
- Minaccia, vulnerabilità o condizione causale
- Conseguenze operative, economiche e normative
- Fonti ed evidenze della valutazione
Stimare rischio inerente e residuo
NIST IR 8286A Rev. 1 approfondisce identificazione, stima, appetito e tolleranza al rischio. Scale e criteri devono essere definiti prima della valutazione e applicati con coerenza; numeri molto precisi non compensano dati incerti.
Il rischio inerente rappresenta lo scenario prima dei controlli considerati; quello residuo tiene conto dell’efficacia osservata. Certificazioni, policy o prodotti sono input, ma l’efficacia richiede prove: configurazioni, test, log, incidenti, audit e copertura reale.
- Probabilità e impatto con criteri dichiarati
- Controlli esistenti ed evidenza di efficacia
- Rischio inerente e rischio residuo
- Incertezza, assunzioni e dipendenze
- Confronto con appetito e tolleranza
Trasformare il registro in decisioni
Per ogni rischio occorre una risposta: mitigare, evitare, trasferire o accettare, secondo il modello adottato. Azioni, proprietario, risorse e scadenze devono essere separate dalla descrizione del rischio e aggiornate quando cambia lo stato.
Il registro viene riesaminato periodicamente e quando si verificano incidenti, nuove vulnerabilità sfruttate, cambi di fornitore, servizi o esposizione. I rischi più rilevanti possono essere aggregati nel profilo aziendale, mantenendo il collegamento con i dettagli tecnici.
- Decisione e livello autorizzativo
- Piano di trattamento con priorità
- Risk owner e action owner distinti
- Scadenza ed eventi di riesame
- Stato, rischio residuo atteso e chiusura verificata
Domande frequenti
Il registro dei rischi sostituisce il vulnerability register?+
No. Una vulnerabilità è una possibile causa o evidenza; il rischio descrive uno scenario e il suo impatto sugli obiettivi. I due registri devono essere collegati quando pertinente.
Serve assegnare un proprietario a ogni rischio?+
Sì. Il risk owner deve avere autorità per comprendere e decidere il trattamento; il responsabile delle singole azioni può essere diverso.
Con quale frequenza va aggiornato?+
Secondo criticità e cambiamento, con un riesame programmato e aggiornamenti anticipati in presenza di eventi significativi, incidenti o variazioni del contesto.