Questo sito web utilizza cookie tecnici e, previo Suo consenso, cookie di profilazione, nostri e di terze parti. Chiudendo questo banner, scorrendo questa pagina o cliccando qualunque suo elemento acconsente all'uso dei cookie. Leggi la nostra Cookie Policy per esteso.OK

Incident response e policy collaborative tra i team: cosa fare in caso di incidenti informatici

pittogramma Zerouno

Sicurezza

Incident response e policy collaborative tra i team: cosa fare in caso di incidenti informatici

Sono diversi i team coinvolti nella gestione delle vulnerabilità e degli incidenti informatici. In caso di un attacco conclamato come devono comportarsi le aziende? Cosa dovrebbe fare un CISO per gestire al meglio il processo? Come allineare lo staff interno con il team forense esterno?

24 Ago 2016

di TechTarget

Che cosa sono i cosiddetti incident response nell’ambito della sicurezza informatica? Sono le conseguenze degli attacchi informatici legati alle varie vulnerabilità che tormentano le aziende.

Il fattto è che nessuno conosce meglio il controllo delle infrastrutture aziendali di un CISO e del suo gruppo di lavoro. Ogni giorno il security team si occupa di protezione, monitoraggio e attività di test per seguire il follow up quotidiano dei servizi che vanno presidiati.

Così, quando subentra una breccia nel perimetro aziendale e viene coinvolta una società forense esterna per seguire tutta l’attività di investigazione e di rilevamento dei danni subiti per il CISO può essere frustrante gestire la cosa.

Uno dei punti da cui si generano i maggiori attriti, segnalano gli esperti, è che il team forense ha competenze che non ha il team IT intermo ma deve relazionarsi e comunicare con tutti i diversi referenti aziendali: gli executive, le operation, gli impiegati e la parte legale. Questo perché solo così è possibile determinare le cause dell’attacco, contenere la falla e identificare le azioni correttive necessarie a evitare che l’incidente informatico possa ripetersi.

Incident response plan: come definire una corretta politica di risposta agli incidenti

Ogni CISO dovrebbe avere realizzato un piano di gestione degli incidenti informatici (Incident Reponse Plan – IRP). Questo, idealmente molto prima che avvenga un’attacco che si può tradurre in un incidente informatico di varia entità.

L’IRP dovrebbe basarsi su una metodologia di risposta ale violazioni informatiche come, ad esempio, la NIST SP 800-61 Incident Handling Guide. Nel manuale sono sviluppate quattro fasi:

  1. preparazione
  2. rilevamento e analisi
  3. contenimento, eliminazione della vulnerabilità e ripristino del servizio
  4. attività di gestione post incidente

Se le policy di gestione degli incidenti informatici sono controllate e testate su più scenari, l’impresa dovrebbe essere già in grado di gestire l’attacco prima ancora che arrivi il team forense esterno.

Security collaboration: le aziende hanno bisogno di un team IRP

L’attività di gestione che fa seguito all’incidente informatico aiuta a capire meglio la dinamica della vulnerabilità e il danno subito, indirizzando le azioni da compiere a supporto di una  migliore sicurezza. I dati raccolti dall’analisi dell’incidente e le evidenze raccolte, infatti, migliorano la comprensione di cosa non sia stato fatto per potenziare la protezione, aiutando il CISO e il suo staff a definire le linee di intervento ma anche a condividere queste informazioni con il team forense che prima viene messo al corrente di queste informazioni, prima può aiutare l’azienda a risolvere i danni. Gli esperti suggeriscono di ragionare in un’ottica di security collaboration, pensando a un team IRP preposto all’Incident Respons Plan.

Il gruppo dovrebbe essere in grado di gestire anche le nuove minacce alla sicurezza, così come di lavorare al miglioramento della tecnologia mettendo a frutto le lezioni apprese. Nel caso sia intercorso un incidente informatico, la squadra dovrebbe porsi alcune domande fondamentali:

  • Cosa è andato perso?
  • Queste informazioni erano vitali per l’impresa?
  • Come si è verificata la falla?
  • Si è trattato di un errore umano (social engineering o errore di configurazione), di una vulnerabilità dipesa da una patch non aggiornata o da una buco nel servizio di un fornitore?

Utilizzando le risposte a queste domande, il team IRP può ottenere un quadro più chiaro in merito all’incidente informatico subito. Il consiglio degli esperti in merito alla definizione di un buon IRP è che Il CISO debba utilizzare un calendario IRP sempre aggiornato, su cui riportare una pianificazione delle riunioni con i system engineering, con la parte legal, i responsabili della comunicazione, il team di investigazione forense e gli executive. Tenendo conto che con alcuni dovranno essere fatte più riunioni al giorno mentre con altri basterà un solo aggiornamento quotidiano.

Incident response: come usare al meglio i dati raccolti

Una volta che l’incidente è stato rilevato e sono stati raccolti tutti i dati utili, bisogna chiamare le forze dell’ordine, ovvero la polizia locale o nazionale. Negli Stati Uniti le agenzie possono includere l’US Department of Homeland Security mentre in Europa sarà coinvolta la divisione criminalità informatica dell’INTERPOL, a seconda dello stato in cui si trova la sede aziendale che ha subito l’attacco. Le forze dell’ordine, tra cui il gruppo di indagine forense, formano il team esteso, che ha diverse responsabilità nella fase di attività a seguito dell’incidente informatico.

Come prima cosa, il team IRP si dovrò poi occupare di preparare un rapporto per gli executive dell’azienda su cui saranno riportati:

  • i danni stimati e l’impatto dell’attacco sull’azienda
  • le misure adottate durante l’incidente
  • le attività intraprese per eliminare o attenuare la vulnerabilità
  • le politiche di risposta agli incidenti e/o le procedure di aggiornamento relative
  • gli sforzi messi in campo per minimizzare il tempo di esposizione al’attacco

Come seconda cosa, è necessario fornire il registro cronologico dei log così come qualsiasi altro tipo di reportistica dei log a tuto il team IRP.

Il terzo punto importante è quello di documentare cosa si è appreso a seguito dell’incidente andando modificare le policy di risposta agli incidenti di conseguenza. Il team IRP dovrebbe anche assicurarsi che:

  • La parte legale e amministrativa collaborino con le autorità locali nel caso l’incidente informatico convolga risorse esterne
  • La parte legale e amministrativa lavorino con il fornitore dei servizi assicurativi che proteggono l’azienda dai crimini informatici a seguito della stipula di un contratto
  • Le risorse umane e il gruppo di sicurezza lavori insieme alla direzione per determinare le azioni correttive nel caso i responsabili degli incidenti siano le risorse interne
  • Gli investigatori forensi a livello di rete confermino se i dati esposti siano stati sottratti o manomessi, determinando se gli aggressori siano stati isolati dagli ambienti aziendali compromessi.

Come si raccolgono (e si conservano) le evidenze

Le organizzazioni dovrebbero stabilire anche una precisa politica di sicurezza rispetto all’arco di tempo secondo cui le prove di un incidente informatico debbano essere conservate. La maggior parte delle organizzazioni scelgono di conservare tutte le prove per mesi o addiruttra anni.

Oltre alla voce delle prove che dovrebbero essere scritte e ampiamente documentate nell’IRP sarebbe il caso di inserire una seconda voce legata al costo delle attività di follow up per il presidio e quella del costo dello storage necessario ad archiviare questo tipo di dati, che sia un hard disk, supporti rimovibili o nastri di backup. Secondo gli specialisti, una buona politica di conservazione dei dati di risposta a incidente dovrebbe includere un calendario per la conservazione su un arco di almento tre anni.

 

 

TechTarget

Argomenti trattati

Approfondimenti

B
Backup

Articolo 1 di 5