Un elenco di password deboli, software obsoleto e backup non verificati non spiega ancora che cosa potrebbe perdere l’azienda. La valutazione del rischio informatico collega questi elementi ai processi aziendali: vendite interrotte, documenti non disponibili, una fuga di dati o un pagamento errato. Alla direzione serve questo risultato per scegliere gli interventi e assegnare le risorse.
Una valutazione efficace produce un registro dei rischi, criteri concordati e un elenco di decisioni. Ogni voce deve avere un responsabile, input verificati, un’azione successiva e una data di revisione. Il processo descritto può essere applicato a un singolo servizio, un dipartimento o l’intera azienda.
Concordare finalità, ambito e partecipanti
Innanzitutto, definire la decisione a cui la valutazione deve contribuire. Ad esempio, valutare la prontezza per spostare i documenti dei clienti nel cloud o identificare i rischi per le operazioni di vendita affidabili. Specificare i sistemi, i dati, i siti e i fornitori interessati. Registrare separatamente le esclusioni e le dipendenze esterne. Un servizio escluso può comunque interrompere un processo incluso.
Assegnare un coordinatore di valutazione e i responsabili del processo. L’IT conferma la progettazione del sistema e lo stato di sicurezza. I dipendenti spiegano come avviene il lavoro e quali soluzioni alternative utilizzano già. Il responsabile del processo valuta le conseguenze e prende decisioni nell’ambito della propria autorità. Se un rischio supera tale autorità, identificare chi deve approvarlo. Un appaltatore può aiutare a raccogliere prove, ma non può sostituire il responsabile decisionale aziendale.
Scegliere un metodo di valutazione chiaro e documentarlo prima di compilare il registro. Le linee guida NIST aiutano a organizzare la preparazione, l’esecuzione e la manutenzione della valutazione. I requisiti del settore e i contratti possono aggiungere controlli e prove obbligatorie. Completare un modello da solo non dimostra che tutti i requisiti applicabili sono stati soddisfatti.
Raccogliere i fatti e descrivere gli scenari
Partire dai processi e dalle risorse collegate
Utilizzare l’inventario esistente di attrezzature, software e servizi. È sufficiente un identificatore di asset, lo scopo, il proprietario, i dati importanti e le connessioni ai processi aziendali per la valutazione. Aggiungere servizi esterni, dipendenti con privilegi speciali e operazioni manuali in cui il risultato dipende da essi. Non creare una copia parallela di ogni record di asset. Collegare invece a un record verificato invece di reinserirlo.
Confermare le informazioni attraverso diverse fonti: impostazioni, log, risultati di test tecnici, ticket, contratti e discussioni con i proprietari. Registrare la data e la fonte di ogni prova separatamente. Se le informazioni sui test di ripristino mancano, indicare “ripristino non verificato” anziché “nessun backup”. L’incertezza richiede un’indagine, non un fatto inventato.
Collegare minaccia, debolezza e conseguenze
Descrivere un rischio come un evento possibile con una causa e una conseguenza aziendale. “Phishing” è una descrizione troppo ampia. Un’entrata più utile indica che un attaccante utilizza credenziali rubate per accedere alla posta elettronica aziendale e sostituire i dettagli di pagamento. Questo identifica il processo, l’evento e il potenziale danno interessati. Un altro scenario prevede un errore di un amministratore: la cancellazione di una cartella condivisa causa interruzioni se il ripristino non funziona.
- Considerare attacchi esterni, errori degli impiegati, uso improprio degli accessi e errori di configurazione.
- Verificare le dipendenze da fornitori, servizi cloud, alimentazione e disponibilità del sito. Includerli quando influiscono sullo scenario di rischio informatico selezionato.
- Identificare le conseguenze per la disponibilità, l’integrità e la riservatezza dei dati. Quindi tradurle in operazioni interrotte, costi, obblighi e impatto sui clienti.
- Separare eventi con diversi proprietari o opzioni di trattamento. È possibile combinare la stessa vulnerabilità in diversi sistemi correlati, mantenendo l’elenco degli asset interessati.
Valutare i controlli esistenti sulla base di evidenze
Registrare cosa riduce già la probabilità dell’evento o la gravità delle sue conseguenze. Esempi includono l’autenticazione a più fattori, permessi limitati, aggiornamenti, formazione, segmentazione, log e backup testati. Il nome di un controllo è meno importante del suo ambito e delle prestazioni nello scenario richiesto. Una copia senza un test di ripristino di successo non dimostra che il servizio può essere ripristinato. L’installazione di una protezione non dimostra che funziona su tutti i dispositivi richiesti.
Registrare lo stato di ciascun controllo e le eventuali lacune riscontrate. L’articolo su controlli prioritari per le aziende soggette a regolamentazione spiega come implementare le prime misure di protezione. Utilizzare i risultati della verifica dei controlli nella scelta delle azioni di gestione del rischio.
Valutare probabilità e conseguenze con criteri coerenti
Tre livelli qualitativi possono fornire un punto di partenza. Concordare il periodo di valutazione e le caratteristiche di ciascun livello. Non presentare la parola “alto” come una percentuale calcolata. Se le prove sono limitate, registrare l’incertezza e un’azione per ridurla. Il responsabile del processo dovrebbe comprendere la valutazione, piuttosto che semplicemente trovare un diagramma colorato convincente.
|
Livello |
Probabilità nel periodo scelto |
Conseguenze per il processo scelto |
|---|---|---|
|
Basso |
Non sono note vie di accesso all’evento; i controlli limitati sono stati testati. L’incertezza rimanente viene registrata. |
Il lavoro prosegue attraverso una soluzione alternativa accettabile; l’impatto rimane entro i limiti concordati. |
|
Medio |
Lo scenario è realistico, ma dipende da ulteriori condizioni o è parzialmente limitato dai controlli. |
Sono necessari ulteriori risorse o un metodo di lavoro alternativo temporaneo; alcune operazioni sono interessate. |
|
Alto |
Esistono percorsi accessibili, eventi ripetuti o significative falle di sicurezza. |
Un’operazione critica si interrompe, potrebbero verificarsi perdite significative di dati o finanziarie, o il rispetto degli obblighi è minacciato. |
Questi criteri sono solo un esempio, non uno standard universale. L’azienda deve definire le proprie operazioni critiche e le perdite accettabili. Utilizzi i propri dati per importi finanziari, tempi di inattività e limiti contrattuali. Una matrice di probabilità e conseguenze aiuta a stabilire le priorità, ma valutazioni uguali non rendono due rischi identici. Tenere conto delle dipendenze, della scala e della fiducia nelle prove.
Distinguere rischio intrinseco, attuale e previsto
Se una decisione richiede un confronto, valuti lo scenario senza controlli di sicurezza e separatamente con i controlli che effettivamente funzionano. La seconda valutazione può essere definita come il rischio residuo attuale. Registri il rischio previsto dopo le modifiche pianificate separatamente: un piano non riduce la valutazione attuale. Dopo aver implementato e testato le modifiche, rivaluta il rischio residuo utilizzando nuove prove. Non è necessario avere tutte e tre le valutazioni per ogni elemento. Indica chiaramente quali controlli, assunzioni e fatti sono inclusi nella valutazione.
Compilare il registro e scegliere le azioni successive
L’esempio di formazione seguente contiene tre voci con ruoli e valutazioni ipotetiche. Sostituiscile con i dati del tuo ambiente. Ogni riga dovrebbe descrivere uno scenario gestibile, piuttosto che la situazione di sicurezza complessiva dell’azienda.
|
ID e risorsa |
Minaccia e conseguenza |
Controlli esistenti |
Probabilità e impatto |
Responsabile del rischio |
Azione successiva e verifica |
|---|---|---|---|---|---|
|
R001. Posta aziendale del team pagamenti |
L’accesso non autorizzato consente di modificare i dettagli di pagamento nelle comunicazioni; è possibile effettuare pagamenti errati. |
L’autenticazione a più fattori è abilitata per alcuni utenti; la copertura per gli altri non è stata verificata. |
Probabilità media e impatto elevato. Motivo: il processo di pagamento dipende dalle comunicazioni, e la copertura assicurativa è incompleta. |
Responsabile del processo finanziario |
Il team IT verifica la copertura assicurativa per l’autenticazione; il responsabile del processo verifica la conferma delle modifiche ai dettagli di pagamento. Concordare una data e un responsabile per ogni attività nel piano. |
|
R002. File di lavoro condivisi |
L’eliminazione o la cifratura interrompe la preparazione dei documenti. |
Sono state eseguite le copie di backup, ma non è stata verificata la possibilità di recuperare i dati necessari. |
È necessario verificare la probabilità; l’impatto è elevato per il processo critico selezionato. L’incertezza non è stata sostituita da un numero. |
Responsabile del processo di preparazione dei documenti |
Pianificare un test di recupero sicuro, definire il criterio e la data del risultato. Utilizzare il risultato per affinare la valutazione e le modifiche necessarie. |
|
R003. Servizio aziendale esterno |
Un ex collaboratore ha ancora accesso ai dati e potrebbe modificarli o copiarli. |
Esiste un elenco di utenti, ma non è stata assegnata la verifica periodica con i contratti attuali. |
Probabilità media; l’impatto dipende dai dati accessibili e dai permessi. Confermare con il proprietario. |
Responsabile del servizio |
Verificare l’accesso con le attività attuali, concordare la rimozione dei permessi non necessari e pianificare un controllo ripetuto. |
Aggiungere collegamenti a prove, l’autore della valutazione e la data, lo stato, il trattamento selezionato, l’implementatore, la scadenza e il criterio di completamento al registro di lavoro. Il responsabile del rischio decide sulle conseguenze; il responsabile del compito effettua la modifica specifica. Una persona può ricoprire entrambi i ruoli in una piccola azienda, ma distinguerli nell’inserimento. Limitare l’accesso a informazioni dettagliate sui permessi e sulle debolezze. Fornire alla direzione un riepilogo appropriato.
Scegliere il trattamento del rischio e concordare un piano
- Ridurre: modificare l’accesso, la configurazione o un processo per ridurre la probabilità o le conseguenze.
- Evitare: interrompere l’operazione rischiosa o sostituire il modo in cui viene eseguita.
- Condividere la responsabilità e le conseguenze attraverso un contratto o un’assicurazione, mantenendo al contempo i propri obblighi e la dipendenza dal fornitore.
- Accettare: un proprietario autorizzato concorda esplicitamente con il rischio residuo, le condizioni e la data di revisione. La mancanza di un budget o di un implementatore non significa automaticamente un’accettazione.
Definire le priorità, le risorse e i tempi in base alle conseguenze, all’accessibilità del percorso di attacco e alle dipendenze. Assegnare un proprietario e un metodo di verifica a ciascun compito. Se la risoluzione richiede un’interruzione, concordare una finestra di lavoro, un test dell’applicazione e il ripristino alle impostazioni precedenti. Se un cambiamento non è ancora possibile, registrare un controllo temporaneo, i suoi limiti e una data di revisione. Se ci sono segni che un incidente si è già verificato, avviare il processo di risposta concordato invece di aspettare che la valutazione sia completata.
Verificare i risultati e mantenere il registro
Chiudere un compito dopo aver verificato il risultato, anziché ricevere un messaggio che un tool è stato installato. Per il rischio R002, la prova sarebbe il recupero riuscito dei dati richiesti in conformità con le condizioni concordate. Dopo la verifica, aggiornare lo stato del controllo, la valutazione del rischio residuo e la decisione del proprietario. Se l’effetto è inferiore alle aspettative, riaprire la questione. Conservare la cronologia delle modifiche in modo che la ragione di una valutazione rivista rimanga visibile.
Pianificare revisioni periodiche in base alla criticità e ai requisiti applicabili. Rivedere anche un elemento dopo un incidente, un cambiamento del fornitore, nuove evidenze o un cambiamento significativo nell’accesso o nell’infrastruttura. Non esiste una frequenza obbligatoria che si applica a tutte le aziende. La scoperta automatica e i report possono aggiornare i fatti di base, ma le persone assegnate devono comunque concordare sulle conseguenze, sulle assunzioni e sull’accettazione del rischio.
Prima di presentare i risultati alla direzione, verificare che l’ambito sia chiaro, che i scenari importanti siano collegati ai processi, che i controlli esistenti siano verificati, che i criteri siano coerenti e che le incertezze siano evidenziate. Ogni rischio prioritario deve avere un proprietario e una decisione. Ogni azione deve avere un implementatore, una scadenza e un criterio di verifica. In questo modo, il registro supporta il lavoro piuttosto che limitarsi a elencare descrizioni allarmanti.
Se la valutazione manca di evidenze tecniche verificate sulle condizioni di sicurezza, discutere una revisione con i responsabili della sicurezza tramite la pagina Valutazione della sicurezza. I risultati possono aiutare a raffinare gli elementi e a scegliere azioni giustificate.
