Gestione del rischio (2)

Per completare questa analisi dei rischi, deve poi seguire un'altra accurata identificazione delle misure adottate (o da adottare) dove, a fronte dei singoli rischi, si applica la classificazione della tabella T1.

N.	Misura	Rischio contrastato	Descrizione Misura adottata	Già adottato Si/No	Chi se ne occupa
	Misure fisiche
1	Sistema antincendio	R13
2	Estintori	R13
3	Conditioning System	R14
4	Video sorveglianza	R11
5	Antifurto	R12
6	Restrizioni accessi	R11, R12
7	UPS	R14
8	Distruggi documenti	R16
	Backup:
9	Hardware	R3, R4, R8, R13, R15
10	Software	R3, R4, R8, R13, R15
11	Procedure	R3, R4, R8, R13, R15
12	Restore	R3, R4, R8, R13, R15
13	Ghosts (image) copies	R3, R4, R8, R13, R15
14	Dispositivi per il controllo accessi	R11
15	Armadi ignifughi	R4, R14
	Hardware:
16	Alimentazione	R8
17	Schede rete	R8
18	Hard Disks	R8
19	Dispositivi Network	R8
20	Connessione internet	R8
21	Clustering	R8
	Policy
22	Password	R1, R2, R3, R4
23	Domain Controllers	R1, R2, R3, R4, R9, R10
24	Firewalls o Routers	R7, R8, R9, R10
25	VPN	R9, R10
26	Funzionalità del SO	R7, R9, R10
27	Piano di Disaster Recovery	R8, R13
	Software tools:
28	Proxy Server	R7, R9, R10
29	Antivirus	R5
30	Anti-Spyware	R9, R10
31	Anti-Spamming	R6
32	Software and OS upgrading tools	R2, R5, R7, R8, R9, R10
	Manutenzione e garanzie
33	Garanzie server	R8
34	Garanzia dispositivi Network	R8
35	Accesso Internet	R8
36	Monitoraggio Network	R8
	Documentation:
37	Procedure documentate	R2, R3, R4, R8, R14, R15
38	Regolamento	R2, R3

Gestione del rischio (1)

Risk Management

Introduzione

La gestione del rischio comprende tutte le attività necessarie dal riconoscimento e consapevolezza fino allo sviluppo di strategie che possano attenuare il rischio.

Una strategia può portare a diversi tipi di comportamento; per esempio "evitare il rischio", "ridurre l'effetto negativo", "trasferire il rischio ad una terza parte (assicurazione, contratti manutenzione)"; "accettare le conseguenze"

Un risk management non ha quindi il compito di eliminare i rischi, ma di ridurlo all'interno di un livello accettato dalla specifica azienda.

Una attenta analisi deve considerare che le minacce possono provenire da differenti sorgenti, come per esempio: l'ambiente, la tecnologia, le persone.

Risk Analysis

Una analisi dei rischi necessita innanzi tutto una classificazione.

Nella tabella T1 è riportata una classificazione a due livelli, avendo suddiviso le minaccie in tre classi.

Il passo successivo è la valutazione della probabilità dell'evento.

Sono considerazioni in parte soggettive e comunque dipendenti dalle specifiche condizioni del sistema in esame.

Nella tabella T1 si propone una semplice scala da 0 a 3, indicando con 0 evento che non si verificherà mai e con 3 evento altamente probabile.

Se si vuole misurare il rischio occorre prendere in considerazione almeno un altro parametro: l'impatto che il danno avrà sul sistema.

Anche in questo caso viene proposta la stessa scala da 0 a 3.

La misura del rischio può essere calcolata moltiplicando i due valori identificati (il risultato sarà dato da una scala con sette distinti valori che vanno da 0 a 9).

Infine (ultima colonna), bisogna prendere delle decisioni e decidere se il rischio sarà tollerato, o se deve essere ridotto.

Tabella T1 - Classificazione rischi - azioni adottate o da adottare
Descrizione del Rischio (minacccia o vulnerabilità)		Probabilità dell'evento	Impatto del danno	Misura del rischio	Trattamento adottato
					T=Tollerato R=Ridotto E=Eliminato F=Trasferito
		P: da 0 a 3	D: da 0 a 3	M=PxD
Comportamento
R1	furto di Login	2	3	6	R
R2	Mancanza di consapevolezza, negligenza	3	2	6	R
R3	Comportamento disonesto o fraudolento	1	3	3	R
R4	Errore umano	2	1	2	R
Tecnologia
R5	Virus e programmi malware	1	3	3	R
R6	Spamming	1	1	1	R
R7	Danni dolosi	1	3	3	R
R8	Funzionamento improprio, non disponibilità o deterioramento dispositivi	2	2	4	T
R9	Accessi esterni remoti non autorizzati	2	3	3	R
R10	Intrusione nella rete	1	3	3	R
Ambiente
R11	Accesso non autorizzato in aree sensibili	1	3	3	R
R12	Furto di dispositivi	2	3	6	R
R13	Eventi catastrofici (terremoti, fulmini, incendi, allagamenti, ...): naturali o dolosi.	1	3	3	F
R14	Guasti ai sistemi di infrastruttura (impianto elettrico, condizionamento...)	1	2	2	R
R15	Errore tecnico umano	2	2	4	R
R16	Altri eventi	0	0	0	R

(segue)

Rischio e profitto nei sistemi informativi

L'impatto che l'Information Technology può produrre nell'organizzazione di una azienda, dipende dal tipo di approccio, che a sua volta porta con sè un livello di rischio e di "possibile" profitto che vanno a braccetto.
Più rischio, più "possibile profitto" (ma anche più dolori in caso di fallimento del progetto).

I quattro approcci che vengono individuati dagli analisti sono:

Automazione:
Svolgere un compito in maniera più efficace.
Sponsor tipico è l'utilizzatore finale.

Razionalizzazione delle procedure:
Svolgere una procedura con la massima efficienza operativa.
Coinvolge l'analisi delle risorse impiegate per ottenere il miglior risultato.
Sponsor tipico è il responsabile di Reparto/Divisione

Reingegnerizzazione dei processi:
Revisione di tutti o parte dei processi per identificare le attività, semplificarle, ridisegnarle nel flusso.
Sponsor tipico è la linea del Top Management.

Cambiamento dei paradigmi:
Implica un un ripensamento globale degli obiettivi aziendali fino a una riformulazione della natura stessa.
Sponsor tipico: gli azionisti.

E' chiaro da quanto detto perchè il rischio e il profitto che ne può derivare crescono in base all'approccio.

Naturalmente non esiste un approccio migliore degli altri e una stessa azienda può, nel tempo, sperimentare diversi progetti a livello differente, ma è altrettando inequivocabile che quanto più si sale, tanto più la complessità del progetto induce a sottovalutare l'importanza degli aspetti procedurali o funzionali.
Viceversa se non si è capaci di gettare uno sguardo oltre al problema quotidiano, si continua a migliorare aspetti secondari rispetto alle sorti dell'azienda.

Nella mia esperienza mi è capitato di condurre progetti fino alla "Reingegnerizzazione" (progetti ERP).

Non tutta la burocrazia viene per nuocere

Il D.Lgs.196/2003 sulla Gestione della privacy ha aggiunto uteriori impegni all'agenda del CIO, a causa della necessità di preparare un DPS, cioè un Documento Programmatico sulla Sicurezza, in altre parole un Piano annuale che fotografa la situazione delle basi-dati che contengono informazioni personali, sensibili e giuridiche, che identifica tutti i 'trattamenti' possibili e permette di elaborare una valutazione dei rischi.

Un lavoro che coinvolge anche i reparti amministrativi e di gestione del personale, ma che di fatto, in aziende medio-piccole, almeno nella fase di progettazione e sviluppo, cade spesso sulle spalle del CIO. Per me è stato così.
Quest'anno però la consueta revisione, che poi si trasforma sempre in un miglioramento continuo, mi ha lasciato qualche soddisfazione. Mi riferisco al fatto che la consuntivazione degli eventi significativi e delle misure adottate durante l'anno mi ha spinto verso una visuale diversa rispetto a quella periodica del 'budget' economico da rispettare.
Ho rilevato tre/quattro eventi sensibili alla protezione dei dati e ho potuto apprezzare i correttivi che avevo deciso in corso d'anno, che oggettivamente hanno diminuito il rischio di perdita accidentale dei dati.

- Il primo è un non-evento, nel senso che l'anno precedente erano stati raddoppiati i motori del climatizzatore dell'aria nel data center. Durante il Luglio scorso, un grave guasto (al sabato pomeriggio naturalmente) all'impianto non ha provocato alcun problema ai server e ai dispositivi. La temperatura si è innalzata di poco più di un grado. Evitati costi per l'emergenza, straodinari, fermi macchina per surriscaldamento.
- Un'altro evento, dovuto a un bug nella procedura di copia in un database di posta locale (stavolta con parziale perdita di dati) ha determinato invece una revisione della procedura che da allora è in grado di segnalare salvataggi andati a buon fine solo apparentemente. Inoltre l'evento ha determinato una nuova valutazione delle politiche adottate sui singoli utenti e un aggiornamento della capacità di back-up del sistema.
- Infine, un'allarmante realtà è stata la crescita vertiginosa degli spam. Il motore del programma che utilizzavo, non era più in grado di soddisfare le esigenze e provocava rallentamenti e perdita di messaggi nelle code in entrata. L'installazione di un 'appliance' dedicato e configurato secondo necessità, ha azzerato il problema e oggi leggo con relativa tranquillità gli articoli sull'incremento esponenziale di questi messaggi indesiderati.

make-or-buy (3)

Concludo, con gli ultimi fattori che ho considerato: personalizzazioni, rischi, esperienza, vantaggi strategici.

Parte 3

Fattore

TO BUY

TO MAKE

Personalizzazioni	E’ disponibile il codice sorgente? Che tipo di documentazione viene rilasciata?	Quanto è produttivo e vantaggioso in una visione globale, realizzare tutte le personalizzazioni richieste dai key-users?
Rischi	Storia e stabilità economica/finanziaria del fornitore? Disponibilità a condivisione del rischio di progetto?	Valutare rischi sulla data di consegna del prodotto, sulla reale aderenza alle specifiche, sui reali costi
Esperienza	Maturità del prodotto? Base installata?	Competenze
Vantaggi strategici	Il fornitore partner si configura come un partner in grado di aggiungere valore?	Quali specifiche flessibilità si ottengono rispetto all’acquisto?