* 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 opportuno chiedersi se esistono politiche di sicurezza sufficienti o se ce ne sono altre che è opportuno proporre

* ''Legal Assessment'': 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 Assessment'': quantifica il danno economico generato dall'incidente informatico.

* ''raccolta e gestione delle evidence'': si raccolgono tutte le possibili fonti di prova seguendo un modello investigativo che sarà illustrato nelle prossime lezioni

Il '''reporting''' è la documentazione e presentazione delle informazioni raccolte nei vari momenti dell'indagine, dunque va fatto 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.\\

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 rimarrebbe inalterata. 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.

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 alle segnalazioni degli utenti e di terze parti coinvolte nell'incidente (Autorità Giudiziaria compresa).

L'incident detection ha una difficoltà molto variabile a seconda del caso, ma molto dipende anche dalle conoscenze tecniche di chi opera e dalle prestazioni dei sistemi che gestiscono le informazioni (che possono arrivare tranquillamente a terabyte di dati, di log, ...).

La '''risposta iniziale all'incidente''' avviene con la formazione dello '''CSIRT''' (''Computer Security Incident Response Team'') e delle fonti di prova iniziali. 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.

* "[@ripresa del servizio@]"
* "[@utilizzo di strumenti di Incident Response (Helix, IRItaly, Live CD)@]"

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 di 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 non fosse 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.

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:
* ''furto di informazioni dai computer portatili''. Sembrerà assurdo ma la maggior parte delle volte questo tipo di incidente è 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 che compromettono la segretezza dei dati sulla macchina e sulla rete aziendale.

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à su diverse entità:

L' ''availability'' (disponibilità) si riferisce al fatto le risorse devono essere sempre disponibili agli utenti autorizzati, dove 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'' (molto semplice e frequente), ovvero la ricerca di servizi in esecuzione sul computer remoto, oppure con il ''vulnerability scanning'' (più invasivo) che prevede una ricerca specifica delle vulnerabilità dei servizi stessi . 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.

* 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 permessi a lui concessi per effettuare accessi non autorizzati, il fatto di essere amministratore rappresenta per lui un aggravante in sede legale.

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

* accesso a siti pornografici o non inerenti l'attività aziendale, non tanto perché rappresentano attività legalmente perseguibili, ma perché potrebbero compromettere uno degli aspetti C.I.A.

* 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 opportuno chiedersi se esistono politiche di sicurezza sufficienti o se non ce ne sono alcune che è opportuno proporre

* ''Legal Assessment'': la serie di processi per verificare il distacco (''gap'' per i più fighi) tra il reale stato aziendale e quello che dovrebbe essere secondo la legge. E' generalmente compiuto da avvocati esperti;
* ''Damage and Risk Assessment'': quantifica il sicuro danno economico generato dall'incidente informatico.

Entrando più nello specifico, andrebbe pianificato:
* le procedure da seguire in caso di incidente per continuare a garantire il servizio (pensate a quanto ciò sia importante per i servizi bancari)
* stabilire chi sono i ''Point Of Contact'' ('''P.O.C.'''), ovvero i contatti da interpellare in caso di incidente; possono essere interni (personale interno all'azienda, ad esempio l'amministratore del servizio informatico) o esterni (libere categorie esterne come Polizia Giudiziaria, Legali, CERT, etc...)

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

La '''risposta iniziale all'incidente''' avviene con la formazione dello '''CSIRT''' (''Computer Security Incident Response Team'') e delle fonti di prova iniziali. Per quanto riguarda gli CSIRT vale la pena consultare la [[RFC 2350]] o i capitoli successivi, mentre per le seconde 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 dei dati contenuti sul disco (dal cluster 0 all'ultimo), integri cancellati o modificati che siano.

* ''identificazione dell'attaccante'': si correlano le varie informazioni raccolte così da capire come ha agito, da dove e possibilmente chi è

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 violando la legge sulla privacy.

* dal momento che è molto probabile che a un incidente ne segua un altro a catena, è molto utile fare ''snapshot'' incrementali del sistema così da capire cosa è successo o cosa sta succedendopuò essere utile a capire cosa sia successo o stia succedendo
* effettuare quando possibile una ''Live Analysis''
* se possibile fare sempre esami post-mortem sulle macchine su cui è stato accertata una compromissione

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 alle forze dell'ordine o alle 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. Abbiamo già detto infatti che 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 si ripresenta inalterata. 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.

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

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

* "''ripresa del servizio''"
* "''utilizzo di strumenti di Incident Response'' (Helix, IRItaly, Live CD) "

* dal momento che è molto probabile che a un incidente ne segua un altro a catena, è molto utile fare "snapshot" incrementali del sistema così da capire cosa è successo o cosa sta succedendopuò essere utile a capire cosa sia successo o stia succedendo

* "log analysis"
* "correlazione degli eventi"
* "artifacy analysis"

Il testo tra virgolette va inteso come citazione letterale dalle slide del prof [[Dario Forte]], 2008.