Incident response, cos’è e come funziona passo per passo: ecco cosa fare

Nel panorama aziendale moderno abbiamo assistito ad un aumento della superficie di attacco a disposizione dei malintenzionati, dovuta all’aumento delle soluzioni digitali nelle aziende: questa circostanza non può essere ignorata o sottovalutata e pertanto le aziende devono essere pronte a rispondere agli attacchi impostando un efficace piano di incident response.

Per prevenire le minacce cyber è importante avere una struttura difensiva adeguata, dotata sia delle più moderne ed efficienti apparecchiature, costantemente aggiornate, sia dei più avanzati sistemi anti cracker, sia del personale istruito, addestrato e qualificato, pronto ad usare i suddetti strumenti per bloccare sul nascere le iniziative dei malintenzionati.

Come in ogni settore lavorativo, quindi, la sola componente proattiva non è sufficiente; i security incident possono verificarsi anche nella più corazzata delle strutture e quindi avere una divisione adibita al comportamento “reattivo” è ugualmente importante.

L’incident response, cioè la risposta agli incidenti, è dunque un processo fondamentale all’interno di tale contesto e per tale motivo avere un team di persone adibite a questo scopo, opportunamente formate e dotate degli strumenti adeguati, è di vitale importanza per le aziende.

Tali elementi sono essenziali poiché un ambiente adeguatamente preparato avrà la necessaria forza per reggere l’impatto derivante da eventuali eventi avversi in ambito cyber.

Struttura dei team di incident response e criteri di scelta

Il National Institute of Standard and Technology – NIST, definisce l’Incident Response nel seguente modo: “L’incident response è un processo strutturato che le organizzazioni utilizzano per identificare e gestire gli incidenti di sicurezza informatica. La risposta comprende diverse fasi, tra cui la preparazione agli incidenti, il rilevamento e l’analisi di un incidente di sicurezza, il contenimento, l’eradicazione e il recupero completo, nonché l’analisi e l’apprendimento post-incidente”.

Nell’esame della definizione sono tre le caratteristiche che dovrebbero balzare all’occhio di un attento osservatore, ossia:

1. la risposta agli incidenti non è un processo semplice né breve, ma composto da molteplici passaggi che già presi singolarmente sono importanti, nel momento in cui vengono combinati insieme lo diventano ancora di più;
2. tale procedura non si limita al momento in cui l’incidente accade, poiché cura anche il dopo, in quanto cerca di capire come mai l’incidente sia stato possibile e come si possa procedere per evitare che riaccada in futuro;
3. dai punti precedenti si evince che non ci si può improvvisare Incident Responder e che un team adeguato a tale mansione deve essere formato, addestrato e messo in grado di operare con efficienza; ciò comporta sicuramente un costo per le ditte che però è bene sostenere in quanto spendere una determinata cifra prima è propedeutico a non sostenere un esborso molto più grande dopo.

Stabilito ciò, è opportuno esaminare come sono fatti i team che si occupano di incident responding. Ci sono tre possibili modi di organizzare una squadra di incident responder:

1. Central: il modello più semplice, dove tutti gli incidenti sono gestiti da una singolo team. De facto è il modello standard pe le piccole imprese con poca, o nulla, diversificazione geografica in termini di infrastrutture e risorse IT.
2. Distribuited: non uno, ma molteplici team gestiscono gli incidenti. Ogni squadra è responsabile per gli incidenti o di uno specifico segmento fisico o logico della struttura ed ha un responsabile che ne coordina le attività. Questo modello è efficace per le grandi organizzazioni e per quelle con importanti risorse dislocate in luoghi distanti tra loro (ad esempio, una squadra per regione geografica, oppure una per struttura principale). Tuttavia, i teams dovrebbero far parte di un’unica entità coordinata in modo che il processo di risposta agli incidenti sia coerente all’interno dell’organizzazione e le informazioni siano condivise tra loro. Ciò è particolarmente importante perché più squadre possono vedere componenti dello stesso incidente o potrebbe gestire incidenti simili.
3. Coordinated: un team di risposta agli incidenti fornisce consulenza ad altre squadre senza avere l’autorità su di loro, ad esempio una squadra di tutto il dipartimento può assistere quelle delle singole agenzie. Questo modello può essere pensato come un CSIRT per CSIRT.

Detto questo, un altro fattore da decidere è come devono essere inquadrati i membri componenti rispetto all’azienda che usufruisce del servizio, ossia:

• Employees: i membri del team di Incident Response sono tutti impiegati della ditta;
• Partially Outsourced: il servizio è in parte gestito con il personale proprio della ditta, mentre la rimanente è presa in carico da un’azienda esterna;
• Fully Outsorced: la ditta usufruisce del servizio senza fornire personale, cioè la gestione del processo è completamente in carico ad un’azienda esterna.

Sottolineiamo ora un elemento molto importante: il fatto di avere una piccola ditta o meno, di possedere un ambiente geograficamente variegato o no costituiscono soltanto alcuni elementi da considerare quando si sceglie il modello di team più adatto alle proprie esigenze.

Il NIST, infatti, definisce anche una serie di domande che occorre porsi per fare la scelta migliore possibile, ossia:

• Avviabilità 24/7: è necessario avere un supporto costante, senza interruzioni? Un team che lavori in tale contesto rappresenta la scelta migliore per avere una copertura continua, anche perché più tempo passa dall’inizio dell’attacco al suo rilevamento ed alla successiva interruzione e maggiori saranno stati i danni causati. Tuttavia, in un simile scenario è necessario avere de facto operatori in loco senza interruzioni del servizio, con una comunicazione in tempo reale con tutti gli attori coinvolti nel processo, cliente finale incluso.
• Personale full time o part time: il fattore decisivo sotto questo punto di vista è l’aspetto economico. Il vantaggio del personale part time è infatti quello di non dover pagare risorse che si occupano in via esclusiva di questa mansione, delegando il compito ad altre strutture che all’occorrenza eseguono le varie parti del processo. A esempio, l’IT Help Desk può svolgere il compito di analisi di primo livello dell’incidente e fornire in output l’analisi al personale L2, tornando quindi ai suoi compiti usuali. Chiaramente, ciò è applicabile soprattutto alle realtà più piccole con esigenze più contenute rispetto ad altre.
• Staff Expertise: come già evidenziato, per svolgere tale compito occorrono delle specifiche competenze e spesso il vantaggio nell’impiego di personale in outsourcing è che i membri costituenti sono opportunamente formati ed addestrati per quanto riguarda tutti gli aspetti tecnici: conoscenza dei protocolli, degli strumenti di rilevamento delle intrusioni, delle tecniche di attacco dei criminali; inoltre posseggono capacità di correlazione che permettono di scovare nuove minacce più velocemente del personale interno della ditta. D’altro canto, però, il personale IT della ditta conosce meglio l’environment informatico ed i suoi meccanismi, essendo quindi avvantaggiato nel rilevamento dei falsi positivi.
• Costo: è ovvio che un tale servizio richieda di sostenere dei costi, potenzialmente anche notevoli, quindi la valutazione dell’h24 o meno e del personale altamente qualificato esterno o la formazione di quello interno è pesantemente influenzata da tali fattori.

Organizzazione e fasi dell’incident responding

L’organizzazione delle unità adibite al servizio di Incident Response non si limita a decidere se usare uno o più team ed alle considerazioni economiche del caso; è necessario stabilire delle procedure ad hoc che permettano in primis di avere delle linee guida a cui attenersi e da queste estrapolare dei passaggi precisi.

Possiamo definire, stando alle linee guida del NIST, le linee guida come l’organizzazione, mentre i passaggi sono le fasi del processo. L’organizzazione stabilisce le seguenti linee guida:

• Stabilire una capacity formale di risposta agli incidenti: indipendentemente dal modello di team scelto, non si può abbozzare in modo vago e impreciso come questo sia organizzato. Anche nel caso di uno/pochi team e di personale part time, è necessario stabilire con chiarezza chi detiene determinate autorità al suo interno e per ogni membro quali sono le responsabilità.
• Definire le Policy: stabiliti ruoli e responsabilità occorre definire con precisione cosa è considerato incidente di sicurezza, quali sono i requisiti per generare una segnalazione e di quale documentazione occorre avvalersi nell’espletamento delle mansioni.
• Delineare un Incident Response Plan: secondo la metodologia NIST, un piano di risposta agli incidenti non è semplicemente un elenco di passaggi da eseguire quando si verifica un incidente. È una tabella di marcia per il programma di risposta agli incidenti dell’organizzazione, inclusi obiettivi a breve e lungo termine, metriche per misurare il successo, formazione e requisiti di lavoro per i ruoli di risposta agli incidenti.
• Sviluppare una Incident Response Procedure: questi sono i passaggi dettagliati che i team di risposta useranno per rispondere a un incidente. Dovrebbero basarsi sulle Policy e sull’ Incident Response Plan; inoltre dovrebbero affrontare tutte e quattro le fasi del ciclo di vita della risposta agli incidenti.

L’ultimo punto dell’organizzazione ha anticipato quante sono le fasi, ossia quattro, che in realtà sono state esposte già nella definizione. Esse sono così definite:

1. Preparazione: stabilire quali sono gli assets dell’azienda che potrebbero essere sottoposti ad attacco e quindi vittime di incidenti. Che valore hanno? Quale la priorità tra questi? Sono sottoposti ad adeguato monitoraggio tramite gli strumenti opportuni? In caso di necessità di ripristino, esiste la strumentazione adeguata, sia essa hardware (come uno storage di backup), software (ad esempio, ISO image)? In caso di effettiva compromissione, la comunicazione tra i vari reparti ed attori coinvolti è garantita essere stabile, tempestiva e sicura, cioè riservata solo a colore che devono essere resi partecipi? In questa fase inoltre è necessario accertarsi che tutto il necessario pe prevenire il verificarsi di incidenti sia stato fatto: la struttura ha adeguati hardware e software di sicurezza? Le policy di monitoraggio ed accesso ai sistemi sono conformi agli standard del settore ed aggiornate? Un check regolare viene eseguito con continuità?
2. Rilevazione ed analisi: la rilevazione concerne lo studio dei precursori e degli Un precursore è un evento notificante che, pur non essendo ancora avvenuto, un attacco potrebbe accadere nel nostro enviroment: ciò avviene identificando i possibili vettori d’attacco. Ad esempio, se si autorizza l’uso di device provenienti dall’esterno, come le penne USB personali dei dipendenti, queste potrebbero essere – anche a loro insaputa – veicoli di malware e software vari in grado di compromettere gli assets. Oppure, consultando l’elenco delle CVE pubblicate dagli opportuni organi si può venire a conoscenza che l’attuale versione di un software in uso nella ditta è passibile di compromissione e quindi si rende necessario aggiornarlo ad una versione patchata. Gli indicatori invece indicano che un attacco è già in corso e devono essere pertanto costantemente monitorati in quanto sono i “sintomi” che qualcosa non va. Il loro esame può ad esempio tramite opportuna strumentazione, come ad esempio un SIEM. L’analisi implica l’identificazione di una linea di base o attività normale per i sistemi interessati, correlando gli eventi e vedendo se e come si discostano dal comportamento normale. Rilevato un effettivo incidente, sarà necessario redigere un documento che notifichi il suddetto e lo illustri nel modo più dettagliato e preciso possibile: solo con una chiara e precisa illustrazione di quanto accaduto infatti sarà possibile prendere le dovute contromisure. In questa fase è molto importante effettuare lo studio del caso nel più preciso ed accurato dei modi; ciò perché l’errore umano, sommato ai limiti degli strumenti stessi – come un falso positivo – possono rendere impreciso e/o incompleto il rilevamento della falla, con seguenti misure di contenimento e ripristino non sufficienti, in quanto la minaccia non sarà completamente eradicata e potrà riproporsi.
3. Contenimento, Eradicazione e Ripristino: per contenimento s’intende il fermare l’attacco prima che travolga le risorse o causi danni. La strategia da adottare dipenderà dal danno che l’incidente può causare, dalla necessità di mantenere servizi critici disponibili per dipendenti e clienti e dalla durata della soluzione: temporanea per alcune ore, giorni o settimane oppure permanente. Inoltre, è molto importante comprendere che le strategie di contenimento non sono universali; se per esempio si rileva un host compromesso, non necessariamente disconnetterlo dalla rete rappresenta una scelta adeguata, in quanto la suddetta mossa potrebbe far scattare un meccanismo malevolo di cifratura dei dati ivi presenti. Ciò significa che avere un quadro completo della situazione, ossia l’identikit della vittima, dell’attacco e dei danni che sta producendo è vitale per evitare di peggiorare la situazione con rimedi sbagliati. L’eradicazione consiste invece nel passaggio successivo al contenimento; bloccata la propagazione del danno, va eliminata la fonte, la radice del problema: per esempio, se un virus ha iniziato a cifrare i dati presenti su di un host, in caso di contenimento avvenuto con successo, l’eradicazione si occupa di stanarlo e distruggerlo, insieme a tutte le eventuali copie di sé stesso prodotte. Infine, il ripristino consiste nel riportare le macchina ad un funzionamento normale, ossia in linea con le aspettative; possibilmente si vorrebbe anche che esse siano hardenizzate di modo tale da evitare che la situazione si ripresenti.
4. Attività Post Incidente: la lezione che è stata appresa. Perché l’incidente si è verificato? Cosa si può fare per evitare che in futuro si ripresenti o se ne verifichino di simili? Durante l’evento critico, la prassi seguita è stata ben svolta? Era sufficiente? In caso negativo, cosa non è stato opportuno? Questa fase, dunque, è l’analisi di tutto il decorso, dall’inizio alla fine, per capire come migliorare il contesto e rendere più sicura la struttura e, conseguentemente, dura la vita ai pirati.

Competenze dell’incident responder

Definito con maggiore chiarezza il processo, è opportuno delineare meglio la figura dell’operatore.

Come in ogni lavoro, un candidato deve essere valutato alla luce sia delle hard che delle soft skills; spesso si commette l’errore di valutare soprattutto, se non in maniera quasi esclusiva, le prime a scapito delle seconde ma ciò rappresenta un grave errore.

Si pensi per un attimo a cosa di preciso deve fare un incident responder: è la prima linea quando un sistema, una parte della rete aziendale o addirittura tutto l’environment sono stato compromessi. Un po’ come i pompieri che sono il primo “nemico” di un incendio che si propaga. In un simile scenario, si possono possedere tutte le skills tecniche del mondo ma saranno inutili se non affiancate da una precisa forma mentis e caratteristiche psicologiche tali da garantire una reazione pronta, decisa e sicura; ma procediamo con ordine.

Le mansioni di un incident responder possono essere riassunte in questa lista, non esaustiva ma sufficientemente rappresentante le suddette:

• monitorare attivamente i sistemi e le reti per scovare eventuali intrusioni;
• identificare le falle di sicurezza e le vulnerabilità;
• eseguire audit di sicurezza, analisi dei rischi, analisi forensi della rete e penetration test;
• eseguire analisi di malware e reverse engineering;
• sviluppare una serie procedurale di risposte a problemi di sicurezza;
• stabilire protocolli di comunicazione all’interno di un’organizzazione e rapporti con le forze dell’ordine durante incidenti di sicurezza;
• creare un piano di sviluppo del programma che includa valutazioni del gap di sicurezza, politiche, procedure, documenti, formazione e test di verifica;
• produrre report dettagliati sugli incidenti e brief tecnici per dirigenti, amministratori e utenti finali;
• collegamento ed interazione con altre entità di analisi delle minacce informatiche.

Queste mansioni richiedono un background, sia accademico che lavorativo, ben preciso e strutturato.

Ovviamente ogni profilo è una storia a se stante, ma in generale si può considerare che una Laurea in informatica, matematica e/o discipline affini è sicuramente utile, sebbene non richiesta strettamente; esserne in possesso tuttavia permette l’accesso a Master universitari di livello superiore, come quello in Assurance or Information Security.

Per quanto riguarda invece le hard skills, esse sono molteplici e variano in base al ruolo che si dovrà ricoprire all’interno del team ma, volendo fornire un sommario, sarà sicuramente utile possedere conoscenze relative alla configurazione, gestione e manutenzione dei principali OS, dei linguaggi di programmazione principalmente usati in ambito security come Ruby, Python, C, C++, Perl ed ASM; reti e relativi protocolli, incluse le metodologie di patching; strumenti di monitoraggio e tecniche di rilevamento delle vulnerabilità, come i vari SIEM e scanner NESSUS like; conoscenze da penetration tester, in modo a capire come l’avversario ragiona e dove potrebbe andare a colpire; in ultimo, il cloud e tutte le tematiche correlate.

In termini di anzianità, il membro tipo ha maturato almeno due o tre anni di esperienza nel campo della security ma ovviamente questo non è un requisito scolpito nella “roccia”.

Inoltre, il possesso di alcune certificazioni è sicuramente un ottimo surplus: tra gli enti che le mettono a disposizione esempi molto validi sono l’Ecouncil oppure la eLearnSecurity o ancora la Offensive Security, per citarne alcune.

Ultimo ma non meno importante, anzi forse più importante in base a quanto prima esposto, è l’insieme delle soft skills che sono richieste ad un incident responder.

Questo può essere un lavoro stressante e pieno di pressione. I “nemici” non conoscono tregua: i loro attacchi possono arrivare in qualsiasi momento della giornata, in qualsiasi giorno dell’anno.

Festività e periodi di ferie, come l’estate, non hanno significato per loro; al contrario, nella maggior parte dei casi sono il momento principale in cui colpiscono, poiché le difese potrebbero essere abbassate.

Ciò implica che un aspirante incident responder debba essere flessibile, adattabile e concreto; paura, insicurezza e procrastinazione non sono assolutamente ammesse. Oltre al già citato paragone del vigile del fuoco, un incident responder può essere comparato ad un medico del pronto soccorso a cui arriva un codice rosso: sangue freddo e lucidità mentale in ogni contesto, anche nel più critico e stressante sono requisiti indispensabili, senza i quali si possono conoscere anche manuali e procedure a memoria ma i risultati non saranno ottenuti.

Oltre alla componente psicologica, è necessario esaminare anche le skills che potremmo definire di “contorno”, a sostegno di quelle prettamente tecniche.

Gli incident responder fungono da investigatori, quindi capacità analitiche e di problem solving sono un must have. Per capire se si è adatti, occorre chiedersi: so scrivere in modo chiaro e conciso? So come parlare in una stanza piena di colleghi e dirigenti non tecnici? Le grandi capacità orali e comunicative sono un notevole vantaggio da non sottovalutare, soprattutto perché occorre considerare che si potrebbe dover resocontare il proprio operato a personale non tecnico/non specializzato, quindi la capacità di condivisione con un pubblico vasto ed eterogeneo è un elemento molto importante.

Conclusione

L’incident response è un macro-processo importantissimo, del quale oggi è impossibile fare a meno; ciò perché un enviroment realmente sicuro al 100% ed impenetrabile non esiste.

La falla critica è sempre dietro l’angolo: errori di progettazione, di configurazione, d’implementazione; vulnerabilità 0 day; spesso, se non soprattutto, errori degli utenti che riescono ad annullare tutte le misure e precauzioni prese a livello IT.

Occorre mettere in conto quindi che l’inviolabilità è un’utopia e pertanto è necessario essere sempre pronti a correre ai ripari, perché in caso contrario gli effetti saranno deleteri: non solo si rischia che un sistema compromesso persista in un tale stato per tempi inaccettabili, ma gli asset aziendali potrebbero diventare la tana di minacce persistenti o, in alternativa, i preziosi dati ivi presenti potrebbero non essere più disponibili per i legittimi utenti.

Come ogni processo legato al mondo della cyber security, anche l’incident response deve scontrarsi con un problema tristemente diffuso: la questione economica.

Spesso si pensa che “il problema non si verificherà, non abbiamo budget anche per questo” ma un investimento in tal senso non può che essere vantaggioso, poiché per quanto oneroso sarà sempre più economico dell’esborso al quale si è costretti in caso di breach.

Leggerezza non deve essere commessa nemmeno quando, superato l’ostacolo del “non serve”, si esaminano i team a cui ci si affida; come già esposto, non ci si improvvisa incident responder dall’oggi al domani.

Una forte motivazione, una capacità di autocontrollo mista ad un solido bagaglio tecnico e la consapevolezza che mai si smette d’imparare, in quanto le minacce evolvono e con loro gli attaccanti, sono doti fondamentali per chi intende intraprendere questa carriera.

Al contempo, il datore di lavoro deve essere consapevole che lo scenario nel quale andrà ad inserire il suo team di “primo soccorso” è faticoso, stancante e non semplice; questo significa che sebbene il candidato tipo debba tassativamente possedere dei requisiti essenziali, tenerne alto l’interesse, l’attenzione, ravvivare costantemente la sua passione per quello che fa è essenziale.

Il buon lavoro svolto dal team di incident response deve essere riconosciuto e premiato, in quanto in caso contrario l’effetto sarà lo stesso di avere un “guardiano” frustrato e demotivato, ossia un sorvegliante che abbassa il livello d’attenzione; del resto, quando si prende un cane da guardia, ciò non implica di certo che lo si confini sempre e costantemente nel giardino di casa senza dargli le attenzioni che merita, no?