Articolo Pubblicazioni

ISO/IEC 27035:2011: lo standard ISO per la gestione degli incidenti di sicurezza

di · Pubblicato il 21 novembre 2011

Abstract

Quest’anno ISO e IEC hanno pubblicato la norma 27035, dedicata alla gestione degli incidenti di sicurezza delle informazioni. Prende il posto del rapporto tecnico 18044 del 2004 e completa la famiglia 27000, che con la 27001 chiede alle organizzazioni di saper gestire gli incidenti. L’articolo spiega la differenza fra evento e incidente, le cinque fasi del processo, il ruolo del gruppo di risposta, la classificazione per gravità e il legame con la raccolta delle prove digitali.

Vincenzo Calabrò | ISO/IEC 27035:2011: lo standard ISO per la gestione degli incidenti di sicurezza
 

Una norma attesa

Fino a oggi chi voleva organizzare la gestione degli incidenti secondo un riferimento internazionale aveva due strade. La prima era la guida del NIST SP 800-61, nata negli Stati Uniti per le amministrazioni federali e aggiornata nel 2008. La seconda era il rapporto tecnico ISO/IEC TR 18044 del 2004, che non aveva il valore di una norma. Nel 2011 ISO e IEC hanno pubblicato la ISO/IEC 27035, «Information security incident management», che sostituisce il rapporto tecnico e si inserisce nella famiglia 27000.
Il collegamento con la ISO/IEC 27001 è diretto. Lo standard sui sistemi di gestione della sicurezza chiede di gestire gli incidenti con un processo definito, e la 27002 dedica un capitolo ai controlli sulla segnalazione degli eventi e sulla risposta. La 27035 descrive come costruire quel processo.

Evento e incidente

La norma distingue con chiarezza due concetti. Un evento di sicurezza è un fatto che indica una possibile violazione delle politiche o un malfunzionamento dei controlli, come un allarme dell’antivirus o un tentativo di accesso fallito. Un incidente è un evento, o una serie di eventi, che ha una probabilità significativa di compromettere le attività dell’organizzazione o di minacciare la sicurezza delle informazioni. Non ogni evento è un incidente, e il processo serve proprio a filtrare i molti eventi per individuare quelli che richiedono una risposta.

Le cinque fasi

La gestione degli incidenti è descritta come un ciclo in cinque fasi:
  1. pianificazione e preparazione, con la politica di gestione degli incidenti, il gruppo di risposta, le procedure, gli strumenti e la formazione;
  2. rilevazione e segnalazione, cioè la raccolta delle informazioni sugli eventi da sistemi automatici e da persone e la loro registrazione;
  3. valutazione e decisione, in cui si stabilisce se un evento è un incidente e quanto è grave;
  4. risposta, con il contenimento, l’eliminazione della causa, il ripristino e, quando serve, l’analisi forense e l’escalation;
  5. lezioni apprese, cioè l’analisi dell’incidente concluso per migliorare controlli, procedure e valutazione dei rischi.
La prima e l’ultima fase sono quelle che più spesso mancano nelle organizzazioni. Senza preparazione la risposta è improvvisata, e senza lezioni apprese lo stesso incidente si ripete.

Il gruppo di risposta

La norma prevede un gruppo di risposta agli incidenti di sicurezza delle informazioni, indicato con la sigla ISIRT. Può essere un gruppo permanente o virtuale, formato da persone che in condizioni normali svolgono altri compiti. Ne fanno parte competenze tecniche, ma anche referenti legali, delle risorse umane e della comunicazione, perché molti incidenti hanno conseguenze che vanno oltre i sistemi. La norma suggerisce di definire un punto di contatto unico per le segnalazioni e un responsabile con l’autorità per prendere decisioni rapide, compresa quella di isolare un sistema.

Classificare per decidere

Per decidere in fretta servono criteri condivisi. La norma propone di classificare gli incidenti per categoria, come attacchi tecnici, malfunzionamenti, errori umani o violazioni fisiche, e per gravità, valutando l’impatto sulla riservatezza, sull’integrità e sulla disponibilità e le conseguenze per l’organizzazione. La scala di gravità determina chi deve essere informato, quali tempi di risposta applicare e quando coinvolgere la direzione o le autorità esterne.

Comunicare durante l’incidente

Una parte della norma riguarda la comunicazione. Durante un incidente servono canali sicuri e alternativi, perché la posta elettronica potrebbe essere compromessa o fuori servizio, e un elenco aggiornato dei contatti interni ed esterni, dai fornitori ai gruppi di risposta nazionali. Va deciso in anticipo chi parla con i clienti, con la stampa e con le autorità, e quali informazioni possono essere condivise. Una comunicazione confusa può fare più danni dell’incidente stesso, soprattutto quando riguarda dati personali.
La norma raccomanda anche di registrare in un unico archivio tutte le informazioni sull’incidente, dalle prime segnalazioni alle decisioni prese, con data e ora. Questo registro serve durante la risposta per coordinare il gruppo e, dopo, per l’analisi delle lezioni apprese e per eventuali verifiche.

Il legame con le prove digitali

Un aspetto spesso trascurato riguarda le prove. La 27035 chiede che, quando un incidente può avere conseguenze legali o disciplinari, le informazioni siano raccolte e conservate in modo da poter essere usate davanti a un giudice. In pratica significa preparare in anticipo procedure di acquisizione, strumenti e moduli per la catena di custodia, e non lasciare all’improvvisazione dei tecnici il trattamento dei sistemi compromessi. In Italia questo si collega alle regole introdotte dalla legge 48 del 2008, che chiedono misure tecniche per conservare i dati originali e impedirne l’alterazione.

Da dove cominciare

Per un’organizzazione che non ha ancora un processo formale, la norma offre un percorso graduale. Si parte da una politica breve, approvata dalla direzione, che definisce cosa si intende per incidente, chi deve essere avvisato e come. Si individua il gruppo di risposta, anche ridotto, e si scrivono poche procedure per gli scenari più probabili, come un’infezione da malware, la perdita di un portatile o un accesso non autorizzato. Si registrano tutti gli eventi segnalati e, dopo ogni incidente, si dedica un’ora a capire che cosa ha funzionato e che cosa no. Con il tempo il processo si arricchisce e diventa parte del sistema di gestione della sicurezza.
Conviene infine mettere alla prova il processo prima che serva davvero. Un’esercitazione a tavolino, in cui il gruppo discute come reagirebbe a uno scenario realistico, fa emergere in poche ore contatti mancanti, decisioni non attribuite e procedure poco chiare. La norma invita a ripetere questi test con regolarità e a includerli nel piano di formazione.
 
 
Vincenzo Calabrò | Ingegnere informatico specializzato in sicurezza informatica e investigazioni digitali. Funzionario informatico del Ministero dell'Interno; su incarico autorizzato si occupa di sicurezza informatica e di perizie informatiche forensi. Autore di articoli e saggi. Lecturer, Speaker, Trainer.
Profili: Google Scholar · ORCID · ResearchGate · Academia.edu · CyberSecurity360 · AgendaDigitale · ICT Security Magazine · LinkedIn