ABC della sicurezza: CERT

Le origini

Il 4 Maggio 1990 un giudice federale degli Stati Uniti d’America condanna Robert Tappan Morris  a  tre anni di libertà condizionata, 400 ore di servizi socialmente utili e 10.050 dollari di multa. Il crimine di cui era accusato, in violazione del Federal Computer Fraud and Abuse Act del 1986, era stato compiuto il 2 novembre del 1988 tramite il primo “worm” della storia di Internet. Il malware progettato da Morris fu in grado di bloccare circa 6.000 computer (pari a circa il 10% delle macchine dotate di una connessione a Internet a quell’epoca), causando danni per 98 milioni di dollari. Fu proprio in seguito a questo evento devastante che il governo degli Stati Uniti, per mano del DARPA e per cercare di prevenire simili episodi in futuro, decise di creare presso la Carnegie Mellon University il Computer Emergency Response Team ovvero il primo CERT della storia.

CERT o CSIRT?

Il termine CERT, usato appunto per la prima volta sul finire degli anni ’80 del secolo scorso per indicare il CERT/CC (CERT Coordination Center), è un marchio registrato (negli USA) dalla Carnegie-Mellon; un termine che ha pari valore, ma che non è sottoposto a vincoli di registrazione è CSIRT ossia Computer Security Incident Respose Team. Dalla sua fondazione, il CERT/CC ha contribuito a costruire una rete formata da più di 50 CSIRT sparsi per il globo con responsabilità nazionali, compreso il US-CERT (il CERT degli Stati Uniti) nato dalla collaborazione con il DHS (Department of Homeland Security).

Oltre ai CSIRT con responsabilità nazionali, la Carnegie-Mellon ha autorizzato una lista di CSIRT a fregiarsi del marchio CERT, tale lista è consultabile qui. Esiste poi il FIRST (Forum of Incident Response and Security Teams) che raggruppa e ne facilita la cooperazione un gran numero di CSIRT disseminati per il mondo.

La missione

Ma qual è lo scopo di un CERT? I CERT sono lo strumento chiave per la protezione delle infrastrutture critiche e ogni nazione connessa ad Internet deve disporre delle capacità di rispondere in maniera efficace ed efficiente agli incidenti di sicurezza informatica, i CERT sono in grado di dare queste risposte, ma possono e devono fare molto di più grazie alla loro ruolo. Ad esempio devono agire come promotori di consapevolezza sulle minacce incombenti e come educatori nell’ambito della sicurezza informatica. Sia nella sigla CERT che in quella CSIRT si fa riferimento alla parola “response” ossia risposta, in effetti il “core business” dei CERT è la gestione degli incidenti di sicurezza (incident management), la quintessenza del concetto più ampio di gestione degli incidenti è in definitiva l’incident handling, ossia proprio la risposta all’accadimento di un incidente.

Qualsiasi entità che si definisca CERT, che sia essa una squadra di persone, un servizio, un processo o una funzione, non ha tuttavia come unisco scopo quello di reagire agli incidenti, bensì – come detto – deve farsi carico di tutte le attività inerenti la sicurezza degli asset, dei beni e dei processi che ha il compito di proteggere; quindi deve essere parte attiva nella prevenzione, nell’alimentare la consapevolezza degli utenti finali e di ogni stakeholder, nella “detection” degli incidenti, nella loro risoluzione e nel fare tesoro delle esperienze pregresse al fine di non ripetere i medesimi errori (‘lesson learnt’). Da questa breve descrizione dei compiti si inizia ad intravedere quella che è l’importanza dei CSIRT. Gli incidenti di sicurezza accadono e continueranno ad accadere sempre più frequentemente, almeno stando alle statistiche. Alla numerosità degli incidenti è associata anche una sempre maggiore sofisticatezza degli attacchi e nessun “luogo” può considerarsi sicuro, nemmeno piccole scuole o organizzazioni sperdute, per non parlare di grandi reti, di banche o di strutture governative e militari. Inoltre, elevate contromisure di sicurezza perimetrale, tendenti ad isolare le organizzazioni dal resto del mondo, non mettono al riparo al 100% le organizzazioni stesse, non foss’altro per il fatto che molti degli attacchi (e quindi degli incidenti) che hanno successo hanno origine dall’interno (le cosiddette “insider threat”).

Un concetto mai troppo enfatizzato è quello del miglioramento continuo, in sostanza il compito di un CERT non è solo quello di prevenire, reagire, risolvere problemi, ma anche quello di innescare un circolo virtuoso che faccia tesoro degli errori del passato.

Quali altri aree, oltre all’incident handling, vedono il CERT come protagonista?

Sicuramente un’area in cui un CERT deve essere impegnato è il Vulnerability Management, ma non solo, il CERT deve essere promotore e divulgatore di bollettini, annunci, allarmi di sicurezza (early warnings), preferibilmente mirati alla realtà in cui operano e ai clienti/utenti di cui sono al servizio. Fra i servizi proattivi di un CERT sono ovviamente da annoverare quelli di Intrusion Detection. Non sono esclusi, fra i compiti di un CERT, servizi di addestramento, istruzione, formazione nell’ambito della sicurezza informatica. In sostanza, nel corso degli anni, i CERT/CSIRT si sono trasformati in fornitori primari di servizi di sicurezza a 360°.

Incident Handling

Torniamo ora alla missione cardine di un CERT, ovvero l’Incident Handling. Per dare un senso immediato alla “mission” di un CERT è sufficiente utilizzare questa semplice frase di esempio, che potrebbe essere l’effettiva mission di un vero CERT: “Lo scopo è quello di contenere gli incidenti di sicurezza informatica in modo che il loro impatto sui processi di business critici sia minimizzato”. Nella sua semplicità ed immediatezza, questa frase racchiude in sé l’essenza del compito affidato ad un CERT: nessuna missione impossibile (gli incidenti avvengono, non è possibile evitarli tout cour), ma il massimo dello sforzo per evitare impatti devastanti sul business. L’incident handling può essere sintetizzato in quattro passi essenziali: Incident Report, Triage, Incident Resolution, Incident Closure.

La fase dell’incident report scatta quando l’incidente viene rilevato, la rilevazione può essere fatta da una “terza parte” che si accorge del problema e lo segnala al CERT stesso (via mail, fax, chiamata telefonica, form web, ecc.), in questo caso il CERT ha un ruolo reattivo. In alternativa può essere il CERT stesso a rilevare l’incidente che viene quindi inserito nel “ciclo di vita” di “incident handling”, in questo caso il ruolo del CERT diventa proattivo.

La fase successiva è quella, importantissima, del “triage” (in analogia a quanto accade all’accesso di un paziente al pronto soccorso). La fase è importante perché, come in qualsiasi processo di business, le risorse sono limitate e quindi ogni attività va eseguita secondo priorità. La fase del “triage” permette di discernere la gravità del problema ed effettuare una iniziale classificazione, in base alla quale la priorità verrà assegnata secondo criteri dipendenti dalla realtà in cui opera il CERT (solo per fare un esempio, supponiamo che un CERT eroghi servizi a più clienti, alcuni governativi/pubblici altri privati; in tal caso probabilmente la priorità verrà data agli incidenti che colpiscono le risorse governative). Il “triage” termina con l’assegnazione dell’incidente, la cui gestione viene affidata alla persona o al team che in quel momento vengono giudicati più idonei.

Si passa poi alla fase più lunga e complessa, ovvero quella della “Incident Resolution”, questa fase a sua volta è composta da un ciclo di passi differenti che vanno dall’analisi alla “eradication and recovery”, ossia la fase finale attraverso la quale il problema viene eliminato e il sistema colpito viene riportato allo stato di normale operatività.

Una volta risolto il problema, l’incidente deve essere ufficialmente chiuso, archiviato e di esso deve essere effettuata la classificazione finale (che può risultare differente da quella iniziale).

Esiste poi una quinta fase, opzionale, che è quella della “Post-analysis” da riservare agli incidenti giudicati significativi, magari più complessi da gestire o che corrispondono a nuovi vettori di attacco. Questa fase di analisi a posteriori può essere molto utile per dare linfa al processo di miglioramento continuo del CERT a cui ho accennato in precedenza.

Conclusioni

In un breve contributo come questo risulta impossibile trattare l’argomento in maniera esaustiva, quello che ritengo tuttavia importante sottolineare è quanto l’azione dei CERT/CSIRT sia fondamentale per la “salute” globale dell’interconnesso ecosistema in cui ci muoviamo ogni giorno. Dall’incidente del “Morris Worm” in poi, la comunità di Internet si è resa conto di quanto la collaborazione, l’attenzione, la condivisione e lo scambio di informazioni siano importanti per garantire la maggior resistenza possibile agli attacchi da parte di quello che possiamo chiamare “organismo Internet”.