In ambito IT si parla sempre più spesso di incident management. Spesso confuso con l’IT service management, che equivale alla più ampia disciplina in cui rientra, ed al più specifico incident response, l’IT incident management è un processo necessario per garantire di tornare alla normale condizione operativa dopo qualsiasi imprevisto, in modo da evitare o mitigare qualsiasi impatto negativo derivante dalle eventuali interruzioni di servizio.
L’incidente informatico, nella sua definizione più ampia ed informale, è un evento inaspettato che causa un effetto dirompente sulla normale routine dei servizi IT. La gestione di un incidente deve pertanto prevedere sia gli aspetti utili a prevenire che tali eventualità accadano, sia le misure per reagire in modo corretto e pianificato per ripristinare nella maniera più efficace i livelli di servizio compromessi.
A livello IT, l’incident management consente ad un’organizzazione di essere pronta a gestire qualsiasi criticità per ridurre sia la durata che la magnitudo degli eventi imprevisti che possono verificarsi nel funzionamento di hardware e software, oltre che per quanto concerne la sicurezza dei dati.
A livello disciplinare, i processi che regolano l’incident management costituiscono un ambito ormai consolidato e vengono agevolati da alcuni framework. I più noti sono, con ogni probabilità, l’ITIL e il COBIT, i cui contenuti possono essere peraltro combinati dagli specialisti durante l’implementazione del processo in ciascuna realtà aziendale.
Per ragioni esemplificative, faremo riferimento soprattutto alla letteratura dell’ITIL. Acronimo di IT infrastructure library, è attualmente diffuso in due versioni principali: ITIL v2 (2001), che ha definito i processi di Service Delivery e Service Support, e ITIL v3 (2007), che ne ha integrato ed esteso i contenuti fondamentali in cinque testi fondamentali: Service Strategy, Service Design, Service Transition, Service Operation, Continual Service Improvement, secondo cui si articola l’intero ciclo di vita del servizio (service lifecycle).
Perché l’incident management è importante
Nell’era del digitale, garantire la continuità di business non è più possibile mediante semplici interventi di natura episodica, a fronte di una avvenuta criticità. Occorre che le organizzazioni si dotino di una struttura permanente, dotata degli strumenti e dei processi efficaci per garantire sia la corretta operatività interna, sia una solida erogazione dei servizi verso i clienti finali.
I downtime all’infrastruttura IT e la violazione della sicurezza dei dati comportano infatti una sensibile minaccia per la sopravvivenza stessa delle aziende. Da essi possono infatti derivare sensibili danni economici e reputazionali, che possono comportare la perdita di clienti e, nelle circostanze più serie, al risarcimento di ingenti danni dovuti alla violazione di accordi contrattuali, oltre alle possibili inadempienze a livello normativo, a sua volta potenziale causa di azioni a livello amministrativo.
L’incident management rappresenta dunque il processo dell’IT service management a cui si deve la garanzia della continuità di business.
Quali sono gli obiettivi
Secondo la documentazione di ITIL v2, il principale obiettivo del processo di incident management risiede nel ripristino delle normali operazioni previste dal business, nella maniera più veloce e con la minor interruzione di servizio possibile, in modo da assicurare il soddisfacimento del miglior livello di disponibilità possibile. Tale definizione si applica sia per i processi operativi interni che per i servizi erogati ai clienti.
Nella letteratura dell’incident management si fa spesso riferimento a due termini fondamentali: l’incidente e il workaround.
Secondo il framework ITIL, l’incidente è: “qualsiasi evento che non fa parte dell’operatività standard di un servizio e che causa, o può causare, un’interruzione e una riduzione della qualità di tale servizio”.
Per workaround invece ITIL fa piuttosto riferimento ad una: “correzione temporanea ad un incidente o una sequenza di azioni alterantiva a quella che produce l’incidente, utilizzabile dall’utente”.
L’organo a cui viene affidato il processo di service management è solitamente definito quale service desk, a cui fanno capo una serie di responsabilità ben precise, anch’esse definite nel dettaglio dal framework ITIL:
1. La registrazione degli incidenti
2. La classificazione degli incidenti ed il supporto iniziale
3. L’analisi e diagnosi dell’incidente
4. La soluzione ed il ripristino
5. La chiusura dell’incidente
6. La “ownership” dell’incidente, il monitoraggio e le relative comunicazioni
Mentre i punti da 1 a 5 sono da intendersi in maniera ciclica e sequenziale, la ownership costituisce un concetto trasversale, che si applica lungo l’intera durata del processo.
La tipologia di incidenti da gestire in azienda
Nel contesto dell’incident management, gli incidenti sono generalmente categorizzati con priorità bassa, media e alta, a seconda del loro relativo impatto:
- Gli incidenti con priorità bassa non causano interruzioni di servizio tangibili per gli utenti, che possono continuare ad effettuare le loro operazioni senza effetti penalizzanti;
- Gli incidenti con priorità media vengono avvertiti in maniera più o meno critica dagli utenti, pur senza condizionare in maniera evidente la loro operatività;
- Gli incidenti con priorità alta condizionano in maniera critica la disponibilità ed il funzionamento dei servizi necessari per garantire la corretta operatività, fino alla totale interruzione degli stessi.
A prescindere dal livello di priorità, gli incidenti vengono classificati come hardware, software o di sicurezza. Ogni service desk definisce nel dettaglio come implementare il processo di incident management e all’atto pratico la casistica degli incidenti manifesta una caratterizzazione ibrida, coinvolgendo vari elementi dell’infrastruttura IT.
A livello hardware gli incidenti più comuni sono dovuti ai guasti delle apparecchiature. A livello software a bug, malfunzionamenti, problem di configurazione e disponibilità. Infine, a livello di sicurezza, i problemi più frequenti riguardano le violazioni dei dati da parte di un’ampia casistica di minacce informatiche.
I ruoli dell’incident management
Le attività di incident management sono solitamente affidate ad uno specifico service desk. Sulla base dell’effettivo livello di responsabilità comportato dall’organizzazione, si definiscono differenti tier, a cui corrisponde un livello di supporto equivalente. Di norma ci si riferisce a tre differenti tier:
- Il tier-1 invece garantisce un livello di base nel servizio di supporto, come le operazioni utili a risolvere i problemi di natura informatica più comune, oppure assistere durante le procedure di registrazione, cambio password e controllo delle autenticazioni. In caso di incidente, il tier-1 deve pertanto si occupa di controllare l’identificare dell’incidente, il logging, la definizione del livello di priorità e la categorizzazione dell’incidente stesso.
- Il tier-2 svolge funzioni simili al tier-1 ma riesce a gestire incidenti più critici, grazie ad un superiore livello di competenze e dotazioni strumentali, riguardando molto spesso i problemi di sicurezza informatica.
- Il tier-3 è in grado di gestire anche gli incidenti più importanti, di priorità alta, che richiedono una risposta immediata, ai fini di evitare la propagazione del problema e garantire l’immediato avvio delle operazioni previste dal piano di continuità di business.
I vantaggi dell’implementazione dell’incident management in azienda
A fronte dell’investimento dovuto ad una corretta formazione ed implementazione di una strategia di incident management, le aziende possono ottenere, sia nel breve che nel lungo periodo, una serie di fondamentali benefici per garantire la propria continuità di business. Secondo il framework ITIL, essi sarebbero contestualizzabili nei seguenti punti:
• Minore impatto degli incidenti sul business a cause di una piu’ veloce risoluzione
• Identificazione proattiva di possibili miglioramenti all’infrastruttura
• Disponibilita’ di informazione significativa per poter redigere e valutare i livelli di servizio
• Migliore utilizzazione dello staff
• Eliminazione di incidenti “persi”
• Aumento della customer satisfaction
• Meno interruzioni sul lavoro sia allo staff IT che agli utenti
A tali aspetti vanno indubbiamente aggiunti quelli relativi al soddisfacimento delle normative sulla conservazione e sul trattamento dei dati (es. GDPR), a tutti i riferimenti normativi in senso ampio e a tutti gli aspetti derivanti dagli accordi di natura privatistica con i clienti.
Incident management vs incident response
Anche se vi sono evidenti sovrapposizioni di attività, incident management e incident response non sono la stessa cosa, così come i rispettivi piani servono a definire azioni e attività piuttosto differenti tra loro, sia a livello strategico, sia a livello operativo. Semplificando estremamente il concetto, l’incident response è uno dei vari elementi che compongono l’incident managent, occupandosi nello specifico della risposta agli incidenti di sicurezza informatica.
A livello gerarchico l’incident management si posiziona pertanto ad un livello superiore rispetto all’incident response e tale aspetto è facilmente percepibili osservando i rispettivi piani. Se un piano di incident management coinvolge tutti gli aspetti utili a garantire la resilienza dell’intera infrastruttura IT e dei dati aziendali, un piano di incident response mira soprattutto a definire le fasi da affrontare nel contesto dell’incidente di sicurezza informatica.
La sovrapposizione evidente è data dal fatto che, soprattutto per quanto riguarda la parte analitica, i documenti prodotti dall’incident response team risultano utili ai responsabili dell’incident management per capire come supportare il processo di miglioramento continuo necessario per garantire un’adeguata cybersecurity a livello aziendale, a livello di risorse tecnologiche, risorse umane e dei budget stimati per adempiere a tutte le azioni previste dal piano.
Un’ulteriore area di comunione tra le attività di incident management e di incident response è relativa alla formazione del personale in fatto di sicurezza informatica, nel contesto di un consapevole utilizzo delle risorse IT aziendali. Si tratta di un tema divenuto particolarmente attuale dopo la pandemia Covid-19, con la grande diffusione dello smart working, che prevede molte procedure di lavoro da remoto.
Come si può definire il processo di incident management
Anche se i framework come ITIL e COBIT consentono di implementare un processo di incident management con linee guida dettagliate, ogni organizzazione prevede una specifica declinazione strategica, che necessita a sua volta delle competenze di specialisti dotati di un comprovato know-how in questa ampia quanto complessa disciplina gestionale.
Ogni azienda, per tipologia di attività e modalità organizzative, dispone di workflow di fatto unici, che vanno analizzati in maniera dettagliata, per identificare in maniera proattiva le possibili cause di un incidente, oltre a prevede le misure necessarie per la sua mitigazione.
Tutte le attività svolte dal service desk aziendale contribuiscono a formare una documentazione utile ad investigare sulle cause degli incidenti, in modo da saperli prevenire intervenendo qualora venissero rilevate vulnerabilità o condizioni particolarmente critiche nell’infrastruttura IT.
In tale contesto emerge oltremodo l’utilità di una linea guida tracciata da un framework, come i già citati ITIL e COBIT, con l’indispensabile consulenza di specialisti in materia di incident management.
L’implementazione
Il framework ITIL v2, tra i più diffusi ed applicati nel suo settore, ci viene in aiuto per tracciare i passi essenziali nell’implementazione di un processo di incident management. Inizialmente, è prevista una fase di valutazione, entro cui si rende opportuno cercare di dare una risposta ai seguenti interrogativi:
- In azienda esiste la volontà di farlo? ITIL si riferisce soprattutto al management commitment, ossia alla consapevolezza e all’effettivo coinvolgimento dei vertici aziendali, sulla base della loro effettiva comprensione dei vantaggi derivanti da una corretta implementazione dell’incident management.
- È già attivo un service desk nell’organizzazione? In caso contrario, è già prevista una sua implementazione?
- L’azienda dispone di risorse umane interne dedicate all’incident management? Se si, sono dedicate in maniera esclusiva e questa attività o svolgono più ruoli nell’ambito dell’IT aziendale?
- I dipendenti aziendali sono adeguatamente formati per comprendere il processo di incident management e le relazioni con gli altri processi? ITIL si riferisce in particolare al concetto di process awareness.
- In azienda è diffuso un mindset volto a mettere l’utente al centro del servizio?
- L’azienda dispone di una knowledge base condivisa per la risoluzione dell’incidente? In particolare, questa è effettivamente integrata nel workflow dell’organizzazione o si manifesta quale un corpo estraneo? In che modo, con quali strumenti e con quale frequenza viene aggiornata la knowledge base relativa alla gestione degli incidenti?
- A livello tecnologico, quali sono le dotazioni utilizzate dal service desk per le attiività di incident management? Sono effettivamente commisurate a soddisfare le esigenze aziendali?
Sulla base dei risultati e delle valutazioni svolte durante la fase analitica, secondo ITIL v2 è necessario formalizzare i seguenti punti, che citiamo espressamente:
- Definire i livelli di servizio da rispettare (andrebbero negoziati con gli utenti/clienti) per ogni tipo di incidente.
- Definire le priorita’ degli incidenti in base a criteri obiettivi (matrice urgenza/impatto)
- Monitorare i livelli di servizio in maniera periodica (giornaliera o almeno settimanale)
- Formalizzare accordi con gruppi esterni qualora gli incidenti vadano scalati (OLA o Operating Level Agreement)
- Definire il ciclo di vita degli incidenti per evitare che vi siano “zone morte” in cui non si sa chi e’ responsabile.
Secondo ITIL v2, i fattori critici di successo nell’implementazione dell’Incident Management devono necessariamente comprendere:
- Un CMDB aggiornato. Se il CMDB non è aggiornato la determinazione dell’impatto e dell’urgenza della soluzione diventa molto lenta e difficile.
- Strumenti software adeguati per la gestione degli incidenti. I processi manuali/cartacei sono ragionevoli solo per implementazioni molto ridotte, ed impossibili per implementazioni che includono più gruppi di lavoro.
Infine, la knowledge base del processo di incident management dovrebbe comprendere almeno i seguenti elementi fondamentali:
- Il Known Error Database
- La lista dei problemi nell’infrastruttura
- Uno storico degli incidenti risolti nel passato
- Documentazione tecnica
- Una stretta connessione con il processo di Service Level Management per determinare le deadline per la risoluzione per ogni tipo di incidente.
Tali informazioni, oltre a costituire uno storico utile ad una strategia di miglioramento continuo del processo di incident management, costituiscono un riferimento fondamentale per l’attività di conoscenza a cui è necessariamente soggetto il service desk aziendale, soprattutto durante le fasi di onboarding dei nuovi specialisti.
