1

LA SICUREZZA NEI SISTEMI INFORMATIVI

Antonio Leonforte

Rendere un sistema informativo sicuro non significa solo attuare un insieme di contromisure specifiche (di carattere tecnologico ed organizzativo) che neutralizzi tutti gli attacchi ipotizzabili per quel sistema; significa anche collocare ciascuna contromisura in una politica organica di sicurezza che tenga conto dei vincoli (tecnici, logistici, amministrativi, politici) imposti dalla struttura in cui il sistema informativo opera, e che giustifichi ciascuna contromisura in un quadro complessivo.

1. Definizione e concetti di base

1.1. Definizione Con il termine “sicurezza”, nell’ambito dei sistemi informativi, si intende l’insieme delle misure (di carattere organizzativo e tecnologico) tese ad assicurare a ciascun utente autorizzato (e a nessun altro) tutti e soli i servizi previsti per quell’utente, nei tempi e nelle modalità previste. Più formalmente, secondo la definizione ISO, la sicurezza è l’insieme delle misure atte a garantire la disponibilità, la integrità e la riservatezza delle informazioni gestite.

1.2. Disponibilità controllata delle informazioni Il sistema deve rendere disponibili a ciascun utente abilitato le informazioni alle quali ha diritto di accedere, nei tempi e nei modi previsti. Nei sistemi informatici, i requisiti di disponibilità sono legati anche a quelli di prestazione e di robustezza. La disponibilità di una informazione ad un utente, infatti, deve essere assicurata in modo ininterrotto durante tutto il periodo di tempo previsto (continuità del servizio). Il raggiungimento dell’obiettivo disponibilità dipende quindi da fattori critici come la robustezza del software di base e di quello applicativo, l’affidabilità delle apparecchiature e degli ambienti in cui sono collocati, l’esperienza e l’affidabilità degli amministratori del sistema. Non è in generale buona norma assumere che le contromisure adottate in un sistema informatico siano sufficienti a scongiurare qualsiasi attacco. Rientra quindi fra gli obiettivi di una politica di sicurezza quello di garantire il rientro in funzione in tempo utile del sistema informatico, a seguito di eventi negativi anche gravi (disaster recovery).

2

1.3. Integrità delle informazioni Il sistema deve impedire la alterazione diretta o indiretta delle informazioni, sia da parte di utenti e processi non autorizzati, che a seguito di eventi accidentali. Anche la perdita di dati (per esempio a seguito di cancellazione o danneggiamento), viene considerata come alterazione.

1.4. Riservatezza delle informazioni

Il sistema deve impedire a chiunque di ottenere o dedurre, direttamente o indirettamente, informazioni che non è autorizzato a conoscere. Vale la pena di osservare che, in determinati contesti, il fatto stesso che una informazione sia protetta, o che esista una comunicazione in atto fra due utenti o processi, può essere sufficiente per dedurre informazioni riservate.

2. Considerazioni preliminari

2.1. Esigenza della sicurezza L’interesse per la sicurezza nei sistemi informatici è cresciuto negli ultimi anni in funzione della loro diffusione, del ruolo sempre più importante che essi hanno nei contesti in cui operano, e della loro crescente complessità ed esposizione a possibili attacchi. Sul piano della strategicità, occorre sottolineare come accanto alla disponibilità ed alla integrità delle informazioni, spesso fondamentali per assicurare continuità alla produzione, anche la riservatezza è divenuta critica con la progressiva adozione di strumenti informatici nella pianificazione e nel supporto alle decisioni (cioè nella gestione di informazioni di interesse strategico). Quanto alla maggiore esposizione dei moderni sistemi, basti considerare la maggiore interconnessione, dalle reti locali ad Internet, e la maggiore complessità, dalle architetture client-server a quelle fortemente distribuite.

2.2. Approccio al problema

Occorre partire dal presupposto che, a dispetto delle misure attuate, un evento indesiderato possa comunque violare i requisiti di disponibilità, integrità e riservatezza, attraverso meccanismi non previsti. Proteggere i requisiti di sicurezza di un sistema significa quindi, in termini realistici: • ridurre ad un valore accettabile la probabilità che vengano violati; • individuare tempestivamente quando ed in quale parte del sistema questo accade; • limitare i danni e ripristinare i requisiti violati nel minor tempo possibile. Si deve, in definitiva, mettere in atto contemporaneamente misure di tipo complementare. E’ molto importante che queste misure siano adottate in modo organico e sistematico, cioè nell’ambito più generale di una politica di sicurezza, e nel rispetto dei

3

vincoli tecnici, logistici, amministrativi, politici ed economici imposti dalla struttura in cui il sistema opera.

3. Risorse di un sistema

Le risorse di un sistema informativo sono l'insieme delle entità (dagli operatori alle componenti hardware, dal software di base a quello applicativo) necessarie al suo funzionamento. Dal punto di vista della sicurezza, non è importante distinguere fra le risorse che costituiscono il sistema (i.e. le sue componenti) e le risorse delle quali ha bisogno per funzionare: si tratta in ogni caso di risorse "critiche" e quindi da proteggere. Anticipando alcuni concetti meglio esposti nella sezione sugli aspetti metodologici, per proteggere un sistema occorre innanzitutto identificarne le risorse e valutare il rischio legato agli eventi (indesiderati) che possano minacciarne la integrità. Una classificazione delle tipologie di risorsa comunemente presenti in un sistema informativo è utile per procedere in modo sistematico ed esaustivo nella identificazione delle risorse stesse. Possiamo in particolare distinguere fra risorse fisiche e logiche. Le principali risorse fisiche solitamente presenti in un sistema informativo moderno sono calcolatori (server e postazioni di lavoro), periferiche (scanner, stampanti, modem), apparecchiature di rete, i locali che ospitano le apparecchiature e gli impianti di alimentazione e condizionamento di tali locali. Vale la pena osservare che anche gli operatori umani possono essere considerati per certi aspetti come risorse fisiche. Le risorse logiche presenti in un sistema informativo moderno sono tipicamente i moduli del software applicativo e del software di base (DBMS, Sistema Operativo, Software di Rete), le basi di dati, i registri di configurazione dei dispositivi (per esempio router). Anche in questo caso, possono essere considerate come risorse logiche anche l'insieme delle regole organizzative e comportamentali degli operatori umani. E’ importante osservare infine come il corretto funzionamento di una risorsa possa dipendere da quello di altre. Questo aspetto, che nella sezione metodologica viene definito come "dipendenza funzionale fra risorse" è alla base dei fenomeni di propagazione dei guasti, e va tenuto in conto nel valutare i danni che un determinato attacco è in grado di apportare.

4. Eventi indesiderati

Una volta individuate le risorse critiche, si deve stabilire quali eventi indesiderati possano determinarne un degrado nelle caratteristiche di integrità, disponibilità e riservatezza. Una definizione precisa di “evento indesiderato” permette di verificare, a fronte di una analisi sistematica di tutti gli eventi che potrebbero accadere intorno al sistema, se e

4

quanto ciascun evento sia indesiderato rispetto alla definizione data. Un buon punto di partenza è costituito dal considerare come evento indesiderato qualsiasi accesso (a servizio o informazione) che non sia esplicitamente permesso dalla politica di sicurezza del sistema. L’insieme degli eventi indesiderati, tuttavia, è ben più esteso, in quanto comprende eventi che non sono affatto degli attacchi deliberati, bensì dei semplici eventi accidentali. Stando alle statistiche, anzi, gli eventi accidentali quali il guasto di un dispositivo o l'errore umano (per esempio cancellazione accidentale di file, installazione di componenti incompatibili o infettate che corrompono il software di base) restano la principale causa di perdita accidentale di dati. Per questo motivo il titolo di questa sezione fa riferimento al concetto più generale di "evento indesiderato". Allo scopo di affrontare il problema in modo sistematico, classifichiamo quindi gli eventi indesiderati a seconda che siano accidentali o piuttosto conseguenza di un attacco deliberato. Analogamente a quanto visto per le risorse, una classificazione degli eventi indesiderati risulta utile per affrontare la loro identificazione con sistematicità.

4.1. Attacchi deliberati

Nel classificare l’insieme dei possibili attacchi al sistema, è importante partire dal presupposto che chiunque tenti di penetrarvi o danneggiarlo applicherà, in sequenza o in parallelo (sfruttando eventuali effetti combinati), tutte le tecniche di cui dispone su tutte componenti attaccabili. Appare naturale caratterizzare un attacco in funzione della componente attaccata e della tecnica utilizzata dall’intrusore. Un approccio sistematico individua tutte le componenti del sistema, sia fisiche (calcolatori, router, cavi) che logiche (file, processi, etc..) e, per ciascuna di esse, individua tutte le tecniche di attacco ad essa applicabili. Il risultato di questo approccio può essere convenientemente riassunto in una matrice avente le componenti su un asse e le tecniche di attacco sull’altro. Una cella di tale matrice permette infatti di descrivere se e come una certa tecnica può essere utilizzata per attaccare una certa componente.

4.1.1. Attacchi a livello fisico Gli attacchi a livello fisico sono principalmente tesi a sottrarre o danneggiare risorse critiche. I principali tipi di attacco a livello fisico sono: • furto: prevedibile per nastri di backup, dischi o interi server; è un attacco alla

disponibilità ed alla riservatezza; • danneggiamento: attacco tipicamente condotto contro apparecchiature e cavi di

rete, più raramente contro calcolatori server in quanto questi sono generalmente confinati in locali sicuri; è un attacco alla disponibilità ed alla integrità.

5

4.1.2. Attacchi a livello logico Gli attacchi a livello logico sono principalmente tesi a sottrarre informazione o degradare la operatività del sistema. Un attacco può essere caratterizzato in funzione del livello architetturale sul quale agisce e dei risultati che è indirizzato a conseguire. I livelli architetturali sui quali può agire un attacco a livello logico dipendono evidentemente dalla architettura del sistema. I livelli comunemente presenti nei sistemi informativi moderni (client/server o multi-livello) sono: • il livello interfaccia (client), che implementa la interfaccia utente; • il livello applicazione (application-server), che implementa i servizi applicativi; • il livello dati (data-server, spesso realizzato con un DBMS commerciale),

responsabile della memorizzazione dei dati sulla memoria di massa e della loro estrazione;

• il livello main-frame, che, quando necessario, interfaccia il sistema informativo moderno con servizi offerti da uno o più sistemi "legacy", cioè sistemi importanti che non è conveniente sostituire o modificare.

Dal punto di vista dei risultati che è indirizzato a conseguire, un attacco a livello logico può essere classificato come di: • intercettazione e deduzione (attacco alla riservatezza); • intrusione (attacco alla integrità ed alla riservatezza); • disturbo (attacco alla disponibilità).

4.1.2.1. Attacchi di intercettazione Gli attacchi di intercettazione possono richiedere un attacco preventivo a livello fisico per installare dispositivi pirata o per agganciarsi alla rete, e di intrusione (livello logico), per installare software di supporto alla intercettazione. Le tecniche comunemente utilizzate sono basate su: • analizzatori di traffico su rete (locale o geografica); • applicazioni di analisi del traffico su rete (sniffing); • server pirata che si spacciano come router (spoofing); • programmi che emulano servizi del sistema (tipicamente il login, durante il quale

l’utente digita username e password) registrando al contempo le informazioni riservate digitate dall'utente.

Gli attacchi di intercettazione possono sfruttare debolezze intrinseche di protocolli e software di rete, o poco accorte configurazioni del sistema operativo. In alcune versioni del sistema grafico X-Window, ad esempio, è possibile spiare tutto quello che fa un utente. I meccanismi di controllo degli accessi, in tali versioni del sistema, sono infatti aggirabili tramite spoofing o semplicemente intercettando informazioni di sessione, dette COOKIE, che transitano in chiaro). Sulle certe reti TCP-IP, ad esempio, è possibile inviare falsi messaggi di controllo al calcolatore che svolge le funzioni di DNS (Database Network System) per ottenere

6

informazioni su tutti i calcolatori in rete e talvolta anche sui loro sistemi operativi. Questo permette in seguito di condurre attacchi mirati. Telnetd è il demone che permette di aprire un terminale virtuale su una macchina UNIX attraverso una connessione TCP/IP: un terminale è associato ad un file i cui permessi in lettura vengono revocati una volta che la connessione è stabilita; con una tecnica particolare, è comunque possibile leggere tale file nel momento in cui l’utente digita username e password. Gli attacchi di intercettazione possono infine sfruttare il fatto che un utente abbia disatteso qualche norma comportamentale imposta dalla politica di sicurezza (ad esempio scrivendo la password sotto la tastiera, oppure utilizzando come password il proprio nome di battesimo o quello della moglie).

4.1.2.2. Attacchi di deduzione Gli attacchi basati sulla deduzione sono condotti incrociando informazioni tratte dall’osservazione del sistema con informazioni ottenute per altre vie. Alcuni esempi sono gli attacchi condotti: • a partire dal fatto stesso che un certo servizio o una certa informazione sia negata

dal sistema. • a partire dal monitoraggio dei volumi di traffico nella comunicazione fra

componenti del sistema; • confrontando informazioni presenti nel sistema, individualmente configurate come

poco riservate.

4.1.2.3. Attacchi di intrusione Quando il sistema non prevede strumenti evoluti per il riconoscimento dell’utente (chiave hardware, lettore di impronte digitali, etc.), l’accesso al sistema tramite password illegale è uno degli attacchi di intrusione più frequenti. Tralasciando il caso in cui la password sia stata rubata al legittimo proprietario tramite intercettazione o deduzione (casi già trattati nelle sezioni precedenti), è possibile che essa venga individuata utilizzando programmi (ad esempio "ypx" per UNIX) appositamente progettati per generare sistematicamente combinazioni di caratteri semi-casuali e verificarle come password tentando l’accesso al sistema in modo automatico. Attacchi di questo tipo devono il loro successo al fatto che gli utenti scelgono come password parole di uso comune, e quindi, in definitiva, ad una debolezza nella politica di sicurezza o nella sua attuazione da parte del personale. Altri tipi di intrusione possono essere basati su tecniche più sofisticate, generalmente tese a sfruttare debolezze nei protocolli di rete e nel software di rete. Su certe reti TCP/IP si possono generare con programmi appositi pacchetti IP falsificati, nei quali l’indirizzo del mittente è alterato per far credere al destinatario che i pacchetti provengano da un altro calcolatore (IP-spoofing) e/o il routing da seguire è prefissato in modo conveniente (source-routing). Sempre su certe reti TCP/IP, è inoltre possibile

7

indovinare il sequence-number di una connessione, e quindi far credere al calcolatore sotto attacco, che i pacchetti inviati siano relativi ad una connessione già esistente e regolarmente autenticata. Su reti TCP/IP con certe versioni di NFS (Network File System) è possibile, laddove il sistema sia configurato in modo poco accorto, accedere ad un disco remoto scavalcando i controlli sui diritti di accesso. Una volta ottenuti in qualche modo (anche temporaneamente) i diritti di amministratore, è possibile installare nel sistema un meccanismo, detto backdoor, che permetta anche in seguito di mantenere un accesso privilegiato. Si tratta in questo caso di un attacco particolarmente insidioso in quanto la backdoor, finché non viene individuata e rimossa, continua a garantire l’accesso all’intrusore anche se il primo accesso illegale viene scoperto e la password di amministratore viene cambiata. Nei sistemi UNIX, ad esempio, si può installare un demone pirata con privilegi di amministratore (root) che, in condizioni legittimamente scatenabili dall’intrusore, provveda ad aprire una finestra (shell) di comando attraverso la quale accedere al sistema con diritti di amministratore. Questa tecnica rientra fra quelle indicate come “cavallo di Troia”.

4.1.2.4. Attacchi di disturbo

Gli attacchi che fanno uso di queste tecniche non sono tesi ad accedere a servizi ed informazioni, ma semplicemente a degradare la operatività del sistema. Sono considerabili come atti di sabotaggio, e minacciano tipicamente la integrità e la disponibilità dei dati, più raramente (e indirettamente) la riservatezza. Esistono diverse tecniche di disturbo.

4.1.2.5. Attacchi di disturbo tramite virus

I virus sono programmi auto-replicanti, spesso inseriti nel sistema come cavalli di Troia, generalmente pericolosi per la integrità del file-system e per la disponibilità dei servizi. Sono molto diffusi sui Sistemi Operativi mono-utente, decisamente meno frequenti su quelli multi-utente. In molti contesti, comunque, il sistema informatico presenta postazioni di lavoro client basate su Personal Computer con Sistema Operativo mono-utente, ed in tal caso gli attacchi tramite virus vanno presi in grande considerazione. I virus sono principalmente caratterizzati da: • logica del payload, cioè dal modo in cui arrecano danno al sistema; il payload è la

parte del codice virale che arreca direttamente il danno; la logica del payload può essere piuttosto complessa, e variare il comportamento del virus in funzione di variabili come data ed ora, presenza di determinati file nel file-system infettato, nome, tipo o dimensione dei file da alterare; gli effetti del payload sono spesso resi volutamente pseudo-casuali al fine di camuffare i danni causati come problemi nell’hardware o nel software di base del calcolatore colpito;

• modalità di infezione, cioè dal modo in cui si inseriscono e si duplicano nel sistema; rispetto alla modalità di infezione, abbiamo ad esempio virus parassiti, di Boot-Sector, gemelli, multi-partiti, etc.; una casistica estesa e ragionata dei meccanismi di

8

infezione esula dagli scopi di questa sezione, e rimandiamo per essa a testi specializzati;

• modalità di mimetizzazione, cioè dal modo in cui si sottraggono alla identificazione da parte dei programmi anti-virus; rispetto alla modalità di mimetizzazione, abbiamo ad esempio virus stealth, polimorfici, armoured, tunneling, etc.

4.1.2.6. Attacchi di disturbo tramite worm I worm sono virus particolari che si limitano a degradare le prestazioni del sistema, ad esempio lanciando molte immagini di uno stesso processo. Quando il rallentamento del sistema supera una certa soglia, alcuni servizi possono risultare di fatto inutilizzabili, ed in questo caso si ha una violazione dei requisiti di disponibilità. L’attacco con worm è particolarmente subdolo su sistemi batch, nei quali è più probabile che il degrado delle prestazioni sia rilevato con un ritardo inaccettabile.

4.1.2.7. Attacchi di disturbo “denial of service”

Si tratta di una famiglia di tecniche tese a fare in modo che il sistema neghi l’accesso a servizi ed informazioni anche ad utenti regolarmente autorizzati. Gli attacchi che usano queste tecniche minacciano quindi i requisiti di disponibilità del sistema. Due tipiche tecniche “denial of service” consistono ad esempio nel paralizzare il traffico sulla rete generando falsi messaggi di errore o intasandola con traffico di disturbo generato appositamente. ICMP (Internet Control Message Protocol) è un protocollo utilizzato fra calcolatori di reti TCP/IP per scambiarsi messaggi di errore. È possibile comporre pacchetti IP contenenti falsi messaggi ICMP ed inviarli ad un calcolatore, al fine di indurre questo a credere che un altro calcolatore o una intera sottorete sia fuori servizio. Le nuove versioni di UNIX, comunque, non permettono più l’utilizzo di questa tecnica, in quanto dispongono di meccanismi più potenti per verificare la provenienza dei messaggi. La tecnica detta “network flooding” consiste nel saturare una sottorete immettendovi pacchetti pirata generati automaticamente. Sfruttando la tecnica di IP-spoofing, è possibile fare il modo che il traffico pirata sia considerato dal gateway di accesso alla sottorete come traffico interno al sistema, e quindi immesso nella sottorete senza restrizioni. Quando la sottorete si congestiona, tutti i servizi che ne fanno uso risultano evidentemente non più disponibili.

4.2. Eventi accidentali Parallelamente a quanto fatto per gli attacchi deliberati, caratterizziamo un evento accidentale in funzione della componente che lo subisce e del fattore ambientale che lo scatena. Un approccio sistematico individua, per ciascuna componente fisica o logica del sistema, tutti i fattori potenzialmente pericolosi per quella componente. Il risultato di questo approccio può essere convenientemente riassunto in una matrice avente le componenti su un asse ed i fattori ambientali sull’altro. Una cella di tale

9

matrice permette infatti di descrivere se e come un certo fattore può accidentalmente provocare danno ad una certa componente. Stando alle statistiche, il fattore umano (per esempio cancellazione accidentale di file, installazione di componenti incompatibili o infettate che corrompono il software di base) resta la principale causa di perdita accidentale di dati. Per quanto riguarda gli eventi accidentali di altra origine, accanto ai guasti più frequenti (dischi, alimentatori, memoria, etc.) occorre valutare anche i guasti a dispositivi di supporto come condizionatori d’aria o trasformatori di potenza, ed eventi disastrosi come l’incendio o l’allagamento della sala CED.

5. Contromisure Per contromisure intendiamo tutto ciò che concorre, attivamente o passivamente, a minimizzare la probabilità che gli eventi indesiderati accadano, rilevare il fatto che sono accaduti, individuarne e minimizzarne le conseguenze, ripristinare il corretto funzionamento del sistema. L’evoluzione storica delle contromisure è legata a quella delle tecnologie, alla crescente interconnessione fra i sistemi e, soprattutto, al crescente grado di sofisticazione degli attacchi deliberati. Un’elencazione estesa delle contromisure adottate nei sistemi informativi moderni va oltre gli scopi di questa trattazione, ma una classificazione delle principali tipologie di contromisura, è comu nque utile per affrontare la tematica in modo organico. Una prima possibilità è quella di classificare le contromisure in funzione degli eventi indesiderati che vanno a contrastare. Affiancare a ciascun evento indesiderato le contromisure applicabili è in effetti lo schema adottato da molti testi destinati agli amministratori di sistema. Accanto a questo criterio di classificazione molto diffuso, è possibile adottarne altri basati su caratteristiche generali proprie delle contromisure, piuttosto che sulla loro specifica applicabilità. Possiamo in particolare distinguere fra contromisure: • preventive o correttive : per contromisure preventive intendiamo quelle finalizzate

a minimizzare la probabilità che un evento indesiderato accada, mentre per contromisure correttive indichiamo quelle le tese a riparare i danni causati dagli eventi indesiderati che, a dispetto delle contromisure preventive, sono ugualmente accaduti;

• informatiche o organizzative : le prime sono basate sulla tecnologia informatica e le seconde riconducibili alla organizzazione che utilizza il sistema informatico ed alle norme e regole di comportamento stabilite per il personale;

• a livello fisico o logico: le contromisure operanti a livello fisico proteggono dispositivi (calcolatori, cavi ed apparecchiature di rete, locali, impianti di alimentazione e condizionamento, etc.) da attacchi di tipo fisico quali furto o danneggiamento; quelle operanti a livello logico, come ad esempio i software anti-

10

virus, proteggono risorse logiche (basi di dati, registri di configurazione, moduli software, etc.) da attacchi di tipo logico.

In questa sede, dopo alcuni cenni agli standard esistenti, presentiamo un insieme esemplificativo di contromisure distinguendo in prima analisi quelle a carattere organizzativo da quelle propriamente informatiche.

5.1.1. Standard e modelli di riferimento Una ricognizione sugli standard internazionali, in tema di sicurezza, permette di allineare il più possibile il seguito del lavoro a quanto previsto da tali standard, anche ai fini di una eventuale certificazione del sistema. Fra gli standard esistenti, possiamo citare quelli definiti nel cosiddetto “Orange Book”, le norme ITSEC, lo standard ISO 7498-2 per i servizi di sicurezza, il modello “Trusted Network Computing Environment Model”.

5.1.2. Contromisure di carattere organizzativo Una condizione essenziale affinché la tecnologia a protezione di un sistema informatico risulti realmente efficace, è che venga utilizzata nel modo corretto da personale pienamente consapevole della sua importanza. Occorre innanzitutto una forte dichiarazione di intenti da parte dei vertici della organizzazione che gestisce il sistema. Devono quindi essere definiti con precisione ruoli e responsabilità nella gestione sicura del sistema, e per ciascun ruolo, dall’amministratore al semplice utente, devono essere definite norme comportamentali e procedure precise da rispettare. Affinché tutti gli aspetti procedurali vengano compresi e attuati correttamente, è fondamentale istruire il personale, a tutti i livelli, con opportuni corsi di addestramento. L’introduzione delle procedure di sicurezza dovrebbe inoltre essere giustificata e resa accettabile con una vasta opera di sensibilizzazione, da condursi ad esempio con dimostrazioni che ne evidenzino il significato e la necessità. I ruoli operativi che vengono generalmente definiti, nell’ambito della gestione sicura di un sistema informatico, appartengono a due tipologie, a seconda che controllino gli aspetti fisici o logici del sistema. Per quanto riguarda il controllo degli aspetti fisici, vanno definiti ruoli (a vari livelli di responsabilità) di garante della integrità fisica delle componenti del sistema (o parti di esso). A fronte di questa responsabilità, devono essere stabilite, ad esempio, procedure per il controllo e la registrazione dell’accesso di chiunque debba entrare nei locali che ospitano il sistema informatico (dagli stessi utenti, al personale della pulizia, a quello della manutenzione hardware); altre procedure devono essere definite, ad esempio, per la custodia e la assegnazione delle chiavi. Per quanto riguarda il controllo degli aspetti logici, vanno innanzitutto definiti i ruoli di amministratore e di auditor del sistema informatico. I compiti di un amministratore sono

11

in generale quelli di creazione e cancellazione degli utenti, corretta configurazione del sistema operativo ai fini della sicurezza, installazione e configurazione delle applicazioni di rete, controllo delle attività periodiche di backup. A fronte di queste responsabilità, l’amministratore può utilizzare servizi speciali del sistema operativo e dello stesso sistema informatico. I compiti dell’auditor sono quelli di verificare che il sistema informatico sia realmente sicuro. Gli strumenti a disposizione dell’auditor comprendono l’analisi delle registrazioni (log) delle attività svolte degli utenti (incluso lo stesso amministratore), interviste ai responsabili e tentativi reali di intrusione. I ruoli di più elevata responsabilità sul fronte della sicurezza, in generale non omologabili in nessuna delle suddette tipologie, sono tipicamente contigui, e spesso coincidono, con i più alti vertici della organizzazione nel suo complesso.

5.1.3. Contromisure di carattere informatico Relativamente alle contromisure basate sulla tecnologia informatica, un interessante criterio di classificazione è quello basato sul livello architetturale al quale la contromisura agisce. Conviene in tal senso distinguere in prima battuta fra contromisure a livello di applicazione, quindi specifiche del particolare sistema informatico considerato, e contromisure di base a carattere più generale.

5.1.3.1. Contromisure informatiche a livello di applicazione Le contromisure operanti a livello di applicazione sono particolari funzioni inserite nelle applicazioni ai fini della sicurezza, e possono essere utilizzate da esse solo quando effettivamente necessario. Le contromisure a livello di applicazione sono spesso caratterizzate da una efficacia elevata ma relativa ad un insieme tipicamente ristretto di eventi indesiderati che è quello specificamente previsto per l’applicazione che vanno a proteggere.

5.1.3.2. Contromisure informatiche di base (DBMS, sistema operativo, rete) Le contromisure che operano a livello di DBMS, sistema operativo o rete hanno carattere più generale, rispetto a quelle di livello applicativo, e indipendente dalla particolare applicazione eseguita. Di conseguenza, sono spesso meno sofisticate di quelle a livello applicazione, ma dotate in compenso di un più ampio grado di copertura rispetto alla gamma degli eventi indesiderati che vanno a contrastare. I produttori di Sistemi Operativi rilasciano spesso delle guide alla configurazione “sicura” del loro prodotto. Questi documenti sono spesso un buon punto di partenza per la definizione di una politica di sicurezza. Con il “Trusted Network Computing Environment Model”, ad esempio, Novell definisce un insieme decisamente ampio ed organico di misure adottabili su reti Netware. Nella tabella seguente presentiamo, a titolo esemplificativo, alcune esempi di contromisure di base. È interessante notare come alcune delle contromisure abbiano anche un carattere organizzativo ed operino talvolta anche a livello fisico.

12

Protezione dalle false autenticazioni Imporre che a ciascun login name sia associato una persona fisica. Disabilitare o eliminare i login name non più utilizzati per qualunque motivo. Mantenere una lista degli utenti cancellati. Imporre che a ciascun login name sia associata una password. Imporre agli utenti di cambiare periodicamente (eventualmente ad ogni sessione) la password, impedendo il riuso di password utilizzate in precedenza. Utilizzare tecniche avanzate di autenticazione (smart-card, riconoscimento della retina, etc.). Verificare che tutti i serventi della rete siano fra loro reciprocamente autenticati. Protezione dagli accessi illegali Limitare il numero delle connessioni simultanee di ciascun utente Rilevare i login falliti e disabilitare i login name al terzo tentativo. Limitare gli intervalli temporali in cui è possibile utilizzare la rete. Limitare gli indirizzi MAC di rete delle stazioni di lavoro da cui consentire l’accesso agli utenti. Disabilitare e rimuovere fisicamente lettori di dischetto e di CD-ROM dalle stazioni di lavoro e dai server. Educare gli utenti a chiudere la sessione ogni volta che abbandonano la propria stazione di lavoro. Verificare periodicamente i diritti di accesso di ogni utente. Limitare l’accesso fisico alle postazioni di lavoro ai soli utenti autorizzati. Utilizzare esclusivamente prodotti certificati. Installare le applicazioni di rete in modo conforme alle specifiche della casa produttrice. Protezione degli attacchi via rete ed alla rete stessa Configurare il sistema in modo che tutti i nodi firmino ogni pacchetto trasmesso (8% di sovraccarico). Definire esplicitamente un utente cui assegnare i diritti di amministratore di rete (eliminando un eventuale utente di default). Utilizzare Hub dotati di meccanismi anti-intercettazione. Installare Hub e router in locali protetti, e far passare i cavi della rete in canaline murate. Bloccare il traffico non autorizzato su una rete locale (firewall, packet-inspecting routers, etc.); Cifrare il traffico riservato a livello applicativo oppure a livello di router; Protezione dagli attacchi ai server Isolare i server in un locale sicuro e proteggerne l'eventuale impianto di condizionamento. Definire una politica precisa per la gestione e la distribuzione delle chiavi di accesso ai locali protetti. Registrare gli accessi ai locali dove si trovano server e dispositivi di rete. Bloccare la console dei server con una password diversa da quella dell’amministratore di rete.

13

Imporre una password per ciascun server di stampa. Limitare il caricamento dei serventi applicativi in directory predefinite. Disabilitare tutti i servizi di console remota. Duplicare le unita di alimentazione e di raffreddamento Rendere a sola lettura tutte le directory in cui sono installate applicazioni. Protezione dai virus Verificare periodicamente le dimensioni di tutti i file eseguibili. Installare solo software originale prelevato da confezioni sigillate. Acquisire, installare ed aggiornare periodicamente un sistema anti-virus per le stazioni di lavoro in rete. Protezione dalle perdite di dati Definire una politica di backup periodico. Abilitare la funzione di controllo automatico del backup. Effettuare prove a campione di lettura dei dati su backup. Isolare nastri e dischi di backup in un luogo sicuro, separato da quello che ospita i server. Utilizzare array ridondanti di dischi (per esempio in configurazione RAID)

5.1.3.3. Sovrapposizione fra contromisure informatiche È interessante notare come certi meccanismi di sicurezza già presenti a livello di Sistema Operativo (autenticazione degli utenti, diritti su file) siano talvolta replicati e migliorati (specie dal punto di vista della flessibilità) a livello applicativo (ad esempio con funzioni per la verifica di chiavi hardware). D’altra parte, è anche possibile che alcune funzionalità di sicurezza offerte dai DBMS, ad esempio (crittografia, controllo degli accessi) siano invece disabilitate in quanto coperte più efficacemente a livello applicativo.

Meccanismi di sicurezza tipicamente offerti dal Sistema Operativo

Meccanismi di sicurezza tipicamente offerti dal DBMS

Meccanismi di sicurezza implementati a livello applicativo

In contesti particolarmente

critici ed articolati

14

6. Tecnologie di crittografia e di hashing La tecnologia alla base dei meccanismi di sicurezza è quella degli algoritmi di crittografia e di hashing sicuro (anche detti di “message digest”). Combinando opportunamente questi algoritmi è possibile realizzare servizi di più alto livello, come quelli di autenticazione e di riservatezza.

6.1. Algoritmi di crittografia

Sono algoritmi matematici in grado di trasformare (cifrare) reversibilmente un insieme di dati, ad esempio un documento, in modo da renderlo non intelligibile. Affinché algoritmi siano di qualche utilità pratica occorre che soddisfino le seguenti condizioni fondamentali: • la cifratura e la decifratura deve avvenire in funzione di una variabile detta chiave e

costituita da una sequenza di bit di lunghezza variabile in funzione dell'algoritmo e del livello di sicurezza che si desidera ottenere;

• le operazioni di cifratura e decifratura sono relativamente semplici nel caso in cui si conosca la chiave; in caso contrario risultano laboriose al punto da risultare praticamente inattuabili;

• risulta egualmente laborioso dedurre la chiave con cui è stato cifrato un documento confrontandolo con la sua versione in chiaro (cioè non cifrata).

La lunghezza delle chiavi, quando non fissata dal particolare algoritmo di crittografia, può tipicamente assumere un insieme di valori che varia in funzione dell'algoritmo stesso e degli standard applicabili. La lunghezza effettivamente scelta per le chiavi da utilizzare nell'ambito di una specifica applicazione è sempre il risultato di un compromesso fra esigenze di sicurezza e potenza dei calcolatori a disposizione. Al crescere della dimensione della chiave, infatti, aumenta infatti la sicurezza (intesa come difficoltà di decifrare le informazioni crittografate) ma anche la potenza di elaborazione (numero di istruzioni al secondo) necessaria per contenere i tempi delle operazioni di cifratura entro limiti accettabili. Gli algoritmi di crittografia possono essere classificati come simmetrici, anche detti “a chiave privata”, ed asimmetrici, anche detti “a doppia chiave” o “a chiave pubblica”.

6.1.1. Algoritmi simmetrici Gli algoritmi simmetrici utilizzano la stessa (ed unica) chiave privata, per cifrare e decifrare. Conviene evidenziare da subito che gli algoritmi simmetrici non si prestano bene a garantire la riservatezza nella comunicazione continuativa fra N soggetti indipendenti, in quanto: • occorre una chiave privata per ogni coppia di soggetti; • ogni soggetto è costretto a possedere N-1 chiavi, a mantenerle segrete ed a ricordare

la chiave da utilizzare per comunicare con ciascuno degli altri soggetti; • nel caso in cui la chiave sia generata autonomamente dal soggetto che avvia la

comunicazione, è necessario che venga trasmessa al destinatario affinché questo

15

possa decifrare i messaggi che riceve, e durante il trasferimento la chiave potrebbe essere intercettata.

D’altra parte, gli algoritmi simmetrici sono relativamente poco costosi, dal punto di vista della potenza di elaborazione che richiedono, e per questo motivo vengono tipicamente usati in congiunzione con algoritmi asimmetrici. Uno degli algoritmi simmetrici utilizzati al momento è il DES (Data Encription Standard) con chiavi di 56 o 112 bit.

6.1.2. Algoritmi asimmetrici Gli algoritmi asimmetrici sono di concezione recente (1976) ed utilizzano due chiavi distinte per cifrare e decifrare, con alcune proprietà fondamentali: • un documento cifrato con una chiave può essere decifrato con l’altra e viceversa; • le chiavi vengono generate in coppia da uno speciale algoritmo ed è di fatto

impossibile ottenere una chiave a partire dall’altra; • una qualsiasi delle due chiavi viene detta pubblica, è può essere distribuita; l’altra,

detta privata, deve essere mantenuta segreta. Nella comunicazione fra N soggetti, gli algoritmi asimmetrici risultano decisamente più utili dei simmetrici in quanto: • occorre una sola coppia di chiavi per ciascun soggetto. • ogni soggetto genera autonomamente una propria coppia di chiavi, ed è tenuto a

mantenere segreta una sola di esse, quella privata, mentre può, anzi deve, pubblicare l’altra;

• le chiavi private non devono essere scambiate, dunque non sussiste pericolo di intercettazioni.

Se il soggetto A vuole inviare un messaggio riservato al soggetto B, ad esempio, cifra il messaggio con la chiave pubblica di B che, in quanto pubblica, è nota a tutti. In questo modo il messaggio sarà decifrabile soltanto con la chiave privata di B che, in quanto privata, solo B conosce.

L’algoritmo RSA, proposto da Rivest, Shamir e Adleman nel 1978, è attualmente considerato come standard per la crittografia a chiave pubblica. Esistono varie implementazioni di RSA, che utilizzano coppie di chiavi di 512 o di 1024 bit.

6.1.3. Utilizzo congiunto di algoritmi simmetrici ed asimmetrici

A causa della loro complessità, le implementazioni degli algoritmi asimmetrici sono generalmente troppo lente per cifrare direttamente i documenti. Per questo motivo essi si utilizzano spesso in congiunzione con algoritmi simmetrici e di hashing sicuro. Per inviare un documento di grandi dimensioni in modo riservato, ad esempio, si genera una password casuale, si cifra il documento con DES (algoritmo simmetrico di veloce

A

B

16

esecuzione) la password casuale, poi si cifra la password stessa (molto più breve del documento) con RSA (algoritmo asimmetrico, più lento), ed infine si invia il tutto (documento cifrato in modo simmetrico e password cifrata in modo asimmetrico) al destinatario.

6.2. Algoritmi di hashing sicuro Questi algoritmi permettono di creare, a partire da un documento D, una sequenza di bit, detta digest, strettamente correlata a D e di lunghezza fissa (cioè indipendente dalla dimensione di D). Un algoritmo di questo tipo generalmente utilizzato dai servizi sicurezza è lo SHA (Secure Hash Algorithm), sviluppato a partire da un lavoro di ricerca di Rivest. Esistono versioni implementate di SHA che generano digest di 160 bit ad una velocità piuttosto soddisfacente nella maggioranza delle applicazioni. L’utilizzo più immediato di SHA è nelle verifiche di integrità: confrontando digest ottenuti da uno stesso documento a distanza di tempo, è possibile verificare facilmente se il documento ha subito alterazioni. SHA è inoltre spesso utilizzato insieme ad RSA per generare e validare firme digitali. Per generare una firma: • si estrae un digest SHA dal documento da firmare; • si cifra RSA il digest con la chiave privata del firmatario. Chiunque può verificare la validità della firma: • decifrando la firma con la chiave pubblica del firmatario; • generando a parte un digest SHA del documento firmato; • confrontando il digest ottenuto dalla firma con quello ottenuto dal documento.

6.3. Servizi base di sicurezza Vari servizi di sicurezza sono stati definiti in modo formale dallo standard ISO 7498-2. In questa sezione analizziamo, per alcuni di questi servizi, un esempio di come sia possibile realizzarli utilizzando in modo combinato gli algoritmi RSA, DES ed SHA. Si assume nel seguito che i servizi descritti operino nell'ambito di un sistema in cui a ciascuna delle parti sia stata assegnata una coppia di chiavi RSA, essendo quella privata mantenuta segreta dal rispettivo possessore, e quella pubblica consultabile in un registro mantenuto da una terza parte da tutti riconosciuta come fidata.

6.3.1. Introduzione di riservatezza

Obiettivo di questo servizio è quello di rendere un documento, o più genericamente una informazione, leggibile solo da parte di un destinatario prefissato, cioè senza possibilità che terze parti possano interpretarlo. Sebbene questo servizio possa essere realizzato, sul piano teorico, con l'utilizzo del solo RSA, la lentezza di tale algoritmo (come di tutti quelli asimmetrici) rende necessario l'utilizzo congiunto di un algoritmo simmetrico quale il DES.

17

I passi di cui si compone il servizio di introduzione della riservatezza sono elencati di seguito e sintetizzati nella figura successiva. 1. Viene generata una chiave DES in modo pseudo-casuale. 2. L'informazione che si vuole rendere riservata viene cifrata con DES utilizzando la

chiave pseudo-casuale. 3. La chiave pseudo-casuale, che se intercettata permetterebbe di decifrare

l'informazione originale, viene a sua volta cifrata con RSA utilizzando la chiave pubblica del destinatario, cioè dell'interlocutore al quale si desidera comunicare l'informazione in modo riservato.

Conviene sottolineare come RSA, troppo lento per cifrare la intera informazione originale (tipicamente costituita da un documento di molte pagine), può invece essere applicato alla chiave DES con prestazioni soddisfacenti in quanto questa è di appena 112 bit. Una volta cifrata con la chiave RSA pubblica del destinatario, la chiave DES che permetterebbe la decodifica della informazione riservata sarà decifrabile solo dal destinatario stesso, in quanto egli è l'unico a possedere la corrispondente chiave RSA privata.

Informazione in chiaro

DES

Chiave RSA pubblica del destinatario

Chiave DES

casuale

Informazione cifrata

RSA

Chiave DES casuale cifrata

18

6.3.2. Rimozione di riservatezza Obiettivo di questo servizio è quello di permettere al destinatario di una informazione a lui riservata di riportare in chiaro, cioè in forma leggibile, l'informazione stessa. I passi di cui si comp one il servizio di rimozione della riservatezza sono elencati di seguito e sintetizzati nella figura successiva. 1. Viene ricevuta la informazione cifrata e, in allegato, la relativa chiave DES (cioè la

chiave con cui l'informazione stessa è stata cifrata). La chiave DES è a sua volta cifrata RSA con la chiave pubblica del destinatario.

2. Il destinatario decifra la chiave DES applicando su di essa RSA con la propria chiave privata. Essendo tale chiave nota solo al destinatario, nessun altro può decifrare la chiave DES e quindi l'informazione originale.

3. L'informazione cifrata viene riportata in chiaro, cioè in forma intelligibile, applicando su di essa DES con la chiave decifrata.

Informazione cifrata

DES

Chiave RSA privata

del

Informazione in chiaro

RSA

Chiave DES cifrata

Chiave DES in chiaro

19

6.3.3. Apposizione di firma digitale Obiettivo di questo servizio è quello di generare, dato un documento e la chiave privata di un soggetto che chiameremo firmatario, una sequenza di bit detta firma digitale che provi in modo non ripudiabile il possesso del documento "firmato" da parte del soggetto firmatario. I passi di cui si compone il servizio di firma digitale sono elencati di seguito e sintetizzati nella figura successiva. 1. Al documento viene applicato SHA al fine di ottenere un digest, cioè una breve

sequenza di bit equivalente ad una "impronta digitale" del documento. La stretta correlazione fra il documento ed il suo digest, assicurata da SHA, garantiscono con sufficiente sicurezza che firma generata dal servizio sia stata effettivamente apposta sul documento originale.

2. Il digest viene cifrato RSA con la chiave privata del firmatario. Il fatto che il risultato della cifratura, cioè la firma, sia decifrabile solo con la chiave pubblica del firmatario garantisce circa la identità del firmatario stesso.

Chiave RSA privatadi chi firma

RSA

Documento

SHA

Digest

Firma

20

6.3.4. Verifica di firma digitale Obiettivo di questo servizio è quello di verificare l’autenticità di una firma digitale, rispetto al documento firmato ed al soggetto firmatario. In particolare, dato un documento, un soggetto (o meglio la sua chiave pubblica) ed una firma, il servizio verifica che quel soggetto (e non altri) abbia effettivamente apposto la firma sul quel documento (e non su altri o sullo stesso modificato in qualche sua parte). I passi di cui si compone il servizio di verifica di una firma digitale sono elencati di seguito e sintetizzati nella figura successiva. 1. La firma viene decifrata con RSA utilizzando la chiave pubblica del soggetto

firmatario. In questo modo, se la firma è autentica, si ottiene il digest del documento al momento della firma.

2. Il documento nella versione corrente viene sottoposto ad SHA e ne viene generato il digest che, se il documento non ha subito modifiche e se la firma è autentica, dovrebbe coincidere con quello ottenuto al passo precedente decifrando la firma con RSA.

3. Il digest ottenuto applicando SHA sul documento viene confrontato con il digest ottenuto applicando RSA sulla firma. Se i digest coincidono la firma è valida, altrimenti la firma è apocrifa (cioè apposta da un soggetto diverso da quello considerato) e/o il documento è stato modificato dopo la firma.

Per distinguere il caso di firma apocrifa da quello di firma apposta su diverso documento, è possibile, nell'ambito del servizio di generazione della firma, accodare al digest del documento una stringa fissa che viene quindi cifrata RSA insieme al digest. Il

Documento nella versione

SHA

Digest del documento nella versione

Chiave RSA pubblica del supposto

firmatario

Firma

RSA

Digest del documento al momento della

Comparazione

Firma apocrifa o autentica ma apposta su un

documento diverso da quello corrente

= !=

Firma valida

21

servizio di verifica, una volta decifrata la firma, potrà così verificare la presenza della stringa fissa e, nel caso di alterazione della stessa, dedurre il fatto che la chiave pubblica utilizzata non corrisponde a quella privata che ha generato la firma e che quindi, in definitiva, la firma è stata apposta da un soggetto diverso dal supposto firmatario.

6.3.5. Timbratura Obiettivo di questo servizio è quello di associare in modo incontestabile un riferimento temporale (data ed ora esatta) ad un dato documento. Affinché questo servizio sia di qualche utilità è essenziale che venga svolto da un soggetto al di sopra degli altri e da tutti ritenuto autorevole e fidato. Questo soggetto, spesso indicato come terza parte fidata, dovrà naturalmente gestire autonomamente ed in modo sicuro un orologio di sistema. I passi di cui si compone il servizio di timbratura sono elencati di seguito e sintetizzati nella figura successiva. 1. Alla informazione da timbrare viene applicato SHA al fine di ottenerne il digest.

Questa operazione è tipicamente compiuta dal soggetto che richiede il servizio di timbratura.

2. La terza parte fidata accoda al digest la data e l'ora dell'orologio di sistema da essa gestito autonomamente.

3. La terza parte fidata cifra RSA il digest e la sequenza temporale utilizzando la propria chiave privata. Il risultato della cifratura è il timbro, la cui validità è verificabile da chiunque semplicemente decifrando il timbro stesso con la chiave pubblica della terza parte fidata.

Chiave RSA privata del server di timbratura

RSA

Informazione da timbrare

SHA

Timbro

Data ed ora corrente del server di timbratura

Digest con time-stamp

22

6.4. Servizi di notariato I servizi di notariato sono offerti da una Autorità di certificazione (nel seguito indicata come Autorità) che sia riconosciuta come fidata ed autorevole da tutti gli utenti del sistema informativo. Come ogni altro utente, anche l'Autorità dispone di una coppia (privata, pubblica) di chiavi asimmetriche. I principali servizi di notariato offerti dall'Autorità sono la certificazione delle chiavi pubbliche, la gestione delle chiavi pubbliche sospese o revocate, la certificazione temporale, detta anche timbratura.

6.4.1. Certificazione di una chiave pubblica Con la certificazione di una chiave pubblica l'Autorità garantisce la sua effettiva corrispondenza con il soggetto che la espone. A tal fine, l'Autorità pubblica mantiene, in un apposito registro, certificati firmati con la propria chiave privata. Tali certificati includono il nome dell'Autorità, la data di emissione del certificato, la data di scadenza del certificato, il nominativo univoco del soggetto (cioè reso non ambiguo da dati aggiuntivi, nel caso di omonimie) e la chiave pubblica del soggetto. Vale la pena di osservare la estrema importanza che ha la certificazione delle chiavi pubbliche nella verifica di una firma digitale. Per tale verifica occorre infatti: • conoscere la chiave pubblica del soggetto firmatario al momento della firma; questo

é possibile richiedendo all'Autorità il relativo certificato; • essere certi della reale appartenenza della chiave al soggetto firmatario; la firma

dell'Autorità garantisce la validità del certificato e quindi la effettiva corrispondenza fra chiave pubblica e soggetto.

Tale sequenza di operazioni viene tipicamente svolta in modo automatico dal software che gestisce le firme digitali, a partire da informazioni contenute nella firma stessa.

6.4.2. Gestione delle chiavi pubbliche sospese o revocate

Le chiavi pubbliche possono essere sospese o revocate (ad esempio a seguito di furto o smarrimento delle corrispondenti chiavi private). L'Autorità deve quindi gestire un registro storico delle chiavi pubbliche revocate, al fine di garantire nel tempo la verificabilità delle firme generate utilizzando le corrispondenti chiavi private.

6.4.3. Gestione del tempo di riferimento e timbratura ufficiale Il servizio base di timbratura ricade fra i servizi di notariato in quanto richiede che il time-stamp sia generato ed apposto da una Autorità riconosciuta da parte tutti gli utenti del sistema. come detentrice affidabile del riferimento temporale.

7. Tecniche avanzate di autenticazione

La autenticazione degli utenti é generalmente basata su una combinazione di tre tipi di elemento:

23

• conoscenze dell’utente (per esempio una password); • oggetti posseduti dall’utente (per esempio una card o una smart-card); • caratteristiche biometriche dell’utente (per esempio l’impronta di un polpastrello o

l’immagine di una retina).

7.1. Password La tecnica di autenticazione tramite password é quella più diffusa, ma presenta vari problemi legati al fatto che, tendenzialmente, gli utenti: • impostano password troppo brevi, che quindi possono facilmente essere individuate

attraverso tentativi ripetuti, o prevedibili (per esempio il proprio nome); • impostano password appropriate ma poi le scrivono in luoghi non sicuri, per non

doverle imparare a memoria; • impostano password appropriate, impiegano del tempo per impararle a memoria, ma

proprio per questo non le cambiano mai. Configurando opportunamente i sistemi é spesso possibile fare in modo che l’utente sia costretto a inserire password di lunghezza e formato appropriato (per esempio almeno 20 caratteri di cui almeno 5 numerici) ed a cambiare la password periodicamente o addirittura ad ogni sessione (one-time password), anche al fine di evidenziare eventuali accessi illeciti.

7.2. Card Le card sono tessere che memorizzano in modo non duplicabile o alterabile la chiave privata dell’utente. La card dialoga con la stazione di lavoro attraverso un apposito lettore, ed software applicativo può interrogarla per ottenere la chiave privata dell’utente. La card fornisce la chiave privata solo se riceve dalla applicazione (e quindi dall’utente) un PIN (Personal Identification Number) segreto. In definitiva, analogamente a quanto avviene con il Bancomat, l’utente é identificato sia per il fatto di conoscere il PIN, sia per il fatto di possedere la card. Il punto debole delle card é insito nel fatto che la chiave privata dell’utente viene trasferita sulla stazione di lavoro, ove potrebbe essere intercettata.

7.3. Smart-card A differenza delle semplici card, le smart-card non si limitano a memorizzare in modo inalterabile la chiave privata dell’utente, ma dispongono di firmware, micro-processore e memoria con caratteristiche sufficienti a eseguire autonomamente un algoritmo asimmetrico di crittografia. Il principale vantaggio delle smart-card, rispetto alle card semplici, é che non richiedono il trasferimento della chiave privata dell’utente sulla stazione di lavoro. La chiave rimane sempre stabilmente memorizzata nella card, che resta peraltro inutilizzabile senza il PIN associato.

24

La presenza di un micro-processore a bordo, permette inoltre alle card interessanti funzionalità accessorie, quali ad esempio la generazione e la memorizzazione automatica di una one-time password ad ogni sessione di lavoro.

8. Componenti e servizi per la sicurezza su reti Nell'affrontare la complessa tematica della sicurezza su reti, conviene distinguere fra le componenti che possono essere utilizzate (cifratori, screening router ed application gateway, etc.) e i servizi che esse offrono (packet-filtering, packet-inspection, proxy, etc.), e gli schemi architetturali nell'ambito dei quali possono essere impiegate (bastion host, firewall). Accenneremo anche ai protocolli sicuri sul Web, una tematica di grande interesse ed in veloce evoluzione.

8.1. Componenti e relativi servizi

8.1.1. Cifratori del traffico

I cifratori sono dispositivi hardware che operano a basso livello, in modo trasparente rispetto allo strato applicativo, cifrando indiscriminatamente tutto il traffico. Sono generalmente impiegati a coppie fra router che collegano due reti locali attraverso un collegamento geografico. In tal caso, i cifratori incapsulano il traffico IP (IP-tunneling) in modo da cifrare non solo il payload ma anche lo header dei pacchetti originali. Nell’ambito di una LAN, infine, client e server possono essere dotati si schede di rete cifranti che, opportunamente configurate, consentono la autenticazione reciproca e la cifratura del traffico in modo trasparente rispetto allo strato applicativo.

8.1.2. Screening router Gli screening router sono dispositivi in grado di bloccare o instradare i pacchetti in transito fra la rete interna e quella esterna, sulla base della loro intestazione (packet-filtering) o del loro contenuto (packet-inspection). Si tratta in ogni caso di dispositivi operano a basso livello (rete e trasporto) e quindi in modo trasparente rispetto allo strato applicativo. Gli screening router sono chiaramente soggetti ad attacchi tesi a riconfigurare l’insieme delle regole di filtraggio dei pacchetti. Per questo motivo, le loro eventuali funzioni di configurazione remota devono essere disabilitate. I router in generale, inoltre, sono sensibili ad attacchi tesi a modificare le tabelle interne di routing ed aggirare in tal modo eventuali firewall posti a difesa della rete interna. Questo tipo di attacchi possono ad esempio essere condotti attraverso falsi pacchetti ICMP. Per questo motivo, gli screening router vanno configurati in modo da disabilitare le funzioni di dynamic-routing. I servizi offerti dagli screening router sono generalmente di due tipi: packet-filtering e packet-inspection.

25

8.1.2.1. Packet filtering router Gli screening router basati sul packet-filtering valutano i pacchetti sulla base della loro intestazione (header). Si tratta di dispositivi configurabili con una lista ordinata di regole che permettono o negano il passaggio di un pacchetto sulla base delle informazioni contenute nell’header, quali: • indirizzo IP e porta sorgente, • indirizzo IP e porta destinazione, • TCP flag, • IP options. Molti produttori di router applicano le regole di filtraggio solo sui pacchetti in uscita dal router, e non su quelli in ingresso. In questo modo, tuttavia, pacchetti artificiosamente generati aventi come indirizzo sorgente quello di un host della rete interna (attacco di tipo address-spoofing) sarebbero instradati dal router sulla rete interna come se fossero effettivamente provenienti dall’host oggetto dello spoofing. Verificando i pacchetti anche in ingresso, il router può facilmente rilevare che un pacchetto con indirizzo sorgente uguale a quello di un host interno non può provenire dalla rete esterna, e deve quindi essere bloccato. L'esame dei pacchetti in ingresso e in uscita consente di effettuare le seguenti azioni: • sui pacchetti che giungono al router dalla rete esterna:

• l’indirizzo IP sorgente permette di definire regole che accettino o scartino pacchetti provenienti da un host o da una sottorete di host esterni;

• l’indirizzo IP destinazione permette di definire regole che accettino o scartino pacchetti destinati ad un host o ad una sottorete di host interni;

• sui pacchetti che giungono al router dalla rete interna: • l’indirizzo IP sorgente permette di definire regole che accettino o scartino

pacchetti provenienti da un host o da una sottorete di host interni; • l’indirizzo IP destinazione permette di definire regole che accettino o scartino

pacchetti destinati ad un host o ad una sottorete di host esterni; • su tutti i pacchetti:

• la porta sorgente e quella di destinazione permettono di definire regole che accettino o scartino pacchetti relativi a servizi e protocolli che operano su porte con numeri noti o compresi in intervalli noti, quali telnet, FTP e X-Windows;

• il TCP flag permette di definire regole che accettino o scartino pacchetti specifici, come quelli di inizio (SYN) o conferma (ACK) di una connessione.

Un problema specifico dei packet-filtering router risiede nella difficoltà di individuare un insieme di regole corretto e completo rispetto alle esigenze della sicurezza. Individuare eventuali errori nella configurazione di un packet-filtering router può essere inoltre assai difficile per la mancanza di strumenti automatici di verifica, e per la incompletezza dei log generati.

26

8.1.2.2. Packet inspection router Gli screening router basati sul packet-inspection valutano i pacchetti sulla base del loro contenuto (payload). Si tratta di dispositivi in grado di comprendere un insieme predefinito (ed a volte configurabile) di protocolli che viaggiano incapsulati nel protocollo IP, e in taluni casi controllare lo stato delle relative sessioni (stateful inspection). A fronte della loro complessità, i packet-inspection router offrono una notevole flessibilità nella definizione delle regole di filtraggio (smart-rules) che, operando a livello di sessione (session filtering), sono spesso paragonabili a quelle offerte dagli application gateway. Rispetto agli application gateway, però, i packet-inspection router non hanno funzionalità proxy, cioè non ricostruiscono i pacchetti ma si limitano a lasciar transitare quelli che superano le regole di filtraggio.

8.1.3. Application gateway

Gli application gateway sono i dispositivi che offrono, limitatamente ai protocolli supportati, attualmente il maggior grado di controllo del traffico fra una rete interna e la rete Internet. Sono generalmente realizzati tramite un calcolatore opportunamente configurato con software specifico in grado di erogare, accanto ai servizi di packet-filtering e packet-inspection (già visti negli screening router), anche i cosiddetti servizi di application proxy. Un application proxy é un processo che, eseguito sul gateway, si interpone a livello di applicazione nella comunicazione fra componenti di una specifica applicazione per la quale é stato progettato. Esempi di application proxy commercialmente disponibili sono quelli per il controllo del traffico telnet, FTP ed HTTP. Nel caso di applicazioni client-server, ad esempio, un application proxy comunica con il client simulando di essere il server, e viceversa, comunica con il server simulando di essere il client. In nessun caso i pacchetti viaggiano direttamente fra client e server. Il flusso dei pacchetti provenienti da ciascuna delle parti viene: • intercettato dal proxy; • interpretato a livello applicativo; • ricostruito sulla base della conoscenza del protocollo; • instradato verso la parte opposta. Rispetto ai packet-inspection router, gli application gateway (o meglio gli application proxy in esecuzione su di essi), presentano vantaggi e svantaggi che vanno adeguatamente considerati:

27

• ricostruendo il traffico, un application gateway minimizza le probabilità di successo di attacchi basati su debolezze di un server rispetto a particolari sequenze di messaggi non previste dal protocollo;

• la ricostruzione dei pacchetti in uscita richiede un tempo di processamento che rende un application gateway solitamente più lento di un packet-inspection router;

• operando a livello di applicazione, un application gateway è in grado di controllare un numero generalmente più ridotto di protocolli, e richiede la installazione e la configurazione di un nuovo proxy per ciascun nuovo protocollo da gestire.

8.2. Schemi architetturali

8.2.1. Bastion host

Con il termine “bastion host” si intende generalmente un application-gateway di particolare importanza per la sicurezza della rete, in quanto unico punto di contatto fra la rete stessa e l’esterno.

8.2.2. Firewall Con il termine “firewall” si identifica in modo generico un insieme di componenti e di servizi finalizzati a controllare e limitare il traffico fra una rete da proteggere e l’esterno. Gli schemi architetturali secondo i quali le componenti disponibili (principalmente router ed application gateway) possono essere disposte al fine di proteggere una rete sono molteplici, e vanno valutati dal progettista sulla base di vari fattori: • sicurezza; • flessibilità, rispetto al controllo di nuovi protocolli ed applicazioni; • prestazioni del sottosistema firewall e della rete nel suo complesso; • costo di installazione e manutenzione. Alcuni degli schemi comunemente adottati vengono brevemente illustrati di seguito a titolo esemplificativo, e commentati relativamente alle caratteristiche appena citate.

8.2.2.1. Schema "packet-filtering"

Rete interna

Packet-filteringrouter

Internet

28

Lo schema firewall detto "packet-filtering" è una soluzione spesso adottata in quanto poco costosa. Si tratta tuttavia di uno schema difficilmente configurabile e manutenibile. Inoltre implica che ogni host deve disporre di meccanismi avanzati di autenticazione degli utenti.

8.2.2.2. Schema "dual-homed"

Rete interna

Applicationgateway

Internet

Infoserver

Packet-filteringrouter

Lo schema firewall detto "dual-homed" prevede un application gateway con doppia scheda di rete ed IP-forwarding disabilitato. Questo schema presenta una ottima sicurezza ma una scarsa flessibilità in quanto solo il traffico riconosciuto dai proxy offerti dal gateway viene instradato verso la rete interna. Il server (info-server) a monte del gateway permette inoltre di pubblicare informazioni (per esempio un sito Web) senza sovraccaricare il gateway.

8.2.2.3. Schema "screened host"

Rete interna

Applicationgateway

Internet

Infoserver

Packet-filteringrouter

Emailserver

Lo schema firewall detto "screened-host" é in generale meno sicuro di quello dual-homed, ma più flessibile: il traffico può infatti aggirare l’application gateway laddove questo non offra un proxy utilizzabile.

8.3. Cenni sui protocolli sicuri sul Web

La forte diffusione dei servizi su Web e l'interesse crescente verso le possibilità del commercio elettronico stanno dando grande impulso alla definizione di protocolli per la

29

comunicazione sicura sul Web. Si esaminano brevemente due dei primi protocolli che fanno uso delle tecnologie di cifratura: S-HTTP ed SSL.

8.3.1. Schema S-HTTP

Lo schema di funzionamento di questo protocollo è il seguente: • il client richiede un documento protetto; • il server replica con un messaggio di tipo “Unauthorized” al quale allega la propria

chiave pubblica; • il client genera una chiave casuale (session-key), vi associa i dati identificativi

dell’utente ed un time-stamp, cifra il tutto con la chiave pubblica del server e glielo invia;

• il server decifra il messaggio del client con la sua chiave privata, estrae la session-key del client, la usa per cifrare il documento riservato, ed invia il documento cifrato al client;

• il client decifra il documento con la stessa session-key e lo presenta all’utente.

8.3.2. Schema SSL (Secure Socket Layer) A differenza del protocollo S-HTTP, la chiave pubblica del server è fornita al client attraverso un certificato rilasciato e firmato da una Autorità di certificazione. Inoltre anche il client può essere autenticato laddove disponga di un certificato valido per la sua chiave pubblica. Come per S-HTTP, la riservatezza delle comunicazioni é realizzata attraverso la cifratura simmetrica del traffico con una chiave di sessione generata casualmente. SSL supporta inoltre la firma digitale dei documenti scamb iati fra client e server. SSL é indipendente dal protocollo di applicazione, e può quindi supportare qualsiasi servizio che usi il protocollo TCP, quindi non solo HTTP ma anche News, Telnet, FTP, etc.

9. Un approccio metodologico al problema della sicurezza

La sicurezza può essere un requisito di progetto di un sistema informatico ancora da realizzare, oppure una caratteristica da aggiungere ad un sistema informatico già in esercizio. Fermo restando che molti dei temi da trattare restano sostanzialmente invariati in entrambe gli scenari, nel primo caso i temi specifici della sicurezza si legano inevitabilmente con quelli relativi al progetto del sistema complessivo. Questa sezione descrive le principali attività necessarie per la definizione di una politica di sicurezza per un sistema informatico. Come si vedrà, occorre in sostanza analizzare il sistema ed il contesto in cui opera, capire da cosa difenderlo e decidere come farlo.

9.1. Analisi del contesto La definizione di una politica di sicurezza per un sistema informatico non può prescindere da una buona conoscenza dell'organizzazione in cui opera. Occorre in

30

sostanza comprendere le finalità della organizzazione, la sua struttura ed il flusso di lavoro che avviene al suo interno. Parte di tale conoscenza può evidentemente essere tratta dalla analisi svolta per la realizzazione del sistema informatico in esame. Un'analisi preliminare dell'organizzazione in cui opera il sistema informatico guida inoltre nella successiva classificazione dei soggetti che lo utilizzano, e permette di evidenziare una serie di vincoli importanti, di carattere logistico, amministrativo e legislativo, da tenere presenti nella definizione di una politica di sicurezza. Ad un primo livello di astrazione, appare dunque importante valutare: • finalità della organizzazione; • numero e distribuzione geografica delle sedi; • unità organizzative (ad esempio dipartimenti ed uffici) di cui si compone; • ruoli, competenze e responsabilità di ciascun unità; • flussi informativi, relazioni gerarchiche e funzionali esistenti fra le varie unità.

9.2. Analisi del sistema informatico

Per analizzare un sistema informatico è importante cogliere, nelle sue varie componenti, il doppio aspetto fisico e logico. L’intera analisi può essere quindi svolta in modo più sistematico distinguendo i due piani, fisico e logico, ed evidenziandone, laddove sia rilevante, la complementarità. Occorre inoltre rilevare, anche al fine di individuare i punti nevralgici del sistema, le dipendenze funzionali fra le varie componenti.

9.2.1. Analisi degli aspetti fisici

In questa fase, l’analisi tende ad evidenziare tutti quegli aspetti legati al fatto che il sistema informatico ha una sua fisicità, cioè che è costituito da apparecchiature (elaboratori elettronici, cavi, periferiche, etc.) che occupano spazio, necessitano di alimentazione elettrica e di condizioni ambientali idonee in quanto soggetti a guasto, furto, incendio, etc.

9.2.1.1. Individuazione e catalogazione delle componenti fisiche

Occorre innanzitutto individuare e catalogare tutte le componenti fisiche necessarie al corretto funzionamento del sistema. Tale censimento sarà essenziale in seguito per verificare in modo sistematico che ogni risorsa rispetti i requisiti di sicurezza che verranno individuati, e per controllare periodicamente la presenza di tutte e sole le apparecchiature previste per il sistema. Le principali componenti fisiche solitamente presenti in un sistema informatico moderno sono calcolatori (server e postazioni di lavoro), periferiche (scanner, stampanti, modem) ed apparecchiature di rete.

9.2.1.2. Individuazione ed ispezione dei locali disponibili In secondo luogo, occorre individuare ed ispezionare i locali che ospitano (o che sono destinati ad ospitare) le risorse fisiche del sistema. Una politica di sicurezza può infatti

31

richiedere lo spostamento delle componenti più critiche nei locali che offrono maggiori garanzie, o l’adeguamento dei locali con porte blindate, inferriate alle finestre, sistemi di condizionamento dell’aria, etc. Nell'individuazione/ispezione dei locali destinati ad ospitare le componenti fisiche del sistema occorre tenere conto, per ciascun locale, di vari fattori, più o meno critici in funzione di quali componenti è destinato ad ospitare. I fattori più importanti sono • dimensione ed abitabilità; • collocazione del locale nell’ambito dell’edificio; • numero, posizione e grado di protezione degli accessi; • presenza di un impianto di condizionamento dell’aria; • libertà e costo di intervento in caso di ristrutturazione; • vincoli di carattere politico ed amministrativo nell’uso del locale.

9.2.1.3. Individuazione ed ispezione della cablatura. Occorre infine verificare le canaline che ospitano (o che sono destinate ad ospitare) i cavi e le eventuali connessioni LAN basate su cavo. Può essere opportuno, ad esempio, che i cavi di rete passino in canaline murate, e che attraversino esclusivamente mura interne (non perimetrali).

9.2.2. Analisi degli aspetti logici

In questa fase, l’analisi astrae dagli aspetti fisici del sistema informatico, e tende piuttosto ad evidenziare i servizi che il sistema informatico offre ai suoi utenti, e le modalità con cui tali servizi si esplicano.

9.2.2.1. Classificazione delle informazioni Ai fini della sicurezza, le informazioni possono essere classificate in modo più o meno fine in funzione delle esigenze dell’utenza. La classificazione serve a definire vincoli comuni alla circolazione ed alla fruizione di informazioni con caratteristiche analoghe in termini di valore e di riservatezza. La classe di ciascuna informazione determina insomma il tipo di protezione che il sistema garantisce per essa. Alcuni parametri per la classificazione delle informazioni ai fini della sicurezza possono essere • valore per l'organizzazione: può essere misurato a partire dallo sforzo sostenuto per

ottenerle, dal numero e dalla importanza dei processi che ne dipendono; • grado di riservatezza: può essere valutato in funzione del danno ipotizzabile in caso

di utilizzo illecito; • afferenza ad un certo contesto: alcune informazioni possono essere riservate o meno

in funzione del contesto al quale afferiscono.; ad esempio, negli atti dei procedimenti giudiziari, la residenza di un pentito è da considerare più riservata di quella di un comune indagato.

32

Il lavoro di classificazione va svolto al giusto livello di astrazione, deve cioè tenere conto di come i dati elementari sono aggregati nel flusso di lavoro della organizzazione (ad esempio in pratiche, certificati, verbali). È possibile che tutte le istanze di uno stesso concetto (ad esempio, sempre nel caso di procedimenti giudiziari, tutti gli interrogatori) siano collocabili in una unica classe ai fini della sicurezza. In generale, tuttavia, le classi di sicurezza non coincidono con quelle che emergono dalla analisi concettuale, e possono raggruppare istanze di concetti diversi o sottoinsiemi delle istanze di uno stesso concetto. Ad esempio, potremmo voler considerare come riservati solo gli interrogatori effettuati ad un certo indiziato. In altre parole, informazioni dello stesso tipo sono generalmente protette in modo analogo, ma è anche possibile che ciascuna singola informazione venga etichettata con specifici attributi finalizzati ad istruire il sistema su come proteggerla.

9.2.2.2. Classificazione dei servizi

I servizi esplicano le potenzialità del sistema informativo permettendo, a tutti e soli gli utenti abilitati, di accedere alle informazioni di loro pertinenza, elaborarle nei limiti delle autorizzazioni loro concesse, renderle disponibili ad altri utenti abilitati. Una condizione necessaria, perché un sistema sia sicuro, è che gli utenti (fatta qualche eccezione per gli amministratori) possano controllarlo esclusivamente attraverso i servizi messi a disposizione. Questo evidenzia l’importanza di individuare con precisione tutti i servizi offerti dal sistema informatico, al fine di verificare poi, in maniera sistematica, che ogni servizio risponda pienamente a tutte e sole le specifiche di progetto (e non presenti, ad esempio, side-effects potenzialmente pericolosi). L'analisi funzionale svolta per la realizzazione del sistema sono generalmente una buona fonte di informazione per la individuazione dei servizi disponibili.

9.2.3. Analisi delle dipendenze funzionali Per ciascuna componente del sistema, sia essa fisica o logica, occorre individuare di quali altre componenti ha bisogno per funzionare correttamente. Questa analisi tende ad evidenziare, almeno in prima battuta, alcune delle componenti potenzialmente critiche del sistema, cioè quelle da cui dipende il funzionamento di un numero rilevante di altre componenti. I risultati di questa analisi sono poi utilizzati anche nella fase di valutazione del rischio, ed in particolare sono di supporto allo studio della propagazione dei malfunzionamenti a seguito della occorrenza di eventi indesiderati. I risultati dell'analisi delle dipendenze fra risorse sono poi utilizzati anche nella fase di valutazione del rischio, ed in particolare sono di supporto allo studio della propagazione dei malfunzionamenti a seguito del verificarsi di eventi indesiderati.

33

9.3. Classificazione degli utenti La assegnazione di una classe di appartenenza a ciascun utente permette di definire, per tutti gli utenti di una medesima classe, vincoli comuni ai fini della sicurezza. Analogamente a quanto visto per le informazioni, la classificazione consente di ignorare le particolarità irrilevanti del singolo utente, e di imporre vincoli basati sul ruolo che l’utente stesso riveste nell’ambito del sistema. Gli utenti possono quindi essere classificati, ad un primo livello di approssimazione, a partire dal ruolo che rivestono all’interno della organizzazione. Tale ruolo delinea infatti, in genere, anche i servizi e le informazioni alle quali hanno diritto di accedere. È talvolta conveniente prevedere che ciascun utente possa disporre di più account sullo stesso sistema, tutti afferenti alla sua persona ma caratterizzati da differenti profili di sicurezza; in questo caso, nel momento in cui accede al sistema con un determinato account, l’utente dichiara implicitamente con quale ruolo desidera interagire, ed il sistema gli concederà tutti e soli i diritti necessari a svolgere il lavoro previsto per quel ruolo.

9.4. Definizione dei diritti di accesso

Definire esplicitamente quello che ciascuna tipologia di utente può fare con il sistema (cioè a quali servizi ed informazioni può accedere e con quali modalità) risulta indispensabile per configurare correttamente i meccanismi di controllo degli accessi offerti dal sistema, e delinea anche implicitamente l’insieme complementare di ciò che non deve poter fare, insieme che verrà esaminato in seguito, nell’ambito più generale degli eventi indesiderati.

9.4.1. Accesso ai servizi e accesso alle informazioni Alla base di qualsiasi sistema informatico sicuro è innanzitutto il rispetto di un principio fondamentale già citato: le informazioni gestite dal sistema devono essere accessibili dagli utenti esclusivamente attraverso i servizi del sistema stesso. Solo in questo modo, infatti, il sistema ha la possibilità di vagliare la liceità dell’accesso ed eventualmente negarlo. Nel valutare le autorizzazioni di accesso, dunque, è spesso più conveniente chiedersi, per ogni tipologia di utente, “di quali servizi può usufruire”, piuttosto che “a quali informazioni può accedere”. La convenienza di definire le autorizzazioni ai servizi, piuttosto che alle informazioni, risulta evidente considerando che un servizio raramente accede ad un'unica tipologia di informazione, ma, in generale, ad un insieme di informazioni a differente livello di riservatezza. Considerare i servizi piuttosto che le informazioni, laddove si assuma che tali informazioni siano accessibili esclusivamente tramite detti servizi, permette dunque di definire i diritti di accesso ad un più elevato livello di astrazione.

34

Nei sistemi informatici più sofisticati, tuttavia, sono disponibili servizi parametrici rispetto ai dati: uno strumento di navigazione all’interno di una base dati, ad esempio, opera su informazioni la cui tipologia (ed il relativo grado di riservatezza) non è generalmente determinabile a priori. In questo caso è fondamentale definire, per ciascuna tipologia di utente, le autorizzazioni di accesso sia ai servizi che alle varie tipologie di informazione.

9.4.2. Matrice dei diritti di accesso ai servizi I servizi e le tipologie di utente individuate durante la fase di analisi possono essere collocate sugli assi di una tabella allo scopo di avere una visione complessiva dei servizi ai quali può accedere ciascuna tipologia di utente. Ogni cella della tabella così creata (matrice dei diritti di accesso ai servizi) definisce se, a quali condizioni ed in quale modalità, una certa tipologia di utente può accedere ad un certo servizio. Le condizioni che generalmente vengono imposte sono: • sul tempo : basate su data, ora e durata dell’accesso; • sulla storia : basate sul numero e la frequenza degli accessi precedenti.

In effetti la rappresentazione dei diritti di accesso ai servizi richiederà l'utilizzo di più di una matrice, a seconda della tipologia di servizi (di sistema, applicativi, etc.) e del livello di astrazione considerato. Ad esempio, per le applicazioni può essere costruita una matrice generale che stabilisca a quali applicazioni possa accedere ciascuna classe di utenza e una matrice per ciascuna applicazione relativa alle singole funzionalità. Anche la coordinata dell'utenza può generare matrici differenti, una più generale per classi di utenza e una più specifica per singoli utenti che agisca per eccezione rispetto alla prima.

9.4.3. Matrice dei diritti di accesso alle informazioni Nel caso in cui il sistema informatico offra uno o più servizi di tipo parametrico rispetto ai dati (in grado cioè di accedere ad informazioni di tipologia non determinabile a priori) occorre definire, accanto ai servizi utilizzabili, anche a quali tipologie di informazioni ciascuna tipologia di utente debba poter accedere.

Cla

ssi d

i ute

nza

Servizi

CU3

S Condizioni alle quali un utente appartenente alla classe CU3 può accedere al servizio S4.

35

Allo scopo di avere una visione complessiva del problema, è conveniente collocare lungo gli assi di una tabella, analogamente a quanto fatto per l’accesso ai servizi, le tipologie di utente e le tipologie di informazione individuate durante la fase di analisi. Ogni cella della tabella così creata (matrice dei diritti di accesso alle informazioni), definisce se, a quali condizioni ed in quale modalità, una certa tipologia di utente può accedere alle informazioni di una certa tipologia. Le condizioni che generalmente vengono imposte sono: • sul valore, basate sul valore della informazione alle quali si accede; • sul tempo, basate su data, ora e durata dell’accesso; • sul contesto, basate sulle proprietà di una combinazione di valori; • sulla storia, basate sul numero e la frequenza degli accessi precedenti.

Vale la pena sottolineare come un sistema informatico possa controllare in modo più fine l’accesso alle informazioni permettendo all’amministratore, in fase operativa, di etichettare ciascun singolo dato con speciali note aggiuntive che ne definiscono individualmente la accessibilità. In fase di progetto delle misure di sicurezza, tuttavia, i singoli dati non sono ovviamente prevedibili, mentre risultano completamente definiti i tipi di dato che il sistema è in grado di gestire. Anche nel caso della definizione dei diritti di accesso alle informazioni, la rappresentazione completa delle autorizzazioni può richiedere più di una matrice, per specificare l'accesso alle informazioni a diverso livello di dettaglio e le regole valide per classi di utenza e per singoli utenti.

9.5. Individuazione e classificazione degli eventi indesiderati

Una definizione precisa di “evento indesiderato” permette di verificare, a fronte di un'analisi sistematica di tutti gli eventi che potrebbero accadere intorno al sistema, se e quanto ciascun evento sia indesiderato rispetto alla definizione data. Come già accennato

Cla

ssi d

i ute

nza

Classi di Informazione

CU3

CI Condizioni alle quali un utente appartenente alla classe CU3 può accedere ad informazioni di classe CI4.

36

nella sezione "Eventi indesiderati", alla quale rimandiamo il lettore, una preventiva classificazione degli eventi indesiderati risulta utile per affrontare la loro identificazione con sistematicità.

9.6. Valutazione del rischio Una volta definiti e catalogati gli eventi che consideriamo indesiderati, è importante associare un rischio a ciascuno di essi, in modo da indirizzare la successiva attività di individuazione delle contromisure verso le aree del sistema potenzialmente più critiche. Il concetto di rischio esprime in modo combinato la probabilità che un evento accada ed il danno che arreca al sistema se accade.

9.6.1. Valutazione del rischio legato ad attacchi intenzionali Nel caso di attacchi intenzionali: • la probabilità di occorrenza (cioè la probabilità che l’attacco venga tentato) dipende

principalmente dalla facilità di attuazione e dai vantaggi che potrebbe trarne l’intrusore; nella quantificazione della probabilità è utile consultare i dati statistici disponibili in letteratura, rilevati dalla osservazione di sistemi informatici attivi da molti anni. Datapro Research, ad esempio, attribuisce il 10% delle perdite di dati ad omissioni volontarie degli addetti, il 10% a disonestà degli addetti e il 5% ad azioni di estranei;

• il danno arrecabile va misurato come grado di perdita di ciascuno dei tre requisiti fondamentali di riservatezza, integrità e disponibilità; nel valutare il danno, occorre tenere conto delle dipendenze fra risorse, e prevedere l'eventuale propagazione del malfunzionamento iniziale.

Relativamente agli attacchi intenzionali, occorre inoltre partire dal presupposto che l’attaccante applicherà sempre (in sequenza o in parallelo, sfruttando eventuali effetti sinergici), tutte le tecniche di cui dispone su tutte le risorse attaccabili. Conviene dunque, laddove possibile, calcolare anche il rischio legato agli attacchi composti realisticamente attuabili.

9.6.2. Valutazione del rischio legato ad eventi accidentali Nel caso di eventi accidentali: • la probabilità di occorrenza può essere valutata a partire da dati tecnici sulla risorsa

oggetto dell’evento (ad esempio il MTBF di un disco) e/o da dati statistici sulla tipologia di evento (come ad esempio una casistica sugli incendi nei CED); Datapro Research, ad esempio, attribuisce il 55% delle perdite di dati ad errori degli addetti, ed il 20% ad eventi naturali e carenze strutturali (alimentazione, condizionamento, etc.);

• il danno arrecabile va misurato esattamente come vis to per gli attacchi, cioè come grado di perdita di ciascuno dei tre requisiti fondamentali di riservatezza, integrità e disponibilità.

37

Anche nel caso di eventi accidentali, come visto per gli attacchi, conviene talvolta (nel caso in cui la probabilità combinata sia significativa) valutare anche il rischio legato ad eventi composti, costituiti cioè da un insieme di eventi elementari che accadono in sequenza (furto di nastri di backup e successivo guasto di un disco) o in parallelo (inizio di una transazione e contemporanea interruzione della alimentazione elettrica).

9.7. Individuazione delle contromisure

Individuato l’insieme degli eventi indesiderati e valutato il rischio ad essi associato, occorre ora scegliere le contromisure da adottare per neutralizzarli. In questa selezione, accanto ai criteri, è opportuno tenere conto degli standard e dei modelli di riferimento emessi da varie organizzazioni internazionali. Delineato l’insieme di tutte le contromisure utili, occorre poi effettuare una valutazione costo/benefici per ciascuna contromisura, allo scopo di selezionare un sotto-insieme efficace di minimo costo. Per un'introduzione alle principali tipologie di contromisura e per alcuni cenni agli standard esistenti, rimandiamo alla sezione "Contromisure". Di seguito, invece, approfondiamo gli aspetti legati alla valutazione del costo e della efficacia di una contromisura.

9.7.1. Valutazione del costo e dell'efficacia di una contromisura

La considerazione, almeno qualitativa, del rapporto costo/efficacia di ciascuna contromisura, permette di valutarne il grado di adeguatezza, evitando in particolare quelle contromisure con un costo ingiustificato rispetto al rischio dal quale proteggono. L'efficacia di una contromisura può essere valutata, in prima analisi, come funzione del rischio dal quale protegge, cioè dal rischio complessivamente legato agli eventi indesiderati che neutralizza. Il costo di una contromisura deve essere valutato ponendo la dovuta attenzione sui cosiddetti costi nascosti. Oltre al lavoro necessario per individuare ed attuare le contromisure, infatti, occorre tenere presenti le limitazioni che esse impongono e le operazioni di controllo che introducono nel flusso di lavoro del sistema informatico e dell'organizzazione nel suo complesso. Il costo di una contromisura, insomma, deve essere valutato su vari fronti, sia tecnologici che organizzativi. Si hanno, in particolare: • un costo di messa in opera della contromisura: si tratta di un costo “una tantum”

che assume particolare rilevanza laddove la contromisura imponga un riassetto logistico della organizzazione (adeguamento di locali, trasloco di apparecchiature, etc.);

• un peggioramento dell'ergonomia della interfaccia utente: aumentare la sicurezza di un sistema informatico impone generalmente la introduzione o la complicazione delle procedure di autenticazione degli utenti; l’utente che viene costretto a digitare una password ogni volta che accede ad un servizio riservato, ad esempio, troverà il sistema informatico meno piacevole da utilizzare;

38

• un decadimento delle prestazioni del sistema nell’erogare i servizi: allo scopo di validare le autorizzazioni di accesso, o di cifrare le informazioni riservate, un sistema informatico può spendere una parte anche consistente della sua potenza elaborativa; ne consegue un decadimento prestazionale che, superati certi limiti, si traduce in un calo nella produttività degli utenti;

• un aumento nella complessità di procedure e norme comportamentali come la registrazione delle presenze o le richieste di intervento tecnico.

9.8. Integrazione delle contromisure Un insieme di contromisure, per quanto individuate ad hoc rispetto ad un sistema informatico ed alla organizzazione che lo gestisce, può ancora presentarsi come una collezione disorganica di espedienti tecnici ed organizzativi, espedienti non correlati che difficilmente danno risposta adeguata ad un'esigenza di sicurezza che le organizzazioni percepiscono invece come globale. Definire una politica di sicurezza è inoltre un presupposto importante affinché eventuali nuove esigenze in tema di sicurezza (scenario piuttosto probabile) siano trattate in modo consistente e compatibile con le scelte operate in precedenza. Occorre innanzitutto fare una selezione delle contromisure da adottare effettivamente. Lo scopo di tale selezione è quello di individuare il sotto-insieme di costo minimo che al contempo rispetti alcuni vincoli essenziali, come • completezza: il sotto-insieme delle contromisure scelte deve comunque far fronte a

tutti gli eventi indesiderati individuati per il sistema in esame; • omogeneità: le contromisure che si decide di adottare devono essere compatibili ed

integrabili tra loro in modo da minimizzare il costo della loro attuazione congiunta; a fronte di eventi indesiderati con analogo livello di rischio, inoltre, le rispettive contromisure dovrebbero avere costo comparabile;

• ridondanza controllata: la ridondanza delle contromisure ha un costo e deve quindi essere rilevata e vagliata accuratamente; può accadere, ad esempio, che più contromisure siano inutilmente ridondanti, che ad esempio neutralizzino un medesimo evento valutato a basso rischio; d’altra parte, è anche possibile che un evento ad alto rischio, che potrebbe e dovrebbe essere neutralizzato da più di una contromisura, di fatto non lo sia;

• effettiva attuabilità: l’insieme delle contromisure deve rispettare vincoli di tipo logistico (per esempio la distribuzione dei locali), di tipo amministrativo (per esempio limitazioni nella assunzione di nuovo personale), di tipo giuridico (per esempio vincoli su formato e disponibilità delle informazioni).

Le contromisure così selezionate possono e devono essere integrate nel quadro più ampio di una politica organica di sicurezza che le collochi e le giustifichi come parte di un disegno unitario. Per ogni contromisura, in sostanza, deve essere evidenziato il ruolo preciso che occupa in relazione alle altre contromisure ed alle linee guida cui il disegno complessivo risponde.