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à.

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.

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.

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 adottino. 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à.

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.

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.

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.

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à.

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.

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.

Questa sezione è dedicata a tutte le informazioni utili per contattare uno CSIRT. \\
Le elencheremo senza commentarle dato che sono autoesplicative:

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:

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.

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.

Vediamo ora quali politiche devono rendere note gli CSIRT.

In questa sezione vanno elencati brevemente i ''tipi di incidente'' che il response team è in grado di affrontare ed i ''livelli di supporto'' che offrono durante la gestione. Questi ultimi possono variare a seconda di una serie di fattori come il carico di lavoro del team o le 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.

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à

* ''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

La comunicazione è importante anche se la maggior parte delle informazioni, essendo legate alla sicurezza, sono di carattere riservato; 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.

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.

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.

* ''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

* ''categorizzazione delle informazioni'' relative all'incidente (quelle dai contatti, dai file di log, ...)

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.

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.

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 assestment'': 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 occorso, 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 logfile, ...)
* ''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

* 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

Questa sezione è dedicata a tutte le informazioni utili per contattare un dato CSIRT. \\
Le elencheremo semplicemente dato che sono autoesplicative:

* time zone (fuso orario)

Le constituency sono quei soggetti che richiedono l'intervento o il supporto di uno CSIRT, dunque la loro definizione 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.

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.

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, al di fuori è soggetta alla discussione e decisione della comunità. Nel secondo caso i response team possono muoversi in modo decisamente più autonomo.

In questa sezione vanno elencati brevemente i tipi di incidente che il response team è in grado di affrontare ed i livelli di supporto che offrono durante la gestione. Questi ultimi possono variare a seconda di una serie di fattori come il carico di lavoro del team o le informazioni disponibili, fattori che vanno in ogni caso riportati e motivati. Ultima 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.

Un altro tipo di informazione che gli CSIRT devono diffondere riguarda tutti quei soggetti con cui interagiscono abitualmente, 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; con questa sezione verranno date delle risposte.

Vediamo quali sono i gruppi con cui i response team possono interagire:
* ''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 aggiornare circa la situazione e per chiarire le aspettative dei loro assistiti
* ''altri'', come ad esempio le organizzazioni che li sponsorizzano o organismi di ricerca

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.

Tra le politiche da elencare vi sono ovviamente anche quelle che riguardano il sistema con cui gli CSIRT garantiscono la sicurezza delle comunicazioni tra loro e tra 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, segnalarne le violazioni.

È opportuno utilizzare moduli diversi a seconda del tipo di segnalazione, ad esempio una per gli incidenti e un'altra per la notifica di vulnerabilità.

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, dato che 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.

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 adottino. 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à.

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 proprio supporto. Andremo dunque dagli CSIRT più grandi come il [@CERT Coordination Center@], a quelli più limitati 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, così che ci sia un sistema semplice e univoco per accedervi ulteriormente agevolato dall'esistenza dei 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, sarebbe bello scoprire se nel frattempo è stata realizzata.

Ultima cosa da osservare prima di concludere il capitolo è che bisogna garantire l'autenticità della fonte delle informazioni, ad esempio utilizzando firme digitali che la attestino; è di prioritaria importanza garantire che la constituency non stia 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. Va a questo proposito fatta una distinzione tra i “peering agreement” e le semplici collaborazioni: i primi prevedono una condivisione completa delle informazioni dei rispettivi constituent, con gli altri invece 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.

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?).

Dopo averne tanto parlato, finalmente vediamo che tipo di informazioni deve pubblicare uno CSIRT per farsi conoscere dalla comunità. Non tutte quelle che vedremo sono obbligatorie (a rigor di logica, nessuna lo è), ma sono fortemente consigliate.

Gli CSIRT possono cambiare nel tempo alcuni dettagli e caratteristiche, dunque è fondamentale che il documento sia aggiornato e che vengano fornite informazioni aggiuntive sul come controllare che ci siano update.

Abbiamo i seguenti campi: