Sicurezza informatica

 

IT Administrator Sicurezza informatica
Introduzione alla sicurezza delle informazioni
Diventate esperti di sicurezza con PC Open

Inizia il primo corso di taglio professionale destinato al conseguimento di una certificazione ufficiale, riconosciuta in tutta Europa. La certificazione fa parte di un nuovo filone denominato EUCIP (European Certification of Informatics Professionals) e si chiama IT Administrator – Sicurezza Informatica. Il corso si articola
in tre elementi: un articolo sulla rivista, un articolo, molto più esteso in formato PDF e un corso multimediale completo
su CD e DVD di Giorgio Gobbi

La sicurezza delle informazioni è un’esigenza che ha accompagnato la storia dell’uomo fin dalle antiche civiltà. Oggi ci preoccupiamo di mantenere riservate le informazioni personali, militari e d’affari. Nel V secolo a.C. gli spartani inviavano gli ordini ai capi militari tramite messaggi scritti su una striscia di cuoio che, avvolta su un bastone (lo scitale) di un diametro ben preciso, permetteva di leggere il testo in chiaro lungo il bastone. Giulio Cesare cifrava i messaggi sostituendo ogni lettera con quella che nell’alfabeto segue di qualche posizione. La crittografia, cioè la scienza della scrittura segreta, ha avuto una progressiva evoluzione nel corso dei secoli, fino ai rapidi sviluppi teorici e tecnologici impressi dalla seconda guerra mondiale, che permisero la decifrazione dei codici giapponesi e te-
deschi da parte degli alleati.
Oggi buona parte del pianeta vive nella società dell’informazione, basata cioè sull’uso delle informazioni come parte integrante delle attività umane. Pertanto, la sicurezza delle informazioni è diventata una componente della sicurezza dei beni in generale, o security, e non si limita alle tecniche per nascondere il contenuto dei messaggi. Qualunque programma che si occupi di preservare la sicurezza delle informazioni, persegue, in qualche misura, tre obiettivi fondamentali: la disponibilità, l’integrità e la riservatezza delle informazioni.
La disponibilità è il grado in cui le informazioni e le risorse informatiche sono accessibili agli utenti che ne hanno diritto, nel momento in cui servono. Questo significa che sistemi, reti e applicazioni hanno le capacità necessarie a fornire il livello di servizio e le prestazioni richieste e che, in caso di guasto o di eventi distruttivi, sono pronti gli strumenti e le procedure per ripristinare l’attività in tempi accettabili. Per impedire l’inaccessibilità delle informazioni, si deve preservare la disponibilità delle condizioni ambientali (energia, temperatura, umidità, atmosfera, ecc.) e delle risorse hardware e software a fronte sia di problemi

interni (guasti, errori, blackout, disastri e altro), sia di attacchi esterni, per esempio provenienti da Internet, volti a impedire o a ridurre l’accessibilità ai sistemi e alle informazioni. Sistemi di backup locale e remoto, ridondanza dell’hardware e degli archivi, firewall e router configurati per neutralizzare attacchi DoS (denial of Service), sistemi di climatizzazione, gruppi di continuità, controllo dell’accesso fisico, monitoraggio delle prestazioni sono alcuni degli strumenti che servono per mantenere la disponibilità.
L’integrità è il grado di correttezza, coerenza e affidabilità delle informazioni e anche il grado di completezza, coerenza e condizioni di funzionamento delle risorse informatiche. Per l’hardware e i sistemi di comunicazione, l’integrità consiste di fattori come elaborazione corretta dei dati, livello adeguato di prestazioni e corretto instradamento dei dati. L’integrità del software riguarda fattori come la completezza e coerenza dei moduli del sistema operativo e delle applicazioni e la correttezza dei file critici di sistema e di configurazione.
Per le informazioni, l’integrità viene meno quando i dati sono alterati, cancellati o anche inventati, per errore o per dolo, e quando si perde, per esempio in un database, la

Lezione 1 IT Administrator Sicurezza informatica

coerenza tra dati in relazione tra loro (per esempio i record coinvolti in una transazione).
Procedure di manutenzione e diagnosi preventiva, hardware e software per la rilevazione e prevenzione di accessi illeciti, attacchi virali e intrusioni, applicazioni che minimizzano errori logici e formali di data entry, accesso ristretto alle risorse critiche e controllo degli accessi sono alcuni degli strumenti utili a preservare l’integrità delle informazioni e delle risorse.
Anche le tecniche di hashing (calcolo di un numero di lunghezza fissa a partire da un qualsiasi messaggio o documento) sono usate per verificare che le informazioni non vengano alterate per dolo o per errore (anche di trasmissione).
La riservatezza consiste nel limitare l’accesso alle informazioni e alle risorse informatiche alle sole persone autorizzate e si applica sia all’archiviazione sia alla comunicazione delle informazioni. Un’informazione è composta generalmente di più dati in relazione tra di loro, ciascuno dei quali non necessariamente costituisce un’informazione. Il nome e il numero di conto corrente di una persona, separati, non sono informazioni; è la combinazione dei due dati che costituisce l’informazione.
La riservatezza dell’informazione può essere quindi garantita sia nascondendo l’intera informazione (per esempio con tecniche di crittografia) sia nascondendo la relazione tra i dati che la compongono. La riservatezza non dipende solo da strumenti hardware e software; il fattore umano gioca un ruolo chiave quando vengono ignorate le elementari regole di comportamento: tenere le password segrete, controllare gli accessi a reti e sistemi, rifiutare informazioni a sconosciuti (anche quando affermano di essere tecnici della manutenzione), cifrare i documenti e i messaggi riservati e così via.
Possiamo aggiungere altri due obiettivi di sicurezza che possono essere considerati un’estensione dell’integrità delle informazioni, applicata a eventi più complessi come l’invio di un messaggio o una transazione. L’autenticità garantisce che eventi, documenti e messaggi vengano attribuiti con certezza al legittimo autore e a nessun altro. Il non ripudio impedisce che un evento o documento possa essere disconosciuto dal suo autore. Queste due caratteristiche trovano applicazione nella firma digitale, che utilizza tecniche di hashing e crittografia per garantire che un documento resti integro e provenga da un autore univocamente identificato.

Gestione del rischio
Per esaminare i rischi connessi ai vari aspetti di sicurezza delle informazioni, iniziamo introducendo i termini del discorso: beni da difendere, obiettivi di sicurezza, minacce alla sicurezza, vulnerabilità dei sistemi informatici e impatto causato dall’attuazione delle minacce.

Beni
Un bene è qualsiasi cosa, materiale o immateriale, che abbia un valore e debba quindi essere protetta. Nel campo della sicurezza delle informazioni, tra i beni di un’azienda ci sono le risorse informatiche, il personale (utenti, amministratori, addetti alla manutenzione), le informazioni, la documentazione e l’immagine aziendale. Per un individuo, i beni comprendono non solo risorse informatiche, informazioni e mezzi di comunicazione, ma anche le informazioni personali e la privacy.
Per esempio, se un attacco via Internet causa a un’azienda il furto di informazioni riservate, magari relative alle carte di credito dei clienti, i beni colpiti sono molteplici: le informazioni, l’immagine, la reputazione, la stessa continuità operativa. Un altro esempio è il defacing, ovvero l’alterazione di un sito web per rovinare l’immagine del proprietario; è una forma di vandalismo che colpisce sia le informazioni sia l’immagine dell’azienda o persona titolare. A livello personale, la privacy degli individui è minacciata da più parti: aziende che non proteggono adeguatamente le informazioni in loro possesso, applicazioni che trasmettono via Internet dati personali, software maligno che spia le abitudini degli utenti (acquisti, navigazione Internet ecc.) o che altera la navigazione Internet a scopo di
truffa o furto di informazioni.
I beni possono essere distinti in beni primari, quelli che hanno valore effettivo, e beni secondari, che servono per proteggere i beni primari. Un esempio di bene secondario è la password che permette di accedere a un computer, a una rete, ai dati archiviati e a Internet. La password in sé non ha alcun valore, ma è un’informazione che permette a un altro utente o a un estraneo di accedere ai beni primari (sistemi, periferiche, reti, archivi) e di eseguire operazioni a nome dell’utente titolare della password, che ne sarà ritenuto responsabile. La password, bene secondario, assume un’importanza paragonabile a quella degli archivi e delle attrezzature hardware/software, bene primario a cui la password dà accesso. Lo stesso vale per i dispositivi di identificazione e autenticazione, come le Smart Card. Se la scheda viene utilizzata da qualcuno che si è procurato il corrispondente PIN (Personal Identification Number), il titolare della scheda sarà ritenuto responsabile dell’utilizzo fino alla denuncia di furto o smarrimento.
Altri esempi di beni secondari sono le attrezzature che permettono all’hardware di funzionare con continuità e sicurezza: gruppi di continuità, condizionatori, alimentatori e altri componenti ridondanti e così via. I beni secondari, in quanto investimento preventivo per mantenere alta la disponibilità dei servizi informatici, rappresentano un costo ampiamente inferiore rispetto al rimedio a situazioni non previste.
Obiettivi
Gli obiettivi di sicurezza sono il grado di protezione che si intende predisporre per i beni, in termini di disponibilità, integrità e riservatezza. Per definire gli obiettivi, si classificano i beni in categorie e si assegnano i criteri di sicurezza da applicare. Ci sono beni, come le password e i numeri di identificazione, che hanno più requisiti di riservatezza che

IT Administrator Sicurezza informatica Lezione 1

non problemi di integrità e disponibilità. Al contrario, le informazioni contabili di una banca che esegue transazioni on line hanno requisiti di disponibilità, integrità e riservatezza. Le informazioni pubblicate sul sito web di un’azienda richiedono disponibilità e integrità (per esempio per impedire il defacing), ma non certo riservatezza.
La selezione degli obiettivi in base al tipo di protezione richiesto dai beni, permette un approccio concreto e scalabile in base alle priorità e alle risorse disponibili. In assenza di una mappa di ciò che è urgente e importante da proteggere, si tende a improvvisare o a voler proteggere tutto, salvo poi mancare anche gli obiettivi minimi quando il costo preventivato supera di gran lunga le disponibilità. Minacce
Una minaccia è un’azione potenziale, accidentale o deliberata, che può portare alla violazione di uno o più obiettivi di sicurezza. Le minacce possono essere classificate secondo la loro origine: naturale, ambientale o umana. Per esempio, un allagamento dovuto a forti piogge è una minaccia accidentale di origine naturale che ha un impatto sulla sicurezza, visto che può interrompere la disponibilità dei servizi informatici. Un cavallo di Troia installato all’apertura di un allegato di posta elettronica infetto, è una mi-

Esempi di minacce

naccia deliberata di origine umana e coinvolge tutti gli obiettivi di sicurezza: il computer può cadere sotto il controllo esterno e non essere più completamente disponibile per il suo proprietario (disponibilità), le sue informazioni possono essere alterate e cancellate (integrità) e dati da non divulgare (password, informazioni personali, informazioni sensibili aziendali) possono essere letti da estranei (riservatezza). Una rete wireless che opera senza protezione (a partire dalla cifratura delle comunicazioni) può essere intercettata o, perlomeno, usata per l’accesso a Internet, magari per operazioni illegali riconducibili all’indirizzo IP (e quindi alla responsabilità) del titolare della rete. In questo caso gli obiettivi violati coinvolgono la riservatezza, la disponibilità e potenzialmente anche l’integrità.
L’entità che mette in atto la minaccia viene chiamata agente. Esempi di agenti di minaccia sono un intruso che entra in rete attraverso una porta del firewall, un processo che accede ai dati violando le regole di sicurezza, un tornado che spazza via il centro di calcolo o un utente che inavvertitamente permette ad altri di vedere le password. Vulnerabilità
Mentre una minaccia è sempre portata da un agente esterno (fenomeno naturale o intervento umano), una vul-
Esempi di vulnerabilità

( D = deliberata,

= accidentale,

= ambientale)

Infrastruttura
Mancanza di protezione fisica

Minaccia D A E
----------------------------------------------------------------------------------------------------------------------
Terremoto x
Inondazione x x
Uragano x
Fulmine x
Bombardamento x x
Incendio x x
Uso di armi x x
Vandalismo x
Furto x
Blackout x
Linea elettrica instabile x x
Guasto climatizzatore x
Temperatura alta o bassa x x x
Umidità eccessiva x x x Polvere x
Radiazioni elettromagnetiche x Guasto hardware x
Uso improprio delle risorse x x Errori software x x
Uso non autorizzato supporti
di memoria x
Deterioramento supporti di memoria x Errori degli utenti x x
Errori del personale operativo x x Errori di manutenzione x x
Accesso illegale alla rete x
Uso illegale di password x
Uso illegale del software x Indirizzamento illecito messaggi x Software dannoso x x Installazione/copia illegale
di software x
Interruzione ser vizio
provider Internet x
Interruzione ser vizio hosting web x
Errori di trasmissione x
Traffico eccessivo x x Intercettazione in rete x
Infiltrazione in rete x
Analisi illecita del traffico x
Carenze di personale x

Mancanza di controllo degli accessi Linea elettrica instabile
Locali soggetti ad allagamento

Hardware e impianti
Mancanza di sistemi di backup Suscettibilità a variazioni di tensione Suscettibilità a variazioni di temperatura Suscettibilità a radiazioni elettromagnetiche Programma di manutenzione insufficiente
Comunicazioni
Linee di comunicazione non protette Uso di password in chiaro
Traffico wireless non cifrato Presenza di linee dial-up
Libero accesso ai dispositivi di rete

Documentazione
Locali non protetti
Carenza di precauzioni nell’eliminazione Assenza di controllo nella duplicazione
Software
Complessità inter faccia applicazioni Mancanza autenticazione utente Mancanza logging accessi
Errori software noti Password non protette Cattiva gestione password Diritti di accesso scorretti
Uso del software incontrollato
Sessioni aperte senza presenza utente Assenza di backup
Carenza nella dismissione dei supporti

Personale
Personale insufficiente
Procedure reclutamento inadeguate Personale esterno incontrollato Addestramento di sicurezza inadeguato
Uso improprio o scorretto hardware/software Carenza di monitoraggio

Lezione 1 IT Administrator Sicurezza informatica

nerabilità è un punto debole del sistema informatico (hardware, software e procedure) che, se colpito o sfruttato da una minaccia, porta alla violazione di qualche obiettivo di sicurezza. Una vulnerabilità presenta due caratteristiche: è un aspetto intrinseco del sistema informatico ed esiste indipendentemente da fattori esterni. Una vulnerabilità, di per sé, non causa automaticamente una perdita di sicurezza; è la combinazione tra vulnerabilità e minaccia che determina la probabilità che vengano violati gli obiettivi di sicurezza. Un centro di calcolo situato nel seminterrato di un centro urbano ha le stesse vulnerabilità in una zona poco soggetta a terremoti come in una zona sismica. Quello che cambia è la probabilità che si attui la minaccia terremoto, a scapito della disponibilità dell’impianto.
Un computer dedicato alla contabilità di un negozio, non protetto da firewall e antivirus e privo delle patch di sicurezza del sistema operativo, è assai vulnerabile, ma se è tenuto al sicuro, viene usato solo dal titolare e non è collegato a Internet, può funzionare a lungo senza essere colpito dalle minacce più comuni.
Impatto
L’impatto è la conseguenza dell’attuazione di una minaccia. Esso dipende dal valore del bene colpito e dagli obiettivi di sicurezza violati. Per una piccola azienda, se la minaccia “guasto dell’hard disk” colpisce la vulnerabilità “backup poco frequenti”, l’impatto è serio, perché può includere il blocco temporaneo dell’attività e inconvenienti nei rapporti con i clienti. Gli obiettivi di sicurezza violati sono la disponibilità ed eventualmente l’integrità delle informazioni. Se un dirigente in viaggio connette il portatile a Internet senza protezione (programmi firewall e antivirus), apre un’e-mail infetta e di ritorno propaga l’infezione alla rete aziendale, l’impatto può essere grave e coinvolgere tutti gli obiettivi di sicurezza (disponibilità, integrità e riservatezza). In questo esempio l’agente della minaccia è l’utente, le vulnerabilità sono la cattiva configurazione del portatile e le falle di sicurezza di Windows e la minaccia sta nelle cattive abitudini e incompetenza dell’utente. L’impatto può includere il blocco temporaneo della rete e dei computer e un’attività generalizzata di disinfestazione con possibile perdita di dati e reinstallazione di software; anche parte dei backup potrebbe essere compromessa.
Rischio
Concettualmente, il rischio è la possibilità che si verifichi un evento dannoso ed è tanto maggiore quanto è forte l’impatto causato dall’evento e quanto è alta la probabilità che esso si verifichi. In una zona statisticamente non soggetta ad alluvioni, il rischio informatico connesso a questo tipo di eventi è trascurabile, anche se l’impatto potenziale è ingente. In una rete aziendale soggetta a tentativi di intrusione, a parità di protezione, la sottorete delle finanze corre un rischio maggiore rispetto alla sottorete amminstrativa, perché a parità di probabilità di attacco, l’impatto dell’attacco è più grave.
In termini numerici, il rischio R può essere definito come il prodotto scalare tra la gravità G dell’impatto (conseguenze di un evento dannoso) e la probabilità P che si verifichi l’evento dannoso (la minaccia).
Le fasi della gestione del rischio

Nella gestione del rischio si possono individuare due fasi distinte.
1) Analisi del rischio. In questa fase si classificano le informazioni e le risorse soggette a minacce e vulnerabilità e si identifica il livello di rischio associato a ogni minaccia. Ci sono vari metodi per quantificare il rischio, basati su un approccio quantitativo, qualitativo o combinazione dei due. L’approccio quantitativo è basato su dati empirici e statistiche, mentre quello qualitativo si affida a valutazioni intuitive. Entrambi hanno vantaggi e svantaggi. Il primo richiede calcoli più complessi ma può basarsi su

sistemi di misura indipendenti e oggettivi, fornisce risultati numerici (il valore delle perdite potenziali) e un’analisi dei costi e benefici. Il secondo utilizza l’opinione del personale che ha esperienza diretta in ciascuna delle aree interessate.
2) Controllo del rischio. In questa fase vengono individuate le modalità che l’azienda intende adottare per ridurre i rischi associati alla perdita della disponibilità di informazioni e risorse informatiche e della integrità e riservatezza di dati e informazioni. Ogni tipo di minaccia deve essere trattata separatamente e la pianificazione delle contromisure richiede un’analisi di costi e benefici che ottimizzi il valore della protezione. Se, per esempio, il rischio per l’intrusione in un server web è stimato di 12.000 euro in un anno e con una spesa annua di
1.000 euro esso scende a 3.000 euro, possiamo calcolare il valore della protezione in 12.000 (rischio iniziale) –
3.000 (rischio dopo l’allestimento delle contromisure) –
1.000 (costo annuale delle contromisure) = 8.000 euro.
Analisi del rischio
L’analisi del rischio è un processo composto di una sequenza di fasi, che inizia con la classificazione dei beni (informazioni e risorse informatiche), prosegue con l’identificazione delle minacce e delle vulnerabilità e si conclude con l’identificazione del livello di rischio.
1) Classificazione delle informazioni e delle risorse informatiche. Questa fase ha lo scopo di censire e classificare le informazioni gestite dal sistema informativo aziendale (attraverso sistemi informatici e altri mezzi) e le risorse informatiche utilizzate. Il risultato è la documentazione delle informazioni che hanno valore per l’azienda, in modo che nelle fasi successive si possa valutare il rischio a fronte della perdita di disponibilità, integrità e riservatezza di ogni categoria di informazioni. Visto che le informazioni sono aggregazioni di dati che, singolarmente, potrebbero essere (o apparire) privi di valore, si dovrà tenere conto delle relazioni tra dati e informazioni.
La sicurezza delle informazioni è strettamente legata alla disponibilità delle risorse informatiche, quindi, in questa fase, vengono documentati anche i sistemi, le attrezzature di rete, la capacità di elaborazione, la capacità dei canali di comunicazione, i processi vitali e altre risorse necessarie per gli obiettivi di sicurezza delle informazioni.
2) Identificazione delle minacce. Una minaccia è un’azione potenziale, accidentale o deliberata, che può portare alla violazione di uno o più obiettivi di sicurezza e quindi causare un danno all’azienda. In questa fase si compila l’elenco delle minacce, avendo cura di includere gli eventi di origine naturale, gli eventi accidentali (guasti hardware, errori software, errori umani ecc.) e le azioni umane deliberate (sia interne, sia esterne). Le minacce a cui è soggetta un’organizzazione hanno aspetti generali e aspetti specifici riguardanti il campo di attività, il modello di business, le caratteristiche del sistema informativo e del sistema informatico, la dislocazione e le comunicazioni dell’organizzazione. Esempi di minacce generali sono quelle ambientali che possono impedire il funzionamento delle attrezzature informatiche (alimentazione elettrica, temperatura ecc.), i guasti hardware (hard disk, supporti di backup, alimentatori, ventole ecc.), gli errori software, la cancellazione accidentale di dati, gli errori degli utenti, i virus e altro malware (worm, trojan, spyware, ecc.), i tentativi di intrusione da Internet, l’esecuzione di software insicuro, la sottrazione e/o la divulgazione di informazioni e software e via dicendo.
Minacce più specifiche sopratutto per le aziende che eseguono transazioni economiche on line (banche, siti di ecommerce, broker ecc.) sono ad esempio le azioni di social engineering (fingersi altre persone, come pubblici ufficiali o addetti all’assistenza) per procurarsi password e altre informazioni utili per avere accesso alle informazioni.

Identificazione delle vulnerabilità. Le vulnerabilità sono tutti quei punti deboli del sistema informativo tali che, se sfruttate dall’attuarsi di una minaccia, permettono la violazione degli obiettivi di disponibilità, integrità e riservatezza delle informazioni. In precedenza abbiamo mostrato esempi di vulnerabilità in diverse categorie. Per esempio, l’assenza di un gruppo di continuità e l’intolleranza di alte temperature ambiente rientrano nella categoria impianti. La categoria software include le falle di sicurezza e gli errori dei sistemi operativi e delle applicazioni. La categoria hardware comprende computer, periferiche, accessori e dispositivi di rete, tutti soggetti a guasti e malfunzionamenti. L’assenza di regole e di strumenti adeguati per il backup degli archivi fa parte delle vulnerabilità procedurali. Alla categoria del personale competono carenze come l’inadeguata preparazione e istruzione degli utenti, l’utilizzo improprio di Internet e delle risorse informatiche e la scarsa diligenza nel custodire le password e altre informazioni riservate.
Come per le minacce, anche le vulnerabilità sono specifiche per il tipo di azienda, il campo di attività e l’organizzazione interna. Inoltre, la stessa vulnerabilità può avere diversi livelli di importanza secondo le caratteristiche dell’azienda. La vulnerabilità di un particolare servizio di comunicazione del sistema operativo può essere considerata irrilevante per un’azienda manifatturiera tradizionale ma allo stesso tempo grave per un’azienda che progetta strumenti ad alta tecnologia per un mercato competitivo.
Identificazione del livello di rischio. Dopo aver censito i beni da proteggere e quantificato il loro valore, e dopo aver calcolato la probabilità di attuazione delle minacce (in base alle vulnerabilità e agli agenti di attacco individuati), è possibile calcolare il rischio seguendo l’approccio quantitativo. A tale scopo si possono utilizzare fogli elettronici o apposite applicazioni per automatizzare il calcolo del rischio secondo i settori di attività.
In alternativa, l’approccio qualitativo non quantifica i danni e le probabilità, ma esamina le aree di rischio assegnando, in base a intuizione, esperienza e giudizio, valori relativi (per esempio da 1 a 5) alla gravità della minaccia, alla sua probabilità di attuazione e alla perdita potenziale per l’azienda. Anche le contromisure sono valutate con lo stesso criterio, in modo da selezionare quella che il personale interessato ritiene più adatta per fronteggiare la minaccia.
In tabella 1 consideriamo un piccolo esempio di analisi quantitativa, ridotto a poche righe a scopo illustrativo.
In questo esempio sono indicate le previsioni di danno (perdita economica) per un singolo evento (attuazione della minaccia) e la probabilità stimata in base a statistiche di frequenza o dati empirici. Nella realtà, l’attacco a un bene materiale di valore limitato, come un server di rete, può
Tabella 2 Analisi del rischio qualitativa

causare un danno superiore per ordini di grandezza a beni immateriali come l’immagine, la reputazione e il credito dell’azienda. Inoltre, certi tipi di minacce, in assenza di appropriate difese, possono attuarsi ripetutamente in un anno, come le perdite e alterazioni di dati per errori degli utenti e/o del software applicativo. Va detto che un’analisi del rischio puramente quantitativa è pressoché impossibile, vista la difficoltà di assegnare valori precisi ai danni subiti dai beni e alle probabilità di attuazione delle minacce. In ogni caso, l’analisi permette di identificare i beni da proteggere, le fonti di danno e l’entità del rischio; in base a queste informazioni si potrà definire una strategia per proteggere i beni nel modo più efficiente.
Vediamo ora un esempio di analisi qualitativa, basata sul giudizio, l’esperienza e l’intuito delle persone che operano nelle aree soggette a minacce. Ci sono diversi metodi per raccogliere le informazioni per un’analisi qualitativa del rischio. Il metodo Delphi, per esempio, si basa su decisioni di gruppo per assicurare che ogni membro del gruppo di valutazione possa esprimere onestamente il proprio parere sulle minacce e sui rimedi più efficaci. Ogni membro del gruppo scrive le proprie valutazioni in modo anonimo, senza pressioni o influenze da parte degli altri. I risultati vengono compilati e distribuiti ai membri del gruppo, che scrivono i loro commenti, ancora anonimi. Il processo si ripete finché non si forma un consenso su costi, perdite potenziali, e probabilità di attuazione delle minacce, senza discussioni verbali.
Altri metodi qualitativi fanno uso di brainstorming, focus group, sondaggi, questionari, liste di verifica, interviste, incontri individuali e altro ancora.
Nella tabella 2 vediamo un piccolo esempio semplificato di analisi qualitativa applicata alla minaccia di intrusione da Internet.
In questo esempio gli addetti all’analisi del rischio hanno distribuito una descrizione della minaccia (intrusione da Internet) a cinque persone con diverse mansioni nell’area IT, con la richiesta di valutare, da 1 a 5, la gravità della minaccia, la probabilità che accada, la perdita conseguente e l’efficacia di alcune possibili misure di protezione. La valutazione è quindi sottoposta al management, che vedrà qual è il punto di vista del personale interessato sulla gravità delle minacce e sui modi di proteggersi.
Il controllo del rischio e le contromisure
Consideriamo l’analisi del rischio secondo l’approccio quantitativo; il documento finale elenca in modo dettagliato i beni con i relativi valori monetari, le vulnerabilità, le minacce con relativa probabilità di attuazione e le perdite potenziali (per esempio su base annua). La fase successiva,

Minaccia intrusione da Internet Gravità della minaccia Probabilità di attuazione Perdita potenziale Efficacia firewall Efficacia firewall con IPS Efficacia firewall più IDS

Lezione 1 IT Administrator Sicurezza informatica

controllo del rischio, ha lo scopo di eliminare i rischi, o perlomeno di ridurli entro limiti accettabili. Parte dei rischi può essere ceduta a terzi, per esempio attraverso polizze di assicurazione (per cautelarsi da eventi come furto, incendio e disastri naturali). Anche l’outsourcing, cioè la delega a terzi di servizi che potrebbero essere svolti da personale interno, può essere utile a ridurre vari tipi di rischio, tra cui il mancato ritorno dagli investimenti in addestramento specialistico del personale. Anche la gestione dello storage, ovvero gli archivi e i backup, può essere affidata a terzi appositamente strutturati per garantire alti livelli di sicurezza (disponibilità, integrità e riservatezza delle informazioni). L’hosting dei siti web è un esempio di outsourcing conveniente alle piccole aziende, solitamente prive di impianti e personale per amministrare hardware, software e sicurezza dei siti.
Tolta la cessione a terzi di parte dei rischi, consideriamo la parte di gestione del rischio che avviene all’interno dell’azienda. Il controllo del rischio viene esercitato attraverso opportune contromisure che agiscano sulle due componenti del rischio: la gravità dell’impatto e la probabilità di attuazione della minaccia. Abbiamo visto che le minacce coprono un ampio spettro di fenomeni e attività; ognuna dovrà essere quindi trattata separatamente sia nel valutare l’impatto e la probabilità, sia nel selezionare le contromisure che risultano più efficaci nell’analisi di costo e benefici.
Contromisure
Le contromisure di sicurezza sono le realizzazioni e le azioni volte ad annullare o limitare le vulnerabilità e a contrastare le minacce. Una parte delle contromisure viene solitamente realizzata nel corso della progettazione di un sistema o di un prodotto. Le altre contromisure vengono adottate in fase di utilizzo del sistema o prodotto.
La scelta delle contromisure da mettere in campo è dettata dall’analisi del rischio e dall’analisi costo/benefici delle contromisure. Considerato un bene, il suo valore e il danno potenziale in base alle vulnerabilità e alle probabilità di attuazione di una minaccia, l’effetto di una contromisura si misura con la riduzione del rischio. Se la riduzione del rischio è ampiamente superiore al costo della contromisura, questa è efficace. Se un certo rischio è di scarsa entità e la contromisura risulterebbe più costosa rispetto ai benefici, si può decidere di accettare il rischio senza alcuna contromisura. Lo stesso dicasi nei casi in cui il rischio residuo (il rischio che rimane dopo l’adozione delle contromisure) non fosse significativamente inferiore al rischio iniziale. In pratica, la scelta e adozione delle contromisure è dettata sia dagli obiettivi di sicurezza (e relative priorità di urgenza e importanza) sia dal buon senso economico.
Si possono classificare le contromisure in tre categorie a seconda che siano di carattere fisico, di tipo procedurale o di tipo tecnico informatico.
Contromisure di carattere fisico. Queste contromisure sono generalmente legate alla prevenzione e al controllo dell’accesso a installazioni, locali, attrezzature, mezzi di comunicazione. Un esempio è un centro di calcolo realizzato in un edificio protetto e accessibile solo dopo il riconoscimento del personale autorizzato. Una server farm per ospitare migliaia di siti web è probabilmente dotata di varie contromisure di tipo fisico: la collocazione in zona elevata non soggetta ad alluvioni, pompe e rilevatori per evacuare l’acqua, sistemi antincendio, accessi blindati e sorvegliati e via dicendo. Dato che sistemi e installazioni comunicano in rete, anche le linee di comunicazione possono avere bisogno di protezione fisica contro intercettazioni, disturbi e danneggiamenti. Tra le contromisure fisiche ci sono le canalizzazioni dei cavi di rete, magari interrate o sotto traccia per ostacolare l’accesso e le schermature di vetri e pareti per contenere il campo delle reti wireless.
Contromisure di tipo procedurale. Queste contromisure definiscono passo per passo le operazioni per eseguire un

certo compito oppure regolano il comportamento degli utenti per gli aspetti che riguardano la sicurezza delle informazioni e delle risorse.
Mentre le contromisure fisiche proteggono l’accesso fisico alle risorse e le contromisure informatiche agiscono a livello hardware, firmware e software, le procedure operative e le regole di comportamento si applicano alle persone (utenti e amministratori). Lo scopo, da un lato, è quello di evitare che gli utenti causino vulnerabilità e minacce e, dall’altro, che contribuiscano a mantenere alte le difese riducendo i rischi residui lasciati dalle altre contromisure.
Esempi di contromisure di tipo procedurale sono il controllo dell’identità dei visitatori e la limitazione delle aree a cui hanno accesso. Quando si usa un badge o altra scheda di riconoscimento, anche la sua custodia è oggetto delle procedure, così che non venga lasciato sulla scrivania o in un cassetto aperto o comunque a disposizione di altri.
Le password sono uno strumento di protezione informatico, ma le regole per la loro assegnazione, durata, utilizzo e custodia fanno parte delle contromisure procedurali per ridurre il rischio che cadano in cattive mani. Alcune norme comuni sono: utilizzare password non brevi, contenenti non solo lettere; raccomandare o imporre modifiche periodiche delle password; bloccare l’accesso dopo un numero limitato di tentativi errati; sensibilizzare e responsabilizzare gli utenti sugli effetti della mancata riservatezza (tenere la password su un post-it sotto la tastiera, in un cassetto ecc. o comunicare la propria password a un collega o a un sedicente tecnico di assistenza).
Come per le password, ci sono altre contromisure informatiche che sono efficaci solo se si rispettano certe norme d’uso o procedure organizzative. Un antivirus, per esempio, è efficace se è aggiornato di frequente, come minimo una volta al giorno. Una vulnerabilità degli antivirus è infatti quella di non proteggere dai virus di recente introduzione; il rimedio è installare un sistema centralizzato e una procedura che assicuri l’aggiornamento almeno quotidiano del file di riconoscimento dei virus e un aggiornamento periodico del software antivirus. Per un piccolo ufficio, lo stesso risultato può essere ottenuto installando un antivirus che scarichi automaticamente gli aggiornamenti tutti i giorni e che esegua una scansione giornaliera dei file.
In generale, le contromisure di tipo procedurale dovrebbero essere ridotte al minimo, sostituendole quando possibile con sistemi automatizzati, meno soggetti agli errori, dimenticanze e violazioni degli utenti. È il caso, per esempio, dei dispostivi di riconoscimento biometrici usati al posto dei badge o delle password. Anche l’aggiornamento periodico del firmware dei firewall, anziché essere oggetto di norme procedurali, può essere automatizzato utilizzando firewall che si aggiornano automaticamente collegandosi al sito del produttore. In questo modo, sia le funzionalità sia le protezioni sono tenute aggiornate evitando il costo degli interventi manuali, l’interruzione del servizio, il rischio di errori manuali e il rischio di una minore protezione a causa dell’invecchiamento del firmware.
Altri esempi riguardano le norme d’uso di hardware e software, dove una documentazione inadeguata e un addestramento sommario possono favorire errori o il mancato utilizzo di certe funzioni, aumentando i rischi per la sicurezza.
Nel campo dei backup, non tutte le aziende hanno procedure automatiche che garantiscano il ripristino dopo un disastro (disaster recovery) o la continuità operativa (business continuity) a dispetto di qualsiasi evento catastrofico. Vista l’entità dell’impatto e la frequenza di guasti ai supporti magnetici, è vitale avere una strategia di backup e mettere in atto procedure che garantiscano l’esecuzione dei back a più livelli (con diverse periodicità) e la verifica dell’integrità e utilizzabilità dei supporti di backup. Parte di queste operazioni può essere automatizzata, specialmente nelle aziende medio-grandi; la verifica dei supporti di

IT Administrator Sicurezza informatica Lezione 1

backup è invece spesso un punto trascurato. Nei piccoli uffici, i più soggetti a improvvisazione e omissioni in tema di backup, la difficoltà di imporre l’osservanza di procedure è aggirabile tramite applicazioni software commerciali che, in modo automatico e pianificato, salvano le immagini delle partizioni degli hard disk, senza interrompere il lavoro sui computer. In questo modo, si può utilizzare una contromisura tecnico informatica al posto di quella che, normalmente, è una contromisura procedurale.
Lo smaltimento dei supporti su cui risiedono informazioni è un altro esempio dell’opportunità di contromisure procedurali per evitare che informazioni riservate siano rese pubbliche. Le contromisure possono includere la distruzione dei documenti cartacei da gettare nella spazzatura, la cancellazione dei supporti magnetici da smaltire o da sostituire in garanzia, lo spostamento degli archivi o l’estrazione degli hard disk prima di mandare un computer in manutenzione (salvo l’uso di personale interno con qualifica di sicurezza) e la distruzione dei supporti ottici da smaltire.
Contromisure di tipo tecnico informatico. Queste sono le contromisure realizzate attraverso mezzi hardware, firmware e software e prendono anche il nome di funzioni di sicurezza. In base al loro campo d’azione, possono essere classificate nelle categorie che seguono.
Identificazione e autenticazione. Le funzioni di questa categoria servono a identificare un individuo o un processo e ad autenticarne l’identità. L’esempio più comune è la funzione di accesso (login) a un sistema tramite nome utente (per l’identificazione) e password (per l’autenticazione dell’identità). L’autenticazione viene usata anche nelle comunicazioni tra processi e nei protocolli di comunicazione per accertare l’identità del processo o dell’utente associato al processo.
Controllo degli accessi. In questa categoria troviamo le funzioni di sicurezza che verificano se il processo o l’utente, di cui è stata autenticata l’identità, ha il diritto di accedere alla risorsa richiesta (per esempio file, directory, stampanti) e di eseguire l’operazione specificata (per esempio lettura, esecuzione, modifica, creazione, cancellazione). Per i processi, anche l’accesso alla memoria è regolamentato, in modo che un processo non possa leggere i dati di un altro processo o, in certi casi, non possa eseguire istruzioni contenute in aree destinate esclusivamente a dati. Analoghe funzioni sono svolte a livello hardware dalla CPU nella sua gestione delle pagine di memoria.
Rendicontabilità (accountability). A questa categoria appartengono le funzioni che permettono di attribuire la responsabilità degli eventi agli individui che li hanno causati. L’accountability richiede l’attuazione delle misure d’identificazione e autenticazione degli utenti e l’associazione a ogni processo dell’identità del suo proprietario, come avviene nei moderni sistemi operativi.
Verifica (audit). A questa categoria appartengono le funzioni che registrano gli eventi in un file di logging, con informazioni riguardo a errori e a violazioni di sicurezza. Grazie a queste registrazioni, è possibile risalire a ciò che è accaduto e prendere provvedimenti. Nel caso di segnalazione di malfunzionamenti hardware o di errori software, si possono intraprendere azioni di diagnosi e manutenzione (per esempio la verifica e correzione del file system).
Nel caso di eventi che riguardano la sicurezza, il log permette di scoprire irregolarità, come tentativi di accesso illeciti e tentativi di intrusione. Esempi di funzioni di logging sono quelle di Windows, che registra log degli eventi di sistema, applicativi e di sicurezza oppure il demone syslogd dei sistemi Unix/Linux.
Nel caso dei firewall, il log comprende la registrazione selettiva degli eventi che si desidera tenere sotto controllo: tutti, se non non attiva nessun filtro, oppure solo quelli che superano un certo livello di gravità.
Solitamente i firewall offrono l’opzione di logging remo-

to, che consiste nell’inviare la segnalazione degli eventi a un computer, in modo da poter tenere registrazioni anche voluminose (su lunghi periodi di tempo) e poterle analizzare più facilmente.
Riutilizzo degli oggetti. Questa categoria comprende le funzioni che permettono di riutilizzare oggetti contenenti informazioni riservate: supporti magnetici, supporti ottici riscrivibili, aree di memoria RAM, zone di memoria dei processori (registri, cache, ecc.), buffer di periferiche e simili. Lo scopo è quello di evitare che informazioni riservate siano lasciate a disposizione di programmi e utenti dopo il loro regolare utilizzo. Le contromisure in questa area hanno il compito di cancellare le aree di memoria e di disco subito dopo il loro utilizzo per il transito di informazioni riservate. Un esempio riguarda le aree di memoria dove transitano le password o altre informazioni in chiaro prima della loro cifratura: buffer, registri e aree di lavoro dovrebbero essere cancellate per evitare che siano lette da altri processi autorizzati ad accedere a quelle aree ma associati a utenti non autorizzati alla conoscenza di quelle informazioni. Un altro esempio è offerto dalle aree di scambio su disco, come i file di swapping o paging del sistema operativo. È utile attivare l’opzione di cancellazione automatica di questi file alla chiusura del sistema, in modo che utenti non autorizzati non possano esaminarlo a caccia di informazioni riservate.
Accuratezza. Fanno parte di questa categoria tutte le funzioni intese a garantire l’accuratezza delle informazioni. Per esempio, perché i file di logging forniscano informazioni attendibili, la registrazione temporale (time stamp) dell’evento deve essere precisa. Questo accade se l’orologio interno è sincronizzato periodicamente con un time server di riferimento. Sistemi operativi, switch, firewall e altri dispositivi offrono questa funzionalità, che se necessario va attivata specificando il nome del time server (per esempio time.nist.gov). In campo software, esempi di funzioni a difesa dell’accuratezza delle informazioni sono le funzioni che controllano i limiti di occupazione di buffer e array e quelle che validano la correttezza dei dati immessi dagli utenti.
Affidabilità del servizio. Questa è una vasta categoria di contromisure, perché sono diverse le aree che potrebbero compromettere l’affidabilità dei servizi informatici. Si inizia dalle contromisure per mantenere condizioni di alimentazione elettrica stabile, filtrata e senza interruzione (gruppi di continuità), per passare alle difese dai malfunzionamenti hardware (monitoraggio e manutenzione preventiva) e software (monitoraggio degli errori nei file di logging, aggiornamenti, monitoraggio delle prestazioni, rollback delle transazioni non andate a buon fine, ripristino di uno stato precedente del sistema operativo, ripristino delle partizioni di disco a uno stato integro precedente). Altre contromisure possono essere sviluppate per difendere sistemi e applicazioni dagli errori degli utenti.
Scambio dati sicuro. In questa categoria ci sono le funzioni destinate a garantire la sicurezza delle trasmissioni. Il modello OSI Security Architecture (ISO 7498-2) le classifica nelle seguenti sottoclassi: autenticazione, controllo dell’accesso, riservatezza, integrità (dell’hardware, dei dati e dei flussi di pacchetti trasmessi sia in modo connectionless, come UDP, sia connection-oriented, come TCP, anche ai fini della corretta sequenza dei pacchetti) e non ripudio. Esempi di contromisure in questa area sono l’uso di crittografia a chiave simmetrica e asimmetrica (chiave pubblica più chiave privata) e l’autenticazione tramite Message Authentication Code (il risultato dell’hashing applicato al messaggio più una chiave segreta simmetrica; vengono trasmessi messaggio e MAC; a destinazione il MAC viene ricalcolato sul messaggio più chiave simmetrica e confrontato col MAC ricevuto, così da verificare l’integrità del messaggio e l’autenticazione del mittente).
Funzionalità e garanzia nel controllo del rischio
La sicurezza delle informazioni è caratterizzata da due

Lezione 1 IT Administrator Sicurezza informatica

fattori di base indipendenti: la funzionalità e la garanzia (assurance).
Il termine funzionalità, applicato alla sicurezza, conserva il significato generale che ha in altri settori; è l’insieme di ciò che un prodotto o un sistema informatico fornisce in relazione alla protezione delle informazioni e, di riflesso, delle risorse e dei servizi informatici. Il panorama di contromisure descritto nella sezione precedente (5.1.2.2) comprende gran parte delle funzionalità di sicurezza che potrebbero essere necessarie.
Il concetto di garanzia è stato introdotto da chi si occupa di sicurezza per esprimere il grado in cui l’implementazione di una funzionalità riduce una vulnerabilità o la possibilità di attuazione di una minaccia. Se la funzionalità rappresenta un elemento di protezione, la garanzia ne indica la validità.
Prendiamo ad esempio la funzionalità autenticazione dell’identità. Oggi l’implementazione più comune consiste nell’uso di una password segreta per convalidare il nome dell’utente. Tuttavia, ci sono altre soluzioni, come l’utilizzo di un oggetto fisico (come badge o smart card) o di un dispositivo biometrico (basato ad esempio sul riconoscimento dell’impronta digitale, della cornea, del volto o della voce). Nessuna di queste implementazioni è infallibile e la scelta dipende da vari fattori: il settore di attività, la dimensione aziendale, il livello di rischio, la sensibilità e la competenza degli utenti, le minacce ambientali, i costi sostenibili e via dicendo. Un laboratorio di ricerca in un settore avanzato competitivo potrebbe dotarsi di un sistema di riconoscimento vocale sofisticato da un punto di vista funzionale, ma di scarsa garanzia se le parole da pronunciare sono prevedibili (e quindi preventivamente registrabili).
Altrettanto scarsa garanzia offrirebbe un sistema di riconoscimento dell’impronta digitale dove un guardiano prevenisse frodi ma la precisione del riconoscimento fosse insoddisfacente.
Vediamo quindi che la garanzia è costituita a sua volta da due aspetti distinti: la correttezza e l’efficacia. La correttezza è un attributo intrinseco di un prodotto (o componente o procedura), che riflette il grado di corrispondenza tra le effettive funzioni svolte dal prodotto e le sue specifiche. Per esempio, un prodotto capace di riconoscere il 99% delle voci umane adulte con almeno 30 dB di rapporto segnale/rumore, riceverebbe un’alta valutazione di correttezza rispetto alla funzione “riconoscere la voce degli utenti”.
La correttezza è una proprietà intrinseca del prodotto nell’ambito delle condizioni d’uso previste; non dipende da fattori esterni, come l’opportunità di utilizzare o meno quel prodotto per soddisfare una particolare esigenza.
L’efficacia è invece una proprietà che mette in relazione la contromisura (prodotto, procedura o altro) con il contesto in cui è utilizzata, in particolare le vulnerabilità, la gravità e la probabilità di attuazione delle minacce, le caratteristiche degli agenti che attuano le minacce, l’importanza del bene da proteggere e così via. Supponiamo che per il laboratorio del nostro esempio sia vitale consentire l’accesso solo al personale autorizzato, visto il valore delle informazioni e risorse da proteggere e l’alta probabilità di minacce di intrusione fisica e telematica da parte di agenti (software e individui) ritenuti pericolosi. Il progetto di sicurezza si basa sulla completezza delle funzionalità (le contromisure messe in campo) e sulla garanzia che le contromisure adottate riducano le vulnerabilità e le minacce a livelli accettabili. Supponendo che l’analisi del rischio abbia portato a identificare tutte le funzionalità di sicurezza utilizzabili, tra cui gli strumenti e le procedure per impedire una falsa autenticazione da parte di software e personale ostile, nella fase di valutazione della garanzia si dovranno esaminare correttezza ed efficacia delle soluzioni. Per esempio, un sistema di riconoscimento vocale potrebbe ri-

sultare adatto per ambienti con livello medio di rischio, ma essere inadeguato a fronte di un rischio elevato e di una minaccia agguerrita. Potrebbe risultare più efficace un sistema basato su domande a cui solo il legittimo utente possa rispondere o su un dispositivo fisico (tipo smart card) interattivo, da aggiornare ogni giorno per rimanere valido (in modo da perdere validità in caso di furto o manipolazione). Un altro esempio ci viene offerto dalle contromisure di natura fisica per impedire l’accesso alle persone non autorizzate. Le contromisure per il controllo dell’accesso possono limitarsi a una porta blindata o includere sistemi di rilevamento del movimento, telecamere e registratore video, sistemi di allarme con chiamata di numeri telefonici e altri deterrenti per impedire e/o scoraggiare il tentativo di effrazione. In fase di analisi del rischio, supponiamo che sia emersa l’esigenza di installare una porta blindata capace di resistere a una determinata forza di sfondamento, priva di cardini a vista e resistente al fuoco. Queste sono quindi le specifiche rispetto alle quali verrà valutata la correttezza dei prodotti. Ora, anche se abbiamo individuato la migliore delle porte blindate sul mercato, dobbiamo valutare l’aspetto efficacia. Per quanto tempo la porta resisterà alle tecniche di scasso più evolute? Qual è la probabilità che le forze dell’ordine arrivino in tempo per impedire l’accesso alle risorse informatiche, agli archivi e alle informazioni? Se il rischio è rilevante, probabilmente si dovrà identificare un pacchetto di contromisure che, nell’insieme, costituiscano un percorso ad ostacoli capace di resistere al gruppo d’at-
tacco più determinato.
Poiché i beni da proteggere possono essere assai diversi da un caso all’altro, il programma di sicurezza dovrà essere personalizzato per la situazione specifica, in modo che la scelta delle contromisure e relative funzionalità e garanzie siano commisurate all’entità del rischio e ai tipi vulnerabilità e minacce.

Organizzazione della sicurezza
I processi
La sicurezza delle informazioni è il risultato di un insieme di processi ai vari livelli dell’organigramma aziendale. Non bastano strumenti e tecnologie per ottenere la sicurezza. Occorre, in primo luogo, creare un’organizzazione per la sicurezza che assuma la responsabilità di quanto attiene alla sicurezza e coinvolga l’intera struttura aziendale, in modo che tutto il personale contribuisca nel proprio ambito al disegno generale della sicurezza. Infatti, la sicurezza delle informazioni, delle risorse informative (non solo informatiche) e in generale dei beni e del valore dell’azienda dipende non solo dal lavoro del gruppo addetto alla sicurezza ma anche dal comportamento del personale (interno ed esterno) a tutti i livelli dell’organigramma.
Come avviene per il progetto di un edificio, l’organizzazione della sicurezza dovrebbe partire dall’alto, dove gli obiettivi e le politiche di sicurezza sono definiti in termini generali dal top management, per essere poi specificati nei dettagli man mano che si scende attraverso gli strati del modello organizzativo della sicurezza. In cima a questo modello ci sono gli obiettivi di business strategici, che ispirano i processi fondamentali di cui si deve fare carico l’organizzazione di sicurezza: classificazione dei beni e del loro valore, censimento di vulnerabilità e minacce, analisi del rischio, analisi costi/benefici delle contromisure, valutazione del grado di protezione, definizione delle politiche di sicurezza, pianificazione, implementazione e gestione dei progetti di sicurezza, monitoraggio della conformità tra le soluzioni adottate e le politiche di sicurezza e altro ancora. L’approccio dall’alto al basso permette di coinvolgere tutti i livelli aziendali interessati, di assegnare precise responsabilità, di definire politiche coerenti per l’intera strut-

IT Administrator Sicurezza informatica Lezione 1

 

Un esempio di politica di sicurezza per le comunicazioni wireless
1.0 Scopo
Questa policy proibisce l’accesso alla rete della ACME SpA attraverso connessioni wireless insicure, cioè non protette tramite autenticazione dell’utente e cifratura dei dati. Solo i sistemi wireless conformi ai criteri di questa policy o che hanno ricevuto una speciale esenzione dal responsabile della sicurezza sono approvati per la connessione alle reti della ACME SpA.
2.0 Portata
Questa policy copre tutti i dispositivi di comunicazione dati senza fili (per es. personal computer, telefoni cellulari, PDA eccetera) connessi con una delle reti della ACME SpA. Questo comprende qualunque tipo di dispositivo wireless capace di trasmettere dati a pacchetti. I dispositivi e le reti wireless senza alcuna connessione alle reti della ACME SpA non rientrano nell’ambito di questa policy.
3.1 Policy
3.2 Registrazione degli access point e delle schede Tutti gli access point o stazioni di base connessi alla rete aziendale devono essere registrati e approvati dal responsabile della sicurezza. Questi access point sono soggetti a test di intrusione e a periodici audit. Tutte le schede d’inter faccia wireless di rete usate sui desktop e notebook aziendali devono essere registrate presso il responsabile della sicurezza.
3.3 Tecnologie approvate
Ogni accesso wireless alla LAN deve utilizzare prodotti e configurazioni di sicurezza approvati dall’azienda.
3.4 Cifratura e autenticazione via VPN
Tutti i computer con dispositivi LAN wireless devono

utilizzare una Rete Privata Virtuale (VPN) approvata dall’azienda e configurata per ignorare tutto il traffico non autenticato e non cifrato. Per conformità con questa policy, le implementazioni wireless devono mantenere una cifratura hardware di ogni connessione con chiavi di almeno 128 bit. Tutte le implementazioni devono
supportare un indirizzo hardware (MAC address) registrato e rintracciabile. Tutte le implementazioni devono supportare e impiegare una forte autenticazione degli utenti tramite accesso a un ser ver e database esterno come TACACS+, RADIUS o simile.
3.5 Impostazione dell’SSID
L’SSID (Ser vice Set Identifier – un’intestazione aggiuntiva ai pacchetti mandati su una WLAN che funge da password per chi vuole accedere alla rete sarà impostato in modo che non contenga alcuna informazione relativa all’organizzazione, come nome dell’azienda, nome della divisione o identificatore del prodotto.
4.0 Applicazione
Qualunque dipendente sia riconosciuto responsabile di aver violato questa policy può essere soggetto ad azione disciplinare, fino alla cessazione del rapporto di lavoro.
5.0 Definizioni

Termine Definizione
Autenticazione Un metodo per verificare se l’utente
di un sistema wireless è un utente legittimo, indipendentemente dal computer o dal sistema operativo che viene usato.
6.0 Revisioni
10 luglio 2004, aggiunta la sezione 3.4
20 marzo 2004, sezione 3.3 modificata per includere gli indirizzi MAC

tura aziendale, di sensibilizzare ed educare il personale, di finanziare adeguatamente il progetto sicurezza e di rimuovere gli ostacoli che si presenteranno quando verranno adottate procedure e strumenti che avranno un impatto sull’operatività quotidiana e sulle abitudini del personale (a tutti i livelli).
A volte nelle aziende vengono prese iniziative di sicurezza dal basso, con le buone intenzioni di proteggere alcuni obiettivi di sicurezza immediati. Senza la forza di spinta, l’autorità, la responsabilità, il coinvolgimento generale e i mezzi assicurati dal management superiore, i tentativi dal basso si scontrano facilmente con ostacoli insormontabili e sono spesso destinati a fallire. Il migliore interesse dell’azienda esige che la responsabilità della sicurezza si diffonda a cascata dalla cima verso la base della piramide aziendale, con la partecipazione dei vari strati di utenti della sicurezza. In questo modo, anziché turare alcune falle senza un piano preciso, si potrà corazzare l’intera struttura aziendale nel modo più efficiente rispetto al rischio da controllare e al budget disponibile. Una volta definiti gli obiettivi, le politiche, un piano e le soluzioni da adottare, si potrà sensibilizzare e informare tutto il personale sugli aspetti concernenti la sicurezza, rendendo esplicite le responsabilità e le sanzioni per manager, amministratori e utenti.
La struttura organizzativa della sicurezza può assumere varie forme secondo il tipo e le dimensioni dell’azienda, il campo di attività, il rapporto con l’ambiente, il mercato e altri fattori. Può essere informale in una piccola azienda senza particolari problemi di sicurezza oppure essere

complessa con rappresentanti delle diverse aree aziendali in una grande società. Può limitarsi alla sicurezza delle informazioni o estendere la propria sfera all’intera sicurezza aziendale, inclusa la gestione del rischio nei settori operativo, marketing, finanziario ecc.
Un aspetto che modella i processi di sicurezza è il costo in base al rischio e all’attività dell’azienda. A questo proposito, è facile immaginare una scala crescente di rischi e investimenti in sicurezza. Aziende manifatturiere, organizzazioni finanziarie, certification authority (organizzazioni fidate che rilasciano certificati digitali) e forze armate sono esempi di requisiti crescenti di sicurezza.
Uno dei primi compiti del gruppo incaricato della sicurezza è quindi quello di inquadrare l’azienda in base al modello di attività, all’esposizione ai rischi e alla dipendenza dall’infrastruttura informatica e di comunicazioni. Questo esame preliminare dovrà tenere in considerazione il quadro legislativo tracciato dalle leggi sulla criminalità informatica e sulla privacy che si sono succedute numerose nel corso degli anni e che sono culminati con il decreto legge 196 del 2003 (Codice in materia di protezione dei dati personali). Le norme di legge pongono dei vincoli, secondo il tipo di attività, che devono essere calcolati nel delineare l’organizzazione, le politiche e i progetti di sicurezza.
Di conseguenza, l’organizzazione della sicurezza dovrebbe partire dagli individui, top manager e personale delegato, che per legge sono ritenuti proprietari e custodi delle informazioni e pertanto responsabili delle eventuali violazioni da parte dell’intero personale aziendale e responsabili dei danni verso terzi che ne conseguono. Dopo di

Lezione 1 IT Administrator Sicurezza informatica

che, la partecipazione dovrebbe allargarsi a tutti i livelli. Il management di livello superiore ha la visione globale dell’azienda e degli obiettivi di business. I manager intermedi sanno come funzionano i propri dipartimenti, conoscono il ruolo degli individui e possono valutare l’impatto diretto della sicurezza nelle loro aree. I manager di livello inferiore e lo staff sono a contatto con l’effettiva operatività dell’azienda e conoscono in dettaglio le esigenze tecniche e procedurali, i sistemi e il loro utilizzo; utilizzano i meccanismi di sicurezza nel lavoro quotidiano e sanno come essi si integrano nei sistemi e nei flussi di lavoro e come influiscono sulla produttività.
Il ruolo delle politiche di sicurezza
Di solito, le informazioni e le risorse informatiche hanno una relazione diretta con gli obiettivi e con l’esistenza stessa di un’azienda. Il management di livello superiore dovrebbe perciò considerare prioritaria la loro protezione, definendo gli obiettivi della sicurezza, fornendo il supporto e le risorse necessari e avviando il programma di sicurezza aziendale. Il management deve definire la sfera d’azione della sicurezza, che cosa deve essere protetto e in che misura, tenendo conto delle leggi vigenti e dei risultati dell’analisi del rischio. Quindi deve precisare ciò che ci si aspetta dal personale e le conseguenze delle violazioni. Un programma di sicurezza dovrebbe contenere tutti gli elementi necessari a fornire all’azienda una protezione completa secondo una strategia a lungo termine. Questi elementi comprendono tra l’altro le politiche di sicurezza, le procedure, gli standard, le linee guida, i criteri minimi di sicurezza, le azioni di sensibilizzazione e addestramento, le modalità di reazione agli incidenti e un programma per il controllo della sicurezza.
La definizione delle politiche di sicurezza a livello aziendale è il primo risultato dell’organizzazione di sicurezza. Una politica di sicurezza è un documento sintetico in cui il management superiore, o un comitato delegato allo scopo, delinea il ruolo della sicurezza nell’organizzazione o in un suo aspetto particolare.
Generalmente sono necessarie diverse politiche di sicurezza a più livelli, da quello superiore riguardante l’intera azienda, scendendo ad argomenti più specifici, come il sistema informatico e i singoli aspetti tecnici. Il linguaggio, il livello di dettaglio e il formalismo dei documenti di sicurezza dovranno essere realistici per avere efficacia. Un’organizzazione altamente strutturata sarà più portata a seguire politiche e linee guida dettagliate, mentre un’azienda meno strutturata richiederà maggiori spiegazioni e una particolare enfasi per ottenere l’applicazione delle misure di sicurezza.
La terminologia usata per individuare i livelli principali delle politiche di sicurezza può variare. In una grande organizzazione si può parlare di organizational security policy, issue-specific policies e system-specific policies per indicare le politiche di sicurezza aziendale, le politiche per l’implementazione di funzioni di sicurezza specifiche e quelle riguardanti direttamente i computer, le reti, il software e i dati.
Un’altra suddivisione, applicabile anche su scala mediopiccola, individua tre livelli: la politica di sicurezza aziendale (corporate security policy), la politica di sicurezza per il sistema informativo (system security policy) e la politica di sicurezza tecnica (technical security policy).
La politica di sicurezza aziendale indica tutto ciò che deve essere protetto (beni materiali e immateriali) in funzione del tipo di attività dell’azienda, del modello di business, dei vincoli esterni (mercato, competizione, leggi vigenti) e dei fattori di rischio. Questo documento definisce gli obiettivi del programma di sicurezza, assegna le responsabilità per la protezione dei beni e l’implementazione delle misure e attività di sicurezza e delinea come il programma deve essere eseguito. La politica di sicurezza

aziendale fornisce la portata e la direzione di tutte le future attività di sicurezza all’interno dell’organizzazione, incluso il livello di rischio che il management è disposto ad accettare.
La politica di sicurezza del sistema informatico definisce, coerentemente con la politica di sicurezza aziendale, in che modo l’azienda intende proteggere le informazioni e le risorse informatiche, senza entrare nel merito delle tecnologie che verranno adottate. In questa fase vengono presi in considerazione requisiti di sicurezza di tipo fisico e procedurale, mentre gli aspetti tecnici sono demandati al livello inferiore.
La politica di sicurezza tecnica traduce in requisiti tecnici funzionali gli obiettivi che si desidera raggiungere attraverso le contromisure di tipo tecnico informatico, nel contesto dell’architettura di sistema adottata o pianificata dall’azienda.
In un’azienda di piccole dimensioni potranno essere sufficienti singole politiche di sicurezza per ciascuno dei due livelli inferiori, ma in presenza di più sistemi, dipartimenti e divisioni, è probabile che le politiche di sicurezza si suddividano per area e per argomento. (Esempi di politiche di sicurezza sono forniti dal SANS Institute alla pagina http://www.sans.org/resources/policies/).
Disaster Recovery e Business Continuity
La Disaster Recovery, nel contesto informatico, è la capacità di un’infrastruttura di riprendere le operazioni dopo un disastro. La maggior parte dei grandi sistemi di calcolo include programmi di disaster recovery, inoltre esistono applicazioni di disaster recovery autonome che, periodicamente, registrano lo stato corrente del sistema e delle applicazioni, in modo da poter ripristinare le operazioni in un tempo minimo. Il termine disaster recovery può essere usato sia dal punto di vista della prevenzione contro la perdita di dati sia delle azioni per rimediare a un disastro.
Due caratteristiche per valutare l’efficacia di un sistema di disaster recovery sono il Recovery Point Objective (RPO, il momento nel tempo a cui il sistema è riportato) e il Recovery Time Objective (RTO, il lasso di tempo che intercorre prima di ripristinare l’infrastruttura). Per ridurre la distanza dell’RPO rispetto al presente occorre incrementare il sincronismo della data replication, ovvero la replica di archivi e database su un altro sistema, generalmente remoto per motivi di sicurezza. Per ridurre l’RTO, ossia il tempo di ripristino, occorre che i dati siano tenuti on line su un sistema di riserva pronto a subentrare in caso di avaria al sistema principale.
La business continuity (talvolta chiamata business continuance) descrive i processi e le procedure che un’organizzazione mette in atto per assicurare che le funzioni essenziali rimangano operative durante e dopo un disastro. Il Business Continuity Planning cerca di prevenire l’interruzione dei servizi critici e di ripristinare la piena operatività nel modo più rapido e indolore possibile.
Il primo passo nel pianificare la business continuity è decidere quali delle funzioni aziendali sono essenziali e destinare di conseguenza il budget disponibile. Una volta che siano identificati i componenti principali, si possono installare i meccanismi di failover (sistemi di riserva che subentrano in caso di avaria). Tecnologie appropriate, come la replica dei database o il mirroring dei dischi su Internet, permettono a un’organizzazione di mantenere copie aggiornate dei dati in ubicazioni remote, in modo che l’accesso ai dati sia garantito anche quando un’installazione cessa di funzionare.
Un piano di business continuity dovrebbe includere: un piano di disaster recovery che specifichi le strategie per le procedure in caso di disastro; un piano di business resumption che specifichi i mezzi per mantenere i servizi essenziali presso il luogo di crisi; un piano di business recovery che specifichi i mezzi per ripristinare le funzioni azien-

IT Administrator Sicurezza informatica Lezione 1

dali in una località alternativa e un contingency plan che specifichi il modo di reagire a eventi esterni che causino un serio impatto sull’organizzazione.
Nel mondo degli affari, il disaster recovery planning si sta evolvendo verso il business continuity planning da parecchi anni e i recenti eventi terroristici hanno accelerato questa tendenza. Già nel 1995 il Disaster Recovery Institute International ha rimpiazzato la designazione di Certified Disaster Recovery Planner (CDRP) con quella di Certified Business Continuity Planner (CBCP).
La differenza tra disaster recovery e business continuity è che un piano di disaster recovery è reattivo e si focalizza di solito sul ripristino dell’infrastruttura informatica. Sebbene sia logico irrobustire l’infrastruttura informatica per prevenire un disastro, lo scopo principale del piano di disaster recovery è rimediare ai danni all’infrastruttura. Al contrario, un piano di business continuity non soltanto è proattivo, ma ha anche l’obiettivo di mantenere in funzione le attività dell’azienda durante qualsiasi evento, non limitandosi a ripristinare i computer dopo il fatto.
Come parte del processo di pianificazione della business continuity, un’azienda dovrebbe riesaminare la continuità o il ripristino di produzione, imballaggio, stoccaggio, spedizione, supporto clienti e qualsiasi altra struttura o funzione critica per la sopravvivenza dell’azienda. Un fattore chiave per un piano di continuità funzionale è il coinvolgimento degli utenti, in modo da non trascurare procedure, attrezzature, documentazione e altre necessità necessarie per ripristinare i processi di business, non soltanto l’hardware e il software.
Un piccolo esempio della differenza tra ripristino dopo un disastro e continuità operativa viene offerto dall’uso personale del computer. L’utente che si organizza per un rudimentale disaster recovery, tiene backup periodici dei dati e dei file importanti e tiene sotto mano il software originale; se il sistema si blocca o l’hard disk si guasta, reinstalla il sistema operativo e le applicazioni, applica di nuovo tutte le personalizzazioni (Windows, e-mail, Internet, applicazioni eccetera) e ripristina i dati dal backup, perdendo solo le aggiunte e le modifiche successive all’ultimo backup.
L’utente orientato alla business continuity si attrezza con almeno due hard disk e un software di backup automatico delle immagini delle partizioni di disco; quindi pianifica copie complete settimanali e copie incrementali giornaliere.
Se si è dotato di un hard disk di backup ben dimensionato, può anche conservare più immagini delle partizioni per scegliere quale ripristinare secondo le circostanze (per esempio una più affidabile o una più aggiornata). Anche se si guasta il disco principale, basta sostituirlo e ripristinare le partizioni dai file immagine per riprendere la normale operatività in poco tempo (può bastare un’ora), senza reinstallare nulla.
In sintesi, l’obiettivo generale delle attività di sicurezza è mantenere la continuità del business aziendale e, in particolare, del lavoro del personale e del servizio ai clienti. Hardware, software, sistemi, reti, informazioni, attrezzature e personale sono elementi da proteggere, ma vanno inquadrati nel piano di sicurezza generale con l’obiettivo di assicurare la continuità operativa.
Strati di responsabilità
Ogni membro del personale di un’azienda, dalla cima al fondo dell’organigramma, ha una parte di responsabilità per le condizioni operative dell’azienda e, in particolare, per il mantenimento e il miglioramento della sicurezza.
Il management superiore ha la responsabilità di tracciare obiettivi e strategie a lungo termine per l’intera azienda; inoltre ha la responsabilità globale per la sicurezza dell’azienda e per la protezione dei beni. In base alle leggi vigenti, ai beni da proteggere, ai rischi da controllare e agli al-

tri fattori, spetta al management superiore dar vita a un’organizzazione di sicurezza, assegnare gli obiettivi di sicurezza, fornire i mezzi per raggiungerli e far sì che l’intero personale partecipi agli obiettivi e osservi le politiche, le linee guida, le procedure e le direttive in materia di sicurezza.
Il management di livello divisionale e dipartimentale, avendo conoscenza diretta del funzionamento dei propri dipartimenti e delle mansioni del personale, ha la responsabilità di contribuire alla formazione delle politiche di sicurezza, di partecipare ai processi di analisi e di controllo del rischio, all’analisi costi/benefici delle contromisure e al monitoraggio delle attività di sicurezza, delegando parte dei compiti, ma condividendo le responsabilità con il management operativo, gli specialisti di sicurezza, i system administrator, gli auditor e gli utenti.
I manager operativi e lo staff sono a contatto con l’effettiva operatività dell’azienda e conoscono in dettaglio i requisiti tecnici e procedurali, i sistemi e il loro utilizzo. Il loro compito è fornire informazioni utili per pianificare, organizzare e monitorare i programmi di sicurezza e implementare le politiche, le linee guida e le procedure stabilite dal management e dall’organizzazione di sicurezza.
Gli esperti di sicurezza, sia che si tratti di funzionari o di dirigenti interni (come security officer o Chief Information Officer) o di professionisti esterni, hanno la funzione e la responsabilità di realizzare gli obiettivi di sicurezza e di implementare le direttive del management superiore. Gli esperti di sicurezza, grazie alla loro competenza specifica, sono un fattore chiave per dare solide fondamenta all’organizzazione di sicurezza e per metterne in funzione i processi, inclusi i meccanismi di monitoraggio e controllo per mantenere la rotta senza un rilassamento delle policy, delle linee guida, degli standard e delle procedure. Una delle principali responsabilità degli esperti di sicurezza è il coinvolgimento del management, a cui spetta la firma su ogni decisione e direttiva dopo aver recepito requisiti, informazioni e analisi dal gruppo di sicurezza e dal personale (coinvolto tramite questionari, interviste ecc.).
Due ruoli importanti per la sicurezza, che devono essere chiaramente definiti, sono il proprietario dei dati e il custode dei dati.
Il proprietario dei dati è generalmente un membro del management superiore ed è, in definitiva, il massimo responsabile della protezione delle informazioni e della sicurezza in generale. A lui verrà imputata ogni negligenza che abbia come conseguenza la perdita o la divulgazione illecita delle informazioni e i danni conseguenti. Le violazioni vanno dalla inosservanza della legge sulla privacy (per esempio consentendo l’accesso illegale al database tramite Internet) alla copia illecita di dati soggetti a copyright (come software, musica e film scaricati dai dipendenti) alla inadeguata implementazione di procedure di disaster recovery e business continuity (gli azionisti potrebbero denunciare inadempienze che causino grosse perdite all’azienda).
Il custode dei dati ha la responsabilità della manutenzione e della protezione dei dati, un ruolo che di solito è ricoperto dal system administrator o, in una grande azienda, da un ruolo senior a system administrator e network administrator. Tra le funzioni ci sono l’esecuzione di backup periodici (generalmente secondo una strategia a più livelli, con diversi tipi di supporto, diverse periodicità e, nel caso dei database, sistemi di replicazione remota sincroni o asincroni secondo i requisiti). Deve inoltre implementare i meccanismi di sicurezza, validare periodicamente l’integrità dei dati e dei supporti (sia on line sia di backup), ripristinare i dati (e i programmi) dai backup quando necessario e soddisfare i requisiti delle politiche di sicurezza, degli standard e delle linee guida che riguardano la sicurezza delle informazioni e la protezione dei dati. In particolare, un system administrator è responsabile dei singoli computer

Lezione 1 IT Administrator Sicurezza informatica

e dispositivi collegati, mentre un network administrator è responsabile delle connessioni, dell’hardware e del software di networking, oltre che del funzionamento in rete dei computer e delle periferiche. Nelle aziende piccole le due figure si sovrappongono.
Gli utenti sono tutti gli individui che quotidianamente utilizzano i dati per motivi di lavoro. Ogni utente dovrebbe avere i privilegi di accesso necessari per svolgere le proprie mansioni ed è responsabile di applicare le procedure di sicurezza per preservare la disponibilità, l’integrità e la riservatezza delle informazioni.
Una cattiva gestione della sicurezza, non conforme agli strati di responsabilità, causa buona parte dei problemi in tale campo. L’organizzazione della sicurezza dovrebbe prevedere un comitato di alto livello per assicurare che le istanze di sicurezza ricevano la dovuta attenzione da parte del management superiore.
Un CIO (Chief Information Officer) o security officer dovrebbe lavorare con il management superiore per definire le procedure di sicurezza strategiche e supportare i business manager nel definire le loro necessità in tema di informazioni e sicurezza. I business manager (responsabili ad esempio di attività commerciali, di marketing, di rapporti con i clienti, di progetti di espansione) hanno la principale responsabilità nel determinare i requisiti di protezione delle risorse informative, quindi dovrebbero essere coinvolti direttamente nella scelta delle misure di protezione. Spetta ai business manager anche approvare i nuovi account degli utenti, mentre gli amministratori della sicurezza creano gli account, assegnano le password, si occupano del software di sicurezza, testano le patch prima di applicarle ai sistemi.
Le decisioni sui beni da proteggere e sulle contromisure da adottare sono compito del management superiore (assistito dallo staff e dagli organismi predisposti), non dei system administrator e dei professionisti della sicurezza. Un errore molto frequente è gestire la sicurezza a livello di security administrator o system administrator. In tal caso, la sicurezza non è vista nei termini ampi e generali che richiede, non viene eseguita alcuna analisi del rischio, un’attività che richiede le valutazioni del management superiore e quest’ultimo non prende consapevolezza dei rischi a cui l’azienda è esposta. Inoltre, non vengono stanziati i fondi necessari per le attività di sicurezza e non viene svolta opera globale di sensibilizzazione ed educazione del personale.
Il dipartimento del Personale ha responsabilità specifiche in tema di sicurezza. Metà dei problemi di sicurezza sono originati da cause interne alle aziende, sia per carenze nella gestione della sicurezza sia per pratiche di reclutamento inadeguate. Al dipartimento del Personale spetta assumere o ingaggiare personale qualificato, verificare il curriculum di studi e lavoro e le informazioni personali, far firmare un impegno di non divulgazione delle informazioni (e di rispetto del copyright).
Spetta sempre al dipartimento del personale fornire l’addestramento necessario, imporre uno stretto controllo degli accessi, monitorare l’utilizzo dei sistemi e, in caso di violazione, provvedere immediatamente per impedire ulteriori danni e proteggere le informazioni, le risorse e tutte le parti interessate (non dimentichiamo la condanna dell’amministratore delegato per i film pirata scaricati abusivamente dall’impiegato).
CERT, CSIRT e la gestione degli incidenti
Con la diffusione delle connessioni in rete e l’espansione di Internet, dopo i primi attacchi si sentì l’esigenza di costituire organizzazioni per reagire prontamente a eventi che minacciassero la sicurezza dei computer collegati a Internet. Il primo Computer Emergency Response Team (CERT, squadra di intervento per le emergenze informatiche) fu creato negli USA dalla DARPA (Defense Advanced

Research Projects Agency), nel novembre 1988, in risposta al primo grave attacco alla rete, quando un worm mandò in avaria il 10% di Internet.
La missione del CERT è quella di operare con la comunità di Internet per facilitare la risposta agli eventi riguardanti la sicurezza degli host (i computer collegati a Internet), prendere iniziative per sensibilizzare la comunità sugli aspetti della sicurezza e condurre ricerche rivolte a incrementare la sicurezza dei sistemi esistenti.
Il primo CERT (www.cert.org) è diventato il CERT Coordination Center (CERT-CC) ed è situato presso il Software Engineering Institute, finanziato dal governo USA e gestito dalla Carnegie Mellon University di Pittsburg.
Si focalizza sulle violazioni alla sicurezza, allerta sulle nuove minacce, reagisce agli attacchi (i cosiddetti incidents) e fornisce assistenza, informazioni sulla vulnerabilità dei prodotti e istruzione con documenti e tutorial.
Nel 2003 è stato formato lo United States Computer Emergency Readiness Team (US-CERT, www.us-cert.gov), una partnership tra il Department of Homeland Security (nato nel 2002 per fronteggiare gli attacchi terroristici in USA) e il settore privato.
L’US-CERT opera a Washington e a Pittsburg, in stretto coordinamento con il CERT-Coordination Center. Il suo compito è analizzare e ridurre le minacce e vulnerabilità informatiche, disseminare informazioni per allertare sulle nuove minacce e coordinare le attività di risposta agli incidenti.
Vista la dimensione delle reti, il numero di comunità di utenti e la richiesta di supporto per fronteggiare i problemi di sicurezza, il CERT-CC è impegnato ad aiutare la formazione degli CSIRT (Computer Security Incident Response Team), squadre di intervento per gli incidenti di sicurezza informatica, a cui fornisce guida e addestramento. Nella maggior parte delle aziende, i system e network administrator non hanno a disposizione personale, competenze e procedure per fronteggiare prontamente gli attacchi informatici e minimizzare i danni, come dimostra il numero crescente di incidenti di sicurezza.
In questi casi è necessaria una risposta rapida ed efficace; più tempo trascorre per riconoscere, analizzare e rispondere a un incidente, maggiori sono i danni e i costi di ripristino. Le grandi organizzazioni hanno la possibilità di crearsi il proprio CSIRT, come avviene negli USA con l’aiuto del CERT CSIRT Development Team.
In alternativa, si ricorre a gruppi di intervento pubblici, come il CERT-IT (http://security.dico.unimi.it) e il GARRCERT (www.cert.garr.it) entrambi italiani.
I CERT o CSIRT delle varie nazioni sono collegati in una struttura internazionale che permette la rapida condivisione delle informazioni utili a fronteggiare minacce e attacchi. Il FIRST (Forum for Incident Response and Security Teams, www.first.org) è nato nel 1990.
Nel 2003 FIRST contava la partecipazione di 150 organizzazioni per la risposta agli incidenti di sicurezza in ogni parte del mondo. Il CERT-IT, ubicato presso l’Istituto di Scienza dell’Informazione dell’Università degli Studi di Milano, è il primo membro italiano di FIRST, a cui è stato ammesso nel 1995.
La segnalazione degli incidenti al CERT-IT avviene in forma riservata e autenticata tramite PGP (Pretty Good Privacy), un programma di cifratura gratuito usato da milioni di utenti per proteggere la riservatezza della posta elettronica (www.it.pgpi.org). La gestione degli incidenti prevede tre fasi:
1) la segnalazione dell’incidente, via e-mail o via Web, con allegate le informazioni sull’attacco e i file rilevanti (come quelli di log);
2) la registrazione dell’incidente da parte del CERT-IT e l’indagine sull’attacco fino a informare l’utente, se le informazioni fornite sono sufficienti, sui rimedi da adottare;
3) la chiusura della segnalazione.

IT Administrator Sicurezza informatica Lezione 1

Standard ed enti
di standardizzazione
Gli enti di standardizzazione principali e il loro ruolo
Gli enti di standardizzazione sono organizzazioni di natura molto differente, che coprono aspetti normativi diversificati e hanno avuto una genesi diversa a seconda dei casi. Operano in ambito nazionale o internazionale ed emettono norme e linee guida (gli standard) che 1) permettono di realizzare prodotti, processi e servizi secondo lo stato corrente delle tecnologie e 2) forniscono le basi per garantire l’interoperabilità tra prodotti di produttori diversi. Oltre a emettere standard, questi enti svolgono altre attività, come la pubblicazione di documenti interpretativi per facilitare l’applicazione degli standard secondo determinati profili di utilizzo.
Generalmente gli enti di standardizzazione operano sulla base del consenso con un’attività di coordinamento e armonizzazione. A volte il documento che descrive uno standard è il risultato del lavoro di ricerca e sviluppo di un gruppo di aziende e un compito dell’ente di standardizzazione è far sì che le norme raggiungano un vasto campo di applicabilità nel settore industriale interessato. In qualche caso diversi gruppi industriali adottano tecnologie in concorrenza tra loro e l’ente di standardizzazione, se non prevalgono interessi economici o politici particolari, riesce ad armonizzarne le caratteristiche definendo uno standard a cui tutti i partecipanti si uniformano.
Casi di questo genere sono frequenti, per esempio nel campo delle comunicazioni e del networking, quando alla fase di rapida uscita sul mercato segue la ricerca del consenso e della massima interoperabilità. In generale, un ente di standardizzazione permette che le tecnologie con la migliore combinazione di caratteristiche e consenso siano codificate in modo da superare l’ambito locale di origine e siano applicabili uniformemente e in modo interoperabile su scala nazionale e internazionale. Gli organismi di standardizzazione possono essere istituzioni formalmente riconosciute dagli stati nazionali o essere consorzi privati di imprese che operano in un certo settore del mercato. Vediamo ora quali sono gli enti di standardizzazione rilevanti ai fini della sicurezza informatica.

• ITU (International Telecommunication Union, www.itu.int): è un’organizzazione internazionale, nell’ambito dell’ONU, dove governi e settore privato coordinano le reti e i servizi globali di telecomunicazioni. Ha sede a Ginevra e comprende i settori ITU-T (standardizzazione), ITU-R (radiocomunicazioni) e ITU-D (sviluppo). Ai fini della sicurezza delle informazioni, sono di interesse le raccomandazioni ITU-T della serie X.500 (servizi di directory) e, in particolare, la norma X.509 che descrive il formato dei certificati digitali.

• ISO (International Organization for Standardization, www.iso.org): è la maggiore organizzazione internazionale di standardizzazione e comprende gli enti di standardizzazione nazionali di 146 paesi (l’UNI è il membro italiano). L’ISO, il cui nome non è un acronimo ma deriva dalla parola greca isos uguale ha sede a Ginevra e opera a stretto contatto con IEC (International Electrotechnical Commission), ITU, CEN (Comitato Europeo di Normalizzazione) e CESI (Centro Elettrotecnico Sperimentale Italiano). Le norme ITU X.500, in realtà, sono state emesse congiuntamente all’ISO e sono contenute nella serie ISO 9594. ISO/IEC/JTC1 è il comitato che si occupa di standardizzazione nel campo dell'ICT (http://www.jtc1.org). I membri del JTC1 (Joint Technical Committee 1) sono gli enti nazionali di standardizzazione IT. Il JTC 1 è responsabile della gestione di un vasto e complesso programma di lavoro ed è strutturato in sottocomitati e gruppi di lavoro in base alle aree di interesse. Il sottocomitato 27

(ISO/IEC JTC1/SC27) è quello che si occupa di tecniche di sicurezza e vi partecipa, per l’Italia, l’UNINFO.

• IETF (Internet Engineering Task Force, www.ietf.org): è una vasta comunità internazionale di progettisti, operatori, produttori e ricercatori nel campo del networking, interessati all’evoluzione dell’architettura di Internet e all’affidabilità del suo funzionamento. È aperta a tutti gli interessati e il lavoro tecnico effettivo è svolto dai gruppi di lavoro, che sono organizzati per argomento in aree come routing, trasporto, sicurezza e così via. L’IETF emette norme sotto forma di Request For Comment (RFC). Ne fa parte la serie dedicata alle infrastrutture a chiave pubblica, normalmente indicate con la sigla PKIX (Internet X.509 Public Key Infrastructure).

• CEN (Comitato Europeo di Normalizzazione, www.cenorm.org): è un organismo europeo composto dagli enti di standardizzazione dei paesi membri dell’Unione Europea e dell’EFTA (European Fair Trade Association tra cui l’UNI per l’Italia). CEN, CENELEC ed ETSI sono i tre enti europei di standardizzazione a cui è riconosciuta la competenza nell’area della standardizzazione tecnica su base volontaria e che sono elencati nell’Allegato I della Direttiva 98/34/EC riguardante la “procedura informativa” per gli standard e la normativa tecnica. Insieme, essi preparano gli standard europei in settori di attività specifici e costituiscono il “sistema di standardizzazione europeo”. La maggior parte degli standard è preparata su richiesta dell’industria, ma anche la Commissione Europea può farne richiesta. Le direttive UE normalmente contengono principi generali obbligatori, demandando i requisiti tecnici dettagliati agli enti di standardizzazione. Il CENELEC è il Comitato Europeo per la Standardizzazione Elettrotecnica (www.cenelec.org). L’EFTA (European Fair Trade Association, www.eftafairtrade.org) è lo spazio di libero scambio nato nel 1960 tra Austria, Danimarca, Norvegia, Portogallo, Svezia, Svizzera e Gran Bretagna.

• ETSI (European Telecommunications Standards Institute, www.etsi.org): è un’organizzazione europea indipendente, riconosciuta dalla Commissione Europea e dall’EFTA. Ha sede a Sophia Antipolis (Francia) ed è responsabile per la standardizzazione delle tecnologie informatiche e di comunicazioni (ICT) in Europa. Queste tecnologie includono le telecomunicazioni, il broadcasting e le aree collegate come i trasporti intelligenti e l’elettronica medica. L’ETSI raggruppa 688 membri in 55 nazioni (dato di febbraio 2005) dentro e fuori l’Europa, tra cui produttori, gestori di reti, amministratori, service provider, enti di ricerca e utenti. Tra i campi d’interesse, l’ETSI si occupa di algoritmi di sicurezza e di servizi TTP (Trusted Third Party Services); tra i progetti, segnaliamo l’European Electronic Signature Standardization Initiative (www.ict.etsi. org/EESSI_home.htm), che tra il 1999 e il 2004 ha coordinato l’attività di standardizzazione per implementare la direttiva CE sulla firma elettronica.

• UNINFO (www.uninfo.polito.it): è una libera associazione a carattere tecnico, con lo scopo di promuovere e di partecipare allo sviluppo della normativa nel settore delle tecniche informatiche. Rientrano nel suo campo d’attività i sistemi di elaborazione e di trasmissione delle informazioni e le loro applicazioni nelle più diverse aree, quali, ad esempio, le attività bancarie e le carte intelligenti. L’UNINFO è associato all’UNI, l’ente nazionale italiano di unificazione (www.uni.com/it) e rappresenta l’Italia presso CEN e ISO. Le attività dell’UNINFO nell’ambito della sicurezza informatica sono svolte dalla commissione STT (Sicurezza delle Transazioni Telematiche), che si occupa delle norme di sicurezza nelle transazioni telematiche, con particolare riferimento alla firma elettronica.

Lezione 1 IT Administrator Sicurezza informatica

Normative relative alla sicurezza delle informazioni
L’attività normativa relativa alla sicurezza può essere suddivisa in tre aree: norme funzionali, criteri di valutazione della garanzia e norme relative al sistema di gestione della sicurezza.
1) Norme funzionali: queste sono relative ai prodotti e hanno lo scopo principale di ricercare l’interoperabilità dei prodotti informatici. Coprono argomenti quali i protocolli di comunicazione, il formato dei dati (per esempio in un certificato digitale o in una smartcard) e così via. Oltre agli standard emessi dagli enti formali di standardizzazione, ci sono numerose specifiche tecniche pubbliche emesse da associazioni e talvolta anche da industrie private. Oltre agli enti già citati, segnaliamo anche i seguenti: ANSI, American National Standards Institute (www.ansi.org), IEC, Commissione Elettrotecnica Internazionale: (www.iec.ch), DIN, Deutsches Institut für Normung (www.din.de), SEIS, Swedish Secured Electronic Information in Society Specifications, Sweden (www.seis.se).Tra le associazioni, oltre al citato IETF, segnaliamo l’IEEE, Institute of Electrical and Electronics Engineers (www.ieee.org.). Tra gli standard di aziende private segnaliamo la serie PKCS#1-15 (Public Key Cryptography Standards) di RSA Security (www.rsa.com).
2) Criteri di valutazione della garanzia: sono i metodi con cui viene valutata la fiducia che può essere accordata ai sistemi e ai prodotti informatici di sicurezza. Tra le pubblicazioni disponibili, le tre più significative sono i criteri americani TCSEC (Trusted Computing Security Evaluation Criteria, 1985), i criteri europei ITSEC (Information Security Evaluation Criteria, 1991) e i criteri internazionali ISO/IEC 15408, noti come Common Criteria e pubblicati nel 1999.
3) Norme e linee guida relative al sistema di gestione della sicurezza nell’azienda: segnaliamo le linee guida ISO/IEC 13335 (Part 1: Concepts and models for IT Security, Part 2: Managing and planning IT Security, Part 3: Techniques for the management of IT Security, Part 4: Selection of safeguards, Part 5: Management guidance on network security) e le norme BS (British Standard) 7799 (Part 1: Code of Practice, recepita dalla ISO/IEC 17799 Code of practice for information security management del 2000 e Part 2: Controls, riveduta nel 2002).

I criteri per la valutazione della garanzia
Abbiamo visto in precedenza che i sistemi di sicurezza sono caratterizzati dalla funzionalità (quello che il sistema deve fare per la sicurezza) e dalla garanzia (la fiducia nella protezione offerta dalla funzionalità), a sua volta costituita da correttezza (qualità di implementazione della funzionalità) e da efficacia (in quale grado la contromisura protegge dalle minacce).
Le tre fonti citate sopra a proposito dei criteri di valutazione della garanzia si chiamano appunto criteri di valutazione, anziché norme o standard, perché, sia pure con diversa attenzione ai requisiti funzionali, tutti si esprimono sui livelli di garanzia, un concetto troppo astratto per essere ridotto a uno standard. In ogni caso, TCSEC mischia funzionalità e garanzia, ITSEC tenta di separare le due categorie, ma non ci riesce del tutto, mentre questo risultato è stato raggiunto nei Common Criteria, più efficaci e agevoli da applicare.
I criteri di valutazione dei processi di sicurezza hanno seguito idee e metodi diversi nel tempo e nelle varie aree geografiche. Oggi il TCSEC viene considerato troppo rigido, l’ITSEC troppo morbido e complicato e i Common Criteria accettabili da tutti.
Il TCSEC è stato sviluppato dal Dipartimento della Difesa USA e pubblicato dal National Computer Security Center (parte della National Security Agency) nel cosiddetto

Orange Book del 1985. Sebbene in Europa possa essere visto come superato, nella cultura di sicurezza americana occupa ancora uno spazio rilevante ed è considerato indicativo delle esigenze di sicurezza degli ambienti militari.
Il TCSEC serve per valutare sistemi operativi, applicazioni e prodotti di vario genere. I criteri di valutazione sono stati pubblicati in un volume dalla copertina arancione, detto perciò Orange Book. Le valutazioni di sicurezza risultanti dall’applicazione del TCSEC servono ai compratori per confrontare diverse soluzioni e ai produttori per sapere a quali specifiche conformarsi.
L’Orange Book viene usato per accertare se i prodotti offrono le caratteristiche di sicurezza dichiarate e per valutare se un prodotto è appropriato per una funzione o applicazione specifica. Durante la valutazione, l’Orange Book prende in considerazione la funzionalità e la garanzia di un sistema e fornisce un sistema di classificazione suddiviso in una gerarchia di livelli di sicurezza:
A. Protezione verificata
B. Protezione obbligatoria
C. Protezione discrezionale
D. Sicurezza minima.
Ognuna delle quattro divisioni, da A (massima sicurezza) a D (minima sicurezza), può avere una o più classi di sicurezza, ognuna numerata e corrispondente a un certo insieme di requisiti da soddisfare. Le classi con numero superiore indicano un maggiore grado di fiducia e garanzia. I criteri di valutazione includono quattro argomenti principali: politiche di sicurezza, rendicontabilità (accountability), garanzia (assurance) e documentazione, ciascuna delle quali si suddivide in sei aree:
- Politiche di sicurezza (la policy deve essere esplicita e ben definita e imposta da meccanismi interni al sistema)
- Identificazione (i singoli soggetti devono essere identificati)
- Etichette (le etichette per il controllo degli accessi devono essere associate in modo appropriato agli oggetti)
- Rendicontabilità (si devono raccogliere e proteggere i dati di audit per imporre la rendicontabilità)
- Garanzia del ciclo di vita (software, hardware e firmware devono poter essere testati individualmente per assicurare che ciascuno imponga la politica di sicurezza in modo efficace per tutto il ciclo di vita)
- Protezione continua (i meccanismi di sicurezza e l’intero sistema devono funzionare con continuità in modo prevedibile e accettabile in tutte le diverse situazioni).
Queste categorie sono valutate in modo indipendente, ma alla fine viene assegnata una valutazione complessiva. Ogni divisione e classe di sicurezza include i requisiti delle classi e divisioni inferiori (per esempio la B2 include i requisiti di B1, C2 e C1).
Le classi sono: C1 (protezione di sicurezza discrezionale), C2 (protezione ad accessi controllati), B1 (protezione obbligatoria), B2 (protezione strutturata), B3 (domini di sicurezza) e A1 (progetto controllato). TCSEC s’indirizza alla riservatezza, ma non all’integrità. Mette grande enfasi su controllare quali utenti possono accedere al sistema e ignora praticamente che utilizzo costoro facciano delle informazioni. Funzionalità e garanzia dei meccanismi di sicurezza non sono valutate separatamente, ma combinate tra loro.
Viste le numerose carenze dell’Orange Book, specialmente se applicato in ambito civile, furono pubblicate diverse estensioni, in quella che prese il nome di Rainbow Series (serie arcobaleno). Ne fa parte il Trusted Network Interpretation (TNI), detto Red Book, che si occupa di sicurezza delle reti, uno dei tanti argomenti non trattati dall’Orange Book.
L’ITSEC è stato il primo tentativo di stabilire un unico standard di valutazione degli attributi di sicurezza da parte di molti paesi europei. Durante gli anni ’80, Regno Uni-

IT Administrator Sicurezza informatica Lezione 1

to, Germania, Francia e Olanda avevano prodotto versioni dei loro criteri nazionali, in seguito armonizzate e pubblicate come Information Technology Security Evaluation Criteria (ITSEC).
La versione 1.2 corrente è stata pubblicata nel 1991 dalla Commissione Europea, a cui ha fatto seguito nel 1993 l'IT Security Evaluation Manual (ITSEM) che specifica la metodologia da seguire per realizzare le valutazioni ITSEC.
L’innovazione rispetto al TCSEC è stato il tentativo di rendere indipendente la definizione delle funzionalità, così da poter applicare i criteri ITSEC a un ampio spettro di prodotti e sistemi, che nel gergo ITSEC si chiamano TOE (target of evaluation).
La definizione delle funzionalità di sicurezza è scorporata in un documento chiamato Security Target, che descrive le funzionalità offerte dal TOE e l’ambiente operativo del TOE. Nel caso di un sistema, il Security Target contiene una System Security Policy (regole operative definite su misura per uno specifico ambiente operativo).
La valutazione ITSEC viene eseguita da terze parti chiamate CLEF (Commercial Licensed Evaluation Facility) a cui spetta fornire le certificazioni di conformità ai requisiti di sicurezza. Il processo ISEC inizia con lo sponsor (di solito lo sviluppatore del prodotto, o TOE) che nomina un CLEF. Il CLEF valuta il Security Target e produce un piano di lavoro. Viene nominato un certificatore e il processo ha inizio. Lo sponsor fornisce tutto il materiale al valutatore, che valuta se esso soddisfa i requisiti in termini di completezza, coerenza e accuratezza. Una volta soddisfatto, il valutatore produce un report e lo sottopone al certificatore per l’approvazione. Se il certificatore è soddisfatto, produce un report di certificazione e pubblica un certificato ITSEC.
Il Security Target è il documento chiave per la valutazione e contiene il target evaluation level, ossia il livello di valutazione di sicurezza a cui il produttore aspira per commercializzare il suo prodotto in un certo mercato. Ci sono sei livelli di valutazione da E1 a E6; maggiore è il livello, maggiore è il dettaglio e il rigore richiesto ai materiali sottoposti alla valutazione.
I requisiti di efficacia sono gli stessi per i sei livelli di valutazione e sono valutati in una serie di analisi: Suitability Analysis, Binding Analysis, Ease of Use Analysis, Construction Vulnerabilities Analysis e Operational Vulnerabilities Analysis.
Per valutare la correttezza del prodotto viene prodotto il documento Architectural Design, che identifica ad alto livello la struttura di base del TOE, le interfacce e la suddivisione in hardware e software. Il Detailed Design è un documento che scende nei dettagli dell’Architectural Design fino a un livello di dettaglio utilizzabile come base per l’implementazione. Durante il processo di valutazione, viene verificato se le specifiche di sicurezza del Detailed Design sono implementate correttamente e vengono esaminati i sorgenti del software e i diagrammi di progetto dell’hardware.
Ulteriori materiali forniti dal produttore per la valutazione includono l’ambiente di sviluppo (controllo di configurazione, linguaggi di programmazione, compilatori eccetera), la documentazione operativa (guida utente e manuale di amministrazione) e l’ambiente operativo (distribuzione, configurazione, installazione e utilizzo).
L’ITSEC ha tentato di fornire un approccio più flessibile del rigido TCSEC, di separare funzionalità e garanzia e di consentire la valutazione di interi sistemi. La flessibilità ha però portato con sé la complessità, perché i valutatori possono mescolare e abbinare le valutazioni di funzionalità e garanzia, facendo proliferare le classificazioni e rendendo il processo tortuoso.
I tempi erano maturi per tentare un approccio più efficace e unificato tra aree geografiche. Nel 1990 l’ISO riconobbe l’esigenza di criteri standard di valutazione di applicabilità globale. Il progetto Common Criteria iniziò nel

1993 quando diverse organizzazioni si associarono per combinare e allineare i criteri di valutazione esistenti ed emergenti: TCSEC, ITSEC, il canadese CTCPEC (Canadian Trusted Computer Product Evaluation Criteria) e i criteri federali USA. Il progetto fu sviluppato attraverso la collaborazione degli enti nazionali di standardizzazione di Stati Uniti, Canada, Francia, Germania, Regno Unito e Olanda. I benefici di questo sforzo comune comprendono la riduzione della complessità del sistema di valutazione, la disponibilità di un unico linguaggio per le definizioni e per i livelli di sicurezza e, a beneficio dei produttori, l’uso di un unico insieme di requisiti per vendere i prodotti sul mercato internazionale.
La versione 1.0 dei Common Criteria è stata completata nel gennaio 1996. Sulla base di approfondite prove, valutazioni e reazioni del pubblico, la versione 1.0 subì un’estesa revisione e diede vita alla versione 2.0 dell’aprile 1998, che divenne lo standard ISO 15408 nel 1999. Il progetto ha in seguito incorporato modifiche di lieve entità che hanno prodotto la versione 2.1 dell’agosto 1999. Oggi la comunità internazionale ha adottato i CC attraverso il Common Criteria Recognition Arrangement, un accordo in base al quale i firmatari concordano nell’accettare i risultati delle valutazioni CC eseguite da altri membri della CCRA.
La flessibilità dell’approccio dei Common Criteria sta nel fatto che un prodotto è valutato a fronte di un certo profilo di protezione, strutturato in modo da soddisfare specifici requisiti di protezione. Rispetto all’ITSEC, di cui conserva molti aspetti, come la separazione tra funzionalità e garanzia, i Common Criteria forniscono cataloghi di funzionalità e requisiti di garanzia che rendono più formale e ripetibile la compilazione del Security Target. Alla valutazione di un prodotto viene assegnato un Evaluation Assurance Level (EAL) che va da 1 a 7 (massima garanzia). La completezza e il rigore dei test crescono con il livello di garanzia assegnato. I sette livelli hanno questi significati: EAL1 testato funzionalmente
EAL2 testato strutturalmente
EAL3 testato e verificato metodicamente
EAL4 progettato, testato e riveduto metodicamente EAL5 progettato e testato in modo semi-formale EAL6 verifica del progetto e testing semi-formali EAL7 verifica del progetto e testing formali

Il sistema Common Criteria utilizza i protection profile per la valutazione dei prodotti. Il protection profile contiene l’insieme di requisiti di sicurezza, il loro significato e le ragioni per cui sono necessari, oltre che il livello EAL che il prodotto deve soddisfare. Il profilo descrive le condizioni ambientali, gli obiettivi e il livello previsto per la valutazione della funzionalità e della garanzia. Viene elencata ogni vulnerabilità e come dev’essere controllata da specifici obiettivi di sicurezza. Inoltre il documento fornisce le motivazioni per il livello di garanzia e la robustezza dei meccanismi di protezione.
Nella struttura del sistema Common Criteria, il protection profile descrive la necessità di una specifica soluzione di sicurezza, che è l’input per il prodotto da valutare (TOE). Il TOE è il prodotto proposto per fornire la soluzione alle esigenze di sicurezza. Il security target è scritto dal produttore e spiega le funzionalità di sicurezza e i meccanismi di garanzia che soddisfano i requisiti di sicurezza. I Security Functionality Requirements e i Security Assurance Requirements formano dei componenti (package) riutilizzabili che descrivono gli insiemi dei requisiti di funzionalità e di garanzia da soddisfare per ottenere lo specifico EAL a cui il produttore aspira. Questi documenti di requisiti sono indipendenti dalle tecnologie con cui vengono realizzati i prodotti.
L’utilizzo di prodotti certificati, oltre a rispondere a requisiti formali di approvvigionamento, offre numerosi benefici, tra cui la disponibilità di un documento di specifi-

Lezione 1 IT Administrator Sicurezza informatica

che di sicurezza formalizzate (il security target) contenente la descrizione delle minacce che il prodotto è in grado di contrastare e l’esistenza di test e verifiche effettuate, secondo metodologie documentate, da un ente indipendente. Le pubblicazioni relative ai Common Criteria sono inoltre di ausilio per tenere conto dei requisiti di funzionalità e di garanzia nella progettazione di sistemi informatici con requisiti di sicurezza, anche se non s’intende sottoporli al processo di certificazione.

Riferimenti:
csrc.nist.gov/cc, www.rycombe.com/cc.htm, www.clusit.it/whitepapers/iso15408-1.pdf, www.clusit.it/whitepapers/iso15408-2.pdf e www.clusit.it/whitepapers/iso15408-3.pdf
Le norme sul sistema
di gestione della sicurezza
Gli sviluppi normativi nel campo dei sistemi di gestione della sicurezza delle informazioni sono avvenuti in tempi più recenti rispetto all’evoluzione dei criteri di valutazione della garanzia (come TCSEC, ITSEC e Common Criteria) e dei sistemi di gestione della qualità (come ISO 9000).
ISO/IEC ha pubblicato, tra il 1996 e il 2001, una serie di cinque documenti (ISO/IEC TR 13335), la cui sigla TR (technical report) indica che si tratta di linee guida del tipo best practice (modalità operative consigliate), non di specifiche formali. Questi documenti sono una possibile alternativa alla coppia ISO/IEC 17799 BS 7799 di fonte britannica. Le cinque parti della serie TR 13335 sono le seguenti:

- Parte 1: Concepts and models for IT security. Il primo documento fornisce una panoramica dei concetti relativi alla sicurezza delle informazioni e dei modelli che un’organizzazione può utilizzare per definire la propria sicurezza IT.

- Parte 2: Managing and planning IT security. Questo documento si occupa degli aspetti di pianificazione e di gestione della sicurezza delle informazioni.

- Parte 3: Techniques for the management of IT security. Questo documento si occupa delle attività di management che sono direttamente legate al ciclo di vita dei progetti: pianificazione, progettazione, implementazione, testing eccetera.

- Parte 4: Selection of safeguards. In parte complementare alla parte 3, descrive la selezione delle contromi-

sure e l’importanza e la modalità d’impiego dei modelli di sicurezza di base e delle verifiche.

- Parte 5: Management guidance on network security. Questo documento fornisce linee guida sulle comunicazioni e sulle reti, in particolare l’analisi dei fattori che devono essere presi in considerazione per definire requisiti di sicurezza e contromisure appropriati. Inoltre fornisce un approccio alla definizione dei livelli di fiducia basato sulla valutazione del rischio.

Le linee guida BS 7799, oggi ISO/IEC 17799 e BS 7799-2, hanno una storia che risale agli inizi degli anni ’90, quando il Dipartment of Trade and Industry britannico istituì un gruppo di lavoro con l’intento di fornire alle aziende linee guida per la gestione della sicurezza delle informazioni. Nel 1993 questo gruppo pubblicò il Code of practice for information security management, un insieme di buone regole di comportamento per la sicurezza delle informazioni. Questo costituì la base per lo standard BS 7799 pubblicato da BSI (British Standards Institution) nel 1995 e noto come Code of Practice. Nel 1998 BSI aggiunse la seconda parte, Specification for Information Security Management, che fu sottoposta a revisione e ripubblicata nel 1999. Il Code of Practice fu sottoposto a ISO/IEC per essere approvato come standard internazionale, una volta nel 1995 senza successo e in seguito di nuovo nel 1999 con esito positivo. Il BS 7799 Parte 1 è stato quindi recepito come ISO/IEC 17799. La sua edizione del 2000 è in corso di aggiornamento nel 2005. La seconda parte, BS 7799-2, è stata aggiornata nel 2002.
L’ISO/IEC 17799 presenta una serie di linee guida e di raccomandazioni compilata a seguito di consultazioni con le grandi aziende. I 36 obiettivi e le 127 verifiche di sicurezza contenuti nel documento sono suddivisi in 10 aree, o domini, riportati nel riquadro A, II dieci domini formano una piramide che scende dalla prospettiva organizzativa (1, 2, 3, 4, 9, 10) verso quella operativa (6, 7, 8), con inclusi gli aspetti tecnici (5).
Le verifiche di sicurezza ulteriormente dettagliate nel documento, portano a oltre 500 il numero di controlli ed elementi di best practice dell’ISO/IEC 17799. Il documento sottolinea l’importanza della gestione del rischio e chiarisce che non è indispensabile implementare ogni singola linea guida, ma solo quelle che sono rilevanti. Lo standard copre tutte le forme d’informazione, incluse la voce, la grafica e i media come fax e cellulari. Esso riconosce anche i nuovi metodi di business, come l’e-com-

IT Administrator Sicurezza informatica Lezione 1

merce, Internet, l’outsourcing, il telelevoro e il mobile computing.
Mentre l’ISO/IEC 17799 fornisce le linee guida, gli aspetti di sicurezza e le buone norme da applicare, in sé sufficienti per un’azienda medio-piccola, lo standard BS 77992 fornisce le direttive per istituire un sistema di gestione della sicurezza delle informazioni (SGSI in italiano o ISMS, Information Security Management System, nella letteratura) da sottoporre alla certificazione di un ente accreditato. L’applicazione del BS 7799-2 permette all’azienda di dimostrare ai suoi partner che il proprio sistema di sicurezza è conforme allo standard e risponde alle esigenze di sicurezza determinate dai propri requisiti.
Un’organizzazione che ottiene la certificazione è considerata conforme ISO/IEC 17799 e certificata BS 7799-2.
L’aggiornamento del 2002 del BS 7799-2 ha introdotto varie modifiche suggerite dall’esigenza di dare continuità al processo di gestione della sicurezza. Il modello di ISMS definito dallo standard comprende quattro fasi in un loop ciclico, analogo a quello dell’ISO 9001.
Il modello è detto PDCA dalle iniziali delle quattro fasi: Plan (pianifica: la definizione dell’ISMS), Do (esegui: l’implementazione e utilizzo dell’ISMS), Check (verifica: i controlli e le revisioni dell’ISMS) e Act (agisci: la manutenzione e miglioramento dell’ISMS).

Le quattro fasi dell’Information Security Management System
Plan:
1. la definizione dell’ambito di applicazione dell’ISMS
2. la definizione di una politica di sicurezza di alto livello
3. la definizione di un approccio sistematico per l’analisi del rischio
4. l’identificazione dei rischi
5. la valutazione dei rischi

6. l’identificazione delle opzioni per il trattamento dei rischi (eliminazione, cessione e riduzione)
7. la selezione delle contromisure per il controllo dei rischi
8. la redazione della dichiarazione di applicabilità, comprendente l’esplicitazione delle ragioni che hanno portato alla selezione delle contromisure e alla non applicazione di misure indicate nell’appendice A della norma.
Do:
1. la formulazione di un piano di trattamento dei rischi
2. l’implementazione del piano
3. l’implementazione delle contromisure selezionate
4. lo svolgimento di programmi d’informazione e di formazione
5. la gestione delle operazioni connesse alla fase Do
6. la gestione delle risorse connesse alla fase Do
7. l’implementazione di procedure e altre misure che assicurino la rilevazione e le opportune azioni in caso di incidenti relativi alla sicurezza
Check:
1. l’esecuzione delle procedure di monitoraggio dell’ISMS
2. l’esecuzione di revisioni del rischio residuo
3. la conduzione di audit interni all’ISMS
4. la conduzione di review al massimo livello dirigenziale dell’ISMS
5. la registrazione delle azioni e degli eventi che potrebbero avere impatti sulla sicurezza o sulle prestazioni dell’ISMS
Act:
1. l’implementazione delle azioni migliorative dell’ISMS identificate
2. l’implementazione delle azioni correttive e preventive
3. la comunicazione dei risultati
4. la verifica che i miglioramenti raggiungano gli obiettivi identificati alla loro base.
L’appendice A della norma BS 7799-2 del 2002 include una serie di misure per il controllo del rischio suddivise in 10 capitoli, gli stessi delle 10 aree sopra elencate per l’ISO/IEC 17799.

Naturalmente, la conformità all’ISO/IEC 17799 o la certificazione BS 7799-2 non implicano che un’organizzazione sia sicura al 100%, un obiettivo peraltro irraggiungibile. Tuttavia, l’adozione di questo standard, apprezzato a livello internazionale, offre diversi vantaggi a livello organizzativo (efficacia dello sforzo di sicurezza a tutti i livelli, diligenza degli amministratori), a livello legale (osservanza di leggi e regolamenti), a livello operativo (gestione del rischio, qualità di hardware e dati), a livello commerciale (distinzione dalla concorrenza, partecipazione a gare), a livello finanziario (costo delle violazioni, costi assicurativi) e a livello umano (consapevolezza e responsabilità del personale). La popolarità della coppia ISO/IEC 17799 e BS 7799-2 è dovuta in parte alla sua flessibilità e alla sua complementarità con altri standard di sicurezza IT. Mentre l’ISO/IEC 17799 delinea le migliori pratiche per la gestione della sicurezza delle informazioni, l’ISO 13335 (Guideline for the Management of IT Security, GMITS) può essere visto come il suo fratello maggiore, con l’aggiunta di aspetti tecnologici e un’estensione della gestione del rischio. C’è forte complementarità anche tra l’ISO/IEC 17799 e l’ISO 15408, ossia i Common Criteria. Mentre il primo si focalizza più sugli aspetti organizzativi e amministrativi, il secondo copre gli aspetti tecnici della sicurezza. Ulteriori relazioni si possono individuare tra questi standard e gli standard ISO 18044 (Incident Management), ISO 17944 (Financial Systems), ISO 18028 (Communications Management) e ISO 14516 (E-commerce Security). Il BS 7799-2 del 2002 è anche armonizzato con l’ISO 9001:2000 (Vision 2000) e l’ISO 14001:1996.

Lezione 1 IT Administrator Sicurezza informatica
Il processo di standardizzazione di Internet
Quello che segue è un elenco di alcune delle organizzazioni più importanti che operano nell’interesse dell’intera comunità di Internet e dei suoi standard.

Internet Society – ISOC (www.isoc.org) Un’organizzazione privata senza fini di lucro che riuni-
sce professionisti nel mondo del networking e che ha la missione di garantire il continuo funzionamento di Internet e il suo potenziamento. Opera attraverso una serie di comitati tecnici che definiscono gli standard e i protocolli utilizzati da qualsiasi apparecchiatura che si collega a Internet (IETF, IESG, IAB, IRTF). L’ISOC fornisce la leadership nella gestione di Internet per quanto riguarda gli standard, l’istruzione e lo sviluppo della politica amministrativa.

IETF (Internet Engineering Task Force, www.ietf.org)
È la comunità internazionale dei progettisti, operatori, produttori, e ricercatori nel campo del networking, interessati all’evoluzione dell’architettura di Internet e della sua continuità e affidabilità di funzionamento. Sviluppa standard tecnici su base consensuale, per esempio in relazione ai protocolli di comunicazione.

IESG
(Internet Engineering task Group, www.ietf.org/iesg.html) Lo IESG è responsabile della gestione tecnica delle attività dell’IETF e del processo di standardizzazione di Internet. Come parte dell’ISOC, amministra tale processo secondo le regole e le procedure che sono state ratificate dai fiduciari dell’ISOC. Lo IESG è direttamente responsabile delle azioni associate all’avvio e alla prosecuzione dell’iter di standardizzazione, inclusa l’approvazione finale delle specifiche come Standard Internet. Lo IESG
coordina e approva gli standard tecnici.

IAB (Internet Architecture Board, www.iab.org)
Lo IAB è un gruppo tecnico consultivo della Internet Society, responsabile della selezione dello IESG, della supervisione dell’architettura, della supervisione del processo di standardizzazione e della procedura di appello, della serie delle RFC (Request For Comment), dei collegamenti esterni e di consiglio all’ISOC.

IRTF (Internet Research Task Force, www.irtf.org)
La missione dell’IRTF consiste nel promuovere attività di ricerca che possano contribuire in modo significativo al futuro sviluppo di Internet. Opera creando gruppi di ricerca focalizzati sui seguenti temi: protocolli, applicazioni, architettura e tecnologia.

ICANN (Internet Corporation for Assigned Names and Numbers, www.icann.org)
È l’azienda non-profit che fu creata per assumere la responsabilità dell’attribuzione degli spazi d’indirizzamento IP, dell’assegnazione dei parametri dei protocolli, della gestione del sistema dei domini e della gestione del sistema dei server root, funzioni che in precedenza erano eseguite, sotto contratto con il governo USA, dalla IANA e da altre entità. È l’autorità per l’assegnazione dei nomi di dominio a livello globale.

IANA
(Internet Assigned Numbers Authority, www.iana.org)
La IANA mantiene le funzioni di coordinamento centrale dell’Internet globale nel pubblico interesse. La IANA custodisce i numerosi parametri e valori di protocollo unici necessari per il funzionamento di Internet e per il suo sviluppo futuro.
Il processo di definizione degli Standard Internet è

un’attività della Internet Society, che è organizzata e gestita per conto della comunità Internet dallo IAB e dallo IESG. Comprende una serie di passi e di attività che producono come risultato gli standard dei protocolli e delle procedure.
“Uno Standard Internet è una specifica stabile e ben compresa, è scritto con competenza tecnica, conta diverse implementazioni indipendenti e interoperabili con sostanziale esperienza operativa, gode di un supporto pubblico significativo e la sua utilità è riconosciuta in tutta Internet o in parti di essa” RFC 2026, 1996.
Per essere adottata come standard, una specifica è sottoposta a un periodo di sviluppo e a numerose iterazioni di revisione da parte della comunità di Internet e a un esame basato sull’esperienza.
Per prima cosa, una specifica diventa un documento RFC. Non tutte le RFC diventano Standard Internet. Poi, se la RFC diventa uno standard, viene adottata dall’ente appropriato ed è resa disponibile al pubblico quale standard. Il processo di standardizzazione attraversa i seguenti stadi di sviluppo, collaudo e accettazione.

Proposta di standard
(almeno sei mesi)
- generalmente stabile
- scelte di progettazione risolte
- sembra godere di sufficiente interesse della comunità per essere considerato valido

Bozza di standard
(almeno quattro mesi dall’approvazione della riunione IETF
- ben capito
- ottenuta una sufficiente esperienza operativa

Standard
(fino a una successiva revisione o sostituzione)
- ottenuta un’implementazione significativa e un’esperienza operativa positiva
- alto grado di maturità tecnica
- fornisce benefici di rilievo alla comunità Internet

IT Administrator Sicurezza informatica
Concetti e algoritmi di crittografia
Scopriamo
i fondamenti e le tecniche di crittografia
Prosegue il primo corso di taglio professionale destinato al conseguimento della certificazione ufficiale, EUCIP IT Administrator – Sicurezza Informatica, valida in tutta Europa. La seconda lezione esplora tutti i principali algoritmi e standard di crittografia utilizzati per garantire riservatezza, l’integrità e l’autenticità dei documenti. Anche in questo caso i contenuti si articolano in tre elementi:
un articolo sulla rivista,
un articolo, molto più esteso in formato PDF e un corso multimediale completo su CD e DVD di Giorgio Gobbi

e reti di computer, soprattutto attraverso Internet, hanno reso possibile la rapida e facile comunicazione tra utenti oltre che tra aziende e compratori. Con 285 milioni di siti attivi (ottobre 2004) e oltre 800 milioni di utenti (febbraio 2005), gli scambi commerciali e le transazioni economiche che avvengono su Internet hanno raggiunto un volume ingente e sono in forte crescita, favoriti dalla
progressiva fiducia nella sicurezza delle operazioni. L’assenza del contatto personale e dello scambio di do-
cumenti cartacei intestati e firmati, richiede strumenti sostitutivi per identificare gli interlocutori, per mantenere la riservatezza e l’integrità delle informazioni scambiate e per conferire validità legale alla transazione, in modo che non possa essere disconosciuta (oppure, come si suol dire, ripudiata) dalla parte che contrae l’impegno (o in generale da tutte le parti in gioco).
In pratica, gli strumenti e le procedure della sicurezza informatica hanno il compito di fornire agli utenti (individui e organizzazioni) lo stesso livello di fiducia che provano quando eseguono lo stesso tipo di operazioni con i metodi tradizionali e le firme autografe. Nella lezione precedente abbiamo trattato dell’analisi del rischio, una fase essenziale del programma di sicurezza, dove si considerano le probabilità di attuazione delle minacce e la gravità del loro impatto per selezionare le contromisure da mettere in campo. Si tratta di un approccio fondamentalmente difensivo o passivo, che valuta quali rischi accettare, quali delegare a terzi e quali controllare, riducendoli o azzerandoli.
Nella presente lezione ci occupiamo invece di sicurezza attiva, ossia delle misure di sicurezza che proteggono le informazioni in modo proattivo, in modo cioè da anticipa-

re e neutralizzare i problemi futuri. Questo viene ottenuto non solo impedendo agli estranei di accedere alle informazioni (sicurezza passiva o difensiva), ma rendendo le informazioni intrinsecamente sicure a livello applicativo, proteggendone la riservatezza (confidentiality, chiamata anche confidenzialità), l’integrità e l’autenticità. Vedremo che le tecniche crittografiche permettono 1) di trasformare dati, informazioni e messaggi in modo da nasconderne il contenuto a chiunque non sia autorizzato e attrezzato per prenderne visione, 2) di impedire a estranei di alterare i dati, segnalando qualunque tentativo in tal senso e 3) di garantire l’autenticità dei dati, associandoli in modo certo al loro proprietario, impedendo allo stesso tempo che il mittente di un messaggio possa ripudiarne la paternità.

Lezione 2 IT Administrator Sicurezza informatica

Per meglio apprezzare i vantaggi della sicurezza attiva, proviamo a immaginare cosa accadrebbe a un messaggio confidenziale che venisse inviato su Internet. Sul computer di partenza, il messaggio, contenuto nell’archivio della posta elettronica, sarebbe leggibile da chiunque si procurasse l’accesso al computer, un’operazione relativamente facile dall’interno dell’organizzazione e non impossibile dall’esterno se mancano le opportune difese. Nel momento in cui il messaggio viene spedito, attraversa la rete locale interna (dove può essere intercettato tramite analizzatori di rete, packet sniffer e altri strumenti per intercettare i pacchetti), esce dall’edificio, raggiunge la centrale del gestore di telecomunicazioni, viene instradato verso il sito che ospita il server di e-mail e qui staziona in una casella postale in attesa di essere prelevato. Una volta prelevato, secondo i casi, viene cancellato o meno dal server e viene comunque trasferito sul computer del destinatario, nell’archivio personale di posta elettronica. Durante il percorso, il messaggio è intercettabile dagli organismi di sicurezza nazionali (di solito su mandato della magistratura) e, se fosse per qualche verso appetibile, anche da agenzie di sicurezza che non chiedono permessi. Inoltre, se il messaggio contenesse informazioni preziose per nemici, concorrenti e specialisti di furto e ricatto, lungo il suo percorso, dal computer di origine a quello di destinazione, potrebbe trovare in agguato hacker, dispositivi di rilevamento o individui che, mediante tecniche di social engineering, si procurano i file da chi ha o può procurare (anche inconsapevolmente) il diritto di accesso. Il social engineering, nel campo della sicurezza informatica, è la pratica di manipolare ad arte le persone per indurle a compiere azioni (come l’esecuzione di software maligno) oppure a rivelare informazioni (come le password) utili a ottenere accesso a dati e risorse. Si comprende la complementarità della difesa passiva e di quella attiva con un esempio. Supponiamo che su un computer siano installati sistemi crittografici che proteggono i documenti dal momento in cui sono archiviati localmente in poi (trasmissione, prelievo dal mail server e archiviazione sul computer di destinazione). Supponiamo al tempo stesso che, per carenza di sicurezza difensiva, un malintenzionato convinca l’utente a eseguire un’applicazione particolarmente interessante o divertente, che in realtà installa un key logger, cioè un registratore dell’input di tastiera, salvato in un file che potrà essere prelevato segretamente attraverso Internet, anche tramite e-mail. In questo scenario, i documenti sono crittografati e ben protetti come tali, ma il loro contenuto è stato intercettato a monte e viene trasmesso all’esterno.

La crittografia
La parola crittografia deriva dal greco kryptós (nasco-

sto) e graphein (scrivere). L’utilizzo della “scrittura nascosta”, come accennato nella prima lezione, risponde da millenni all’esigenza di mantenere riservate o segrete certe categorie di comunicazioni, a partire da quelle militari. La crittografia non studia come nascondere un messaggio (di cui si occupano altre tecniche, come la steganografia – che deriva dal greco stèganos – rendo occulto, nascondo), bensì come nascondere il significato o contenuto di un messaggio (o di un documento) in modo che risulti comprensibile solo al destinatario stabilito dal mittente.
Il mittente di un messaggio prende il testo originale, detto testo in chiaro, lo sottopone a un’operazione di cifratura e ottiene il testo cifrato. Il destinatario esegue un’operazione di decifratura per ricostruire il messaggio originale. Per semplicità, e per assonanza con i termini in lingua inglese (plaintext e ciphertext), parliamo spesso di testo, intendendo che documenti e messaggi possono contenere anche immagini, sequenze audio/video, dati binari eccetera.
Il metodo utilizzato per cifrare il messaggio è detto algoritmo di crittografia o cifrario.

Un esempio di algoritmo è la sostituzione di ogni lettera con la lettera che si trova tre posizioni più avanti nell’alfabeto ed è noto come cifrario di Cesare. Nella moderna crittografia un cifrario prevede l’uso di una chiave di cifratura, una sequenza di caratteri di lunghezza massima stabilita che governa il funzionamento dell’algoritmo. L’algoritmo esegue una serie di trasformazioni dal testo in chiaro al testo cifrato: la chiave determina l’entità delle sostituzioni, trasposizioni e altre operazioni che formano l’algoritmo, così che, al variare della chiave, cambia il testo cifrato. Idealmente, per un dato testo in chiaro e per un dato algoritmo di cifratura, chiavi diverse generano sempre testi cifrati diversi.
L’algoritmo definisce anche le regole con cui il testo cifrato viene ritrasformato nel testo in chiaro originale attraverso l’uso di una chiave di decifratura.
I moderni standard di crittografia si ispirano al Principio di Kerchoff. Nel 1883, Auguste Kerchoff pubblicò un articolo in cui sosteneva che l’unico aspetto segreto di un sistema crittografico dovrebbe essere la chiave. Kerchoff affermava che l’algoritmo dovrebbe essere di pubblico dominio e che un sistema di sicurezza basato su troppi segreti finisce con l’essere più vulnerabile. Questo punto di vista è condiviso dal settore privato, ma non necessariamente dalle agenzie militari e governative, che amano creare i propri algoritmi mantenendoli segreti. Viceversa, è solo rendendo gli algoritmi ben noti che se ne possono scoprire le eventuali debolezze e vulnerabilità e si possono confrontare le caratteristiche delle diverse soluzioni disponibili, inventando una nuova generazione di cifrari quando cominciano ad apparire le prime crepe in quelli consolidati.
Secondo il grado di sicurezza che si desidera ottenere, esistono diversi algoritmi e diverse gestioni delle chiavi. La lunghezza delle chiavi determina il numero di valori possibili (che raddoppia a ogni bit aggiunto) e lo sforzo necessario per ricostruire il messaggio in chiaro in assenza della chiave. La lunghezza della chiave non è un termine di paragone assoluto: secondo il tipo di algoritmo, varia la lun-

IT Administrator Sicurezza informatica Lezione 2

ghezza di chiave considerata sicura nel contesto tecnologico corrente.

 

Quando la chiave di cifratura è la stessa usata per la decifratura, o possono essere derivate facilmente una dall’altra, si parla di crittografia simmetrica. In questo caso, sia il mittente sia il destinatario concordano sull’algoritmo da utilizzare e sulla chiave segreta. Quest’ultima dovrà essere comunicata in modo sicuro (possibilmente di persona), dovrà essere mantenuta segreta (possibilmente affidata solo alla memoria) e dovrà essere cambiata spesso per evitarne la scoperta, vuoi per mancanza di riservatezza nel suo uso vuoi per via matematico-statistica analizzando un vasto campione di messaggi.
Se la chiave di cifratura è diversa da quella di decifratura, si parla di crittografia asimmetrica. In tal caso le due chiavi sono generate contestualmente; una di esse prende il nome di chiave privata ed è tenuta segreta (e custodita al sicuro) dal proprietario, mentre l’altra, detta chiave pubblica, può essere messa a disposizione di chiunque. Le caratteristiche principali di questa coppia di chiavi sono le seguenti:
1) per ogni chiave pubblica esiste una sola chiave privata e viceversa, 2) se si utilizzano chiavi abbastanza grandi, non è praticamente possibile ricavare la chiave privata dalla chiave pubblica, 3) per cifrare un documento si può usare sia la chiave privata sia la chiave pubblica; per la decifratura si deve usare l’altra chiave della coppia.
Se per esempio si cifra un messaggio con la chiave pubblica del destinatario, solo quest’ultimo sarà in grado di decifrarlo, utilizzando la corrispondente chiave privata. Se invece si cifra un messaggio con la propria chiave privata e si rende disponibile la chiave pubblica, chiunque potrà decifrarlo (a patto di conoscere l’algoritmo utilizzato e di procurarsi la chiave pubblica). Mentre un messaggio cifrato con una chiave pubblica non garantisce l’identità del mittente e l’integrità del messaggio (chiunque può usare una chiave pubblica), un messaggio cifrato con una chiave privata, nel momento in cui viene decifrato con la chiave pubblica, assicura che proviene dal proprietario delle chiavi e che non è stato modificato lungo il percorso. Su questo principio si basa la firma digitale, di cui parleremo più avanti.
Obiettivi della sicurezza attiva
Abbiamo introdotto il concetto di sicurezza attiva, complementare alle misure difensive della sicurezza passiva, per rendere i dati intrinsecamente sicuri. I servizi di sicurezza attiva, che proteggono dati e messaggi nei sistemi informatici e di comunicazione, hanno i seguenti obiettivi: riservatezza (o confidenzialità), privacy, integrità, autenticità e non ripudio.
I servizi di sicurezza che permettono di raggiungere questi obiettivi sono basati su tecniche crittografiche e, come è facile immaginare, fanno uso di architetture standardizzate e ben collaudate, di cui, almeno per il settore non mi-

litare, si conoscono in dettaglio le proprietà e il grado di sicurezza e affidabilità. L’accento è sull’uso di metodi e tecnologie che hanno raccolto ampio consenso per la loro efficacia ed efficienza e che permettono la facile interoperabilità delle applicazioni, evitando i rischi e le complessità delle soluzioni ad-hoc. Tutti gli obiettivi di sicurezza attiva citati sono ottenibili tramite tecniche crittografiche standardizzate.

Crittografia simmetrica
La crittografia simmetrica, detta anche crittografia a chiave segreta, richiede che i due interlocutori usino lo stesso algoritmo e la stessa chiave segreta. Ciò significa che si deve trovare un canale sicuro per consegnare al destinatario la chiave o, meglio, dati privi di valore intrinseco da cui il destinatario ricostruisca la chiave. Visto che ogni coppia d’interlocutori richiede una chiave segreta, se questa fosse un elemento statico, per esempio una frase concordata a voce tra due persone, il numero di chiavi da conservare crescerebbe esponenzialmente con il numero degli interlocutori. Per esempio, per proteggere la comunicazione tra 10 persone, sarebbero necessarie 45 chiavi, che crescono a quasi mezzo milione per 1.000 interlocutori. In generale, per N persone che scambiano messaggi cifrati con crittografia simmetrica, occorrono N(N-1)/2 chiavi e ciascuno degli N utenti deve conservare al sicuro N-1 chiavi. Di conseguenza, nella pratica si usano sistemi automatici per la generazione e lo scambio sicuro delle chiavi.
Un altro aspetto della crittografia simmetrica è che conferisce riservatezza al messaggio, ma non assicura l’autenticazione o il non ripudio, poiché non c’è un’associazione univoca e sicura tra la chiave e un individuo. Di conseguenza, il mittente apparente di un messaggio cifrato con chiave simmetrica potrebbe sempre negare di avere spedito il messaggio, attribuendone la responsabilità diretta o indiretta al destinatario (detentore della stessa chiave).
D’altra parte, gli algoritmi di crittografia simmetrica sono molto veloci da eseguire e difficili da violare, se la chiave è abbastanza lunga. La crittografia simmetrica è l’unica opzione utilizzabile per cifrare grandi quantità di dati, un’operazione fuori della portata degli algoritmi asimmetrici.
A un buon algoritmo di crittografia simmetrica sono richieste alcune proprietà fondamentali, in modo che l’analisi delle relazioni tra input e output non fornisca indicazioni sull’algoritmo o sulla chiave:
1) il testo cifrato dev’essere funzione di tutti i bit della chiave e del testo in chiaro, 2) non ci dev’essere nessuna relazione statistica evidente tra testo in chiaro e testo cifrato, 3) modificando un singolo bit nel testo o nella chiave, ogni bit del testo cifrato è soggetto alla stessa probabilità di variazione, 4) modificando un bit nel testo cifrato, ogni bit del testo decifrato è soggetto alla stessa probabilità di variazione.

Lezione 2 IT Administrator Sicurezza informatica

Esistono due tipi di cifrari simmetrici: a blocchi (block cipher) e a flusso (stream cipher).
I cifrari a blocchi operano sui dati un blocco alla volta (le dimensioni tipiche dei blocchi sono di 64 o 128 bit) e ogni operazione su un blocco è un’azione elementare. I cifrari a flusso operano invece un bit o un byte alla volta; una volta inizializzati con una chiave, producono un flusso di bit e si prestano alla cifratura di grandi quantità di dati.
I cifrari a blocchi possono operare in diversi modi, che in molti casi prevedono il concatenamento dei blocchi fornendo in input all’operazione corrente i risultati delle operazioni precedenti; il che rende il cifrario meno vulnerabile a certi tipi di attacchi.
I principali tipi di cifrari a blocchi sono due: ECB (Electronic Code Book), CBC (Cipher Block Chaining).
Alla base troviamo la modalità ECB: ogni blocco di testo in chiaro viene trasformato in un blocco di testo cifrato. Lo stesso blocco di testo, con la stessa chiave, produce sempre lo stesso blocco di testo cifrato, il che consente ai malintenzionati di compilare un codice (code book) di tutti i possibili testi cifrati corrispondenti a un dato testo in chiaro. Se per esempio sappiamo che il blocco di testo contiene un pacchetto IP (Internet Protocol), i primi 20 byte di testo cifrato rappresentano sicuramente l’intestazione IP del pacchetto e possiamo usare tale conoscenza, abbinata a un code book, per determinare la chiave. Al fine di avere blocchi di input di lunghezza stabilita dal cifrario, può essere necessario aggiungere all’input un riempitivo (padding).
Il fatto che ogni blocco è indipendente dagli altri e produce sempre lo stesso blocco cifrato, rende meno sicuro l’algoritmo e permette a un attaccante di sostituire un blocco con un altro senza che il fatto sia rilevato. Avendo a disposizione una quantità di dati sufficienti e conoscendo la lingua o altre proprietà della comunicazione, si possono analizzare la frequenza con cui si presentano blocchi uguali e ricavare informazioni per compiere deduzioni sul testo originale. La modalità ECB è quindi adeguata per testi molto brevi (idealmente di un blocco) o nei casi in cui la chiave cambi per ogni blocco. In compenso, un bit errato nella trasmissione del testo cifrato causa un errore di decifratura solo nel blocco interessato.
La modalità CBC (Cipher Block Chaining) utilizza il blocco di testo cifrato precedente e lo combina in XOR (OR esclusivo, un’operazione tra due bit che produce come risultato 1 se i bit sono diversi o 0 se sono uguali) con il blocco successivo di testo in chiaro prima della cifratura. Il primo blocco è combinato in XOR con un Vettore di Inizializzazione (IV, Initialization Vector), scelto con forti proprietà di pseudocasualità in modo che testi diversi producano lo stesso testo cifrato.
La decifratura funziona nel modo opposto: ogni blocco è decifrato e combinato in XOR con il blocco precedente. Il primo blocco è decifrato e combinato in XOR con il vettore d’inizializzazione.
Poiché la cifratura dipende dai blocchi precedenti, un bit errato nella trasmissione del testo cifrato causa un errore di decifratura nel blocco interessato e in tutti quelli successivi. La modalità CBC assicura che le ripetizioni pre-

senti nel testo in chiaro non si riflettano in ripetizioni nel testo cifrato.
Altri modi utilizzati per i cifrari a blocchi sono il CFB (Cypher Feedback Mode), dove il blocco precedente di testo cifrato è cifrato e combinato in XOR con il blocco corrente di testo in chiaro (il primo blocco è combinato in XOR con il vettore d’inizializzazione) e l’OFB (Output Feedback Mode), che mantiene uno stato di cifratura, ripetutamente cifrato e combinato con i blocchi di testo in chiaro per produrre i blocchi cifrati (lo stato iniziale è costituito dal vettore d’inizializzazione).
Un cifrario a flusso (stream cipher) è un tipo di cifrario simmetrico che può essere progettato in modo da essere eccezionalmente veloce, molto più rapido di qualunque cifrario a blocchi. Mentre i cifrari a blocchi operano su blocchi di dati relativamente grandi (come 64 o 128 bit), i cifrari a flusso operano su unità più piccole, solitamente singoli bit. Un cifrario a blocchi produce lo stesso testo cifrato a parità di testo in chiaro, di chiave e di vettore d’inizializzazione. Con un cifrario a flusso, la trasformazione delle piccole unità di testo in chiaro varia a seconda del momento in cui esse compaiono durante il processo di cifratura.
Un cifrario a flusso genera il keystream, ossia una sequenza di bit usata come chiave, traducibile come flusso chiave, e la cifratura avviene combinando il keystream con il testo in chiaro in un’operazione di OR esclusivo (XOR), bit per bit, equivalente a una somma con eliminazione dell’eventuale riporto. La generazione del keystream può essere indipendente dal testo in chiaro e dal testo cifrato, producendo il cosiddetto cifrario sincrono, oppure può dipendere dai dati e dalla loro cifratura, nel qual caso il cifrario a flusso viene detto auto-sincronizzante. La maggior parte dei cifrari a flusso sono del tipo sincrono.

Principali algoritmi di crittografia simmetrica
Esistono diversi algoritmi di crittografia simmetrica, ognuno con le proprie caratteristiche di velocità, con specifici requisiti di risorse hardware o software e con un proprio livello di sicurezza (misurato dal tempo necessario per il “cracking”, cioè la scoperta della chiave segreta). Per esempio, alcuni sono più sicuri, ma richiedono un’implementazione hardware, altri sono meno sicuri, ma presentano bassi requisiti di memoria e si prestano per l’uso con piattaforme limitate come le smartcard.
Alcuni esempi di algoritmi di crittografia simmetrica tra i più conosciuti sono: Data Encryption Standard (DES), Triple-DES (3DES), Blowfish, International Data Encryption Algorithm (IDEA), Advanced Encryption Standard (AES), Rivest Cipher #4 e #5 (RC4 e RC5) e Skipjack.

DES
Il National Institute of Standards and Technology (NIST), ex National Bureau of Standards, è una divisione del Dipartimento del Commercio statunitense, strettamente legato alla National Security Agency (NSA) che a sua volta appartiene al mondo militare. All’inizio degli anni ’70, era alla ricerca di un algoritmo di crittografia da adottare come standard. Tra i produttori invitati a proporre soluzioni, IBM presentò il proprio algoritmo Lucifer a 128 bit, utilizzato per le transazioni finanziarie. Lucifer fu accettato, ma la NSA lo modificò riducendone la chiave a 64 bit (di cui 56 bit

IT Administrator Sicurezza informatica Lezione 2

effettivi e 8 usati per il controllo di parità), rinominandolo Data Encryption Standard. Nel 1977 DES divenne lo standard nazionale di crittografia per le informazioni non classificate (ossia non confidenziali). Nel corso degli anni, il NIST ha ricertificato periodicamente DES attraverso i documenti FIPS (Federal Information Processing Standards Publication) 46-1, 46-2 e 46-3, fino alla fase di transizione tra DES e il suo successore AES. DES è l’algoritmo di cifratura più conosciuto ed è stato il primo di cui sono stati forniti tutti i dettagli di implementazione. E’ stato incluso nella maggioranza dei prodotti commerciali dotati di funzionalità crittografiche ed è stato usato dagli enti governativi. Per oltre un decennio, DES è stato considerato uno degli algoritmi più efficaci ed efficienti, finché la NSA smise di supportarlo nel 1988, prevedendo la sua vulnerabilità a fronte della crescita della potenza di calcolo dei computer. Nel 1998 DES fu violato in un attacco di tipo “forza bruta” (test di tutte le possibili chiavi) durato tre giorni, con un computer dotato di 1.536 processori. Tale fatto accelerò il processo di sostituzione di DES con 3DES (tripla applicazione di DES) e con AES. Dal 1999, DES poteva essere usato solo sui sistemi “legacy”, cioè hardware o software antiquato ancora in uso, e nella pratica corrente doveva essere sostituito da 3DES e in seguito da AES.
DES è un algoritmo di crittografia simmetrica a blocchi di 64 bit secondo il modello di Horst Feistel (il crittologo di IBM che l’ha sviluppato), che prevede la divisione del blocco in due metà e una serie di sostituzioni e permutazioni in 16 passaggi con scambi tra i due semiblocchi.

3DES
Saltato il doppio DES (chiave di 112 bit) perché si dimostrò che avesse la stessa efficacia del DES, si passò alla tripla applicazione del DES (112 o 168 bit per le chiavi) prolungando il ciclo di vita di questo particolare sistema di cifratura. 3DES è 256 volte più robusto del DES, ma richiede fino al triplo di tempo per la cifratura e la decifratura. Esistono diverse varianti di 3DES:
- DES-EE3: utilizza tre diverse chiavi di cifratura
- DES-EDE3: usa tre chiavi per cifrare, decifrare e cifrare di nuovo i dati
- DES-EEE2 e DES-EDE2: come sopra, salvo che la prima e la terza operazione utilizzano la stessa chiave.
L’algoritmo alla base di 3DES è lo stesso di DES, l’algoritmo più studiato e collaudato di tutti i tempi. 3DES è molto robusto e affidabile, ma è stato progettato circa 30 anni fa ed è stato concepito per l’implementazione in hardware. A maggior ragione, 3DES è poco efficiente in software e non è considerato una soluzione valida a lunga scadenza, anche se saranno necessari parecchi anni per la sua definitiva sostituzione.

AES
Dopo che il DES era stato usato per oltre 20 anni e si avvicinava il momento del suo “cracking”, il NIST decise che era tempo d’introdurre un nuovo standard di crittografia. La decisione fu annunciata nel 1977, assieme alla richiesta di candidature. Il nuovo standard avrebbe dovuto essere un algoritmo simmetrico a blocchi capace di supportare chiavi di 128, 192 e 256 bit. I finalisti furono MARS di IBM (sviluppato dagli autori di Lucifer), RC6 (di RSA Laboratories), Serpent (di Anderson, Biham e Knudsen), Twofish (di Counterpane Systems) e Rijndael (dei belgi Joan Daemon e Vincent Rijmen). Rijndael (così chiamato dai nomi degli autori) fu stato scelto dal NIST per sostituire il DES. E’ stato pubblicato dal NIST nel 2001 col nome di AES ed è l’algoritmo richiesto per proteggere le informazioni riservate, ma non classificate, del governo statunitense. AES utilizza blocchi di 128 bit, rappresentati sotto forma di matrice; ogni blocco viene cifrato in 10, 12 o 14 passaggi (a seconda della lunghezza della chiave) che comprendono operazioni di sostituzione dei byte, permutazione delle righe della

matrice, sostituzione delle colonne, combinazione XOR dei byte con una matrice (chiave espansa) ottenuta espandendo la chiave dai 128, 192 o 256 bit originari a 176, 208 o
240 byte.
L’attento scrutinio dell’algoritmo Rijndael non ha mostrato punti deboli, tanto che nel 2003 il governo USA ha autorizzato l’uso di AES per la cifratura di documenti classificati fino al livello di secret con chiave di 128 bit e di top secret con chiave di 192 o 256 bit. E’ la prima volta che il pubblico ha accesso ai dettagli di un algoritmo crittografico approvato per informazioni di massima segretezza. Al 2004, sono noti attacchi su 7, 8 e 9 passaggi rispettivamente con chiavi di 128, 192 e 256 bit; qualche crittografo ha espresso dubbi sulla tenuta futura del margine di sicurezza, ma, a meno di sorprese, è previsto che AES risulti sicuro per decenni a venire. AES è utilizzabile senza il pagamento di royalty.

Blowfish
Blowfish è un cifrario simmetrico a blocchi di 64 bit con chiavi di lunghezza fino a 448 bit. Durante la cifratura i dati sono sottoposti a 16 fasi di funzioni crittografiche. Blowfish è un algoritmo molto robusto ed è stato scritto da Bruce Schneier, uno degli autori più citati nel campo della crittografia.

IDEA
IDEA è un cifrario simmetrico a blocchi di 64 bit, suddivisi in 16 sotto-blocchi sottoposti a otto serie di manipolazioni matematiche. IDEA presenta similitudini con DES, ma è molto più robusto. La chiave è lunga 128 bit. IDEA è brevettato ed è concesso in licenza dalla società svizzera Mediacrypt.

RC5
RC5 è un cifrario simmetrico a blocchi dotato di parecchi parametri per assegnare le dimensioni del blocco, la lunghezza della chiave e il numero di passaggi di trasformazione da eseguire. E’ stato creato da Ron Rivest (la R di RSA). Di solito si utilizzano blocchi di 32, 64 o 128 bit e la chiave può raggiungere i 2.048 bit. RC5 è stato brevettato da RSA Security nel 1997. Il basso consumo di memoria lo rendono adatto per smartcard e altri dispositivi simili.

Skipjack
Skipjack è un cifrario a blocchi sviluppato dalla NSA nel 1987, messo in servizio nel 1993 e declassificato nel 1998. Opera su blocchi di 64 bit con una chiave di 80 bit e può

Lezione 2 IT Administrator Sicurezza informatica

 

sfruttare le principali modalità di crittografia a blocchi: ECB, CBC, CFB e OFB. E’ stato fornito in chipset preconfezionati e nella cryptocard Fortezza, una PC Card con processore di cifratura e memoria per i dati da cui costruire le chiavi. Skipjack è un cifrario molto robusto, ma la lunghezza limitata della chiave lo rende inferiore all’AES. Skipjack è utilizzato soprattutto da militari e agenzie governative USA.

RC4
RC4 è il più noto dei cifrari a flusso. E’ stato creato nel 1987 da Ron Rivest per RSA Security. Utilizza un keystream di dimensioni variabili (ma solitamente di 128 bit) e opera su un byte alla volta. In origine il cifrario era segreto, ma fu fatto filtrare su Internet. L’algoritmo è molto robusto se utilizzato con chiavi di lunghezza adeguata (tipicamente 128 bit) casuali e non riutilizzate. Nel 2000 il governo USA ha rimosso la limitazione a 40 bit per l’esportazione dei prodotti con RC4. RC4 è 10 volte più veloce di DES. Due esempi di impiego sono nel protocollo SSL (Secure Sockets Layer) utilizzato dai browser Internet per lo scambio sicuro di informazioni (per esempio nelle transazioni commerciali) e nel protocollo WEP (Wired Equivalent Privacy) che è parte dello standard 802.11 per le LAN wireless.
Crittografia nel PC
Le immagini seguenti mostrano alcuni degli algoritmi di crittografia supportati da Microsoft Outlook e dal browser Opera (su piattaforma Windows) e dal browser Konqueror (su piattaforma SUSE Linux).

Crittografia asimmetrica
Per la maggior parte della storia della crittografia, dall’antichità nota fino a qualche decennio fa, mitten-

te e destinatario dei documenti segreti utilizzavano, per la cifratura e la decifratura, la stessa chiave, concordata in anticipo usando un mezzo di trasmissione non crittografico e custodita al sicuro.
Si è già accennato alle difficoltà di gestione delle chiavi simmetriche e alla proliferazione di chiavi da custodire e distribuire segretamente. Whitfield Diffie e Martin Hellmann, i primi a introdurre pubblicamente i concetti della crittografia a chiave pubblica nel 1976, si posero l’obiettivo di risolvere due dei principali problemi della crittografia simmetrica:
1) la necessità di condividere una chiave, precedentemente distribuita agli interlocutori, o, in alternativa, allestire un centro per la distribuzione delle chiavi (key distribution center) e
2) l’esigenza di associare ai messaggi e documenti cifrati una “firma digitale” equivalente a una firma autografa su carta. Diffie ed Hellmann a Stanford e Merkley a Berkeley unirono le rispettive competenze sulla crittografia a chiave pubblica e sulla distribuzione delle chiavi pubbliche rivoluzionando il mondo della ricerca crittografica, fino ad allora chiuso nelle stanze degli enti militari.
Solo in seguito, sono venute alla luce le vere e segrete origini della crittografia a chiave pubblica: a metà degli anni ’60 presso la National Security Agency NSA (secondo affermazioni del direttore dell’NSA di quel tempo, indirettamente suffragate dall’uso nell’NSA di telefoni basati su crittografia a chiave pubblica) e nel 1973 presso il britannico
Government Communications Headquarters (GCHQ), i cui documenti sono stati rivelati nel 1997 dal Communications-Electronics Security Group (CESG), il braccio del GCHQ per la sicurezza delle informazioni. I documenti di Ellis e Cocks (www.cesg.gov.uk/), in assenza di documentazione dell’NSA, sono quindi i più antichi riguardo la nascita della crittografia asimmetrica. Dopo Ellis e Cocks e Diffie, Hellmann e Merkley, il terzo gruppo chiave per lo sviluppo della crittografia a chiave pubblica è stato Rivest, Shamir e Adleman, autori dell’algoritmo RSA.
La loro ricerca è quasi contemporanea ai lavori di Diffie, Hellmann e Merkley (ma basata su un diverso principio matematico) e costituisce un ulteriore passo in avanti, perché include l’implementazione della firma digitale. Oggi RSA è la sigla più spesso associata alla nozione di crittografia a chiave pubblica, ma in molte applicazioni sono utilizzate le tecnologie derivate dallo scambio chiavi di Diffie-Hellmann.
La crittografia asimmetrica, ossia a chiave pubblica, fa uso di due chiavi diverse per cifrare e decifrare i messaggi o documenti. Con un sistema di crittografia a chiave pubblica, gli utenti possono comunicare in modo sicuro attraverso un canale insicuro senza dover concordare in anticipo una chiave. Un algoritmo asimmetrico prevede che ogni utente abbia una coppia di chiavi: la chiave pubblica e la chiave privata, in relazione tra loro, ma tali che non si possa ricavare l’una dall’altra. La chiave privata dev’essere custodita al sicuro dal proprietario, mentre la chiave pubblica può essere distribuita senza restrizioni, a patto che sia autenticata. La proprietà fondamentale di un algoritmo asimmetrico è che si può cifrare un messaggio con una qualsiasi delle due chiavi, dopo di che si deve utilizzare l’altra chiave per decifrarlo.
Se Alessandro vuole spedire a Bruno un documento riservato, deve procurarsi una copia autenticata della chiave pubblica di Bruno (in pratica un certificato digitale di Bruno) e con essa cifrare il messaggio. Bruno utilizza la propria chiave privata per decifrare

IT Administrator Sicurezza informatica Lezione 2

il messaggio e ricostruire il documento originale. Il messaggio rimane riservato, ma non si può essere certi della sua autenticità, ossia che sia stato spedito da Alessandro.
Se Alessandro vuole inviare a Bruno un documento

 

in modo da garantirne l’autenticità e l’integrità, lo cifra con la propria chiave privata, dopo di che Bruno (ma anche chiunque altro) lo decifra con la chiave pubblica di Alessandro. In questo caso manca la riservatezza.
Per assicurare riservatezza, autenticità e integrità,

Alessandro potrebbe utilizzare una doppia cifratura, con la propria chiave privata e con la chiave pubblica di Bruno. Questi tre scenari sono puramente didattici; in pratica, vedremo che esistono metodi più efficienti e che la crittografia asimmetrica non è usata per cifrare l’intero contenuto dei messaggi.
Torniamo al primo esempio, in cui Alessandro invia un messaggio cifrato con la chiave pubblica di Bruno. Un modo per autenticare il messaggio, dimostrando la propria identità, è quello di allegare un certificato digitale, ovvero un oggetto che associa la chiave pubblica al suo proprietario, eliminando il sospetto che il mittente sia un impostore. Un certificato digitale è rilasciato da un’autorità di certificazione (CA, Certification Authority), uno degli elementi che compongono un’infrastruttura a chiave pubblica (PKI, Public Key Infrastructure, un sistema per la creazione e gestione delle chiavi pubbliche). Il certificato garantisce dell’identità del possessore della chiave pubblica: la coppia di chiavi viene tipicamente generata sul computer dell’utente e presso la CA viene conservata la sola chiave pubblica e il certificato che la CA ha generato sulla base di questa.
Il certificato digitale contiene varie informazioni più la chiave pubblica del suo proprietario, ed è firmato dall’autorità che lo emette per attestare la validità del certificato e del certificatore.
Un’alternativa all’uso dei certificati emessi da una CA è l’utilizzo di PGP (Pretty Good Privacy), un metodo ampiamente diffuso per cifrare messaggi e documenti tramite una coppia di chiavi che chiunque può generare, senza certificazione o con un certificato firmato, non da una Certification Authority, bensì da altri utenti fidati che formano una rete di fiducia.
Il metodo dei certificati si basa su una struttura organizzata e comporta oneri in base alle funzionalità e modalità d’impiego.
Thawte è l’unica CA che fornisce certificati gratuiti di durata annuale per uso personale, da usare per firmare e cifrare la posta elettronica. L’uso di PGP e delle sue varianti (come vedremo in seguito) è invece più libero e informale e ha forme d’implementazione gratuite.
I cifrari asimmetrici hanno prestazioni bassissime, inferiori a quelle dei cifrari simmetrici per vari ordini di grandezza (RSA è mille volte più lento di DES). Perciò, di solito, non sono utilizzati per cifrare interi messaggi e documenti, bensì per cifrare una chiave di sessione, che a sua volta viene utilizzata per cifrare il messaggio con un cifrario simmetrico. Una chiave di sessione è una chiave temporanea “usa e getta”, creata al momento e distrutta alla fine della sessione, per esempio dopo l’invio di un messaggio e-mail cifrato o alla fine di una transazione Internet con SSL (Secure Sockets Layer – il protocollo standard per transazioni sicure su Internet).
In questo scenario ibrido, che vede l’uso contemporaneo di cifrari simmetrici e asimmetrici, s’innesta un altro dei mattoni fondamentali delle applicazioni crittografiche, cioè le funzioni di hash. Una funzione di hash riceve in input un messaggio o un blocco di dati di lunghezza variabile e fornisce come risultato un valore di lunghezza fissa chiamato codice di hash (hash code o semplicemente hash) o anche message digest o hash digest.
Una tale funzione è progettata in modo che a un dato input corrisponda sempre lo stesso output e che sia minima la probabilità che input diversi generino lo stesso output (collisione). Un hash rappresenta una “impronta informatica” (fingerprint) del messaggio o documento su cui è calcolato e serve a verificare l’integrità dei dati: qualunque alterazione ai dati causa

Lezione 2 IT Administrator Sicurezza informatica

 

un’alterazione dell’hash. Una funzione di hash può essere vista come una funzione di compressione o di cifratura a senso unico, perché non c’è modo di risali re dall’hash ai dati di partenza.
Standard di crittografia asimmetrica
Ci sono parecchi algoritmi di crittografia asimmetrica, ma quelli più noti, sicuri e utilizzati sono il citato RSA e quelli derivati dalla ricerca di Diffie e Hellmann, tra cui ElGamal e DSA.
RSA, dell’omonima azienda, è il cifrario asimmetrico più utilizzato. Può essere usato sia per la cifratura (per ottenere la riservatezza), sia per la firma digitale (per ottenere l’autenticazione), sia per lo scambio delle chiavi (come nell’esempio di cui sopra). Secondo RSA, una chiave asimmetrica di 1.024 bit equivale, in robustezza, a una chiave simmetrica di 80 bit (una lunghezza oggi relativamente limitata), mentre chiavi di
2.048 e 3.072 bit equivalgono a chiavi simmetriche di 112 e 128 bit. RSA raccomanda di utilizzare almeno
1.24 bit fino al 2.010, mentre 2.048 bit dovrebbero essere adeguati fino al 2.030, per poi passare a 3.072 bit. Secondo il NIST (National Institute of Standards and Technology), una chiave RSA di 15.360 bit equivale a una chiave simmetrica di 256 bit. In pratica, per chiavi importanti che si prevede di usare per molti anni, conviene passare a 2.048 bit, come già s’inizia a vedere per le chiavi di firma dei certificati digitali.
Gli algoritmi asimmetrici si basano su calcoli matematici facili da eseguire in una direzione, ma molto difficili, o pressoché impossibili da eseguire nella direzione inversa. RSA si basa sulla difficoltà di scompor-

re in fattori il prodotto di due numeri primi di grandi dimensioni. La soluzione di Diffie ed Hellmann si basa invece sul cosiddetto problema del logaritmo discreto, ovvero della difficoltà di risalire alla x nell’equazione gx = y mod p. La notazione y mod p (y modulo p) indica il resto della divisione y/p. Il metodo Diffie-Hellmann è utilizzato per lo scambio delle chiavi, dove i due interlocutori si scambiano le chiavi pubbliche e, con le proprie chiavi private, costruiscono una chiave segreta condivisa. L’algoritmo ElGamal, dal nome del suo inventore, sfrutta anch’esso il problema del logaritmo discreto, dove x è la chiave privata e p, g e y formano la chiave pubblica. ElGamal può essere usato sia per la cifratura sia per l’autenticazione con firma digitale. E’ un algoritmo sicuro e ha la caratteristica di generare un testo cifrato lungo il doppio del testo in chiaro.
Una variante dell’algoritmo ElGamal è il DSA, o Digital Signature Algorithm, sviluppato dalla NSA e pubblicato dal NIST (National Institute of Standards and Technology) e diventato uno standard del governo USA. DSA ha una chiave pubblica e una privata, ma viene usato solo per la firma dei documenti, non per la cifratura. DSA richiede l’uso dell’algoritmo di hash SHA (Secure Hash Algorithm), uno standard FIPS (Federal Information Processing Standard) statunitense. SHA genera un digest di 160 bit che viene passato a DSA o a un altro degli algoritmi di firma digitale ammessi dal governo USA (RSA ed ECDSA, Elliptic Curve Digital Signature Algorithm). Lo standard federale americano per la firma elettronica si chiama DSS (Digital Signature Standard), di cui DSA è l’algoritmo di firma e SHA è l’algoritmo di hash.
A parità di lunghezza di chiave, RSA e DSA hanno sicurezza comparabile.
Se il problema del logaritmo discreto e la fattorizzazione del prodotto di numeri primi sono i due metodi matematici alla base dei cifrari asimmetrici più diffusi, la recente crittografia a curve ellittiche (ECC) si rivela promettente in termini di efficienza, con chiavi molto più corte. Una chiave ECC di 163 bit equivale a una chiave RSA di 1024 bit. Le curve ellittiche sono una branca della teoria dei numeri e sono definite da certe equazioni cubiche (di terzo grado); le loro proprietà permettono di creare algoritmi crittografici asimmetrici, vista l’estrema difficoltà di eseguire i calcoli a ritroso per ricostruire la chiave privata dalla chiave pubblica e dalle condizioni iniziali. Un esempio di utilizzo dell’ECC è nella ECDSA, una variante più efficiente del DSA basata sulle curve ellittiche.

Riferimenti bibliografici:
Handbook of Applied Cryptography, A. Menezes, P. van Oorschot, S. Vanstone, 1996.
Scaricabile in Pdf da www.cacr.math.uwaterloo.ca/hac Applied Cryptography, Bruce Schneier, Second Edition, 1996
Cryptography and Network Security, William Stallings, Third Edition, 2002
Internet Cryptography, Richard Smith, 1997

Funzioni di hash e digest
Un hash è un numero binario di lunghezza fissa, ricavato da un input (file, messaggio, blocco di dati ec-

IT Administrator Sicurezza informatica Lezione 2
sa (simmetrica).
Il messaggio viene spedito con il MAC aggiunto in coda. Il destinatario separa il MAC dai dati, aggiunge la chiave segreta e ricalcola il MAC. Se i due MAC coincidono, il destinatario sa che i dati sono integri. L’uso del MAC permette la verifica dell’integrità solo a chi è in possesso della chiave segreta. Inoltre, se qualcuno modificasse il messaggio, non potrebbe ricalcolarne il MAC senza avere la chiave segreta, quindi la modifica verrebbe scoperta.
Questa tecnica viene chiamata keyed hashing (hashing con chiave).

 

Un esempio d’uso delle funzioni di hash è nel calcolo di un Message Authentication Code, che consente al destinatario di verificare la sola integrità dei dati ricevuti. I dati vengono trasmessi in chiaro in abbinamento a un MAC (MD5, SHA-1 o
successivi) che è stato calcolato unendo il messaggio e la chiave segreta

 

È possibile utilizzare il MAC in abbinamento alla cifratura per garantire sia la riservatezza sia l’integrità del messaggio. L’approccio è duplice
1) si cifra il messaggio con la chiave segreta e quindi si aggiunge l’hash o digest calcolato con la stessa chiave, oppure si calcola l’hash sul messaggio in chiaro e poi si cifra messaggio più hash con la chiave
segreta

 

cetera) di lunghezza variabile, che funge da “impronta” del dato di partenza. L’analogia con l’impronta digitale è pertinente, perché è compatta, può essere facilmente archiviata, trasmessa ed elaborata elettronicamente e consente d’identificare un individuo senza che da essa si possa risalire alle caratteristiche fisiche della persona.
In modo simile, sottoponendo un documento elettronico a un algoritmo di hash, si ottiene un dato di piccole dimensioni (tipicamente 128 o 160 bit) che identifica il documento senza permettere di risalire al suo contenuto. Il codice di hash risultante dall’applicazione di una funzione di hash a un documento, viene chiamato hash, digest o impronta informatica del documento.
Per essere efficace, un algoritmo di hash deve soddisfare i seguenti requisiti:
- può essere applicato a dati di qualunque dimensione
- produce un risultato di lunghezza fissa
- il codice di hash è relativamente facile da calcolare per qualsiasi input, rendendone pratica l’implementazione hardware e software
- per qualsiasi codice di hash h, non è praticamente possibile trovare un dato di input tale per cui l’algoritmo produca h come risultato (l’algoritmo è cioè a senso unico)
- per qualunque dato di input x, non è praticamente possibile trovare un dato y diverso da x per cui l’algoritmo produca lo stesso codice di hash (resistenza debole alle collisioni)
- è praticamente impossibile trovare una coppia di dati (x, y) tale per cui l’algoritmo produca lo stesso codice di hash quando è applicato a x e a y (resistenza forte alle collisioni)
- come corollario, la modifica di qualsiasi bit del dato di input produce una modifica del codice di hash; anche la trasposizione di due bit, che non modificherebbe una checksum (somma di controllo) per il controllo di parità, modifica il valore dell’hash.
L’espressione “non è praticamente possibile” significa che non è computazionalmente fattibile con le tecnologie correnti e con quelle prevedibili nei prossimi anni.
Un esempio di applicazione consiste nel calcolare l’hash di un messaggio e inviarlo, cifrato insieme al messaggio, in modo che il destinatario, ricalcolando l’hash dei dati con lo stesso algoritmo di hashing, possa verificare l’integrità dei dati ricevuti. Inoltre, se l’hash è stato cifrato con la chiave privata del mittente, la verifica (decifratura dell’hash tramite chiave pubblica del mittente e confronto con l’hash ricalcolato sul messaggio ricevuto) serve anche per stabilire l’autenticità del mittente.
Un altro esempio di utilizzo è offerto dai Message Authentication Code (MAC), calcolati come hash del messaggio con aggiunta di una chiave segreta condivi-

Il MAC assicura che il messaggio non è stato alterato e che proviene dal mittente dichiarato (nessun altro possiede la chiave segreta) si tratta quindi di un’autenticazione indiretta e non forte (visto che la chiave è nel possesso di due persone e perciò non è possibile stabilire con assoluta certezza quale delle due abbia generato il messaggio e il relativo hash). Inoltre, se il messaggio include un numero di sequenza, il destinatario ha anche la certezza che la sequenza non sia stata alterata.

Un MAC può essere usato per l’autenticazione del messaggio (come nell’esempio) o per l’autenticazione e la riservatezza (tramite cifratura). Quest’ultima può essere realizzata calcolando il MAC sul messaggio in chiaro più la chiave e poi cifrando il messaggio più il MAC generato prima usando la medesima chiave, oppure, viceversa, cifrando prima il messaggio e successivamente calcolando il MAC su messaggio già cifrato

Lezione 2 IT Administrator Sicurezza informatica

più la chiave.
Il keyed hashing può essere usato anche per fornire l’autenticazione a un messaggio di tipo stream (flusso continuo), dividendo lo stream in blocchi e calcolando il MAC di ogni blocco. I MAC diventano parte dello stream e servono per verificare l’integrità dei dati ricevuti. L’uso degli hash è molto più rapido rispetto alla generazione delle firme digitali, un altro campo di applicazione delle funzioni di hash.
Un tipo speciale di MAC è chiamato HMAC ed è specificato nella RFC 2104. HMAC è anch’essa una funzione keyed hash, ma in realtà costituisce un keyed hash all’interno di un keyed hash.
Può utilizzare qualsiasi algoritmo di hash, come SHA e MD5, prendendo il nome di HMAC-SHA o HMAC-MD5. HMAC, dal punto di vista crittografico, è più robusto della sola funzione di hash di base, come è stato dimostrato da un attacco riuscito contro MD5 (una collisione creata trovando due input che producono lo stesso hash), mentre HMAC-MD5 non è stato vulnerabile a tale attacco.
Indicando con H l’algoritmo di hash utilizzato, M il messaggio e K la chiave, la funzione HMAC è definita come:

HMAC (K, M) = H (K XOR opad, H (K XOR ipad, M))

dove ipad è un array di 64 elementi di valore 0x36 (36 in esadecimale) e opad è un array di 64 elementi di valore 0x5C.
Tutta l’autenticazione dei messaggi in IPSEC (una famiglia di protocolli utilizzata per trasmissioni sicure su Internet) avviene tramite HMAC.
Principali algoritmi di hash
Fra i numerosi algoritmi di hash riportati in letteratura, tre sono quelli più utilizzati per le loro caratteristiche di efficienza e sicurezza: MD5, SHA-1 e RIPEMD160.

MD5, evoluzione di MD4, è stato sviluppato da Ron Rivest all’MIT nel 1991 ed è descritto nella RFC 1321 (www.ietf.org/rfc).
MD5 è molto popolare, ma la crescita della potenza di calcolo e i primi successi degli attacchi sia basati su forza bruta sia di tipo crittoanalitico (basati sull’analisi dell’algoritmo) inducono a considerare MD5 vulnerabile e hanno suggerito lo sviluppo di nuovi algoritmi con un output più lungo dei 128 bit di MD5 e con caratteristiche specifiche per resistere agli attacchi crittoanalitici.

SHA-1 è stato sviluppato dal NIST ed è stato pubblicato come standard federale USA nel 1993 con il nome di Secure Hash Algorithm (SHA, FIPS 180) e riveduto nel 1995 come SHA-1 (FIPS180-1). SHA-1 è specificato anche nella RFC 3174 che, rispetto al FIPS 180-1, include anche un’implementazione in C.
SHA-1 riceve in input un messaggio di lunghezza massima inferiore a 264 bit (una dimensione equivalente a 2.147 Gbyte e perciò praticamente illimitata), suddiviso in blocchi di 512 bit, e produce un hash di 160 bit. Sia SHA-1 sia MD5 derivano da MD4, ma SHA-1 è notevolmente più robusto grazie ai 32 bit aggiuntivi dell’hash, che rendono molto più arduo un attacco di tipo forza bruta. Sul fronte degli attacchi crittoanalitici, MD5 ha iniziato a mostrarsi vulnerabile fin dai primi anni di vita, mentre SHA-1 non risulta vulnerabile allo stesso tipo di attacchi.
Nel frattempo sono state specificate le evoluzioni di SHA-1 a 224 bit (RFC 3874) e a 256, 384 e 512 bit di hash, talvolta chiamate ufficiosamente SHA-2 e annun-

ciate dal FIPS 180-2. I rispettivi standard si chiamano SHA-224, SHA-256, SHA-384 e SHA-512.

RIPEMD-160 è stato sviluppato nell’ambito del progetto European RACE Integrity Primitives Evaluation (RIPE) da un gruppo di ricercatori che avevano conseguito parziali successi nell’attaccare MD4 e MD5.
Inizialmente gli autori svilupparono una versione a 128 bit, ma visto che era possibile attaccare due fasi di elaborazione, decisero di espanderla a 160 bit. L’algoritmo è descritto nella norma ISO/IEC 10118-3:1998 “Information technology Security techniques Hash functions Part 3: Dedicated hash-functions” (ISO, 1998).
Anche RIPEMD-160 deriva da MD4 e ha molte analogie con MD5 e SHA-1. Alla pari di SHA-1, è molto resistente ad attacchi di vario tipo; l’ulteriore complessità rispetto a SHA-1 dovrebbe rendere RIPEMD-160 ancora più protetto da attacchi crittoanalitici, benché più lento in esecuzione.

Glossario di crittografia
Algoritmo (o cifrario):
un insieme di regole logiche e matematiche usate nella cifratura e nella decifratura.

Chiave: la sequenza segreta di bit che governa l’atto della cifratura o della decifratura.

Crittografia:
la scienza della scrittura nascosta (o segreta) che permette di memorizzare e trasmettere dati in una forma utilizzabile solo dagli individui a cui essi sono destinati.

Crittosistema:
l’implementazione hardware o software della crittografia, che trasforma un messaggio in chiaro (plaintext) in un messaggio cifrato (ciphertext) e poi di nuovo nel messaggio in chiaro originario.

Crittoanalisi:
la pratica di ottenere il messaggio in chiaro dal messaggio cifrato senza disporre della chiave o senza scoprire il sistema di cifratura.

Crittologia:
lo studio della crittografia e della crittoanalisi.

Testo cifrato (ciphertext):
dati in forma cifrata o illeggibile.

Cifrare o cifratura:
l’azione di trasformare i dati in formato illeggibile.

Decifrare o decifratura:
l’azione di trasformare i dati in formato leggibile.

Keyspace (spazio delle chiavi):
l’insieme di tutti i possibili valori che una chiave può assumere.

Testo in chiaro (plaintext o cleartext):
dati in forma leggibile o intelligibile.

Work factor (fattore di lavoro):
il tempo, lo sforzo e le risorse che si stimano necessari per violare un crittosistema.

IT Administrator Sicurezza informatica Lezione 2
Applicazioni della crittografia
Firma elettronica e certificati digitali per
le operazioni elettroniche
Applicazioni pratiche delle più moderne tecniche di crittografia e dei protocolli che regolano le transazioni on-line. La lezione, oltre a essere un requisito per il conseguimento della certificazione ufficiale EUCIP IT Administrator – Sicurezza Informatica, valida in tutta Europa, spiega come condurre operazioni sicure mediante il PC garantendo riservatezza, integrità e autenticità dei documenti e delle persone in gioco, oltre che il non ripudio delle decisioni concordate. I contenuti si articolano in quattro elementi: un articolo sintetico
sulla rivista che riepiloga solo i concetti essenziali, l’articolo completo in formato PDF e un corso multimediale completo su CD e DVD di Giorgio Gobbi

iassumiamo i principali caratteri distintivi dei due modelli di crittografia. Nella prima parte della lezione 2 abbiamo visto in dettaglio le differenze tra crittogra-
fia simmetrica (a chiave segreta) e crittografia asimmetrica (a chiave pubblica e privata). Rivediamoli brevemente. Simmetrica: 1) migliori prestazioni, 2) adatta per cifrare messaggi lunghi, 3) chiavi brevi, 4) pone il problema della distribuzione delle chiavi, 5) facile uso con PRGN (PseudoRandom Number Generator) e funzioni di hash, 6) utilizzabili come componenti di uno schema ad alta sicurezza, 7)
lunga storia, 8) tecnologia collaudata
Asimmetrica: 1) chiavi molto lunghe, 2) cattive prestazioni, 3) adatta per cifrare dati brevi, 4) risolve il problema della distribuzione delle chiavi, 5) la chiave può essere autenticata; 6) le chiavi pubbliche possono essere accessibili pubblicamente, presso terze parti fidate, 7) vita più lunga delle chiavi, 8) utilizzabile per la firma digitale, 9) storia breve (anni ’70)
PRNG significa Pseudo-Random Number Generator (generatore di numeri pseudo-casuali), una funzione che tra i vari impieghi include la generazione di chiavi simmetriche di sessione.
Per la lunghezza delle chiavi, Schneier, in Applied Cryptography (scritto nel 1995), raccomandava almeno 112 bit per le chiavi simmetriche (come nel 3DES a due chiavi) e prevedeva, per il periodo 2005-2010, la necessità di usare chiavi asimmetriche lunghe 1.280, 1.536 o 2.048 bit rispet-

tivamente per utilizzo personale, aziendale o governativo. Secondo le linee guida del NIST (Key Management Guideline, novembre 2001), una chiave 3DES di 112 bit ha la robustezza di una chiave RSA di 2.048 bit, mentre una chiave AES di 256 bit equivale a una chiave RSA di 15.360 bit.
Vantaggi della crittografia simmetrica
utilizza algoritmi molto veloci, che possono cifrare/decifrare grandi quantità di dati per secondo, dell’ordine delle centinaia di MByte al secondo.

Lezione 2 IT Administrator Sicurezza informatica

- può cifrare e decifrare messaggi e documenti di lunghezza illimitata
- le chiavi utilizzate sono relativamente brevi; AES, per esempio, utilizza chiavi di 128, 192 o 256 bit (la scelta della lunghezza della chiave dipende dai requisiti di sicurezza presente e futura)
- gli algoritmi a chiave simmetrica possono essere integrati nella realizzazione di schemi di cifratura più complessi, insieme a funzioni hash e a generatori PRNG
- più algoritmi simmetrici, non abbastanza robusti se utilizzati singolarmente, possono essere combinati per ottenere schemi di cifratura di notevole robustezza (come nel caso di 3DES costruito utilizzando l’ormai superato DES)
- la crittografia simmetrica si è sviluppata in un lungo arco di tempo e utilizza meccanismi ben studiati e collaudati.
Vantaggi della crittografia asimmetrica
- un utente deve conservare solo una chiave privata, mentre la chiave pubblica è resa disponibile a tutti (anche se richiede l’onere della certificazione per essere ritenuta autentica)
- per la gestione delle chiavi sulla rete è sufficiente la presenza di una CA (Autorità di certificazione) affidabile, ma non necessariamente sempre online
- la coppia chiave privata/chiave pubblica può restare invariata per lunghi periodi di tempo (anche anni, se il tipo d’impiego non è critico)
- in una rete di grandi dimensioni, è necessario un numero di chiavi limitato (proporzionale al numero di utenti, anziché in relazione quadratica come nel caso di chiavi simmetriche)
Problemi della crittografia simmetrica
- la chiave usata per la cifratura e decifratura da una coppia di interlocutori deve restare segreta ed essere cambiata di frequente; la soluzione migliore è la generazione di una chiave casuale per ogni sessione di comunicazione abbinata a uno dei meccanismi di scambio sicuro delle chiavi
- in una rete con N utenti, a meno che si usino chiavi di sessione, il numero di chiavi simmetriche è pari a N(N-1)/2; se gestite da una terza parte fidata, ne farebbero il punto debole del sistema
I due interlocutori devono avere un canale sicuro per scambiarsi la chiave segreta; una soluzione efficace utilizza i meccanismi di scambio delle chiavi che hanno dato vita alla crittografia asimmetrica (vedi l’esempio alla sezione
5.2.3.1 Principi di crittografia asimmetrica).
Problemi della crittografia asimmetrica
- richiede una modalità di autenticazione delle chiavi pubbliche
- gli algoritmi di cifratura sono lenti (tipicamente mille volte più lenti rispetto ai simmetrici)
- è applicabile a dati di breve lunghezza (inferiore alla lunghezza della chiave)
- le chiavi asimmetriche sono di lunghezza decisamente maggiore rispetto alle chiavi simmetriche (non meno di
1.024 bit)
- nessun metodo utilizzato dagli algoritmi asimmetrici (come la fattorizzazione del prodotto di numeri primi o il calcolo del logaritmo discreto) è stato matematicamente dimostrato essere sicuro; la loro sicurezza si basa sull’estrema difficoltà, con i mezzi correnti, di risolvere determinati problemi della teoria dei numeri
- nel 2003 l’ufficio federale tedesco per la sicurezza informatica ha violato il metodo di fattorizzazione alla base di RSA per numeri di 174 cifre decimali, corrispondenti a RSA-576; la crescita della lunghezza delle chiavi potrebbe dover essere più rapida del previsto, dopo che il matematico Bernstein, con il suo articolo “Circuits for Integer Factorization” del 2001, ha scosso la fiducia nel sistema di cifratura/decifratuira di RSA e ha teorizzato la vulnerabi-

lità delle chiavi di 1.536 bit (mentre la maggior parte dei sistemi, come HTTPS, SSH, IPSec, S/MIME e PGP utilizzano RSA con chiavi di lunghezza limitata)
Livelli di sicurezza
Dato che non esiste un singolo algoritmo di crittografia ideale per tutte le occasioni, si dovranno considerare diversi fattori nell’operare la scelta dell’algoritmo, o più spesso della combinazione di algoritmi, da utilizzare per una certa applicazione. Alcuni criteri di base sono i seguenti:
- stima del livello di affidabilità sulla base degli anni di utilizzo, dell’analisi di robustezza, degli attacchi subiti, valutando anche la presumibile durata futura
- dimensione della chiave in base alle esigenze di sicurezza e alla progressiva estensione della chiave, negli anni, per preservare la robustezza di un algoritmo
- efficienza di calcolo e consumo di risorse in relazione alle piattaforme hardware/software da utilizzare.
Come anche citato in precedenza, la dimensione della chiave gioca un ruolo fondamentale, riassumibile in due aspetti:
- nella crittografia simmetrica, DES (con chiave di 56 bit) e a maggior ragione gli algoritmi a 40 bit sono da considerare obsoleti perché non sicuri e violabili con comuni computer; è necessario utilizzare 3DES o algoritmi con chiave di almeno 128 bit, come AES
- nella crittografia asimmetrica, chiavi inferiori a 1.024 bit non offrono più garanzie sufficienti; sono adeguate le chiavi di 1.024 bit per uso personale e durata annuale (comuni nei certificati digitali usati per la posta elettronica) e le chiavi di 2.048 bit per uso più generale e durata pluriennale.
Sulle categorie di attacco, sui livelli di sicurezza necessari per le categorie di utenza (privata, business, governativa, eccetera), sulla longevità e robustezza degli algoritmi e sulla crescita delle chiavi col passare degli anni, si trova abbondante documentazione, per esempio presso i siti di NIST e di SANS Institute. Mostriamo due tabelle, una sulla robustezza equivalente delle chiavi tra diversi algoritmi e l’altra su algoritmi raccomandati e lunghezza minima delle chiavi, tratte dalla versione 2003 del citato Key Management Guideline di NIST, Parte 1 (http://csrc.nist.gov/CryptoToolkit/KeyMgmt.html)

 

L’articolo “A Discussion of the Importance of Key Length in Symmetric and Asymmetric Cryptography” di SANS (http://www.giac.org/practical/gsec/Lorraine_Williams_GS EC.pdf) passa in rassegna diverse fonti d’informazione sulla lunghezza delle chiavi e include tra l’altro due tabelle: una stima del 1997 sulla lunghezza delle chiavi in funzione dei tipi di attacco e una stima sulla lunghezza minima delle chiavi pubblicata da Schneier nel suo classico “Applied

 

5.2.5.2 Saper distinguere tra i diversi livelli di sicurezza e il relativo peso

Una mappa della robustezza delle chiavi secondo i valori di equivalenza calcolati dal NIST

IT Administrator Sicurezza informatica Lezione 2

Algoritmi raccomandati in funzione della lunghezza minima delle chiavi.

Una stima, ottimistica, della robustezza dei vari tipi di chiave in funzione dell’attacco subito pubblicata da SANS (SysAdmin, Audit, Network, Security Institute ) nel 1997

 

Una stima sulla lunghezza minima delle chiavi pubblicata da Schneier nel 1996

 

5.2.5.3 Conoscere i problemi di distribuzione delle chiavi nella crittografia simmetrica e asimmetrica

 

Cryptography” del 1996. Un decennio di sviluppi hardware e software, di evoluzioni concettuali e di attacchi andati a buon fine oltre le previsioni, suggeriscono stime leggermente meno ottimistiche e il frequente aggiornamento del rapporto tra livelli di sicurezza e algoritmi e lunghezza delle chiavi. La prima tabella si riferisce a chiavi asimmetriche, la seconda a chiavi simmetriche; entrambe sono ottimistiche sulla distanza.

Distribuzione delle chiavi
Nei capitoli precedenti abbiamo citato i problemi connessi con la trasmissione e lo scambio di chiavi, derivanti dalla necessità di mantenere segrete le chiavi simmetriche e di assicurare l’integrità e l’autenticità dei dati trasmessi. Vediamo in sintesi gli argomenti principali.
Distribuzione delle chiavi simmetriche
Per utilizzare la crittografia simmetrica, i due interlocutori devono disporre della stessa chiave, che deve restare segreta per chiunque altro. Inoltre, per limitare i danni potenziali di una chiave compromessa, la chiave segreta dovrebbe essere sostituita di frequente. Ne consegue che, per quanto sia robusto il cifrario utilizzato, la sicurezza di un sistema crittografico simmetrico dipende dalla tecnica di distribuzione delle chiavi, ossia dai modi di consegnare una chiave a due interlocutori A e B senza che altri la possano vedere.
Vediamo alcuni approcci:
1) A sceglie una chiave e la consegna fisicamente a B
2) Una terza parte fidata sceglie una chiave e la consegna fisicamente ad A e B
3) Se A e B hanno già usato una chiave di recente, uno di loro trasmette all’altro la nuova chiave cifrata con quella vecchia
4) Se A e B hanno una connessione cifrata con una terza parte C, questa può consegnare una chiave ad A e B at-

traverso i collegamenti cifrati
Le soluzioni 1 e 2 sono praticabili solo nel caso di due interlocutori che utilizzano un dispositivo di cifratura per cifrare il collegamento (tutto ciò che passa sulla linea), ma non sono applicabili a trasmissioni da un punto all’altro di un sistema distribuito. In una rete, la scala del problema dipende dal numero di punti terminali in comunicazione. Se la cifratura è applicata allo strato 3 di rete, vale a dire al protocollo IP (considerando il modello OSI oppure il modello TCP/IP) e ci sono N host (computer collegati alla rete), il numero di chiavi necessarie è N(N-1)/2. Se la cifratura viene eseguita a livello applicativo, serve una chiave per ogni coppia di utenti o processi in comunicazione, il che ci porta a un ordine di grandezza superiore al numero di host. Una rete con 1.000 nodi e cifratura a livello di nodo avrebbe bisogno di distribuire mezzo milioni di chiavi, ma se la stessa rete avesse 10.000 applicazioni in funzione, ciascuna con la propria cifratura delle comunicazioni, le chiavi da distribuire sarebbero dell’ordine dei 50 milioni.
La soluzione 3 è praticabile sia a livello di collegamento (link) sia tra i punti di una rete, ma se un nemico si procura una chiave, avrà scoperto tutte le chiavi successive. Per la cifratura tra punti di una rete, la soluzione 4 è la più utilizzata. Si basa su un Key Distribution Center (KDC, centro di distribuzione delle chiavi) che, quando necessario, distribuisce una chiave a una coppia di utenti (host, processi o applicazioni). Ogni utente condivide con il KDC una chiave segreta usata per la distribuzione delle chiavi.
Quando A vuole stabilire una connessione logica con B, invia al KDC la richiesta di una chiave simmetrica temporanea (chiave di sessione) da usare nella comunicazione con B e, per identificare la richiesta in modo univoco (a scopo di sicurezza), include nonce, ovvero un numero casuale, progressivo o segnatempo, sempre diverso per ogni richiesta. Il KDC risponde inviando ad A un messaggio cifrato con la chiave condivisa tra A e il KDC. Questo messaggio contiene:
1) la chiave di sessione da usare tra A e B
2) il messaggio originale con il nonce per abbinare la risposta alla richiesta
3) una parte destinata a B e cifrata con la chiave che B condivide col KDC, contenente la chiave di sessione e un identificatore di A (per esempio il suo indirizzo di rete). Tali contenuti proteggono la riservatezza, l’integrità e l’autenticazione dei dati. A memorizza la chiave di sessione e inoltra a B la chiave di sessione e il proprio identificatore cifrati con la chiave di B, che solo il KDC potrebbe aver confezionato. B usa la chiave di sessione per inviare ad A un nonce di propria scelta. A, sempre usando la chiave di sessione, risponde a B con qualche tipo di trasformazione concordata del nonce, che mostra a B che il messaggio è autentico e non una ripetizione usata per trarlo in inganno.
Questa è la traccia di base, soggetta a varianti ed evoluzioni (per esempio la gerarchia di KDC e la distribuzione decentralizzata delle chiavi) per adattarsi alle diverse applicazioni.
Distribuzione delle chiavi asimmetriche
Consideriamo, per prima cosa, la distribuzione delle chiavi pubbliche, visto che la chiave privata deve essere custodita al sicuro sul computer della persona a cui appartiene. La maggior parte delle tecniche di distribuzione rientra in questi quattro schemi:
1) Annuncio pubblico
2) Directory di pubblico accesso
3) Autorità per le chiavi pubbliche
4) Certificati di chiave pubblica.
Nel caso 1, i partecipanti possono inviare ad altri la chiave, farne il broadcast (totale diffusione) in una comunità, pubblicare la chiave su una mailing list, su un newsgroup o su un sito. Il punto debole fondamentale di tale approc-

Lezione 2 IT Administrator Sicurezza informatica

cio è che chiunque può fingere di essere l’utente A e inviare o pubblicare una chiave pubblica. Prima che A se ne accorga e avvisi gli interessati, l’impostore avrà letto i messaggi cifrati destinati ad A e avrà usato le chiavi fasulle per l’autenticazione.
Il caso 2 consiste nell’affidare la manutenzione e distribuzione delle chiavi pubbliche a una terza parte fidata. Questa entità mantiene una directory con una voce (nome e chiave pubblica) per ogni partecipante. Ogni partecipante registra la sua chiave pubblica di persona o attraverso una comunicazione autenticata; quando lo desidera, può sostituire la chiave (per esempio dopo un certo periodo d’uso o perché la chiave privata è stata compromessa). La directory può essere aggiornata e pubblicata periodicamente anche su media off-line. I partecipanti possono accedere alla directory solo attraverso comunicazioni autenticate dal gestore. Lo schema 2 è più sicuro del caso 1, ma se un nemico riesce a procurarsi la chiave privata del gestore della directory, può iniziare a far circolare false chiavi pubbliche, a impersonare qualunque partecipante (impostura) e a intercettare i messaggi diretti ai partecipanti. Lo stesso scopo può essere raggiunto attraverso un’intrusione che riesca ad accedere alle registrazioni tenute dal gestore.
Il caso 3 è realizzato partendo dal caso 2 ed esercitando un controllo più stretto sulla distribuzione delle chiavi pubbliche. Ora ogni partecipante conosce la chiave pubblica dell’autorità, la quale è l’unica a conoscere la propria chiave privata. Vediamo i passi da eseguire quando A vuole comunicare con B. A invia all’autorità la richiesta della chiave pubblica di B e un timestamp con la registrazione temporale (data, ore, minuti, eccetera). L’autorità risponde con un messaggio cifrato mediante la propria chiave privata, che contiene la chiave pubblica di B e una copia della richiesta e del timestamp (A ora dispone della certezza che il messaggio viene dall’autorità, che non è stato alterato e che risponde alla richiesta corrente). A memorizza la chiave pubblica di B e la usa per cifrare un messaggio indirizzato a B contenente un identificatore di A e un nonce N1 usato per identificare la transazione in modo univoco. B contatta l’autorità per ricevere la chiave di A (invia la richiesta e il timestamp). L’autorità risponde a B inviando, cifrati con la propria chiave privata, la chiave di A, la richiesta e il timestamp. Ora B risponde ad A cifrando, con la chiave pubblica di A, il nonce N1 ricevuto da A e un nuovo nonce N2 generato da B. Per finire, A invia a B un messaggio di conferma, cifrato con la chiave di B, contenete il nonce N2. I quattro messaggi con cui A e B si procurano le chiavi pubbliche del loro interlocutore avvengono raramente, mentre la comunicazione tra A e B avviene per un certo periodo di tempo utilizzando le chiavi ricevute, in base alle stime e ai requisiti di sicurezza.
Un punto debole di questo schema è la centralizzazione dell’autorità, a cui gli utenti devono rivolgersi ogni volta che vogliono usare la chiave pubblica di un altro utente, creando un conseguente collo di bottiglia. Inoltre, come nel caso 2, la directory dei nomi e delle chiavi pubbliche è soggetta a intrusioni e manomissioni.
Il caso 4 prevede l’uso dei public-key certificate, ossia certificati di chiave pubblica (chiamati anche certificati a chiave pubblica). I certificati servono agli utenti per scambiare le chiavi pubbliche senza dover contattare un’autorità, ma con lo stesso grado di sicurezza che si avrebbe se le chiavi fossero fornite direttamente dall’autorità che amministra la directory. Ogni certificato contiene la chiave pubblica e varie informazioni; è creato da una Certification Authority ed è consegnato all’utente. Un utente A trasmette la propria chiave pubblica a un utente B inviandogli il certificato; B verifica che il certificato sia stato creato dall’autorità dei certificati.
Lo schema 4 funziona in questo modo: un utente A richiede alla CA (di persona o via comunicazione autentica-

ta) un certificato, fornendo la propria chiave pubblica; la CA risponde ad A con un messaggio cifrato con la propria chiave privata e contenente il tempo, l’identificatore di A e la sua chiave pubblica; A trasmette il certificato (cifrato) a B; B decifra il certificato ricevuto usando la chiave pubblica della CA, accertando così che il certificato di A proviene dalla CA e verificando l’integrità e la validità dei contenuti (tempo, identità di A e chiave di A). B può ripetere le stesse operazioni e inviare ad A il proprio certificato, cifrato dalla CA in modo da garantirne la sicurezza. In questo schema, il tempo contenuto nel certificato determina il limite di validità; se la chiave privata di un utente viene compromessa e il titolare, dopo la notifica alla CA, non riesce ad avvisare tutti gli interessati, il certificato cessa di valere trascorso un certo tempo dal timestamp.
In questo schema, descritto da Stallings in Cryptography and Network Security, vediamo un antesignano dei moderni certificati digitali, che hanno struttura e utilizzo diversi rispetto al modello riportato sopra. Oggi il tipo più comune di certificato digitale è conforme allo standard ITU X.509, versione 3, del 1997, che comprende una serie di informazioni, la chiave pubblica e una firma digitale applicata dalla CA, con la propria chiave privata, a un hash (o digest) calcolato sui campi precedenti (le informazioni e la chiave pubblica). In questo modo la CA certifica tutte le informazioni del certificato e la loro associazione alla chiave pubblica. La gestione delle chiavi e dei certificati X.509 fa parte della PKI (Public Key Infrastructure infrastruttura a chiave pubblica, basata su una gerarchia di Certification Authority). Uno standard per i certificati, più semplice dell’X.509, è quello dei certificati PGP (Pretty Good Privacy) citati in precedenza, che non sono firmati da una CA, ma possono essere firmati da parecchi individui quale attestazione di fiducia.

Distribuzione di chiavi simmetriche tramite chiavi asimmetriche
Nella sezione 5.2.3.1 (Principi di crittografia asimmetrica) abbiamo mostrato un esempio di distribuzione di una chiave segreta (simmetrica) tramite crittografia asimmetrica RSA. L’esempio ci ricorda che la crittografia asimmetrica è lenta e si applica a dati di piccole dimensioni, mentre quella simmetrica è anche mille volte più veloce e accetta dati di qualsiasi lunghezza. La distribuzione delle chiavi simmetriche non si limita quindi all’uso di un centro di distribuzione, ma può utilizzare i meccanismi della crittografia asimmetrica, a partire dal primo che è stato pubblicizzato: lo scambio di chiavi secondo Diffie-Hellmann.
Whitfield Diffie e Martin Hellmann pubblicarono il primo articolo sui crittosistemi a chiave pubblica (“New Directions in Cryptography”) nel 1976, descrivendo un metodo per stabilire un dato segreto condiviso sulla base dello scambio d’informazioni non segrete su un canale non sicuro. Lo scambio di chiavi Diffie-Hellmann non è studiato solo per ragioni storiche; è tuttora alla base, per esempio, del protocollo IKE (Internet Key Exchange) di scambio delle chiavi utilizzato da IPSec, la forma più avanzata di sicurezza a livello IP (IPSec è lo standard più sicuro per le reti private virtuali o VPN).
Mostriamo brevemente come funziona lo scambio DiffieHellmann. Supponiamo che Alessandro e Bruno siano i partecipanti allo scambio e che, per prima cosa, concordino sulla scelta di un numero primo p e di un generatore g. Lo scambio avviene in due parti. Nella prima parte, sia Alessandro sia Bruno scelgono un numero privato casuale, a per Alessandro e b per Bruno, e lo usano come esponente nelle espressioni seguenti per produrre un valore pubblico (A per Alessandro e B per Bruno). Ricordiamo che mod p (modulo p) indica il resto della divisione per p.
Alessandro Bruno
A=ga mod p B=gb mod p

IT Administrator Sicurezza informatica Lezione 2

Ora Alessandro e Bruno si scambiano i valori pubblici: Alessandro invia A a Bruno e Bruno invia B ad Alessandro. Alessandro e Bruno elevano a potenza i valori pubblici ricevuti, usando come esponente il proprio valore privato.
Alessandro Bruno
Ba mod p = gab mod p = Ab mod p

Il valore ottenuto è il segreto condiviso; ora Alessandro e Bruno possono usarlo per proteggere le loro comunicazioni. A e B sono stati trasmessi su una rete insicura senza nessun rischio per la sicurezza. Neppure g e p hanno bisogno di essere tenuti segreti, perché non permettono di scoprire il segreto.
Questa versione dello scambio di chiavi è vulnerabile al tipo di attacco chiamato man-in-the-middle (l’uomo in mezzo), dove il nemico si presenta ad Alessandro come se fosse Bruno e a Bruno come se fosse Alessandro, raccogliendo e decifrando le informazioni trasmesse. Questa vulnerabilità viene eliminata facendo in modo che Alessandro e Bruno firmino digitalmente i propri valori pubblici, il che impedisce all’uomo in mezzo d’ingannare Alessandro e Bruno, come avviene in IKE (Internet Key Exchange). Un ottimo riferimento a riguardo è “IPSec” di Nagand Doraswamy e Dan Harris (l’autore del protocollo IKE).
Questo capitolo ha proposto una serie (non completa) di spunti sul tema della gestione e distribuzione delle chia-
vi. Come ultimo argomento, citiamo alcuni possibili approcci alla generazione delle chiavi asimmetriche, un aspetto legato alla loro distribuzione. Abbiamo già distinto tra l’uso di PGP (e delle sue varianti Open Source) e la generazione autonoma della coppia di chiavi e il ricorso a una Certification Authority per la generazione dei certificati e delle relative chiavi su cui tali certificati si basano. Durante la richiesta di un certificato, la Certification Authority fa eseguire al computer dell’utente la generazione della coppia di chiavi e si prende unicamente la chiave pubblica al fine di generare il certificato che rilascia contestualmente. La chiave pubblica viene quindi mantenuta negli archivi della CA e il proprietario ne dispone di una copia locale assieme alla chiave privata che dovrà mantenere segreta, magari rimuovendola anche dal computer perché la relativa segretezza costituisce l’unica garanzia ai fini dell’autenticazione. Nell’ambito della PKI (infrastruttura a chiave pubblica), le coppie di chiavi possono anche essere generate sul computer della CA, ma tale approccio non viene utilizzato nella pratica poiché consente il ripudio, visto che l’utente non sarebbe l’unico possessore della chiave privata. Di conseguenza la coppia di chiavi viene sempre generata sul computer dell’utente (per esempio mediante le funzioni del browser) e solo la chiave pubblica viene trasmessa alla CA o alla RA (Registration Authority, un elemento opzionale della PKI a cui la CA può delegare parte dei propri compiti). I libri sulla PKI e sulle firme digitali espandono tale argomento, oggetto di discussioni e di varie soluzioni.
Ruolo del software libero nella crittografia
Per software libero (traduzione di free software), s’intende software che
1) può essere liberamente eseguito per qualunque scopo
2) può essere studiato e adattato da chiunque, data la pubblica disponibilità del codice sorgente
3) può essere liberamente ridistribuito, in modo da aiutare altri utenti
4) può essere migliorato e rilasciato al pubblico, così che l’intera comunità ne tragga beneficio. La definizione completa di software libero è pubblicata nel sito della Free Software Foundation alla pagina www.fsf.org/licensing/essays/free-sw.html. GNU (pronuncia gutturale come in Wagner), acronimo ricorsivo di “GNU is Not Unix”, è un esempio di software libero compatibile con Unix e oggi ampiamente utilizzato nelle varianti GNU/Linux

che utilizzano il kernel (nucleo) di Linux.
Il software libero, grazie alla vitalità delle comunità di utenti e sviluppatori, ha dato un grosso contributo alla diffusione del software crittografico e all’evoluzione delle caratteristiche di robustezza e prestazioni di tutte le implementazioni.
La moderna crittografia si basa sul principio già citato che è preferibile rendere pubblici gli algoritmi e puntare sulla segretezza e sulle caratteristiche delle chiavi per ottenere il massimo livello di sicurezza. La robustezza di un crittosistema si basa, in primo luogo, sulla validità dell’algoritmo (o algoritmi) e sulla lunghezza delle chiavi (altri fattori in gioco sono, ad esempio, la qualità e la correttezza dell’implementazione e l’efficacia della gestione delle chiavi). Se l’algoritmo è robusto, basta utilizzare chiavi abbastanza lunghe per dilatare a piacere (anche trilioni d’anni) il tempo presumibilmente necessario per ricostruire una chiave o comunque violare l’algoritmo.
Vista la complessità e la delicatezza del software crittografico, dove un errore può sfuggire più facilmente che nelle normali implementazioni, la disponibilità delle specifiche degli algoritmi ha consentito un ampio studio dei loro pro e contro e la nascita di numerosi progetti open source e relative implementazioni. Il confronto tra diverse implementazioni, la partecipazione di esperti e l’utilizzo da parte di un esercito di utenti che non sarebbe stato raggiungibile dal software a pagamento, ha permesso a tali progetti di produrre software di qualità eccellente. Anche le aziende private hanno contribuito allo sviluppo di tale software, rendendo disponibili implementazioni di riferimento e anteponendo i benefici derivanti dalla qualità dei sorgenti, ampiamente diffusi, al possibile inconveniente del riutilizzo da parte di terzi, che caratterizza il software libero. Inoltre, l’ampia diffusione e l’assenza di barriere artificiali ha permesso ai produttori di software crittografico di eseguire test d’interoperabilità dei loro prodotti a costo più basso e con la necessità di eseguire meno test con i concorrenti, potenzialmente dispendiosi in termini di tempo e di energie.
Perciò il software libero non va inteso come software gratuito, anche se può esserlo; talvolta il software libero, anche nella crittografia, fornisce maggiori garanzie rispetto al software commerciale. La disponibilità dei sorgenti permette agli utenti che dispongono delle competenze necessarie di accertarsi che il software sia ben realizzato, implementi fedelmente le specifiche e non nasconda qualche backdoor.
Una lista non completa, ma significativa di progetti free software in corso è la seguente.
- Progetto OpenSSL (www.openssl.org): si basa sull’eccellente libreria software SSLeay sviluppata da Eric Young e Tim Hudson e mette a disposizione un’implementazione molto robusta dei protocolli SSLv2 e SSLv3 (http://wp.netscape.com/eng/ssl3/) e TSLv1 (RFC 2246) e una libreria di funzioni crittografiche di uso generale, utilizzate sia da altri progetti open source sia da applicazioni software commerciali.
- OpenCA Labs (ex Progetto OpenCA, www.openca.org): è un’organizzazione aperta avente lo scopo di studiare e sviluppare progetti relativi alla PKI. Il progetto originale è stato suddiviso in unità più piccole per accelerare e meglio organizzare gli sforzi. Il progetto OpenCA di sviluppo di una PKI è uno sforzo collaborativo per sviluppare una Certification Authority open source attraverso l’uso dei protocolli crittografici più robusti e ampiamente accettati. OpenCA si basa su diversi progetti open source, come OpenLDAP, OpenSSL, Apache e Apache mod_ssl.
- Progetti Open Source PKI Mozilla (www.mozilla.org/projects/security/pki): librerie crittografiche per lo sviluppo di applicazioni, tra cui Network Security Services (NSS), Network Security Services for Java (JSS), Personal Security Manager (PSM) e PKCS #11 Confor-

Lezione 2 IT Administrator Sicurezza informatica

mance Testing. Gli obiettivi generali di questi progetti sono: migliorare la qualità, scalabilità e set di funzionalità del codice usato per creare prodotti PKI, incoraggiare lo sviluppo di applicazioni PKI, migliorare la fiducia nel software di sicurezza e accelerare la crescita di una piattaforma di sicurezza basata sugli standard per l’e-commerce e per Internet.
- Progetto OpenLDAP (www.openldap.org): un’implementazione open source completa di un server LDAP (Lightweight Directory Access Protocol) e dei relativi strumenti di sviluppo. Pur non essendo software crittografico in senso stretto, è un componente di base delle infrastrutture a chiave pubblica.
- Progetto MUSCLE (www.linuxnet.com/): librerie per il supporto crittografico e smartcard per i sistemi operativi della famiglia Unix/Linux e Mac OS X. MUSCLE significa Movement for the Use of Smart Cards in a Linux Environment.
- GnuPG (GNU Privacy Guard, www.gnupg.org): è un completo sostituto (libero) del commerciale PGP, che non usa algoritmi brevettati ed è stato riscritto per essere distribuito con licenza GPL. E’ una completa implementazione di OpenPGP (RFC 2440) e può utilizzare gli algoritmi di cifratura ed hash ElGamal, DSA, RSA, AES, 3DES, Blowfish, Twofish, CAST5, MD5, SHA-1, RIPEMD-160 e TIGER. Di per
sé, GnuPG è uno strumento a linea di comando; può essere utilizzato dalla linea di comando, da script di shell o da altri programmi, come i front-end grafici disponibili per Windows e per Linux.

Uso della crittografia
Come anticipato nei capitoli precedenti, una delle applicazioni delle tecniche crittografiche a un dato, un documento oppure un messaggio, consiste nell’accertarne la provenienza, verificandone l’autenticità.
Una tecnica semplice, applicabile ai rapporti bilaterali tra due interlocutori, è l’uso di una chiave segreta. Le due parti concordano l’uso di un algoritmo simmetrico e stabiliscono una chiave segreta, che può essere comunicata di persona o inviata in modo sicuro (la chiave dovrebbe essere modificata di frequente).
Il mittente può cifrare l’intero messaggio con la chiave segreta e inviarlo al destinatario. Costui lo decifra e, sicuro che la chiave non sia nota ad alcun estraneo, deduce che il messaggio proviene effettivamente dal mittente apparente. In tal caso, visto che il messaggio è cifrato, viene assicurata sia l’autenticità sia la riservatezza.
Se peraltro il messaggio non fosse confidenziale e ci bastasse garantirne l’autenticità, anziché cifrare l’intero messaggio, potremmo utilizzare un MAC (Message Authentication Code). Nel capitolo sulle funzioni hash abbiamo visto che si può calcolare un hash (o digest), tipicamente di 128 o 160 bit, sul messaggio a cui è stata aggiunta la chiave segreta, dopo di che si spedisce il messaggio più l’hash. Tale hash prende il nome di MAC (codice di autenticazione del messaggio) perché consente al destinatario di appurare se il messaggio è autentico, cioè proveniente dal mittente dichiarato. Nell’ipotesi che la chiave sia nota solo alle due controparti (basata unicamente sulla fiducia), nessun altro potrebbe impersonare il mittente o modificarne un messaggio senza farsi scoprire dal destinatario. Quest’ultimo ricalcola l’hash sul messaggio più la chiave e lo confronta con il MAC ricevuto; se sono uguali, il messaggio è autentico e integro.
Vista l’efficienza con cui si calcola un MAC e la compattezza tanto del MAC quanto della chiave segreta, la tecnica può essere utilizzata anche su dispositivi con risorse e memoria limitate, come le smartcard (in teoria si chiamano Smart Card, semplificato poi a smart card e, nell’uso comune, a smartcard).

Un limite del MAC è il suo carattere bilaterale, che non lo rende estendibile a più interlocutori. Se da un lato due interlocutori sono pochi, dall’altro sono troppi: un altro limite del MAC è che la chiave segreta non è associata a un singolo proprietario, quindi in caso di controversia non è facile appurare le responsabilità. Quando il proprietario della chiave è un programma, anziché una persona, la soluzione è usare chiavi simmetriche di sessione generate in modo casuale e di breve durata.

Una tecnica di autenticazione più efficace consiste nell’utilizzo della crittografia a chiave pubblica, vale a dire nell’uso di algoritmi a chiavi asimmetriche. Il mittente cifra il dato di cui vuole garantire l’autenticità con la propria chiave privata. Chiunque potrà decifrarlo con la chiave pubblica del mittente, accertandone la provenienza (nessun altro può usare la sua chiave privata). Tale meccanismo viene utilizzato per la firma digitale, che essenzialmente è un hash calcolato sul messaggio e cifrato con la chiave privata del mittente (la firma digitale è trattata in una delle prossime lezioni).

Hashing per garantire integrità e autenticazione
Le funzioni hash sono diventate uno dei componenti di base dei crittosistemi sia simmetrici, sia asimmetrici. Negli esempi precedenti abbiamo visto che l’hashing può essere usato in due modi: 1) per produrre un dato di lunghezza breve e limitata (l’hash o digest), ricavato da un input di lunghezza variabile e 2) per produrre l’hash sulla base del messaggio e di una chiave segreta condivisa tra due interlocutori.
Nel primo caso, la funzione di hash si chiama one-way hash function perché produce una trasformazione a senso unico, dove a N possibili input corrisponde un output, da cui non è possibile risalire all’input. La corrispondenza N:1 deriva dal fatto che i possibili input sono praticamente illimitati, mentre i possibili valori di output sono 2L, dove L è la lunghezza dell’hash (per esempio 128 o 160 bit).
Nel secondo caso il codice di hash viene chiamato MAC (codice di autenticazione del messaggio) e la tecnica di far dipendere l’hash dal messaggio e da una chiave segreta viene chiamata keyed hashing.

Il keyed hashing viene usato nella crittografia simmetrica per produrre i codici MAC utilizzati per autenticare i messaggi e garantirne l’integrità: solo i due interlocutori posseggono la chiave segreta (solitamente una session key di breve durata) e qualsiasi modifica al messaggio sarebbe scoperta dal mittente nel ricalcolare il MAC e nel confrontarlo con il MAC ricevuto.
La variante HMAC descritta nel capitolo 5.2.4.1 (Principi di hashing), più sicura di un semplice MAC, viene correntemente usata in molte applicazioni di sicurezza per la protezione delle comunicazioni su reti TCP/IP (Internet e reti locali).
L’hashing one-way viene usato nella crittografia asimmetrica per produrre le firme digitali (ad esempio con gli algoritmi RSA o DSA), anche in questo caso per assicurare l’autenticità e l’integrità dei dati trasmessi o archiviati.
In pratica, l’autenticazione viene eseguita tramite HMAC o tramite firme digitali, ma in entrambi i casi si usano i medesimi algoritmi di hashing, come MD5 e SHA1. Spesso le due forme di cifratura, simmetrica e asimmetrica, vengono impiegate contemporaneamente. Per esempio, SSL utilizza i certificati a chiave pubblica per la fase di autenticazione iniziale (almeno del server, in opzione anche del client, che normalmente è un browser) e utilizza gli HMAC sia nella fase di handshaking (scambio di chiavi e accordo sui cifrari da usare) sia durante la trasmissione del messaggio per garantirne la riservatezza e l’integrità.
Schemi ibridi analoghi si trovano, ad esempio, nei pro-

IT Administrator Sicurezza informatica Lezione 2

tocolli IPSec (sicurezza allo strato di rete) e SHTTP (sicurezza allo strato applicativo), con autenticazione dei computer tramite certificato e autenticazione dei messaggi tramite HMAC.
Nell’autenticazione dei messaggi di posta elettronica, la crittografia asimmetrica viene usata per firmare digitalmente il messaggio, vale a dire per cifrare un hash del messaggio con la chiave privata del mittente.

Autenticazione e non ripudio mediante firma digitale
I cifrari asimmetrici e gli algoritmi di hashing permettono di verificare l’autenticità e l’integrità di un messaggio attraverso una firma digitale. Prima di scendere in maggior dettaglio, vediamo quali sono i requisiti di una firma e se la firma digitale equivale a una firma autografa.
Una firma autografa serve, principalmente, a fornire certezza legale e commerciale riguardo: 1) l’intenzione e l’impegno a realizzare quanto stipulato, 2) l’autenticità del documento, che le firme legano ai firmatari, e 3) l’approvazione o l’autorizzazione (la firma testimonia che i firmatari hanno letto e approvato il documento). Altri aspetti riguardano la sicurezza di una transazione e l’aspetto cerimoniale (la firma avverte che si sta prendendo un impegno vincolante e suggerisce al firmatario di ponderare sul documento e prendere consapevolezza del suo significato e delle conseguenze, prima di firmarlo).
Una firma dev’essere difficile da falsificare, non ripudiabile (non può essere cancellata o disconosciuta), inalterabile (dopo l’apposizione della firma, non deve essere possibile modificare il documento) e non trasferibile (da un documento a un altro).
Il presupposto per la validità delle firme è che le chiavi private siano tenute al sicuro e che i titolari siano responsabili del loro utilizzo fino al momento di un’eventuale denuncia di furto o smarrimento. L’impiego del timestamp nelle firme è necessario affinché una successiva compromissione (anche volontaria) delle chiavi segrete non porti all‘invalidazione di tutti i documenti firmati, precedenti alla compromissione stessa. Ciò significa che, se le chiavi e i digest hanno lunghezza adeguata, la firma è pressoché impossibile da falsificare e lega il documento al firmatario, che non potrà ripudiare il documento firmato. Dato che la firma dipende dal contenuto del documento, l’integrità è assicurata. Un documento cartaceo firmato potrebbe essere alterato con maggiori probabilità di successo di quanto avvenga per un documento digitale. Per lo stesso motivo, la firma non è trasferibile a un altro documento, visto che è strettamente legata al contenuto del documento, a differenza di una firma autografa che ha sempre lo stesso aspetto.
Come abbiamo visto, la firma digitale si basa sulla cifratura asimmetrica di un hash o digest calcolato sul contenuto del documento o messaggio. L’hash costituisce un’impronta del documento: è assai improbabile che documenti diversi producano lo stesso hash, così com’è pressoché impossibile creare un documento capace di produrre un certo hash. Gli algoritmi di hash più usati sono MD5 e SHA1, quest’ultimo è preferibile perché più sicuro.
La firma viene ottenuta cifrando l’hash con un algoritmo asimmetrico e utilizzando la chiave privata del firmatario. I cifrari più utilizzati sono il commerciale RSA o il pubblico DSA che, insieme a SHA-1, fa parte dello standard DSS di firma digitale definito dal governo degli Stati Uniti.
L’affidabilità di un sistema di firma digitale dipende da vari fattori: la robustezza degli algoritmi di hash e cifratura, la dimensione delle chiavi e degli hash, il livello di protezione con cui è gestita (creata, trasmessa, custodita) la chiave privata e il grado di certezza che la chiave pubblica sia autentica, cioè appartenga al firmatario del documento. Se la chiave pubblica viene sostituita, l’intero sistema è compromesso, visto che si può firmare qualunque cosa

con la chiave privata corrispondente alla falsa chiave pubblica.

La verifica della firma digitale consiste di tre passi: 1) si decifra la firma utilizzando la chiave pubblica del firmatario, ricostruendo l’hash originale del messaggio, 2) si calcola l’hash sul contenuto del messaggio (utilizzando lo stesso algoritmo usato dal mittente), 3) si confrontano i due hash, quello della firma e quello ricalcolato: se coincidono, significa che il messaggio non è stato alterato e che la chiave privata con cui è stato firmato il documento appartiene allo stesso proprietario della chiave pubblica con cui è stata decifrata la firma.

 

Dato che per ogni chiave pubblica esiste una sola chiave privata, la verifica di una firma digitale assicura che chi ha firmato il documento è il possessore della chiave privata. Perché la firma non possa essere ripudiata, occorre soddisfare una serie di condizioni. Le principali sono l’associazione certa tra il firmatario e la sua chiave pubblica, la custodia sicura della chiave privata e l’utilizzo da parte del firmatario di un software che consenta la visualizzazione del documento all’atto della firma, in modo da avere la certezza del contenuto.

Il ruolo di una struttura nell’uso della firma digitale
Abbiamo visto le tecniche e gli algoritmi che si possono utilizzare per garantire l’autenticazione, l’integrità, la riservatezza e il non ripudio nello scambio di messaggi attraverso un canale di comunicazione non sicuro. Inoltre abbiamo notato l’esigenza di soddisfare una serie di requisiti affinché sia possibile utilizzare queste tecnologie e affinché esse permettano di raggiungere gli obiettivi di sicurezza.
Facciamo un esempio applicato alla posta elettronica, chiedendoci in che modo il destinatario di un messaggio possa essere certo dell’identità del mittente. Supponiamo che il mittente apponga la firma digitale al messaggio nel modo visto sopra (hashing più cifratura asimmetrica). Perché il destinatario possa verificare la validità della firma, è necessario che 1) egli possa procurarsi la chiave pubblica del mittente in modo sicuro, 2) conosca il formato dei dati e 3) conosca gli algoritmi utilizzati per la composizione e la firma del messaggio.

Lezione 2 IT Administrator Sicurezza informatica

Per soddisfare queste condizioni, è possibile introdurre una struttura comune (condivisa da una comunità di utenti) che consenta alle entità che devono comunicare (come utenti e processi) d’interoperare con successo. In particolare, si può risolvere il problema della distribuzione sicura delle chiavi ricorrendo a una struttura gerarchica, la già citata Certification Authority (CA), che si faccia garante dell’identità di tutte le entità titolari di una chiave pubblica (e privata). Inoltre, i messaggi e i protocolli di comunicazione devono essere conformi a determinati standard, indipendenti dal sistema operativo, dal software applicativo e da qualsiasi peculiarità del sistema utilizzato.
La CA garantisce le chiavi pubbliche delle entità del proprio dominio mediante l’emissione dei “certificati digitali” in formato standard, contenenti:
1) una serie d’informazioni, tra cui il nome del titolare del certificato, la sua chiave pubblica, il periodo di validità del certificato e altre informazioni che concorrono a identificare il titolare e l’autorità che emette il certificato; 2) la firma digitale, apposta alle suddette informazioni utilizzando la chiave privata della CA.
Tutte le entità che fanno parte del dominio (o dominio di trust) della CA devono ricevere in modo sicuro la chiave pubblica della CA, in modo da poter verificare la validità di qualunque certificato del proprio dominio. Nel contesto di una struttura che faccia uso delle CA per l’emissione dei certificati e la generazione delle chiavi asimmetriche, il formato dei certificati per le chiavi pubbliche è definito dalla norma ITU X.509 Versione 3. L’utilizzo di PGP per la cifratura e firma dei messaggi di e-mail è alternativo all’uso di una CA ed è orientato a comunità limitate d’individui in rapporto di reciproca fiducia. Può utilizzare i certificati, ma essi hanno un formato diverso dall’X.509. Nel campo delle imprese e delle pubbliche istituzioni, vengono usate le CA e i certificati nell’ambito di una PKI (infrastruttura a chiavi pubbliche). Rimandiamo a una sezione successiva (5.2.7.3) la spiegazione in dettaglio del funzionamento di PGP.
Il formato con cui sono codificati i messaggi creati con la cifratura asimmetrica è definito dallo standard PKCS #7 Cryptographic Message Syntax (CMS). PKCS significa Public Key Cryptographic Standard e comprende un’intera serie di standard che hanno l’obiettivo di agevolare l’implementazione delle tecnologie PKI (per esempio, PKCS #1 descrive lo standard di cifratura RSA). PKCS #7 specifica i formati binari usati per la firma digitale e per la “busta elettronica”. Una busta elettronica (digital envelope) consiste di un messaggio che usa la cifratura simmetrica a chiave segreta e una chiave segreta cifrata in modo asimmetrico (come nell’esempio del capitolo 5.2.3.1 Principi di crittografia asimmetrica). Qualunque messaggio formattato con CMS può essere incapsulato dentro un altro messaggio CMS, applicando ricorsivamente la busta elettronica. Ciò permette agli utenti di firmare una busta digitale, di cifrare una firma digitale o di eseguire varie altre funzioni. Lo standard PKCS #7 è stato adottato dall’IETF nella RFC 2315, aggiornata dalla RFC 2630.
Altre proprietà del formato CMS sono: 1) gestisce la firma congiunta di più firmatari, 2) gestisce la firma per un numero arbitrario di destinatari, 3) consente di aggiungere attributi firmati al messaggio, come la data e l’ora della firma,
4) consente di allegare al messaggio i certificati dei firmatari, agevolando la verifica della firma, 5) include gli identificatori degli algoritmi crittografici utilizzati e gli elementi che facilitano la decifratura e la verifica della firma.
Uso della crittografia
per ottenere la riservatezza
Come abbiamo visto nei capitoli precedenti, la riservatezza (o confidenzialità) viene ottenuta cifrando i dati, i messaggi o i documenti da archiviare o da trasmettere. A seconda delle applicazioni, si utilizzano cifrari simmetrici (a chiave segreta) o asimmetrici (con chiave privata e chia-

ve pubblica). I cifrari simmetrici possono essere applicati a dati di dimensioni illimitate, mentre quelli asimmetrici funzionano per input di poche decine di byte.
Un cifrario simmetrico richiede che due interlocutori (persone o componenti hardware/software) concordino sull’uso di un algoritmo e scelgano una chiave segreta da usare per cifratura e decifratura. Il mittente cifra il messaggio e lo trasmette; il destinatario decifra il messaggio con la stessa chiave usata dal mittente e ripristina il contenuto in chiaro.
Un’altra possibilità è utilizzare un programma separato per la cifratura e decifratura dei file e inviare i dati cifrati come allegati. Ci sono applicazioni di questo tipo sia per utenti finali sia per utenti più esperti che vogliono controllare l’algoritmo usato e la lunghezza della chiave.
La crittografia simmetrica è semplice da usare ed efficiente, ma presenta il problema della gestione delle chiavi, che devono essere diverse per ogni coppia d’interlocutori e devono essere sostituite di frequente.
Se si utilizza la crittografia asimmetrica, ogni interlocutore possiede due chiavi: custodisce al sicuro la chiave privata e mette a disposizione di chiunque la chiave pubblica. Il mittente si procura la chiave pubblica del destinatario, la usa per cifrare il messaggio tramite un cifrario asimmetrico e invia il messaggio cifrato. Il destinatario decifra il messaggio usando lo stesso cifrario e la sua chiave privata. In tal modo, si risolve un problema di distribuzione delle chiavi, ma se ne creano altri due: i cifrari asimmetrici sono molto lenti e possono ricevere in input dati molto brevi, perciò debbono lavorare cifrando il messaggio in blocchi il che rallenta ulteriormente le operazioni .
La soluzione sta nell’utilizzo contemporaneo dei due tipi di crittografia: asimmetrica per gestire lo scambio delle chiavi e simmetrica per cifrare i messaggi. La procedura è la seguente:
1) si sceglie un algoritmo simmetrico e uno asimmetrico
2) il mittente si procura la chiave pubblica del destinatario
3) il mittente genera in modo casuale una chiave segreta appropriata
4) il mittente cifra il messaggio utilizzando la chiave segreta
5) il mittente cifra la chiave segreta utilizzando la chiave pubblica del destinatario
6) il mittente invia al destinatario il messaggio cifrato e la chiave segreta cifrata, insieme alle informazioni necessarie per la decifratura
7) il destinatario decifra la chiave segreta utilizzando la propria chiave privata
8) il destinatario decifra il messaggio utilizzando la chiave segreta.

 

Tale meccanismo è comunemente usato dalle applicazioni di comunicazione sicura su Internet, come i client di posta elettronica, e dai protocolli di trasmissione sicura,

IT Administrator Sicurezza informatica Lezione 2

 

come SSL (Secure Sockets Layer). In quest’ultimo caso, il protocollo opera allo strato di trasporto (sopra il TCP), quindi non protegge singoli messaggi, ma tutti i dati trasmessi nell’ambito di una connessione Internet.
Le tecniche per ottenere la riservatezza delle informazioni sono utilizzabili anche per la privacy delle informazioni archiviate, in modo che non siano accessibili da estranei. In tal caso si utilizzano solitamente algoritmi simmetrici; dato che mittente e destinatario coincidono, non c’è il problema della trasmissione della chiave segreta, è sufficiente che l’utente scelga una chiave abbastanza lunga e complessa e la tenga al sicuro. Tra gli esempi citiamo l’Encryption File System di Windows XP (per cifrare file e cartelle) e applicazioni stand-alone come Axcrypt (http://axcrypt.sourceforge.net/), che utilizza AES con chiavi di 128 bit ed è particolarmente comodo da usare.
A parte le applicazioni specificamente crittografiche, i programmi di office automation e le utility di archiviazione e compressione offrono solitamente opzioni di protezione dei dati tramite password, generalmente realizzate con crittografia simmetrica.
Tale crittografia viene spesso implementata con un semplice XOR e assicura un livello di protezione del tutto insufficiente, valido unicamente a difendersi dagli incompetenti, ma non certo per bloccare persone determinate a violarla (nemmeno se queste sono semplici utenti).
Tuttavia, non sempre documentano l’algoritmo usato, il

quale rischia di non essere abbastanza robusto per proteggere dati importanti. Per garantire la riservatezza, è necessario che l’algoritmo sia robusto (come 3DES e AES), che la chiave sia di lunghezza adeguata (per esempio 128 bit) e che il suo valore sia non prevedibile e sia mantenuto segreto.

Applicazioni
Un vasto campo di applicazione delle misure di protezione crittografiche è quello degli affari e della pubblica amministrazione. La possibilità di eseguire transazioni da casa e ufficio attraverso Internet ha portato in primo piano l’esigenza di utilizzare meccanismi di sicurezza adeguati. Consideriamo l’utilizzo di Internet per accedere ai servizi bancari online (conti correnti, pagamenti, investimenti, ecc.) e per eseguire operazioni di acquisto e vendita online. Indipendente dalle reali implementazioni, possiamo sviluppare alcune considerazioni.
Le operazioni di e-banking e di e-commerce che un utente può eseguire on-line sono di due tipi:
1) operazioni di carattere informativo, come la visualizzazione di un estratto conto, la situazione dei bonifici, lo stato degli ordini oppure lo stato di un’asta elettronica,
2) operazioni di tipo dispositivo, come un ordine di acquisto, un ordine di bonifico, la vendita di azioni oppure il pagamento di un’utenza.
Le operazioni di carattere informativo forniscono accesso ai dati in lettura e non danno origine a flussi di denaro. Normalmente è sufficiente proteggere il canale di comunicazione e il protocollo SSL incorporato nei browser è perfettamente adeguato allo scopo.
Per le operazioni di tipo dispositivo sono ipotizzabili diverse strade. Il protocollo SSL, spesso utilizzato, può risultare adeguato nei casi in cui gl’importi in gioco non suggeriscano di adottare meccanismi di protezione più robusti. Sebbene SSL utilizzi algoritmi crittografici affidabili, l’eventuale punto debole è che protegge solo il canale di comunicazione, dopo di che i dati sono messi in chiaro dal server web, senza un controllo preciso di chi possa accedere alle informazioni.
La protezione crittografica della rete viene spesso distinta in due categorie: link encryption ed end-to-end encryption. La protezione del collegamento (link) si applica agli strati inferiori dei protocolli di comunicazione, fino allo strato di trasporto in cui opera SSL. Il modello end-to-end si applica allo strato applicativo: end-to-end significa che sono le applicazioni, ai due estremi (end) della comunicazione, che controllano la cifratura e decifratura e quindi la messa in chiaro dei dati. In tal modo i dati sono più protetti e meno soggetti a intrusioni da parte di altre entità del sistema.
Esempi di protocolli di sicurezza allo strato applicativo sono S-HTTP (Secure Hypertext Transport Protocol) e SET (Secure Electronic Transaction), scarsamente usati rispetto a SSL e alla recente variante TLS. Utilizzando l’approccio end-to-end, l’applicazione può utilizzare le tecniche di cifratura viste in precedenza sulle singole disposizioni (i movimenti economici ordinati dall’utente) e provvede sia a dare corso alle transazioni sia a conservare in modo sicuro i messaggi degli utenti, esponendo le informazioni alla visibilità strettamente necessaria.

Firma digitale e non ripudio nei servizi di e-banking e di e-mail
Abbiamo visto che la firma digitale annovera tra le sue funzioni il non ripudio di un messaggio. Normalmente, possiamo supporre che gli accessi di tipo informativo non abbiano bisogno di firma digitale, mentre è prevedibile che le disposizioni debbano essere firmate dal richiedente. In tal

Lezione 2 IT Administrator Sicurezza informatica

modo, se la firma non risultasse valida (per esempio a causa di un certificato scaduto o revocato), la disposizione non verrebbe eseguita. Inoltre i messaggi sono registrati, così che la banca o altra organizzazione possa sempre dimostrare di aver ricevuto una disposizione valida firmata dal cliente e non ripudiabile.
Il non ripudio può non essere sufficiente se non è associato in modo certo all’istante temporale della firma. Perciò, la firma digitale può essere utilmente affiancata da un servizio di marcatura temporale (timestamp). Si tratta di un servizio fornito da una Time Stamp Authority (TSA), una terza parte fidata che attesta il tempo di produzione o d’invio di un documento tramite una “marca temporale”, che è di fatto una controfirma del documento contenente un hash del documento, il riferimento temporale e altre informazioni.
Nel campo del software libero, OpenTSA (www.opentsa.org) sta sviluppando una TSA aperta e gratuita conforme alla RFC 3161 (Internet X.509 Public Key Infrastructure Time-Stamp Protocol TSP). Trai componenti software già prodotti c’è anche la Time Stamp patch for OpenSSL, un’estensione di OpenSSL con marcatura temporale.
Il funzionamento di PGP
Pretty Good Privacy (PGP) è un programma di sicurezza per la posta elettronica realizzato da Phil Zimmermann e pubblicato inizialmente nel 1991 come freeware. Le funzioni di PGP sono: firma digitale, cifratura dei messaggi, compressione, conversione in ASCII (in base 64) e segmentazione dei messaggi; di queste, le prime due rientrano nel contesto delle applicazioni crittografiche.
PGP fu fatto circolare liberamente (incluso il codice sorgente) e conquistò una rapida popolarità. Per cifrare e firmare i messaggi, PGP utilizza la crittografia simmetrica e asimmetrica. Inizialmente, il cifrario asimmetrico era RSA e quello simmetrico, dopo un breve periodo con un algoritmo rivelatosi poco sicuro, era IDEA. La chiave segreta non fu mai inferiore a 128 bit, contravvenendo alle leggi USA del tempo. Inoltre RSA negò di aver dato un assenso verbale all’uso del proprio cifrario (brevettato fino al 2000) e il brevetto di IDEA scade nel 2007. Seguirono anni di questioni giudiziarie che man mano si sono risolte senza danno, grazie anche al successo di PGP e ad accomodamenti sui vari fronti. Oggi esiste l’azienda PGP che vende le versioni commerciali del programma e offre una versione limitata freeware abbastanza scomoda da usare perché non integrata nei programmi di posta. Tuttavia nel 1997 PGP ha consentito all’IETF di pubblicare uno standard aperto col nome di OpenPGP. Le RFC pubblicate sono la 2440 (OpenPGP Message Format) del 1998 e la 3156 (MIME Security with OpenPGP) del 2001. La Free Software Foundation ha pubblicato la propria versione di PGP (GNU Privacy Guard: GnuPG o GPG) conforme alle specifiche OpenPGP; è disponibile gratuitamente per diverse piattaforme, tra cui Linux, MAC OS X e Windows.
Oggi sia PGP sia GPG supportano la maggior parte dei moderni algoritmi crittografici (cifrari simmetrici e asimmetrici e funzioni hash), tra cui RSA, Diffie Hellmann, ElGamal, 3DES, AES, IDEA, CAST5, SHA, RIPEMD-160 e altri. A
differenza di PGP, OpenPGP non utilizza IDEA, che non è ancora libero da brevetti.
Il funzionamento della firma elettronica in PGP avviene nel modo seguente: 1) il mittente scrive un messaggio, 2) viene calcolato un hash del messaggio, 3) l’hash è cifrato con la chiave privata del mittente, 4) il mittente invia il messaggio insieme all’hash cifrato, 5) il destinatario riceve il messaggio con l’hash, 6) l’hash è decifrato con la chiave pubblica del mittente, 7) viene ricalcolato l’hash sul messaggio, 8) vengono confrontati l’hash decifrato e quello calcolato, 9) se i due hash coincidono, il messaggio è autentico e integro.
La riservatezza viene ottenuta nel modo seguente: 1) il

mittente scrive un messaggio, 2) il programma genera un numero casuale utilizzato come chiave di sessione, ovvero una chiave di cifratura simmetrica usata solo per quel messaggio, 3) il messaggio viene cifrato con un algoritmo simmetrico usando la chiave di sessione generata, 4) la chiave di sessione è cifrata con la chiave pubblica del destinatario,
5) il messaggio cifrato e la chiave cifrata sono inviati al destinatario, 6) presso il destinatario, il programma decifra la chiave di sessione utilizzando la chiave privata del destinatario, 7) il messaggio è decifrato utilizzando la chiave di sessione decifrata.
Firma e cifratura possono essere applicate insieme in questo modo: 1) il mittente scrive un messaggio, 2) il mittente firma il messaggio come visto sopra, 3) messaggio ed hash sono cifrati come appena visto, 4) messaggio ed hash cifrati sono inviati al destinatario, 5) presso il destinatario, la chiave segreta cifrata è decifrata con la chiave privata, ottenendo la chiave di sessione, 6) il resto del messaggio ricevuto è decifrato con la chiave simmetrica di sessione, 7) la prima parte del messaggio decifrato (l’hash) viene decifrato con la chiave pubblica del mittente, 8) sul resto del messaggio viene calcolato l’hash, 9) vengono confrontati l’hash decifrato e quello calcolato, 10) se i due hash coincidono, il messaggio è autentico e integro.
Come si vede, anche PGP sfrutta i principi visti in precedenza: 1) l’integrità del messaggio viene verificata su un hash del messaggio, non sull’intero messaggio (è molto più veloce), 2) il messaggio è cifrato con un algoritmo simmetrico, veloce e non vincolato alla lunghezza dei messaggi, 3) l’algoritmo asimmetrico viene usato per lo scambio delle chiavi simmetriche.
Le operazioni sono svolte automaticamente dal software, senza interventi dell’operatore (dopo la generazione iniziale della coppia di chiavi asimmetriche). PGP offre diverse versioni di software commerciale che si integrano con le applicazioni di posta. La versione freeware richiede invece la cifratura e decifratura del file o del clipboard, da copiare a mano nel programma di posta. GPG viene usato come modulo di base o attraverso un’interfaccia grafica (ne esistono per i vari sistemi operativi e hanno nomi diversi) e può essere integrato con Mozilla e Thunderbird tramite un add-in chiamato Enigmail.
Per la sicurezza nell’uso di PGP si devono considerare due aspetti: 1) i numeri “casuali” usati come chiavi di sessione devono essere il più possibile realmente casuali; si usano algoritmi PRNG (pseudo-random number generator) e meccanismi che sfruttano eventi casuali naturali per generare sequenze di numeri casuali e non ripetibili; 2) le chiavi pubbliche devono essere effettivamente tali e verificabili; le implementazioni più moderne di PGP e GPG si basano su un server di distribuzione delle chiavi pubbliche, ma inizialmente le chiavi erano pubblicate su qualche server e gli utenti si scambiavano gli hash delle chiavi per consentire il controllo dell’autenticità.
Installare e configurare un prodotto PGP
Le versioni commerciali e la versione freeware di PGP, con la relativa documentazione, sono disponibili presso il sito di PGP Corporation (www.pgp.com). La versione freeware limitata per Windows è scaricabile alla pagina www.pgp.com/downloads/freeware/freeware.html ed è facilmente installabile eseguendo il file scaricato. Un’icona nella barra di notifica di Windows (in basso a destra) dà accesso alle funzioni disponibili (le principali sono generazione chiavi, firma, cifratura, firma e cifratura, decifratura). I messaggi possono risiedere in un file o nel clipboard di Windows. Solo le versioni a pagamento includono un plugin per i programmi di posta, come Outlook, in modo da firmare, cifrare e decifrare i messaggi dall’interno del programma.
GPG è già incluso in diverse distribuzioni Linux (come SuSE Linux 9.2 e Fedora 3), inoltre è scaricabile per vari si-

IT Administrator Sicurezza informatica Lezione 2
stemi operativi presso www.gnupg.org e i siti collegati. La versione per Windows è a linea di comando, ma esistono plugin GPG per i programmi di posta, come EudoraGPG per Eudora sotto Windows (http://eudoragpg.sourceforge. net/ver2.0/en/).
In Windows, GPG può essere utilizzato direttamente aprendo il file eseguibile, oppure può essere installato secondo i canoni di Microsoft editando il registro di sistema. Le istruzioni presso http://enigmail.mozdev.org/gpgconfig.html guidano all’installazione e configurazione di GPG in Windows 9x e in Windows NT/2000/XP.
Una sintetica guida in italiano all’uso di GPG è reperibile presso www.gnupg.org/(en)/howtos/it/GPGMiniHowto.html. Un’ottima guida per usare la versione di GPG a linea di comando per Windows è www.glump.net/ content/gpg_intro.pdf.
L’ambiente ideale per utilizzare GPG è SuSE Linux, dato che il client di posta KMail e l’utility di gestione delle chiavi KGpg fanno parte dell’interfac-

 

cia standard KDE. Fedora 3 usa per default l’interfaccia GNOME, ma include parecchie applicazioni KDE, come KMAIL e KGpg (utilizzabili modificando le applicazioni preferite nelle preferenze).
Per utilizzare GPG s’inizia creando una coppia di chiavi in KGpg. La scelta dell’algoritmo asimmetrico è tra RSA e la coppia DSA/ElGamal (firma e scambio chiavi).
Secure Shell SSH
Secure Shell (SSH) è un protocollo per realizzare un collegamento remoto sicuro da un computer a un altro attraverso una rete insicura. Supporta il login remoto sicuro, il trasferimento sicuro di file e l’inoltro sicuro del traffico di tipo TCP/IP e X Window. SSH è in grado di autenticare, cifrare e comprimere i dati trasmessi. Sebbene si chiami Secure Shell, SSH non è un vero shell come il Bourne shell (l’interprete dei comandi) o il C shell di Unix e non è un interprete di comandi. SSH crea un canale sicuro per eseguire uno shell da un computer remoto, in modo simile al comando rsh (remote shell) di Unix, ma con cifratura end-toend (da un’applicazione all’altra) tra il computer locale e il computer remoto. A differenza di rsh, SSH assicura l’autenticazione, la riservatezza e l’integrità alla trasmissione in rete. Esistono molti prodotti basati su SSH, per i diversi sistemi operativi e in versioni sia commerciali sia a libera distribuzione.
Una comunicazione con il protocollo SSH implica la partecipazione di due attori: il client da cui parte la richiesta di collegamento e il server a cui la richiesta è indirizzata. Client e server operano secondo uno schema che prevede numerose varianti. Inoltre esistono due versioni di protocollo, SSH-1 e SSH-2, tra loro incompatibili. La prima è supportata da tutti i prodotti, ma è vulnerabile; la seconda, più articolata e sicura, non è supportata da alcuni prodotti, come TGSSH per PalmOS. I programmi recenti supportano entrambe le versioni e sono quindi in grado di connettersi a qualunque tipo di server.
Il termine SSH indica in genere sia una versione di protocollo che un prodotto software. Per distinguere tra i pro-

Lezione 2 IT Administrator Sicurezza informatica

tocolli e i prodotti commerciali, spesso si usa la seguente terminologia: SSH-1 e SSH-2 indicano i protocolli (per esempio SSH-1-5); SSH1 e SSH2 indicano due prodotti di SSH Communications Security (formata dal finlandese Tatu Ylönen, autore della prima versione del protocollo); OpenSSH è una versione gratuita multipiattaforma di OpenBSD Project; OpenSSH/1 e OpenSSH/2 indicano il comportamento di OpenSSH in relazione all’uso di SSH-1 e SSH-2; ssh indica un programma client incluso in SSH1, SSH2, OpenSSH, F-Secure SSH e altri prodotti. SSH e OpenSSH sono descritti in vari documenti IETF (nel 2005 ancora a livello di bozza draft).

Stabilire la connessione
Il funzionamento di SSH è complesso e ricco di funzionalità e opzioni, tanto da richiedere un libro per una descrizione completa (il più noto è “SSH, The Secure Shell: The Definitive Guide” di Barret e Silverman, pubblicato da O’Reilly). Vediamo lo schema di funzionamento di SSH-1 nella fase in cui viene stabilita la connessione.
1) Il client contatta il server, inviando una richiesta di connessione alla porta TCP 22 del server; 2) Il server risponde con una stringa (del tipo SSH-1.99-OpenSSH_2.3.0) che indica la versione del protocollo e del prodotto. Se il client non supporta la versione (o una delle versioni) del server, chiude la connessione, altrimenti risponde con una stringa simile. Quando client e server supportano entrambe le versioni di SSH, decidono quale utilizzare.
3) Il client e il server passano all’uso di un formato di pacchetto più sicuro, al di sopra del TCP che funge da trasporto, in modo da sventare attacchi al testo in chiaro.
4) Il server identifica se stesso al client e fornisce i parametri per la sessione. Invia le seguenti informazioni in chiaro: la chiave pubblica dell’host (fissata all’installazione), la chiave pubblica del server (rigenerata periodicamente per sventare tentativi di crittoanalisi), una sequenza casuale di otto byte (check bytes o cookie) che il client dovrà ripetere e liste dei metodi di cifratura, di compressione e di autenticazione supportati dal server.
5) Sia il client sia il server calcolano un identificativo di sessione comune di 128 bit, usato nelle operazioni successive per identificare in modo univoco la sessione SSH. Si tratta di un hash MD5 sull’insieme di chiave host, chiave server e cookie.
6) Il client verifica che la chiave host del server corrisponda alla chiave già memorizzata (la prima volta chiede conferma). In caso di discrepanza, la connessione termina (il server connesso potrebbe essere quello di un terzo incomodo che tenta di eseguire un attacco “man in the middle” per appropriarsi della connessione).
7) Il client genera una chiave di sessione, ottenuta generando un numero casuale di 256 bit, calcolando l’OR esclusivo tra l’identificativo di sessione e i primi 128 bit della chiave di sessione. Scopo della chiave di sessione è cifrare e decifrare i messaggi tra client e server. Dato che la cifratura non è ancora attiva, la chiave non può essere trasmessa in chiaro. Perciò il client cifra questa chiave due volte, sia con la chiave host sia con la chiave server sopra citate. Dopo la cifratura, il client invia la chiave di sessione, insieme al cookie e a una lista di algoritmi, scelti tra quelli supportati dal server.
8) Dopo l’invio della chiave di sessione, entrambe le parti iniziano a cifrare i dati con tale chiave e l’algoritmo simmetrico prescelto. Prima d’inviare dati, però, il client attende un messaggio di conferma dal server, cifrato con la chiave di sessione. Esso fornisce l’autenticazione del server: solo il vero server è in grado di decifrare la chiave di sessione, cifrata con la chiave host verificata in precedenza a fronte della lista degli host noti.

Autenticazione del client
Una volta stabilita la connessione (inclusa autenticazione del server), inizia la fase di autenticazione del client. Nel caso più semplice, essa si limita all’invio dell’identificativo di utente e della password; sebbene siano trasmessi cifrati, tale metodo è poco sicuro e sconsigliato, soprattutto per la diffusa abitudine di scegliere password deboli. Normalmente si consiglia di utilizzare una coppia di chiavi RSA o DSA per l’autenticazione del client (SSH accetta comunque anche altri tipi di autenticazione).
L’autenticazione del client con chiavi RSA in SSH-1 avviene secondo i passi che seguono. Per accedere a un account su una macchina in funzione di server (client e server possono comunque scambiarsi i ruoli), il client dimostra di possedere la chiave privata corrispondente a una chiave pubblica autorizzata. Una chiave è “autorizzata” se la componente pubblica è contenuta nel file di autorizzazione dell’account (per esempio ~/.ssh/authorized_keys).
Ecco la sequenza delle azioni.
1) Il client invia al server una richiesta di autenticazione con chiave pubblica e indica quale chiave intende usare (trasmette il modulo e l’esponente, vale a dire i due elementi dell’algoritmo RSA che costituiscono la chiave pubblica).
2) Il server legge il file delle autorizzazioni per l’account dell’utente e cerca una voce contenente la stessa chiave (in sua assenza, l’autenticazione con chiave fallisce). Se il controllo è positivo e non ci sono restrizioni all’uso di tale chiave da parte del client e del suo host, il processo continua.
3) Il server genera una stringa casuale di 256 bit come challenge, la cifra con la chiave pubblica dell’utente e la invia al client.
4) Il client riceve il challenge e lo decifra con la corrispondente chiave privata; in tale fase il programma di solito chiede all’utente una passphrase (frase segreta) che serve unicamente a decifrare la chiave privata, che per sicurezza è salvata cifrata. Dopo di che il client combina il challenge con l’identificativo di sessione, ne calcola l’hash con MD5 e lo invia al server in risposta al challenge.
5) Il server confronta il digest ricevuto con quello calcolato e, se coincidono, considera autenticato l’utente.
La descrizione appena fornita si riferisce a SSH-1; SSH-2 non è molto diverso, ma è più sicuro, più elegante e più flessibile. SSH-1 ha una struttura monolitica ed esegue più funzioni in un singolo protocollo; SSH-2 è articolato in tre componenti principali: Transport Layer Protocol, Connection Protocol e Authentication Protocol.
1) SSH Transport Layer Protocol. Le connessioni negoziate con tale protocollo godono di cifratura forte, autenticazione del server e protezione dell’integrità. Può essere fornita anche la compressione.
2) SSH Connection Protocol. Permette ai nodi client di negoziare canali aggiuntivi per convogliare (multiplex) diversi flussi (stream) di pacchetti da più applicazioni attraverso il tunnel SSH originario. I diversi flussi vengono mescolati secondo un preciso metodo al fine di convogliarli tutti attraverso il medesimo tunnel e quindi separarli di nuovo (de-multiplex) all’uscita dal tunnel. Disporre il Connection Protocol sopra il Transport Layer Protocol riduce anche il carico di elaborazione, perché l’utente non è costretto a impostare una nuova connessione per ogni applicazione.
3) SSH Authentication Protocol. Il processo di autenticazione è separato dal Transport Layer Protocol, perché non sempre è necessario autenticare l’utente. Quando è richiesta l’autenticazione, il processo viene protetto dalla connessione sicura originaria stabilita dal Transport Layer Protocol.
Come abbiamo visto, l’instaurazione del collegamento e l’autenticazione costituiscono una procedura complessa, ma, salvo per la richiesta della passphrase, si tratta di una

IT Administrator Sicurezza informatica Lezione 2

procedura automatica e pressoché istantanea. Il meccanismo di SSH è molto sicuro a patto di utilizzarlo correttamente.
Vediamo alcuni potenziali rischi.
1) L’utilizzo di un cifrario simmetrico debole per cifrare i dati. Per esempio, DES (supportato da SSH-1, ma non SSH-2) va evitato perché facilmente violabile; si possono usare 3DES, AES e altri algoritmi forti.
2) Utilizzo di nome utente e password. Non dovrebbe essere usato perché offre un’autenticazione meno sicura rispetto all’uso delle chiavi asimmetriche, anche nel caso di password scelte oculatamente.
Vediamo alcuni punti deboli delle implementazioni. Il principale limite alla sicurezza è posto talvolta dalla scelta del software e dalla sua versione. E’ consigliabile consultare i report di sicurezza (advisories) di www.cert.org per conoscere i punti deboli delle implementazioni di SSH per le varie piattaforme (per una descrizione delle funzioni di CERT, Computer Emergency Response Team, vedi la sezione 5.1.3.5 della prima lezione: “CERT, CSIRT e la gestione degli incidenti”, pubblicata come capitolo 11 nel corso multimediale su CD). Per esempio, l’advisory www.cert.org/advisories/CA2002-36.html elenca numerose implementazioni di SSH e ne riporta gli eventuali punti deboli. In generale, è preferibile utilizzare la versione 2 di SSH, a meno che non vi siano validi motivi per scegliere la prima versione. In ogni caso, oggi esistono diversi prodotti SSH-2 per diverse piattaforme, incluso Palm OS (vedi www.tussh.com/ www.palmgear.com/index.cfm?fuseaction=software.showsoftware&PartnerREF=&siteid=1&prodid=72847&siteid=1 www.sealiesoftware.com/pssh
http://staff.deltatee.com/ ~angusa/TuSSH_old.html).
Finora abbiamo menzionato il funzionamento di ssh, il client SSH per il login remoto. Altri esempi di client SSH sono scp per il trasferimento sicuro dei file, sftp per la connessione sicura FTP e ssh-agent, un agente che permette l’autenticazione sicura con parecchi computer in rete senza bisogno di ricordare tutte le passphrase. Il daemon sshd viene invece utilizzato per restare in ascolto in attesa delle chiamate dai client SSH.

Installare un prodotto che gestisce il protocollo SSH
SSH è solitamente supportato dalle moderne distribuzioni Linux (in versione OpenSSH) attraverso applicazioni come ssh, scp, ssh-keygen, sshd e sftp. Anche MAC OS X è dotato di SSH (1.5 e 2.0). OpenSSH è disponibile per vari sistemi operativi, incluso Windows. Per Palm OS esistono Top Gun SSH (solo SSH-1) e TuSSH (SSH-1 e SSH-2). Per Windows esistono diverse versioni, elencate in www.openssh.com/windows.htm; tra queste, una delle più note è PuTTY, un client Telnet, Rlogin e SSH per il login remoto. E’ concesso in licenza gratuita dall’MIT ed è facile da usare, anche se meno sicuro della versione OpenSSH (http://sshwindows.sourceforge.net/); sia PuTTY sia OpenSSH for Windows supportano le due versioni di SSH. I computer che agiscono da server devono avere installata anche un’applicazione SSH server, il che è frequente, ma non sempre accade (per esempio PuTTY è solo client). In Linux e Mac OS X, SSH è implementato anche come server; per Windows esistono versioni server (sshd) commerciali come WinSSHD (http://www.bitvise.com/wins-
shd.html).
Alcune applicazioni SSH, vedi OpenSSH, sono del tipo software libero, distribuite anche come sorgenti. Normalmente ci si limita a scaricare i file eseguibili per la piattaforma desiderata (per esempio Win32 su hardware x86). Se occorre, bisogna espandere i file compressi, per esempio con tar (formati tar e tgz), rpmI (formato rpm), dpkg (formato debian) o Winzip (formato zip).
Installato, se occorre, il software SSH, sarà bene utiliz-

zare quando possibile la versione 2 e comunque evitare di utilizzare DES se si usa la versione 1. In OpenSSH si possono modificare le impostazioni SSH a livello di sistema nei file /etc/ssh/ssh_config e /etc/ssh/sshd_config.
Quanto all’autenticazione, è senz’altro preferibile utilizzare le chiavi asimmetriche. Basta generare le chiavi con l’apposita utility (come ssh-keygen) e copiare le chiavi pubbliche sul server come specificato per la versione di SSH utilizzata (vedi l’esempio in Linux più avanti).
In Linux, i parametri Cipher e Ciphers in ssh_config hanno i seguenti valori di default:
Cipher 3des
Ciphers aes128-cbc,3des-cbc,blowfish-cbc,cast128cbc,arcfour,aes192-cbc,aes256-cbc
Il parametro PasswordAuthentication vale solo per i server ed è preferibile sia impostato a no.
Il parametro PermitRootLogin, per i server, permette di collegarsi come root; si consiglia yes qualora le password non fossero abilitate, altrimenti si consiglia il valore without-password, in modo da forzare l’uso delle chiavi per l’autenticazione.
Creare una chiave
con un pacchetto compatibile SSH
Nella maggior parte dei casi, la generazione delle chiavi è assai semplice, come si vede in questo esempio di dialogo in Linux, dove è richiesta la generazione di chiavi DSA e l’uso della versione 2 di SSH.
La passphrase può essere omessa, ma il suo uso è consigliato per proteggere la chiave privata, che deve restare segreta.

gobbi@linux:~> ssh-keygen -t dsa Generating public/private dsa key pair.
Enter file in which to save the key (/home/gobbi/.ssh/id_dsa):
Enter passphrase (empty for no passphrase): Enter same passphrase again:
Your identification has been saved in
/home/gobbi/.ssh/id_dsa. Your public key has been saved in
/home/gobbi/.ssh/id_dsa.pub.
The key fingerprint is: bc:ed:44:26:7a:29:66:1b:5f:6a:d3:15:cb:ef:b6:6d
gobbi@linux

Le versioni di OpenSSH permettono di operare come segue.
Nelle versioni non recenti di SSH ci si può limitare a usare ssh-keygen per generare una coppia di chiavi RSA. Nelle versioni recenti si può scegliere fra tre modalità:
1) ssh-keygen -t rsa1 per chiavi RSA con versione 1 di SSH
2) ssh-keygen -t rsa per chiavi RSA con versione 2 di SSH
3) ssh-keygen -t dsa per chiavi DSA con versione 2 di SSH

Vengono chieste due informazioni: il nome del file dove si vuole memorizzare la chiave privata (la chiave pubblica viene salvata in un file con lo stesso nome e suffisso .pub) e la passphrase di sblocco della chiave privata.
Se, per generare le chiavi, si usa PuTTY in Windows, basta eseguire Puttygen.exe e specificare in basso una delle tre opzioni, equivalenti a quelle viste per OpenSSH; si consiglia di usare una delle due previste per SSH-2. Si può modificare la lunghezza della chiave, ma il default di 1.024 è adeguato.
Dopo il clic su Generate, viene chiesto di muovere il mouse sopra la finestra del programma, in modo da generare eventi casuali che aiutano a produrre valori casuali. Dopo la generazione, si scrive la passphrase per proteggere la chiave privata. Le chiavi pubblica e privata sono salvate separatamente ed è preferibile che abbiano lo stesso nome (viene aggiunto .ppk a quella pubblica).

Lezione 2 IT Administrator Sicurezza informatica

Inserire chiavi su un server per autenticarne i proprietari
Nell’autenticazione con chiavi, il server deve conoscere le chiavi pubbliche dei client che si collegano. Ciò avviene copiando le chiavi pubbliche in una data posizione del server. Nel caso di un utente che utilizza OpenSSH su un sistema Linux o Mac OS X, si procede come segue.
1) Si decide quale identificativo di utente (user-id) va associato al client.
2) Ci si sposta nella sua home directory (per esempio /home/gobbi).
3) Ci si sposta nella sottostante cartella .ssh.
4) Si crea il file authorized_keys se si usa la versione 1 o authorized_keys2 se si usa la versione 2 (per esempio touch authorized_keys2); si limitano gli accessi con chmod 600 authorized_keys2.
5) Si copia la chiave pubblica del client remoto in authorized_keys2; per esempio, se si è trasferita la chiave su un floppy che poi è stato montato in /mnt sul server e la directory corrente è /home/gobbi/.ssh, si può usare cat
/mnt/id_dsa.pub >> authorized_keys2.
6) Altrimenti si può trasferire la chiave al server remoto con un comando del tipo scp id_dsa.pub gobbi@192.168.0.190:./id_dsa.pub, che esegue una copia sicura del file dalla directory .ssh del client alla home directory sul server.
Nell’uso di SSH è particolarmente utile l’opzione -v (verbose) per vedere ciò che accade a ogni passo. La connessione SSH (versione 2) dell’utente gobbi (su Linux SuSE) al computer con indirizzo 192.168.0.190 (con Linux Fedora), autenticata con chiavi DSA, ha il seguente aspetto. Dopo lo scambio d’informazioni e di chiavi, la scelta dei protocolli e l’autenticazione con chiavi asimmetriche, inizia la sessione interattiva. In assenza dell’autenticazione con chiavi, verrebbe chiesta la password di Gobbi sul server.

gobbi@linux:~/.ssh> ssh -2 -v gobbi@192.168.0.190 OpenSSH_3.9p1, OpenSSL 0.9.7d 17 Mar 2004 debug1: Reading configuration data /etc/ssh/ssh_config debug1: Applying options for *
debug1: Connecting to 192.168.0.190 [192.168.0.190]
port 22.
debug1: Connection established.
debug1: identity file /home/gobbi/.ssh/id_rsa type 1 debug1: identity file /home/gobbi/.ssh/id_dsa type 2 debug1: Remote protocol version 1.99, remote software
version OpenSSH_3.9p1
debug1: match: OpenSSH_3.9p1 pat OpenSSH* debug1: Enabling compatibility mode for protocol 2.0 debug1: Local version string SSH-2.0-OpenSSH_3.9p1

debug1: SSH2_MSG_KEXINIT sent debug1: SSH2_MSG_KEXINIT received
debug1: kex: ser ver->client aes128-cbc hmac-md5 none debug1: kex: client->ser ver aes128-cbc hmac-md5 none debug1: SSH2_MSG_KEX_DH_GEX_REQUEST
(1024<1024<8192) sent
debug1: expecting SSH2_MSG_KEX_DH_GEX_GROUP debug1: SSH2_MSG_KEX_DH_GEX_INIT sent debug1: expecting SSH2_MSG_KEX_DH_GEX_REPLY
debug1: Host '192.168.0.190' is known and matches the RSA host key.
debug1: Found key in /home/gobbi/.ssh/known_hosts:1 debug1: ssh_rsa_verify: signature correct
debug1: SSH2_MSG_NEWKEYS sent debug1: expecting SSH2_MSG_NEWKEYS debug1: SSH2_MSG_NEWKEYS received
debug1: SSH2_MSG_SERVICE_REQUEST sent debug1: SSH2_MSG_SERVICE_ACCEPT received debug1: Authentications that can continue:
publickey,gssapi-with-mic,password
debug1: Next authentication method: publickey debug1: Offering public key: /home/gobbi/.ssh/id_rsa debug1: Authentications that can continue:
publickey,gssapi-with-mic,password
debug1: Offering public key: /home/gobbi/.ssh/id_dsa debug1: Ser ver accepts key: pkalg ssh-dss blen 433 debug1: read PEM private key done: type DSA
debug1: Authentication succeeded (publickey). debug1: channel 0: new [client-session] debug1: Entering interactive session.
Last login: Thu Apr 7 15:51:48 2005 [gobbi@host ~]$

Secure/Multipurpose Internet Mail Extensions S/MIME
S/MIME (Secure/Multipurpose Internet Mail Extensions) è un protocollo che aggiunge la cifratura e la firma elettronica ai messaggi MIME descritti nella RFC 1521 (Mechanisms for Specifying and Describing the Format of Internet Message Bodies). MIME è lo standard che specifica come devono essere trasferiti i dati multimediali e gli allegati di e-mail. I messaggi di posta su Internet consistono di due parti, l’intestazione e il corpo. L’intestazione raccoglie una serie di coppie campo/valore che forniscono informazioni essenziali per la trasmissione del messaggio, secondo la struttura specificata nella RFC 822. Il corpo di solito non è strutturato a meno che il messaggio sia in formato MIME. MIME definisce la struttura del corpo del messaggio in modo da permettere d’includere testo con attributi, grafica, audio e altri contenuti in modo standardizzato. MIME non fornisce alcun servizio di sicurezza. Lo scopo di S/MIME è quindi definire tali servizi secondo la sintassi definita dal formato PKCS #7 (citato in precedenza) per la firma e la cifratura. S/MIME estende lo standard MIME e permette la cifratura del messaggio e degli allegati. Gli algoritmi di cifratura e hash possono essere specificati dall’utente nelle impostazioni del programma di posta, come visto nel capitolo 5.2.2.1 (Principi di crittografia simmetrica). S/MIME garantisce la riservatezza mediante l’algoritmo di cifratura, l’integrità mediante l’algoritmo di hash, l’autenticazione mediante l’uso di un certificato a chiave pubblica X.509 e il non ripudio mediante la firma digitale.
S/MIME è stato sviluppato in origine da RSA; in seguito è passato all’IETF. La sua standardizzazione è oggetto dell’S/MIME Working Group dell’IETF (vedi www.imc.org/ietfsmime/index.html per l’elenco dei documenti disponibili).
Ecco alcune caratteristiche di S/MIME.
1) Formato del messaggio: binario, basato su CMS (vedi PKCS #7)
2) Formato del certificato: binario, basato su X.509
3) Algoritmo simmetrico: TripleDES (DES EDE3 CBC)

IT Administrator Sicurezza informatica Lezione 2

4) Algoritmo di firma: Diffie-Hellman (X9.42) con DSS
5) Algoritmo hash: SHA-1
Un modo per proteggere la posta elettronica con S/MIME consiste nel procurarsi un certificato personale per email da Thawte (www.thawte.com/email/ ), che lo fornisce gratuitamente, rinnovabile di anno in anno.
S/MIME è supportato da vari client e-mail: Outlook e Outlook Express di Microsoft, Netscape Messenger 7.x, Mozilla Mail, Mail in Mac OS X e altri, ma non da Eudora (per il quale esistono plug-in in ambiente Windows).
Secure Sockets Layer SSL
Secure Sockets Layer (SSL) è un protocollo per la protezione di un canale di comunicazione attraverso una rete e funziona allo strato di trasporto, tra i protocolli di trasporto e di applicazione. Come altri protocolli di sicurezza di rete, SSL utilizza la crittografia simmetrica e asimmetrica e le funzioni di hash per fornire l’autenticazione del server (e in opzione anche del client), la cifratura dei messaggi e l’integrità dei dati. Quando un client (tipicamente un browser) accede a un sito web, è possibile che trovi una parte delle pagine protette, come accade nei siti che supportano transazioni bancarie o commerciali e la raccolta di informazioni personali tramite moduli da compilare (form). Quando il client passa da una pagina pubblica a una pagina sicura, il web server invoca SSL per proteggere la comunicazione (l’utente se ne accorge perché l’URL della pagina è preceduto da https cioè HTTP over SSL anziché http) inoltre compare solitamente un’icona nella finestra del browser che segnala la presenza di una connessione protetta. Nel caso di Internet Explorer in Windows, ad esempio, l’icona ha la forma di un piccolo lucchetto dorato che compare in basso a destra. Il server risponde al client indicando che dev’essere stabilita una sessione sicura e il client invia i propri parametri di sicurezza. Nella prima fase, opera l’Handshake Protocol, il primo dei tre componenti di SSL. In tale fase client e server negoziano i parametri crittografici da usare: versione del protocollo, identificativo di sessione, selezione degli algoritmi crittografici e del metodo di compressione, generazione di numeri casuali iniziali, autenticazione del server (solitamen-

te con un certificato), eventuale autenticazione del client (rara benché possibile), accordo finale sulla suite di cifrari da usare.
Nella fase di handshake, il client si connette al server, invia una serie di dati (versione supportata, un numero casuale che sarà usato per lo scambio delle chiavi, un ID di sessione, la lista degli algoritmi supportati e il metodo di compressione) e attende risposta.
Il server risponde con un messaggio analogo, con numero di versione, altri dati casuali, lo stesso ID di sessione e gli algoritmi scelti dal server per lo scambio delle chiavi (RSA, Diffie-Hellmann e altri), la cifratura simmetrica, l’hash e la compressione.
Il server dimostra la propria identità inviando al client il suo certificato digitale; tale scambio può includere, in opzione, l’intera catena di certificati fino al certificato root (radice) della Certification Authority (CA). Se richiesto dal metodo di scambio chiavi adottato, il server invia al client un messaggio di scambio chiavi contenente materiale per la generazione della chiave simmetrica.
Il server può quindi iniziare a richiedere l’autenticazione del client con un certificato, ma nella maggior parte dei casi ciò non accade.
Il client verifica il certificato o i certificati del server in base alle date di validità e controlla la presenza della firma di una CA fidata.
Il client invia un messaggio di scambio chiavi il cui contenuto dipende dall’algoritmo usato.
Il server verifica il certificato del client, se presente.
Il client e il server generano la chiave di sessione utilizzando i dati che si sono scambiati nei messaggi precedenti.
Il secondo componente di SSL è il Record Protocol, usato per lo scambio di dati tra le applicazioni dopo aver creato il canale sicuro di comunicazione. I messaggi sono frammentati in blocchi facili da gestire e opzionalmente vengono compressi; si applica un MAC (codice di autenticazione del messaggio) e il risultato viene cifrato e trasmesso. Il ricevente decifra i dati, verifica il MAC, decomprime e riassembla il messaggio e fornisce il risultato al protocollo applicativo.

Lezione 2 IT Administrator Sicurezza informatica

 

Il terzo componente, l’Alert Protocol, è usato per indicare il verificarsi di un errore o la terminazione di una sessione tra due host.
L’uso di SSL richiede un server con capacità SSL; i browser includono generalmente il supporto SSL 2.0 e 3.0. In precedenza abbiamo messo a confronto la protezione a livello di collegamento con la protezione (superiore) a livello di applicazione. SSL, collocato allo strato di trasporto (dove opera il protocollo di rete TCP, per intenderci), fornisce la sicurezza della connessione, ma non la sicurezza dei dati una volta ricevuti e decifrati. L’utente di una connessione SSL può contare su una comunicazione protetta, ma deve avere fiducia nell’istituzione a cui trasmette i dati per la sicurezza con cui essi saranno trattati e conservati.
Una variante rispetto all’SSL versione 3 di uso corrente è il protocollo TLS (Transport Layer Security) definito dall’IETF nella RFC 2246, simile a SSL, ma con differenze soprattutto negli algoritmi crittografici utilizzati. TLS è già implementato e si può prevedere una sua graduale adozione.
Uso delle smartcard
Le smartcard, piccole schede di plastica che includono capacità logiche e memoria, sono utilizzate per memorizzare in modo sicuro le chiavi private usate per la firma digitale e per la decifratura. In tal modo si evita di conservarle o dimenticarle sul computer, ossia in un ambiente poco sicuro.
In sintesi, una smartcard oggi è costituita da un microprocessore dotato di una certa quantità di RAM e da una memoria EEPROM (Electrically Erasable Programmable Read-Only Memory) che alloggia il software di gestione e le chiavi e il cui contenuto non si cancella col tempo, ma può essere modificato mediante apposite apparecchiature. La smartcard dialoga con il mondo esterno attraverso un’interfaccia seriale (secondo la disposizione a otto contatti

dello standard ISO7816 Part 1) o senza contatti, mediante un’interfaccia radio.
Il programma residente sulla scheda riconosce i comandi che arrivano dall’esterno e risponde di conseguenza. Fondamentalmente, i comandi inviati a una smartcard sono del tipo seguente:
1) richiesta di generazione di chiavi
2) richiesta della chiave pubblica
3) richiesta di cifrare un blocco di dati con la chiave privata
4) richiesta di memorizzazione del certificato della CA che ha emesso il certificato dell’utente in base alla chiave pubblica estratta dalla smartcard.
Una trattazione dettagliata può essere trovata su Smart Card Handbook, Secon Edition di Rankl ed Effing.
Le smartcard possono generare, su richiesta, coppie di chiavi (pubblica e privata); non c’è modo di estrarre la chiave privata dalla scheda, mentre la chiave pubblica è disponibile per l’uso nei sistemi PKI. La custodia sicura della chiave privata permette di usare le smartcard per firme digitali con validità legale e garanzia di non ripudio.
A causa della capacità limitata del processore e della memoria di una smartcard, le operazioni di generazione di chiavi e di cifratura sono piuttosto lente, ma ciò non è grave se si considera che le chiavi sono generate non più di una volta l’anno e che le operazioni avvengono su hash di lunghezza ridotta.
L’accesso alle smartcard (come ad altri dispositivi crittografici) avviene mediante un’API (interfaccia programmatica) definita dallo standard PKCS #11 (Cryptographic Token Interface Standard, detto Cryptoki). L’interfaccia standard permette di sviluppare software indipendente dalla smartcard utilizzata.
Un esempio di smartcard ad uso dei cittadini è la carta dei servizi della Regione Lombardia (vedi www.crs.lombardia.it/). •

IT Administrator Sicurezza informatica Lezione 3

Autenticazione e controllo degli accessi
Prevenire i furti e gli accessi non autorizzati

Prosegue il primo corso di taglio professionale destinato al conseguimento della certificazione ufficiale, EUCIP IT Administrator – Sicurezza
Informatica, valida in tutta Europa. In questo numero ci occupiamo di tutti i sistemi di riconoscimento e autenticazione, dalla password, alle smartcard con un esame approfondito anche dell’autenticazione via rete.
I contenuti sono composti da tre elementi: un articolo sulla rivista, un articolo, molto più esteso in formato PDF e un corso multimediale completo
su CD e DVD di Giorgio Gobbi e Marco Mussini

n termini molto generali, l’autenticazione può essere definita come il processo mediante il quale si verifica un determinato parametro. Il parametro può riguardare gli argomenti più svariati, come l’identità di un processo o di un utente o di un computer, oppure l’identità e l’integrità di un
pacchetto in rete.
Una definizione più focalizzata vede l’autenticazione come il processo tramite il quale viene stabilita l’identità di un’entità. Nel campo della sicurezza informatica, l’entità è tipicamente un computer, un processo, un utente o un messaggio.
La legge italiana considera autenticata l’identità di una persona solo se c’è un pubblico ufficiale che lo attesti e ricorre a complesse perifrasi per definire la conferma di identità ottenuta mediante mezzi informatici. Per semplicità, continueremo a usare il termine autenticazione come equivalente dell’inglese authentication di uso generale, consapevoli del fatto che, quando si passa dal contesto tecnico a quello giuridico (per esempio riguardo la validità delle firme digitali), bisogna fare riferimento al linguaggio e alle disposizioni dei recenti articoli di legge. Sebbene la legge possa risultare complessa, farraginosa e criticabile dagli ambienti informatici, resta il fatto che nessun computer, software o utente può confermare con certezza l’identità di un utente; si possono solo eseguire test che, quando superati, forniscono una garanzia sufficiente sull’identità dell’interlocutore. Il problema sta nell’aggettivo “sufficiente”,

che muta significato nel tempo con l’evolversi delle tecnologie di attacco e di difesa e che dipende da ipotesi, spesso disattese, sul comportamento degli utenti e sulla validità degli strumenti tecnici. Di fronte alle possibilità di falsificazione e soprattutto alla possibile trascuratezza o incompetenza degli utenti, i test di autenticazione assumono un valore relativo.
All’atto dell’autenticazione, l’entità che chiede di essere autenticata presenta alcune credenziali, come una password o un certificato digitale, come prova della propria

Lezione 3 IT Administrator Sicurezza informatica

identità. Se le credenziali sono valide e sufficienti, l’entità è ritenuta autentica. L’autenticazione verifica solo che un’entità sia quella che dichiara di essere, senza entrare nel merito dell’accesso al sistema.
Una volta che un utente (in senso lato) è stato autenticato, il passo successivo è assicurare che possa accedere solo alle risorse per cui è autorizzato. Ciò avviene implementando controlli di accesso, permessi, privilegi e altri elementi, secondo il sistema in questione. L’autorizzazione viene talvolta confusa con l’autenticazione nei documenti tecnici e normativi, ma è un concetto ben distinto: autorizzazione è il diritto accordato a un individuo (oppure entità hardware/software) di accedere a un sistema e alle sue risorse secondo un profilo di permessi ben definito (definito ad esempio da un system administrator o stabilito automaticamente dalla categoria di autorizzazione dell’utente).
Un’analogia per un processo di autenticazione informatico è il controllo del passaporto a una frontiera. Il viaggiatore fornisce alla guardia di frontiera il proprio passaporto con la foto, le generalità e informazioni sull’ente che ha rilasciato il documento. La guardia osserva se il passaporto appare autentico, se la foto è somigliante e magari se ha un numero identificativo valido, verificato tramite accesso a un database. L’atto di convalidare il passaporto e di valutare la somiglianza tra il viaggiatore e la foto è una forma di autenticazione.
Il successo dell’autenticazione non implica che al viaggiatore sia concesso di varcare la frontiera, come pure nel caso dell’accesso a un sistema. La persona può essere priva di visto o di qualche altro requisito o risultare indesiderata o pericolosa per i suoi trascorsi, attività o connessioni. Allo stesso modo un’entità informatica potrebbe essere autenticata e, una volta riconosciuta, potrebbe risultare priva di autorizzazioni.
Su una rete (e specialmente Internet), l’autenticazione è più complessa sia perché eseguita da macchine sia perché le entità autenticatrici della rete di solito non hanno accesso fisico alle entità da autenticare. Programmi o utenti ostili possono tentare di rubare informazioni, crearne di false, interrompere o alterare un servizio fingendosi entità valide. Il ruolo dei processi di autenticazione è quello di distinguere le entità valide da quelle non valide ed è un compito essenziale per la sicurezza di una rete e dei sistemi che vi sono connessi. Se un individuo riesce a impersonare un utente valido, non ci sono limiti al danno potenziale per la riservatezza e integrità delle informazioni, oltre ai danni economici che ne possono derivare. Vedremo che in qualche caso può essere persino compromessa la futura capacità di autenticazione degli utenti.
Oggi esiste una vasta schiera di metodi di autenticazione, che comprende l’uso di password, di certificati digitali, di dispositivi biometrici e di oggetti fisici come token (“gettoni”, ovvero schede o chiavi di vario tipo) e Smart Card contenenti ad esempio un certificato. Nessuno di essi è perfetto. Le password, da tempo considerate insicure, sono destinate a essere rimpiazzate da metodi più efficaci. Persino metodi apprezzati o promettenti come le Smart Card e i dispositivi biometrici pongono seri problemi: le Smart Card per le difficoltà di adozione generalizzata data la varietà di soluzioni sul mercato (senza contare i costi), il secondo perché è relativamente facile procurarsi i dati biometrici di un individuo (a sua insaputa) compromettendone l’autenticazione per tutta la vita.
Oltre agli schemi consolidati di autenticazione che vedremo nei prossimi capitoli, è inevitabile che ne nascano di nuovi, favoriti anche dall’evoluzione delle tecnologie mobili. Oggi, ad esempio, esistono PDA dotati di funzioni crittografiche e di capacità biometriche, come il riconoscimento dell’impronta digitale, della firma e della voce, che li rendono idonei a impieghi di autenticazione riducendo i rischi di furto di identità. Infatti, nel caso di furto, il PDA,

protetto da crittografia forte, può resistere per un buon tempo.
Modelli di architettura
I modelli a cui si fa riferimento per progettare un sistema di autenticazione dipendono dal tipo di utenti, dalla distribuzione fisica delle risorse, dal valore delle informazioni da proteggere e da altri fattori. In sintesi, i modelli fondamentali sono quattro.
1) Autenticazione locale: è quella utilizzata su un computer desktop o portatile. L’intero sistema, inclusi i meccanismi di autenticazione e controllo degli accessi, risiede all’interno di un singolo perimetro di sicurezza. L’utente definisce e tiene aggiornate le informazioni di autenticazione all’interno di tale perimetro.

2) Autenticazione diretta: è stata usata in passato dai server delle reti locali e dai sistemi di timesharing (utilizzo contemporaneo di un computer da parte di più utenti che si ripartiscono il tempo di elaborazione dello stesso). Il sistema è usato da molti utenti, anche remoti. Autenticazione e controllo degli accessi risiedono in un singolo perimetro fisico. E’ un modello “diretto” perché è centralizzato: un sistema prende tutte le decisioni e contiene il database con le informazioni sugli utenti. Ogni sistema di questo genere è amministrato e aggiornato indipendentemente, quindi il modello diretto si presta per un singolo sistema o per un gruppo di sistemi con popolazioni di utenti indipendenti. La vulnerabilità a intercettazioni e replay di messaggi impone l’uso di crittografia, almeno per le password.
3) Autenticazione indiretta: è usata nei moderni sistemi distribuiti per consentire a una popolazione di utenti di accedere a più sistemi e punti di servizio in rete. Quando un sistema riceve una richiesta di accesso, la inoltra a un server di autenticazione centralizzato che esamina le credenziali fornite e conferma l’identità dell’utente. A tale scopo vengono usati protocolli come RADIUS e Kerberos o i domini dei server Windows. Il server di autenticazione gestisce un unico database, facilmente amministrabile, con le informazioni sugli utenti, che possono accedere in modo uniforme a tutti i punti di servizio ospitati dai sistemi sulla rete.
4) Autenticazione off-line: è quella utilizzata nei sistemi che sfruttano l’infrastruttura a chiave pubblica (PKI). In questa architettura, diversi componenti autonomi prendono decisioni sull’autenticazione degli utenti anche se

IT Administrator Sicurezza informatica Lezione 3

in tale momento non possono contattarsi l’un l’altro. Le parti interessate accettano il rischio che talvolta le decisioni siano basate su informazioni di autenticazione non aggiornate, che possono determinare risultati scorretti. Il modello indiretto è una combinazione dei tre precedenti: l’autenticazione e il controllo degli accessi risiedono sullo stesso dispositivo, mentre il titolare della sicurezza (l’autorità di certificazione che gestisce le chiavi pubbliche) mantiene un database centralizzato degli utenti autorizzati. L’aspetto peculiare è che non occorre che la CA sia online, e quest’ultima può anche distribuire le chiavi pubbliche attraverso mezzi tradizionali e proteggere in tal modo i propri sistemi da intrusioni. Per esempio, il protocollo SSL incorporato in un browser si procura il certificato con la chiave pubblica dal server da autenticare (per esempio il sito di una banca), lo autentica con un’altra chiave pubblica prestabilita (nota al browser) e quindi utilizza la chiave pubblica del server nella fase di scambio dati per la costruzione di una chiave di sessione con cui cifrare le comunicazioni.
I diversi schemi di autenticazione
Indipendentemente dai metodi usati, i sistemi di autenticazione hanno generalmente alcuni elementi comuni: una persona o entità da autenticare, una o più caratteristiche distintive su cui si basa l’autenticazione, un proprietario o amministratore del sistema di sicurezza e un meccanismo di autenticazione che verifica le caratteristiche distintive. Il meccanismo di controllo dell’accesso, spesso considerato parte integrante del sistema di autenticazione, è in realtà una funzione successiva, invocata se l’autenticazione ha avuto successo.
Per esempio, nel caso del Bancomat, l’elemento da autenticare è una persona, le caratteristiche distintive sono due (la scheda e il PIN), il proprietario è la banca e il meccanismo di autenticazione è il software di validazione delle informazioni fornite dalla scheda (registrate su una banda magnetica o nella memoria di un chip) e del PIN digitato dall’utente. Se l’autenticazione ha successo e l’utente ha il credito necessario, il meccanismo di controllo dell’accesso autorizza il prelievo della somma richiesta.
Un altro esempio è quello di un sito di e-commerce; l’entità da autenticare (verso il client che si collega al sito) è il proprietario del sito, la caratteristica distintiva è una chiave pubblica in un certificato digitale, l’amministratore e garante della sicurezza è l’autorità certificatrice che ha emesso il certificato, il meccanismo di autenticazione è il software di convalida del certificato contenuto nel browser dell’utente, che determina se la pagina web è sicura. Tale schema è riscontrabile nel protocollo SSL (Secure Sockets Layer) presentato nel capitolo 5.2.7.8 della sezione Crittografia.
Nella letteratura è frequente trovare i fattori di autenticazione di un utente suddivisi in tre categorie:
- qualcosa che sai (come password, passphrase, PIN o combinazione)
- qualcosa che hai (come token, Smart Card o dati incorporati in un file o dispositivo)
- qualcosa che sei (caratteristiche biometriche come impronta digitale, retina, iride, volto, voce).
La paternità di questo schema è attribuita a Carlton e agli altri autori dell’articolo del 1988 “Alternate Authentication Mechanisms”. L’appeal mnemonico di “qualcosa che sai, qualcosa che hai, qualcosa che sei” ha fatto in modo che questa sorta di filastrocca mettesse stabili radici. Facciamo notare in ogni caso la forzatura in cui s’incorre se si prende alla lettera la terza categoria, visto che tra un individuo e una caratteristica del proprio corpo corre una distanza pressoché incolmabile. Trascurare tale aspetto porterebbe a situazioni paradossali, dove si rischierebbe di autenticare corpi (non necessariamente vivi) o loro parti anziché individui. Sebbene la terza categoria rientri in realtà

nella seconda (un individuo possiede un corpo che ha caratteristiche biometriche), per non allontanarci troppo dalla convenzione ci limiteremo a correggere la formulazione in qualcosa che “sei”.
Qualcosa che sai
È uno dei metodi di autenticazione più antichi, utilizzato per esempio in passato per bloccare gli stranieri che non conoscevano la parola d’ordine o la pronunciavano male. Oltre a parole (password) e frasi (passphrase), gli elementi di autenticazione di questa categoria includono i PIN, le combinazioni da digitare su una tastiera numerica (l’equivalente della combinazione numerica di un lucchetto o cassaforte) e le informazioni note soltanto all’individuo, da usare in risposta a specifiche domande personali. L’autenticazione tramite un dato segreto in possesso dell’utente è vulnerabile sia per motivi tecnici sia per i comportamenti insicuri degli utenti; sebbene ancora ampiamente usata, tende a essere sostituita da metodi più sicuri e da combinazioni di più fattori (come scheda più PIN). Il grado di sicurezza peggiora rapidamente quando un utente, per ricordare tutte le password di accesso a banche, siti e servizi, le scrive su carta o le conserva in un file non cifrato.
Qualcosa che hai
Anche gli oggetti sono stati usati nel passato a scopo di autenticazione; sigilli di ceralacca, chiavi e documenti firmati erano alcuni degli strumenti utilizzati per farsi riconoscere o per avere accesso a luoghi e risorse. Il termine “chiave” in informatica deriva in effetti dalle chiavi di casa, anche se l’analogia si ferma qui perché, a differenza di una chiave informatica, la chiave di casa non identifica il possessore come il padrone di casa o come qualcuno che abbia diritto a entrarvi. Oggi l’oggetto in possesso dell’utente e usato come caratteristica distintiva per l’autenticazione può essere semplicemente un file di dati. Se l’utente è una persona (piuttosto che un processo o un dispositivo hardware) il file è generalmente incorporato in un dispositivo che l’utente può portare con sé, come una scheda con striscia magnetica, una Smart Card o un calcolatore di password. Tali oggetti vengono anche chiamati token. L’autenticazione tramite token è la più difficile da violare, dato che si basa su un oggetto fisico che l’utente deve avere con sé al momento dell’autenticazione e dell’accesso al sistema. A differenza delle password e strumenti simili, nel caso di un token l’utente sa se gli è stato rubato ed è difficile che possa condividerlo con altri riuscendo ancora a collegarsi a un sistema. Un token costa di più, può essere smarrito e si può guastare, ma soddisfa le esigenze
di sicurezza di un ampio spettro di applicazioni.
Qualcosa che “sei”
Tale categoria di fattori di autenticazione si basa su caratteristiche del corpo umano e, secondariamente, anche su comportamenti unici della persona. Prima dei computer,

Lezione 3 IT Administrator Sicurezza informatica

queste caratteristiche includevano un ritratto, la firma, una descrizione scritta e le impronte digitali. Oggi i computer permettono di confrontare rapidamente un attributo fisico con una registrazione archiviata in un database. Le tecniche comprendono le impronte digitali, la forma e l’impronta delle mani, le caratteristiche dell’occhio (iride e retina), la voce, la firma autografa e altre possibilità. Nel complesso, tali caratteristiche sono chiamate biometriche.
Nonostante i vantaggi dell’autenticazione biometrica, che non richiede dati segreti o schede da portare con sé, i punti deboli possono superare i benefici. Oltre ai costi maggiori per l’acquisto, l’installazione e la gestione dell’attrezzatura, i dati biometrici possono essere intercettati, l’identificazione non è certa (c’è una percentuale di falsi postivi e di falsi negativi), le caratteristiche biometriche possono variare nel tempo e soprattutto, è facile procurarsi i dati biometrici di un individuo e comprometterne l’autenticazione per tutta la vita.
È facile capire che non esiste, almeno per ora, un metodo di autenticazione perfetto. La scelta dipende dai rischi specifici per le diverse circostanze, dai costi e da altri fattori, come la disponibilità e l’utilizzabilità degli strumenti, l’adozione di standard e altro ancora. Visto che tutti i metodi presentano inconvenienti e spesso non offrono il livello di protezione richiesto, è sempre più comune utilizzare meccanismi di protezione multipli, che incorporano due o tre dei fattori citati. Tali sistemi offrono la cosiddetta autenticazione forte, perché, usando più fattori, ciascuno di essi contribuisce a neutralizzare i punti deboli degli altri.
Tuttavia quando si passa dall’autenticazione di un utente presso un sistema locale all’autenticazione in rete, le cose si complicano. Le tre categorie di fattori di autenticazione si basano su caratteristiche distintive della persona o entità, ma quando tali caratteristiche si traducono in sequenze di bit che attraversano la rete, nessun meccanismo può fornire la certezza assoluta che una password o una lettura biometrica siano raccolte dalla persona anziché registrate e ritrasmesse da altri. Perciò, insieme ai fattori di autenticazione forniti dagli utenti, sono necessarie tecniche che identifichino univocamente i messaggi scambiati e impediscano agli estranei d’inserirsi nel dialogo.

Password
Gestione delle password
L’uso delle password è uno dei più antichi sistemi di autenticazione, che già ritroviamo nell’”Apriti sesamo” di Alì Babà e i 40 ladroni. Qualche decennio fa, quando la multiutenza consisteva di terminali connessi a un sistema centrale di timesharing e gli utenti cominciavano a essere ubicati all’esterno del centro di calcolo (ben protetto), le password erano lo strumento di autenticazione. Il terminale, di tipo telescrivente con stampa sul rullo di carta, dopo l’input della password (anch’essa stampata), sovrastampava caratteri casuali per impedirne la lettura a estranei.
Negli anni successivi abbiamo visto i sistemi operativi conservare le password in chiaro in un file. Nella corsa tra attacchi e difese, il file delle password in chiaro ebbe breve vita, vista la facilità di impossessarsene sia dal sistema online sia dai nastri di backup periodico dello stesso.
A partire dal 1967 cominciò a essere introdotto l’hashing delle password, che viene tuttora utilizzato. Il sistema conserva un file con i nomi degli utenti e l’hash delle relative password. All’atto dell’autenticazione, l’hash calcolato in base alla password digitata viene confrontato con quello registrato nel file; se coincidono, l’utente è autenticato. Dato che dall’hash è impossibile ricostruire la password, il sistema è relativamente sicuro, a meno di attacchi di forza

bruta o basati su dizionari delle parole più usate.
L’hash delle password venne aggirato dai programmi di keystroke sniffing, ossia di registrazione dell’input di tastiera (i tasti battuti dall’utente). Si tratta di un attacco tuttora possibile e praticato con una varietà di mezzi hardware e software. Un modo per neutralizzare il keystroke sniffing è stato la protezione delle aree di memoria, affinché un programma non possa curiosare nella memoria di un altro programma. E’ una protezione parziale che comunque non sconfigge i dispositivi hardware di registrazione collocati tra la tastiera e il connettore sul computer.
L’evoluzione degli attacchi ha portato al network sniffing, vale a dire all’analisi del traffico di rete per carpire password, chiavi di cifratura e altre informazioni. A questo si è risposto con le password usate una volta sola, ossia generate nel momento stesso in cui devono essere utilizzate e quindi eliminate, e con la periodica variazione delle chiavi fisse, in modo da limitare le possibilità che vengano scoperte. Vi presentiamo un quadro fin troppo semplificato e approssimativo, ma rappresenta la dinamica con cui evolve la competizione tra attacchi e difese.
Oltre a carpire password e altre informazioni per via tecnologica, un metodo usato per conquistare l’accesso a un sistema è il social engineering: l’attaccante si fa aiutare da un dipendente, inconsapevole, convincendolo a rivelare le informazioni (come nome utente e password) necessarie a entrare nel sistema. Uno dei modi più usati consiste nel presentarsi come un tecnico di assistenza, che per esempio ha urgente bisogno del nome utente e della password del malcapitato interlocutore allo scopo dichiarato di evitargli la perdita dei dati. L’attaccante può anche ordinare, con una falsa e-mail apparentemente inviata dal system administrator, di cambiare provvisoriamente la password, come specificato, per lavori di manutenzione.
Un esempio di procedura di login tramite password appare in Unix, che ha iniziato a utilizzare l’hashing delle password intorno al 1973 e si è evoluto utilizzando algoritmi di hashing più sicuri. Il file delle password nel classico Unix Versione 7 comprendeva questi campi: nome utente, hash della password preceduto da un valore casuale di 12 bit detto “salt” (sale), User ID numerico, Group ID numerico, un campo di uso misto detto GCOS field (dal nome di un sistema operativo utilizzato a quel tempo dai Bell labs) e il nome dello shell preferito dall’utente (per esempio
/bin/csh).
Quando un utente digita un nome utente, il programma di login cerca il nome nel file delle password (/etc/passwd) e, se lo trova, estrae l’hash della password; il programma chiede la password all’utente e ne calcola l’hash; se i due codici di hash coincidono, l’utente è autenticato e si collega al sistema.
La seconda versione di hashing delle password di Unix utilizza una variante di DES, il cifrario simmetrico presentato nella sezione sulla crittografia. L’hashing è realizzato cifrando una stringa di zeri, usando come chiave di cifra-

IT Administrator Sicurezza informatica Lezione 3

tura la password e usando il salt di 12 bit al fine di permutare una tabella interna dell’algoritmo DES. In tal modo la cifratura risulta incompatibile con lo standard DES, complicando eventuali tentativi di attacco.
Policy aziendali, raccomandazioni ai clienti e articoli sui media riportano spesso i criteri con cui dovrebbero essere scelte le password, almeno nei casi in cui esse vengano stabilite dagli utenti. In altri casi le password sono generate in modo casuale e risultano abbastanza complesse da essere difficili da indovinare. Alcuni criteri di base per scegliere una password sono i seguenti:
1) lunghezza: più la password è lunga, più è difficile da scoprire: la lunghezza minima è di sei caratteri o più, secondo le dimensioni del set di caratteri;
2) caratteri: idealmente una password dovrebbe contenere minuscole, maiuscole, cifre e altri segni, in modo da aumentare il numero di combinazioni (a parità di lunghezza) e di eludere gli attacchi tramite dizionario;
3) contenuto: dovrebbero essere esclusi nomi di persone, luoghi, aziende, animali, prodotti, targhe automobilistiche, date, parole del dizionario e altri nomi o simboli riconducibili all’utente;
4) assegnazione: per diversi prodotti hardware e software non è obbligatorio specificare nome utente e password: il primo passo consiste quindi nell’assegnare tali valori (che questo sia ancora un problema è testimoniato dal fatto che, nel 2004, il 70% delle reti wireless sia stato installato senza alcuna protezione);
5) periodo di validità: più frequente è la modifica della password, minore è la probabilità di scoperta;
6) cambiamento: ogni password assegnata o scelta da un utente dovrebbe essere nuova e differente;
7) valore di default: molti dispositivi sono posti in commercio con nome utente e password impostati di default, da modificare all’atto dell’installazione;
8) se una password dev’essere annotata o registrata, va conservata al sicuro (in cassaforte, cifrata adeguatamente);
9) memorizzazione: in teoria una password dovrebbe essere lunga, complicata e memorizzata dall’utente senza che ne esista alcuna traccia scritta o registrata, ma una password troppo lunga e complicata è meno sicura perché induce l’utente a scriverla su foglietti facilmente accessibili; un’alternativa a password complicate consiste nell’impiego di password mnemoniche molto lunghe e di passphrase (insieme di parole brevi utilizzate come singola password), che sono una buona protezione anche se contengono parole di soli caratteri.
In base a ricerche statistiche condotte nel 1990, Daniel Klein arrivò alla conclusione che un sistema dovrebbe rifiutare password che abbiano anche una sola delle seguenti caratteristiche:
1) più corta di sei caratteri,
2) contenente il nome dell’utente o una sua parte o le iniziali (anche al contrario),
3) coincidente con una parola del dizionario, una parola con parte delle lettere in maiuscolo, una parola scritta al contrario (magari parte in maiuscolo), una parola con qualche lettera sostituita da un carattere di controllo o da una cifra di ovvio significato (come 1 per I o $ per S),
4) coniugazione di una parola del dizionario,
5) tutta in minuscolo o maiuscolo,
6) non contenente un mix di caratteri, cifre e punteggiatura,
7) corrispondente a un gruppo di caratteri della tastiera (come qwerty),
8) contenente solo cifre, una data o qualcosa di simile a una targa automobilistica.
La tendenza degli utenti a usare nomi e parole facili da ricordare riduce drammaticamente lo spazio delle password definibili con un certo numero di caratteri, spianando la strada agli attacchi tramite dizionario che sono stati

usati nel corso degli anni (a partire dall’Internet worm che nel 1988 penetrò il 5% di Internet). Per esempio, si può calcolare che una password di 10 caratteri (solitamente 80 bit), contenente solo parole della lingua inglese, equivale per efficacia a una password di soli 16 bit in cui vengano utilizzate tutte le combinazioni possibili. A maggior ragione non si dovrebbero usare password numeriche rappresentanti date (facili da ricordare e da scoprire). In particolare, i PIN di quattro cifre (che proteggono ad esempio le Smart Card) dovrebbero essere casuali e non riconducibili a date oppure ad altri valori particolari.
In realtà, i PIN non soddisfano né la prima, né l'ultima delle condizioni e sarebbero una pessima scelta se non avessero l'abbinamento dei dati del token e anche in tal modo aggiungono una sicurezza molto limitata all'uso dei token (come dimostrato dalla facilità di duplicazione dei Bancomat).
Oltre a definire ed applicare una serie di criteri tecnici e amministrativi per definire le password, un’azienda dovrebbe stabilire una policy di sicurezza sulla riservatezza delle password, in modo che in nessun caso esse vengano rivelate a chicchessia. In determinate circostanze, può essere rischioso che ci sia un amministratore che possiede tutte le password; quando la sicurezza lo richieda, si può stabilire una divisione di compiti e di accesso alle informazioni che eviti l’eccessiva concentrazione di poteri e di controllo.
Anche l’assunzione di un dipendente (oppure l’inizio della collaborazione di un consulente) e la cessazione del rapporto di lavoro o di consulenza rappresentano momenti di assegnazione e di revoca delle password, da trattare secondo policy ben definite. In particolare, alla cessazione, le utenze e le autorizzazioni devono essere immediatamente revocate, per impedire accessi non autorizzati alle risorse, remoti o di altro genere.
Se provate a visitare diverse aziende, sia ad alta tecnologia sia a bassa tecnologia, probabilmente scoprirete, sotto il tappetino del mouse dei vari posti di lavoro, un discreto numero di password. Benché possano essere nascoste anche nel cassetto, sotto il tavolo, sotto la tastiera e via dicendo, il mouse pad è la metafora di uno zerbino ed è facile che qualcuno vi nasconda la password così come nasconde la chiave sotto lo zerbino di casa. L’ispezione dei mouse pad e dintorni è uno dei tipi di attacco dall’interno a cui un’organizzazione è soggetta. Le policy aziendali, la sensibilizzazione e l’istruzione del personale dovrebbero convincere gli utenti ad evitare i comportamenti insicuri a favore di pratiche più efficaci.
Data la velocità con cui un computer può cercare d’indovinare una password, il numero di tentativi di login dovrebbe essere limitato: raggiunto il numero stabilito di errori nell’inserire il nome utente e la password, il sistema dovrebbe bloccare ulteriori tentativi o richiedere una nuova procedura di collegamento. Tra i vari tentativi viene sempre inserito un ritardo al fine di rallentare le operazioni di “password guessing”.
Un’altra misura precauzionale da adottare è la registrazione in un file di log dei tentativi di accesso falliti (omettere le password errate evita di favorire attacchi interni). Un sistema dovrebbe avvertire l’amministratore in presenza di numerosi tentativi di accesso con password errata; dovrebbe avvertire anche un utente, al login, se al suo nome utente sono associati parecchi tentativi di accesso falliti.
Password interne ed esterne
Spesso si fanno considerazioni sulla scelta delle password senza distinguere se si tratti di password usate all’interno dell’organizzazione (dove gli estranei non mettono piede) o usate per accedere dall’esterno della rete. L’uso consigliato delle password varia secondo che gli utenti siano insider (personale dell’azienda) o outsider (come i

Lezione 3 IT Administrator Sicurezza informatica

clienti che si collegano via Internet).
All’interno dell’azienda le password servono all’autenticazione dei dipendenti e di solito non forniscono un alto livello di protezione, visto che gli utenti hanno accesso fisico al sistema. Un attacco dall’interno ha vari mezzi a disposizione, dall’uso dei dizionari delle password più usate allo sniffing di ciò che viene trasmesso in rete. Per tale motivo è superfluo imporre agli utenti interni password complicate. Al contrario, sono consigliabili i seguenti criteri:
1) usare password mnemoniche (affinché non vengano scritte), ma difficili da indovinare anche per amici e colleghi. Evitare qualsiasi nome o argomento che è noto oppure è stato discusso con i colleghi, scegliere semmai qualcosa di personale che non viene mai rivelato ad altri. Conviene in ogni caso verificare le password così generate mediante un verificatore automatico che le scarta se deboli ad un attacco basato su dizionario.
2) disabilitare la scadenza della password, che induce gli utenti ad annotare le password, è comunque un metodo poco diffuso e poco condiviso, e solitamente utilizzato in abbinamento al successivo.
3) incoraggiare gli utenti a cambiare password in occasione dei cambiamenti di configurazione del computer,
4) tenere i server e i dispositivi di rete sotto chiave;
5) i posti di lavoro dedicati ad applicazioni critiche (come paghe e stipendi) dovrebbero essere situati in stanze separate chiuse a chiave e non restare mai incustoditi. Tale precauzione è efficace a condizione che tali posti di lavoro siano accessibili solo da consolle e non anche da rete.
6) i sistemi a cui si accede tramite single sign-on (sign-on ossia registrazione singola per tutti i sistemi della rete) non usano password “interne”, ma solo “esterne”,
7) le password degli amministratori devono essere più forti di quelle degli utenti interni, visto che rappresentano un target più ambito per eventuali attacchi.
In pratica, all’interno dell’azienda si cerca di mediare tra usabilità e sicurezza: una password troppo complicata per essere usabile diventa una minaccia alla sicurezza quando è scritta sotto la tazza portamatite.
All’esterno, invece, una password è più complessa ed è protetta con metodi crittografici, ma è vulnerabile ad attacchi tramite dizionario. In un’azienda, le connessioni remote dovrebbero ricevere un trattamento diverso rispetto alle connessioni interne ed essere filtrate da un dispositivo di sicurezza.
In passato, il punto di filtro era tipicamente il Network Access Server (NAS) per le connessioni telefoniche (dial-in) visto che la gran parte degli attacchi avveniva via modem. Oggi si utilizzano invece firewall per le connessioni in arrivo da Internet. Volendo consentire l’accesso dall’esterno a sistemi interni si utilizza tipicamente una VPN (Virtual Private Nework).
Le password esterne dovrebbero essere resistenti agli attacchi di tipo dizionario, il che si ottiene usando password abbastanza complicate e cambiandole periodicamente. Se la risorsa da proteggere ha particolare valore, allora la password è un meccanismo di protezione inadeguato e dovrebbe essere sostituita da metodi basati su token.
Ecco quindi alcune raccomandazioni per la sicurezza delle connessioni esterne:
1) se il sistema gestisce informazioni di particolare valore, anziché normali password si dovrebbero usare token con password single-use, Smart Card, token USB e simili,
2) le connessioni esterne dovrebbero usare protocolli che impediscano il rerouting (instradamento verso destinazione diversa) della connessione,
3) le password esterne dovrebbero resistere agli attacchi di tipo dizionario,
4) le password esterne dovrebbero essere cambiate perio-

 

dicamente,
5) le password esterne dovrebbero essere fisicamente protette dagli attacchi interni,
6) le password esterne usate su computer portatili non devono essere conservate sul computer.
Un buon modo per scegliere una password memorizzabile che resista ai dizionari è il seguente:
1) scegliere una password a caso secondo i criteri visti per le password interne,
2) scegliere una seconda password a caso, affinché non abbia alcuna relazione con la prima,
3) scegliere a caso una cifra o segno di punteggiatura come carattere intermedio,
4) costruire la password forte concatenando la prima password debole, il carattere intermedio e la seconda password debole,
5) esaminare il risultato e trovare qualche modello strutturale, ritmo, ripetizioni o qualsiasi significato che permetta di memorizzarlo senza doverlo scrivere.
Per esempio, “frantumi5bistecca” è una password resistente, ma abbastanza facile da ricordare.

Token
Autenticazione tramite token
Tra le tante definizioni della parola token, la più vicina all’uso in campo informatico è “gettone”, un oggetto simile a una moneta usato da un certo gruppo di utenti per pagare qualcosa o per un impiego specifico. Il concetto si è esteso ai “gettoni” immateriali che non hanno la forma di una moneta, ma che sono comunque oggetti fisici usati da un gruppo secondo regole specifiche. Esempi in tal senso sono i gettoni che viaggiano su una LAN Token Ring (che usa appunto il gettone per assegnare il turno di trasmissione ai vari computer collegati) e i gettoni impiegati dai dispositivi di autenticazione.
Un token è un fattore di autenticazione della categoria “qualcosa che hai”; l’utente dev’essere in possesso del token al fine di essere autenticato dal computer. Se il token viene smarrito, rubato o prestato, l’utente non ha modo di farsi autenticare, come un tempo accadeva per una chiave o un sigillo personale.
Dal punto di vista della sicurezza, un token ha alcune proprietà fondamentali:
1) la persona dev’essere in possesso fisico del token per poterlo usare,
2) un buon token è molto difficile da duplicare,
3) una persona può smarrire un token e con esso perdere l’accesso a risorse critiche,
4) l’utente si accorge del furto di un token facendo l’inventario dei token in suo possesso.

IT Administrator Sicurezza informatica Lezione 3

Rispetto a una password, un token offre notevoli benefici:
1) elimina il fardello di dover ricordare password complicate,
2) può contenere un dato segreto molto più complesso di quanto sia memorizzabile da una persona,
3) è spesso associato a un secondo fattore di autenticazione, come un PIN memorizzato dall’utente,
4) un token attivo può generare un output diverso in diverse circostanze oppure ad ogni utilizzo.
Oggi un token può assumere i formati e le dimensioni più svariate: una carta di credito, una chiave, una calcolatrice, un anello e altro ancora. Da un punto di vista funzionale, la principale distinzione è tra token passivi, che si limitano a memorizzare dati, e token attivi, dotati di capacità di elaborazione.
Token passivi
Una carta di credito e una scheda Bancomat di vecchia generazione (prive cioè di processore) sono esempi di token passivi, perché i dati identificativi sono registrati su una striscia magnetica. Il lettore riceve sempre gli stessi dati a ogni autenticazione; per sicurezza, può essere richiesto un secondo fattore di identificazione, come il PIN per le schede Bancomat o il codice di sicurezza stampato sul retro delle carte di credito.
I token passivi possono essere “chiavi” con una memoria di sola lettura, schede con una certa struttura di perforazione, schede con codice a barre e schede a prossimità, cioè dispositivi a induzione che rispondono con un certo segnale quando avvicinati al lettore.
Un vecchio esempio di token passivo è la “datakey” (chiave con ROM) di Datakey (poi fusa con SafeNet). Più recente è la XyLoc di Ensure Technologies, che viene indossata e permette l’autenticazione via radio quando l’utente si trova entro un certo raggio dal computer.
Tra gli esempi più economici e diffusi ci sono i badge di accesso, cioè schede di plastica con striscia magnetica a cui è associato un PIN da digitare sulla tastiera numerica del lettore.
Il problema principale dei token passivi è la facilità di duplicazione; inoltre il PIN può essere scoperto osservando l’utente oppure in altri modi (intercettazione, reverse engineering del token, complicità del personale).
Token attivi
A differenza dei token passivi, quelli attivi non trasmettono il proprio dato segreto per autenticare l’utente, ma lo utilizzano per qualche calcolo, come la generazione di una one-time password, cioè una password usata una volta sola (e quindi ogni volta diversa). Sebbene i token di tipo onetime password affondino le proprie radici nei decenni passati, questa è la tecnologia tradizionale usata da vari prodotti delle famiglie SafeWord, SecuirID, CryptoCard e altri. A questi si sono aggiunti numerosi prodotti basati sulla crittografia asimmetrica e i certificati a chiave pubblica, sotto forma di Smart Card, chiavi USB e altro.
I token attivi usano solitamente tecniche crittografiche che li rendono immuni da intercettazioni e replay dei messaggi. Ogni volta che l’utente si connette per autenticarsi, vengono generati messaggi diversi, in modo da vanificare

la registrazione e la ripetizione dei messaggi.
Esistono token attivi con e senza tastiera; alcuni s’interfacciano direttamente col computer (per esempio via USB), altri richiedono un lettore particolare (per esempio le Smart Card e i token iButton) o un adattatore PCMCIA (disponibile per le Smart Card). Dato che la crittografia a chiave pubblica viene trattata a parte e per molti aspetti è stata introdotta nella lezione 2 (Crittografia), qui ci occupiamo soprattutto di token del tipo one-time password. Essi seguono generalmente uno tra i due metodi fondamentali per generare la password: il metodo basato su contatore oppure il metodo basato sull’orologio. In qualche caso vengono adottati entrambi.
Una data significativa per l’adozione di sistemi basati su one-time password generate da token a contatore è il 1994, quando furono adottati da Citybank in risposta a una truffa di vaste proporzioni. Un gruppo di russi, dopo aver rubato le password di vari funzionari della banca, aveva disposto una serie di trasferimenti attraverso mezzo mondo. I token di questo tipo incorporano un contatore che viene usato per generare una nuova password a ogni collegamento.
Al momento del login, l’utente preme un pulsante sul token, il contatore viene incrementato e una funzione hash riceve in input il valore del contatore e il dato segreto memorizzato nel token; il risultato compare sul display del token e l’utente lo utilizza come password di login. Se la password viene intercettata e riutilizzata, sarà considerata invalida.
Un esempio di token a contatore è SafeWord, un token a forma di chiave prodotto da Secure Computing. L’algoritmo di hashing varia a seconda dei prodotti. Per funzionare, un sistema a contatore deve tenere sincronizzati il contatore sul token e quello sul computer; un amministratore imposta i valori iniziali. Nel caso di SafeWord, ciò avviene mediante un dispositivo che si collega ai sette contatti presenti frontalmente sul token. Opzionalmente, può essere richiesto un PIN prima dell’emissione della password, in modo da neutralizzare il possibile furto oppure l’uso abusivo del token.
In caso di perdita del sincronismo del contatore, il server SafeWord utilizza l’ultima password ricevuta (e conservata) e verifica se le password successive (incrementando il contatore) possono essere state prodotte dallo stesso token, sincronizzando di nuovo il proprio contatore. Nel caso un token a contatore venisse duplicato, il sistema si comporterà in modo erratico, alternando successi, fallimenti e ri-sincronizzazioni che indicano la presenza di due token con lo stesso dato segreto.
Il token SecurID di RSA Security, molto diffuso nonostante l’età, utilizza l’orologio anziché un contatore. Ogni 60 secondi la funzione hash, in base al valore dell’orologio e al dato segreto, genera una password one-time. Il server mantiene il proprio orologio e accetta la password se si trova all’interno di una data finestra temporale. Token e server sono sincronizzati con l’UCT (Universal Coordinated Time – l’ora del meridiano di Greenwich). Con l’invecchiamento, il clock dei token può scostarsi da quello del server, ma quest’ultimo conserva informazioni per la correzione. Se dopo un lungo periodo il token si collega e risulta fuori dalla finestra temporale di accettazione, il server rifiuta l’autenticazione, ma al successivo login, se rileva lo stesso errore temporale, aggiorna le informazioni sullo scostamento di quel token, ri-sincronizzandosi. I token SecurID sono prodotti in vari formati hardware (a scheda e a chiave anche con collegamento USB al computer, per non dover digitare la password) e nella versione software.
PIN
Il punto debole dei token è che possono essere rubati (oppure “presi a prestito”) e utilizzati per commettere un crimine. La soluzione comune è di associare al token un PIN

Lezione 3 IT Administrator Sicurezza informatica

che ostacoli l’uso del token almeno per il tempo necessario ad accorgersi del furto e reimpostare il server in modo che non accetti le password di quel token. Il PIN di un token può essere utilizzato in vari modi, tra cui i seguenti:
1) PIN concatenato a una password esterna: il PIN viene combinato ad altre informazioni, come la password onetime generata dal token, e il tutto è inviato al server. Al login, l’utente digita la password generata (visualizzata sul display del token) seguita dal PIN. Tale approccio è adottato da SecurID e da altri prodotti. Il rischio è che il PIN sia visto e che il token sia rubato.
2) PIN come password interna: il PIN è impostato nel token e nessun altro ne ha visibilità. Dato che in questo caso il PIN è digitato sulla tastiera del token, si possono impostare diversi comportamenti in caso di PIN errato: ritardare l’accesso o bloccare il token, riportare l’accesso errato in modo che il titolare ne sia informato e via dicendo. Di base, a fronte di un PIN errato, il token dovrebbe ritardare progressivamente le operazioni al fine di dare tempo all’utente d’intervenire. Tale implementazione del PIN consente, come nel caso di certi token SafeWord, di riconoscere un particolare valore di PIN (quello corretto meno uno) come segnale di allarme, perché l’utente è sotto minaccia. Il PIN come password interna è vulnerabile in caso di implementazione software, visto che possiede tutte le informazioni che potrebbero servire in caso di attacco.
3) PIN come parte del dato segreto: questo approccio risolve il problema dell’implementazione software, dato che il token non memorizza il valore del PIN e neppure il completo dato segreto. La password è generata inserendo il PIN, calcolando l’hash in base al PIN e al segreto parziale e calcolando la password in base all’hash e al valore del contatore o dell’orologio. In questo modo, un login errato viene scoperto solo al tentativo di connettersi al server e l’attaccante non ha modo di eseguire tentativi senza che vengano registrati nel file di logging. Di conseguenza, se i tentativi vengono segnalati, si possono predisporre tempestivamente le difese.
Challenge
Una variante di token di autenticazione utilizza il cosiddetto challenge response. Al momento del login, il token riceve dal server un dato (challenge, ossia sfida) e lo elabora appropriatamente, utilizzando il proprio dato segreto, per fornire la risposta (response) che attesta la corretta identità dell’utente. Esempi di token che supportano questo tipo di autenticazione si trovano nelle famiglie SafeWord, WatchWord e CryptoCard.

Biometria
Schemi di autenticazione biometrica

La biometria è la scienza e tecnologia dell’autenticazione (stabilire l’identità di un individuo) misurando le caratteristiche fisiologiche o comportamentali di una persona. Il termine deriva dalle parole greche “bios” (vita) e "metron" (misura), quindi è applicabile a particolari caratteristiche di un corpo umano vivo o ad alcuni tratti comportamentali di un individuo, misurabili e utili per l’identificazione.
Le caratteristiche fisiche utilizzate per l’autenticazione biometrica sono diverse:
1) impronte digitali. Usate da un secolo e mezzo, mantengono la loro reputazione di unicità per ogni individuo, gemelli inclusi. Gli scanner di impronte sono molto diffusi e hanno un basso costo, molto inferiore a quello degli altri dispositivi biometrici.

 

2) Geometria delle mani: rispetto alle impronte digitali, che richiedono mani pulite, ha il vantaggio di poter essere usata anche in condizioni ambientali difficili, come fabbriche e cantieri.
3) Retina: la sua scansione è utilizzata in installazioni militari e governative. Il modello dei vasi sanguigni della retina è unico e stabile, sebbene siano possibili variazioni (come durante la gravidanza). La fotografia della retina richiede un’esposizione prolungata a bassa intensità luminosa ed è vista come una procedura intrusiva, sebbene non rechi danno agli occhi.
4) Iride: come per la retina, la sua scansione fornisce un modello unico e stabile ed è oggi una delle tecnologie in rapida ascesa per l’adozione in aeroporti e controlli dell’immigrazione. La foto è ripresa da una certa distanza e presenta difficoltà simili a quelle della retina.
5) Riconoscimento del volto: è un metodo particolarmente flessibile e può essere utilizzato all’insaputa della persona oggetto della scansione (con i relativi pro e contro). Può essere usato per cercare un individuo nella folla, a patto che raggiunga la necessaria precisione di riconoscimento. Negli ultimi tempi negli USA si sono registrati fallimenti clamorosi .
6) Impronta vocale: come il riconoscimento del volto, l’analisi della voce può essere usata all’insaputa dell’interessato. E’ possibile falsificarla manipolando una registrazione, ma imitare la voce di un altro non trae in inganno un analista esperto. Questa caratteristica a volte è elencata nella categoria dei tratti comportamentali, dato che non si basa sull’osservazione di una parte del corpo.
Altre caratteristiche comportamentali sono:
1) firma autografa. I sistemi di riconoscimento affidabili la confrontano con una registrazione che comprende la dinamica del movimento della penna da parte dell’utente. Di solito, comunque, la verifica della firma è abbinata ad altri metodi di autenticazione e serve soprattutto per rilevare firme falsificate.
2) Dinamica della digitazione su tastiera: esistono alcuni sistemi che riconoscono il comportamento dell’utente durante la battitura, come il ritardo tra pressione e rilascio dei tasti e il tempo che intercorre tra la pressione di varie coppie di tasti. Un vantaggio è che non occorre hardware aggiuntivo.
La diffusione dei dispositivi biometrici ha subito un forte impulso dal settembre 2001, quando è iniziato un processo di progressivo spostamento del punto di equilibrio tra esigenze di sicurezza e garanzie personali (a partire dalla privacy). Oggi sono già istallati in varie nazioni dispositivi biometrici per il controllo delle frontiere che sono basati sulla scansione delle impronte digitali o della retina.

IT Administrator Sicurezza informatica Lezione 3

Quelle che oggi sono installazioni sperimentali, che richiedono il consenso dell’individuo, sono destinate a diventare prassi generalizzata. Entro pochi anni è previsto che i dati biometrici siano registrati nei passaporti. A seguito della rapida espansione della biometria nel settore pubblico, è prevedibile che anche il settore privato adotti le stesse tecnologie di autenticazione, nonostante quelle biometriche siano probabilistiche (non funzionano nel 100% dei casi) e non siano prive d’inconvenienti, sia tecnici sia di altra natura. Per esempio, non c’è nessuna garanzia che un database d’impronte biometriche, oggi garantito impermeabile a utilizzi volti al controllo delle persone (ubicazione, abitudini, acquisti, comportamenti, eccetera), un domani non venga usato contro ogni diritto alla privacy per presunti motivi di sicurezza.
L’approvazione del Real Id Act negli USA impone ai cittadini, entro maggio 2008, di avere un documento di identità digitale (con incorporato chip RFID di trasmissione radio – Radio Frequency Identification) per poter guidare un veicolo, prendere un aereo, aprire un conto bancario e accedere ai servizi pubblici.
Inoltre la legge consente al dipartimento per la sicurezza nazionale (Homeland Security) di chiedere l’inclusione di dati biometrici nel documento di identità (impronte digitali o scansione della retina o dell’iride) in aggiunta alla foto, indirizzo e altri dati personali.
Anche la letteratura sui dispositivi biometrici, piuttosto asettica e imparziale fino al 2001, nel momento in cui ingenti finanziamenti sono confluiti nel settore della sicurezza, ha subito le pressioni di interessi economici e di posizioni dominanti (come quella legata alla scansione dell’iride).
Oggi, per valutare correttamente le tecnologie biometriche disponibili e le proposte dei produttori, è consigliabile estendere l’indagine a fonti di informazione che presentino i rispettivi pro e i contro, incluse le eventuali forzature motivate da obiettivi commerciali. Ne è un esempio la polemica intorno alla scansione dell’iride, che vede contrapposte le valutazioni di chi ha ottenuto i brevetti (John Daugman, http://www.cl.cam.ac.uk/users/jgd1000) e le controdeduzioni di chi lo accusa di disinformazione (www.irisward.com/TEMP/02-cadre.html); altre fonti, come http://www.iris-recognition.org, sono più neutrali. Dopo la fusione tra le aziende IriScan e Sensar, Iridian Technologies è oggi il detentore dei brevetti e il principale protagonista in questo settore.
Funzionamento
Il principio base di funzionamento è lo stesso per tutti i sistemi biometrici. Ogni sistema usa un sensore per raccogliere in forma digitale i dati corrispondenti a una misura biometrica. Il sensore può essere ad esempio uno scanner apposito per l’impronta digitale o una speciale fotocamera usata per riprendere l’immagine dell’iride. In entrambi i casi sono state dimostrate le possibilità di falsificazione, che possono essere sventate migliorando i sensori (per esempio rilevando temperatura, conducibilità e altri indicatori di un dito vivo) e presidiando il sensore (per evitare di autenticare la foto di un occhio).
A partire dalla misura digitale fornita dal sensore, vengono estratte le caratteristiche individuali, che permettono di differenziare un individuo da un altro; per esempio, nel caso dell’iride, ci sono oltre 200 punti da esaminare. Il processo di estrazione fornisce un’impronta o “firma” biometrica, che all’atto dell’autenticazione viene confrontata con i modelli biometrici archiviati in un database.
Il confronto fornisce generalmente una corrispondenza parziale: se lo scostamento è inferiore alla soglia di accettazione, l’autenticazione è positiva, altrimenti è rifiutata. Idealmente, il processo di registrazione dell’impronta biometrica di riferimento dovrebbe sfruttare tutte le occasioni in cui vengono confrontate due misure dello stesso sog-

getto per affinare e adattare l’impronta campione e ridurre la probabilità di falsi rifiuti.
Usi
Sebbene la biometria sia qui citata nel contesto delle tecniche di autenticazione, è utile sapere che essa può servire a tre diversi campi di utilizzo:
1) autenticazione: l’accertamento che l’impronta biometrica sia (con buona probabilità) proprio quella dell’utente che la presenta;
2) identificazione: dato un campione biometrico, si vuole scoprire a quale individuo esso appartiene (o perlomeno a quale rosa di “sospetti”, visto che questo uso è tipico delle forze di polizia);
3) unicità: dato un campione biometrico, si vuole verificare se il suo proprietario è già in un certo database (per esempio per evitare di accordare due volte un certo beneficio sociale alla stessa persona o di permettere l’immigrazione di individui già espulsi).
Precisione
La precisione di un dispositivo biometrico (sempre inferiore al 100%) è misurata dalla stima delle false accettazioni (impronte biometriche non registrate nel database, ma erroneamente riconosciute come valide) e dei falsi rifiuti (impronte valide ed erroneamente rifiutate). La precisione viene stimata leggendo i campioni biometrici da un’ampia popolazione di prova e confrontandoli con le impronte registrate in un database.
Le due curve FAR (False Acceptance Rate, tasso di false accettazioni) e FRR (False Rejection Rate, tasso di falsi rifiuti) si incrociano nel punto ERR (Equal Error Rate, pari tasso di errori), che generalmente corrisponde al miglior punto di taratura del lettore biometrico. Il valore di FAR indica la sicurezza del lettore biometrico ed è paragonabile al numero di bit di una password.
Un FAR di 1 su 100.000 per un lettore biometrico corrisponde circa a una password di 16 bit. Abbassando il FAR si alza però l’FRR, che rappresenta l’usabilità del sistema (i falsi rifiuti impediscono agli utenti autorizzati l’accesso al sistema), quindi occorre bilanciare sicurezza e usabilità.
Segretezza
Chi intercetta o entra in possesso di un’impronta biometrica può tentare di impersonare il proprietario di quell’impronta o, peggio, monitorare gli spostamenti e i comportamenti di tale individuo. Ne possono seguire truffe, crimini commessi a nome altrui e gravi violazioni della privacy.
Un sistema biometrico per autenticazione locale, incluso cioè in un perimetro di sicurezza, è relativamente sicuro. Lo stesso non vale per i sistemi distribuiti in rete, che devono ricorrere a tecniche di crittografia per proteggere la riservatezza dei dati trasmessi. Una soluzione è cifrare i dati biometrici con una chiave pubblica prima di trasmetterli e decifrarli in ricezione con la corrispondente chiave privata.
Non si possono usare le funzioni hash nel confronto tra impronte biometriche lette e archiviate perché a piccole variazioni di un’impronta biometrica corrisponderebbero ampie variazioni dell’hash, impedendo il riconoscimento. In pratica, un’impronta biometrica serve per autentica-
re una persona, ma per evitare falsificazione nella trasmissione dei dati, non si può fare a meno di autenticare a loro volta, per esempio con una coppia di chiavi per crittografia asimmetrica, i dati biometrici.
La cifratura dei dati biometrici dovrebbe rispondere, in qualche misura, anche alle esigenze delle normative sulla privacy. Il settore privato sarà chiamato a rispondere della privacy dei dati biometrici conservati nei database; i settori e le agenzie governative nel mondo si sono mostrati invece propensi a sacrificare la privacy re-interpretando, di

Lezione 3 IT Administrator Sicurezza informatica

volta in volta, le esigenze di sicurezza nazionale nel senso di una riduzione effettiva del diritto individuale alla non divulgazione d’informazioni personali.
Autenticazione in rete
Per risolvere il problema di autenticare un soggetto – sia esso un utente o un processo – in contesto di rete si deve fare i conti con il problema di trovare un compromesso fra modalità operative ragionevolmente semplici, un onere amministrativo non eccessivo (per i sistemisti che hanno in gestione le macchine) e un livello di sicurezza accettabile. Questi problemi derivano dal fatto che da un lato l'utente non desidera dover ricordare e usare troppe password diverse, né l'amministratore vuole dover configurare e mantenere un numero eccessivo di profili e password, e d'altra parte si desidera che anche la sicurezza di ogni singolo sistema inserito in rete non sia troppo inferiore a quella che avrebbe se fosse isolato.
Si consideri innanzitutto il fatto che, se l'accesso a un sistema B avviene remotamente agendo da un sistema A, resta ovviamente necessario che l'utente abbia accesso (cioè disponga di una username e password) sul sistema B, ma occorre anche, in generale, che disponga di un login sul sistema da cui effettua l'accesso, ossia A. Per evitare che l'utente debba ricordare coppie login/password per troppi sistemi diversi si potrebbe decidere di adottare account uguali (con password uguali) su A e su B. Così facendo lo username e la password da digitare sarebbero gli stessi su entrambi i sistemi e l'utente avrebbe meno segreti da ricordare. Tuttavia egli sarebbe ancora costretto a ripetere la manovra di login (seppure con dati sempre uguali) a ogni accesso remoto, senza contare che dovrebbe effettuare l'operazione periodica di cambiamento delle password sia su A sia su B.
In ambiente Windows è possibile semplificare le cose organizzando i server in un unico "dominio": con tale termine s’intende un raggruppamento logico di server di rete e altri host che condividono le informazioni sui profili utente e altre impostazioni di security. In un dominio esiste sempre un database principale (Primary Domain Controller, PDC) che contiene tali informazioni ed è inoltre possibile, opzionalmente, replicare per sicurezza tale database su una o più altre macchine (Backup Domain Controller, BDC), che vengono mantenute aggiornate mediante operazioni periodiche di "sincronizzazione". Nel dominio possono, poi, esistere macchine sempre con funzioni di server (e che per la gestione di profili utente si appoggiano al PDC), ma su cui non risiede né una copia primaria né una secondaria del database di dominio. In terminologia Windows, tali host sono chiamati "member servers".
Una volta effettuate le impostazioni necessarie, l'utente ha il vantaggio di dover ricordare una sola password valida per tutte le macchine che partecipano al dominio; inoltre, nelle utility di Windows che mostrano elenchi di risorse di rete disponibili, quelle del dominio saranno raggruppate sotto un unico "cappello", rendendo più facile la consultazione (soprattutto in reti di grandi dimensioni). Anche l'amministratore avrà vantaggi non indifferenti, potendo effettuare la gestione degli account in modo centralizzato, e senza bisogno di tediose ripetizioni, qualunque sia il numero delle macchine facenti parte del dominio.
Sotto Linux esistono diverse strategie (tra le quali anche un'architettura basata su Kerberos, equivalente, per concezione e per tecnologia crittografica sottostante, all'approccio adottato da Windows) per semplificare la situazione degli account multipli. Con la più semplice di esse è possibile, in sostanza, fare in modo che il sistema B "si fidi" dell'autenticazione avvenuta su un altro sistema A identificato dal suo nome logico. Ciò avviene scrivendo specifiche righe nel file .rhosts presente nella home directory dell'u-

tente U (sul file system del sistema B). Quando l’utente di nome U, già autenticato nel sistema A, tenta di collegarsi a B fornendo la stessa username U (o un'altra username prestabilita, U2), il sistema B, consultando il corrispondente file .rhosts, conclude che per tale connessione proveniente da A e tentata dall'utente U non occorre chiedere la password.
È ovvio che questo tipo di configurazione include anche la macchina A nel "perimetro" entro il quale occorre vigilare perché non si verifichino violazioni di security. Infatti, se la security del sistema A fosse violata, per proprietà transitiva risulterebbe violata anche quella di B, dal momento che questo accetta senza ulteriori controlli i login provenienti da A. La situazione può essere paragonata a quella dello "spazio Schengen" nell'Unione Europea, con l'abolizione delle frontiere interne, e alla questione del controllo delle frontiere esterne degli Stati membri.
Nel caso in cui le home directory degli utenti appartengono a un file system esportato via NFS, il sistema potrebbe essere esposto a un semplice attacco qualora NFS e permessi di scrittura siano configurati in modo troppo "permissivo". Un utente potrebbe infatti montare da un sistema C il file system delle home directories del sistema B e scrivere o modificare un file .rhosts in modo tale da assicurarsi l'accesso al sistema B senza digitare né conoscere alcuna password. Sarà poi sufficiente che egli definisca sul sistema C (sul quale deve avere privilegi di amministratore, cosa che su un PC è quasi la norma) un utente dal nome uguale a quello per il quale ha alterato il file .rhost su B, e poi effettui un remote login da C a B con tale username.
Un secondo aspetto da affrontare è invece legato alla "vulnerabilità" della comunicazione tra A e B. I pericoli in-

IT Administrator Sicurezza informatica Lezione 3

siti in tale comunicazione (che, ricordiamolo, generalmente implica sotto qualche forma uno scambio via rete di username e password) sono essenzialmente due. Quello fondamentale è il rischio di intercettazione dei messaggi scambiati all'atto del login, con conseguente compromissione della segretezza della password utilizzata. L'altro, che ne è la logica conseguenza, è il rischio che una volta così ottenuta la conoscenza di una username U e della relativa password valida, qualche soggetto terzo "impersoni" l'utente legittimo U, collegandosi a B da A o anche da una macchina C diversa da A fornendo le credenziali di U. Soprattutto se C è un PC, può risultare relativamente semplice disporre dei permessi di amministratore, coi quali è possibile creare il profilo U. Una blanda linea di difesa contro tale attacco consiste nell'impostare B in modo tale che accetti connessioni solo da indirizzi IP noti e "fidati": ad esempio, per il servizio telnet, in diversi ambienti Linux, si agisce sul file /etc/xinetd.d/telnet scrivendo una clausola only_from che includa tutti e soli gli indirizzi dai quali si accetteranno connessioni. Naturalmente tale protezione può essere facilmente vanificata poiché è banale impostare il PC in modo tale che abbia un indirizzo di rete identico a uno di quelli "fidati" e, avendo accesso alle connessioni fisiche di rete, collegarlo poi al posto della macchina da impersonare.
Per una sicura e affidabile autenticazione "da remoto" di U sul sistema B è necessario perciò che sussistano contemporaneamente diverse condizioni: il fatto che U si colleghi a B da un sistema A identificato ed il cui livello di security sia ritenuto adeguato; il fatto che U si sia autenticato anzitutto su A e poi su B utilizzando le credenziali di cui dispone su tali due sistemi, oppure che il sistema B accetti per vera l'autenticazione già avvenuta su A; infine, nel caso in cui per qualsiasi motivo si renda necessario uno scambio in rete fra B e A di informazioni sensibili concernenti identità e password di U, che tale scambio sia protetto. Schemi e strategie di autenticazione di rete si prefiggono l'obiettivo di assicurare il rispetto di queste condizioni.
Requisiti per l’autenticazione su host e in rete
Lo schema classico per l'autenticazione locale di un utente su un host (o più in generale di un soggetto – come un processo che può effettuare azioni: con terminologia Windows, come già accennato, si parla di Security Principal) si basa sulla conoscenza di una password che deve essere fornita insieme al proprio username all'atto del login. La tecnica non richiede all'utente eccessivi sforzi mnemnonici e, a patto che sia stata scelta una password "forte" (ossia non facile da indovinare), tenuta rigorosamente segreta dal titolare e memorizzata dal sistema in modo ben protetto, offre una discreta sicurezza. Non appena tale schema di autenticazione viene utilizzato per l'accesso da remoto al sistema, però, sorge immediatamente il problema della possibile intercettazione del messaggio contenente login e password, che deve per forza di cose transitare sulla rete. In tale scenario quindi le cose si complicano.
Tutti gli schemi di autenticazione in rete si basano sull'applicazione di un qualche ben definito protocollo per lo scambio di messaggi. Tale scambio interessa come minimo le due parti fondamentali in causa, ossia il client (che chiede di essere autenticato) e il server (che deve erogare il servizio, o consentire un accesso, dopo essersi convinto della autenticità del client), anche se, come vedremo, in alcuni schemi possono comparire anche ruoli terzi, come un server di autenticazione, di cui entrambe le parti si fidano e che diventa depositario di determinati segreti o al quale vengono deputate alcune decisioni chiave.
Poiché i messaggi che si scambiano le due parti possono essere intercettati, esaminati, ricordati e poi ritrasmessi (intatti o modificati) da un attaccante, è assolutamente

necessario prevedere un’adeguata protezione crittografica che contrasti tali tecniche: in virtù della stessa è possibile fare in modo che (1) per qualunque terzo non autorizzato i messaggi intercettati risultino incomprensibili, che (2) risulti impossibile modificarli in modo da non lasciare tracce e che (3) risulti anche del tutto inutile archiviare un messaggio intercettato (pur non avendolo potuto decifrare) e riproporlo invariato in seguito nel tentativo di ottenere una "replica" di un qualche effetto desiderato.
E' ovvio che per cifrare i messaggi in transito occorre che mittente e ricevente si accordino su quale algoritmo usare e, cosa ben più delicata, sulle chiavi crittografiche. Per molte applicazioni è accettabile utilizzare algoritmi simmetrici a chiave segreta (la stessa chiave viene usata sia per cifrare sia per decifrare); in tal caso la chiave dev'essere nota a tutte le parti in causa, che devono anche provvedere a memorizzarla in modo sicuro e non facilmente violabile. Se questo non è possibile o non è ritenuto abbastanza sicuro, esistono tecniche, basate su particolari proprietà matematiche, che consentono di concordare "al volo" tra due parti una chiave segreta scambiandosi apertamente messaggi (in chiaro), senza che tuttavia qualcuno in ascolto possa ricavare la conoscenza della chiave segreta dai messaggi intercettati (protocollo Diffie-Hellman).
Infine, è possibile utilizzare schemi di autenticazione basati sull'uso di algoritmi crittografici a chiave pubblica, in cui il problema della segretezza e della condivisione delle chiavi risulta alleviato in modo sostanziale (vedi lezione 2).
Protocolli per l’autenticazione degli utenti
Meritano un cenno, a questo punto, due protocolli per l'autenticazione in rete degli utenti.
Il più semplice è il Password Authentication Protocol (PAP), denominazione fin troppo enfatica per una banale procedura che essenzialmente prevede l'invio dal client al server di uno username (in chiaro) e successivamente di una password (eventualmente cifrata). Il server confronta le due informazioni con quelle detenute nel suo archivio di dati segreti e in base al risultato conferma o rifiuta l'autenticazione.
Il grosso limite di PAP sta nella sua vulnerabilità rispetto alle intercettazioni (specialmente nel caso in cui non sia usata crittografazione per la password) ed agli attacchi ripetitivi volti a indovinare la password per tentativi.
Una versione più sicura è il Challenge Handshake Authentication Protocol (CHAP) in cui il server manda anzitutto al client una stringa casuale (detta in gergo "challenge", o "sfida", in quanto presuppone una "risposta"). La stringa è casuale per generare messaggi ogni volta diversi, al fine di ostacolare tentativi di attacco di tipo replay o attacchi statistici sui messaggi di autenticazione. Per escludere con elevata sicurezza il rischio di attacchi statistici, la stringa challenge è lunga ben 8 byte, il che significa che esistono 2^64 stringhe possibili (18 miliardi di miliardi). Se il generatore di numeri casuali ha buone proprietà statistiche, la challenge string dovrebbe risultare praticamente sempre diversa.
Il client utilizza la stringa challenge e, combinandola in modo prestabilito con la chiave segreta da trasmettere, calcola un one-way hash (checksum crittografico irreversibile) sul complesso dei due dati. È tale hash, e non la chiave, che il client spedisce, poi, al server.
Per verificare la validità dell'autenticazione del client, al server basterà effettuare la stessa operazione appena eseguita dal client (il challenge è ovviamente noto al server che lo ha "inventato", così come gli è nota la chiave che occorre verificare) e confrontare l'hash ottenuto sui suoi dati con quello appena inviatogli dal client. Nel caso i due hash coincidano, si può essere ragionevolmente sicuri che il messaggio non possa che provenire dal client (a rigore: da qualcuno che conosce la chiave, ma ai nostri fini ciò è quello che conta), che viene così autenticato.

Lezione 3 IT Administrator Sicurezza informatica

Gli algoritmi PAP e CHAP possono essere utilizzati in molteplici scenari di autenticazione, per esempio nelle connessioni PPP (Point-to-Point Protocol) usate per le connessioni a Internet via modem.
Accanto a tali protocolli standard, Microsoft ha proposto (RFC2433) una propria variante di CHAP, nota come MSCHAP, per l'autenticazione di client Windows remoti in ambito Win9x/Me e NT/2k/XP. Le modifiche riguardano un adattamento del formato del pacchetto dati per ragioni di compatibilità con i protocolli di rete Windows, nonché la definizione di codici d'errore dettagliati e l'introduzione di meccanismi (più sicuri e posti sotto il controllo del server) per ritentare l'autenticazione e per la modifica della password. Per esempio, diventa possibile per il server (che svolge il ruolo di autenticatore) rifiutare una password in quanto scaduta.
Un’evoluzione ulteriore di questo protocollo (MS-CHAP v2) è stata introdotta con Windows XP. Le novità riguardano la reciproca autenticazione di client e server, una crittografia più forte per la protezione delle fasi iniziali e l'uso di chiavi distinte per le due direzioni di traffico.
Una vera e propria "piattaforma" per l'integrazione, sempre in contesto PPP (o VPN) di altri possibili metodi di autenticazione è costituita poi dall'Extensible Authentication Protocol (EAP: RFC2284; e la sua evoluzione Protected EAP, o PEAP). In tale contesto, metodi di autenticazione di varia natura, comprese le Smart Card e i certificati digitali, sono messi, da un punto di vista operativo, sullo stesso piano, consentendo una facile scelta tra l'uno e l'altro. In figura 1 vediamo il dialog box con cui Windows XP propone varie scelte per l'autenticazione in contesto LAN (Ethernet o Wireless).
Per esempio, nel caso il metodo scelto sia MD5-Challenge, si userà un protocollo molto simile a CHAP, mentre qualora si selezioni PEAP, Windows renderà disponibile una seconda finestra di opzioni per la scelta delle autorità emittenti di certificati digitali ritenute "attendibili" e per la selezione, in ambito EAP, dello specifico metodo di autenticazione da usare (Figura 2). In caso di mancata autenticazione, MS CHAP può passare in modalità PAP (fallback) il che costituisce un potenziale rischio di sicurezza.
Schema di funzionamento del protocollo CHAP
Il protocollo CHAP prende le mosse su iniziativa del server che esige l’autenticazione del client C. Il primo passo è

infatti la generazione e l’invio, da parte del server, di un “pacchetto challenge” contenente (in chiaro) un valore casuale X (ossia il challenge vero e proprio), un numero progressivo N (usato dal server per mantenere storia dei vari challenge ancora in attesa di replica emessi verso vari client) e un nome di autenticazione S che identifichi il server.

Quando il client riceve il messaggio challenge esso costruisce una stringa composta dalla password P da usare con quel particolare server (identificato dal nome contenuto nel pacchetto) e dal numero progressivo N e challenge X appena ricevuti dal server. Questa stringa viene poi passata all’algoritmo MD5 che calcola H, un hash (checksum crittografico) che viene rispedito al server in un messaggio di “risposta al challenge”. Oltre a tale hash, questo messaggio porta a bordo C, inteso come il nome (in chiaro) del “principal” lato client a cui si riferisce la password entrata nel calcolo dell’hash.

Quando il server riceve il messaggio di risposta, quello che viene fatto è consultare il database locale di password conosciute per trovare la password corrispondente al principal C, dopodiché si procede allo stesso calcolo che il client ha appena effettuato per ottenere H. Se anche il server arriva allo stesso risultato H, per la proprietà

IT Administrator Sicurezza informatica Lezione 3

della funzione hash usata (MD5), ciò è considerato prova ragionevolmente certa che gli input dati all’algoritmo MD5 lato client e lato server erano uguali. In particolare, si considera dimostrato che la password usata lato client come input all’algoritmo è la stessa usata lato server, perciò lato client vi è qualcuno che ha dimostrato di conoscere la password e per questa ragione, a questo punto, lo si considera autenticato. In questo caso il protocollo termina con l’invio, dal server al client, di un messaggio che attesta l’avvenuta autenticazione.
Protocolli per l’autenticazione dei processi
Numerosi servizi di rete di larga diffusione e di grande importanza, a partire dall'NFS (Network File System) per la condivisione dei dischi in rete in ambiente Unix e Linux, si basano su un'architettura client-server nella quale lo scambio di messaggi tra le due parti in causa è modellato come una serie di Remote Procedure Calls (RPC) – un protocollo che consente a un programma residente su un particolare computer di mandare in esecuzione un programma residente su un server. Con RPC non ci si riferisce solamente a uno schema logico, ma anche a un vero e proprio protocollo standard che regola il comportamento che i processi in gioco devono seguire, nonché a un set di librerie utilizzabili dagli sviluppatori di applicativi per realizzare servizi client-server; RPC può appoggiarsi sia su connessioni TCP (Transmission Control Protocol) sia su comunicazioni UDP (User Datagram Protocol).
Data la delicatezza e la criticità di molti dei servizi basati su RPC, la questione dell'autenticazione del richiedente riveste particolare importanza (ovviamente accanto a quella della correttezza degli applicativi). Per tale motivo esistono schemi di autenticazione applicabili a RPC, che naturalmente fanno uso di tecniche crittografiche per contrastare attacchi basati su intercettazione, modifica, replay e altro. Tali tecniche (o authentication flavors) differiscono principalmente per l'algoritmo crittografico usato, per la modalità con cui avviene lo scambio delle chiavi e per altri dettagli.
L'assenza di strategia di autenticazione è anch'essa identificata come un flavor, (nella fattispecie il tipo è AUTH_NULL). Il flavor AUTH_UNIX (detto anche AUTH_SYS), ancor oggi molto usato, prevede l'invio, da parte del client, di hostname, username e gruppo (o un massimo di 10 gruppi) di appartenenza. Si tratta, e il nome non ne fa mistero, di un’impostazione molto orientata al modello di autenticazione del mondo Unix e nella quale, soprattutto, manca del tutto un ruolo di "verificatore", sicché risulta semplice falsificare le credenziali e spacciarsi per qualcun altro.
Il flavor AUTH_DES tenta di risolvere tali problemi. Innanzitutto il client viene identificato da una stringa (un nome di rete, detto anche "netname") il cui formato è libero (e non più Unix-oriented), purché soddisfi una condizione di univocità globale nella rete. E' responsabilità del client generare tale stringa nel modo a esso più comodo e garantire il rispetto di tale condizione. Un classico modo per farlo, adatto a molti sistemi operativi, consiste nel concatenare username, hostname ed eventuali altre informazioni, con opportuni separatori non ambigui. Per quanto riguarda il problema della protezione crittografica della comunicazione RPC, in AUTH_DES si fa uso, anche per motivi di prestazioni, di crittografia DES (simmetrica a chiave segreta) a 56 bit, con una fase iniziale, per la definizione concordata di una chiave di sessione, protetta da uno schema Diffie-Hellman con impiego di crittografia a chiave pubblica. Nei messaggi vengono inoltre inseriti timestamp (informazioni sull'ora di emissione dei messaggi) per rendere possibile il riconoscimento di messaggi troppo "vecchi" e poter così contra-
stare eventuali attacchi di tipo replay.
Esiste anche un flavor di più recente introduzione,

AUTH_KERB, che differisce da AUTH_DES principalmente per il fatto che, anziché spedire il "netname" e una chiave di sessione, si riutilizza con vantaggio il "service ticket" generato e gestito da Kerberos. Inoltre, come in tutti gli schemi Kerberos, la sensibilità di AUTH_KERB alla differenza tra i clock delle due macchine non è trascurabile come nel caso di AUTH_DES, in cui è previsto un sistema per il rilevamento e la compensazione automatica di tale eventuale differenza.

Schema (semplificato) della fase di invio delle credenziali dal client al server all’inizio di una sessione RPC
In modo AUTH_DES le credenziali (sempre accompagnate da informazioni di verifica, non mostrate in figura, che le proteggono) sono costituite dal nome del principal e dalla chiave di sessione Ks cifrata mediante la chiave Kdh precedentemente concordata con l’algoritmo DiffieHellman.

In modo AUTH_KERB tutto quello che occorre che il principal mandi come proprie credenziali (a parte le informazioni di verifica, anche in questo caso non mostrate) è il ticket di sessione precedentemente ottenuto mediante Kerberos (Tk). Il semplice possesso di quel ticket attesta infatti che in precedenza il principal ha superato con successo una fase di autenticazione con l’Authentication Server, di cui anche il server “si fida”.

 

Architetture a singolo sign-on
Quando si ha a che fare con sistemi articolati e complessi, composti da una molteplicità di host (connessi tra loro in rete) e di servizi erogati da essi, con un gran numero di utenti e con la necessità di autenticarsi con ogni servizio per potervi accedere, ci si può facilmente trovare davanti a una situazione pressoché ingestibile, sia per l'utente finale – costretto a ripetere frequentemente l'operazione di login, sia per gli amministratori di sistema, alle prese con il problema di governare un elevato numero di profili per diversi host o servizi.
Come abbiamo visto, possibili soluzioni "palliative" vanno dalla scelta, da parte degli utenti, di login e password ovunque uguali, all'utilizzo di stratagemmi come il meccanismo .rhosts per il riconoscimento reciproco dell'autenticazione tra host.
Una soluzione strutturalmente migliore prende le mosse da una strategia di gestione unificata degli utenti, attraverso la creazione di un database unico, centralizzato, per tutti i profili (username, password e altri dati) al quale le applicazioni possano magari accedere attraverso un'interfaccia standard, specializzata nel trattamento di questo tipo di dati, come LDAP (Lightweight Directory Access Protocol). Il passo successivo però consiste nel congegnare le applicazioni del sistema complessivo in modo che non soltanto l'autenticazione avvenga appoggiandosi alle informazioni contenute in tale database unificato, ma che l'utente debba autenticarsi una sola volta, al primo accesso, e in seguito risulti automaticamente autenticato su tutte le altre risorse di rete. A tal fine sono considerate ri-

Lezione 3 IT Administrator Sicurezza informatica

sorse di rete non solo periferiche o i dischi condivisi, ma qualunque servizio reso disponibile dal sistema nel suo complesso, inclusi gli accessi interattivi (come telnet/rlogin/rsh, per sistemi Linux) e l'accesso a servizi erogati via Web.
Tale approccio complessivo all'autenticazione va sotto il nome di Single Sign-On (SSO) e, se da un lato offre degli indubbi benefici in termini di praticità d'uso per gli utenti finali (e, di conseguenza, un incremento di produttività), ha anche effetti positivi sulla sicurezza del sistema, in quanto è evidente che non dovendo più ricordare numerose password l'utente è meno portato a tenerne traccia scritta in luoghi magari poco protetti; inoltre la gestione dei profili risulta centralizzata e quindi non solo più semplice, ma anche più sicura (diminuisce il rischio di dimenticare gli account attivi o le password obsolete, magari già compromesse).
Naturalmente la difficoltà di realizzare una architettura SSO per l'autenticazione è proporzionale all'eterogeneità del sistema.
Quando l'ambiente complessivo è omogeneo la soluzione può essere addirittura già disponibile "gratis", come avviene con il modello Microsoft.
Esso prevede anzitutto un LDAP server come deposito centrale delle informazioni di profilo. Si distinguono poi quattro tipi di logon, pensati per altrettanti modelli di comportamento e di accesso a risorse di rete. Innanzitutto vi è il login interattivo, che corrisponde alla classica situazione in cui si accede a un computer per il quale si disponga di accesso fisico diretto (anche se, per la verità, gli accessi via Terminal Server sono equiparati); il login di rete, per l'utilizzo da remoto, in modalità client-server, di qualche risorsa o servizio; il login per servizi, che i servizi Win32 effettuano sul nodo locale per poter entrare in attività; e infine i login batch, usati appunto per l'esecuzione di job batch, magari in background.
Qui interessa soprattutto il secondo di questi tipi di login, il login di rete, il quale si avvale del protocollo Kerberos (di origine Unix, ma adottato ufficialmente da Microsoft – precisamente in versione 5 per i suoi sistemi operativi da Windows 2000 in poi) per garantire un elevato livello di sicurezza per l'autenticazione malgrado questa avvenga in rete.
Vedi il seguente capitolo (5.3.5.5) per la descrizione dettagliata delle fasi di autenticazione utilizzate dal protocollo Kerberos.
Principi operativi di Kerberos
Il servizio distribuito di autenticazione in rete Kerberos, inventato nella metà degli anni '80 dal MIT, prende appropriatamente il nome dal cane a tre teste che secondo la mitologia greca vigilava sull'accesso agli inferi.
In sintesi, il servizio offerto da Kerberos consente a un processo (client) mandato in esecuzione da un utente (principal) di attestare e dimostrare la propria identità a un ente verificatore (una applicazione server) senza inviare alcuna informazione in rete – in particolare, password la cui intercettazione potrebbe consentire a un attaccante o allo stesso verificatore d’impersonare in seguito l'utente.
Tale operazione apparentemente contraddittoria e impossibile, è in realtà consentita da un impiego ingegnoso di tecniche crittografiche.

Nel funzionamento di Kerberos gli attori fondamentali sono 4: oltre ai già citati client (C) e server (R) vi sono infatti:
- un authentication server (AS), con il quale ogni client C condivide una propria chiave crittografica segreta Kc. AS ha la funzione di generare in modo sicuro (fidato e non intercettabile da terzi in ascolto) "l'innesco" della successiva conversazione: la chiave di sessione.

- un ticket-granting server (TGS) che si occupa di fare da "ponte crittografico" fra client e server per generare in modo convincente per entrambi, e non intercettabile da terzi, una chiave da usare per la successiva comunicazione diretta tra C e R.
FASE 1
Quando C desidera attivare una connessione con R per richiedere l'esecuzione di un servizio, autenticandosi in modo credibile per R, ma non intercettabile per terzi non autorizzati, per prima cosa invia (in chiaro) il proprio nome "C" ad AS. AS esamina il proprio database di controparti note e verifica che effettivamente un client C è noto e che in particolare è nota la chiave segreta Kc da usare nelle comunicazioni con esso. AS allora genera una chiave di sessione Ks (ogni volta una diversa) e un "ticket" ottenuto crittografando con la chiave segreta Ktgs la coppia di informazioni costituita dall'identità del client, C, e dalla chiave di sessione, Ks. Chiave di sessione e ticket vengono usati per formare un messaggio che viene poi cifrato con la chiave segreta Kc e spedito a C come risultato. Il messaggio così ottenuto risulta indecifrabile per chiun-

Approfondimenti

RFC 2251 (LDAP):
http://www.faqs.org/ r fcs/r fc2251.html

5.3.5.5
Conoscere i principi generali di funzionamento del sistema di autenticazione Kerberos.

IT Administrator Sicurezza informatica Lezione 3

Approfondimenti

Per una presentazione di Kerberos si veda Tanenbaum, Computer Networks (IV edition),
Prentice-Hall, cap. 8.7.4; oppure, su Web. http://www.isi.edu/ gost/publications/ kerberos-neumantso.html

5.3.6 Controllo degli accessi

 

5.3.6.1
Conoscere i principi concettuali alla base del controllo d’accesso

que non conosca la chiave segreta Kc, ma non per C, che ne è al corrente. Quando C riceve il messaggio, utilizza proprio Kc per decifrarlo ed estrarre Ks e il ticket. Il ticket è indecifrabile per C, che non conosce la chiave Ktgs con cui è stato cifrato. [figura fase 1]
FASE 2
C invia al ticket-granting server TGS il ticket così come l'ha ricevuto, accompagnato dall'identità R (in chiaro) del server con cui vuol parlare e dall'ora esatta crittografata con la chiave di sessione Ks.
Per il TGS, che naturalmente conosce Ktgs, è possibile decifrare il ticket ed ottenere così Ks e C. Con Ks può poi decifrare l'ora esatta e verificare se il messaggio che ha appena ricevuto da C è effettivamente stato mandato di recente oppure se si tratta di un vecchio messaggio che qualcuno ha intercettato e sta ora cercando di ripetere per ingannare il server inducendolo a ripetere una operazione già effettuata in precedenza (replay attack).
Il TGS sceglie ora una chiave segreta Kcr da usarsi per la comunicazione che sta per avere inizio fra il client C e il server R.
Il prossimo passo consiste nell'invio a C, da parte del TGS, di due informazioni protette. La prima consiste nella coppia R, Kcr crittografata usando la chiave di sessione, Ks. La chiave di sessione è nota solo a C (oltre ai fidati AS e TGS) quindi nessun altro, all'infuori del client, può intercettare tale messaggio. C può così estrarre Kcr e iniziare a usarla per parlare con R.
La seconda informazione consiste nella coppia C, Kcr crittografata con la chiave Kr del server. Poiché il client non conosce Kr, C non ha la possibilità di decifrare (magari per alterarlo) questo valore. Tutto quello che può fare è di spedirlo tale e quale al server R, accompagnato anche in questo caso dall'ora esatta cifrata usando la chiave Kcr.

FASE 3
Quando il server R riceve questo messaggio, per prima cosa lo decifra usando la sua chiave segreta Kr. Ottiene così la chiave Kcr e l'identità C del client che gli sta parlando, il che gli permette di verificare che il messaggio stia arrivando proprio da chi il mittente afferma di essere.
Con la chiave Kcr invece il server per prima cosa decifra l'ora esatta e verifica che il messaggio sia davvero recente. In caso contrario potremmo essere ancora di fronte a un replay attack, e il server per tutelarsi non dovrà fare altro che ignorare il messaggio.

A questo punto sia C sia R (e nessun altro, escluso, naturalmente, il "fidato" TGS) conoscono la chiave segreta condivisa Kcr e R considera finalmente autenticato C: la comunicazione sicura fra essi può cominciare, naturalmente crittografata usando Kcr come chiave. Chiunque fosse stato in ascolto non ha visto passare alcuna password (nemmeno crittografata) e da ciò che può avere intercettato non ha acquistato né la possibilità di intromettersi nella conversazione spacciandosi in modo credibile per qualcun altro (per farlo dovrebbe ingannare AS e TGS, ma non conosce le chiavi segrete per farlo), né la possibilità di memorizzare e ripetere dei messaggi (grazie ai timestamp crittografati con chiavi segrete).
Inoltre, ogni successivo scambio di messaggi fra C e R avviene in forma cifrata usando una chiave segreta Kcr e risulta quindi incomprensibile a terzi non autorizzati in ascolto.

 

Controllo degli accessi
Una volta conseguita l'autenticazione, con cui ha convalidato la propria identità, il "principal" (utente o processo che sia) che desideri accedere a una determinata risorsa si trova ancora a metà del guado: il fatto che la sua identità sia ora accertata, infatti, non significa necessariamente che gli debba essere concesso quello che chiede.
Occorre prima verificare se a quel "principal" è consentito l'accesso alla risorsa e questo, ove applicabile, nella modalità richiesta, a seconda del modello previsto a tale riguardo (lettura, scrittura, creazione,..).
Di questo si occupa una seconda "barriera" subito a valle dell'autenticazione: il controllo degli accessi (Access Control).
Principi di controllo degli accessi
Con il termine "controllo degli accessi" ci si riferisce a quelle funzionalità del sistema operativo che stabiliscono chi può accedere alle risorse disponibili ed esercitano il potere di concedere, o negare, l'abilitazione a tale accesso.
A seconda dei sistemi operativi, il controllo degli accessi può riguardare un set più o meno vasto di entità, dai "soliti" file fino a concetti più sottili come le chiavi di registro o i semafori, passando per stampanti di rete, processi e thread.
Nella terminologia Windows, le entità assoggettabili a controllo degli accessi si chiamano "securable objects".
Da un punto di vista concettuale, poi, qualunque sia l'implementazione offerta dal sistema operativo, si può

Lezione 3 IT Administrator Sicurezza informatica
pensare a uno stesso modello logico di riferimento per la determinazione dei permessi di accesso: la cosiddetta "tabella delle autorizzazioni", di cui, come vedremo, altri modelli costituiscono restrizioni o semplificazioni.
Access Control List e List of Capabilities
La tabella delle autorizzazioni (o "matrice degli accessi") può essere immaginata come una matrice bidimensionale le cui righe rappresentano "soggetti" (o "principal"), ossia entità – utenti, processi, eccetera che possono richiedere un accesso a qualche risorsa; le sue colonne rappresentano invece "oggetti", o risorse – file, periferiche, database, porte di I/O, eccetera – per le quali, a fronte di una richiesta di un "principal", può essere consentito o negato l'accesso.
All'incrocio di una riga con una colonna la matrice riporta l'elenco dei diritti, od operazioni, che sono concessi a quel determinato "principal" su quella particolare risorsa. Per esempio, limitandoci per semplicità al caso degli utenti e dei file:

utente1 lett./scritt. nessun diritto ... lett./esecuz. utente2 lett. nessun diritto ... lett.
... ... ... ... ...
utenteM lett./esec. lett./scritt. ... lett.

Riconsiderando ora questa matrice ed estraendone una determinata colonna otteniamo l'elenco dei diritti di accesso riconosciuti su quella risorsa (nell'esempio, un file) per ogni utente conosciuto al sistema. Questo tipo di informazione non è altro che la Access Control List (ACL) associata alla risorsa:

...

Viceversa, se dalla stessa tabella estraiamo una determinata riga, otteniamo l'indicazione di tutto ciò che nel complesso è consentito fare a un determinato "principal" (nell'esempio, un utente). Questo vettore è spesso definito "Capability List" (lista di capacità)

Controllo degli accessi nei comuni file system
Anche se da un punto di vista logico il modello di riferimento per quanto riguarda il controllo degli accessi sui file è sostanzialmente analogo nella maggioranza dei sistemi operativi, esistono differenze e restrizioni piuttosto marcate nella sua implementazione da caso a caso. Qui prenderemo in considerazione Windows XP Home, Windows XP Professional e Linux.
Fra i tre sistemi presi in esame, Windows XP Professional offre il modello ACL per i file più articolato e completo. È possibile, per ogni singolo "principal", sia esso un utente o un gruppo, specificare per ogni singolo file (o per intere cartelle o unità disco) non soltanto i "classici" permessi di lettura e scrittura (Figura 3), ma anche permessi estremamente specifici quali l'autorizzazione ad acquisire il possesso della risorsa, a impostare il valore dei suoi attributi base ed estesi e perfino l'autorizzazione a leggere (e cambiare) i permessi stessi. Questo si fa utilizzando un'apposita scheda (Figura 4) del dialog box "Properties" che si visualizza selezionando il file in Explorer e facendo clic con il tasto destro del mouse; la scheda Permissions

IT Administrator Sicurezza informatica Lezione 3

(Figura 5) fornisce invece una vista tabellare abbastanza chiara della ACL per l'oggetto in questione.
Nel caso di XP Home, per i file, è disponibile una versione di ACL molto ristretta. Tutto quello che si può fare è specificare se una determinata cartella è per esclusivo uso personale di un determinato utente sul computer locale, oppure condivisa con gli altri utenti locali del computer, oppure condivisa in rete, nel qual caso è consentito anche precisare se agli utenti di rete deve essere permesso modificare i file contenuti nella cartella. Non è possibile impostare queste restrizioni a livello di singolo file e non è possibile differenziarle utente per utente. In sintesi, sia i "principals" sia le risorse (ovvero, sia le righe sia le colonne della "access matrix") sono trattabili solo in modo "grossolano", per gruppi, e anche i permessi che possono essere concessi o negati (lettura; scrittura) sono un sottoinsieme di quelli previsti dal modello di XP Professional.
In Linux lo schema per attribuire i permessi ai file è semplice ma pratico e soprattutto sufficiente per tutte le applicazioni normali. Ogni file o directory ha associato un set di permessi accordati a tre diverse categorie: il proprietario del file (user); il gruppo di utenti a cui il proprietario appartiene (group); tutti gli altri utenti (other). Per ognuno di questi tre "principal" sono definiti tre permessi: lettura, scrittura, esecuzione/attraversamento. Quest'ultimo assume il primo significato nel caso in cui l'entità in esame sia un file e il secondo significato nel caso di una directory.
Caratteristica peculiare di Unix in generale e quindi anche di Linux, il permesso di esecuzione esiste anche nella variante "set user id": l'effetto è quello di far sì che anche se il programma è lanciato in esecuzione da un utente U, durante l'esecuzione gli verrà temporaneamente attribuita un'identità (effective user ID) uguale a quella del proprietario del file. Si tratta di una possibilità molto utile per consentire anche a semplici utenti l'esecuzione di determinate operazioni privilegiate, ma naturalmente, se abusata, è foriera di gravi rischi per la sicurezza, specie se il flag "set user id" è usato per un programma di proprietà di root.
I permessi dei file sono mostrati quando si richiede la visualizzazione della directory con il comando "ls –l": la rappresentazione, che compare subito alla sinistra del file, consiste in una stringa di 10 caratteri, in cui il primo codifica il tipo di file (file, directory, link simbolico, socket – un oggetto software che collega un’applicazione a un protocollo di rete named pipe – collegamento temporaneo fra due programmi o comandi) e i successivi 9 caratteri, a gruppi di 3 (da sinistra a destra: utente/gruppo/altri), sono i permessi per i 3 diversi "principal".
Se un dato permesso è concesso, la relativa lettera è visualizzata (r per read, w per write, x per execute, s per setuser-ID). Viceversa, se il permesso non è disponibile, nella corrispondente posizione della stringa viene mostrato un trattino ("-"). Per esempio, la stringa dei permessi di un file di programma eseguibile ha normalmente il seguente aspetto:
-r-xr-xr-x

Se si vuole che, quando qualcuno lo esegue, il programma acquisisca i diritti dell'utente proprietario del file per tutto il tempo dell'esecuzione, occorre assegnare il permesso set-user-id, così:
-r-sr-xr-x

Invece i permessi di un semplice file di dati leggibile dal proprietario e dal suo gruppo, ma scrivibile solo dal proprietario, appaiono così:

-r w-r-----

Una directory (tipo di file: "d") in cui tutti possono scrivere e leggere e che tutti possono attraversare avrà invece una stringa permessi di questo tipo:
dr wxr wxr wx

mentre sarà opportuno che la home directory di un utente sia maggiormente protetta, per non consentire né letture, né scritture, né attraversamenti ad estranei, compresi gli appartenenti allo stesso gruppo di utenti del proprietario, al quale invece dev’essere concesso tutto:
dr wx------

È bene tenere comunque sempre presente che per l'utente root è come se tutte queste limitazioni non esistessero.
Esiste anche una rappresentazione numerica di questi permessi che è basata su una notazione binaria: a ogni permesso concesso o negato viene fatto corrispondere un bit in una maschera di 9 bit. Ogni bit della maschera vale 0 se il rispettivo permesso è negato, 1 se concesso. Da sinistra a destra, i bit hanno il seguente significato:

user group other
read 1 write 1 execute 0 read 1 write 0 execute 0 read 1 write 0 execute 0

La maschera mostrata nell'esempio (110100100) corrisponde alla stringa "rw-r--r--", ossia: il proprietario può leggere o scrivere il file, gli altri (gruppo ed estranei) possono solo leggerlo.

Solitamente si fa uso della notazione ottale per comodità (in quanto ogni cifra ottale corrisponde a 3 bit, un raggruppamento ideale). Così, una situazione di "tutti i permessi negati" corrisponde a 000 ottale, mentre 777 rappresenta il binario 111 111 111, ossia "tutti i permessi sono concessi a tutti". I permessi dell'esempio di cui sopra, in ottale, avrebbero la rappresentazione 644.
Da segnalare infine il meccanismo dei permessi di default. Quando viene creato un file, il sistema operativo provvede ad attribuirgli dei permessi che dipendono dal tipo di file (per esempio: programma o file di dati) e da una speciale misura precauzionale supplementare, volta di solito a restringere i permessi che spettano a "gruppo" e "altri": si tratta del meccanismo della "umask", in sostanza un valore binario (espresso per comodità in ottale) che rappresenta i bit che devono essere azzerati nella maschera dei permessi rispetto al valore dei permessi standard per quel tipo di file. Il comando umask, senza parametri, visualizza il valore attuale di questa maschera. Per impostarla si usa lo stesso comando ma si passa un parametro ottale su riga di comando, per esempio:
umask 022

che corrisponde a negare a "gruppo" e "altri" il diritto di scrittura per il nuovo file.

Controllo degli accessi in database relazionale
Uno dei tipi più importanti di risorse disponibili in rete è il database. E' evidente che, se si ha a cuore la sicurezza delle informazioni, l'accesso a un database (che spesso può contenere dati estremamente rilevanti e sensibili) non è privilegio da concedere a chiunque senza restrizioni.

Lezione 3 IT Administrator Sicurezza informatica

Due sono gli aspetti da considerare a questo riguardo: il controllo sulla connessione al Database server e l'autorizzazione a compiere le varie operazioni una volta connessi.
Per il primo punto i database utilizzano naturalmente uno schema basato su password; a seconda dei casi la password può viaggiare da client a server su una connessione più o meno protetta da tecniche crittografiche, ma si tratta di uno scenario simile a quelli già discussi, con vantaggi e criticità analoghi, su cui non ci soffermiamo.
E' il secondo aspetto a meritare un cenno. I database sono dei sistemi per la gestione veloce e affidabile di grandi quantità di informazioni in forma strutturata. Nel caso particolare dei database relazionali (RDBMS) la struttura usata è la tabella bidimensionale; una tabella si usa per modellare una determinata entità; le righe (o record) corrispondono a istanze, le colonne ad attributi.

Esempio di tabella in un RDBMS
Nome tabella: Correntista
Nome Codice fiscale Numero cliente Saldo John Smith 1234567XYZ 1423 1000
Jack White 9876543KLM 5253 2000
In questa tabella gli attributi sono “Nome”, “Codice fiscale”, “Numero cliente” e “Saldo”; l’entità modellata è il Correntista. Sono attualmente presenti 2 istanze, corrispondenti ai correntisti i cui nomi sono John Smith e Jack White; per esempio, il record contenente le informazioni riguardandi John Smith è il seguente record di quattro campi:
John Smith 1234567XYZ 1423 1000

Così, possiamo dire che il valore dell’attributo “Numero cliente” per l’istanza relativa a “John Smith” è 1423.

Il modello di protezione a livello di utente, con il quale si possono stabilire livelli di permessi d'accesso ai dati e ad altre informazioni di controllo del database, non ha una logica "tutto o niente" ma consente di specificare questi permessi con una granularità più fine, per definire la quale si fa proprio riferimento a questi oggetti ed alle operazioni possibili su di essi.
Con riferimento al caso particolare di Access, in ambiente Windows, per ogni "principal" (utente o gruppo di

utenti) e per ogni oggetto definito nel database, fra quelli di tipo controllabile (tabella, query, maschera, eccetera) è infatti possibile specificare le autorizzazioni desiderate, fra cui lettura, scrittura, inserimento, cancellazione.
L'operazione, nel caso di Access, si effettua da una comoda finestra dedicata (Figura Permessi Access). Per altri database, in assenza di una interfaccia grafica di gestione analoga a questa, per definire i permessi occorre utilizzare comandi interattivi stile SQL oppure agire su speciali tabelle di controllo che fanno parte anch'esse, seppure a titolo speciale, del database a cui si riferiscono; nome, tipo e struttura di questi comandi o tabelle dipendono dal particolare RDBMS usato, anche se i concetti su cui si basano restano naturalmente gli stessi. Per esempio, in MySQL (un database molto diffuso, in particolare in ambiente Linux) e vari altri RDBMS, i seguenti comandi hanno l'effetto di concedere all'utente "smith12" di modificare ("alter") la tabella dei conti correnti, "Accounts", in un database bancario, purché "smith12" si sia preventivamente autenticato a mezzo password:

Mysql> GRANT alter on Accounts to smith12 Mysql> IDENTIFIED by "password";

Si potrebbe anche concedere a un utente "admin" ogni permesso su ogni tabella del database, pretendendo però, per ragioni di sicurezza, una autenticazione che avvenga in modo protetto crittograficamente a mezzo SSL (Secure Socket Layer):
Mysql> GRANT all on *.* to admin
Mysql> IDENTIFIED by "password" REQUIRE SSL;

Esiste anche un comando REVOKE che ha l'effetto contrario di GRANT, in quanto revoca una o più autorizzazioni per un dato utente e tabella. La sintassi è del tutto simile a quella di GRANT:

Mysql> REVOKE alter on Accounts FROM smith12; Mysql> REVOKE ALL PRIVILEGES FROM smith12;

IT Administrator Sicurezza informatica Lezione 4
Disponilbilità dei dati
Proteggere i dati da disastri
e attacchi maligni

Prosegue il primo corso di taglio professionale destinato al conseguimento della certificazione ufficiale, EUCIP IT Administrator – Sicurezza
Informatica, valida in tutta Europa. In questo numero ci occupiamo di tutti i meccanismi per garantire la costante disponibilità delle informazioni anche in caso di disastro o di attacco maligno. I contenuti
sono composti da tre elementi: un articolo sulla rivista, un articolo, molto più esteso in formato PDF e un corso multimediale completo
su CD e DVD di Marco Mussini

a un punto di vista colloquiale, il senso dell’espressione “disponibilità dei dati”, e dei rischi che possono comprometterla, può apparire quasi intuitivo.
Viene spontaneo pensare alla possibilità che si guastino i dischi fissi, che la rete cessi di funzionare, che si verifichi un black out, che si guasti qualche altro apparato vitale. Tutti questi aspetti certamente esistono e li approfondiremo nei prossimi paragrafi, ma conviene qui ricordare che tecnicamente l’espressione “disponibilità dei dati” ha un’accezione piuttosto ampia e articolata che a volte sconfina anche in questioni collaterali. Vediamo quali sono, anche attraverso qualche esempio.
Innanzitutto l’accessibilità. Il fatto che i dati esistano senza che sia possibile avervi accesso non è di grande interesse. Per la disponibilità dei dati è quindi necessario anzitutto assicurare che gli eventuali meccanismi di protezione e di controllo degli accessi (dall’autenticazione del richiedente, all’autorizzazione per mezzo di uno schema di permessi) funzionino regolarmente e che i relativi database, che sono necessari per il loro funzionamento, siano a loro volta accessibili e contengano dati validi. Questi comprendono i database di chiavi crittografiche usate per rendere sicuro il processo di autenticazione e accesso, quelli di elenchi di utenti e relative password, nonché le Access Control List (l’elenco dei diritti di accesso riconosciuti per una risorsa) e le Capability List (tutti i permessi che sono attribuiti a un particolare utente o processo). Sempre per garantire l’accessibilità dei dati è naturalmente necessario

che le connessioni di rete funzionino e siano affidabili, come approfondiremo fra breve.
Vi sono poi aspetti che riguardano intrinsecamente i dati stessi, a cominciare dalla loro integrità. Non si possono definire disponibili, infatti, dati che siano solo parziali, privi di informazioni essenziali per il loro utilizzo. Per esempio, in un database relazionale usato per modellare i dati di un istituto bancario, è del tutto inutile che esistano la tabella A, con la situazione dei conti correnti (figura 1) e la tabella B, dei dati anagrafici dei correntisti (figura 2), se è andata perduta la tabella C, che mette in relazione i correnti-

Lezione 4 IT Administrator Sicurezza informatica

sti con conti correnti (figura 3). La mancanza della tabella C rende di fatto inutili, e non disponibili, i dati delle tabelle A e B.
Tabella A la situazione dei conti correnti di una banca N.conto Saldo Tasso attivo Tasso passivo Fido 10001 1090 1.25 8.75 300
10322 2315 1.00 9.25 500
10224 3167 1.50 8.50 1250

La tabella B con i dati anagrafici dei correntisti

371 Rossi Mario C.so Garibaldi 10 Pavia
392 Bianchi Giorgio Via Bellini 40 Lecco
407 Verdi Alfredo P.za Cavour 17 Milano

La tabella C, che mette in relazione clienti e conti correnti. In sua mancanza le tabella A e B del database sono inutili.

371 10322
392 10224
407 10001

Anche se formalmente i dati sono accessibili e tutti presenti, vi può essere tuttavia un problema di consistenza. Sempre sulla falsariga all’esempio bancario, il fatto che formalmente siano presenti le tabelle A, B e C non serve a nulla se la corrispondenza espressa dalla tabella C fa riferimento a identificativi di conto corrente oppure a codici cliente non corretti, ai quali non fa riscontro alcun conto (nella tabella A) o alcun cliente (nella tabella B). In questo caso si dice che i dati contenuti nella tabella C (figura 1) sono inconsistenti con i dati delle tabelle A e B, il che rende i dati, nel loro complesso, privi di senso e inutilizzabili perché privi di una rete di collegamenti validi che li metta in relazione reciproca.

Figura 1. Un esempio di tabella C contenente dati parzialmente inconsistenti con le tabelle A e B mostrate in figura 1 e 2. Esempi di dati inconsistenti sono evidenziati in giallo.

Codice Cliente Numero Conto
375 10322
392 10224
407 10771

Per completezza ricordiamo che quando i dati sono inesatti, ma l’effetto di tale inesattezza si esaurisce in sé stesso (non si ripercuote cioè sulle relazioni tra i dati e sulla loro utilizzabilità nel loro complesso) la questione riguarda invece la correttezza dei dati; si tratta tuttavia di un problema che è solo contiguo a quello della loro disponibilità. La garanzia di disponibilità dei dati, insieme all’ininterrotto e regolare funzionamento dei processi aziendali, sono i pilastri della cosiddetta "Business Continuity", intesa come la misura in cui un’organizzazione riesce a garantirsi la stabilità ininterrotta dei sistemi e delle procedure operative anche a fronte di eventi “eccezionali”. Tale risultato non è realisticamente raggiungibile aggiungendo una “stratificazione” di rimedi a processi e sistemi che di base sono fragili e vulnerabili: occorre piuttosto progettarli in modo che siano intrinsecamente robusti e “fault tolerant” ossia resi-
stenti ai guasti.
La Business Continuity è dunque il risultato di una corretta pianificazione della gestione delle criticità (Crisis Management), di un’accurata identificazione, valutazione e gestione dei rischi (Risk Analysis, Assessment and Management), di processi organizzativi e informatici progettati con criteri di ridondanza e sicurezza, e di appropriate proce-

dure di Data Recovery in grado di fornire un grado supplementare di protezione in caso di eventi eccezionali.
Naturalmente la sicurezza ha un costo proporzionale al livello di servizio garantito, pertanto ogni organizzazione deve stabilire il livello di compromesso tra il rischio d’interruzione dell’operatività e il costo delle misure preposte a garantire la Business Continuity. Idealmente si sarebbe portati a dire che non ci si può permettere di perdere alcun dato e che non è tollerabile alcuna interruzione di servizio; purtroppo è assai probabile che un simile livello di protezione abbia un costo proibitivo. Si deve inoltre osservare che non tutte le applicazioni e i dati usati in azienda sono ugualmente “mission-critical”. È quindi utile definire alcune soglie ed è qui che torna utile definire due concetti, quello di Recovery Time Objective (RTO) e quello di Recovery Point Objective (RPO).
Il Recovery Time Objective, riferito a un determinato sistema o processo organizzativo, è un valore che indica il tempo -disponibile per il recupero della piena operatività di quel sistema o processo. In altre parole è la massima durata prevista o tollerata dell’eventuale downtime, ove questo si verificasse. L’aspetto di primaria importanza è che un qualche valore di RTO sia definito, conosciuto e verificato. Infatti, se è vero che un downtime lungo danneggia l’organizzazione più di uno breve, il danno peggiore deriva senza dubbio dal non avere alcuna idea precisa di quanto tempo sarà disponibile per terminare il downtime quando si verifica. Avere una soglia di RTO conosciuta e verificata permette se non altro di reagire all’emergenza in modo ordinato e potendo contare su un tempo massimo garantito prima del ritorno alla normalità.
Una misura utile per ridurre l’RTO consiste nel fare in modo che i dati siano disponibili integralmente e “a caldo” in un sito secondario, che sia immediatamente accessibile qualora il sito primario subisca un’interruzione di servizio. Se l’RTO stabilisce un limite di tempo entro il quale è atteso il ritorno alla normalità, l’RPO (Recovery Point Objective) quantifica invece l’entità massima della perdita di da-
ti che può essere tollerata a seguito di un evento di crisi. Per rimanere dentro le richieste imposte dall’RPO oc-
corre, per esempio, che i dati vengano salvati e replicati con immediatezza, con un minimo tempo di permanenza in memoria volatile (come un buffer in RAM) o priva di protezione (come un disco non ridondato). Una soluzione ben più idonea consiste però nell’adozione di schemi di replicazione dei dati sulle unità a disco (RAID), come vedremo tra poco.
I valori di RPO ed RTO devono risultare da un’analisi della struttura informatica nel suo complesso e il loro diminuire porta progressivamente a una struttura sempre più critica. Ad esempio, una struttura che disponga di un RTO alto può rimanere inattiva senza problemi per un lungo periodi, al fine di consentire riparazioni anche complesse. Una struttura con un RPO alto può invece tollerare un numero alto di transazioni non ripristinate senza problemi.
Requisiti sull’infrastruttura ICT
Anche l’equipaggiamento hardware deve avere caratteristiche tali da contribuire a un buon livello generale di information availability.
L’esempio più evidente consiste nel tutelarsi dal rischio di black-out dotandosi di sistemi UPS (Uninterruptible Power Supply) adeguati alle attrezzature da proteggere.
Le principali caratteristiche degli UPS da valutare nella scelta sono otto.
1) il carico massimo sopportabile, espresso in VA (Volt – Ampere). Naturalmente è sempre saggio sovradimensionare l’UPS rispetto all’assorbimento teorico dell’insieme dei sistemi da proteggere. Sarà così possibile assorbire picchi inattesi di carico, senza contare che l’autonomia durante il black-out sarà maggiore.
2) il tempo di commutazione della fonte di alimentazione

IT Administrator Sicurezza informatica Lezione 4

da rete elettrica a batteria interna. Tale tempo (che deve essere dell’ordine dei pochi millisecondi al massimo) va confrontato con il tempo massimo sopportabile, in condizioni di assenza di alimentazione, dalla più “esigente” tra le unità da proteggere.
3) la durata massima del periodo di autonomia in assenza di alimentazione in condizione di carico massimo. A seconda del dimensionamento, l’UPS può lasciare giusto il tempo per salvare i dati e chiudere le applicazioni (una decina di minuti) oppure permettere una vera “business continuity” per un tempo di diverse ore. Fra questi due scenari passa una differenza molto rilevante per quanto riguarda il dimensionamento e il costo dell’UPS (che sarà varie volte maggiore nel secondo caso).
4) il tempo richiesto per una ricarica completa. Si tratta di un valore essenziale per sapere quali chance ha il sistema di resistere a due o più black-out in rapida successione. In molti casi il processo di carica è di gran lunga più lento di quello di scarica: un UPS che garantisce 10 minuti di autonomia a carico massimo può impiegare ore per ricaricarsi completamente. Questo evidentemente pone limiti precisi non solo alla durata degli incidenti di alimentazione, ma anche alla loro frequenza. La soluzione è ancora una volta quella di sovradimensionare l’UPS.
5) la capacità di smorzare sovratensioni, disturbi impulsivi e scariche conseguenti a fattori meteorologici o a disservizi della rete elettrica. Questa prestazione può essere intrinseca per il tipo di tecnologia dell’UPS (come spiegato più avanti) oppure essergli conferita da un modulo dedicato interno. È anche possibile interporre un filtro tra la rete elettrica e l’UPS oppure tra questo e le unità sotto protezione.
6) la capacità di interfacciarsi a livello logico-applicativo con i sistemi sotto protezione, in modo da forzare il salvataggio automatico dei dati e lo shutdown ordinato dei sistemi stessi. Di solito ciò avviene mediante collegamento seriale o USB ed è richiesta l’installazione di un apposito software di supervisione. Tale software raramente è disponibile su molti sistemi operativi diversi, pertanto è importante valutare con attenzione la qualità del supporto software offerto dal fornitore dell’UPS.
7) la disponibilità di un sistema di controllo remoto per il monitoraggio dello stato di carica della batteria e per la consultazione di un log degli eventi critici verificatisi.
8) il tipo di tecnologia. In ordine crescente di protezione, di rapidità di commutazione e di immunità dai disturbi sull’alimentazione primaria, ma anche di costo, citiamo il tipo Passivo (ormai obsoleto) che interviene solo in caso di mancanza di alimentazione, ma non filtra l’alimentazione proveniente dalla rete primaria, il tipo On line interactive che regola e filtra tensione della rete primaria mantenendo contemporaneamente in carica la batteria che interviene immediatamente in caso di blackout e infine il tipo Online a doppia conversione che alimenta il carico costantemente dalla batteria. Quest’ultimo tipo di unità trasforma costantemente in corrente continua la corrente alternata in ingresso mediante un raddrizzatore; la corrente continua così ottenuta viene in parte usata per la carica di mantenimento della batteria, mentre il resto viene nuovamente convertito in corrente alternata per il carico, con parametri assolutamente stabili e totale disaccoppiamento da eventuali disturbi presenti sull’alimentazione primaria.

Anche la climatizzazione del locale macchine dev’essere curata con attenzione. Tutte le unità come PC, monitor, unità disco, apparati di rete, eccetera, riportano nella propria documentazione il campo di temperatura (e in qualche caso di umidità) ammissibile. Il sistema di condizionamento deve assicurare il mantenimento dei parametri ambientali (temperatura, umidità) entro l’intervallo tollerato dai sistemi installati, tenendo conto anche di un adeguato margine di tolleranza (per esempio si deve tener conto di un black out durante il quale gli UPS proteggono i sistemi, ma probabilmente non l’impianto di condizionamento, che cesserebbe di funzionare). Il progetto del sistema di condizionamento può altresì prevedere una qualche forma di ridondanza dell’impianto, per fare fronte al possibile cedimento di un’unità refrigerante.
Per quanto riguarda il dimensionamento, una prima grossolana quantificazione del calore che il sistema dev’essere in grado di asportare deve tenere conto dell’assorbimento elettrico di tutti i sistemi, oltre naturalmente alle quote dovute all’illuminazione dei locali e alla presenza del personale.
Una corretta definizione dei percorsi per i cablaggi, la loro ridondanza e la scelta dei materiali più opportuni sono altri due aspetti che contribuiscono in modo importante alla Business Continuity, riducendo il rischio di black out o d’isolamento di rete in caso di accidentale danneggiamento dei cavidotti oppure riducendo la generazione di fumo in caso di incendio.
È bene che lo schema di cablaggio non sia il risultato di una serie di disordinati interventi incrementali effettuati in un lungo arco di tempo intorno a una rete di base obsoleta, ma che al contrario sia il frutto di un vero e proprio progetto di cablaggio strutturato dell’edificio, capace di supportare in modo ordinato e senza “forzature” o scompensi, entro limiti prefissati e noti, eventuali estensioni e potenziamenti della rete.
Un aspetto da non trascurare, a tale proposito, è il mantenimento di documentazione aggiornata sullo schema di cablaggio dell’edificio, che rende più facile ed economico un eventuale upgrade programmato, mentre in caso di evento critico permette di effettuare interventi di riparazione più rapidamente e a colpo sicuro. Specialmente nelle installazioni più complesse risulta conveniente archiviare e consultare questo tipo di documentazione sfruttando particolari applicazioni gestionali (Cable plant documentation software).

 

Schemi di replicazione dei dati “a caldo” per dischi fissi
Uno dei modi per fare fronte al possibile rischio di guasto a una unità disco consiste nel mantenere una copia completa degli stessi dati su una unità disco diversa. Lo si può fare eseguendo regolarmente un backup, ma tale approccio presenta almeno due inconvenienti. Innanzitutto

Lezione 4 IT Administrator Sicurezza informatica

resterebbero comunque non protetti i dati modificati dopo l’ultimo backup; in secondo luogo, il recupero dei dati da un backup è un’operazione “non trasparente”, che dev’essere eseguita esplicitamente, richiede tempo (lanciare un’applicazione, selezionare i dati da recuperare, attendere che il recupero avvenga) e non si presta, per tali ragioni, a supportare in modo appropriato una strategia di Business Continuity.
Una soluzione convincente per il problema della prote-

banda, per es. applicazioni video

 

A A E E
B B F F
C C G G
D D H H

I I M M
J J N N
K K O O
L L P P

zione dei dati dei dischi fissi consiste invece nel mantenere una “copia a caldo” dei dati, aggiornata in tempo reale, pronta a subentrare alla copia primaria senza causare la minima interruzione del servizio. Il modo più economico per

Coppia di dischi dati in mirror

• RAID 1 •
Numero minimo dischi: 2

Coppia di dischi dati in mirror

Coppia di dischi dati in mirror

Coppia di dischi dati in mirror

ottenerlo è di ridondare le unità disco con altri dispositivi identici, e gestire il tutto secondo una delle configurazioni previste dalla tecnologia RAID (Redundant Array of Inexpensive Disks: letteralmente: schiera ridondata di dischi a basso costo).
Va detto subito che molti degli schemi RAID esistenti affrontano il solo problema della protezione dei dati, altri il solo problema del miglioramento delle prestazioni e altri entrambe le questioni.
Gli schemi che seguono mostrano il “bouquet” di configurazioni RAID possibili.

Descrizione: Mirroring + Duplexing
Ridondanza: 100%. Richiede 2N drives
Prestazioni: su ogni tandem: raddoppiano in lettura, invariate in scrittura
Fault Tolerance: elevata. A certe condizioni sono sopportabili anche guasti multipli simultanei Applicazioni idonee: applicazioni che richiedono alta disponibilità

Il concetto di base è duplice: da un lato la distribuzione dei dati fra più dischi (“striping”), finalizzata all’aumento delle prestazioni (una determinata quantità di dati può infatti essere letta in parallelo, per metà da un disco e per l’altra metà da un secondo disco); dall’altro la ridondanza dei dati, che consente di resistere a un guasto singolo o multi-

A0 A1 A2 A3
B0 B1 B2 B3
C0 C1 C2 C3
D0 D1 D2 D3

Dischi dati
• RAID 2 •
Numero minimo dischi: -

ECC A/a
ECC B/a ECC C/a ECC D/a

ECC A/b
ECC B/b ECC C/b ECC D/b

Dischi ECC

ECC A/c
ECC B/c ECC C/c ECC D/c

plo ricostruendo i dati a partire da bit di parità, codici ECC (Error Correcting Code) oppure rileggendoli da una pura e semplice replica integrale. I codici ECC costituiscono un sistema per monitorare l’accuratezza delle informazioni e apportare eventuali correzioni nel caso in cui si siano verificate alterazioni rispetto al valore originale a seguito di difetti solitamente di natura fisica. La correzione è possibile poiché il codice consente di risalire alla posizione del bit errato all’interno della “parola” ossia del gruppo di bit monitorato.
Per ogni schema RAID è possibile quantificare l’aumento di prestazioni raggiungibile, così come il numero di guasti simultanei sopportabili. Generalmente poi è possibile

Descrizione: parallelismo + codici a correzione d’errore (ECC)
Ridondanza: elevata ma minore di RAID 1. Interi dischi sono dedicati alla memorizzazione dei codici ECC. Prestazioni: aumento delle prestazioni read/write direttamente proporzionale al parallelismo esistente sul gruppo dei dischi dati Fault Tolerance: corregge al volo errori singoli in una “parola” dati
Applicazioni idonee: non è commercialmente conveniente a causa dell’elevata ridondanza hardware

Generazione

sostituire i dischi guasti senza interruzione di servizio. A seconda degli schemi RAID e delle prestazioni del controller, l’attività di compensazione automatica degli errori o guasti può avere un effetto da nullo a medio sulle prestazioni del sistema.
La grande varietà di schemi RAID definiti nasce dal gran numero di possibili combinazioni dei vari schemi di ridondanza (replica, parità, ECC) e di striping.

A0 A1 A2 A3
B0 B1 B2 B3
C0 C1 C2 C3
D0 D1 D2 D3
Dischi dati 0 Dischi dati 1 Dischi dati 2 Dischi dati 3 (Stripe = RAID 3 Blocco = RAID 4)

• RAID 3 •
Numero minimo dischi: 3

XOR A parità
B parità C parità D parità
Disco parità

È interessante notare che con un investimento di entità tutto sommato modesta è possibile realizzare un sistema di memorizzazione che è al tempo stesso più veloce e di gran lunga più sicuro del sistema di partenza.

 

A B C D
E F G H
I J K L
M N O etc...
• RAID 0 •
Numero minimo dischi: 2
Descrizione: striping (parallelismo senza ridondanza)
Ridondanza: nessuna
Prestazioni: aumentano grazie al parallelismo fra dischi, controller e canali DMA
Fault Tolerance: nessuna
Applicazioni idonee: applicazioni ad alta intensità di

Descrizione: parallelismo + parità XOR a livello di stripe (generata durante le scritture, verificata durante le letture) Ridondanza: bassa. Richiede N+1 drives.
Prestazioni: aumento delle prestazioni in lettura direttamente proporzionale al parallelismo esistente sul gruppo dei dischi dati
Fault Tolerance: corregge al volo gli errori senza rallentare il ser vizio
Applicazioni idonee: applicazioni ad alta intensità di banda con requisiti di disponibilità

 

• RAID 4 •
Numero minimo dischi: 3

67 www.pcopen.it

IT Administrator Sicurezza informatica Lezione 4

Descrizione: parallelismo + parità a livello di blocco (generata durante le scritture, verificata durante le letture) Ridondanza: bassa. Richiede N+1 drives
Prestazioni: la granularità a livello di blocco fa sì che ogni richiesta di lettura o scrittura di blocco interessi un solo disco dati. Ciò permette potenzialmente di trattare più richieste in parallelo, cosa impossibile con RAID 3. Il singolo disco per la parità diventa però il collo di bottiglia (specie in scrittura)
Fault Tolerance: la correzione degli errori ha le stesse potenzialità di RAID 3 ma avviene più lentamente Applicazioni idonee: applicazioni RAID 3 bisognose di un aumento di prestazioni soprattutto in lettura

 

• RAID 5 •
Numero minimo dischi: 3
Descrizione: parallelismo + informazioni di parità distribuite fra i dischi dati
Ridondanza: bassa. Richiede N+1 drives Prestazioni: massime prestazioni in lettura; medie in scrittura
Fault Tolerance: la correzione degli errori ha un impatto moderato sulle prestazioni In caso di guasto a un disco la sua ricostruzione è più difficoltosa che in altri schemi Applicazioni idonee: File ser vers Application ser vers Web ser vers Database ser vers

 

• RAID 6 •
Numero minimo dischi: 4
Descrizione: parallelismo + parità distribuita fra i dischi + ECC distribuiti fra i dischi
Ridondanza: superiore all’overhead richiesto da RAID 5. Richiede N+2 drives
Prestazioni: prestazioni elevate a condizione che il controller sia veloce a generare e verificare i codici ECC. Fault Tolerance: estrema protezione e sicurezza con il minimo overhead possibile.
Resiste anche a due guasti di disco simultanei
Applicazioni idonee: applicazioni mission critical

• RAID 10 •
Numero minimo dischi: 4
Descrizione: i dati sono gestiti in striping su un tandem e in mirroring su un secondo tandem

Ridondanza: richiede 2N drives
Prestazioni: veloce come un RAID 0 ma più affidabile Fault Tolerance: sicuro come un RAID 1 ma più veloce Applicazioni idonee: applicazioni ad alte prestazioni con requisiti di disponibilità

• RAID 50 •
Numero minimo dischi: 5
Descrizione: Abbinamento di uno schema RAID 3 e di uno RAID 0
Ridondanza: molto elevata
Prestazioni: prestazioni elevate come in RAID 0
Fault Tolerance: sicuro come un RAID 3 ma più veloce
Applicazioni idonee: -

• RAID 0+1 •
Numero minimo dischi: 4
Descrizione: mirroring di due tandem i cui dischi sono gestiti in striping.
Ridondanza: richiede 2N drives
Prestazioni: prestazioni elevate come con RAID 0
Fault Tolerance: Come RAID 5.
Un singolo guasto rende l’intero array equivalente a uno schema RAID 0
Applicazioni idonee: applicazioni che richiedono alte prestazioni ma non necessariamente la massima disponibilità

Oltre agli schemi RAID, utilizzabili per aumentare l’affidabilità e/o le prestazioni di uno storage system localizzato in una certa sede fisica, meritano un cenno gli schemi di “distributed storage” a ridondanza anche geografica (Storage Area Networks, SAN).
Una SAN collega fra loro più unità disco (o nastro) e più host; in casi estremi, e usando le tecnologie di rete adatte, le entità collegate possono trovarsi a grandi distanze (al limite, anche a distanze di scala geografica). A differenza del più convenzionale schema Direct-Attached Storage (DAS), che fa un uso “punto-punto” delle tecnologie di interconnessione “locale” di unità disco a host, come SCSI in tutte le sue varianti, oppure FDDI, Firewire o USB, nelle SAN è importante la possibilità di realizzare una matrice che metta in comunicazione vari host e varie memorie di massa.
Una SAN può essere usata per consentire l’accesso a un centro di memorizzazione dati a più host ubicati in luoghi differenti, ma anche, simmetricamente, per ridondare su sedi diverse le unità disco usate da uno o più host. In questo senso, in combinazione con altre tecnologie, è utilizzabile come soluzione per migliorare la disponibilità dei dati. È chiaro però che per raggiungere tale risultato è neces-

Lezione 4 IT Administrator Sicurezza informatica

sario che la “matrice” implementata dalla rete su cui si basa la SAN possieda una ridondanza sufficiente per immunizzarla perlomeno da guasti singoli di link, switch di rete o schede di rete.
Infatti la minore affidabilità di una connessione di rete a grande distanza rispetto a un collegamento diretto SCSI significa che oltre all’evenienza di guasto di disco si deve prevedere e poter gestire anche l’evento di malfunzionamento (o congestione) della rete di interconnessione tra dischi e host.
Schemi di ridondanza per le unità di elaborazione
Per assicurare un’alta disponibilità dei dati non è sufficiente assicurarsi che le unità di memorizzazione siano “tamponate” contro possibili guasti. L’archiviazione dei dati in forma “grezza” non è tutto: l’accesso ai dati, infatti, quasi sempre comporta anche una qualche forma di elaborazione.
Vediamo tre esempi classici di elaborazione necessaria:
• per presentare i dati in forma comodamente fruibile (per esempio, una pagina Web illustrata anziché un arido “elenco” di informazioni testuali provenienti direttamente dal database);
• per trasformare i dati “grezzi” in valori utilizzabili, attraverso calcoli aritmetici o logici;
• per selezionare, ordinare, filtrare i dati da estrarre dal database.
È quindi necessario anche garantire che l’elaborazione dei dati non sia compromessa da un malfunzionamento (hardware o anche software) a un server. A tale scopo si utilizzano tecniche di “clustering” ossia il collegamento reciproco di due o più computer in modo che funzionino come se fossero uno solo. Il clustering, con filosofia analoga a quella RAID, aumenta il parallelismo con due possibili scopi: aumentare le prestazioni ripartendo i compiti su più macchine, oppure aumentare l’affidabilità dell’insieme, per esempio tenendo una macchina “in riserva calda” pronta a subentrare a una macchina che dovesse guastarsi.
Il primo schema è sfruttato soprattutto per quelle applicazioni nelle quali prevale la necessità di aumentare al massimo le prestazioni rispetto all’esigenza di assicurare affidabilità sulle singole transazioni. Il tipico esempio è quello del web server per siti ad alta intensità di traffico. Data la natura del traffico Web HTTP (composto da innumerevoli richieste elementari, la stragrande maggioranza delle quali è di sola lettura), l’esigenza primaria sta nella riduzione del tempo di latenza prima che una richiesta venga servita e, in subordine, nella riduzione del tempo necessario per servire ogni richiesta; è invece una questione assai meno rilevante il concetto di transazionalità, ossia la garanzia che tutte le operazioni collegate a una determinata transazione vadano a buon fine prima che la transazione possa essere considerata completa oppure l’annullamento delle stesse in caso contrario.
Se il livello di throughput richiesto non risulta raggiungibile con un singolo server, non resta che ricorrere a uno schema parallelo, con un raggruppamento (cluster) di unità di elaborazione gestito da politiche di bilanciamento del carico di lavoro (load balancing), che assegnano le richieste HTTP in arrivo all’unità di elaborazione in quel momento più scarica. Fra l’altro, a parità di capacità di calcolo complessiva del sistema, la soluzione parallela, basata su un gran numero di esecutori a medie prestazioni, risulta generalmente più economica e certamente più scalabile di una soluzione “single CPU” ad elevatissime prestazioni.
Il clustering può essere, però, usato anche per migliorare la disponibilità del sistema nel suo complesso attraverso un aumento di affidabilità. In sistemi di questo tipo possono essere ridondati le CPU, le schede di rete e altri componenti hardware essenziali; la commutazione, a se-

conda dei casi, può avvenire in modo immediato e trasparente oppure con coinvolgimento del software e del sistema operativo (e quindi con minor immediatezza). Per esempio, nel primo caso, due schede di rete “normali” possono essere viste dal software come una unica scheda di rete ad affidabilità circa doppia; nel secondo caso, un’applicazione di monitoraggio che rilevasse una condizione anomala sull’istanza primaria in esecuzione del software potrebbe decidere di far subentrare il server di riserva e far dirottare su di esso il futuro carico di lavoro.
Negli schemi con clustering è abbastanza normale che più unità di elaborazione accedano a un sottosistema di storage condiviso; per un ulteriore aumento di affidabilità è possibile dotarsi anche di un sistema di memorie di massa a sua volta totalmente ridondato, tuttavia questa scelta determina un rilevante aumento dei costi senza necessariamente riuscire ad eliminare la causa più probabile e frequente di disfunzione del sistema, che è dovuta al software (applicazioni e sistema operativo).
Il funzionamento delle applicazioni in cluster richiede accortezze particolari in fase di progetto e sviluppo del software, un’amministrazione di sistema più complessa e competenze specifiche per la risoluzione di eventuali malfunzionamenti.
D’altra parte, l’utilizzo di sistemi cluster generalmente può aprire possibilità interessanti, come quella di effettuare l’upgrade delle macchine anche durante il loro funzionamento, senza interruzione totale del servizio grazie alla possibilità di “allontanare” temporaneamente il carico di lavoro dal server che deve essere oggetto di azioni di manutenzione o aggiornamento.
Esiste una distinzione importante tra sistemi in cluster a “high availability” (HA) e “fault tolerant”. Con High Availability s’intende la capacità del sistema di superare un singolo punto di guasto a uno dei propri componenti mediante l’impiego di soluzioni hardware o software che permettano di riprendere l’elaborazione dopo il guasto. Fault Tolerant indica invece la capacità di un sistema di rispondere in maniera controllata a un guasto hardware o software, solitamente spegnendosi o fermandosi e trasferendo il proprio carico di lavoro a un componente o sistema replicato (mirror) che è in grado di continuare l’elaborazione iniziata.
1) Negli schemi High Availability, la salvaguardia dello stato del sistema è affidata ai dati salvati sulla memoria di massa condivisa (o al database condiviso): si tratta di una filosofia adeguata per le soluzioni applicative dove l’eventuale perdita dei dati in RAM non avrebbe che un impatto circoscritto sulla funzionalità del sistema (classico esempio, ancora una volta, i Web server). Il recupero della normale funzionalità potrebbe avvenire fin dalla prima transazione successiva all’evento critico, dopo che un apposito processo “failover” avesse provveduto a dirottare il lavoro su un altro processo server.
2) I sistemi fault tolerant sono invece progettati per mantenere addirittura una copia “calda”, integrale, continuamente aggiornata, anche dei dati in memoria centrale. In questo caso l’elaborazione può commutare e proseguire senza alcuna perturbazione significativa, ma tutt’al più con un leggero e momentaneo calo di prestazioni.

Un’altra distinzione riguarda l’architettura del sistema di memorie di massa. Esistono tre schemi principali:
1) Dischi condivisi: le CPU accedono in modo concorrente a un unico sistema dischi. Tale schema fornisce garanzie strutturali di “allineamento” dei dati visti dai vari sistemi, ma presenta svantaggi. Per evidenti necessità di controllo della concorrenza, tale accesso deve essere regolato da un “arbitro” (Distributed Lock Manager) che aumenta la complessità e riduce le prestazioni del sistema. Generalmente la distanza fisica delle

IT Administrator Sicurezza informatica Lezione 4

Tipo di rete

LAN

 

WLAN (WiFi)

 

WLAN (WiFi) WAN

Schema
di ridondanza Duplicazione della scheda di rete

Antenna Diversity (duplicazione dell’antenna)

Installazione di più Access Points operanti su più canali Collegamento a due ISP diversi (oppure doppio collegamento allo stesso ISP) per resistere a malfunzionamenti sul “last mile”

Logica di funzionamento

Qualora l’autodiagnosi riveli un guasto a una delle due schede, un apposito sistema fa subentrare la scheda di scorta, con lo stesso indirizzo di rete della scheda fuori ser vizio
Un circuito provvede a monitorare costantemente il livello di disturbo, echi, riflessioni, etc., rilevato in ricezione su ognuna delle due antenne e sceglie quella con la migliore ricezione
Le schede di rete sui client possono commutare automaticamente sul canale “migliore”
Il router rileva eventuali interruzioni di ser vizio su uno dei due link e in base a regole precedentemente impostate provvede a dirottare il traffico sull’altra direttrice Internet. In condizioni normali il traffico può essere avviato a entrambe le direttrici per aumentare la banda complessiva

Effetto “ai morsetti”

Le due schede di rete sono viste dal sistema operativo e dalle applicazioni come un’unica scheda di rete a maggiore affidabilità
Il link di rete wireless appare più stabile e il throughput maggiore

I client osser vano un momentaneo disser vizio solo in caso di passaggio ad altro canale Gli applicativi di rete “vedono” una connessione Internet con disser vizi sporadici e facilmente recuperabili

Reti di trasporto Network Protection;

I circuiti sono completamente ridondati e il

Gli strati di rete che si avvalgono

(SDH/WDM)

Network Restoration

tasso d’errore è tenuto sotto sor veglianza hardware.
Gli apparati di rete (protection) o i sistemi di gestione di rete (restoration) provvedono a deviare il traffico su un path alternativo in caso di guasto o tasso d’errore eccessivo

della rete di trasporto “vedono” connessioni affidabili. La commutazione comporta un’interruzione di ser vizio di pochi millisecondi

CPU dal sistema dischi deve essere bassa, per motivi tecnici.
2) Dischi in mirroring: ogni CPU ha un proprio sistema dischi e un apposito sistema di replicazione che provvede a rilevare tutte le sue scritture su disco e a replicarle sulle unità a disco dell’altra CPU, attraverso un collegamento LAN. Rispetto allo schema precedente calano i costi, ma anche le garanzie di perfetta e costante identità dei dati tra le varie unità disco e anche la scalabilità del sistema è minore.
3) Nessuna condivisione: in condizioni di funzionamento normale, non vi sono risorse disco condivise fra le CPU: tali risorse sono controllate e utilizzate solo dalla CPU attiva. Solo in caso di malfunzionamento di quest’ultima scatta un meccanismo che trasferisce la “proprietà” di tali risorse alla CPU “di riserva” che subentra a quella in crisi.
Scalabilità e disponibilità sono simili a quelle ottenibili con la prima soluzione (anche se il “trasferimento di proprietà” può richiedere un tempo non trascurabile); la mancanza di un Distributed Lock Manager inoltre riduce la complessità del sistema.
Infrastrutture per la disponibilità della rete
Non basta garantire la disponibilità dei dati memorizzati su disco e la disponibilità delle unità di elaborazione, con schemi a ridondanza più o meno marcata, per assicurare complessivamente la disponibilità del servizio. Un aspetto fondamentale riguarda infatti la disponibilità della connessione di rete attraverso la quale gli utenti accedono al servizio, oppure della LAN che interconnette i sistemi che concorrono a erogare il servizio, oppure ancora della LAN (o SAN) che collega questi ultimi alle unità disco condivise.
Come ogni componente dell’architettura, anche la LAN può guastarsi o semplicemente andare incontro a fenomeni di congestione, e ancora una volta le strategie per aumentare l’affidabilità o per migliorare le prestazioni condividono la filosofia di base: ridondanza.
Nel caso delle reti la ridondanza può attuarsi con modalità diverse a seconda del tipo di tecnologia di rete (ve-

di la tabella sulla ridondanza).
In generale, in un’infrastruttura di rete, i punti di criticità riguardano:
• La connessione al provider esterno
• Il servizio offerto dal provider esterno
• Il cablaggio interno
• Le schede di rete
• Gli apparati attivi di rete

Per quanto riguarda le cause esterne di malfunzionamento, una prima forma di autotutela “non tecnologica” può consistere nel negoziare col provider un Service Level Agreement (SLA) con tanto di penali in caso di malfunzionamenti di entità e frequenza superiori a determinate soglie contrattuali. In tal caso assume particolare importanza poter disporre di strumenti di misura per rilevare (ed eventualmente dimostrare in sede di contenzioso) quando si producono tali malfunzionamenti.
Come accennato in tabella, inoltre, una strategia efficace consiste anche nel ridondare (almeno duplicare) il collegamento al provider esterno, oppure nel collegarsi a due provider diversi: rispetto alla prima, questa seconda strategia complica le cose dal punto di vista degli schemi di indirizzamento e può anche dare luogo a scompensi qualora la banda disponibile sia molto diversa sulle due connessioni, ma conferisce un interessante grado di protezione dall’isolamento totale anche in caso di guasti severi al backbone (dorsale) del network provider.
I rischi dovuti a cause interne possono essere mitigati con la ridondanza sui cavi, sulle schede di rete o sugli apparati attivi.
Per quanto riguarda il cablaggio in particolare è consigliabile che la ridondanza dei collegamenti sia sempre accompagnata anche da una differenziazione del percorso fisico seguito dal cavo. In sostanza, è preferibile che i due link corrano in due cavidotti distinti e separati. Diversamente si correrebbe il rischio che una lesione strutturale accidentalmente prodotta a un unico cavidotto provochi l’interruzione contemporanea sia del link primario sia di quello “di scorta”.

Lezione 4 IT Administrator Sicurezza informatica

Il backup/restore locale e in rete
Dotarsi di un sistema di memoria di massa RAID di tipo idoneo assicura di non poter mai perdere dati? Purtroppo no. L’architettura RAID (escluso RAID 0, con puro striping, che è finalizzato soltanto all’aumento di prestazioni) fornisce garanzie contro le perdite di dati dovute a guasto fisico di un certo numero prestabilito di unità disco.
Nulla può, però, contro la cancellazione o l’alterazione di dati dovuta a un malfunzionamento software, sia esso scatenato da un bug dell’applicazione o del sistema operativo, oppure da un virus, da un malware o da altre minacce analoghe. Ironicamente, anche se nello schema RAID i dischi fossero fisicamente raddoppiati o triplicati, in caso di attacco da parte di un virus che (per esempio) formatta il disco fisso, tutto quello che RAID ci garantirebbe sarebbe soltanto di replicare esattamente tale formattazione su tutte le copie del disco!
È dunque necessario prendere contromisure anche per resistere all’alterazione dei dati dovuta a cause software e per assicurarsi la possibilità di regredire tale danno, almeno entro un certo lasso di tempo. In questo caso, l’immediatezza o la simultaneità della copia dei dati che viene effettuata dagli schemi RAID è l’esatto contrario di ciò che occorre. Serve in realtà una copia dei dati “fredda, ma non troppo”: fredda, per tenerla fuori pericolo rispetto a malfunzionamenti software che potrebbero danneggiarla irreparabilmente “online” come la copia “calda”, rendendola del tutto inutile ai fini di un eventuale ripristino; ma non troppo fredda, perché una copia molto vecchia non dà conto di troppe modifiche (legittime e intenzionali) intervenute sui dati prima del verificarsi dell’errore software o dello scatenarsi del virus. Sarebbe ovviamente desiderabile che un recupero dei dati riuscisse a ricostruire tali informazioni dalla copia fredda. Tuttavia è importante rendersi conto del fatto che una ricostruzione di tutte le modifiche intervenute sui dati, fino all’ultima modifica, quella “dannosa” (esclusa quest’ultima, ovviamente), non può avvenire soltanto con copie fredde periodiche dei dati. Occorre affiancarle, per esempio, con un log cronologico e non cancellabile delle transazioni avvenute in seguito. Mediante tale abbinata, si potrebbe ripartire dallo stato integrale salvato nell’ultima copia fredda e da lì proseguire, rieseguendo in sequenza le transazioni memorizzate sul log fino alla penultima transazione, compresa.
Tale schema logico può essere attuato usando l’ultimo backup integrale più l’ultimo backup differenziale, oppure l’ultimo backup integrale più tutti i backup incrementali successivi ad esso.
Anche i file system con journaling (come NTFS nel mondo Windows, oppure Ext3, ReiserFS, XFS e JFS nel caso di Linux) mantengono una storia delle modifiche elementari intervenute sulla struttura del file system stesso, ma con uno scopo differente: assicurare la transazionalità delle operazioni, che a livello logico-applicativo devono avvenire in modo atomico (creazione di una directory, creazione di un file, aumento delle dimensioni di un file, cancellazione), ma che a basso livello si traducono in realtà in una sequenza di passi elementari. Tali operazioni, sviluppandosi in modo transazionale, lasciano il disco in uno stato consistente oppure, in caso di prematura interruzione del funzionamento, in uno stato inconsistente dal quale però ci si possa automaticamente riportare in uno stato consistente utilizzando il log delle operazioni elementari effettuate (il journal, appunto). Per dirla con terminologia database, l’ultima transazione, avvenuta sul file system in modo incompleto, subirà un rollback.
La tecnica assicura che per il ripristino di uno stato perfettamente consistente del file system bastino pochi secondi, senza bisogno di effettuare ogni volta una scansione integrale del disco, “a forza bruta”, alla ricerca di possibili

errori. La disponibilità di tool di scansione resta comunque necessaria per il recupero di situazioni in cui il deterioramento delle strutture su disco e dello stesso journal siano tali da rendere impossibile il recupero transazionale automatico.
Per approfondimenti sui journaling file systems (con particolare riferimento a Linux) si veda ad esempio http://www.linux-mag.com/2002-10/jfs_01.html. Per NTFS si veda ad esempio http://www.microsoft.com/windows2000/community/centers/fileervices/fileervices_faq. mspx.
I backup
Le “copie fredde, ma non troppo” a cui abbiamo poc’anzi accennato vanno tecnicamente sotto il nome di “copie di back-up” o “backup” tout court.
Nonostante si tratti “semplicemente” di copie dei file presenti sul disco, esistono almeno tre strategie fondamentali per effettuarle, che differiscono per il criterio di selezione dei file da salvare: tutti o solo quelli recentemente modificati, con due sfumature di significato per “recentemente”. (v. tabella Tipi di backup).
Oltre ai tipi di backup, che avvengono in modo puntuale a scadenze regolari secondo un piano di backup appositamente stabilito dall’amministratore di sistema, esiste una diversa politica di backup secondo la quale la copia di sicurezza dei file avviene continuativamente durante il funzionamento dei sistemi. Il vantaggio consiste nel fatto che i sistemi non devono essere fermati durante il backup, inoltre non vi è mai uno specifico momento del giorno in cui il sistema è fortemente rallentato perché sta eseguendo il backup. Vi è invece un costante, ma minimo rallentamento dovuto all’attività di backup che procede regolarmente in background. Questo tipo di backup “continuo” è detto “online backup”, in contrapposizione con i backup effettuati in modo “puntuale” che sono spesso chiamati “offline backup”.
Attenzione all’ambiguità dell’espressione “online backup” che può anche essere usata per riferirsi a un backup effettuato su un server di rete, magari addirittura su un sito Internet, anziché su unità disco locali. Il vantaggio del backup eseguito in tal modo consiste nel fatto che i dati possono risultare accessibili da molti punti diversi e non solo dall’interno dei locali dell’organizzazione. Si tratta quindi di una procedura utile per chi è spesso fuori sede, ma pone anche seri problemi di riservatezza dei dati salvati: non soltanto il provider dello spazio su disco online usato per il backup deve garantire la privacy dei dati salvati sul suo sito, ma il controllo degli accessi dev’essere adeguato, per evitare che attacchi da Internet permettano a chiunque di entrare in possesso dei dati salvati sul disco online. In generale è bene usare cautela nell’impiego di servizi di backup online e in particolare evitare i servizi gratuiti o a basso costo che non possono offrire il livello di protezione necessario. Esistono provider che eseguono la cifratura integrale delle informazioni e che, di conseguenza, richiedono costi maggiori, ma pienamente giustificati.
Se il backup avviene con regolarità, a certe ore del giorno (più spesso, della notte), su dischi condivisi in rete sulla LAN aziendale, è possibile ed opportuno studiare l’entità dei flussi di dati e tenerne sotto controllo l’evoluzione nel tempo, anche per intervenire con opportune azioni prima che si produca la saturazione della rete durante l’esecuzione dei backup.
Le valutazioni per il dimensionamento della rete, per la definizione della concentrazione o distribuzione delle stazioni di backup, per la scelta della periodicità e del tipo di backup da effettuare e per stabilire gli orari esatti ai quali far scattare i backup delle varie macchine devono basarsi su quattro fattori.
1) una stima della quantità di dati da trasferire,
2) una misura della banda mediamente disponibile sulla

IT Administrator Sicurezza informatica Lezione 4

Tipo backup: incrementale Che cosa viene salvato: tutti i file creati o modificati dopo il più recente fra l’ultimo backup integrale e l’ultimo backup incrementale Come avviene il recupero: si prendono in considerazione l’ultimo backup integrale e tutti i backup incrementali effettuati da allora in poi Vantaggi: il backup può essere eseguito frequentemente in quanto richiede poco tempo e poco spazio su disco (v. figura). Si riduce così la “finestra” di lavoro fatto non protetta da backup Svantaggi: il recupero dei dati richiede un tempo non breve, in quanto occorre prendere in considerazione l’ultimo backup integrale e tutti i successivi backup incrementali

Rappresentazione schematica del volume di dati trattato nel tempo con i tre tipi fondamentali di backup. Con il backup integrale i backup set hanno tutti dimensioni elevate. I backup incrementali hanno dimensioni dipendenti dalle modifiche
inter venute sul file system dall’ultimo backup incrementale. I backup differenziali hanno generalmente
dimensioni crescenti in quanto accumulano le modifiche inter venute sul file system dall’ultimo backup integrale; le dimensioni del backup set tornano modeste subito dopo che viene eseguito un nuovo backup integrale

Tipo backup: integrale Che cosa viene salvato: l’intero contenuto delle aree di file system per le quali è stato impostato il backup Come avviene il recupero: si prende in considerazione l’ultimo backup integrale Vantaggi: Il recupero dei dati è facilitato in quanto il backup set contiene un’immagine del file system completa di tutti i file
Svantaggi: l’esecuzione del backup è molto lenta e richiede una grande quantità di spazio (v. figura), perciò non può essere eseguita troppo frequentemente. Non conviene usare questo schema di backup da solo, ma abbinarlo a uno dei due successivi.

LAN aziendale nella fascia oraria in cui si prevede di far scattare il backup,
3) il numero di macchine da sottoporre a backup,
4) la topologia della rete che interconnette le macchine e le stazioni di backup.
Se il servizio di backup per tutte le macchine è fornito da un’unica stazione di memorizzazione connessa alla rete aziendale, il collo di bottiglia diventa immediatamente la connessione di rete di tale sistema. Al crescere del numero di macchine da sottoporre a backup e delle dimensioni del disco di ognuna di esse, anche adottando le politiche più prudenti, si arriverà presto alla saturazione di tale collegamento. Si dovrà allora pensare, ad esempio, a un upgrade dell’infrastruttura di rete, magari con una sua gerarchizzazione, oppure all’installazione di più stazioni di backup operanti in parallelo e attestate ognuna sul troncone di rete che ospita le macchine da servire, in modo tale da ripartire più efficacemente il traffico e il carico di backup.
Le unità di backup possono essere basate su hard disk, nastri o dischi ottici. Queste tecnologie hanno caratteristiche diverse sotto vari punti di vista (costo per GByte dei supporti, costo per GByte dei drive, throughput in lettura/scrittura, tempo di accesso medio in modalità recupero, durata dei supporti, numero massimo di cicli di lettura/scrittura sopportabili).
La scelta di quale tecnologia impiegare deve farsi caso per caso, tenendo conto di cinque fattori.
1) frequenza del backup. I dischi ottici riscrivibili hanno un numero massimo di cicli lettura/scrittura sopportabili.
2) velocità alla quale si prevede che affluiranno i dati. Il throughput delle unità a nastro e hard disk è solitamente maggiore di quello delle unità ottiche (specie in scrittura).
3) stima della probabilità che si renda necessario un ripristino di dati: se queste operazioni sono molto frequenti, le unità a nastro, ad accesso sequenziale, non sarebbero particolarmente indicate.
4) quantità totale di dati soggetti a backup. Se questa quantità è enorme, l’alta densità di memorizzazione e il basso costo per GByte delle unità a nastro possono essere ideali.
5) lunghezza della “storia” di backup che si desidera mantenere. Vedi punto precedente.

Tipo backup: differenziale Che cosa viene salvato: tutti i file creati o modificati dopo l’ultimo backup integrale Come avviene il recupero: Si prendono in considerazione l’ultimo backup integrale e solo l’ultimo dei backup differenziali effettuati dopo di esso Vantaggi: il recupero dei dati è più veloce che con il backup incrementale Svantaggi: Il recupero dei dati è leggermente più lento che con il backup solo integrale.
La dimensione del backup differenziale non è mai inferiore a quella di un backup incrementale fatto nelle stesse condizioni e continua a crescere (v. figura) fino al prossimo backup integrale.

Effettuare backup e restore in ambiente Windows XP
Con riferimento a Windows XP e alla utility di backup che Microsoft fornisce insieme al sistema operativo, vediamo ora come si procede per effettuare un backup. In questo caso particolare effettueremo un backup integrale di una specifica cartella del PC locale (My Documents), salvando i dati in una cartella creata appositamente su un disco di rete.
1 welcome to backup wizard.bmp
Anzitutto lanciamo l’applicazione Backup con Start/Tutti i programmi/Accessori/Utilità di sistema/Backup. Se è la prima volta che utilizziamo il programma e non abbiamo mai alterato le sue impostazioni predefinite, si presenterà questa schermata. Consigliamo di fare clic su Modalità avanzata per avere pieno controllo sulle numerose opzioni disponibili.

2 Dopo aver selezionato Modalità avanzata, appare la schermata principale del programma. Consigliamo, almeno la prima volta, di seguire la procedura guidata (Wizard) facendo clic sul primo dei tre pulsanti.

3 Ci troviamo così nuovamente alla schermata di avvio del Wizard, ma questa volta è preimpostata la Modalità

Lezione 4 IT Administrator Sicurezza informatica

che risulta quindi solo parzialmente interessato dall’operazione

6 Il passo successivo consiste nella scelta dell’unità di storage destinataria del backup. Se l’elenco a discesa di opzioni offerte non contiene quella desiderata, è possibile selezionare una destinazione diversa. Nel nostro caso desideriamo salvare i dati su un disco di rete non compreso in elenco, quindi facciamo clic su Sfoglia... per selezionarlo.

 

avanzata. Premiamo Avanti per accedere alle prime opzioni.

4 La prima scelta da compiere riguarda l’area macroscopica interessata dal backup. È possibile salvare tutti i dati e impostazioni memorizzati sul computer, oppure un sottoinsieme specificato, oppure ancora le sole impostazioni di sistema. Per il nostro esempio scegliamo di salvare un sottoinsieme dei file del disco (seconda opzione).

 

7Nel dialog box che appare scegliamo l’unità disco di rete ed eventualmente creiamo una cartella (Backup PC1) in cui depositare il backup. È inoltre necessario scegliere un nome per il backup, nella casella Nome file in basso. Scegliamo il nome “backup PC1” e facciamo clic su Salva.

 

5 Avendo deciso di salvare solo alcuni dei file su disco, nella fase successiva ci viene richiesto di scegliere quali. Nel nostro esempio supponiamo di voler salvare la cartella Documenti, perciò contrassegnamo la casella nell’elenco di sinistra. Il segno di selezione qui appare in blu, a significare che l’oggetto è integralmente selezionato. A destra vediamo invece che accanto all’unità C è apparso un segno di spunta verde (e non blu), perché la cartella Documenti rappresenta solo un sottoinsieme del disco C:,

IT Administrator Sicurezza informatica Lezione 4

8 Una volta selezionata l’unità disco e cartella di destinazione ed il nome del backup, veniamo riportati nella schermata del wizard. Premiamo Avanti per passare alla fase finale.

 

9 Nella videata conclusiva vediamo un riepilogo delle impostazioni di base relative al job di backup di imminente attivazione. È tuttavia presente un pulsante “Avanzate” che dà accesso a ulteriori impostazioni per un controllo fine su tempi e modi dell’operazione. Premiamolo.

 

10 La prima opzione riguarda il tipo di backup. Incrementale e Differenziale corrispondono alle tipologie discusse nella Tabella Tipi di backup. “Normale” corrisponde a un backup integrale, in quanto salva i file e li marca tutti come archiviati. “Copia” salva i file, ma non li marca come archiviati. “Giornaliero” è una sorta di backup incrementale che salva i file creati o modificati in data

odierna, indipendentemente dal fatto che fossero già stati salvati da un precedente backup; inoltre, i file creati o modificati prima di oggi, ma dopo l’ultimo backup effettuato resterebbero non salvati. Se si decide di utilizzare l’opzione Giornaliero, consigliamo di farlo solo quotidianamente e solo se si è ben certi dell’effetto che si sta ottenendo.
Per il nostro esempio selezioniamo “Normale”.

11 Questa schermata consente di richiedere la verifica dei dati scritti (vivamente raccomandato), di selezionare la compressione hardware dei dati, ove disponibile, e di attivare o disattivare la modalità “copia replicata del volume” che effettua comunque il backup dei file anche se sono aperti in scrittura da qualche processo.

12 La schermata successiva consente di scegliere se aggiungere backup a quelli già esistenti nella cartella di destinazione oppure se rimpiazzare i backup vecchi con quelli nuovi. In questo secondo caso, date le implicazioni di sicurezza, è offerta un’ulteriore opzione per restringere l’accesso al solo proprietario o amministratore del sistema.

13 Vi è poi una schermata che consente di scegliere se eseguire il backup subito o in un secondo tempo. Se si desidera differirlo è sufficiente selezionare “In seguito” e premere “Imposta pianificazione”: apparirà una finestra con le necessarie regolazioni.

14 Nella scheda “Pianificazione processo” è possibile scegliere tra varie possibili periodicità per l’esecuzione del backup appena definito. Oltre alla periodicità è possibile selezionare l’orario di avvio. Premendo il pulsante “Avanzate” si ha accesso a ulteriori opzioni di programmazione.

Lezione 4 IT Administrator Sicurezza informatica

15 Da questa finestra è possibile determinare il periodo di tempo durante il quale deve considerarsi valida la programmazione espressa nella schermata precedente (per esempio: il backup giornaliero dovrà essere eseguito solo per i prossimi 15 giorni).
È anche possibile impostare una ripetizione continua del task con una certa periodicità, o per un certo tempo, o ancora fino a un certo momento.

16 La scheda Pianificazione processo permette ad esempio d’interrompere i backup la cui esecuzione stia prendendo troppo tempo, o di farli eseguire solo se e quando il computer è “scarico” di lavoro da un certo tempo, di escludere le operazioni di backup quando il PC sta funzionando a batterie (per non rischiare di restare “a secco” a metà backup, compromettendone l’integrità e rendendolo di fatto inutile).

17 Una volta completate le impostazioni, il Wizard presenta una schermata conclusiva con il riepilogo delle opzioni impostate. Controlliamole e premiamo Fine per procedere (o Indietro, se desiderato, per correggerle).

18 Così si presenta la schermata di monitoraggio dello stato di avanzamento del backup. La stima di tempo mancante al completamento dell’operazione è importante perché, nel caso di backup di rete, consente di studiare il tempo di impegno della LAN da parte di ogni PC soggetto a backup. In reti non troppo grandi, questo permette all’amministratore di programmare l’ora di inizio e la durata delle operazioni di backup dei singoli PC per evitare che, “accavallandosi”, esse causino congestione nella rete e sovraccarico sul file ser ver destinatario dei backup.

19 Al termine dell’operazione viene generato un log in forma testuale che può essere visualizzato in Blocco note

IT Administrator Sicurezza informatica Lezione 4

 

premendo l’apposito pulsante. Nella figura vediamo come si presenta il log generato dal nostro esempio di backup integrale.

20 L’operazione di ripristino (restore) è nettamente più semplice di quella di backup. Una volta lanciato lo strumento in Modalità avanzata e selezionata la scheda “Ripristino”, appare un’inter faccia per la selezione di uno o più file o cartelle da recuperare. È sufficiente contrassegnare una cartella nell’albero di sinistra (oppure un file nell’elenco di destra) e scegliere la destinazione dall’elenco a discesa in basso: i file possono essere ripristinati nelle posizioni originali (sovrascrivendo eventuali modifiche successive) oppure in una posizione differente, che andrà eventualmente specificata. L’opzione “Singola cartella” consente infine di ripristinare tutti i file selezionati in una singola directory “piatta” specificata, perdendo quindi la strutturazione in cartelle del backup originario.
Una volta fissate le opzioni si preme “Avvia ripristino” per avviare il processo. Da notare che l’inter faccia di controllo per il restore può essere usata (senza lanciare il restore vero e proprio) anche solo per controllare quali file sono stati effettivamente archiviati nel file di archivio.

 

21 Così si presenta la quarta e ultima scheda dell’inter faccia avanzata dello strumento di backup/ripristino di Windows XP. Si tratta di un vero e proprio calendario per la pianificazione dei backup. Per programmare che un backup avvenga a una certa data è
sufficiente selezionarla sul calendario e premere Aggiungi processo. Verrà così lanciato il wizard che ben conosciamo, con le date preimpostate secondo la selezione appena effettuata. Le altre opzioni dovranno essere impostate nel modo consueto. Alla fine si ritornerà a questa schermata, con un’icona nella casella della data interessata dal job di backup appena programmato.

Effettuare backup e restore in ambiente Linux
Anche per il backup in ambiente Linux non mancano le utility con interfaccia grafica “amichevole”, è bene abituarsi ad usare gli strumenti che esistono sicuramente in tutte le installazioni: il comando di archiviazione tar, le utility di compressione/decompressione compress/uncompress, gzip/gunzip, zip/unzip e il meccanismo di temporizzazione-programmazione cron/crontab.
Il comando tar deve il suo nome all’acronimo “Tape ARchive”: un nome risalente all’epoca in cui il backup, dato il costo proibitivo dei dischi di alta capacità, si faceva sempre su nastro. Si può pensare a questo comando come a un PKZIP privo d’interfaccia grafica. Come ZIP, tar è in grado di leggere un albero di cartelle e file e di salvarli in un unico file archivio (normalmente con suffisso .tar e perciò detto “tar file”, in modo analogo al fatto che un file .ZIP è chiamato “zip archive”), ricordando anche la struttura dell’albero. Il file archivio può venire salvato su un file system basato su hard disk oppure, per esempio, su unità a nastro. Per esempio, nel caso del disco fisso:
tar cvf mioarchivio.tar /usr/marco/cartella-da-archiviare/*

Il comando sopra crea il file mioarchivio.tar nella directory corrente. Il file contiene un salvataggio completo dell’albero di file system sotteso alla directory specificata come ultimo parametro. A tal fine la directory viene visitata ricorsivamente e in modo esaustivo dal comando tar.
Il parametro cvf sta a indicare che il tar file deve essere Creato (“c”) con il Filename (“f”) specificato come parametro immediatamente successivo e che durante il processo dovrà essere emesso un output diagnostico Verboso (“v”) che riferisca sulle operazioni in corso, sui file interessati dall’archiviazione e sulla loro dimensione man mano che vengono inseriti nel tar file.
È possibile (e caldamente raccomandabile, allo scopo di verificare che l’archivio sia stato creato correttamente) richiedere al comando tar di mostrare l’elenco integrale del contenuto di un determinato tar-file, senza tuttavia estrarre i file che vi sono contenuti: per esempio:
tar tvf mioarchivio.tar

In questo caso la lettera “t” sta per “Table of contents”: ciò che si chiede è infatti di stampare il “sommario” dell’archivio. L’elenco dei file viene stampato su “stdout” e nella probabile ipotesi che sia troppo lungo sarà bene mandare l’output di tar in pipe a more: ciò consentirà la lettura pagina per pagina (“spazio” per avanzare, “q” per interrompere).
tar tvf mioarchivio.tar | more

Lo stesso comando tar usato per creare l’archivio svolge anche la funzione inversa, ossia a partire dal file archivio è in grado di ricostruire l’albero di file e cartelle originario integralmente o parzialmente, o anche di estrarre singoli file specificati.
tar xvf mioarchivio.tar

Lezione 4 IT Administrator Sicurezza informatica

Questa volta tar effettuerà un’operazione di eXtract (“x”) di tutto il contenuto del tar-File (“f”) specificato, sempre generando un diagnostico Verboso (“v”). L’albero di file verrà ricreato sotto la directory corrente.
Se avessimo voluto estrarre solo un particolare file sarebbe stato sufficiente specificarne il nome come secondo parametro:
tar xvf mioarchivio.tar soloquestofile.txt

Il comando tar esegue la compressione dei file con l'unico limite di non farlo se si scrive su una device, in tal caso è necessario concatenare in pipeil comando gzip.
Versioni recenti di tar supportano in forma nativa l’integrazione con gzip/gunzip. Per richiedere che il tar-file venga compresso/espanso “al volo” durante l’operazione di creazione/estrazione si aggiunge allora il qualificatore z: tar cvzf mioarchivio.tgz /usr/marco/cartella-daarchiviare/*
per archiviare con compressione, e
tar xvzf mioarchivio.tgz
per estrarre con espansione.

È molto frequente anche il caso di backup effettuati su unità a nastro (note anche come streamers). In tal caso la sintassi del comando resta invariata per quanto riguarda le opzioni fondamentali. L'unica differenza riguarda l'indicazione dell'unità destinataria del backup (un device) che prende il posto del nome del tarfile da creare o da leggere. Normalmente la prima unità a nastro installata sul sistema è rappresentata dal file speciale /dev/st0 (di cui di solito esiste un alias: /dev/tape). Quindi, per esempio, per eseguire su questa unità a nastro il backup di cui all'esempio precedente, senza compressione dati, si userà questo comando:
tar cvf /dev/st0 /usr/marco/cartella-da-archiviare/*

Quanto visto finora consente di effettuare in modo interattivo un backup o un restore dei propri file. Più interessante è però organizzare le cose in modo tale che il backup venga effettuato in forma automatica dal sistema, magari nelle ore notturne. Per farlo si combina la capacità di tar di archiviare dati (e quella di gzip di comprimerli) con il meccanismo cron per l’esecuzione programmata di task.
Tecnicamente cron non è un comando, bensì un demone. In Unix (e quindi in Linux) un demone è un processo di sistema che gira in background per espletare qualche servizio, spesso in base a file di configurazione. Nel caso di

cron, il servizio consiste nell’esecuzione temporizzata di comandi di shell. Il relativo file di configurazione è crontab. crontab contiene righe di testo composte da campi separati da spazi:
minute hour day-of-month month-of-year day-of-week command

La tabella A qui sotto riporta la sintassi accettata per ognuno di questi campi.
Per i campi che ammettono valori numerici è inoltre possibile specificare:

1) intervalli, per esempio 5-15 (da 5 a 15, estremi inclusi)

2) intervalli multipli, per esempio 5-15,25-45 (da 5 a 15 e da 25 a 45 estremi inclusi)

3) un asterisco (*), per indicare “per tutti i valori dell’intervallo ammissibile”

4) (in combinazione con intervalli o con asterisco) uno step, espresso come slash (/) seguito dal valore d’incremento. Per esempio: 0-10/2 significa 0,2,4,6,8,10. Per i giorni della settimana, 1-7/2 significa lunedì, mercoledì, venerdì, domenica.
Ed ecco alcuni esempi riassuntivi per i valori dei primi 5 campi delle righe di crontab (tabella B).
Per automatizzare l’esecuzione del backup della directory /usr/marco/dati tutti i giorni a mezzanotte e mezza, con creazione del tar-file /tmp/backup.tar, si crei anzitutto un file (per esempio: job.txt) contenente la seguente riga di testo:
0 1 * * 1-7 tar cvf /tmp/backup.tar /usr/marco/dati/*

Fatto ciò, per installare questo job negli “appuntamenti” serviti da crontab, si esegua il comando
crontab job.txt

Per verificare che il job sia stato correttamente preso in carico si usa il comando crontab -l (“l” come “list”), che visualizza il quadro della situazione attuale dei job. Per sopprimere l’attuale crontab si usa invece crontab –r (“r” come “remove”). Il file crontab non dovrebbe essere mai modificato direttamente (eventualmente è disponibile il comando crontab –e) ma a titolo di informazione precisiamo che esso viene salvato dal sistema sotto /var/spool/cron/
<username> •

Tabella A sintassi accettata per ognuno i campi

minute 0-59
hour 0-23
day-of-month 1-31
month-of-year 1-12 oppure prime tre lettere del nome inglese del mese (case insensitive) day-of-week 0-7 oppure prime tre lettere del nome inglese del giorno della settimana.
I valori 0 e 7 rappresentano entrambi la domenica
command riga di comando sintatticamente accettabile per la shell. Qualora sia necessario specificare una successione di comandi, questi andranno separati con punto e virgola.
Sono ammessi costrutti con uso di pipe (“|”)

Tabella B esempi per i valori dei primi 5 campi delle righe di crontab
10 0 * * * ogni giorno, a mezzanotte e 10 minuti
30 15 2 * * alle 15:30 il secondo giorno di ogni mese
0 21 * * 1-5 alle ore 21, dal lunedì al venerdì
15 0-23/2 * * * un quarto d’ora dopo le ore pari (alle 0:15, 2:15, 4:15,...) ogni giorno 30 12 * * sun alle 12:30 della domenica.

IT Administrator Sicurezza informatica Lezione 5
Identificare le minacce
Il codice maligno

Il concetto di sicurezza del PC è sempre comunemente associato con la difesa da virus, spyware, cavalli di Troia, worm e altri programmi concepiti per scopi illegali o semplicemente malevoli. In questa lezione di EUCIP IT Administrator Sicurezza Informatica scoprirete come identificare le minacce e difendervi con efficacia.
I contenuti sono composti da tre elementi: un articolo
sulla rivista, un articolo, molto più esteso in formato PDF
e un corso multimediale completo su CD e DVD
di Marco Mussini

pesso il computer viene scherzosamente definito un "idiota veloce" per la sua attitudine a eseguire ordini relativamente semplici in tempi estremamente brevi.
Tali ordini vengono eseguiti in modo perfettamente fedele, e se in condizioni normali ciò è ovviamente desiderabile, non lo è affatto quando gli ordini sono tali da causare malfunzionamenti, perdite di dati, divulgazione di informazioni riservate, degrado di prestazioni.
Purtroppo, come tutti gli utenti di PC ben sanno, questa circostanza non è affatto rara. Si potrebbe anzi azzardare che, soprattutto in ambito domestico o SOHO (Small Office – Home Office), i casi di sistemi "inviolati" rappresentano l'eccezione e non la regola.
La vulnerabilità dei sistemi SOHO è l'effetto combinato di una amministrazione di sistema generalmente più "trasandata" e meno specialistica di quella tipica dell'ambiente aziendale e di una esposizione ad attacchi di "agenti patogeni" accresciuta dal fatto che da tali postazioni si accede, solitamente, a Internet e tramite questa a contenuti e programmi provenienti dalla rete e spesso non adeguatamente controllati.
In questa puntata passeremo in rassegna i canali usati per portare l'attacco al nostro sistema. Si tratta dell'abuso consapevole di "innocenti" programmi difettosi (exploitation) oppure di programmi "nocivi" appositamente scritti. Come tutti i programmi, anche quelli nocivi, per poter agire, devono essere mandati in esecuzione. A tal fine si possono adottare varie tecniche: dissimularli all'interno di altri programmi, anche con la capacità di replicarsi dando luogo a un vero e proprio processo infettivo (virus), camuffarli da programmi innocenti per indurre l'ignaro utente ad eseguirli (trojan horse) o perfino nasconderli in file di dati (virus delle macro). Nelle sezioni che seguono vedremo in dettaglio le tecniche di attacco e le contromisure per contrastarle.

I programmi
Parlando della minaccia rappresentata da programmi scritti con l'esplicito intento di creare danno e disservizio (malware) è importante ricordare che tutti i programmi, malware compresi, possono essere scritti in una pluralità di linguaggi ed essere destinati a entrare in esecuzione in contesti diversi. Per saper contrastare la minaccia rappresentata dai malware è quindi necessario conoscere anzitutto gli ambienti di esecuzione nei quali i programmi possono risiedere ed essere eventualmente attivati.
Il primo tipo di programma, scritto in un generico linguaggio di programmazione e poi trasformato in linguaggio macchina per poter essere eseguito direttamente appoggiandosi al sistema operativo, è spesso detto "eseguibile" o "binario". In ambiente Windows, tale categoria di programmi è di solito riconoscibile dal suffisso EXE o COM.
Più difficile l'identificazione in ambiente Linux, in cui il suffisso non è significativo.

Lezione 5 IT Administrator Sicurezza informatica

Identificazione del tipo di file in ambiente Linux

A differenza dell'ambiente Windows, in cui è previsto che il tipo di un file sia identificato in base al suffisso, i sistemi Unix in generale (e in particolare Linux) non usano tale convenzione.
Di conseguenza, il tipo di file deve essere dedotto da proprietà diverse dal suo nome.
Esiste un apposito comando interattivo di shell, il comando file, che si preoccupa di esaminare un file e di stabilire di che tipo si tratti attraverso un procedimento che si articola su varie fasi.
Anzitutto si verifica se si tratta di uno dei cosiddetti "file speciali" di Unix che possono rappresentare varie entità diverse dai normali file di dati.
Vediamo un elenco dei diversi tipi possibili:

• dispositivi fisici, come unità a disco o a nastro, porte seriali, unità rimovibili e così via;

• socket TCP/IP, ossia le entità astratte che rappresentano le estremità di una connessione di rete punto-punto o i punti di origine/destinazione di una trasmissione broadcast;

• link simbolici, il concetto UNIX a cui si ispirano i “collegamenti a…” di Windows: si tratta di piccoli file che fungono solo da riferimenti a file veri e propri. In genere essi contengono il path completo del file bersaglio, con un qualche marcatore che li qualifica come link simbolici. Aprirli, chiuderli ed effettuare I/O su di essi equivale ad effettuare le stesse operazioni sul file collegato; l’operazione di cancellazione, invece, cancella il link simbolico, ma non il file collegato.

• hard link, ossia collegamenti realizzati nella struttura gerarchica del file system; la differenza rispetto ai link simbolici sta nel fatto che cancellando l’ultimo hard link rimasto ancorato a un file, il file viene cancellato. Anche le prestazioni in termini di tempo d’accesso sono più elevate che nel caso dei link simbolici, dato che non ci sono path da interpretare. L’equivalenza tra hard link e file riferito è perciò praticamente assoluta.

• named pipe: meccanismi utilizzati per la comunicazione a run time tra processi (inter-process communication: IPC) alternative all’uso di connessioni di rete interne alla macchina e molto più efficienti.
I vari tipi di file possono essere

riconosciuti immediatamente attraverso un'analisi delle strutture dati sul file system, eseguita innanzi tutto mediante la primitiva stat.
Se il file risulta non essere un "file speciale", allora si tenta di aprirlo e di esaminarne il contenuto. In un certo numero di casi è possibile stabilire, con certezza, che il file è un eseguibile, un file oggetto, una libreria dinamica, eccetera, semplicemente leggendo i suoi primi byte e confrontandoli con alcuni valori noti, in quanto tali tipi di file hanno una struttura standard che prevede un prologo (header) che deve tassativamente contenere alcuni valori identificativi in ben precise posizioni.
In particolare, per i file eseguibili e i file oggetto, un particolare numero intero (di solito a 32 bit) posizionato vicino all'inizio del file, a una certa distanza nota da esso, funge da marcatore di tipo. Trovare tale valore nella posizione prevista è considerato una signature di un determinato file type: quindi una prova sufficiente per concludere che il file esaminato è del tipo corrispondente alla signature trovata.

Occupazione della banda disponibile
L’attacco smurf descritto in precedenza è usato per saturare la banda disponibile per un certo indirizzo di rete. In generale, questo attacco può avvenire con qualsiasi tipo di pacchetto. Un firewall tra la rete e la connessione, spesso, non protegge da questo attacco: il firewall scarta i pacchetti, ma questi hanno già ottenuto il loro scopo di congestionamento. Ne scaturiscono due conseguenze:
- la difficoltà di distinguere i pacchetti che fanno parte di un attacco da quelli legittimi: per esempio, i pacchetti SYN diretti alla porta 80 (HTTP) di un web server possono essere sia pacchetti ostili, sia reali tentativi di connessione al sito e, a questo punto, la banda è già stata occupata;
- occorre coinvolgere il provider nella gestione dell’attacco.

DDoS, Distributed Denial of Service
Un attacco DoS richiederebbe all’attaccante una notevole quantità di risorse per saturare un grosso sito Internet, ben al di là delle possibilità di una singola rete e della banda della sua connessione a Internet. L’attacco viene, quindi, distribuito fra una gran quantità di sistemi che, sotto il controllo dell’attaccante, operano il loro attacco contemporaneamente per saturare le risorse del sistema bersaglio. A questo scopo, la tecnica più diffusa consiste nell’attaccare preventivamente un gran numero di sistemi, poco protetti (sistema operativo non aggiornato, carenze di firewall e antivirus) ma ben connessi (possibilmente, con banda larga), assumendone il controllo e installandovi degli agenti software che rendono questi sistemi degli zombie agli ordini dell’attaccante. L’insieme degli zombie è controllato in modo centralizzato dall’attaccante, il cui software può ordinare a tutti di attaccare contemporaneamente un singolo sistema, inondandolo di pacchetti SYN spoofed diretti alla porta 80 del server.
Gli attacchi DDoS, di solito, sono coordinati da un singolo sistema master e da un singolo cracker. Possono limitarsi all’invio di un pacchetto ping all’indirizzo di broadcast di una grande rete, con spoofing dell’indirizzo del mittente per indirizzare le risposte verso il bersaglio (il caso dell’attacco smurf). Ma gli attacchi DDoS sono diventati notevolmente più sofisticati rispetto a quelli smurf. Nuovi strumenti di attacco come Trinoo, Tribal Flood Network, Mstream e Stacheldraht permettono a un cracker di coordinare gli sforzi di molti sistemi contro una sola vittima. Questi strumenti utilizzano un’architettura a tre livelli. Un cracker dialoga con un processo master o server da lui in-

stallato su un sistema che ha compromesso (all’insaputa del proprietario). Il master dialoga con i processi slave o client che sono stati installati su un gran numero di altri sistemi compromessi (zombie). I sistemi slave attuano l’attacco contro il sistema bersaglio. I comandi al master e tra il master e gli slave possono essere cifrati, utilizzando pacchetti UDP o ICMP, secondo gli strumenti usati. L’attacco vero e proprio può consistere di un’inondazione di pacchetti UDP, di un SYN flood TCP, o di traffico ICMP. Alcuni strumenti modificano in modo casuale l’indirizzo spoofed del mittente dei pacchetti ostili, rendendoli estremamente difficili da riconoscere. Fintanto che sono disponibili molti sistemi poco protetti, come potenziali zombie, essi possono essere coordinati in un attacco contro un singolo bersaglio. Per quanto ampia sia la banda della connessione di un sito a Internet, gli attacchi DDoS possono sommergerne le capacità operative se un numero sufficiente di sistemi slave è coinvolto nell’attacco.
Questo tipo di attacco crea due difficoltà:
- la possibilità di rintracciare l’origine dell’attacco è ridotta ulteriormente, dato che i pacchetti provengono da più fonti, rendendo più arduo lo sforzo di risalire al mittente;
- per interrompere l’attacco è necessario bloccare un numero significativo di zombie, mentre l’attaccante può aggiungerne e toglierne dall’attacco in modo dinamico.
La protezione è particolarmente difficile senza accordi di collaborazione con i provider, tuttavia sono stati fatti passi avanti nel ridurre la vulnerabilità dei sistemi operativi (in particolare di Windows) agli attacchi provenienti da Internet. In ultima analisi, proteggere il proprio sistema perché non cada sotto il controllo altrui è una responsabilità individuale (anche civile) premiata con la sicurezza collettiva.

Ping of Death
I Denial of Service non si ottengono solo saturando le risorse del bersaglio, ma anche, più semplicemente, causando malfunzionamenti. Un esempio è stato il Ping of Death. Negli anni passati molte implementazioni dello stack TCP/IP non sono state in grado di gestire correttamente pacchetti ICMP Echo Request di grandi dimensioni. Il risultato era l’invio di un pacchetto ping di dimensioni illegali (oltre 65.507 ottetti nel campo dati del pacchetto) che, dopo essere stato frammentato per l’invio, a destinazione veniva riassemblato in modo scorretto, con la possibilità di causare un overflow in memoria oltre i 65.535 byte massimi previsti per il pacchetto. I dati andavano, quindi, a ricoprire altre informazioni (per esempio, l’indirizzo di ritorno di una funzione) con conseguenti crash di sistema, reboot, kernel dump (core dumpblocco del sistema Linus), e altri effetti indesiderati.
Più in generale, i buffer overflow si verificano quando un’applicazione omette di controllare che i dati copiati nello spazio di memoria riservato a una variabile non superino lo spazio allocato. Una lunga serie di vulnerabilità di questo genere è stata scoperta, nel corso degli anni, nei sistemi operativi e nel software applicativo. Spesso, tali vulnerabilità sono state pubblicate e sono state sfruttate dai cracker prima di essere corrette dai produttori.

Contromisure relative ai Denial of Service
Le strategie per affrontare un attacco DoS sono diversificate, e contribuiscono a mitigare il rischio.

Un sommario di misure preventive è il seguente:
- disabilitare i servizi di rete superflui o non usati
- tenere backup regolari
- tenere e monitorare log giornalieri
- introdurre adeguate policy sulle password
- installare un Intrusion Detection System
- implementare filtri di routing per bloccare pacchetti ICMP frammentati

IT Administrator Sicurezza informatica Lezione 7A

- vigilare sulla sicurezza fisica delle risorse di rete
- configurare filtri per i pacchetti IP spoofed
- installare le patch e gli aggiornamenti per gli attacchi noti, come il TCP SYN
- abilitare il sistema delle quote d’uso autorizzate (per esempio sui dischi), se supportato dal sistema operativo
- partizionare il file system per separare dati da applicazioni
- installare strumenti come Tripwire che segnalano cambiamenti nei file critici (per esempio, i file di configurazione)
- utilizzare firewall con capacità di prevenzione contro gli attacchi più diffusi
- investire in macchine “di riserva” da mettere rapidamente in servizio se una macchina simile è stata messa fuori uso
- investire in configurazioni di rete ridondanti e fault-tolerant
(resistenza ai guasti).

E' infine definito come interessato la persona fisica, la persona giuridica, l'ente o l'associazione cui si riferiscono i dati personali.

La normativa a tutela della privacy si basa su alcuni principi fondamentali
Principio del buon trattamento
In base a questo principio (vedi art. 11), i dati persona- li oggetto del trattamento devono essere: trattati in modo lecito e secondo correttezza; raccolti e registrati per scopi determinati, espliciti e legittimi, e utilizzati in altre opera- zioni del trattamento in termini compatibili con tali scopi; esatti e, se necessario, aggiornati; pertinenti, completi e non eccedenti rispetto alle finalità per le quali sono raccolti o successivamente trattati; conservati in una forma che consenta l'identificazione dell'interessato per un periodo di tempo non superiore a quello necessario agli scopi per i quali essi sono stati raccolti o successivamente trattati.

Controllo amministrativo sul corretto trattamento di dati Previsto dalla legge comunitaria e ripreso dalla norma- tiva italiana, questo principio ha determinato la nascita di un'authority amministrativa (in Italia il Garante per la pro- tezione dei dati personali) con compiti di vigilanza sul cor- retto trattamento dei dati personali da parte di privati e
aziende.
Oltre ad avere il potere di prendere provvedimenti anche di tipo sanzionatorio in caso di violazioni, l'authority ha il compito di stendere regolamenti, codici disciplinari e policy di validità generale, di autorizzare particolari trattamenti di dati sensibili e di fissare i criteri e i limiti, anche attraverso

IT Administrator - Sicurezza informatica Lezione 8

campagne di educazione e sensibilizzazione, entro i quali i trattamenti dei dati possono considerarsi leciti.

Obbligo informativo
In base a tale principio (vedi art. 13), chiunque esegua trattamenti di dati personali deve informare oralmente o per iscritto gli interessati circa: le finalità e le modalità del trattamento cui sono destinati i dati; la natura obbligatoria o facoltativa del conferimento dei dati; le conseguenze di un eventuale rifiuto di rispondere; i soggetti o le categorie di soggetti ai quali i dati personali possono essere comu- nicati o che possono venirne a conoscenza in qualità di re- sponsabili o incaricati, e l'ambito di diffusione dei dati me- desimi; i diritti di cui all'articolo 7; gli estremi identificativi del titolare e, se designati, del rappresentante nel territorio dello Stato ai sensi dell'articolo 5 e del responsabile. Le ec- cezioni all'obbligo dell'informativa sono assai limitate e pre- viste dall'art. 13 (un esempio è quando i dati sono trattati in base a un obbligo previsto dalla legge, da un regolamen- to o dalla normativa comunitaria).

Principio del consenso
Salvo alcuni casi previsti, come un obbligo di legge o contrattuale, il titolare della raccolta e trattamento dei da- ti personali deve ottenere il consenso esplicito dell'inte- ressato. Il consenso deve essere scritto qualora il tratta- mento riguardi dati sensibili.

Diritto alla riservatezza
Ai sensi dell'art. 7, l'interessato ha diritto di ottenere la conferma dell'esistenza o meno di dati personali che lo ri- guardano, anche se non ancora registrati, e la loro comu- nicazione in forma intelligibile.
In particolare, l'interessato ha il diritto di ottenere l'in- dicazione: dell'origine dei dati personali; delle finalità e mo- dalità del trattamento; della logica applicata in caso di trat- tamento effettuato con l'ausilio di strumenti elettronici; de- gli estremi identificativi del titolare, dei responsabili e del rappresentante designato ai sensi dell'articolo 5, comma 2; dei soggetti o delle categorie di soggetti ai quali i dati per- sonali possono essere comunicati o che possono venirne a conoscenza in qualità di rappresentante designato nel ter- ritorio dello Stato, di responsabili o incaricati.
L'interessato ha inoltre diritto di ottenere: l'aggiorna- mento, la rettificazione ovvero, quando vi ha interesse, l'in- tegrazione dei dati; la cancellazione, la trasformazione in forma anonima o il blocco dei dati trattati in violazione di legge, compresi quelli di cui non è necessaria la conserva- zione in relazione agli scopi per i quali i dati sono stati rac- colti o successivamente trattati; l'attestazione che le ope- razioni di cui alle lettere a) e b) sono state portate a cono- scenza, anche per quanto riguarda il loro contenuto, di co- loro ai quali i dati sono stati comunicati o diffusi, eccet- tuato il caso in cui tale adempimento si rivela impossibile o comporta un impiego di mezzi manifestamente spropor- zionato rispetto al diritto tutelato.
Infine, l'interessato ha diritto di opporsi, in tutto o in par- te: per motivi legittimi al trattamento dei dati personali che lo riguardano, ancorché pertinenti allo scopo della raccol- ta; al trattamento di dati personali che lo riguardano a fini di invio di materiale pubblicitario o di vendita diretta o per il compimento di ricerche di mercato o di comunicazione commerciale.

Circolazione limitata dei dati
Introdotto nella legislazione comunitaria e ripreso dalla normativa italiana, questo principio ispira gli articoli sulla circolazione delle informazioni. I dati personali, salvo al- cune precise eccezioni, non possono essere comunicati a terzi né tantomeno diffusi ad ampio raggio senza il con- senso dell'interessato. I dati sensibili e giudiziari in nessun caso possono essere diffusi.

Mentre la circolazione dei dati all'interno dell'Unione eu- ropea non deve essere ostacolata dalle normative in mate- ria di dati personali (vedi art. 42), la circolazione dei dati al di fuori dell'Unione è consentita solo nei casi previsti dagli artt. 43 e 44 del codice della privacy. Negli artt. 25 e 26 del- la direttiva 95/46 CE, la Commissione europea ha vietato il trasferimento dei dati personali verso paesi che non assi- curano un livello adeguato di tutela dei dati personali.

Sicurezza
I dati personali devono essere protetti da misure di si- curezza allo scopo di garantirne la riservatezza, l'integrità e la disponibilità. Si veda la sezione 5.8.2.2 circa le misure minime di sicurezza imposte dal codice della privacy.
A tutela dei cittadini e delle aziende interessati al trat- tamento dei dati che li riguardano, il codice della privacy prevede sanzioni sia in sede amministrativa (in particola- re in caso di omessa o inidonea informativa all'interessato, omessa o incompleta notificazione, omessa informazione o esibizione al Garante), sia in sede penale (in particolare in caso di trattamento illecito di dati, falsità nelle dichiara- zioni e notificazioni al Garante, mancata applicazione del- le misure di sicurezza, inosservanza di provvedimenti del garante).
In caso di violazione, è ipotizzabile un risarcimento del danno in base all'art. 2050 del Codice civile, che prevede la responsabilità per le attività pericolose e al quale si appli- ca il ribaltamento dell'onere della prova: è la società re- sponsabile del trattamento dei dati che deve provare di aver posto in essere tutte le misure e precauzioni idonee at- te a evitare il danno.

Informatica forense
Man mano che le informazioni hanno acquisito cre- scente importanza per le aziende, fino a superare in alcuni settori il valore dei beni materiali, gli attacchi alla loro si- curezza (integrità, riservatezza, disponibilità) si sono mol- tiplicati. Ne è derivata una duplice esigenza: proteggere le informazioni da danni e abusi causati sia dall'interno sia dall'esterno dell'organizzazione e dotarsi degli strumenti e procedure che consentano di identificare i responsabili di tali atti e di documentarne le azioni con efficacia probato- ria.
La legge 397/2000 (Disposizioni in materia di indagini di- fensive) ha introdotto nel Codice di procedura penale le nuove disposizioni in materia di indagini difensive, con l'o- biettivo di parificare l'attività difensiva all'attività investi- gativa dell'autorità giudiziaria (in particolare del Pubblico Ministero), dando ad esse uguale valore probatorio in sede processuale. Sono state inoltre definite le modalità con cui i difensori possono procedere alla raccolta delle prove.

L'art. 391-nonies (Attività investigativa preventiva), in- serito nel Codice di procedura penale dalla legge 397/2000, stabilisce che l'attività investigativa prevista dall'articolo 327-bis, con esclusione degli atti che richiedono l'autoriz- zazione o l'intervento dell'autorità giudiziaria, può essere svolta anche dal difensore che ha ricevuto apposito man- dato per l'eventualità che s'instauri un procedimento pe- nale.
L'art. 327-bis. (Attività investigativa del difensore), an- ch'esso introdotto dalla 397/2000, stabilisce che:
1. Fin dal momento dell'incarico professionale, risultan- te da atto scritto, il difensore ha facoltà di svolgere inve- stigazioni per ricercare ed individuare elementi di prova a favore del proprio assistito, nelle forme e per le finalità sta- bilite nel titolo VI-bis del Codice di procedura penale.
2. La facoltà indicata al punto 1 può essere attribuita per l'esercizio del diritto di difesa, in ogni stato e grado del pro-

Lezione 8 IT Administrator - Sicurezza informatica

cedimento, nell'esecuzione penale e per promuovere il giu- dizio di revisione.
3. Le attività previste dal punto 1 possono essere svolte, su incarico del difensore, dal sostituto, da investigatori pri- vati autorizzati e, quando sono necessarie specifiche com- petenze, da consulenti tecnici.
Quanto detto significa che anche un soggetto che si ri- tiene offeso da un reato può affidare un mandato a un di- fensore per compiere indagini al fine di accertare la sussi- stenza delle prove necessarie e per decidere se presentare una successiva denuncia o querela all'autorità giudiziaria. D'altra parte, l'autorità giudiziaria e i difensori sono spesso impreparati ad affrontare le problematiche connesse con tecnologie in continua e rapida evoluzione, quali sono i mezzi di ricerca della prova informatica.
Sebbene siano in corso iniziative, come il progetto eu- ropeo AEEC (Admissibility of Electronic Evidence in Court) del 2005 sull'ammissibilità della prova elettronica, manca ancora un protocollo che definisca regole certe in base al quale i pubblici ministeri e i difensori possano procedere all'individuazione, analisi e presentazione dei dati in forma digitale, secondo modalità idonee a garantire che le infor- mazioni raccolte siano accettate come prove in sede pro- cessuale.
Dato che nei moderni sistemi è difficile cancellare dati elettronici senza lasciare qualche traccia, dall'analisi di ta- li tracce (per esempio il file system, i file di log dei sistemi operativi e delle applicazioni e il registro di sistema di Win- dows), oltre che dei file, è spesso possibile ottenere infor- mazioni importanti per provare la colpevolezza del re- sponsabile di un reato informatico. Ciò è possibile a con- dizione che i dati siano raccolti e conservati in modalità adeguate per il loro utilizzo processuale e che sia rispetta- ta una serie di requisiti riguardanti l'ambiente, il consulen- te tecnico (competenza, certificazioni, testimoni, presenza, capacità di sostenere il contraddittorio), le procedure, gli strumenti, la metodologia, la sicurezza, la ripetibilità, la presentazione e altro.
L'informatica forense (computer forensics) è la discipli- na che si occupa della preservazione, dell'identificazione, dell'analisi e della documentazione dei computer o dei si- stemi informativi al fine di evidenziare l'esistenza di prove nell'attività investigativa.
Dal punto di vista procedurale, l'obiettivo principale del- l'informatica forense è la creazione di un protocollo di re- gole da seguire per le ricerca della prova informatica e re- lativa acquisizione e conservazione al fine di garantire che

i risultati delle indagini abbiano valore anche in sede pro- cessuale.
Di fronte all'incompetenza tecnica dei giudici e alle obiezioni e all'aggressività oratoria degli accusatori e dei di- fensori, intenzionati a sminuire, invalidare o screditare le prove altrui, i relativi metodi e le condizioni di raccolta e conservazione, nonché le qualifiche del consulente tecnico di parte opposta, è facile comprendere che non bastano dei dati trovati su un hard disk per ottenere dal giudice la loro ammissione come prova a carico o a discarico.
Le attività di informatica forense possono riguardare di- verse aree, tra cui le seguenti:
1. monitoraggio e analisi dei supporti di memorizzazio- ne e delle periferiche;
2. visualizzazione di banche dati;
3. esame di immagini e sequenze audio e video;
4. monitoraggio e controllo delle attività svolte su reti in- terne ed esterne, inclusa Internet.
Tra i requisiti fondamentali di una prova informatica, af- finché possa essere accettata in sede processuale, ci sono autenticità, pertinenza, accuratezza, completezza, inte- grità e non ripudiabilità. Inoltre, deve essere raccolta, do- cumentata e presentata in modo convincente per essere ri- tenuta ammissibile e giuridicamente valida da un giudice che, non tecnicamente esperto, ha formato criteri più o me- no soggettivi di accettabilità, a volte basati sull'uso di pro- tocolli e strumenti usati di frequente in un certo ambito.
Alla base della procedura di analisi forense c'è una cor- retta procedura di raccolta e conservazione dei dati e l'u- tilizzo di strumenti di analisi che generino risultati ripro- ducibili senza che vi sia alcuna alterazione dei supporti ori- ginali.
Nei casi di acquisizione delle prove su sistemi accesi (li- ve response), quando le prove includono dati volatili che sarebbero perduti spegnendo il sistema, per prima cosa si provvede al loro salvataggio. Fanno parte di tale categoria i dati in memoria riguardanti gli utenti correnti, i processi e le applicazioni aperte e i relativi dati e le sessioni di co- municazione, inclusi i socket aperti. Si tenga anche conto che possono essere attive applicazioni o servizi che ripuli- scono il sistema alla fine di una sessione del sistema ope- rativo. Se necessario, può essere eseguito un esame in profondità sul sistema acceso, altrimenti si può eseguire un esame iniziale dei dati volatili e quindi la duplicazione dei media in un diverso ambiente di sistema, che non alteri i media stessi.
Come regola generale, le analisi non vengono effettuate

IT Administrator - Sicurezza informatica Lezione 8

sui supporti originali sequestrati, ma su immagini degli hard disk perfettamente identiche catturate byte per byte (dette anche bitstream image) senza alterazione dell'origi- nale. Per ogni immagine così registrata, possibilmente in presenza di testimoni, viene subito calcolata un'impronta informatica (hash) in modo che successivamente sia ga- rantita l'integrità delle informazioni raccolte, che in tal mo- do non sono ripudiabili dalle parti interessate. Se occorre, può anche essere applicata una firma digitale per garanti- re che nessuno alteri l'hash. Il concetto di raccogliere pro- ve non ripudiabili e di custodirle integre e al sicuro fino al processo si chiama Chain of Custody (catena della custo- dia). La custodia in maniera corretta (a prova di manomis- sione) delle prove e dei dati acquisiti è vitale al fine di evi- tare che il lavoro di indagine sia invalidato per un cavillo le- gale. Lavorando con prove pressoché immateriali, è facile distruggere una prova determinante con un semplice pas- so falso. Il lavoro inoltre può essere ostacolato dalle ope- razioni eseguite da utenti o amministratori di sistema pri- ma del sopraluogo, che possono pregiudicare l'indagine.
Nella prassi giudiziaria, finché non verranno standar- dizzate e uniformate le regole per l'acquisizione delle pro- ve informatiche, la pubblica accusa ritiene spesso attendi- bili anche prove mancanti dei requisiti citati, come le stam- pe di documenti (pagine Internet, messaggi e-mail, sessio- ni di chat e così via) e supporti di memorizzazione privi di sigillo o garanzia elettronica di intergità.
In base al principio del libero convincimento del giudice, anche gli organi giudicanti ritengono spesso attendibili ta- li prove. D'altra parte, una recente sentenza della Cassa- zione ha negato il valore di prova alla stampa di una pagi- na web perché priva di una garanzia di rispondenza all'ori- ginale e di un riferimento temporale.
Per tutte queste ragioni, è necessario che anche le im- prese si dotino degli strumenti tecnologici e organizzativi necessari per monitorare (nel rispetto della privacy e del- lo Statuto dei lavoratori) le operazioni informatiche e rico- noscere gli indicatori di un possibile reato mentre viene commesso. In tal modo, si possono raccogliere prove vali- de da utilizzare in sede processuale ad uso sia del Pubbli- co Ministero sia dei difensori. Tali attività richiedono l'in- tervento di personale interno, o di consulenti esterni, con adeguate competenze tecnologiche, organizzative e giuri- diche (inclusa la familiarità con le pratiche accettate dal tri- bunale locale), in costante aggiornamento professionale e in contatto, anche attraverso i forum, con i colleghi della comunità informatica forense.
I motori di ricerca e le librerie online sono una ricca fon- te di riferimenti sulle procedure, gli strumenti e le norma- tive per l'informatica forense (computer forensics).
Esistono numerosi strumenti per la duplicazione e il ri-

pristino dei dati, a partire dalle utility dd e dcfldd dei si- stemi operativi di derivazione Unix. Oltre ai comandi di si- stema, esistono utility Open Source come ODD (Open Da- ta Duplicator), che fa parte dell'architettura Open Digital Evidence Search and Seizure Architecture (ODESSA). Esiste poi una serie di applicazioni commerciali, talvolta molto co- stose, come EnCase Forensics di Guidance Software, uno degli strumenti più utilizzati da organizzazioni governative e forze dell'ordine a livello internazionale (www.guidance- software.com).
Se da un lato non esistono ostacoli tecnici a utilizzare strumenti Open Source o a identificare procedure e stru- menti al di fuori degli schemi abituali per la raccolta delle prove, in realtà c'è il rischio di non vedere ammesse le pro- ve raccolte perché la procedura è incomprensibile al giu- dice o è demolita dalla controparte durante il processo.
Ciò premesso, un ambiente di sistema progettato appo- sitamente per la raccolta di prove informatiche è Helix, una versione di Linux basata sulla distribuzione Knoppix Live CD (avviata da CD senza installare nulla su hard disk) che include molte applicazioni dedicate alla diagnosi dei pro- blemi e alla raccolta di informazioni per uso forense (www.e-fense.com/helix/).
Tra gli strumenti in grado di recuperare i contenuti di un hard disk, anche nascosti o rovinati, citiamo R-Studio di R- Tools Technology (www.r-tt.com), che produce diverse ap- plicazioni per il recupero e il ripristino dei dati.
Tra la abbondante letteratura sull'informatica forense, citiamo i seguenti testi e URL di riferimento:
"Incident Response and Computer Forensics", Seconda Edi- zione, K. Mandia e C. Prosise, McGraw-Hill/Osborne 2003 "File System Forensic Analysis", B. Carrier, Addison-Wesley Professional, 2005
"Real Digital Forensics: Computer Security and Incident Re- sponse", Jones, Bejtlich e Rose, Addison-Wesley Professio- nal, 2005
"Digital Evidence and Computer Crime", Seconda Edizione,
E. Casey, Academic Press, 2004
The Sleuth Kit (TSK), www.sleuthkit.org/sleuthkit/ index.php
Forensic Tools, www.networkintrusion.co.uk/fortools.htm Anti-Forensic Tools, www.networkintrusion.co.uk/foranti. htm
Open Source Digital Forensics, www.opensourceforensics.org
/index.html
Computer Forensics, Cybercrime and Steganography Re- sources, www.forensics.nl
Documenti e libri di informatica forense, www.digital- evidence.org/papers/index.html
Forensic Focus, www.forensicfocus.com/computer- forensics-forums •

ALLEGATO B
DISCIPLINARE TECNICO IN MATERIA DI MISURE MINIME DI SICUREZZA

(Artt. da 33 a 36 del codice) Trattamenti con strumenti elettronici
Modalità tecniche da adottare a cura del titolare, del responsabile ove designato e dell'incaricato, in caso di trattamento con strumenti elettronici:
Sistema di autenticazione informatica
1. Il trattamento di dati personali con strumenti elettronici è consentito agli incaricati dotati di credenziali di autenticazione che consentano il superamento di una procedura di autenticazione relativa a uno specifico trattamento o a un insieme di trattamenti.
2. Le credenziali di autenticazione consistono in un codice per l'identificazione dell'incaricato associato a una parola

chiave riser vata conosciuta solamente dal medesimo oppure in un dispositivo di autenticazione in possesso e uso esclusivo dell'incaricato, eventualmente associato a un codice identificativo o a una parola chiave, oppure in una caratteristica biometrica dell'incaricato, eventualmente associata a un codice identificativo o a una parola chiave.
3. Ad ogni incaricato sono assegnate o associate individualmente una o più credenziali per l'autenticazione.
4. Con le istruzioni impartite agli incaricati è prescritto di adottare le necessarie cautele per assicurare la segretezza della componente riser vata della credenziale e la diligente custodia dei dispositivi in possesso ed uso esclusivo

Lezione 8 IT Administrator - Sicurezza informatica

dell'incaricato.
5. La parola chiave, quando è prevista dal sistema di autenticazione, è composta da almeno otto caratteri oppure, nel caso in cui lo strumento elettronico non lo permetta, da un numero di caratteri pari al massimo consentito; essa non contiene riferimenti agevolmente riconducibili all'incaricato ed è modificata da quest'ultimo al primo utilizzo e, successivamente, almeno ogni sei mesi. In caso di trattamento di dati sensibili e di dati giudiziari la parola chiave è modificata almeno ogni tre mesi.
6. Il codice per l'identificazione, laddove utilizzato, non può essere assegnato ad altri incaricati, neppure in tempi diversi.
7. Le credenziali di autenticazione non utilizzate da almeno sei mesi sono disattivate, salvo quelle preventivamente autorizzate per soli scopi di gestione tecnica.
8. Le credenziali sono disattivate anche in caso di perdita della qualità che consente all'incaricato l'accesso ai dati personali.
9. Sono impartite istruzioni agli incaricati per non lasciare incustodito e accessibile lo strumento elettronico durante una sessione di trattamento.
10. Quando l'accesso ai dati e agli strumenti elettronici è consentito esclusivamente mediante uso della componente riser vata della credenziale per l'autenticazione, sono impartite idonee e preventive disposizioni scritte volte a individuare chiaramente le modalità con le quali il titolare può assicurare la disponibilità di dati o strumenti elettronici in caso di prolungata assenza o impedimento dell'incaricato che renda indispensabile e indifferibile inter venire per esclusive necessità di operatività e di sicurezza del sistema. In tal caso la custodia delle copie delle credenziali è organizzata garantendo la relativa segretezza e individuando preventivamente per iscritto i soggetti incaricati della loro custodia, i quali devono informare tempestivamente l'incaricato dell'inter vento effettuato.
11. Le disposizioni sul sistema di autenticazione di cui ai precedenti punti e quelle sul sistema di autorizzazione non si applicano ai trattamenti dei dati personali destinati alla diffusione.
Sistema di autorizzazione
12. Quando per gli incaricati sono individuati profili di autorizzazione di ambito diverso è utilizzato un sistema di autorizzazione.
13. I profili di autorizzazione, per ciascun incaricato o per classi omogenee di incaricati, sono individuati e configurati anteriormente all'inizio del trattamento, in modo da limitare l'accesso ai soli dati necessari per effettuare le operazioni di trattamento.
14. Periodicamente, e comunque almeno annualmente, è verificata la sussistenza delle condizioni per la
conser vazione dei profili di autorizzazione. Altre misure di sicurezza
15. Nell'ambito dell'aggiornamento periodico con cadenza almeno annuale dell'individuazione dell'ambito del trattamento consentito ai singoli incaricati e addetti alla gestione o alla manutenzione degli strumenti elettronici, la lista degli incaricati può essere redatta anche per classi omogenee di incarico e dei relativi profili di autorizzazione.
16. I dati personali sono protetti contro il rischio di intrusione e dell'azione di programmi di cui all'art. 615- quinquies del codice penale, mediante l'attivazione di idonei strumenti elettronici da aggiornare con cadenza almeno semestrale.
17. Gli aggiornamenti periodici dei programmi per elaboratore volti a prevenire la vulnerabilità di strumenti elettronici e a correggerne difetti sono effettuati almeno annualmente. In caso di trattamento di dati sensibili o giudiziari l'aggiornamento è almeno semestrale.
18. Sono impartite istruzioni organizzative e tecniche che

prevedono il salvataggio dei dati con frequenza almeno settimanale.
Documento programmatico sulla sicurezza
19. Entro il 31 marzo di ogni anno, il titolare di un trattamento di dati sensibili o di dati giudiziari redige anche attraverso il responsabile, se designato, un documento programmatico sulla sicurezza contenente idonee informazioni riguardo:
19.1. l'elenco dei trattamenti di dati personali;
19.2. la distribuzione dei compiti e delle responsabilità nell'ambito delle strutture preposte al trattamento dei dati;
19.3. l'analisi dei rischi che incombono sui dati;
19.4. le misure da adottare per garantire l'integrità e la disponibilità dei dati, nonché la protezione delle aree e dei locali, rilevanti ai fini della loro custodia e accessibilità;
19.5. la descrizione dei criteri e delle modalità per il ripristino della disponibilità dei dati in seguito a distruzione o danneggiamento di cui al successivo punto 23;
19.6. la previsione di inter venti formativi degli incaricati del trattamento, per renderli edotti dei rischi che incombono sui dati, delle misure disponibili per prevenire eventi dannosi, dei profili della disciplina sulla protezione dei dati personali più rilevanti in rapporto alle relative attività, delle responsabilità che ne derivano e delle modalità per aggiornarsi sulle misure minime adottate dal titolare. La formazione è programmata già al momento dell'ingresso in ser vizio, nonché in occasione di cambiamenti di mansioni, o di introduzione di nuovi significativi strumenti, rilevanti rispetto al trattamento di dati personali;
19.7. la descrizione dei criteri da adottare per garantire l'adozione delle misure minime di sicurezza in caso di trattamenti di dati personali affidati, in conformità al codice, all'esterno della struttura del titolare;
19.8. per i dati personali idonei a rivelare lo stato di salute e la vita sessuale di cui al punto 24, l'individuazione dei criteri da adottare per la cifratura o per la separazione di tali dati dagli altri dati personali dell'interessato.
Ulteriori misure in caso di trattamento di dati sensibili o giudiziari
20. I dati sensibili o giudiziari sono protetti contro l'accesso abusivo, di cui all' art. 615-ter del codice penale, mediante l'utilizzo di idonei strumenti elettronici.
21. Sono impartite istruzioni organizzative e tecniche per la custodia e l'uso dei supporti rimovibili su cui sono memorizzati i dati al fine di evitare accessi non autorizzati e trattamenti non consentiti.
22. I supporti rimovibili contenenti dati sensibili o giudiziari se non utilizzati sono distrutti o resi inutilizzabili, ovvero possono essere riutilizzati da altri incaricati, non autorizzati al trattamento degli stessi dati, se le informazioni precedentemente in essi contenute non sono intelligibili e tecnicamente in alcun modo ricostruibili.
23. Sono adottate idonee misure per garantire il ripristino dell'accesso ai dati in caso di danneggiamento degli stessi o degli strumenti elettronici, in tempi certi compatibili con i diritti degli interessati e non superiori a sette giorni.
24. Gli organismi sanitari e gli esercenti le professioni sanitarie effettuano il trattamento dei dati idonei a rivelare lo stato di salute e la vita sessuale contenuti in elenchi, registri o banche di dati con le modalità di cui all'articolo 22, comma 6, del codice, anche al fine di consentire il trattamento disgiunto dei medesimi dati dagli altri dati personali che permettono di identificare direttamente gli interessati. I dati relativi all'identità genetica sono trattati esclusivamente all'interno di locali protetti accessibili ai soli incaricati dei trattamenti ed ai soggetti specificatamente autorizzati ad acceder vi; il trasporto dei dati all'esterno dei locali riser vati al loro trattamento deve avvenire in contenitori muniti di serratura o dispositivi equipollenti; il trasferimento dei dati in formato elettronico è cifrato.
Misure di tutela e garanzia

IT Administrator - Sicurezza informatica Lezione 8

25. Il titolare che adotta misure minime di sicurezza avvalendosi di soggetti esterni alla propria struttura, per provvedere alla esecuzione riceve dall'installatore una descrizione scritta dell'inter vento effettuato che ne attesta la conformità alle disposizioni del presente disciplinare tecnico.
26. Il titolare riferisce, nella relazione accompagnatoria del bilancio d'esercizio, se dovuta, dell'avvenuta redazione o aggiornamento del documento programmatico sulla sicurezza.
Trattamenti senza l'ausilio di strumenti elettronici Modalità tecniche da adottare a cura del titolare, del responsabile, ove designato, e dell'incaricato, in caso di trattamento con strumenti diversi da quelli elettronici:
27. Agli incaricati sono impartite istruzioni scritte finalizzate al controllo ed alla custodia, per l'intero ciclo necessario allo svolgimento delle operazioni di trattamento, degli atti e dei documenti contenenti dati personali. Nell'ambito dell'aggiornamento periodico con

cadenza almeno annuale dell'individuazione dell'ambito del trattamento consentito ai singoli incaricati, la lista degli incaricati può essere redatta anche per classi omogenee di incarico e dei relativi profili di autorizzazione.
28. Quando gli atti e i documenti contenenti dati personali sensibili o giudiziari sono affidati agli incaricati del trattamento per lo svolgimento dei relativi compiti, i medesimi atti e documenti sono controllati e custoditi dagli incaricati fino alla restituzione in maniera che ad essi non accedano persone prive di autorizzazione, e sono restituiti al termine delle operazioni affidate.
29. L'accesso agli archivi contenenti dati sensibili o giudiziari è controllato. Le persone ammesse, a qualunque titolo, dopo l'orario di chiusura, sono identificate e registrate.
Quando gli archivi non sono dotati di strumenti elettronici per il controllo degli accessi o di incaricati della vigilanza, le persone che vi accedono sono preventivamente autorizzate.

Lezione 8 IT Administrator - Sicurezza informatica

GLOSSARIO
3DES (Triple DES)
tripla applicazione del DES. L’algoritmo alla base di 3DES è lo stesso di DES, l’algoritmo più studiato e collaudato di tutti i tempi. 3DES è molto robusto e affidabile, ma è stato progettato circa 30 anni fa ed è stato concepito per l’implementazione in hardware.
Accountability
Vedi rendicontabilità.
Accuratezza
tutte le funzioni intese a garantire l’accuratezza delle informazioni.
AES
pubblicato dal NIST nel 2001, è l’algoritmo richiesto per proteggere le informazioni riser vate, ma non classificate, del governo statunitense. Nel 2003 il governo USA ha autorizzato l’uso di AES per la cifratura di documenti classificati fino al livello di secret con chiave di 128 bit e di top secret con chiave di 192 o 256 bit. E' previsto che risulti sicuro per decenni a venire ed è utilizzabile senza il pagamento di royalty.
Affidabilità del servizio
una vasta categoria di contromisure, perché sono diverse le aree che potrebbero compromettere l’affidabilità dei ser vizi informatici.
Agente
l’entità che mette in atto la minaccia viene chiamata agente. Esempi di agenti di minaccia sono un intruso cheentra in rete attraverso una porta del firewall, un processo che accede ai dati violando le regole di sicurezza, un tornado che spazza via il centro di calcolo o un utente che inavvertitamente permette ad altri di vedere le password.
AH (Authentication Header)
uno dei protocolli della famiglia IPSec. Fornisce la prova di origine dei pacchetti ricevuti, l'integrità dei dati e la protezione da replay.
Algoritmo (o cifrario)
un insieme di regole logiche e matematiche usate nella cifratura e nella decifratura.
Analisi dei protocolli
uno dei tre metodi usati dagli IDS per riconoscere segni d'intrusione. Meno specifico del pattern matching, esamina il pattern (la struttura) del traffico, anziché il campo dati dei pacchetti. Sono verificati gli header e la loro coerenza con la struttura dei pacchetti.
Analisi del rischio
si classificano le informazioni e le risorse soggette a minacce e vulnerabilità e si identifica il livello di rischio associato a ogni minaccia.
Autenticità
garantisce che eventi, documenti e messaggi vengano attribuiti con certezza al legittimo autore e a nessun altro.
Bene
un bene è qualsiasi cosa, materiale o immateriale, che abbia un valore e debba quindi essere protetta.
Blowfish
Blowfish è un cifrario simmetrico a blocchi di 64 bit con chiavi di lunghezza fino a 448 bit. Durante la cifratura i dati sono sottoposti a 16 fasi di funzioni crittografiche. Blowfish è un algoritmo molto robusto ed è stato scritto da Bruce Schneier, uno degli autori più citati nel campo della crittografia.
BS 7799
Le linee guida BS 7799, oggi ISO/IEC 17799 e BS 7799-2, hanno una storia che risale agli inizi degli anni ’90, quando il Dipartment of Trade and Industry britannico istituì un gruppo di lavoro con l’intento di fornire alle aziende linee guida per la gestione della sicurezza delle informazioni. Nel 1993 questo gruppo pubblicò il Code of practice for information security management, un insieme di buone

regole di comportamento per la sicurezza delle informazioni.
Business Continuity
(talvolta chiamata business continuance) descrive i processi e le procedure che un’organizzazione mette in atto per assicurare che le funzioni essenziali rimangano operative durante e dopo un disastro.
Busta elettronica
una busta elettronica (digital envelope) consiste di un messaggio che usa la cifratura simmetrica a chiave segreta e una chiave segreta cifrata in modo asimmetrico. Qualunque messaggio formattato con CMS può essere incapsulato dentro un altro messaggio CMS, applicando ricorsivamente la busta elettronica. Ciò permette agli utenti di firmare una busta digitale, di cifrare una firma digitale o di eseguire varie altre funzioni.
CBC (Cipher Block Chaining)
uno dei principali cifrari a blocchi. Utilizza il blocco di testo cifrato precedente e lo combina in XOR (OR esclusivo, un’operazione tra due bit che produce come risultato 1 se i bit sono diversi o 0 se sono uguali) con il blocco successivo di testo in chiaro prima della cifratura. Il primo blocco è combinato in XOR con un Vettore di Inizializzazione (IV, Initialization Vector), scelto con forti proprietà di pseudocasualità in modo che testi diversi producano lo stesso testo cifrato.
La decifratura funziona nel modo opposto: ogni blocco è decifrato e combinato in XOR con il blocco precedente. Il primo blocco è decifrato e combinato in XOR con il vettore d’inizializzazione.
CEN (Comitato Europeo di Normalizzazione, www.cenorm.org)
un organismo europeo composto dagli enti di standardizzazione dei paesi membri dell’Unione Europea e dell’EFTA (European Fair Trade Association - tra cui l’UNI per l’Italia).
CERT (Computer Emergency Response Team)
(squadra di inter vento per le emergenze informatiche) ha la missione di operare con la comunità di Internet per facilitare la risposta agli eventi riguardanti la sicurezza degli host (i computer collegati a Internet), prendere iniziative per sensibilizzare la comunità sugli aspetti della sicurezza e condurre ricerche rivolte a incrementare la sicurezza dei sistemi esistenti.
CERT-CC
il primo CERT (www.cert.org) è diventato il CERT Coordination Center (CERT-CC) ed è situato presso il Software Engineering Institute, finanziato dal governo USA e gestito dalla Carnegie Mellon University di Pittsburg. Si focalizza sulle violazioni alla sicurezza, allerta sulle nuove minacce, reagisce agli attacchi (i cosiddetti incidents) e fornisce assistenza, informazioni sulla vulnerabilità dei prodotti e istruzione con documenti e tutorial.
certificate repository
è il database dove la CA pubblica i certificati che genera, che può essere utilizzato come fonte centrale dei certificati e delle chiavi pubbliche dagli utenti della PKI. Esso può inoltre essere usato come ubicazione centrale delle CRL. Certification Authority (CA)
la CA garantisce le chiavi pubbliche delle entità del proprio dominio mediante l’emissione dei “certificati digitali” in formato standard, contenenti: 1) una serie d’informazioni, tra cui il nome del titolare del certificato, la sua chiave pubblica, il periodo di validità del certificato e altre informazioni che concorrono a identificare il titolare e l’autorità che emette il certificato; 2) la firma digitale, apposta alle suddette informazioni utilizzando la chiave privata della CA.
certificato
è una struttura di dati che associa l’identità del titolare alla coppia di chiavi (la chiave pubblica è inclusa nel
certificato), certificata tramite una firma digitale prodotta

IT Administrator - Sicurezza informatica Lezione 8

per mezzo della chiave privata della CA. Detto anche certificato digitale e certificato a chiave pubblica.
Chiave
la sequenza segreta di bit che governa l’atto della cifratura o della decifratura.
Chiave privata
una delle due chiavi usate nella crittografia asimmetrica. E’ segreta e viene mantenuta in possesso del solo proprietario.
Chiave pubblica
una delle due chiavi usate nella crittografia asimmetrica. E’ pubblicamente disponibile a chiunque voglia comunicare con il suo proprietario.
Chiave segreta
la chiave usata nella crittografia simmetrica e comune sia al mittente sia al destinatario. Deve essere mantenuta segreta perché la sua conoscenza consente di decifrare qualsiasi messaggio cifrato alla fonte.
Cifrare o cifratura
l’azione di trasformare i dati in formato illeggibile.
Cifrario a blocchi
opera sui dati un blocco alla volta (le dimensioni tipiche dei blocchi sono di 64 o 128 bit) e ogni operazione su un blocco è un’azione elementare.
Cifrario a flusso
opera invece un bit o un byte alla volta; una volta inizializzati con una chiave, producono un flusso di bit e si prestano alla cifratura di grandi quantità di dati.
CMS (Cryptographic Message Syntax)
il formato con cui sono codificati i messaggi creati con
la cifratura asimmetrica è definito dallo standard PKCS #7
Cryptographic Message Syntax (CMS).
Altre proprietà del formato CMS sono: 1) gestisce la firma congiunta di più firmatari, 2) gestisce la firma per un numero arbitrario di destinatari, 3) consente di aggiungere attributi firmati al messaggio, come la data e l’ora della firma, 4) consente di allegare al messaggio i certificati dei firmatari, agevolando la verifica della firma, 5) include gli identificatori degli algoritmi crittografici utilizzati e gli elementi che facilitano la decifratura e la verifica della firma.
Common Criteria
criteri standard di valutazione di applicabilità globale che allinea i criteri di valutazione esistenti ed emergenti: TCSEC, ITSEC, il canadese CTCPEC (Canadian Trusted Computer Product Evaluation Criteria) e i criteri federali USA. Il progetto è stato sviluppato attraverso la collaborazione degli enti nazionali di standardizzazione di Stati Uniti, Canada, Francia, Germania, Regno Unito e Olanda. I benefici di questo sforzo comune comprendono la riduzione della complessità del sistema di valutazione, la disponibilità di un unico linguaggio per le definizioni e per i livelli di sicurezza e, a beneficio dei produttori, l’uso di un unico insieme di requisiti per vendere i prodotti sul mercato internazionale.
Controllo degli accessi
le funzioni di sicurezza che verificano se il processo o l’utente, di cui è stata autenticata l’identità, ha il diritto di accedere alla risorsa richiesta.
Controllo del rischio
vengono individuate le modalità che l’azienda intende adottare per ridurre i rischi associati alla perdita della disponibilità di informazioni e risorse informatiche e della integrità e riser vatezza di dati e informazioni.
Contromisure
le contromisure di sicurezza sono le realizzazioni e le azioni volte ad annullare o limitare le vulnerabilità e a contrastare le minacce.
Contromisure di carattere fisico
Queste contromisure sono generalmente legate alla prevenzione e al controllo dell’accesso a installazioni, locali, attrezzature, mezzi di comunicazione.

Contromisure di tipo procedurale
definiscono passo per passo le operazioni per eseguire un certo compito oppure regolano il comportamento degli utenti per gli aspetti che riguardano la sicurezza delle informazioni e delle risorse.
Contromisure di tipo tecnico informatico
sono le contromisure realizzate attraverso mezzi hardware, firmware e software e prendono anche il nome di funzioni di sicurezza.
Correttezza
è un attributo intrinseco di un prodotto (o componente o procedura), che riflette il grado di corrispondenza tra le effettive funzioni svolte dal prodotto e le sue specifiche.
Criteri di valutazione della garanzia
sono i metodi con cui viene valutata la fiducia che può essere accordata ai sistemi e ai prodotti informatici di sicurezza. Tra le pubblicazioni disponibili, le tre più significative sono i criteri americani TCSEC (Trusted Computing Security Evaluation Criteria, 1985), i criteri europei ITSEC (Information Security Evaluation Criteria, 1991) e i criteri internazionali ISO/IEC 15408, noti come Common Criteria e pubblicati nel 1999.
Crittoanalisi
la pratica di ottenere il messaggio in chiaro dal messaggio cifrato senza disporre della chiave o senza scoprire il sistema di cifratura.
Crittografia
la scienza della scrittura nascosta (o segreta) che permette di memorizzare e trasmettere dati in una forma utilizzabile solo dagli individui a cui essi sono destinati. crittografia a curve ellittiche (ECC)
tecnologia di cifratura asimmetrica con chiavi molto più corte rispetto a RSA. Una chiave ECC di 163 bit equivale a una chiave RSA di 1024 bit. Le cur ve ellittiche sono una branca della teoria dei numeri e sono definite da certe equazioni cubiche (di terzo grado); le loro proprietà permettono di creare algoritmi crittografici asimmetrici, vista l’estrema difficoltà di eseguire i calcoli a ritroso per ricostruire la chiave privata dalla chiave pubblica e dalle condizioni iniziali.
Crittografia asimmetrica
la chiave di cifratura è diversa da quella di decifratura. Detta anche crittografia a chiave pubblica.
Crittografia simmetrica
la chiave di cifratura è la stessa usata per la decifratura, o possono essere derivate facilmente una dall’altra. Detta anche crittografia a chiave segreta.
Crittologia
lo studio della crittografia e della crittoanalisi.
Crittosistema
l’implementazione hardware o software della crittografia, che trasforma un messaggio in chiaro (plaintext) in un messaggio cifrato (ciphertext) e poi di nuovo nel messaggio in chiaro originario.
CRL (Certificate Revocation List)
contiene l'elenco dei certificati sospesi e revocati. E' una struttura firmata (poiché occorre garantire l’attendibilità delle informazioni che vi sono contenute) ed è composta di due parti: una generale con informazioni sulla CRL stessa e la lista dei certificati revocati dall’ente emettitore.
CSIRT (Computer Security Incident ResponseTeam) squadre di inter vento per gli incidenti di sicurezza informatica coordinate dal CERT-Coordination Center.
Custode dei dati
ha la responsabilità della manutenzione e della protezione dei dati.
Decifrare o decifratura
l’azione di trasformare i dati in formato leggibile.
DES (Data Encryption Standard)
è l’algoritmo di cifratura più conosciuto ed è stato il primo di cui sono stati forniti tutti i dettagli di implementazione. E’ stato incluso nella maggioranza dei prodotti commerciali

Lezione 8 IT Administrator - Sicurezza informatica

dotati di funzionalità crittografiche ed è stato usato dagli enti governativi. Per oltre un decennio, DES è stato considerato uno degli algoritmi più efficaci ed efficienti, finché la NSA smise di supportarlo nel 1988, prevedendo la sua vulnerabilità a fronte della crescita della potenza di calcolo dei computer.
Diffie-Hellmann
algoritmo di crittografia asimmetrica, è utilizzato per lo scambio delle chiavi, dove i due interlocutori si scambiano le chiavi pubbliche e, con le proprie chiavi private, costruiscono una chiave segreta condivisa.
Digest
vedi hash.
Disaster Recovery
nel contesto informatico, è la capacità di un’infrastruttura di riprendere le operazioni dopo un disastro.
Disponibilità
è il grado in cui le informazioni e le risorse informatiche sono accessibili agli utenti che ne hanno diritto, nel momento in cui ser vono.
Distributed IDS (DIDS)
è una combinazione di sensori NIDS e sensori HIDS, distribuiti attraverso la rete aziendale, che riportano le informazioni a un sistema centrale di coordinamento. DMZ (Demilitarized Zone)
il termine di origine militare indica un'area tampone tra una zona fidata e una non fidata all'interno della quale non sono consentite le armi. Applicata al networking, una DMZ è una sottorete alla quale sono connessi sistemi accessibili da reti con diversi livelli di fiducia e criticità.
DSA (Digital Signature Algorithm)
una variante dell’algoritmo di cifratura asimmetrica ElGamal è il DSA, o Digital Signature Algorithm, sviluppato dalla NSA e pubblicato dal NIST (National Institute of Standards and Technology) e diventato uno standard del governo USA.
DSS (Digital Signature Standard)
Lo standard federale americano per la firma elettronica di cui DSA è l’algoritmo di firma e SHA è l’algoritmo di hash. Dynamic packet filtering
Vedi Stateful inspection.
ECB (Electronic Code Book)
un dei principali cifrari a blocchi. Ogni blocco di testo in chiaro viene trasformato in un blocco di testo cifrato. Lo stesso blocco di testo, con la stessa chiave, produce sempre lo stesso blocco di testo cifrato, il che consente ai malintenzionati di compilare un codice (code book) di tutti i possibili testi cifrati corrispondenti a un dato testo in chiaro.
ECDSA
una variante più efficiente del DSA basata sulle cur ve ellittiche.
Efficacia
una proprietà che mette in relazione la contromisura (prodotto, procedura o altro) con il contesto in cui è utilizzata, in particolare le vulnerabilità, la gravità e la probabilità di attuazione delle minacce.
ElGamal
algoritmo di cifratura asimmetrica. Può essere usato sia per la cifratura sia per l’autenticazione con firma digitale. E’ un algoritmo sicuro e ha la caratteristica di generare un testo cifrato lungo il doppio del testo in chiaro.
ESP (Encapsulation Security Payload)
uno dei protocolli della famiglia IPSec. Fornisce la prova di origine dei pacchetti ricevuti, l'integrità dei dati, la protezione da replay (invio ripetuto degli stessi dati) e la riser vatezza, ottenuta attraverso la cifratura del traffico. ETSI (European Telecommunications Standards Institute) un’organizzazione europea indipendente, riconosciuta dalla Commissione Europea e dall’EFTA. Ha sede a Sophia Antipolis (Francia) ed è responsabile per la standardizzazione delle tecnologie informatiche e di

comunicazioni (ICT) in Europa.
Firma digitale
una firma dev’essere difficile da falsificare, non ripudiabile (non può essere cancellata o disconosciuta), inalterabile (dopo l’apposizione della firma, non deve essere possibile modificare il documento) e non trasferibile (da un documento a un altro). La firma digitale si basa sulla cifratura asimmetrica di un hash o digest calcolato sul contenuto del documento o messaggio.
FIRST (Forum for Incident Response and Security Teams) I CERT o CSIRT delle varie nazioni sono collegati in una struttura internazionale, il FIRST, che permette la rapida condivisione delle informazioni utili a fronteggiare minacce e attacchi.
FTP bounce
un attacco (rimbalzo FTP) che sfrutta una vulnerabilità del protocollo FTP per cui un attaccante è in grado di usare il comando PORT per chiedere accesso alle porte indirettamente, attraverso l'uso del ser ver FTP come intermediario nella richiesta.
Funzionalità
applicato alla sicurezza, conser va il significato generale che ha in altri settori; è l’insieme di ciò che un prodotto o un sistema informatico fornisce in relazione alla protezione delle informazioni e, di riflesso, delle risorse e dei ser vizi informatici.
Funzioni di sicurezza
Vedi contromisure di tipo tecnico informatico.
Garanzia
concetto introdotto da chi si occupa di sicurezza per esprimere il grado in cui l’implementazione di una funzionalità riduce una vulnerabilità o la possibilità di attuazione di una minaccia.
Gestione del rischio
nella gestione del rischio si possono individuare due fasi distinte.1) Analisi del rischio. 2) Controllo del rischio.
Hash un numero binario di lunghezza fissa, ricavato da un input (file, messaggio, blocco di dati eccetera) di lunghezza variabile, che funge da “impronta” del dato di partenza.
HMAC
Un tipo speciale di MAC specificato nella RFC 2104. HMAC è anch’essa una funzione keyed hash, ma in realtà costituisce un keyed hash
all’interno di un keyed hash.
honeynet
una rete composta da honeypot, ossia sistemi vulnerabili verso cui attirare un attaccante per distrarlo dai sistemi critici e trattenerlo abbastanza a lungo da individuarlo.
Honeypot
un sistema esca, distinto e complementare rispetto a un IDS, progettato per attirare gli attaccanti lontano dai sistemi critici.
Host-Based IDS (HIDS)
un IDS basato su host (HIDS) differisce da un NIDS in due modi: protegge solo il sistema su cui è installato (anziché la sottorete) e la scheda di rete del sistema su cui è installato funziona in modo non promiscuo (non ascolta i pacchetti destinati agli altri nodi della sottorete).
IAB (Internet Architecture Board)
un gruppo tecnico consultivo della Internet Society, responsabile della selezione dello IESG, della super visione dell’architettura, della super visione del processo di standardizzazione e della procedura di appello, della serie delle RFC (Request For Comment), dei collegamenti esterni e di consiglio all’ISOC.
IANA (Internet Assigned Numbers Authority) mantiene le funzioni di coordinamento centrale dell’Internet globale nel pubblico interesse. La IANA
custodisce i numerosi parametri e valori di protocollo unici necessari per il funzionamento di Internet e per il suo sviluppo futuro.
ICANN (Internet Corporation for Assigned Names and

IT Administrator - Sicurezza informatica Lezione 8

Numbers)
azienda non-profit che fu creata per assumere la responsabilità dell’attribuzione degli spazi d’indirizzamento IP, dell’assegnazione dei parametri dei protocolli, della gestione del sistema dei domini e della gestione del sistema dei ser ver root, funzioni che in precedenza erano eseguite, sotto contratto con il governo USA, dalla IANA e da altre entità. È l’autorità per l’assegnazione dei nomi di dominio a livello globale.
IDEA
IDEA è un cifrario simmetrico a blocchi di 64 bit, suddivisi in 16 sotto-blocchi sottoposti a otto serie di manipolazioni matematiche. IDEA presenta similitudini con DES, ma è molto più robusto. La chiave è lunga 128 bit. IDEA è brevettato ed è concesso in licenza dalla società svizzera Mediacr ypt.
Identificazione e autenticazione
Le funzioni di questa categoria ser vono a identificare un individuo o un processo e ad autenticarne l’identità.
IESG (Internet Engineering task Group)
è responsabile della gestione tecnica delle attività dell’IETF e del processo di standardizzazione di Internet. Come
parte dell’ISOC, amministra tale processo secondo le regole e le procedure che sono state ratificate dai fiduciari dell’ISOC. Lo IESG è direttamente responsabile delle azioni associate all’avvio e alla prosecuzione dell’iter di standardizzazione, inclusa l’approvazione finale delle specifiche come Standard Internet. Lo IESG coordina e approva gli standard tecnici.
IETF (Internet Engineering Task Force)
una vasta comunità internazionale di progettisti, operatori, produttori e ricercatori nel campo del networking, interessati all’evoluzione dell’architettura di Internet e all’affidabilità del suo funzionamento.
IKE (Internet Key Exchange)
uno dei protocolli della famiglia IPSec. Fornisce un modo dinamico automatico per autenticare gli interlocutori, negoziare i ser vizi di sicurezza e generare chiavi condivise.
Impatto
è la conseguenza dell’attuazione di una minaccia.
Integrità è la fedele conser vazione del contenuto originario di un documento archiviato o trasmesso in rete, attestata da strumenti che segnalano se il documento ha subito alterazioni. L’integrità è il grado di correttezza, coerenza e affidabilità delle informazioni e anche il grado di completezza, coerenza e condizioni di funzionamento delle risorse informatiche.
Internet Society – ISOC
un’organizzazione privata senza fini di lucro che riunisce professionisti nel mondo del networking e che ha la missione di garantire il continuo funzionamento di Internet e il suo potenziamento.
Intrusion Detection Systems (IDS)
sistemi hardware o software che automatizzano il processo di monitoraggio degli eventi che avvengono in un sistema o in una rete, analizzandoli alla ricerca d’indicatori riconducibili a problemi di sicurezza. Hanno il compito di riscontrare attività sospette e intrusioni, sia di tipo classificato e riconoscibile tramite pattern matching, sia di tipo sconosciuto in virtù di qualche anomalia di
comportamento o di uso scorretto dei protocolli.
Intrusion Prevention Systems (IPS)
sistemi che cercano d'inviduare tentativi d'intrusione e rispondere immediatamente. Anziché limitarsi a monitorare il traffico come fanno gli IDS, gli IPS vengono installati in linea, di fronte alla rete o al ser vizio da proteggere, in modo da bloccare il traffico ostile.
IPSec (Internet Protocol Security)
La principale suite di protocolli usata per creare VPN (Virtual Private Network). Fornisce funzioni di autenticazione e di cifratura a livello del protocollo IP. Il
modo in cui IPSec protegge i pacchetti IP è attraverso l'uso

di uno dei suoi due protocolli, ESP (Encapsulation Security Payload) o AH (Authentication Header). AH fornisce la prova di origine dei pacchetti ricevuti, l'integrità dei dati e la protezione da replay. ESP offre tutto ciò che fornisce AH con in più la riser vatezza, ottenuta attraverso la cifratura del traffico.
IRTF (Internet Research Task Force)
ha la missione di promuovere attività di ricerca che possano contribuire in modo significativo al futuro sviluppo di Internet. Opera creando gruppi di ricerca focalizzati sui seguenti temi: protocolli, applicazioni, architettura e tecnologia.
ISO (International Organization for Standardization) la maggiore organizzazione internazionale di standardizzazione e comprende gli enti di
standardizzazione nazionali di 146 paesi (l’UNI è il membro italiano).
ISO/IEC 17799
una serie di linee guida e di raccomandazioni compilata a seguito di consultazioni con le grandi aziende. I 36 obiettivi e le 127 verifiche di sicurezza contenuti nel documento sono suddivisi in 10 aree, o domini, riportati nel riquadro A, II dieci domini formano una piramide che scende dalla prospettiva organizzativa (1, 2, 3, 4, 9, 10) verso quella
operativa (6, 7, 8), con inclusi gli aspetti tecnici (5).
ITSEC (Information Security Evaluation Criteria)
il primo tentativo di stabilire un unico standard di valutazione degli attributi di sicurezza da parte di molti paesi europei.
ITU (International Telecommunication Union) un’organizzazione internazionale, nell’ambito dell’ONU, dove governi e settore privato coordinano le reti e i ser vizi globali di telecomunicazioni. Ha sede a Ginevra e comprende i settori ITU-T (standardizzazione), ITU-R (radiocomunicazioni) e ITU-D (sviluppo).
Keyed hashing
Far dipendere l'hash del messaggio da una chiave segreta. Il keyed hashing viene usato nella crittografia simmetrica per produrre i codici MAC utilizzati per autenticare i messaggi e garantirne l’integrità.
Keyspace
(spazio delle chiavi) l’insieme di tutti i possibili valori che una chiave può assumere.
Layer 2 Forwarding (L2F)
protocollo di tunneling di strato 2. A differenza di PPTP e L2TP, L2F è destinato all'uso tra dispositivi di rete, come il ser ver di accesso alla rete di un ISP (Internet Ser vice Provider), e il gateway VPN di un'azienda. Gli utenti stabiliscono una connessione non protetta dal loro computer all'ISP. Quest'ultimo riconosce che il traffico degli utenti deve essere incapsulato in un tunnel verso l'azienda, perciò autentica ogni utente e il gateway dell'azienda, quindi fornisce la protezione del traffico tra il proprio ser ver e l'azienda.
Layer 2 Tunneling Protocol (L2TP)
alla pari di PPTP, protegge le comunicazioni tra un client e un ser ver entrambi abilitati a L2TP. Utilizza un proprio protocollo di tunneling che fa uso della porta UDP 1701. Inoltre, L2TP supporta sessioni multiple nello stesso tunnel.
Link Mode Port
vedi Port Mirroring.
MAC (Message Authentication Code)
un hash calcolato su un messaggio con l’aggiunta di una chiave segreta condivisa, usato per verificare all’altro capo della comunicazione l’integrità del messaggio.
man-in-the-middle
tipo di attacco dove il nemico finge rispettivamente di essere l'altro interlocutore nei confronti di due sistemi tra i quali si è interposto. Intercetta il traffico dell'uno prima di ritrasmetterlo all'altro e viceversa, fingendo ogni volta di essere il mittente e il destinatario corretto per ciascuna

Lezione 8 IT Administrator - Sicurezza informatica

comunicazione.
MD5
algoritmo di hash evoluzione di MD4, è stato sviluppato da Ron Rivest all’MIT nel 1991 ed è descritto nella RFC 1321 (www.ietf.org/r fc). MD5 è molto popolare, ma la crescita della potenza di calcolo e i primi successi degli attacchi sia basati su forza bruta sia di tipo crittoanalitico (basati sull’analisi dell’algoritmo) inducono a considerare MD5 vulnerabile
Microsoft Point-to-Point Encryption (MPPE)
un meccanismo di cifratura per PPTP sviluppato da Microsoft, che usa una chiave da 40 o 128 bit con l'algoritmo RC4 di RSA.
MIME (Multipurpose Internet Mail Extensions)
è lo standard che specifica come devono essere trasferiti i dati multimediali e gli allegati di e-mail.
Minaccia
è un’azione potenziale, accidentale o deliberata, che può portare alla violazione di uno o più obiettivi di sicurezza.
Monitoring Port
vedi Port Mirroring.
Network-Based IDS (NIDS)
sotto controllo un intero segmento di rete (o sottorete). La scheda passa agli strati di rete superiori non solo i pacchetti diretti all'indirizzo MAC (Media Access Control) della scheda, ma tutti i pacchetti che transitano in quel punto della rete, qualunque sia il destinatario. L'IDS si comporta quindi da sniffer di tutto il traffico in transito, che viene quindi analizzato con metodi diversi.
Non ripudio
impedisce che un evento o documento possa essere disconosciuto dal suo autore.
Norme e linee guida
segnaliamo le linee guida ISO/IEC 13335 e le norme BS (British Standard) 7799.
Norme funzionali
sono relative ai prodotti e hanno lo scopo principale di ricercare l’interoperabilità dei prodotti informatici. Coprono argomenti quali i protocolli di comunicazione, il formato dei dati (per esempio in un certificato digitale o in una
smartcard) e così via.
Obiettivi
gli obiettivi di sicurezza sono il grado di protezione che si intende predisporre per i beni, in termini di disponibilità, integrità e riser vatezza.
OCSP (Online Certificate Status Protocol)
è un protocollo relativamente semplice di domanda- risposta, che offre uno strumento per ottenere online informazioni aggiornate sulla revoca dei certificati, fornite da un’entità fidata.
one-way hash function
produce una trasformazione a senso unico, dove a N possibili input corrisponde un output, da cui non è possibile risalire all’input. L’hashing one-way viene usato nella crittografia asimmetrica per produrre le firme digitali (ad esempio con gli algoritmi RSA o DSA), anche in questo caso per assicurare l’autenticità e l’integrità dei dati trasmessi o archiviati.
Packet filter
il tipo più semplice di firewall che consiste di un router che include una funzione di controllo d'accesso per i singoli pacchetti governata da una serie di regole (ruleset) eseguite in sequenza.
Padded Cell
una padded cell (cella imbottita) opera in coppia con un IDS, Quando l'IDS riconosce un attaccante, lo trasferisce in modo trasparente a uno speciale host con funzione di padded cell, che contiene un ambiente simulato dove l'attaccante non può fare danno.
Pattern matching
uno dei tre metodi usati dagli IDS per riconoscere segni d'intrusione. Consiste nel riconoscimento dei pacchetti a

fronte di un database di "firme" che identificano i vari tipi di attacco.
PGP (Pretty Good Privacy)
un programma di sicurezza per la posta elettronica realizzato da Phil Zimmermann e pubblicato inizialmente nel 1991 come freeware. Le funzioni
di PGP sono: firma digitale, cifratura dei messaggi, compressione, conversione in ASCII (in base 64) e segmentazione dei messaggi; di queste, le prime due rientrano nel contesto delle applicazioni crittografiche. PKCS (Public Key Cryptographic Standard) comprende un’intera serie di standard che hanno
l’obiettivo di agevolare l’implementazione delle tecnologie PKI (per esempio, PKCS #1 descrive lo standard di cifratura RSA). PKCS #7 specifica i formati binari usati per la firma digitale e per la “busta elettronica”. Lo standard PKCS #7 è stato adottato dall’IETF nella RFC 2315, aggiornata dalla RFC 2630.
PKI (Public Key Infrastructure)
L’infrastruttura a chiave pubblica nasce con lo scopo di distribuire e gestire in modo sicuro le chiavi pubbliche per tutto il periodo della loro validità, garantendo la corrispondenza tra ogni chiave pubblica e il proprietario della coppia di chiavi. La garanzia di autenticità delle chiavi pubbliche (e quindi delle corrispondenti chiavi private) è fornita dalle Autorità di Certificazione (Certification Authority o CA) tramite l’emissione di certificati digitali.
Point-to-Point Tunneling Protocol (PPTP)
fornisce un tunnel protetto tra un client (per esempio un personal computer) e un ser ver entrambi abilitati a PPTP. La versione 2 ha risolto molti problemi di sicurezza, ma se ne consiglia l'utilizzo solo per connessioni occasionali senza alti requisiti di sicurezza.
Politica di sicurezza
è un documento sintetico in cui il management superiore, o un comitato delegato allo scopo, delinea il ruolo della sicurezza nell’organizzazione o in un suo aspetto
particolare.
Port Mirroring
per consentire l'analisi del traffico a scopo di prevenzione delle intrusioni, gli switch vengono riconfigurati in modo da replicare i dati di tutte le porte o VLAN (Virtual LAN) su una singola porta di mirroring. Spesso Port Mirroring indica più precisamente la capacità di copiare il traffico da una singola porta a una porta di mirroring, disattivandone il traffico bidirezionale. Vedi anche Spanning Port.
Privacy
consiste nella salvaguardia dei dati privati degli utenti, anche in conformità alla legge 196/2003 sulla protezione dei dati personali.
Proprietario dei dati
un membro del management superiore, il massimo responsabile della protezione delle informazioni e della sicurezza in generale.
Proxy
(procuratore) un ser ver che si frappone fra un'applicazione client (come un browser) e un reale ser ver (come un web ser ver). Al ser ver il proxy appare come se fosse il client, mentre al client esso appare come se fosse il vero ser ver.
Proxy firewall
un firewall basato su proxy (detto anche application gateway, proxy gateway e proxy ser ver) che richiede un'applicazione specifica per ogni protocollo. Vengono usate applicazioni che accettano connessioni dai client, esaminano il traffico e aprono corrispondenti connessioni verso i ser ver.
RC4
RC4 è il più noto dei cifrari a flusso. E’ stato creato nel 1987 da Ron Rivest per RSA Security. Utilizza un keystream di dimensioni variabili (ma solitamente di 128 bit) e opera su un byte alla volta. In origine il cifrario era segreto, ma fu fatto filtrare su Internet. L’algoritmo è molto

IT Administrator - Sicurezza informatica Lezione 8

robusto se utilizzato con chiavi di lunghezza adeguata (tipicamente 128 bit) casuali e non riutilizzate.
RC5
RC5 è un cifrario simmetrico a blocchi dotato di parecchi parametri per assegnare le dimensioni del blocco, la lunghezza della chiave e il numero di passaggi di trasformazione da eseguire. E’ stato creato da Ron Rivest (la R di RSA). Di solito si utilizzano blocchi di 32, 64 o 128 bit e la chiave può raggiungere i 2.048 bit. RC5 è stato brevettato da RSA Security nel 1997. Il basso consumo di memoria lo rendono adatto per smartcard e altri dispositivi simili.
Recovery Point Objective (RPO)
il momento nel tempo a cui il sistema è riportato.
Recovery Time Objective (RTO)
il lasso di tempo che intercorre prima di ripristinare l’infrastruttura.
Registration Authority
un componente dell’infrastruttura che viene talvolta utilizzato per sollevare la CA da certe funzioni, aumentando la scalabilità e riducendo i costi. I ser vizi della RA sono di autenticazione e validazione delle richieste provenienti dalle entità utenti.
Rendicontabilità (accountability)
le funzioni che permettono di attribuire la responsabilità degli eventi agli individui che li hanno causati.
Replay
tecnica d'attacco che prevede l'invio ripetuto degli stessi dati oppure con forte alterazione della sequenza.
L'attaccante usa un vecchio messaggio o parte del traffico che ha intercettato e registrato e che ora ripropone per indurre un ser ver a ripetere una determinata operazione. Un impiego tipico è richiedere l'autenticazione riciclando informazioni di autenticazione utilizzate da qualcun altro in precedenza.
Reverse proxy
indica un proxy utilizzato per la protezione di un ser ver, tipicamente un web ser ver (HTTP/HTTPS) su Internet. Gli usi più comuni dei reverse proxy riguardano il bilanciamento del carico e la continuità del ser vizio, che costituiscono anche un aspetto di disponibilità.
Rilevamento delle anomalie
uno dei tre metodi usati dagli IDS per riconoscere segni d'intrusione. Suddivisibili in anomalie basate sul comportamento e in anomalie basate sul protocollo. Il
rilevamento delle anomalie si basa sull'esame del traffico a livello superiore rispetto al pattern matching e all'analisi dei protocolli. Anziché i singoli pacchetti, si osser va il traffico nel suo complesso
RIPEMD-160
algoritmo di hash sviluppato nell’ambito del progetto European RACE Integrity Primitives Evaluation (RIPE) da un gruppo di ricercatori che avevano conseguito parziali successi nell’attaccare MD4 e MD5.
Rischio
Concettualmente, il rischio è la possibilità che si verifichi un evento dannoso ed è tanto maggiore quanto è forte l’impatto causato dall’evento e quanto è alta la probabilità che esso si verifichi.
Riservatezza
consiste nel limitare l’accesso alle informazioni e alle risorse informatiche alle sole persone autorizzate e si applica sia all’archiviazione sia alla comunicazione delle informazioni.
Riutilizzo degli oggetti
le funzioni che permettono di riutilizzare oggetti contenenti informazioni riser vate: supporti magnetici, supporti ottici riscrivibili, aree di memoria RAM, zone di memoria dei processori (registri, cache, ecc.), buffer di periferiche e simili.
RSA
dell’omonima azienda, è il cifrario asimmetrico più

utilizzato. Può essere usato sia per la cifratura (per ottenere la riser vatezza), sia per la firma digitale (per ottenere l’autenticazione), sia per lo scambio delle chiavi (come nell’esempio di cui sopra).
S/MIME (Secure/Multipurpose Internet Mail Extensions) è un protocollo che aggiunge la cifratura e la firma elettronica ai messaggi MIME descritti nella RFC 1521 (Mechanisms for Specifying and Describing the Format of Internet Message Bodies).
Scambio dati sicuro
le funzioni destinate a garantire la sicurezza delle trasmissioni. Il modello OSI Security Architecture (ISO 7498-2) le classifica nelle seguenti sottoclassi: autenticazione, controllo dell’accesso, riser vatezza, integrità (dell’hardware, dei dati e dei flussi di pacchetti trasmessi sia in modo connectionless, come UDP, sia connection-oriented, come TCP, anche ai fini della corretta sequenza dei pacchetti) e non ripudio.
Screened subnet
a differenza di una DMZ che è una piccola sottorete collocata tra il router Internet e l'inter faccia esterna del firewall, una screened subnet è una rete isolata accessibile solo attraverso una delle inter facce del firewall e non connessa direttamente alla rete interna.
Secure Shell (SSH)
un protocollo per realizzare un collegamento remoto sicuro da un computer a un altro attraverso una rete insicura.
Supporta il login remoto sicuro, il trasferimento sicuro di file e l’inoltro sicuro del traffico di tipo TCP/IP e X Window. SSH è in grado di autenticare, cifrare e comprimere i dati trasmessi.
Secure Sockets Layer (SSL)
è un protocollo per la protezione di un canale di comunicazione attraverso una rete e funziona allo strato di trasporto, tra i protocolli di trasporto e di applicazione.
Come altri protocolli di sicurezza di rete, SSL utilizza la crittografia simmetrica e asimmetrica e le funzioni di hash per fornire l’autenticazione del ser ver (e in opzione anche del client), la cifratura dei messaggi e l’integrità dei dati. SHA (Secure Hash Algorithm)
uno standard FIPS (Federal Information Processing Standard) statunitense. SHA genera un digest di 160 bit che viene passato a DSA o a un altro degli algoritmi di firma digitale ammessi dal governo USA (RSA ed ECDSA, Elliptic Cur ve Digital Signature Algorithm).
SHA-1
è stato sviluppato dal NIST ed è stato pubblicato come standard federale USA nel 1993 con il nome di Secure Hash Algorithm (SHA, FIPS 180) e riveduto nel 1995 come SHA-1 (FIPS180-1). SHA-1 riceve in input un messaggio di lunghezza massima inferiore a 264 bit (una dimensione equivalente a 2.147 Gbyte e perciò praticamente illimitata), suddiviso in blocchi di 512 bit, e produce un hash di 160 bit.
Sicurezza attiva
le misure di sicurezza che proteggono le informazioni in modo proattivo, in modo cioè da anticipare e neutralizzare i problemi futuri. Questo viene ottenuto non solo impedendo agli estranei di accedere alle informazioni (sicurezza passiva o difensiva), ma rendendo le informazioni intrinsecamente sicure a livello applicativo, proteggendone la riser vatezza (confidentiality, chiamata anche confidenzialità), l’integrità e l’autenticità.
Sicurezza passiva
un approccio fondamentalmente difensivo o passivo, che valuta quali rischi accettare, quali delegare a terzi e quali controllare, riducendoli o azzerandoli.
Skipjack
Skipjack è un cifrario a blocchi sviluppato dalla NSA nel 1987, messo in ser vizio nel 1993 e declassificato nel 1998.
Social engineering

Lezione 8 IT Administrator - Sicurezza informatica

è la pratica di manipolare ad arte le persone per indurle a compiere azioni (come l’esecuzione di software maligno) oppure a rivelare informazioni (come le password) utili a ottenere accesso a dati e risorse.
SPAN port
vedi Spanning Port.
Spanning Port
in parte sinonimo di Port Mirroring. Per consentire l'analisi del traffico a scopo di prevenzione delle intrusioni, gli switch vengono riconfigurati in modo da replicare i dati di tutte le porte o VLAN (Virtual LAN) su una singola porta di mirroring. Spanning Port indica in particolare la possibilità di copiare il traffico da tutte le porte a una singola porta, disattivandone il traffico bidirezionale.
Stateful inspection
tutti i filtri di pacchetti che implementano qualche forma di stateful inspection mantengono in memoria lo stato di tutte le comunicazioni che attraversano il firewall e determinano se bloccare i singoli pacchetti in base a interi flussi di comunicazione, non semplicemente sulla base dei singoli pacchetti. Perciò, i firewall del tipo stateful inspection (o stateful packet inspection, SPI) permettono o bloccano il passaggio di un pacchetto non solo in base a indirizzi IP e porte, ma anche utilizzando SYN, ACK, numeri di sequenza e altri dati contenuti nell'header TCP (strato 4).
Static packet filtering
Vedi Packet filtering
TCSEC (Trusted Computing Security Evaluation Criteria) un sistema per valutare la funzionalità e garanzia di un prodotto, usato soprattutto negli USA e descritto nel cosiddetto Orange Book, un volume dalla copertina arancione. Ser ve per valutare sistemi operativi, applicazioni e prodotti di vario genere.
Testo cifrato (ciphertext)

dati in forma cifrata o illeggibile.
Testo in chiaro (plaintext o cleartext)
dati in forma leggibile o intelligibile.
Time Stamp Authority (TSA)
una terza parte fidata che attesta il tempo di produzione o d’invio di un documento tramite una “marca temporale”, che è di fatto una controfirma del documento contenente un hash del documento, il riferimento temporale e altre informazioni.
TLS (Transport Layer Security)
un protocollo definito dall’IETF nella RFC 2246, simile a SSL, ma con differenze soprattutto negli algoritmi crittografici utilizzati.
UNINFO
una libera associazione a carattere tecnico, con lo scopo di promuovere e di partecipare allo sviluppo della normativa nel settore delle tecniche informatiche. L’UNINFO è associato all’UNI, l’ente nazionale italiano di unificazione (www.uni.com/it) e rappresenta l’Italia presso CEN e ISO. Verifica (audit) le funzioni che registrano gli eventi in un file di logging, con informazioni riguardo a errori e a violazioni di sicurezza.
Virtual Private Network (VPN)
una VPN è una rete virtuale, costruita sulla base di reti fisiche esistenti, in grado di fornire un meccanismo di comunicazione sicura dei dati e delle informazioni IP trasmessi in rete.
Vulnerabilità
una vulnerabilità è un punto debole del sistema informatico (hardware, software e procedure) che, se colpito o sfruttato da una minaccia, porta alla violazione di qualche obiettivo di sicurezza.
Work factor (fattore di lavoro)
il tempo, lo sforzo e le risorse che si stimano necessari per violare un crittosistema.