Task Incident Response Team

Un Incident Response Team (IRT) o Emergency Response team (ERT) è un gruppo di persone che si preparano e rispondono a qualsiasi incidente di emergenza, come un disastro naturale o un’interruzione delle operazioni aziendali. Il team è maggiormente comune nelle organizzazioni di servizio pubblico e in altre organizzazioni militari o specializzate. Questa squadra è generalmente composta da membri specifici designati prima che si verifichi un incidente.

I membri del team di risposta agli incidenti idealmente sono formati e preparati per svolgere i ruoli richiesti dalla situazione specifica. Con l’aumentare delle dimensioni di un incidente e con l’utilizzo di più risorse nell’evento, il comando della situazione può spostarsi attraverso diverse fasi. In un evento su piccola scala, di solito può rispondere solo un volontario o un team ad hoc. Negli eventi, sia grandi che piccoli, sia membri specifici che team aggiuntivi possono lavorare insieme in un sistema di comando unificato. I singoli membri del team possono essere formati in vari aspetti della risposta, che si tratti di fuoriuscite di materiali pericolosi, attacchi ai sistemi informativi o soccorso in caso di calamità. Il team per mitigare il pericolo ha già definito un protocollo o una serie di azioni/ regole.

Le Tecnologie dell’Informazione e della Comunicazione (Information and Communication Technology, ICT) sono in rapida espansione e condizionano ormai completamente un numero crescente di settori vitali dell’economia e di servizi offerti dalle Pubbliche Amministrazioni. L’ampliamento dei settori coinvolti e delle conoscenze richieste è una conseguenza della digitalizzazione dell’economia e della dipendenza di numerose attività dai servizi digitali; molte azioni quotidiane si svolgono infatti nel cosiddetto spazio cibernetico o cyberspace. In prospettiva la crescita dell’internet delle cose (Internet of Things, IoT), ossia l’insieme di dispositivi connessi in grado di svolgere operazioni nel mondo fisico, aprirà le attività domestiche alla dimensione cibernetica. Alle nuove tecnologie si accompagnano tuttavia nuovi e crescenti rischi; tra questi particolarmente rilevante è quello cibernetico (cyber risk). I dispositivi, il software e le connessioni di rete che compongono lo spazio cibernetico presentano vulnerabilità tecnologiche e organizzative che possono essere sfruttate in modo malevolo, come dimostra il moltiplicarsi degli attacchi informatici che riguardano ormai i vari settori della società. Uno spazio cibernetico non sicuro costituisce una debolezza grave in una società digitalizzata, non solo per i danni diretti che possono arrecare alle strutture colpite, ma anche perché una diffusa conoscenza di insicurezza può compromettere il funzionamento di quei settori che si basano sulla disponibilità, sull’integrità e sulla riservatezza di dati digitali. Il rischio cibernetico non è nuovo. Nelle fasi iniziali del processo di digitalizzazione tuttavia erano in numero limitato sia le potenziali vittime sia gli attori della minaccia. Solo i settori informatizzati (come la difesa e le telecomunicazioni) costituivano un target sufficientemente appetibile per gli attacchi cibernetici; inoltre le conoscenze e le risorse necessarie per progettare e sferrare tali aggressioni esistevano quasi esclusivamente in ambito militare e in alcuni centri di ricerca. Negli anni l’uso di dispositivi informatici e l’accesso alle reti telematiche si sono enormemente estesi. Inoltre le competenze necessarie per programmare codici malevoli sono ormai a disposizione di molte organizzazioni criminali, che sviluppano strumenti offensivi e talvolta li offrono a basso costo a un ampio pubblico di clienti ed utenti. Anche ormai il cittadino e i suoi rapporti con la Pubblica Amministrazione sono divenuti nel tempo oggetto di attenzione per gli attacchi cibernetici, con la finalità di colpire e compromettere il legame di fiducia esistente tra gli stessi.

La sicurezza cibernetica dei sistemi informativi delle organizzazioni e della relativa rete di interconnessione viene assicurata dall’azione, e dal relativo coordinamento, di diverse strutture di gestione della cyber security operanti nei diversi ambiti di competenza: Response Team.

Lo scenario informatico degli anni ’90 era costituito soprattutto da mini-computer e workstation, il più delle volte collegate a Internet per mezzo di un indirizzo IP staticamente determinato. I malintenzionati agivano in un ambiente sostanzialmente omogeneo in cui i sistemi operativi Unix-like erano molto diffusi. Agli inizi del decennio in Italia i principali utilizzatori della rete erano le università e i centri di ricerca, le reti locali erano ancora alquanto eterogenee e l’uso domestico di Internet e del computer non era ancora stato immaginato. I servizi disponibili sulla Rete erano limitati essenzialmente alla possibilità di collegamento remoto ad un altro sistema, al trasferimento di file e alla posta elettronica. L’insieme di questi due fattori (omogeneità dell’ambiente e scarsa attenzione delle vittime) contribuiva a formare una classe di attaccanti estremamente preparata contrapposta ad una classe di vittime molto spesso completamente indifese. L’attacco del resto finiva per essere in molti casi un’abilità tecnologica facilitata al contesto di un sostanziale vuoto legislativo (La prima legge italiana che imputa specificatamente il reato di frode informatica è del 1993). L’attacco più diffuso era l’accesso non autorizzato con la conseguente compromissione del file delle password e dell’account di amministrazione. In questa situazione il ruolo dei Response Team era soprattutto di sensibilizzazione e trasferimento tecnologico: gruppi di esperti di sicurezza white hat fornivano le proprie competenze a chi incappava nelle grinfie dei malintenzionati. Conseguentemente, le segnalazioni ricevute dai Response Team riguardavano soggetti del tutto impreparati in materia che chiedevano consulenze per allestire rimedi o anche solo per capire l’entità dell’incidente verificatosi. Comprensibilmente una delle principali richieste di tali soggetti era la riservatezza delle informazioni: nessuno di essi aveva piacere che fosse resa pubblica la propria inadeguatezza strutturale a rispondere agli attacchi verso i propri sistemi informatici.

Il nome “Incident Response Team” è stato utilizzato per la prima volta nel 1988 da Centro di coordinamento CERT (CERT-CC) presso Università Carnegie Mellon (CMU).

La loro storia è legata all’esistenza di malware, in particolar modo di worm di computer e di virus. Infatti il 2 novembre 1988 alle otto e trenta del mattino Robert Tappan Morris, davanti ad un computer del MIT lancia sulla “Internet” il suo codice malevolo (worm) , con l’obiettivo di dimostrare l’inadeguatezza delle misure di sicurezza a protezione della rete. In meno di ventiquattro ore, 6.000 dei 60.000 computer connessi tra università, enti governativi e militari sono vittime di un worm che, pur non distruggendo i dati dei server, li rallenta fino a renderli inutilizzabili. Il rallentamento delle reti, il ritardo di giorni nella consegna delle e- mail, la disconnessione forzata di interi dipartimenti causano danni stimati nell’ordine di milioni di dollari.

Nel tentativo di rimediare al disastro, Robert abbozza un tentativo di incident response inviando anonimamente le istruzioni per la rimozione del worm ed impedire una nuova infezione, ma sulla rete che lui ha danneggiata le informazioni non arrivano in tempo.

L’analisi a posteriori confermarono che le contromisure in atto non sarebbero comunque state in grado di evitare i danni enormi a causa di problemi di comunicazione e coordinamento strutturali alla rete.

Il worm di Morris fornì quindi lo spunto alla DARPA, l’agenzia USA che veicolava importanti finanziamenti verso i progetti di ricerca di sicurezza nazionale, per istituire velocemente il primo centro per la risposta coordinata agli incidenti presso il Software Engineering

Institute (SEI) della Carnegie Mellon University. Nacque così il primo Incident Response Team con il compito di gestire le emergenze, e costruire velocemente un robusto sistema all’interno della comunità Internet.

A metà degli anni ’90 lo scenario cambiò radicalmente grazie principalmente a due fattori: Il primo riguardava l’introduzione del word wide web, la seconda invece la disponibilità di sistemi operativi Unix-like open source come Linux e FreeBSD. Il risultato netto di tale trasformazione dal punto di vista della sicurezza informatica fu uno scenario completamente nuovo: grande varietà di ambienti e protocolli; diffusione della figura del provider. Sono questi gli anni del boom della sicurezza informatica: non a caso il Response Team nasce e conosce i suoi momenti di massima prosperità, fornendo un centinaio di consulenze ogni anno.
Un team di risposta agli incidenti è responsabile della protezione dell’organizzazione da problemi di computer, rete o sicurezza informatica che minacciano un’organizzazione e le sue informazioni. Un modello universale per la risposta agli incidenti è il modello “proteggi, rileva e rispondi”. Il compito di proteggere consiste nell’assicurarsi che un’organizzazione abbia preso le misure e le precauzioni necessarie per limitare il rischio prima che sorgano problemi di sicurezza informatica. Questo compito si concentra su strategie proattive così organizzate:

Creare un piano di risposta agli incidenti organizzativi.
Eseguire valutazioni o analisi del rischio.
Crea una gestione aggiornata dell’inventario delle risorse
Implementa strumenti di scansione delle vulnerabilità e sistemi di rilevamento delle intrusioni (IDS).
Fornire formazione sulla consapevolezza della sicurezza a tutti i dipendenti.
Configurazione della build, vulnerabilità e gestione delle patch
Sviluppare piani di sicurezza, politiche, procedure e materiali di formazione sulla risposta agli incidenti.
Linee guida dettagliate per gli utenti su quali problemi di sicurezza dovrebbero essere segnalati e delineano un processo per la creazione di una segnalazione.
Crea playbook di risposta agli incidenti per i tipi di incidenti comuni.
Implementa misure difensive interne ed esterne che vengono regolarmente aggiornate in base alle minacce attuali.
Rivaluta l’efficacia delle procedure ogni volta che si verifica un incidente.

Il compito di individuare può richiedere settimane o mesi prima che molte organizzazioni vengano completate. Una strategia di rilevamento comune consiste nell’implementare un’architettura di rete difensiva utilizzando tecnologie quali router, firewall, sistemi di rilevamento e prevenzione delle intrusioni, monitor di rete e centri operativi di sicurezza (SOC).Un rilevamento efficace richiede impegno, un alto livello di conoscenza del funzionamento della rete di un’organizzazione. Per determinare se una rete non funziona correttamente, se ospita applicazioni indesiderate o se presenta schemi di traffico anomali, è necessario essere in grado di caratterizzare come dovrebbe funzionare la rete e i sistemi ad essa connessi.La gestione del sistema richiede che ogni parte di una rete debba essere documentata e definita come base. Questo può essere fatto con:

Un programma SAM (Software Asset Management) che stabilisce cosa dovrebbe esserci e chi lo possiede, ovvero quali applicazioni e funzioni aziendali sono supportate da ciascuna risorsa. Inoltre, dovrebbero essere efettuati controlli regolari.
Un programma di sicurezza e gestione delle applicazioni che include i proprietari delle applicazioni, gli utenti autorizzati, la caratterizzazione del trasferimento dei dati e altro traffico di cui sono responsabili le applicazioni.
Programmi di modifica, configurazione e gestione delle patch per sapere se la rete è impostata come dovrebbe essere.
Una baseline di utilizzo della larghezza di banda e controlli di routine della larghezza di banda rispetto alla baseline.
Linee di base del flusso di rete e monitoraggio continuo per acquisire la deviazione dalla linea di base.

Con entrambe le tecniche di protezione e rilevamento, è importante comprendere che tutte le strategie e regole di questi modelli di processo devono essere costruiti in anticipo prima che possano verificarsi azioni malevole.
Come ultima fase alla risposta degli incidenti vi è il compito di rispondere che richiede pochi passaggi per essere applicato.
Il primo passo è quando il team riceve una segnalazione di un incidente da un soggetto, come un utente, un partner commerciale o un membro dello staff del centro operativo di sicurezza. I membri del team analizzano quindi il rapporto sull’incidente per capire cosa sta succedendo e crea una strategia immediata per riprendere il controllo e impedire che si verifichino ulteriori danni. Infine, la strategia si trasforma in un piano che viene poi implementato per riprendersi dall’incidente e tornare alle normali operazioni il più rapidamente possibile.
Il National Institute of Standards and Technology (NIST) ha sviluppato il proprio modello di risposta agli incidenti ovvero il SP-800-61 che descrive in dettaglio questo modello per la mitigazione.
L’Incident Reponse Team ha molti omonimi che svolgono attività molto simili. Questo è dovuto dal fatto che il Software Engineering Institute (SEI) è un centro di ricerca e sviluppo finanziato a livello federale gestito dalla Carnegie Mellon University, il quale ha registrato il marchio e possiede il nome ed il simbolo di marchio “CERT”.
A causa della proprietà del marchio commerciale di Carnegie Mellon altre organizzazioni di risposta agli incidenti hanno sviluppato un loro acronimo differenziandosi dagli altri, dove tutta la documentazione di risposta agli incidenti di sicurezza informatica, le pubblicazioni, i corsi di formazione sono gestite in modo indipendente. Infatti oggi si possono leggere diversi gruppi di risposta agli incidenti:

Computer Security Incident Response Team (CSIRT).
Incident Response Team (IRT).
United States Computer Emergency Readiness Team (US-CERT).
Capacità o centro di risposta agli incidenti di sicurezza informatica (CSIRC).
Capacità o centro di risposta agli incidenti informatici (CIRC).
Computer Incident Response Team (CIRT).
Team di gestione degli incidenti (IHT).
Incident Response Center o Incident Response Capability (IRC).
Team di risposta alle emergenze di sicurezza (SERT).
Team di risposta agli incidenti di sicurezza (SIRT).

Creare un team di risposta agli incidenti - Organizzazione CSIRT

È importante esaminare come sono organizzati i team che si occupano di incident responding. Vi sono tre modalità per creare Incident Response Team:

Central: il modello più semplice, dove tutti gli incidenti sono gestiti da una singolo team. È il modello standard per le piccole imprese
Distribuited: molteplici team gestiscono gli incidenti. Ogni squadra è responsabile per gli incidenti o di uno specifico segmento fisico o logico della struttura e vi è un responsabile che coordina le attività. Questo modello è efficace per le grandi organizzazioni e per quelle con sedi dislocate in luoghi distanti tra lor. 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 potrebbero gestire incidenti simili.
Coordinated: un team di risposta agli incidenti fornisce consulenza ad altre squadre senza avere l’autorità su di loro.Un altro fattore importante per rendere efficace il team la scelta di come devono essere inquadrati i membri componenti:

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.Il NIST, definisce una serie strategie da attuare nel proprio Team per una migliore efficienza del lavoro:
Disponibilità 24/7: supporto costante, senza interruzioni per una copertura continua, che pero richiede operatori in loco senza interruzioni del servizio, con una comunicazione degli incidenti in tempo reale con tutti gli attori coinvolti nel processo e cliente finale.
Staff Expertise: per lo svolgimento di alcune attività sono richieste specifiche competenze e certificazioni per garantire personale opportunamente formati ed addestrati con una conoscenza approfondita dei protocolli, degli strumenti di rilevamento delle intrusioni, delle tecniche di attacco degli hacker; Stabilisce anche delle 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, bisogna avere una struttura solida dell’organizzazione del team. Specificando 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: un piano di risposta agli incidenti è 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 da applicare per rispondere a un incidente.Bisogna esaminare e comprendere quali sono le quattro fasi da applicare:
Preparazione: stabilire quali sono gli assets dell’azienda che potrebbero essere sottoposti ad attacco e quindi vittime di incidenti.
Rilevazione ed analisi: la rilevazione riguarda lo studio dei precursori ovvero un evento notificante che, pur non essendo ancora avvenuto, si ipotizza un attacco che potrebbe verificarsi: ciò avviene identificando i possibili vettori d’attacco. Si deve anche prendere in considerazione l’analisi dell’elenco delle CVE pubblicate dagli opportuni organi per 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. Anche Gli indicatori hanno una forte rilevanza poiché indicano che un attacco è già in corso e devono essere costantemente monitorati. Il loro esame avviene mediante 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 quest’ultimo e lo illustri nel modo più dettagliato e preciso possibile.

Contenimento, Eradicazione e Ripristino: per contenimento s’intende il bloccare 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. L’eradicazione consiste invece nel passaggio successivo al contenimento; bloccata la propagazione del danno, va eliminata la fonte, la radice del problema.
Attività Post Incidente: è 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.

Struttura Incident Response Team

Con la rapida crescita di Internet (più della metà della popolazione mondiale è connessa al web) la protezione della rete è diventata un tema geopolitico.Un Response Team ha il compito di reclutare risorse esperte nella gestione degli incidenti in grado di comprendere i processi aziendali funzionali all’organizzazione. Infatti il Team insieme al il SOC, determina:

se e come un attacco o una minaccia avranno impatto sull’infrastruttura
quali metodi utilizzare per contenere e neutralizzare attacchi e minacce
quali processi di verifica adottare per garantire la ripresa delle normali operazioni
chi informa e aggiorna gli stakeholder sullo stato delle minacce e sulle azioni di risposta.Il team si dedica ai servizi proattivi, (progettati per rilevare e prevenire gli attacchi prima che si verifichi un impatto effettivo sui sistemi di produzione) dove quelli comuni sono annunci, Audit di sicurezza/Pentest, Sviluppo strumenti, Rilevamento delle intrusioni, Condivisione di informazioni sulle minacce. Si occupano di monitoraggio e analisi degli eventi e gestione delle vulnerabilità, fornendo ai propri clienti attraverso report, bollettini e annunci le informazioni relative a nuove minacce e al livello di gravità di impatto sulla loro infrastruttura. Un altro importante ruolo che il Reponse Team ricopre riguarda l’area di servizi legati alla qualità della sicurezza, attraverso programmi di formazione, cyber awareness, risk analysis e tutte le attività che contribuiscono a perfezionare la security posture dell’organizzazione, migliorandone la resilienza attraverso la crescita di consapevolezza cyber.

La raccolta in tempo reale degli avvisi su indicatori di compromissione (IOC), delle minacce emergenti attraverso un attento lavoro di Threath Intelligence, permette al Team di disporre di un ingente quantità di informazioni che, una volta analizzate e condivise, sono utili per definire strategie comuni di difesa con maggiore attenzione al: