Torna alla pagina di Gestione degli incidenti informatici
:: Incidenti informatici e loro gestione ::
Ove non meglio specificato, tutti i testi tra virgolette vanno intesi come citazioni letterali dalle slide del prof Dario Forte, 2008.
Per incidente informatico si intende una classe generale di imprevisti e malfunzionamenti (anche accidentali) hardware o software. Nel corso di questa materia tratteremo in particolare gli incidenti informatici di sicurezza, definiti nel glossario della RFC 2350 come eventi negativi che compromettono alcuni aspetti del computer, della rete o della sicurezza. Potrebbero essere ad esempio violazioni delle politiche di sicurezza aziendali, l'infrangimento di alcune leggi, o più in generale un qualsiasi evento che mini la stabilità del sistema.
Gli incidenti informatici di sicurezza possono essere classificati in base a diversi parametri: gli asset, i livelli di pericolosità (ad esempio assegnandogli un valore da 0 a 5) e il tipo di supporto richiesto (se legale e/o organizzativo).
Gli asset sono i beni nell'ambito aziendale, e possono essere materiali (come sedie, tavoli, computer, ...) o immateriali (software, politiche, procedure, brevetti, progetti, ...); i secondi sono chiamati asset informativi e sono tra i principali obiettivi di violazione. In base agli asset gli incidenti informatici si possono suddividere in:
E' fondamentale tenere in alta considerazione gli asset perché hanno a che fare coi soldi, e i soldi sono il primo interesse di una qualsiasi azienda o attività. Vedi esempio del prof: in un convegno importantissimo che riguardava grossi investimenti su asset aziendali, un relatore che non ha saputo rispondere alla domanda su quanto costa un pc ha perso immediatamente l'interesse di buona parte degli investitori.
Di qualsiasi tipo siano, la regola numero uno da seguire nella gestione di un incidente informatico è trattarlo come un potenziale sbocco giudiziario, anche se nel momento in cui si agisce non è ancora previsto di arrivare in tribunale. Tutto ciò che si fa deve essere quindi documentabile e documentato perché potrebbe essere usato contro di noi. Va inoltre tenuto conto del decreto legge n.231 dell'8 giugno 2001, che introduce l'obbligo di dover rispondere come persona giuridica per i reati commessi all'interno della propria struttura.
Vedremo ora una serie di esempi di incidenti informatici di sicurezza, i primi dei quali riguardano violazioni del paradigma C.I.A. (Confidentiality, Integrity, Availibility).
La confidentiality (segretezza) è strettamente correlata alle operazioni di lettura, e prevede che un'informazione possa essere rilasciata - direttamente o indirettamente - solo agli utenti autorizzati a conoscerla. Vediamo due esempi di violazione:
L' integrity riguarda le operazioni di scrittura e stabilisce che le informazioni e le risorse non possano essere modificate, cancellate o distrutte in modo non autorizzato o improprio. Un incidente informatico può compromettere l'integrità di diverse entità:
L' availability (disponibilità) si riferisce al fatto che le risorse devono essere sempre disponibili agli utenti autorizzati; per risorse si intende informazioni, applicazioni, servizi, sistemi e reti. Un esempio tipico di incidente informatico che inficia l'availability sono gli attacchi Denial of Service (DoS) e Distributed DoS (DDoS).
La Reconnaissance (ricognizione) consiste nell'attività di ricerca di informazioni utili da parte degli attaccanti per portare a termine l'attacco stesso. Tali informazioni possono essere recuperate ad esempio con il port scanning, ovvero la ricerca di servizi in esecuzione sul computer remoto (molto semplice e frequente), oppure con il vulnerability scanning che prevede una ricerca specifica delle vulnerabilità dei servizi stessi (più invasivo). Difficilmente un'azienda considera il port scanning un evento da riportare sotto l'ambito della gestione degli incidenti informatici, tuttavia viene trattato come segnale precursore di un potenziale attacco.
I virus e i worm sono codici malevoli che compromettono l’integrità dei dati presenti sul PC della vittima.
Gli accessi non autorizzati possono essere sia logici che fisici, e sono ovviamente portati a termine da utenti che non hanno il permesso di accedere a una risorsa. Possono essere di diversi tipi (elenchiamo dalle slide di Dario Forte, 2008):
Concludiamo osservando che se un amministratore di sistema abusa dei suoi privilegi per effettuare accessi non autorizzati, la sua stessa posizione rappresenterà un aggravante in sede legale.
Utilizzo inappropriato è il termine generale per indicare le violazioni alle politiche interne dell'azienda. Possono essere di molti tipi diversi, vediamone alcuni esempi:
C.I.A.
L' Incident Management è l'insieme di politiche e procedure di risposta all'incidente informatico di sicurezza. Definiamo i concetti di politica e procedura:
La gestione dell'incidente informatico prevede diverse attività, tra cui:
Il framework di incident management è così strutturato:
Studiamoli ora nei particolari.
La pre-incident preparation comprende tutta quella serie di operazioni di tipo preparativo finalizzate alla prevenzione e alla reazione dell'incidente informatico in ambito aziendale. Dato che la durata della fase di preparazione è inversamente proporzionale al tempo di risoluzione del problema, è molto utile consultare l'amministratore per velocizzarla.
Entrando più nello specifico, andrebbero pianificate:
Questa fase non è assolutamente da sottovalutare: Dario Forte insegna che
"più siamo preparati e meno impiegheremo nell'analisi".
Con incident detection si intende la rilevazione e il riconoscimento dell'incidente informatico. Pur essendo particolarmente complessa, questa fase è assolutamente necessaria: solo scoprendo cosa e come è successo si potrà evitare che quell'incidente si verifichi di nuovo.
Per l'incident detection ci possiamo avvalere di strumenti tecnologici come ad esempio l' Intrusion Detection System (IDS), i log correlator, i firewall e gli antivirus; inoltre si può fare affidamento sulle segnalazioni degli utenti e di terze parti coinvolte nell'incidente (Autorità Giudiziaria compresa).
Le difficoltà di questa fase non dipendono solo dalla complessità del caso in esame, ma anche dalle conoscenze tecniche di chi conduce l'indagine e dalle prestazioni dei sistemi che gestiscono le informazioni (che possono dover arrivare a lavorare su terabyte di dati).
La risposta iniziale all'incidente avviene con la formazione dello CSIRT (Computer Security Incident Response Team) e con la raccolta delle fonti di prova iniziali, anche dette digital evidence. Per quanto riguarda gli CSIRT vale la pena consultare la RFC 2350 o i capitoli successivi, mentre per le fonti di prova la RFC 3227.
La raccolta delle evidence avviene con l'acquisizione delle immagini disco e dei log, e con l'elaborazione di tali informazioni. In particolare, l'acquisizione delle immagini disco deve essere fatta con programmi appositi come DD che effettuano una copia approfondita bit-by-bit (dal cluster 0 all'ultimo) dei dati contenuti sul disco, indipendentemente dal fatto che siano integri, cancellati o modificati.
Anticipiamo qui che l'analisi andrebbe fatta sempre sulle copie (dette per questo motivo copie forensi), così da non compromettere mai gli originali ed esserne sempre sicuri dell'autenticità.
In base alle politiche aziendali e ad eventuali necessità va a questo punto formulata una strategia di incident response. Vediamone alcuni tipi:
In questa fase vanno prese inoltre decisioni informative e di interazione con l'opinione pubblica (public relation). Le decisioni informative pianificano le modalità con cui si informano ed eventualmente si richiedono autorizzazioni all'Autorità Giudiziaria per utilizzare in tribunale fonti di prova raccolte in modo non lecito, ad esempio quelle che hanno violato la legge sulla privacy.
Per quanto riguarda l' investigazione dell'incidente andrebbero sempre seguite alcune semplici regole:
log analysis"
correlazione degli eventi"
Il reporting è la documentazione e presentazione delle informazioni raccolte nei vari momenti dell'indagine, dunque va fatta sempre e non solo a questo punto del framework. Nella stesura dei report bisogna tener conto del tempo a disposizione per la sua redazione, del metodo di diffusione che verrà usato e delle conseguenze di eventuali violazioni delle policy.
Tra le figure a cui vanno presentati i report vi sono sicuramente il management aziendale, il reparto legale, altri CSIRT e in alcuni casi anche le forze dell'ordine o le autorità giudiziarie.
La fase di risoluzione dell'incidente è quella che comprende tutte le operazioni atte a risolvere l'incidente informatico, ripristinare il sistema (ad esempio con backup o reinstallazioni) e capire cosa sia effettivamente successo per evitare che il problema si ripresenti in futuro. Limitarsi a ripristinare il sistema allo stato precedente l'incidente non è altro che un palliativo, dal momento che la vulnerabilità che era stata sfruttata in passato potrebbe essere riusata in futuro. Bisogna quindi fare tesoro delle lezioni apprese affinché non si verifichi lo stesso incidente, attività questa che prende il nome di lesson learned e che purtroppo è spesso sottovalutata.