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

1
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

2
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

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

4
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

5
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

6
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

7
 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

8
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-

9
 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

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

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

12
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

In contesti
Meccanismi di sicurezza particolarmente
implementati a livello applicativo critici ed
articolati

Meccanismi di sicurezza
tipicamente offerti dal DBMS

13
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

14
 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

B 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
A 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

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

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

Informazione
in chiaro

Chiave
DES DES
casuale
Chiave RSA pubblica Informazione
del destinatario
RSA cifrata

Chiave DES
casuale
cifrata

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.

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

Chiave DES
cifrata

Chiave RSA Informazione

privata
RSA
cifrata
del
Chiave DES
in chiaro DES

Informazione
in chiaro

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

Documento

SHA

Digest

Chiave RSA privata

di chi firma
RSA

Firma

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

Firma Documento nella

versione

Chiave RSA pubblica

del supposto RSA SHA
firmatario

Digest del documento Digest del documento

al momento della nella versione

Comparazione
= !=

Firma Firma apocrifa o autentica

valida ma apposta su un
documento diverso da quello
corrente
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

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

Informazione
da timbrare

Data ed ora corrente

SHA del server di timbratura

Digest con time-stamp

Chiave RSA privata

del server di
RSA
timbratura

Timbro

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

22
• 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.

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

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

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

26
• 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"

Packet- Internet
filtering
router

Rete interna

27
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"

Info
server
Application Packet- Internet
gateway filtering
router

Rete interna

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"

Application Info
gateway server
Packet- Internet
filtering
router

Rete interna

Email
server

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

28
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

29
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

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

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

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

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

Servizi

S Condizioni alle quali un

utente appartenente alla
classe CU3 può
accedere al servizio S4.
Classi di utenza

CU3

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.

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

Classi di Informazione

CI Condizioni alle quali un

utente appartenente alla
classe CU3 può accedere
ad informazioni di classe
CI4.
Classi di utenza

CU3

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

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

36
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;

37
• 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.

38