L’igiene informatica consiste nel mantenere controlli essenziali che riducono le occasioni di compromissione: inventario, accessi, aggiornamenti, copie di sicurezza, configurazioni e capacità di reagire. La difficoltà pratica è scegliere da dove iniziare quando risorse e tempo sono limitati. Un programma utile ordina le azioni secondo esposizione, conseguenze e dipendenze, e richiede una prova del risultato.
La guida di igiene informatica dell’ANSSI raccoglie 42 misure e propone una base metodologica. La sua numerazione non costituisce una sequenza obbligatoria di progetto per un’organizzazione italiana. Il percorso seguente adatta l’intento operativo della guida: costruire un piano progressivo, distinguere ciò che è dichiarato da ciò che funziona e rendere sostenibile la manutenzione.
Definire ciò che deve essere protetto per primo
Partite dai servizi che trattano informazioni più delicate o che non possono interrompersi senza conseguenze rilevanti. Individuate sistemi esposti all’esterno, account con privilegi estesi e dati difficili da recuperare. Il numero di dispositivi non misura da solo la criticità: un piccolo servizio può custodire le identità che permettono di amministrare tutta l’organizzazione.
Costruite una mappa dei sistemi e delle dipendenze sufficientemente concreta da assegnare un referente a ogni componente. Non aspettate un inventario perfetto per rimuovere un’esposizione evidente; registrate però i limiti della conoscenza, perché un sistema sconosciuto può rimanere fuori dalle verifiche e dagli aggiornamenti.
Raccogliete anche le pratiche quotidiane: come vengono condivisi i documenti, chi attiva gli account, come si richiede assistenza e dove finiscono le esportazioni. Le procedure informali sono spesso il punto in cui una buona configurazione viene aggirata per completare un’attività urgente. Il programma deve offrire alternative utilizzabili, non soltanto divieti.
Fare una fotografia iniziale verificabile
Per ogni controllo chiedete una dimostrazione breve. Se l’organizzazione dichiara che tutti gli account usano MFA, esaminate un campione e i percorsi alternativi. Se dichiara che i backup sono affidabili, chiedete l’esito di un ripristino. Se dichiara che i dispositivi sono aggiornati, confrontate l’inventario con quelli raggiunti dallo strumento di gestione.
Usate stati che abbiano significato operativo: verificato, parziale, assente, non pertinente e non noto. «Non noto» deve generare una richiesta di informazioni con proprietario. «Parziale» deve indicare la porzione scoperta, altrimenti una percentuale elevata può nascondere proprio un’applicazione critica.
| Controllo | Prova iniziale | Lacuna da descrivere |
|---|---|---|
| Identità | Account, fattori e revoche su un campione | Accessi alternativi o identità senza referente |
| Aggiornamenti | Versioni osservate e stato del supporto | Componenti non raggiunti o non aggiornabili |
| Backup | Recupero di dati e verifica applicativa | Dipendenze, chiavi o tempi non provati |
| Esposizione | Servizi effettivamente raggiungibili | Porte e accessi non motivati |
| Segnalazioni | Percorso di presa in carico di un evento | Canali non disponibili o responsabilità mancanti |
Prima fase: ridurre gli accessi più pericolosi
Controllate account privilegiati, credenziali condivise e accessi remoti. Definite identità personali, privilegi coerenti con la funzione e revoca alla cessazione. La politica password e MFA deve comprendere il recupero e le eccezioni, perché un canale di assistenza debole può aggirare il secondo fattore.
Chiudete servizi inutilizzati soltanto dopo aver verificato le dipendenze. Per gli strumenti di amministrazione, stabilite percorsi autorizzati e limitazioni di rete. Non lasciate aperta una soluzione temporanea perché nessuno sa chi l’abbia creata: individuate il referente, raccogliete l’esigenza e decidete se mantenerla con controlli oppure rimuoverla.
Applicate le misure in modo progressivo e mantenete un accesso di recupero controllato. Un cambiamento di autenticazione distribuito senza collaudo può bloccare gli utenti o gli amministratori. La rapidità utile è quella che riduce il rischio senza produrre una nuova interruzione evitabile.
Seconda fase: rendere affidabili configurazioni e aggiornamenti
Create classi omogenee di dispositivi e definite una baseline per ciascuna. Il rafforzamento di Windows e Linux comprende servizi, privilegi, rete e controlli locali. Conservate versione della baseline, adattamenti e motivi delle eccezioni, evitando una configurazione unica per sistemi con funzioni molto diverse.
Organizzate il trattamento delle vulnerabilità a partire dall’esposizione reale. Un componente critico non aggiornabile richiede una decisione e misure compensative, non soltanto una voce in un elenco. Definite chi valuta l’aggiornamento, chi lo distribuisce e chi controlla che il servizio continui a funzionare.
La manutenzione comprende anche applicazioni, estensioni, strumenti di accesso remoto e componenti gestiti da terzi. Chiedete ai fornitori il perimetro della loro responsabilità e il modo in cui segnalano fine del supporto o interventi necessari. Un contratto generico di assistenza può non includere ogni componente che l’organizzazione presume coperto.
Terza fase: dimostrare che il servizio può ripartire
Verificate copie di sicurezza, separazione dagli accessi ordinari e disponibilità delle chiavi. Un backup eseguito correttamente è soltanto una parte del percorso. Occorre dimostrare che i dati possano essere ripristinati, interpretati dall’applicazione e utilizzati dalle persone autorizzate entro obiettivi compatibili con il servizio.
Il piano di continuità operativa stabilisce priorità e modalità degradate. Il disaster recovery traduce queste esigenze nella sequenza tecnica. Verificate le dipendenze circolari: le istruzioni potrebbero essere conservate nel sistema indisponibile e la chiave di recupero potrebbe dipendere dall’identità che state tentando di ripristinare.
Eseguite una prova delimitata e annotate tempi, difficoltà e dati non recuperati. Prevedete anche la riconciliazione delle operazioni svolte durante l’interruzione. Il ritorno del server non coincide necessariamente con il ritorno del servizio: servono controlli su completezza, correttezza e disponibilità delle funzioni necessarie.
Rendere visibili incidenti e anomalie
Scegliete eventi di sicurezza che possano sostenere decisioni concrete. La progettazione dei log collega sorgenti, integrità, conservazione e presa in carico. Evitate di raccogliere contenuti personali indiscriminatamente nel tentativo di non perdere nulla: il controllo deve avere una finalità e un responsabile.
Create un canale di segnalazione riconoscibile anche per chi non ha competenze tecniche. Chiedete fatti semplici: cosa è accaduto, quando, quale servizio è coinvolto e come ricontattare la persona. Non imponete al dipendente di stabilire se l’evento sia già una violazione di dati prima di chiedere aiuto.
Una breve esercitazione può verificare il percorso di un messaggio sospetto o di un dispositivo smarrito. Controllate chi riceve la segnalazione, come viene classificata e quale sostituto interviene in assenza del referente. Le lacune organizzative meritano la stessa attenzione di quelle tecniche, perché entrambe possono ritardare il contenimento.
Assegnare azioni e misurare risultati
Ogni azione deve contenere problema, perimetro, referente, scadenza interna ed evidenza di chiusura. «Migliorare i backup» è troppo generico; «ripristinare un archivio del servizio selezionato e farne verificare la leggibilità al referente» permette di capire quando l’attività è completata. Le scadenze vanno motivate in relazione a rischio e risorse.
Misurate account senza proprietario, dispositivi fuori supporto, eccezioni scadute, ripristini falliti e allarmi senza presa in carico. Evitate indicatori che premiano soltanto il numero di documenti prodotti. Un controllo può risultare formalmente compilato e continuare a non coprire il sistema più importante.
L’articolo 32 GDPR collega la sicurezza anche alla verifica e valutazione dell’efficacia delle misure. Il programma di igiene informatica deve quindi prevedere manutenzione, riesame dopo incidenti e integrazione dei nuovi servizi. Per una piccola organizzazione può bastare un registro delle azioni chiaro e aggiornato, purché le responsabilità siano reali e le prove consentano di distinguere ciò che è operativo da ciò che rimane soltanto pianificato.
Prima di acquistare un ulteriore strumento, verificate quale lacuna dovrebbe colmare e chi ne utilizzerà i risultati. Una soluzione di rilevazione richiede tempo per interpretare gli allarmi; un catalogo degli asset richiede referenti che correggano le informazioni. Se queste responsabilità non sono definite, l’acquisto può aggiungere una console senza risolvere il problema. Inserite quindi capacità operativa, formazione ed esportazione delle evidenze fra i criteri di scelta.