Torna alla pagina di Gestione degli incidenti informatici
:: RFC 2350 ::
Le aspettative sulla gestione degli incidenti informatici
1 Introduzione
La RFC 2350 stabilisce alcune linee guida circa l'organizzazione e le modalità di comunicazione di un "Computer Security Incident Response Team" (CSIRT), ovvero la squadra che esegue, coordina e supporta la gestione degli incidenti di sicurezza che possono coinvolgere sistemi informatici di determinati soggetti, chiamati constituency. Questi ultimi hanno l'interesse (e il diritto) di conoscere in primo luogo quali sono le aree di competenza e le capacità di un response team, in secondo luogo quali politiche e procedure operative adottano. Uno degli obiettivi della RFC è proprio quello di definire un modello standard per la diffusione delle informazioni tra gli CSIRT e il resto della comunità.
2 Campo di applicazione
Perché vi sia una corretta interazione tra gli CSIRT e i rispettivi constituency, all'intera comunità devono essere ben chiare le politiche e procedure dei response team, i loro rapporti con altri team o terze parti, quali canali di comunicazione utilizzano e come provvedono a renderli sicuri. I capitoli seguenti approfondiranno questi tre temi.
2.1 Pubblicazione di politiche e procedure
Dal momento che esistono molti tipi diversi di CSIRT più o meno grandi e più o meno specializzati, un potenziale constituent dovrebbe poterne conoscerne i servizi offerti e le politiche prima ancora di contattarli. Tale conoscenza è vantaggiosa sia perché l'utente saprebbe già cosa aspettarsi dal response team ("può aiutarmi? E se sì, si limiterà a un unico intervento o anche ai successivi? Si occuperà anche degli aspetti legali?"), ma anche perché potrebbe segnalare l'incidente nel modo a loro più congeniale, così che l'intervento possa essere il più rapido ed efficiente possibile.
La principale caratteristica che distingue i vari response team è la grandezza del loro perimetro operativo, ovvero all'interno di quale ambito sono in grado di offrire il loro supporto. Andremo dunque dagli CSIRT più grandi come il CERT Coordination Center a quelli più ristretti come il DFN-CERT e il CIAC, fino ad arrivare ai team più piccoli confinati spesso a livello aziendale.
Indipendentemente dalla loro estensione abbiamo già ricordato più volte quanto sia importante che comunichino il maggior numero di informazioni utili possibili alla comunità. E' importante sottolineare il termine "utile", dato che non tutte le procedure (ad esempio quelle tecniche di basso livello) aiutano gli utenti nella scelta.
Il sistema con cui queste informazioni venivano diffuse in passato era a discrezione del CSIRT: alcuni diffondevano i loro quadri operativi, altri le FAQ, altri distribuivano documenti illustrativi alle conferenze, altri facevano uso di newsletter.
Con questa RFC viene raccomandato ad ogni response team di pubblicare politiche e procedure su un proprio sito web, non solo per avere una semplice e univoca modalità d'accesso, ma anche per usufruire dei vantaggi offerti dai motori di ricerca.
Nel momento in cui si scriveva la 2350 non esisteva ancora una repository centrale che contenesse i documenti informativi di tutti gli CSIRT, anche se sul sito del CERT (http://www.cert.org/) e del first (http://www.first.org/) ne possiamo trovare moltissimi.
Ultima cosa da osservare prima di concludere il capitolo è che bisogna assicurare l'autenticità della fonte delle informazioni, ad esempio utilizzando firme digitali che la attestino; è di prioritaria importanza garantire alla constituency che non sta consultando un documento manomesso.
2.2 Relazioni tra i diversi CSIRT
Non tutti gli incidenti informatici possono essere interamente gestiti da un unico CSIRT, ma accade spesso che questi debbano interagire con altri team o terze parti che si estendono al di fuori del loro perimetro. In questo caso anche i constituency si dovrebbero adeguare, consentendo ad esempio che alcune informazioni sensibili che li riguardano possano essere divulgate agli altri response team che stanno collaborando alla gestione. A questo proposito va fatta una distinzione tra i "peering agreement" e le semplici collaborazioni: i primi prevedono una condivisione completa delle informazioni dei rispettivi constituent, mentre con i secondi si intendono semplici aiuti e consulenze. Le differenze sono sostanziali, dunque è essenziale che gli CSIRT stipulino tra loro accordi chiari e circostanziati, con un'attenta valutazione dei dettagli: l'abilità di un response team si vede anche dalla capacità di instaurare questo genere di rapporti.
2.3 Costituzione di comunicazioni sicure
Se uno CSIRT decide di instaurare una "peering agreement" con un altro team sorge il bisogno di condividere informazioni, dunque vi è necessità di assicurare la sicurezza del canale di comunicazione. Per sicurezza non intendiamo l'uso appropriato dei dati, ma la garanzia di riservatezza, integrità e autenticità.
Come fare? Le tecniche di crittografia vengono in soccorso, posto che ci si accordi in fase di preparazione sulle modalità e i meccanismi, in particolar modo sulle chiavi crittografiche (pubbliche o private?).
3 Informazioni, politiche e procedure
Dopo averne tanto parlato, finalmente vediamo che tipo di informazioni deve pubblicare uno CSIRT per farsi conoscere dalla comunità. Non tutte quelle di cui parleremo sono obbligatorie (a rigor di logica, nessuna lo è), ma sono fortemente consigliate.
3.1 Ottenere il documento
Gli CSIRT possono cambiare nel tempo alcuni dettagli e caratteristiche, dunque è fondamentale che il documento sia aggiornato e che vengano fornite informazioni sul come e dove controllare gli update.
Abbiamo i seguenti campi:
- data dell'ultimo aggiornamento
- liste di distribuzione (ad esempio mailing list), ovvero meccanismi (resi sicuri da digital signature) per diffondere le notizie sugli ultimi update a un vasto numero di utenti
- ubicazione del documento, cioè l'indirizzo (o il luogo) in cui è sempre possibile trovare l'ultima versione. Il response team si assume la responsabilità di mantenerlo aggiornato e di garantirne l'autenticità con firme digitali
3.2 Informazioni di contatto
Questa sezione è dedicata a tutte le informazioni utili per contattare uno CSIRT.
Le elencheremo senza commentarle dato che sono autoesplicative:
- nome dello CSIRT
- indirizzo fisico e di posta elettronica
- time zone (fuso orario)
- numero di telefono
- numero di fax
- altri recapiti
- chiavi pubbliche e tecnica crittografica utilizzata
- membri del team
- orario di servizio
- varie ed eventuali, ad esempio siti web di riferimento, indirizzi per le mailing list, ...
3.3 Charter
Nel charter (letteralmente carta, ma anche "documento ufficiale") vengono date informazioni sulla missione che si è prefissa il CSIRT e sulle autorità da cui dipende. Dovrebbe includere almeno quattro elementi:
- mission statement
- constituency
- sponsorship / affiliation
- authority
Li abbiamo elencati nei loro termini originali, ora li esamineremo più nel dettaglio.
3.3.1 Mission statement
Indica con chiarezza e precisione gli obiettivi e le finalità che si sono prefissi i response team, e poiché stiamo parlando di CSIRT ci aspettiamo che tra questi ci sia anche la gestione degli incidenti informatici.
3.3.2 Constituency
Le constituency sono quei soggetti che richiedono l'intervento o il supporto di uno CSIRT, dunque la loro dichiarazione aiuterebbe a comprendere il perimetro di lavoro dei response team stessi. Nel caso in cui gli CSIRT non potessero diffondere questo tipo di informazione (ad esempio per via delle leggi sulla privacy) dovrebbero comunque spiegarne le ragioni.
3.3.3 Sponsoring organization / affiliation
La conoscenza degli organismi che supportano e finanziano le attività degli CSIRT è un'informazione molto importante per i potenziali constituent, necessaria per comprendere l'ambiente in cui operano ed instaurare di conseguenza un rapporto di fiducia.
3.3.4 Authority
Per authority si intende la linea di riporto del response team, ovvero a chi questi deve riferire.
Le informazioni di questa sezione dipendono molto dal tipo di rapporto esistente tra response team e constituency: in un contesto aziendale l'autorità viene concessa dal management, mentre al di fuori è soggetta alla discussione e al pronunciamento della comunità. Nel secondo caso i response team possono muoversi in modo decisamente più autonomo.
Un concetto molto importante da sottolineare è che non è detto che uno CSIRT abbia l'autorità di operare in tutti i sistemi all'interno del proprio perimetro, ma dipende dai rapporti di dipendenza gerarchici del team nei confronti di altri soggetti (altri CSIRT o il management).
Osserviamo infine che il fatto di rendere nota l'autorità di un response team espone quest'ultimo all'assunzione di un certo numero di responsabilità aggiuntive, delle cui conseguenze legali dovrebbe essere ben informato.
3.4 Politiche
Vediamo ora quali politiche devono rendere note gli CSIRT.
3.4.1 Tipi di incidente e Livelli di supporto
In questa sezione vanno elencati brevemente i tipi di incidente che il response team è in grado di affrontare ed i livelli di supporto che offre durante la gestione. Questi ultimi possono variare a seconda del carico di lavoro del team o delle informazioni disponibili, fattori che vanno sempre riportati e motivati. Altra precisazione per quanto riguarda i tipi di incidenti: dato che è impensabile elencarli tutti – soprattutto se pensiamo a quelli non ancora conosciuti – è utile definire una serie di scenari generici supportati dallo CSIRT.
3.4.2 Cooperazione, interazione e comunicazione di informazioni
Un altro tipo di informazione che gli CSIRT devono diffondere riguarda tutti quei soggetti con cui interagiscono abitualmente, e non solo per le attività di risposta agli incidenti. I constituent potrebbero infatti chiedersi chi avrà accesso ai report e alle statistiche del team, o se questo interverrà direttamente o attraverso un altro CSIRT; in questa sezione verranno date delle risposte.
I gruppi con cui i response team possono interagire sono:
- incident response team, ovvero altri CSIRT. Queste cooperazioni sono frequenti soprattutto per la gestione di attacchi su vasta scala e spesso comportano la condivisione di informazioni a vario titolo e con diverse modalità
- fornitori, che svolgono un ruolo di fondamentale importanza in quei casi in cui l'incidente è legato a vulnerabilità dei loro prodotti
- forze dell'ordine, ovvero polizia o altre agenzie investigative. A tal proposito va ricordato che uno CSIRT deve lavorare tenendo sempre ben presente gli aspetti legali dell'incidente e del suo operato
- stampa, un organismo cui i constituent sono particolarmente sensibili. Un response team deve approcciarsi ad essa per aggiornarla circa la situazione e per chiarire le aspettative dei loro assistiti
- altri, come ad esempio le organizzazioni che li sponsorizzano o organismi di ricerca
La comunicazione è importante anche se la maggior parte delle informazioni, essendo legate alla sicurezza, sono di carattere riservato; tuttavia uno CSIRT troppo riservato dal punto di vista informativo difficilmente otterrà collaborazione e fiducia dagli altri. Il modello di documento che sta delineando questa RFC dà preziosi consigli sul cosa diffondere, a chi e quando.
Concludiamo osservando che alcuni fattori da cui dipende la libertà di comunicazione dei response team sono gli ordinamenti giuridici locali (spesso molto differenti tra CSIRT che operano in diverse nazioni o giurisdizioni) e i conflitti di interessi con altri constituent che potrebbero trarre vantaggi dalle loro informazioni.
3.4.3 Comunicazione e autenticazione
Tra le politiche da elencare vi sono ovviamente quelle che riguardano il metodo con cui gli CSIRT garantiscono la sicurezza delle comunicazioni tra loro e con i committenti. Andranno dunque descritte le tecniche crittografiche utilizzate (ove consentito), fornite le chiavi pubbliche, specificato l'utilizzo di firme digitali, ecc... accompagnando a tali informazioni le linee guida da seguire per verificarle e, nel caso, segnalare violazioni.
Ovviamente non va detto tutto tutto, le password ad esempio è meglio tenerle per sé (nessuno affiderebbe la gestione di un incidente informatico di sicurezza a qualcuno che dà in giro le password per accedere ai loro sistemi. O almeno, non io).
3.5 Servizi
I servizi offerti da uno CSIRT possono essere distinti in "attività in real time di risposta agli incidenti" e "attività proattive di supporto alla gestione non in real time". Entriamo nei particolari.
3.5.1 Risposta agli incidenti
La fase di risposta include la valutazione delle segnalazioni di un incidente (Incident Triage), il coordinamento con altri CSIRT, con ISP o siti (Incident Coordination), e infine – opzionale – la risoluzione e il ripristino del sistema (Incident Resolution). Esaminiamo ognuna di queste sottofasi elencandone i campi.
3.5.1.1 Incident Triage
L'incident triage generalmente include:
- report assesment: valutazione e interpretazione del report di segnalazione dell'incidente, assegnamento di priorità, relazionamento tra gli incidenti in corso e le tendenze
- verifica: aiuto nel determinare se l'incidente è realmente avvenuto, e se sì qual è il suo campo di applicazione
3.5.1.2 Incident Coordination
L'incident coordination generalmente include:
- categorizzazione delle informazioni relative all'incidente (quelle dai contatti, dai file di log, ...)
- coordinamento, ovvero la notifica delle altre parti con cui andranno condivise le informazioni (sempre nel rispetto delle politiche di divulgazione)
3.5.1.3 Incident Resolution
L'incident resolution generalmente include:
- assistenza tecnica, che potrebbe includere l'analisi del sistema compromesso
- eradication, cioè la rimozione della vulnerabilità che ha permesso l'incidente di sicurezza e dei suoi effetti
- recovery, ovvero il ripristino del sistema allo stato precedente l'incidente
3.5.2 Attività proattive
Sono una serie di servizi opzionali aggiuntivi come: fornitura di informazioni su vulnerabilità note e patch, installazione di strumenti di sicurezza, formazione del personale, valutazione di siti web e prodotti.
3.6 Moduli di segnalazione degli incidenti
L'utilizzo di moduli di segnalazione concordati tra CSIRT e committenti rende infinitamente più semplice ed efficiente la gestione degli incidenti informatici. I primi possono in questo modo ricevere tutte le informazioni che ritengono necessarie per la risposta scritte nel modo a loro più congeniale; i secondi possono invece usufruire di una struttura di segnalazione già conosciuta prima dell'incidente, così che possano affrontarlo più preparati.
È opportuno utilizzare moduli diversi a seconda del tipo di segnalazione, ad esempio una per gli incidenti e un'altra per la notifica di vulnerabilità.
3.7 Avvertenze
Anche se il documento che descrive lo CSIRT non è un contratto implica comunque un certo livello di responsabilità nei confronti dei committenti che lo consultano; questi infatti baseranno il loro livello di fiducia (e interesse) sulle capacità e sui servizi descritti. È dunque opportuno che i response team concludano il loro documento con una sezione dedicata alle avvertenze, in cui segnalare agli utenti tutte le possibili limitazioni e distinguo cui potrebbero essere soggette le informazioni date.
Appendice D: il modello di un documento CSIRT
Concludiamo con lo schema che dovrebbero seguire gli CSIRT nella redazione del proprio documento informativo. I vari punti li abbiamo già spiegati, quindi mi limiterò ad elencarli:
1. Informazioni sul documento
1.1 Data dell'ultimo aggiornamento
1.2 Lista di distribuzione per le notifiche
1.3 Luoghi in cui tale documento può essere trovato
2. Informazioni di contatto
2.1 Nome dello CSIRT
2.2 Indirizzo
2.3 Fuso orario
2.4 Numero di telefono
2.5 Numero di fax
2.6 Altri recapiti
2.7 Indirizzo di posta elettronica
2.8 chiavi pubbliche e tecniche crittografiche
2.9 Membri del team
2.10 Altre informazioni
2.11 Punti di Contatto
3. Charter
3.1 Mission statement
3.2 Constituency
3.3 Sponsorship e/o Affiliation
3.4 Authority
4. Politiche
4.1 Tipi di incidenti e livello di supporto
4.2 La cooperazione, interazione e la comunicazione di informazioni
4.3 Comunicazione e autenticazione
5. Servizi
5.1 Incident Response
5.1.1. Incident Triage
5.1.2. Incident Coordination
5.1.3. Incident Resolution
5.2 Attività proattiva
6. Moduli di segnalazione degli incidenti
7. Avvertenze
Torna alla pagina di Gestione degli incidenti informatici
