Introduzione alla sicurezza informatica

Prima di passare a vedere quelle che sono le problematiche strettamente legate all'utilizzo di un particolare sistema operativo, è bene capire cosa stiamo proteggendo e quali siano in linea di massima i mezzi a nostra disposizione per raggiungere lo scopo prefissatoci.

Principali beni dei sistemi informatici

Parlando di sistemi informatici, a volte si è portati a limitare quello che è il reale campo d'applicazione della parola bene, associandola esclusivamente a tre categorie:

• Hardware: l'apparecchiatura;

• Software: i programmi necessari al funzionamento dell'apparecchiatura e utilizzati per l'elaborazione delle informazioni;

• Dati: le informazioni gestite dai programmi;

Oltre a questi, che rappresentano comunque i beni principali, non bisogna dimenticarsi di aggiungere:

• Supporti di memorizzazione: possono contenere il software ed i dati;

• Reti: permettono l'interconnessione dei vari sistemi consentendo quindi lo scambio di informazioni;

• Accessi: la possibilità che viene data ai soggetti di utilizzare il bene.

• Individui chiave: pensate, per esempio, a quanto tempo e quante risorse economiche occorrono per preparare adeguatamente un valido amministratore di sistema oppure un operatore specializzato nell'uso di un determinato programma.

Obiettivi della sicurezza informatica

La sicurezza informatica ha, come obiettivo principale, quello di: garantire, riducendo i rischi, un adeguato grado di protezione dei beni, mediante l’attuazione di un progetto di sicurezza globale che, partendo dalla definizione di una politica di sicurezza, tenga conto di tutti gli aspetti del problema e pervenga ad un livello di protezione, organizzativo ed informatico, che possa essere monitorato nel tempo.

Per raggiungere quello che è l'obiettivo principale, occorre garantire che il bene mantenga inalterate nel tempo queste proprietà:

• Sicurezza/riservatezza (Confidentiality);

• Integrità (Integrity);

• Disponibilità (Availability).

Clic per ingrandire

• Autenticazione;

• Non ripudio.

Rischio e sicurezza

Tutte quelle circostanze potenziali che possono causare un danno rappresentano un rischio. E' da notare che, come abbiamo visto prima, parlando della sicurezza informatica, un progetto o un programma di sicurezza non azzerano mai il relativo rischio.

La sicurezza totale infatti è un’astrazione e come tale non esiste nella realtà. Si deve allora seguire la logica secondo cui un progetto di sicurezza ha l'obiettivo di ridurre il rischio.

Rischi per un sistema informatico

Vediamo adesso quali sono i rischi relativi ad un sistema informatico:
 

Clic per ingrandire
 

Vulnerabilità

In pratica, per causare un danno basterà sfruttare una vulnerabilità. Ma che cosa si intende per vulnerabilità? Semplicemente una debolezza di cui servirsi per raggiungere gli scopi prefissati, presente nel sistema operativo, nelle procedure di sicurezza, nei controlli interni o nell'implementazione.

Quando si parla di vulnerabilità, la prima cosa che viene in mente è, chiaramente, il difetto del software. Non necessariamente una vulnerabilità è solo un difetto del software. Possiamo dire sicuramente che, anche con un software perfettamente realizzato, perfettamente progettato, implementato e configurato, un sistema informatico può comunque essere vulnerabile. Per esempio, potremmo avere un dipendente di un'azienda che ha accesso a sistemi critici che un bel giorno passa ad un concorrente ma allo stesso tempo le sue credenziali per l'accesso non vengono cancellate. Da qui la vulnerabilità.

La frase "può essere sfruttata", naturalmente presuppone l'esser pronti a violare qualche cosa, in senso generale a violare la politica di sicurezza, che ci dice che cosa si può e che cosa non si può fare. Una vulnerabilità è quindi tale se ci permette di fare qualche cosa che altrimenti non dovremmo poter fare.

Da questo deriva che il problema è quindi da inquadrare in senso generale piuttosto che limitatamente ai difetti nel software. Infatti, prendendo in esame i principali componenti di un sistema informatico, possiamo facilmente associarvi una serie di vulnerabilità:
 

Clic per ingrandire

Per quanto riguarda le vulnerabilità del software è stato definito da tempo uno standard di fatto denominato CVE (Common Vulnerabilities and Exporures) per:

• fornire un "linguaggio comune" per la definizione formale del problema;
• facilitare la condivisione dei dati tra:
  • Intrusion Detection Systems (sistemi per il rilevamento delle instrusioni);
  • Strumenti di verifica (Assessment);
  • Archivi di vulnerabilità;
  • Ricercatori;
  • Gruppi per la gestione degli incidenti.
• permettere lo sviluppo di strumenti di sicurezza migliorati ed interoperabili.

Le vulnerabilità universali definite nel CVE sono quelle vulnerabilità che sostanzialmente sarebbero tali in qualsiasi politica di sicurezza.

Viceversa, le exposures, sono delle violazioni solo in certe politiche di sicurezza. Per esempio il fatto che certe informazioni siano disponibili attraverso un servizio che fornisce più informazioni di quante dovrebbe, potrebbe essere o meno una violazione ad una politica di sicurezza.

Un altro concetto fondamentale parlando di vulnerabilità è rappresentato dal ciclo di vita. Cosa vuol dire ciclo di vita di una vulnerabilità? Prendiamo per esempio un sistema informativo con una sua vulnerabilità, non è nota, ma esiste perchè il sistema è stato progettato in modo imperfetto. I problemi cominciano a nascere quando la vulnerabilità viene scoperta ed inizia quella che viene chiamata, finestra di esposizione, cioè il periodo in cui la vulnerabilità in qualche modo può essere sfruttata per causare un danno.

I casi sono due:

• la vulnerabilità è stata scoperta da qualcuno interessato ad eliminarla e quindi ci si può aspettare che si vada su una strada che porterà alla fine a una correzione. In pratica, la vulnerabilità verrà comunicata a chi è in grado di correggerla, verranno realizzate le apposite correzioni e queste poi saranno apportate ai singoli sistemi.
  
  Cosa importante è che la vulnerabilità in un determinato software si potrà considerare corretta non quando sarà rilasciata la correzione (patch), ma quando quest'ultima sarà installata su un sistema. Questo è un problema che si è visto moltissimo soprattutto in questi ultimi anni, perchè molti degli attacchi diffusi in modo massiccio, spesso sfruttavano delle vulnerabilità note da tempo per le quali le correzioni erano già disponibili ma che semplicemente non erano state applicate.
   
• la vulnerabilità venga scoperta da qualcuno, non interessato a correggerla, ma interessato a sfruttarla. Questa è una situazione spiacevole perchè potenzialmente questa vulnerabilità potrebbe continuare ad essere utilizzata e sfruttata anche diffusamente senza che, chi deve correggerla, ne venga a conoscenza, fino a quando qualcuno vedendo come è stato attaccato il suo sistema, non si rende conto di quale è stata la strada utilizzata.

E' stata la diffusione indiscriminata di informazioni circa le vulnerabilità che ha permesso di definire un vero e proprio ciclo di vita delle stesse, comprendente una finestra di esposizione variabile in base alla logica perseguita. Mentre nel secondo caso la conoscenza della vulnerabilità rimane limitata allo scopritore e quindi la sua diffusione pubblica dipende da quest'ultimo, nel primo si può assistere ad un comportamento ciclico, come è stato messo in evidenza dal CERT/CC. In pratica:

• la vulnerabilità viene scoperta da un ricercatore o comunque qualcuno dotato di ottime conoscenze nella materia;
• viene reso pubblico il metodo per sfruttarla, di solito utilizzando un linguaggio di scripting;
• il codice di scripting viene portato in un linguaggio maggiormente diffuso ed inserito all'interno di applicazioni di facile utilizzo (input obbiettivo > esegui azione)
• si ha la distribuzione capillare dell'applicazione e quindi lo sfruttamento della vulnerabilità;
• la casa produttrice del software corregge il problema;
• viene applicata la correzione.

Nella realtà, si assiste di solito ad una serie di processi simili a quello evidenziato, che, a volte, interessano aspetti diversi dello stesso software. Da qui i ben noti problemi di aggiornamento, legati all'applicazione dell'ultima correzione disponibile, che assillano il responsabile alla sicurezza di un sistema.

Metodi di difesa

Per ridurre o prevenire lo sfruttamento di una vulnerabilità si rende necessaria un'opera di controllo mediante l'applicazione di particolari misure protettive rappresentate da azioni, dispositivi, procedure o tecniche.

Naturalmente bisogna fare particolare attenzione al fatto che "la sicurezza è un processo, non un prodotto, e come tale ha molti componenti, che devono essere affidabili e ben studiati e, soprattutto, collaborare fra loro. Infatti, l'efficacia del sistema di sicurezza dipende in modo essenziale da come i vari componenti collaborano fra di loro. A volte i punti deboli sono costituiti proprio dalle interfacce fra i componenti. Un sistema di sicurezza può essere paragonato a una catena, composta da vari anelli, ciascuno dei quali influisce in modo determinante sulla sua resistenza. Come in qualsiasi catena, la forza del sistema di sicurezza corrisponde a quella del suo componente più debole" (Schneier B., Sicurezza Digitale, Tecniche Nuove, Milano, 2001).

Principali controlli

I principali controlli a nostra disposizione sono:
 

Clic per ingrandire
 

Efficacia dei controlli

Affinche i controlli siano efficaci bisogna considerare:
 

Riferimenti

• AA. VV., Osservatorio sulla criminalità informatica. Rapporto 1997, FrancoAngeli, Milano, 1997;
• Rosario Marasco, La sicurezza informatica, Jackson Libri, Milano, 1998;
• Charles P. Pfleeger, Security in Computing, Prentice-Hall, Upper Saddle River, 1997;
• Statistiche delle vulnerabilità del software su SecurityFocus.com - http://www.securityfocus.com/vulns/stats.shtml
• Common Vulnerabilities and Exposures - http://cve.mitre.org
• ICAT Metabase (CVE Vulnerability Search Engine)
• CERT/CC (originariamente Computer Emergency Response Team) - http://www.cert.org