Somiglianze forti e deboli tra i diversi team che si attivano in caso di incidente informatico

Nonostante sia complesso emettere definizioni 'standard' capaci di regolare l'ambiente della difesa digitale, Robin Ruefle nel 2007 avanzò una descrizione di Computer Security Incident Response Team (CSIRT) nel suo articolo "Defining Computer Security Incident Response Team", ammettendo, nel summary finale, una certa difficoltà nello standardizzare team molto simili tra loro come per esempio: Computer Emergency Response Team (CERT), Security Operation Center (SOC) ed Computer Security Incident Response Team (CSIRT).

Dopo alcuni anni passati nella realizzazione, nell'analisi, nella co-organizzazione e nel miglioramento di CERT, CSIRT e SOC vorrei condividere alcune osservazioni 11 anni dopo la definizione redatta da Robin Rule per analizzare quali siano le somiglianze "forti" e quali siano le somiglianze "deboli" tra le varie organizzazioni che, durante lo scorso decennio, hanno preso nomi significativamente simili ma con percorsi indicativamente differenti. Proprio a causa della reale vicinanza in termini di "scopo" non si parlerà di "differenze" ma di "somiglianze".

Nello specifico, di "somiglianze forti" e di "somiglianze deboli" come quasi a "giustificare" il senso di appartenenza di un operatore a tutte e tre i team. Necessariamente le prime somiglianze "forti" sono rispettivamente: l'attivazione e la necessità di comprendere l'accaduto. Ogni team viene principalmente (ma non necessariamente) attivato durante un "incidente informatico". Ogni team necessita di esperte capacità di analisi per meglio comprendere gli avvenimenti accaduti prima e durante l'incidente segnalato. Nessun team possiede una migliore capacità analitica per definizione, tutti e tre devono possedere una ottima capacita di analisi e di sintesi di un incidente per poter proseguire con le rispettive pipeline di intervento. Un somiglianza "debole" è rappresentata dal focus specifico nell'effettuare l'analisi dell'incidente. Questa somiglianza perde la sua "forza" (somiglianza "debole") nell'interpretazione di "incidente" stesso. Ogni team possiede una visione leggermente differente di cosa significa "rispondere ad un incidente".

Il Security Operation Center usualmente (ma non necessariamente ) interpreta la risposta ad un incidente come una "azione tecnica" che deve essere attuata al fine di mitigare una situazione in atto (usualmente un attacco in corso e/o una possibile minaccia). Il SOC possiede il compito di rispondere tecnicamente ad un incidente. Per esempio possiede le capacità di effettuare azioni direttamente sul perimetro come aggiornare e/o forzare scansioni attraverso Anti Virus, inserire regole sui Firewalls, attuare policies sui Proxies, analizzare logs di IDS e di SandBoxes. Usualmente un SOC vede come suo centro di operatività un SIEM per meglio districarsi tra centinaia, a volte migliaia, di eventi provenienti dai sistemi in dotazione.

Il Computer Security Incident Response Team usualmente (ma non necessariamente) interpreta la risposta ad un incidente come una azione composta da tecnologia ed azioni legati all'organizzazione. Per esempio la risposta ad un incidente puo prevedere una "comunicazione" pubblica e quindi coinvolgere figure di "marketing" per meglio strutturare una strategia di comunicazione appropriata allo status aziendale, oppure puo scaturire la necessità di dotarsi di figure professionali nuove e quindi coinvolgere figure amministrative (HR) o ancora può evidenziare la carenza di policies e per questo potrebbe coinvolgere il delegato aziendale. Un CSIRT ha competenze relative al risk management e struttura una risposta in funzione della relativa priorità legata al asset colpito. Principali strumenti utilizzati da un CSIRT sono piattaforme di ticketing, asset inventory ed intrusion detection /SIEM ed endPoint protectors..

Il Computer Emergency Response Team usualmente (ma non necessariamente) interpreta la risposta ad un incidente come una azione di prevenzione e di "intelligence". Per esempio un CERT comunica attraverso la propria "rete CERT" emettendo e ricevendo indici di compromissione atti all'anticipazione della minaccia stessa. Il CERT usualmente (ma non unicamente) comunica ed interpreta dati appartenenti alla Threat Intelligence condivisa o privata (di cui potrebbe essere dotato) al fine di comprendere il "movimento" delle nuove minacce e l'evoluzione delle minacce conosciute per concordare assieme al CSIRT le indicazioni procedurali su come migliorare le policies aziendali e comunica con il SOC per meglio identificare minacce specifiche.

Il CERT suggerisce linee guida e ne controlla la reale messa in produzione. Principali strumenti utilizzati dal CERT sono threat intelligence platform, sistemi di gestione ticketing, honey pot e dashboard di visualizzazione big data. La seguente immagine esprime alcune keyword ed il rispettivo posizionamento all'interno dei rispettivi teams. Ancora una volta si ribadisce che non vi è una distinzione netta ma piuttosto somiglianze "forti" e somiglianze "deboli" ed è assolutamente corretto e normale identificare il proprio team come una intersezione dei presenti.

Durante il decennio trascorso i tre stereotipi hanno assunto qualifiche differenti per rispondere a domande specifiche spesso correlate ma non necessariamente unite. Per questo motivo all'interno di ognuno di essi sono presenti (o vi sarà la necessita di avere) figure professionali con esperienze e curricula differenti tra loro. Proprio in accordo con quanto affermato in precedenza ogni team necessita di esperti analisti capaci di comprendere cosa sia accaduto (in termine di sicurezza) e quale sia stato l'evento scatenante dell'incidente. Non sono necessarie figure capaci di attuare azioni di "reverse engineering" e/o di "Malware analysis", infatti come già discusso in un altro articolo tali figure sono più efficaci se appartenenti ad un team esterno all'organizzazione. Gli analisti presenti in ogni team dovrebbero comprendere le dinamiche di un incidente come per esempio (ma non limitato a): comprensione della minaccia in atto, fondamenti di Networking, comprensione di analisi di logs di sistema e capacita di gestione degli incidenti.

Nello specifico i Security Operation Centers necessitano di personale qualificato a livello infrastrutturale: dotati di certificazioni di prodotto, di certificazioni di Penetration Testing / Vulnerability Assessment (TP/VA) e di capacità di managing e di gestione degli incidenti. Un Computer Emergency Response Team necessita di figure professionali rivolte alla Threat Intelligence, all'info sharing con micro capacita di sviluppo software per meglio favorire i processi di comunicazione automatici attraverso i defacto standards (come per esempio: STIX/TAXII) e personale adibito alla creazione di policies organizzative. Infine un CSIRT necessita di figure professionali inerenti al risk management e capace di integrarsi perfettamente con la propria organizzazione studiando e conoscendo processi di business, dipartimenti, responsabili dei dati e di processo. Capacità tecniche rivolte a servizi di PT/VA e profonda comprensione del network aziendale sono caratteristiche non sempre presenti ma di gran lunga desiderate.