Analisi dei rischi informatici in una PMI: come funziona

Ogni norma di sicurezza parte dallo stesso punto: l'analisi dei rischi informatici. La ISO/IEC 27001:2022 la richiede ai punti 6.1.2 e 6.1.3, la NIS 2 la colloca al primo posto tra le misure di gestione del rischio, il catalogo VDA ISA usato negli assessment TISAX® la prevede in modo esplicito. Eppure in molte PMI si riduce a un foglio di calcolo compilato una volta e mai più aperto.

A cosa serve

Non è un adempimento. Serve a rispondere a tre domande:

• cosa può andare storto per le informazioni e i sistemi che contano per l'azienda;
• quanto è grave e quanto è probabile;
• quali interventi conviene realizzare, con risorse inevitabilmente limitate.

Senza questa base le misure diventano una lista della spesa.

Gli elementi dell'analisi

Perimetro e criteri

Prima di tutto si stabiliscono cosa viene analizzato e con quali criteri: una scala di probabilità, una scala di impatto descritta in termini concreti (ore di fermo produttivo, dati di clienti esposti, penali, danno d'immagine) e una soglia di accettazione. Scale semplici funzionano meglio di formule complesse; conta che vengano applicate in modo coerente.

Asset

Gli asset rappresentano ciò che ha valore: informazioni (disegni tecnici, dati dei clienti, offerte), sistemi (ERP, server, PLC, postazioni), servizi (email, cloud, connettività), persone e luoghi. In una PMI conviene ragionare per gruppi omogenei, come "postazioni d'ufficio" o "documentazione di progetto del cliente", invece di analizzare ogni singolo dispositivo.

Minacce

Le minacce rappresentano gli eventi che possono colpire gli asset. Le più ricorrenti per una PMI manifatturiera:

• phishing e furto di credenziali;
• ransomware;
• errore umano, come l'invio di un file al destinatario sbagliato;
• guasti hardware o interruzione di un servizio cloud;
• accessi non autorizzati da parte di un fornitore;
• furto o smarrimento di dispositivi;
• eventi fisici: incendio, allagamento, blackout.

Vulnerabilità

Una vulnerabilità è la debolezza che consente alla minaccia di produrre un danno: autenticazione a più fattori assente sulla VPN, sistemi non aggiornati, backup sulla stessa rete dei server, account di ex dipendenti ancora attivi, assenza di formazione sul phishing.

Probabilità, impatto e livello di rischio

Per ogni scenario (asset, minaccia, vulnerabilità) si stimano probabilità e impatto tenendo conto delle misure già presenti. Qualche esempio illustrativo di esito:

• ransomware sui server di produzione con backup non separati: rischio alto;
• accesso remoto del fornitore senza autenticazione a più fattori: rischio medio-alto;
• furto di un portatile con disco cifrato: rischio basso.

Il valore numerico non è una verità scientifica: serve a ordinare le priorità e a rendere confrontabili scelte diverse.

Trattamento

Per ogni rischio sopra soglia si sceglie una strategia: ridurre (nuovi controlli o controlli migliorati), evitare (rinunciare all'attività che genera il rischio), condividere (contratti o assicurazioni, ferma restando la responsabilità dell'azienda) oppure accettare in modo consapevole e motivato. Le scelte confluiscono in un piano di trattamento con azioni, responsabili e scadenze; nella ISO/IEC 27001 il piano si collega alla Dichiarazione di Applicabilità.

Rischio residuo

Dopo le azioni previste si rivalutano probabilità e impatto e si ottiene il rischio residuo, che va approvato formalmente dal responsabile del rischio e, per i rischi rilevanti, dalla direzione. Per la NIS 2 è un punto chiave: gli organi di amministrazione approvano le misure di gestione del rischio e ne rispondono.

Il collegamento con il vulnerability assessment

Analisi dei rischi e vulnerability assessment (VA) si alimentano a vicenda:

• il VA porta dati reali: invece di supporre che i sistemi siano aggiornati, lo si verifica;
• il punteggio CVSS non basta da solo: misura la gravità tecnica, mentre il rischio dipende dal contesto; la stessa vulnerabilità pesa di più su un server esposto su internet che su una macchina isolata;
• l'analisi dei rischi orienta il VA verso sistemi esposti, asset critici e accessi dei fornitori;
• un VA periodico verifica il trattamento, mostrando se le azioni del piano hanno ridotto davvero le vulnerabilità.

Un VA è una valutazione in un momento preciso, non una certificazione, e non può escludere l'esistenza di vulnerabilità non individuate.

Errori frequenti

• Analizzare solo l'IT, trascurando persone, fornitori e processi.
• Usare scale di impatto astratte, prive di esempi concreti per l'azienda.
• Non coinvolgere i responsabili di processo, che conoscono i rischi meglio di chiunque.
• Svolgere l'analisi una sola volta, senza aggiornarla almeno annualmente e dopo cambiamenti rilevanti o incidenti.

Il supporto di General Tech di Rosario Zappalà

L'analisi dei rischi è impostata da Rosario Zappalà, consulente indipendente con competenze Red Team e Blue Team, da remoto e con sopralluoghi quando necessari. Dopo una call gratuita di 30 minuti e una proposta scritta personalizzata, il percorso comprende definizione dei criteri, interviste a direzione, Responsabile IT, fornitore IT e responsabili di processo, registro dei rischi e piano di trattamento, eventuale vulnerability assessment sul perimetro concordato con autorizzazione scritta, e presentazione dei risultati alla direzione per l'approvazione del rischio residuo.

Domande frequenti

Esiste una norma di riferimento per il metodo?

La ISO/IEC 27001 richiede un processo definito e ripetibile senza imporre un metodo specifico. La ISO/IEC 27005 offre linee guida dedicate alla gestione dei rischi per la sicurezza delle informazioni.

Serve un software dedicato?

Non necessariamente. In una PMI un registro ben strutturato è sufficiente, purché aggiornato e collegato al piano di trattamento.

Con quale frequenza va ripetuta?

Almeno una volta l'anno e ogni volta che cambiano in modo significativo sistemi, processi, fornitori o minacce, oppure dopo un incidente.

Analisi dei rischi e vulnerability assessment coincidono?

No. L'analisi dei rischi è un processo di gestione che riguarda l'intera organizzazione; il VA è una verifica tecnica che fornisce dati sulle vulnerabilità dei sistemi e alimenta l'analisi.