Nell’ambito del business, l’espressione “incident response” è sinonimo di capacità di ripristino totale dei processi operativi a seguito di un incidente informatico. Minori sono i tempi di recupero e le perdite di dati, maggiori sono le chance di consentire all’organizzazione di non accusare il colpo causato da un attacco esterno o da un disservizio di sistema.
Questo, in determinati settori, potrebbe voler dire evitare di bruciare milioni di fatturato, senza contare l’impatto dei danni sul piano reputazionale.
Cosa occorre per rimettere in sesto network e applicazioni nel minor lasso di tempo possibile? Che competenze bisogna sviluppare e quali best practice conviene adottare per assicurare che persone e strumenti lavorino correttamente, e in modo sinergico, al rapido e pieno ripristino dell’operatività? Ci risponde Roberto Veca, Head of Cyber Security di Cyberoo.
Indice degli argomenti
Le competenze da sviluppare per gestire correttamente un incidente
“Prima di ogni altra cosa è bene sottolineare che quando parliamo di incident response entriamo in un ambito caratterizzato da dimensioni estremamente verticalizzate, per le quali occorrono competenze più che specialistiche: chirurgiche direi” avverte Veca.
“Mi spiego meglio con un esempio. Neurochirurgo e cardiochirurgo sono entrambi medici in grado di lavorare in sala operatoria con enorme precisione, ma uno non potrebbe affrontare il campo dell’altro con la stessa efficacia, proprio perché le competenze sviluppate dai professionisti sono separate e altamente specializzate. Ecco, nel mondo della cybersecurity, e in particolare per quello che concerne l’incident response, la situazione è più o meno la stessa. Serve un profilo informatico capace di evolversi in un vero e proprio cyber specialist con competenze verticali”.
Questo per Veca significa essere al tempo stesso un sistemista e un networker di talento, in grado cioè di analizzare tutte le anomalie o le possibili vulnerabilità della rete per renderla il più possibile persistente rispetto alla catena del business.
“È necessario possedere, ovviamente, un background IT su cui vanno innestate skill più tecniche, conoscenze che permettano di condurre analisi forensi, mapping della memoria volatile e tutte le operazioni indispensabili per identificare le chiavi di registro che potrebbero risultare propedeuticamente utili a un eventuale attaccante. A queste bisogna aggiungere la capacità di mettere al servizio del sistema tecniche di eradication, nonché di contenimento”.
In altre parole, il professionista in grado di ottimizzare l’incident response management sa fin dove si estendono perimetri e potenziali superfici d’attacco aziendali. Riesce a capire tempestivamente che tipo di tattica sta sfruttando l’attaccante e soprattutto quali mosse occorrono per contenere gli effetti dell’incidente senza staccare tutti i sistemi.
“Attenzione: con questo non intendo che si debba conoscere perfettamente l’intera rete.. Per proteggere i processi, bisogna piuttosto essere capaci di individuare gli elementi utili a circostanziarli”, dice Veca, che suggerisce due strade. “La prima è identificare gli interlocutori aziendali più competenti, e chiedere loro una spiegazione approfondita sulle dinamiche del network. Questo approccio accelera notevolmente la fase esplorativa. Quando non è possibile, consiglio di ricorrere a strumenti di mappatura che aiutano a definire problematiche specifiche. Aggiungo che adottare una prospettiva esterna, rivolgendosi per esempio a consulenti con skill certificate, consente non solo di mettere a nudo aspetti che tendono a rimanere nascosti nelle analisi interne, ma anche di sviluppare ex novo metodi, tecniche e procedure per studiarli ed elaborare strategie di incident response ad hoc”.
L’outsourcing, però, in molti casi è una necessità. “La figura dell’incident responder è, quanto meno, abbastanza difficile da trovare. Non solo bisogna accaparrarsi, come abbiamo visto, dei semi-guru, bisogna anche garantire una disponibilità H24, creando un team con una struttura ridondante. Torna qui di nuovo utile il paragone col neurochirurgo: la continua reperibilità non deve trasformarsi in un carico di lavoro eccessivo, altrimenti il medico (così come l’esperto di cybersecurity) arriva stanco al momento determinante e rischia di fare danni, anziché salvare persone (o aziende)”.
Le migliori best practice per un incident response management ottimizzato
Per ripristinare l’operatività in modo corretto, a competenze comprovate vanno aggiunte anche best practice consolidate. “La primissima – che può sembrare ovvia ma i fatti ci dicono che non lo è – consiste nel rivolgersi agli specialisti” precisa Veca. “Per esperienza diretta con i clienti, posso dire che nel 99% dei casi tentare di gestire l’incident response in proprio non solo si traduce in pratiche inefficaci, ma genera ulteriori problemi sul piano del management.
Si rischia di perdere tempo prezioso ricercando soluzioni che poi non sortiscono alcun effetto e di ignorare evidenze necessarie a capire se, per esempio, gli attaccanti sono ancora dentro il sistema, con impatti significativi sul business. C’è anche chi cerca di recuperare backup senza prima aver compreso dove e quando sono entrati gli attaccanti, e senza fare azioni di eradication. Il che permette agli intrusi di venire a sapere dell’esistenza di uno strumento di ripristino, e di ripartire con un attacco ancora più pervasivo, visto che le carte sono state scoperte”.
Un’altra best practice ancora troppo sottovalutata è quella relativa alla creazione di un piano di disaster recovery. “Anche noi esperti siamo decisamente avvantaggiati se il cliente ne ha predisposto uno” nota Veca. “Mi riferisco a un piano che affronti nella sua interezza il tema della business continuity, coprendo quindi anche l’eventualità di un incidente, naturale o premeditato che sia. In quest’ottica, l’incidente response è già predisposto in anticipo, con step già stabiliti dal cliente. Questo permette di intervenire nell’immediato e di risparmiare tempo prezioso”.
Cosa succede se il piano c’è ma non è stato sviluppato in modo corretto? “È un altro aspetto che si può scoprire solo sottoponendo il progetto a un team di specialisti. Anzi, direi che è la prima cosa che va condivisa, in modo da individuare per tempo eventuali anomalie e risolverle, se possibile, in corsa. È capitato anche di provare a seguire piani sviluppati internamente e rivelatisi poi sbagliati perché non applicabili ai contesti specifici, ed è sempre convenuto, a quel punto, ignorarli del tutto”.
Anche rispetto alle operazioni di ripristino vero e proprio, Veca consiglia di non agire mai in totale autonomia, a meno che in azienda non ci sia per l’appunto un team di incident response strutturato. “Lo dico perché per essere certi che il ripristino avvenga davvero in sicurezza è necessario creare un canale di comunicazione provvisorio parallelo, verso l’interno, verso l’esterno e tra i sistemi, sfruttando appliance ad hoc che migrino il traffico verso connettori dotati di crismi di security elevati: penso per esempio a un Network Intrusion Detection System, o a uno strumento di Web filtering, magari integrati con soluzioni MDR (Managed Detection and Response, ndr) o, in altri contesti, con un EDR (Endpoint Detection and Response, ndr). In pratica – specifica Veca – si dà vita a una blackbox carica di sistemi protezione attraverso cui i flussi di dati passano letteralmente al setaccio. In questo modo, nel caso in cui l’attaccante sia ancora presente nel sistema sarà possibile rilevarlo e rimuoverlo definitivamente. L’idea di base è quella di analizzare nel dettaglio l’infrastruttura compromessa e creare connessioni sicure, riabilitando le comunicazioni esclusivamente con traffico legittimo”.
Contributo editoriale sviluppato in collaborazione con Cyberoo
