Non importa quanto bene gestisci la tua posizione di sicurezza, c'è sempre la possibilità che tu diventi vittima di un attacco informatico. Ecco perché ogni organizzazione, indipendentemente dalle dimensioni, dovrebbe essere pronta a reagire a un incidente informatico. L'elemento chiave di tale preparazione è un piano di risposta agli incidenti informatici (IRP).
Elementi di un piano di risposta agli incidenti di sicurezza informatica
Quando costruisci il tuo piano IR, ci sono molti elementi da considerare e ognuno di questi elementi è ugualmente importante. Se uno di questi elementi viene ignorato, sarebbe impossibile reagire in modo efficiente e potrebbe causare il caos in un'organizzazione, che a sua volta avrebbe un grave impatto sulle operazioni aziendali, sulla sicurezza delle informazioni e altro ancora.
Squadra di risposta agli incidenti
Non è ottimale per nessuna organizzazione avere un team separato in attesa, in attesa di un incidente. Pertanto, quando si crea un team di risposta agli incidenti di sicurezza informatica (CSIRT), è necessario includere le risorse umane esistenti. Tale team viene assemblato solo in caso di incidente, ma ciascuna risorsa deve essere consapevole del proprio ruolo all'interno del team e dell'impatto che avrà sul lavoro quotidiano.
Responsabili delle decisioni: le risorse chiave in un CSIRT sono le parti interessate chiave: le persone che sono in grado di prendere decisioni. Ciò significa che il tuo team deve includere il top management, possibilmente anche coinvolgere i dirigenti dell'azienda. È abbastanza comune che un team di risposta agli incidenti sia guidato dal Chief Information Security Officer (CISO), dal Chief Security Officer (CSO), dal Chief Information Officer (CIO) o anche dal Chief Technology Officer (CTO). Tuttavia, a seconda della struttura organizzativa, il team potrebbe coinvolgere anche il chief operations officer (COO) e l'amministratore delegato (CEO). Quando si reagisce a un incidente, la tempestività è fondamentale, quindi le decisioni devono essere prese rapidamente e non possono essere contestate.
Risorse tecniche: un team di risposta agli incidenti informatici deve includere persone in grado di indagare sull'incidente e identificare la causa principale, lavorare con risorse tecniche, nonché ripristinare/riparare i sistemi interessati e altre risorse e prevenire ulteriori danni. Ciò significa che il team deve coinvolgere il tuo centro operativo di sicurezza, ma anche gli amministratori di sistema, le operazioni IT e, in alcuni casi, anche gli sviluppatori. Poiché questo è il personale che gestirà la maggior parte del lavoro coinvolto, deve essere consapevole delle priorità e delle assegnazioni dei compiti. È necessario considerare l'impatto di ciò sulla continuità aziendale. Ad esempio, il tuo team deve essere ancora in grado di mantenere e proteggere i sistemi non interessati in modo che la tua azienda non si fermi completamente fino a quando l'incidente non viene risolto.
Risorse legali e di conformità: nel caso di molte organizzazioni, un incidente informatico potrebbe coinvolgere dati sensibili e quindi avere conseguenze legali, nonché influire sulla conformità a GDPR, PCI DSS, HIPAA e altro ancora. Pertanto, ai fini della valutazione del rischio (non limitandosi ai rischi per la sicurezza) devono essere coinvolti nel CSIRT anche i rappresentanti dei vostri dipartimenti legali e di conformità. Proprio come nel caso delle risorse tecniche, devono essere consapevoli delle priorità. Tuttavia, per mantenere la continuità aziendale, potrebbe essere impossibile dedicare tutta la loro attenzione all'incidente.
Comunicazioni: quasi tutti gli incidenti informatici influiranno in qualche modo sulle parti esterne. Ad esempio, i tuoi clienti, i tuoi partner o il pubblico in generale (a seconda della natura della tua organizzazione). Pertanto, il tuo team di risposta agli incidenti deve includere risorse del tuo servizio clienti, pubbliche relazioni, gestione dell'account e altro ancora. Tieni presente che una comunicazione chiara che implica la divulgazione al pubblico (compresi i dettagli tecnici) è una buona pratica e aiuta l'immagine del tuo marchio.
Risorse esterne: potresti considerare di coinvolgere risorse esterne come esperti forensi, analisti della gestione del rischio e altro ancora. In tal caso, è necessario selezionare e costruire una relazione con tali parti prima che si verifichi un incidente, in modo che siano pronte ad aiutare quando necessario. Ciò potrebbe comportare contratti o accordi aggiuntivi che devono essere applicati continuamente.
Indipendentemente dal fatto che le risorse coinvolte nel tuo CSIRT siano interne o esterne, devi considerare i seguenti fattori:
Responsabilità: ogni soccorritore coinvolto nel team di risposta agli incidenti deve conoscere chiaramente l'ambito dei propri ruoli, responsabilità e priorità in relazione al proprio lavoro quotidiano. Le responsabilità non devono entrare in conflitto e se sono coinvolte risorse esterne, dovrebbero avere un contatto interno di riferimento se sono necessarie decisioni aziendali interne.
Informazioni di contatto: gli incidenti possono verificarsi al di fuori dell'orario lavorativo e di solito richiedono una risposta in tempo reale. Non puoi permetterti di aspettare con il contenimento fino al giorno lavorativo successivo perché il criminale potrebbe impiegare quel tempo per causare ancora più scompiglio. Pertanto, per una risposta efficace agli incidenti, è necessario disporre delle informazioni di contatto fuori sede per ogni risorsa coinvolta e le risorse devono essere consapevoli del fatto che, in caso di incidente informatico, verranno contattate al di fuori dell'orario di lavoro.
Risorse di backup: per ogni membro chiave del team, è necessario disporre di un backup. Non puoi permetterti di aspettare che, ad esempio, il tuo team manager torni dalle ferie.
Risorse tecniche
Poiché un incidente informatico coinvolge sempre alcune risorse tecniche, la loro chiara visibilità è la chiave per una risposta efficace. Se le risorse non sono ben definite, enumerate e la loro relazione non è chiara, potrebbe essere impossibile contenere e risolvere completamente l'incidente.
Identificazione delle risorse: dovresti avere una visione chiara di tutte le tue risorse tecniche, sia quelle all'interno dell'azienda stessa che quelle esterne. Questa è una buona pratica quotidiana, ma l'importanza è ancora maggiore se le risorse sono interessate da un incidente.
Relazioni con le risorse: molte risorse tecniche sono interconnesse e, pertanto, un criminale potrebbe violare una delle risorse e degenerare in altre. A seconda della struttura tecnica della tua attività, potenzialmente ogni risorsa potrebbe essere interessata da un incidente e dovrebbe far parte di un'indagine e di una riparazione. Ad esempio, se un criminale accede a un'applicazione Web tramite un'iniezione SQL, accederà sicuramente al server del database (che potrebbe essere un sistema separato), raggiungendo potenzialmente il sistema operativo e potenzialmente utilizzando la rete interna per accedere ad altri sistemi. Capire come le risorse sono interconnesse è della massima importanza.
Proprietà delle risorse: alcune delle risorse tecniche interconnesse potrebbero essere al di fuori della proprietà della tua attività. Ad esempio, potresti collaborare con fornitori di servizi cloud o partner. La tua organizzazione potrebbe anche essere divisa in entità separate con una gestione diversa. È qui che le risorse tecniche si intrecciano con le risorse umane e dove potresti dover considerare aspetti tecnici nella composizione del tuo CSIRT. In caso di incidente, non puoi permetterti di scoprire improvvisamente che non sei in grado di contenere o riparare perché non hai il controllo sul bene. Ogni risorsa dovrebbe avere un rappresentante responsabile ben definito che ha il pieno controllo su di essa.
Strumenti
Un piano di risposta agli incidenti di sicurezza potrebbe comprendere strumenti che devono essere identificati e potenzialmente acquistati e implementati prima che si verifichino incidenti e prima di iniziare le attività di risposta agli incidenti:
Strumenti di identificazione: esistono diversi strumenti di sicurezza IT con diverse funzionalità che potrebbero essere utili per identificare un incidente. Ad esempio, un sistema di rilevamento delle intrusioni (IDS) per rilevare una possibile intrusione, uno scanner di vulnerabilità per identificare una vulnerabilità (ma dovresti comunque utilizzarne uno regolarmente come parte della normale automazione), strumenti manuali per test di penetrazione per confermare una vulnerabilità, nonché come altri strumenti di rilevamento delle minacce, sicurezza web, sicurezza della rete e informazioni sulla sicurezza e gestione degli eventi (SIEM).
Strumenti di pianificazione e modellazione: puoi utilizzare strumenti aggiuntivi per modellare la struttura della tua risorsa, organizzare le attività durante la risposta agli incidenti, fornire informazioni sulle minacce, seguire una metodologia selezionata e altro ancora. Tali strumenti possono essere software di pianificazione del progetto e diversi tipi di software di modellazione.
Strumenti di comunicazione: durante le procedure di risposta agli incidenti, alcuni dei normali strumenti di comunicazione aziendale potrebbero essere considerati non sicuri. Ad esempio, se un incidente comporta una violazione del server di posta elettronica interno, non è possibile utilizzare l'e-mail interna per comunicare durante la risposta all'incidente perché esiste il rischio che l'attaccante sia a conoscenza delle tue attività e sia in grado di contrastarle. Pertanto, dovresti avere un piano di comunicazione di backup.
Altri strumenti: potrebbero essere coinvolti anche altri strumenti. Ad esempio, le sale riunioni potrebbero essere considerate uno strumento per la collaborazione del team di risposta agli incidenti. Se includi personale esterno, deve essere dotato anche di idonei strumenti e autorizzazioni per accedere ai tuoi impianti ed eventualmente ai tuoi locali.
Definizione chiara dell'incidente
Ogni organizzazione può avere definizioni diverse dei tipi di incidenti, a seconda dell'impatto sul business e di altri fattori. Ad esempio, un'organizzazione potrebbe non considerare un attacco denial of service (DoS) minore come un incidente informatico perché non influisce sulla continuità aziendale, ma per un'altra organizzazione, anche un'ora di indisponibilità potrebbe comportare gravi conseguenze per l'azienda. Inoltre, alcune organizzazioni potrebbero considerare violazioni della sicurezza interna minori come incidenti di minacce interne e altre no (ad esempio, un dipendente di un dipartimento che accede alle risorse di un altro dipartimento, al quale non dovrebbe avere accesso). Altri fattori da considerare potrebbero essere la fonte dell'attacco (ad esempio, lone script kiddie contro un'organizzazione criminale).
Pertanto, uno degli elementi chiave dell'IRP è avere una definizione molto chiara di quale tipo di minacce informatiche ed eventi di sicurezza possono essere considerati incidenti e quando diventano veri e propri incidenti. Ad esempio, un virus trojan trovato sul computer di un dipendente e distribuito tramite phishing è considerato un incidente? Un cliente che segnala una vulnerabilità di cross-site scripting (XSS) a basso impatto sfruttata sul tuo sito di marketing è considerato un incidente? Una violazione di dati minore causata da un dipendente che espone pubblicamente un file di foglio di calcolo che contiene solo un paio di indirizzi e-mail di marketing è considerata un incidente?
Un buon punto di partenza per la propria definizione di incidente è la definizione ufficiale del NIST: "violazione, o imminente minaccia di violazione, delle politiche di sicurezza del computer, delle politiche di utilizzo accettabile o delle pratiche di sicurezza standard". Tuttavia, dovresti elaborare una definizione più dettagliata, che tenga conto di fattori specifici della tua organizzazione come il potenziale impatto sul business, la potenziale perdita di dati e altro ancora.
Una definizione chiara è molto importante per i decisori perché devono dichiarare se si è verificato un incidente o meno. Un incidente non è una zona grigia, o avvia il processo che coinvolge l'intero team oppure no. Ogni incidente dichiarato dovrebbe essere trattato allo stesso modo, senza valutazione della gravità. Poiché le attività coinvolte nel processo sono estese e possono avere un impatto sulla continuità aziendale, il decisore deve sapere chiaramente quando “premere il pulsante rosso”.
Nota: un incidente e un disastro sono termini diversi. Pertanto, il ripristino di emergenza e il ripristino di incidenti non dovrebbero essere coperti dagli stessi processi e dovrebbero essere soggetti a una pianificazione separata. Il ripristino di emergenza è il processo di ripristino da disastri naturali o indotti dall'uomo, ad esempio disastri naturali, incendi, l'eliminazione accidentale dell'intero database da parte di qualcuno, ecc. Il ripristino di emergenza potrebbe coinvolgere risorse diverse e, ad esempio, non deve coinvolgere la sicurezza squadra tanto quanto il recupero dell'incidente.
Fasi di risposta agli incidenti
Il processo di risposta agli incidenti è suddiviso in diverse fasi che dovrebbero essere incluse nel piano. Queste fasi dovrebbero essere seguite rigorosamente, non importa la tentazione.
Preparazione: questa è la fase più importante della risposta all'incidente e implica la definizione di tutti gli elementi di cui sopra: il CSIRT, le risorse e l'ambito di ciò che è considerato un incidente. Implica anche l'addestramento delle risorse e persino l'esecuzione di prove, esercizi da tavolo e attacchi simulati per vedere se tutto funziona come previsto. La chiave per il successo della fase di preparazione è evitare qualsiasi caos nell'organizzazione nel caso in cui venga dichiarato un incidente.
Identificazione: Questa fase prevede due attività chiave. Uno è l'indagine preliminare che porta alla dichiarazione di un incidente. Questa fase coinvolge solo una parte del team: i decisori e le risorse tecniche che forniscono intelligence. Tieni presente che la segnalazione di un potenziale incidente potrebbe provenire anche da fonti esterne, ad esempio dai tuoi clienti, partner o persino dalle forze dell'ordine, quindi potrebbe essere coinvolto anche il personale addetto alle comunicazioni. L'incidente viene dichiarato durante questa fase e, in tal caso, è necessaria un'indagine dettagliata per sapere quali asset sono potenzialmente interessati dall'incidente e devono essere coinvolti nelle fasi successive. Ad esempio, se un utente malintenzionato viola l'applicazione Web, è necessario identificare se ciò influisce sui server connessi o anche sull'intera rete. Si noti che una volta completata l'identificazione,
Contenimento: una volta che il carattere e la portata dell'incidente sono stati chiaramente identificati dalle risorse tecniche, è necessario decidere quali risorse devono essere contenute. Il contenimento è assolutamente necessario per una mitigazione a breve termine e questa fase non può essere saltata, anche se si è tentati di sradicare la minaccia il prima possibile. Se non viene contenuto, l'attaccante potrebbe continuare a lavorare in parallelo con il tuo team sull'escalation e continuare a diffondersi ad altri sistemi attualmente non interessati. Contenimento significa isolare le risorse interessate da quelle non interessate. Tuttavia, spesso non vengono portati offline (anche temporaneamente) perché ciò potrebbe rendere più difficile l'eradicazione. La fase di contenimento si conclude con la decisione che le risorse interessate vengono isolate in modo sicuro e l'attaccante viene tagliato fuori.
Eliminazione: dopo che le risorse interessate sono state contenute, le risorse tecniche iniziano a eliminare le conseguenze dell'incidente. Ciò significa, ad esempio, rimuovere il malware, correggere le vulnerabilità, ripristinare i sistemi da backup sicuri, applicare patch, ecc. La fase di eliminazione si conclude con la decisione che tutte le conseguenze tecniche dell'incidente vengono eliminate e i sistemi protetti.
Ripristino: i sistemi protetti devono ora essere riportati online e ricollegati ad altre risorse e tutti i processi tecnici e aziendali dovrebbero tornare alle normali operazioni. La fase di recupero si conclude con la decisione che l'intera infrastruttura tecnica sta funzionando così come prima dell'incidente. Si noti che la fase di recupero prevede anche il completamento dei lavori da parte delle vostre comunicazioni e risorse legali/di conformità. Il risultato finale di questa fase è che i tuoi decisori dichiarino chiuso l'incidente e che i membri del tuo team tornino alle loro normali attività.
Lezioni apprese: questa attività non deve essere eseguita immediatamente dopo la chiusura dell'incidente. Qualche tempo dopo l'incidente, è utile riassemblare le risorse chiave del team di risposta agli incidenti, in particolare tutti i responsabili delle decisioni, e analizzare come è stato gestito l'incidente. Di conseguenza, il processo potrebbe tornare alla fase di preparazione per coinvolgere più risorse nel team, spostare le responsabilità o fornire formazione extra se non tutti i membri del team si sono comportati abbastanza bene.
Un IRP per la sicurezza web?
Anche se la tua attività principale è associata al Web e sei maggiormente interessato alle minacce correlate al Web, non puoi limitare il piano di risposta agli incidenti informatici alla sola sicurezza del Web. Poiché i sistemi IT di ogni organizzazione sono interconnessi, il modello del piano di risposta agli incidenti deve coinvolgere tutta l'organizzazione e le parti correlate, nonché tutte le risorse. Solo allora puoi aspettarti un completo successo nell'eliminare le conseguenze degli incidenti.
