La gestione e, di conseguenza, la risposta agli incidenti informatici si compongono di tre fasi che, nella loro rappresentazione grafica classica, sono di grandezza equivalente e che sono sostanzialmente legate ai differenti tempi di azione:
- prima dell’incidente: in questa fase ci si occupa di definire le azioni e le procedure, formare le persone e compiere i test tecnici necessari;
- durante l’incidente: in questa fase ci si deve preoccupare di identificare l’incidente, contenerne i danni, procedere all’eliminazione delle cause e contestualmente provvedere alla comunicazioni ai soggetti terzi interessati;
- dopo l’incidente: dove l’analisi forense e la disamina di quanto successo forniscono gli elementi per quelle che comunemente vengono chiamati “gli insegnamenti dall’accaduto”, che devono fornire la base per evitare che l’incidente si ripeta.
Come detto, nelle rappresentazioni grafiche le tre fasi hanno generalmente uguale grandezza, facendo implicitamente presupporre che abbiano uguale importanza. Nella realtà, invece, accade spesso che la gestione degli incidenti venga associata unicamente alla seconda fase.
Questa consuetudine però aumenta considerevolmente il rischio che un’incidente informatico con bassa incidenza sotto il profilo tecnico abbia ripercussioni ben maggiori, proprio a causa di una mancata definizione a priori di azioni e procedure di emergenza (fase 1).
Basti pensare, per esempio, alle ripercussioni in termini di “danno reputazionale” che possono derivare da una non corretta comunicazione agli interessati di un momentaneo shutdown di alcuni servizi. Senza considerare, naturalmente, gli obblighi di legge, sempre in tema di comunicazione, se l’incidente dovesse interessare la privacy di uno o più soggetti.
Questo modello che si concentra solo sulla fase di gestione dell’incidente viene definito “reattivo” ed è, nella nostra esperienza, tanto più radicato come cultura aziendale tanto più l’azienda si muove nel campo della tecnologia hardware o software.
In questi casi la tendenza a sovrastimare le proprie abilità di risposta ad eventi tecnici avversi sfocia spesso nella sottovalutazione della fase di predisposizione delle procedure.
Di seguito proveremo ad evidenziare le impostazioni di due standard riconosciuti in tema di gestione degli incidenti, con particolare riferimento alle regole per la redazione del documento cardine della gestione degli incidenti: l’Information Security Incident Management Plan.
Le norme che analizzeremo nel dettaglio sono:
- ISO/IEC 27035-1:2016 “Principles of incident management”;
- ISO/IEC 27035-2:2016 “Guidelines to plan and prepare for incident response”;
- NIST Special Publication 800-61 revision 2. Computer Security Incident Handling.
Indice degli argomenti
Gestione degli incidenti informatici: lo schema ISO/IEC 27035
Appartenente alla famiglia della norma ISO/IEC 27001:2013, da cui dipendono anche in fase di certificazione, la norma ISO/IEC 27035:2016 è suddivisa in due parti pubblicate distintamente anche se interdipendenti.
Il punto di partenza della norma è la considerazione che l’applicazione delle policy unite ai controlli di sicurezza non sono sufficienti per garantire una protezione totale sia delle informazioni che dei sistemi che le ospitano. Per questo motivo viene proposto un approccio strutturato alla gestione degli incidenti informatici.
Nella prima parte della norma vengono presentati i concetti base e le diverse fasi della gestione degli incidenti, compresa una parte di schemi ed esempi pubblicati come allegati. Nell’allegato C, per esempio, viene inoltre riportata una tabella delle corrispondenze con la norma ISO/IEC 27001:2013.
Nella seconda parte, invece, vengono analizzate nello specifico le due fasi denominate “Plan and prepare” e “Lesson learnt”.
Le fasi principali come previste dalla norma sono cinque:
- Plan and prepare
- Detectione and reporting
- Assessmente and detection
- Respose (inclusa la fase di Post Incidente activity)
- Lesson learnt
Come si vede, sono una variante delle tre fasi comunemente considerate viste sopra. La cosa che invece connota questo tipo di approccio è il fatto che nello schema dettagliato delle operazioni da compiere fase per fase, la stesura dell’Information Security Management Plan viene prevista come terza attività della fase Plane and Prepare, dopo la definizione delle policy di sicurezza incluse quelle relative alla gestione del rischio e l’approvazione del management (in tipico stile ISO).
Anche l’ultima azione di questa prima fase riguarda l’Information Security Management Plan, in quanto è prevista una sua verifica.
La definizione dell’Information Security Management Plan precede anche la fase di costituzione del IRT (Incident Response Team), ossia il nucleo di persone deputate a gestire gli incidenti.
Queste informazioni sono contenute nella ISO/IEC 27035-1:2016, punto 5.2 c) e sono riprese ampliate nella ISO/IEC 27035-2:2016, punto 6. dove si definisce in modo puntuale il contenuto dell’Information Security Management Plan.
Ed è in questi paragrafi che prende corpo la natura dell’Information Security Management Plan come concepito dalla norma: il piano nasce ed è basato sulle policy di gestione degli incidenti e quindi comprende anche i riferimenti a documenti specifici.
La finalità del piano resta comunque quella di fornire una vista d’insieme delle procedure da attuare in caso di incidenti pur mantenendo un livello di dettaglio per quanto riguarda i riferimenti alle policy; che come detto ne rappresentano la base strutturale.
Gestione degli incidenti informatici: lo schema NIST
Il documento NIST 800-61 riflette nella sua struttura di circa 80 pagine l’approccio generale del National Institute of Standards and Technology americano, definendo in maniera pragmatica contesto ed azioni tecniche in tema di gestione degli incidenti ed in una certa misura anche la definizione dell’Information Security Management Plan risente di questa impostazione.
La prima cosa che si nota è che uno degli elementi del Piano dovrebbe essere l’evidenza del supporto del management, inteso anche in termini di risorse organizzative. Questo mette in correlazione diretta la struttura del Piano con la struttura scelta per l’IRT (Incident Response Team).
L’approvazione formale del piano da parte del management costituisce un elemento centrale.
Gli elementi costitutivi del piano sono quindi (cfr. 2.3.2 Plan elements):
- missione;
- strategie e obiettivi;
- approvazione dei dirigenti;
- approccio organizzativo alla risposta agli incidenti;
- come il team di risposta agli incidenti comunicherà con il resto dell’organizzazione e con altre organizzazioni;
- metriche per misurare la capacità di risposta agli incidenti e la sua efficacia;
- tabella di marcia per l’aumento della capacità di risposta agli incidenti;
- come il programma si inserisce nell’organizzazione generale.
In questa impostazione, sono le Policy di gestione degli incidenti (cfr. 2.3.1) insieme all’Information Security Management Plan a fornire la base per la definizione delle SOP (Standard Operating Procedure), che sono una declinazione di processi tecnici specifici, checklist o moduli usati dall’IRT (Incident Response Team, cfr. 2.3.3).
Sembrerebbe quindi che non vi sia la forte correlazione prevista tra policy e piano dalla norma ISO/IEC 27035:2016, ma questa interpretazione viene chiarita nelle raccomandazioni (cfr. 2.6) dove testualmente si indica come sia necessario “Develop an incident response plan based on the incident response policy”.
Diversa, invece, la struttura delle fasi che nel documento NIST sono quattro.
Ciclo di vita dell’Incident Response Plan.
Nonostante il nome della prima fase sia di fatto simile alla struttura ISO (“Preparation” vs. “Plan and prepare”) queste prevedono due fasi sono di fatto diverse nei due standard.
Nel primo caso (NIST) sono definite già le prime fasi di preparazione all’intervento, nel secondo (ISO/IEC 27035) vengono comprese anche le attività di creazione IRT, delle policy e la definizione dell’Information Security Management Plan.
Nell’approccio NIST, in sostanza, si enfatizza la gestione dell’incidente dal punto di vista tecnico con riferimenti ad alcune moduli di crittografia ed altri dettagli tecnici.
Conclusioni
Come visto, entrambi i modelli per la gestione degli incidenti informatici offrono tutti dei riferimenti completi e costituiscono un ottimo punto di riferimento nell’implementare e gestire a tutto tondo la tematica degli incidenti informatici.
Alcune considerazioni, però, ci fanno preferire l’approccio ISO 27035:2016 a quello NIST:
- in primo luogo, proprio la definizione puntuale della fase “Plan and prepare” è di aiuto nella individuazione di tutti i fattori critici;
- le aziende che richiedono la certificazione AgID per fornire servizi alla PA sono invitate ad integrare la certificazione ISO/IEC 27001 con le certificazioni ISO/IEC 27035:2016;
- la gestione degli incidenti (data breach) nel GDPR potrebbe avere nella applicazione della struttura proposta dalla norma ISO/IEC 27035:2016 una solida base di partenza. Questo naturalmente se non ci si focalizza unicamente su termini e modi della comunicazione obbligatoria al Garante.
In generale al netto di coloro che in tema di incidenti informatici si affidano, più o meno consapevolmente, all’approccio “prega & spera”, farei mia la frase attribuita a Abramo Lincoln “se avessi otto ore per tagliare un albero, ne passerei sei ad affilare la mia scure”.
In altre parole, mi dedicherei a stendere un dettagliato Information Security Incident Managment Plan, quale che sia lo schema applicato.
