8 lezioni che i CISO hanno imparato dagli incidenti informatici

Quando si verifica un incidente informatico, non si tratta soltanto di un evento grave di per sé. Per molti CISO, è molto di più, arrivando a ridefinire il loro approccio alla resilienza, alla gestione dei rischi e persino al loro benessere personale sul lavoro.

In questo articolo, diversi responsabili della sicurezza in azienda riflettono su quanto hanno appreso da incidenti reali e sul motivo per cui è fondamentale condividere con la comunità per rafforzare la resilienza collettiva, abbattere lo stigma che circonda le violazioni e aiutare altri che potrebbero trovarsi ad affrontare un incidente.

1. Condividere le conoscenze acquisite e migliorare la sicurezza per tutti

I CISO che si trovano nell’occhio del ciclone devono aspettarsi i riflettori dei media e delle persone che intervengono sull’incidente.

“Si ottiene l’attenzione del mondo molto rapidamente”, osserva Tim Brown, CISO di Solarwinds.

E non tutti hanno buone intenzioni, poiché alcuni commentatori utilizzano un incidente per promuovere i propri interessi, che si tratti di aumentare la propria visibilità, parlare male di un’altra azienda o, semplicemente, finire sui giornali.

D’altra parte, secondo Brown, certe situazioni offrono un’opportunità per contribuire all’intero settore, poiché attirano l’attenzione di persone di ogni tipo, anche particolarmente competenti.

Ci possono essere considerazioni legali, aziendali e normative su ciò che è possibile condividere. Tuttavia, in termini di strategia tecnica, ci sono probabilmente aspetti che vale la pena condividere.

Brown ritiene che, spesso, dalle violazioni si possano trarre lezioni importanti, sia che si tratti di casi di alto profilo che finiscono nei libri di testo e nei corsi universitari, sia che si tratti di esperienze che possono essere condivise tra colleghi attraverso conferenze e altri eventi. “Cercate sempre di trarre qualcosa di buono dagli eventi. Come potete aiutare il settore ad andare avanti? Potete aiutare la comunità dei CISO?”, avverte.

Todd Thorsen, CISO di CrashPlan, concorda sul fatto che partecipare a un incidente offre lezioni tattiche. A volte, è la prova perfetta di ciò che non dovrebbe accadere, sottolinea Thorsen, che faceva parte del team di sicurezza informatica durante il Target data breach [in inglese], nel 2013.

Il suo approccio consiste nel condurre analisi post mortem senza attribuire colpe per comprendere le cause alla radice, creare un ambiente sicuro per una discussione aperta e identificare cosa si sarebbe potuto fare meglio. L’obiettivo è analizzare i processi senza timore di ripercussioni. Incoraggia gli addetti alla sicurezza a condividere le conoscenze acquisite con la comunità perché “alla fine tutti combattono le stesse battaglie”.

Condividere le proprie conoscenze è anche un modo importante per costruire reti di supporto all’interno della comunità più ampia e restituire il favore, perché potrebbe arrivare un momento in cui sarà necessario rivolgersi ai propri colleghi. “Non si può mai sapere quando potrebbe essere necessario ‘attingere’ alla comunità in futuro”, afferma Thorsen.

2. Dalla difesa all’attacco

Il CISO – e il suo ruolo – non saranno più gli stessi dopo un incidente.

“Il mio lavoro l’11 dicembre era molto diverso da quello del 12 dicembre e dei giorni successivi”, afferma Brown.

A seguito di un incidente, alcune aziende devono cambiare a tal punto da richiedere un Chief Information Security Officer diverso con un diverso  approccio. Secondo Brown, il CISO non viene sempre licenziato perché incompetente o perché si ritiene che la colpa sia sua. Molto dipende dalla situazione e dalla sua capacità di adattamento.

“Se si desidera diventare un CISO post-incidente, è necessario possedere le competenze necessarie, che sono molto diverse da quelle richieste il giorno prima”, afferma Brown.

Molti CISO esperti in incidenti cambieranno il loro approccio e la loro mentalità dopo aver vissuto in prima persona un attacco. “Svilupperete una prospettiva orientata all’attacco, in cui vorrete comprendere il vostro terreno offensivo meglio del vostro avversario e applicare le vostre risorse di conseguenza per proteggervi dai rischi”, dice Cory Michel, vice president per la sicurezza l’IT di AppOmni, che ha fatto parte di diversi team di risposta agli incidenti.

In pratica, passare dalla difesa all’attacco significa prepararsi a diversi tipi di incidenti, che si tratti di abuso della piattaforma, sfruttamento o APT, e adattare le risposte.

Michel include esercitazioni con il red team [in inglese] e simulazioni dal vivo nella strategia offensiva. Significa anche fare periodicamente un passo indietro, ricominciare da capo e mettere in discussione l’approccio alla sicurezza attuale per individuare lacune e punti deboli. I CISO in carica “possono diventare ciechi rispetto alla situazione attuale perché sono troppo immersi nei dettagli”, riflette Michel.

3. Un manuale tattico per la gestione degli incidenti

Gli incidenti ricordano che è necessario disporre di un piano di risposta [in inglese] ben collaudato che dovrebbe designare un coordinatore interno forte, con la possibilità di avvalersi di competenze esterne, come consulenti in materia di violazioni e a carattere legale.

“È necessario disporre di persone di riferimento che parlino con la stampa, si mettano in contatto con la compagnia di assicurazione, avviino le indagini se non è possibile ripristinare i dati e sappiano come comunicare con gli autori dell’attacco in merito al riscatto”, dichiara Steve Tcherchian, CISO di XYPRO.

Senza ruoli e responsabilità chiari, il panico si diffonde molto rapidamente, ha scoperto Tcherchian. “La prima reazione è: ‘Cosa facciamo? Chi è responsabile? Chi chiamiamo? Chi coinvolgiamo? Chi non coinvolgiamo?’”, racconta Tcherchian, che ha ricoperto il ruolo di consulente in seguito ad attacchi ransomware.

Il playbook deve fornire indicazioni chiare sulla comunicazione, durante e dopo un incidente, perché questo aspetto può essere trascurato mentre si affronta la crisi, ma alla fine può determinare l’impatto duraturo di una violazione che diventa di dominio pubblico.

 “Durante una crisi, ogni parola è importante”, sostiene Brown. “Ciò che si pubblica, ciò che si dice, come lo si dice. Quindi è fondamentale essere preparati”.

Il playbook deve anche delineare il punto finale in modo da poter decidere quando chiudere l’indagine. “Una delle parti più difficili della gestione di un incidente informatico è sapere quando interrompere le indagini”, chiarisce George Gerchow, docente presso IANS Research e CSO di Bedrock Security.

Se ci sono team numerosi che indagano sull’incidente, è probabile che inizino a scoprire altre cose, ma se si perdono in dettagli inutili, possono distrarre e ritardare la risoluzione del problema.

I CISO devono accettare che alcune porte possano rimanere aperte, ma se si tratta di rischi minori, è importante non perdere di vista l’incidente. “La chiave è concentrarsi su ciò che si conosce, essere trasparenti e chiudere la vicenda, con l’obiettivo primario di determinare se i dati sono stati sottratti”, afferma Gerchow, che ha vissuto molti casi nella sua posizione a SumoLogic e MongoDB.

4. Trascurare backup robusti e monitorati a proprio rischio e pericolo

Se si verifica un incidente che compromette i dati, avere backup non protetti o inadeguati può essere una svista costosa. Quando ciò si è verificato, i CISO hanno imparato a proprie spese a non dare mai per scontato che i sistemi di backup siano sicuri e perfettamente funzionanti.

“Molti attacchi ransomware oggi prendono di mira prima i backup, prima di fare qualsiasi altra cosa. Prendono di mira la posizione di ripristino, i punti di ripristino, i supporti di backup. Si assicurano di disabilitare la possibilità di ripristinare i dati ed evitare di pagare il riscatto”, precisa Tcherchian.

Anche se si decide di pagare il riscatto, non vi è alcuna garanzia che l’azienda recuperi i dati e questo sottolinea la necessità di garantire che i backup siano isolati e funzionanti.

Tcherchian raccomanda di testare e verificare regolarmente che i sistemi di backup funzionino e siano puliti. “Potrebbe esserci una vulnerabilità o un payload dannoso nella rete, che potrebbe rimanere lì per 30, 60 giorni, il che significa che viene copiato costantemente nei backup”, afferma. “Se si pensa di essere stati attaccati, si ripristinerà dal backup e tutto ciò che si otterrà sarà reintrodurre il virus o il malware nell’ambiente”.

5. Alzare il livello di sicurezza

Dopo un incidente, è probabile che si veda la propria posizione di sicurezza in modo diverso e ciò comprende anche il dover lavorare continuamente per migliorare i processi di sicurezza. L’obiettivo è quello di andare oltre la semplice conformità. Siate pronti a reinventare e ricostruire i sistemi per renderli più resilienti, implementare misure di multilevel security, considerare livelli di conformità più elevati, più esercitazioni teoriche [in inglese], audit di sicurezza, red teaming, protezione degli endpoint e così via.

“Ognuno di questi elementi ci porta a un modello più esemplare che possiamo mostrare dicendo: “Sì, questo è successo a noi e ora stiamo facendo cose che possono essere migliori” per poi condividerlo”, rileva Brown. “L’approccio è: come possiamo rendere le cose molto più difficili, contro un’infezione o un’altra violazione mirata?”.

I CISO con esperienza in materia di incidenti potrebbero anche cambiare il loro approccio alle esercitazioni teoriche. Nel caso di Brown, ora sono più frequenti e prevedono eventi potenziali più gravi, perché quando si è vissuto un incidente si sa che ogni eventualità è possibile.

“Una volta che lo si vive, il tono è molto diverso. E l’idea che fosse teorico prima di diventare reale è radicata in tutti noi che lo abbiamo vissuto”, afferma.

6. Restare vigili contro la sindrome dello shiny-object

Uno degli insegnamenti tratti da Michel è quello di evitare di lasciarsi distrarre da strumenti nuovi, interessanti e accattivanti, ma ciò può essere difficile in un settore inondato da grandi promesse e termini confusi. “L’intero settore soffre della sindrome dello shiny-object”, avverte.

Concentratevi invece su misure di sicurezza come la gestione delle vulnerabilità e l’applicazione di patch, programmi di rilevamento e risposta robusti, metodi di autenticazione forti come il zero trust e quelli senza password, la formazione e l’addestramento dei dipendenti e esercitazioni di risposta agli incidenti reali per testare la prontezza. Soprattutto, state attenti alle vendite aggressive.

“Tutti detestano gestire le vulnerabilità, ma è una delle cose più importanti che si possano fare per comprendere la propria superficie di attacco, individuarle rimuoverle fino a raggiungere un livello di rischio accettabile”, aggiunge.

7. I finanziamenti possono esaurirsi dopo un incidente

Gli incidenti hanno la capacità di focalizzare l’attenzione sulla sicurezza informatica. Improvvisamente, il consiglio di amministrazione e la dirigenza vogliono parlare di cybersecurity [in inglese], conoscere i rischi e investire denaro affinché tutti possano dormire sonni tranquilli.

Questo può essere musica per le orecchie dei CISO che cercano di ottenere maggiori finanziamenti, ma l’attenzione, e i fondi, possono essere di breve durata.

“Quando si è sempre detto ‘questi sono i rischi’ e poi all’improvviso, ci si ritrova in quella situazione, allora i dirigenti, il consiglio di amministrazione, tutti, per un po’ non vogliono parlare d’altro che di sicurezza informatica, ma poi l’interesse inizia a diminuire”, nota Gerchow.

Le aspettative aumentano di pari passo con l’aumento del budget. Il problema è che ci vuole tempo per fare le dovute verifiche e acquisire gli strumenti e le competenze adeguati. Tuttavia, se il denaro non viene utilizzato entro un certo periodo di tempo, i dirigenti potrebbero riassegnarlo ad altre aree una volta che l’attenzione intensa post-incidente si sarà attenuata.

Questo mette i Chief Information Security Officer nella difficile posizione di dover spiegare al consiglio di amministrazione e agli altri dirigenti che cosa comporti la perdita di finanziamenti, quando molti preferirebbero concentrarsi su metriche e miglioramenti. “I CISO possono parlare dei rischi e dei progressi compiuti rispetto all’incidente, ma non possono parlare della possibilità che il budget e le posizioni vengano ridotti”, tiene a precisare.

8. È necessario prendersi cura di sé stessi in ogni momento

Se c’è una lezione comune e fondamentale per i Chief Information Security Officer è che devono prendersi cura di sé stessi, dal punto di vista legale [in inglese], professionale e mentale [in inglese], per tutta la durata del loro mandato nel settore.

A causa del burnout, dello stress elevato e delle responsabilità crescenti, molti CISO sentono la pressione del loro ruolo. Gli incidenti si aggiungono a questi fattori di stress, ma stanno diventando sempre più comuni con l’aumentare della frequenza degli attacchi.

“Purtroppo gli incidenti sono all’ordine del giorno, fanno parte del lavoro”, dichiara Thorsen.

Brown incoraggia i CISO a riconoscere i potenziali effetti sulla salute dei ruoli altamente stressanti e a stabilire un sistema di supporto adeguato, che sarà fondamentale quando si verificherà un incidente. Inoltre, non bisogna sottovalutare quanto possa essere stressante trovarsi nell’occhio del ciclone per i propri meccanismi di coping.

“Uno dei messaggi più importanti è che, anche se si pensa di gestire bene lo stress, potrebbe non essere così”, conclude il manager. “Il lavoro dei Chief Information Security Officer è già abbastanza difficile, quindi è necessario trovare uno sfogo. Ma durante un evento, la situazione peggiora ulteriormente. È importante riconoscerlo e costruire un piano personale, perché non esiste un approccio valido per tutti in questo tipo di situazioni”.