Article. What i write
Incident Management: raccomandazioni per un’implementazione ottimale
Pubblicato il 18 aprile 2024 su CyberSecurity360.it
L’urgenza di dover procedere celermente per rispondere a un incidente informatico, unita ad una scarsa esperienza in materia, ha prodotto soluzioni inadeguate, anzi spesso si è rilevata una vera e propria debacle tecnico-organizzativa. Ecco le raccomandazioni per implementare un efficace incident management.
La corretta gestione di un incidente di sicurezza è divenuta un’esigenza basilare per qualsiasi organizzazione, pubblica o privata, perché i threat actors tentano, in maniera continua e crescente, di compromettere le loro risorse critiche, spesso con effetti a cascata catastrofici.
A ciò si aggiunge l’obbligo normativo, derivante dal recepimento delle Direttive NIS “Network and Information Systems” e in capo alle infrastrutture critiche e non solo, di dover gestire i rischi e le notifiche degli incidenti informatici. A riguardo, il rapporto “IBM Cost of a Data Breach 2023” evidenzia quanto sia fondamentale disporre di un piano di risposta agli incidenti ben strutturato e testato. Infatti, in caso di attacco informatico, le aziende che non dispongano di un piano collaudato si troveranno ad affrontare l’82% in più di costi rispetto a quelle che lo abbiano implementato e testato.
Ma l’urgenza di dover procedere celermente, unita ad una scarsa esperienza in materia, ha prodotto soluzioni inadeguate, anzi spesso si è rilevata una vera e propria debacle tecnico-organizzativa.
Ecco, dunque, alcune raccomandazioni frutto delle lezioni apprese durante la gestione di alcuni incidenti informatici, utili a costituire un Computer Security Incident Response Team (CSIRT), o un Security Operation Center (SOC), in grado di implementare un efficace incident management nell’attuale panorama di minacce informatiche in continua evoluzione.
Adeguatezza delle strutture di Incident Management
Ogni organizzazione è diversa dalle altre, ciascuna caratterizzata da una serie di variabili per rappresentare la struttura, i servizi, le tecnologie utilizzate e l’organizzazione del lavoro; pertanto, non esiste una soluzione universale per costituire uno CSIRT o un SOC aziendale.Per effettuare la scelta migliore è, innanzitutto, utile comprendere la mission e i processi dell’organizzazione e, successivamente, applicare una certa flessibilità per calibrare e configurare correttamente la struttura di incident management.
A riguardo, è prioritario identificare l’ubicazione degli asset critici, i dati in essi contenuti, i rischi e le minacce a cui potrebbero essere esposti, l’impatto di un eventuale compromissione o danneggiamento di questi asset e i vincoli di mitigazione che potrebbero essere presenti.
Allo stesso modo, è indispensabile conoscere la normativa di riferimento applicabile, oltre i requisiti e i vincoli di conformità del settore.
Non esiste un modello unico di Incident Management
In alcune realtà, le strutture CSIRT dedicate all’incident management svolgono diverse attività, come la gestione degli incidenti, l’analisi delle vulnerabilità, l’analisi delle minacce informatiche e l’analisi forense.
In altre realtà, solitamene più estese, questi compiti sono svolti da unità organizzative separate che collaborano e si coordinano tra loro. In questo caso è necessario stabilire come condividere i dati di interesse e identificare chi svolge un determinato ruolo.
Lo stesso accade nell’organizzazione dei SOC: alcuni si concentrano solo sulle attività di monitoraggio e rilevamento, mentre altri svolgono anche le funzioni di risposta agli incidenti e di condivisione delle informazioni.
In sintesi, non esiste un modello standard, ma deve essere configurato per adattarsi alla realtà organizzativa esistente, evitando di duplicare o, peggio ancora, non assegnare determinate attività.
Le lessons learned sugli incidenti hanno sottolineato l’importanza di avere strutture snelle ed efficienti, in grado di reagire prontamente agli attacchi informatici; viceversa, strutture sovradimensionate e ridondanti rallentano la capacità di risposta e facilitano gli attaccanti.
L’Incident Response Team non opera da solo
L’IR team deve integrarsi con l’organizzazione e identificare gli altri componenti che svolgono un ruolo nella gestione degli incidenti, come l’IT, le strutture che si occupano della gestione delle vulnerabilità, della gestione delle patch, della gestione del rischio, della privacy, l’ufficio legale, le risorse umane e, persino, la formazione e la comunicazione con i media.
L’IR team deve identificare tutti i componenti con cui ha necessità di interagire, definire le reciprocità, compresi gli input, gli output, le modalità, i trigger, i tempi e i POC, e formalizzarle in procedure operative standard.
Quando il team rileva un incidente non può preoccuparsi degli aspetti che non riguardano la gestione dell’incidente in senso stretto, ne può occuparsi di identificare e avvisare le altre strutture dell’organizzazione. Invece, occorre procedere in maniera organizzata e coordinata per essere più reattivi ed efficaci.
Le attività devono essere formalizzate
La documentazione e la descrizione dei processi e delle procedure devono essere formalizzate per garantire la resilienza operativa nel momento in cui il personale passa ad altri ruoli.
Le organizzazioni devono disporre di un processo per gestire le informazioni apprese durante l’incident management o raccolte attraverso attività di situational awareness.
Inoltre, occorre definire i ruoli e le responsabilità del personale, le relative competenze, le conoscenze acquisite, le capacità e le abilità maturate.
Ciò determina ricadute positive prima, durante e dopo un incidente, perché consente di verificare la capacità di risposta e di apportare le dovute correzioni.
È basilare identificare gli asset critici
Il team deve sapere cosa sta proteggendo e cos’è critico. Se non venissero identificate le priorità, considererebbe tutto prioritario. Ciò comporterebbe un sovraccarico di lavoro e impedirebbe di portare a termine con successo la missione.
Si supponga, per esempio, lo scenario di un attacco multiplo o di tipo ATP (Advanced Persistent Threat) senza una prioritizzazione degli asset e, di conseguenza, delle attività di risposta.
Non è importante il nome, ma le funzioni e i servizi erogati
Ogni organizzazione assegna nomi diversi alle strutture dedicate alla gestione degli incidenti. Quelle grandi utilizzano l’acronimo CSIRT, mentre realtà più piccole adoperano i SOC (Security Operation Center) o i NOC (Network Operations Center).
Il nome dell’entità non è rilevante. L’importante è che la struttura svolga le seguenti attività obbligatorie: monitoraggio, rilevamento, triage, analisi o risposta.
A riguardo, il FIRST CSIRT Development Framework Special Interest Group (SIG) ha pubblicato un documento, il CSIRT Services Framework, per delineare i potenziali servizi che dovrebbero essere offerti dai CSIRT o dai SOC.
L’efficacia non dipende solo dalla tecnologia e dagli strumenti
La struttura di incident management deve essere customer-service oriented e sviluppare relazioni di fiducia con tutti gli stakeholders e i collaboratori sfruttando la comunicazione.
Il team di incident management necessita di personale con capacità di analisi e di risoluzione dei problemi, in grado di pensare fuori dagli schemi e di adattarsi a situazioni nuove e inaspettate in maniera calma ed equilibrata.
Il personale deve avere competenze tecniche e capacità di comunicazione efficace. Lo sviluppo delle competenze deve essere supportato da un programma di formazione, con una governance adeguata, che offra ampie opportunità di apprendimento e sviluppo professionale.
I servizi devono essere definiti in modo trasparente
Il livello di servizio fornito può avere ripercussioni sull’organizzazione e sul supporto organizzativo necessario per svolgere quel determinato servizio.
Inoltre, determina anche i tipi di impegni con i membri del team e gli stakeholder e le competenze necessarie per fornire i servizi. Chi riceve i servizi del team di incident management deve sapere quali servizi possono essere forniti e quali no.
La trasparenza consente di delineare le aspettative e stabilire le interfacce di comunicazione necessarie per diffondere le informazioni.
Il team deve essere proattivo
Inizialmente, la maggior parte dei team si concentra sulla reattività, successivamente, con la maturazione, diventano più proattivi.
Questa crescita si manifesta con l’assunzione di nuovi compiti quali la vulnerability scanning, il security assessments e l’active research volta a scoprire attività malevole/anomale e nuove minacce.
Gli approcci proattivi si sono evoluti fino a includere attività come il threat hunting, la situational awareness, la security awareness training e l’integrazione con la cyber intelligence.
L’incident response può fornire consapevolezza al resto dell’organizzazione
Le strutture dedicate all’incident response dovrebbero far parte di qualsiasi board in modo che l’organizzazione, durante la pianificazione e l’implementazione di modifiche all’infrastruttura o ai processi, sia edotta riguardo le possibili minacce alla sicurezza.
In cambio, possono utilizzare le informazioni ricevute per dare priorità alle attività di analisi e risposta.
Queste informazioni possono essere utilizzate anche per tenere aggiornato il team sui cambiamenti infrastrutturali dell’organizzazione che possono avere implicazioni per la sicurezza.
La tecnologia deve essere appropriata
Quando si deve avviare una struttura per la gestione degli incidenti informatici, la prima cosa che viene in mente è quale sia la migliore tecnologia sul mercato per la detection e la response. La risposta, ovviamente, non è semplice per due ordini di motivi: il primo è connesso alla difficoltà di selezionare il prodotto migliore in una pluralità di soluzioni per la stessa finalità, ma tra loro diverse e non comparabili; l’altra è legata al costo esorbitante delle tecnologie più avanzate e performanti che spesso confligge con un budget risicato.
La soluzione migliore consiste nel prioritizzare gli obiettivi che si vogliono raggiungere e procedere per step di acquisizione.
Il rischio di questa scelta è rappresentato dalla probabilità di ritrovarsi con prodotti eterogeni, non compatibili e con funzioni ridondanti.
Pertanto, è opportuno effettuare scelte oculate e ponderate, per acquisire la tecnologia più adatta alle proprie esigenze, diversificare ed effettuare una valutazione dei costi e benefici a livello globale.
La condivisione dei rischi e delle informazioni
Un limite riscontrato in molte organizzazioni consiste nella resistenza a condividere l’esperienza acquisita durante la gestione dei propri incidenti, i rischi calcolati, le minacce rilevate e le buone pratiche per la risoluzione.
Sono note le ricadute positive dovute all’attuazione di una prassi che contempli il risk management e l’info-sharing, fattori abilitanti per l’incident management, perché rappresentano due leve strategiche per aumentare la capacità di prevenzione e risoluzione degli incidenti informatici.
Conclusioni
Le criticità indicate hanno evidenziato che i principali problemi riscontrati non sono di natura tecnica, ma piuttosto organizzativi.
La maggiore lacuna è rappresentata dalla mancanza di comunicazione tra la direzione e il personale, tra il team di incident management e il resto dell’organizzazione.
Le altre criticità rilevate includono:
- l’assenza di policy e procedure;
- la mancanza di formazione del personale;
- la carenza di supporto e di governance da parte del management;
- la presenza di funzioni duplicate o ridondanti;
- l’assenza di una mission definita e di corrispondenti ruoli e responsabilità;
- i costi esorbitanti delle tecnologie di detection e response.
In sintesi, la costituzione di un team di incident management efficiente ed efficace richiede un approccio olistico che tenga conto degli aspetti organizzativi, tecnici, giuridici, comunicativi e finanziari.