Incidenti informatici e loro gestione

Torna alla pagina di Gestione degli incidenti informatici

---

:: Incidenti informatici e loro gestione ::

Definizione di incidenti informatici di sicurezza

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:

• singoli, che coinvolgono un unico asset. Sono ormai molto rari, trattati esclusivamente a livello accademico
• strutturati, che compromettono più asset e su più perimetri (ovvero gli ambiti che coinvolgono)

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.

Esempi di incidenti informatici

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

Confidentiality

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:

• furto di informazioni dai computer portatili. Sembrerà assurdo ma la maggior parte degli incidenti di questo tipo è dovuto alla sbadataggine di alcuni manager che lasciano il proprio laptop in giro (un classico è dimenticarlo nei pub), così che altri possano accedere a eventuali dati aziendali sensibili. Un'altra occasione di danno si ha quando gli stessi manager usano il portatile a casa e navigano su siti pericolosi che compromettono la macchina, così che quando l'indomani si riconnettono alla rete aziendale producono conseguenze disastrose;
• installazione di programmi (un esempio su tutti, Skype) potenzialmente dannosi e che compromettono la segretezza dei dati sulla macchina e sulla rete aziendale.

Integrity

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

• dati, che dopo essere stati modificati smettono di essere attendibili
• sistema, di cui non è più possibile garantire il funzionamento una volta alterato
• servizi, che smettono di funzionare correttamente

Availability

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

Reconnaissance

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.

Virus e worm

I virus e i worm sono codici malevoli che compromettono l’integrità dei dati presenti sul PC della vittima.

Accessi non autorizzati

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):

• "compromissione da remoto"
• "defacing di siti web"
• "copiare dati sensibili presenti all’interno di DB"
• "accesso remoto tramite modem non autorizzati alla rete"

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

Utilizzo inappropriato è il termine generale per indicare le violazioni alle politiche interne dell'azienda. Possono essere di molti tipi diversi, vediamone alcuni esempi:

• download di software non consentito
• accesso a siti pornografici o non inerenti l'attività aziendale, non tanto perché rappresentano in sé attività legalmente perseguibili, ma perché potrebbero compromettere uno degli aspetti C.I.A.
• utilizzo di programmi di file sharing, tra cui si inserisce concettualmente anche Skype
• diffusione volontaria di informazioni sensibili
• utilizzo dei sistemi aziendali per attaccarne altri

Incident management

L' Incident Management è l'insieme di politiche e procedure di risposta all'incidente informatico di sicurezza. Definiamo i concetti di politica e procedura:

• la politica è un insieme di linee guida ad alto livello, espressione delle volontà aziendali. Ad esempio potrebbero essere il divieto di navigare su siti web non inerenti l'attività lavorativa. Quando si lavora è sempre bene chiedersi se esistono politiche di sicurezza sufficienti o se ce ne sono altre che è opportuno proporre
• la procedura è invece il documento attuativo della politica, la parte pratica di più basso livello

La gestione dell'incidente informatico prevede diverse attività, tra cui:

• Incident Response: l'insieme di operazioni da svolgere subito dopo il rilevamento dell'incidente (risposta e ripristino);
• Digital Investigation: le attività di recupero delle informazioni da portare come prove;
• Legal Assesment: la serie di processi per verificare il distacco (gap) tra il reale stato aziendale e quello che dovrebbe essere secondo la legge. E' generalmente compiuto da avvocati esperti;
• Damage and Risk Assesment: quantifica il danno economico generato dall'incidente informatico.

Framework di incident management

Il framework di incident management è così strutturato:

• pre-incident preparation
• incident detection
• risposta iniziale all'incidente
• formulazione di una strategia di response
• investigazione dell'incidente
• reporting
• risoluzione dell'incidente

Studiamoli ora nei particolari.

Pre-incident preparation

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:

• le procedure da seguire in caso di incidente per continuare a garantire il servizio (pensate a quanto ciò sia importante per i servizi bancari, i router o i web server)
• stabilire chi sono i Point Of Contact (P.O.C.), ovvero i contatti da interpellare in caso di incidente. Possono essere sia interni (personale interno all'azienda, ad esempio l'amministratore del servizio informatico) che esterni (libere categorie come Polizia Giudiziaria, Legali, CERT, eccetera)
• deinifire i ruoli e le responsabilità all'interno del team di risposta
• fare un Hands On sulla log analysis e sull'esame forense così da cercare il maggior numero di punti di correlazione possibile sulle varie fonti. Per log analysis non si intende banalmente solo l'analisi dei log, ma anche la ricostruzione dell'incidente basandosi sul contenuto delle prove. L' esame forense è invece l'esame delle evidence (le prove), ed è eseguita con strumenti di computer forensics che possono essere standalone o distribuiti
• decidere le linee guida da seguire per garantire la sicurezza del sistema
• scegliere le risorse da utilizzare per l'analisi

Questa fase non è assolutamente da sottovalutare: Dario Forte insegna che
"più siamo preparati e meno impiegheremo nell'analisi".

Incident Detection

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

Risposta iniziale all'incidente

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

Strategia di risposta all'incidente

In base alle politiche aziendali e ad eventuali necessità va a questo punto formulata una strategia di incident response. Vediamone alcuni tipi:

• strategia di contenimento: in caso di attacco si cerca di limitare il danno sia in termini economici che di sicurezza; ad esempio in caso di corruzione di una macchina questa viene messa in quarantena e tenuta sotto controllo
• raccolta e gestione delle evidence: si raccolgono tutte le possibili fonti di prova seguendo un modello investigativo che sarà illustrato nei prossimi appunti
• identificazione dell'attaccante: si correlano le varie informazioni raccolte così da capire come ha agito, da dove, e possibilmente chi è
• "ripresa del servizio"
• "utilizzo di strumenti di Incident Response (Helix, IRItaly, Live CD)"

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.

Investigazione dell'incidente

Per quanto riguarda l' investigazione dell'incidente andrebbero sempre seguite alcune semplici regole:

• rispettare l'ordine di volatilità dei dati: la RAM è più volatile dei Log che sono a loro volta più volatili del Disco, quindi alcune componenti andrebbero acquisite ed investigate prima di altre
• dato che in ambienti molto estesi l'attività di acquisizione è estremamente lunga, essendo il tempo un fattore critico si fa in modo che il recupero delle informazioni avvenga in parallelo in modo distribuito (in questo modo la copia di 1000/2000 macchine può avvenire in poche ore)
• validare le prove utilizzando più fonti, cercando sempre più punti di correlazione possibile
• dal momento che è molto probabile che a un incidente ne segua un altro a catena, è molto utile fare snapshot (backup) incrementali del sistema così da capire cosa è successo o cosa sta succedendo
• mettere la preservazione dei dati originali in primo piano, indipendentemente che si stia compiendo una Live System Analysis o un esame Post Mortem
• "log analysis"
• "correlazione degli eventi"
• artifact analysis
• tenere conto del fatto che i risultati ottenuti dall'investigazione devono essere riproducibili (metodo scientifico)

Reporting

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.

Risoluzione dell'incidente

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.

---

Torna alla pagina di Gestione degli incidenti informatici