370 likes | 678 Views
Sicurezza delle reti informatiche: come, dove e perchè. F.Baiardi * , S.Suin + , C.Telmon * *Dipartimento di Informatica, +Centro SerRA Università di Pisa. Sicurezza Informatica UniPI. corso Sicurezza delle Reti -DU in Informatica progetto Credits corsi specialistici
E N D
Sicurezza delle reti informatiche: come, dove e perchè F.Baiardi *, S.Suin+, C.Telmon* *Dipartimento di Informatica, +Centro SerRA Università di Pisa
Sicurezza Informatica UniPI • corso Sicurezza delle Reti -DU in Informatica • progetto Credits • corsi specialistici • sviluppo di software per sicurezza • proxy sicuro • firewall kit • autorità di certificazione in Java
I temi trattati oggi • I punti critici di una rete informatica • come individuarli • Gli strumenti per attaccare • come violare i punti critici • Gli strumenti per difendersi dagli attacchi • come rafforzare il sistema
Politiche di sicurezza • la definizione della politica di sicurezza non può che partire da una analisi dei rischi • l’analisi dei rischi deve individuare i punti critici • criticità = ridotta robustezza
Robustezza Informatica • robustezza di un componente = capacità di non danneggiare il sistema in cui è inserito quando vengono violate le specifiche del componente stesso • violazione delle specifiche = • input diversi da quelli specificati, • risorse diverse da quelle specificate
Robustezza Informatica • è una proprietà diversa da correttezza, efficienza, facilità d’uso, .... • è in contrasto con efficienza e facilità d’uso, può aumentare solo a spese di queste due proprietà No Free Lunch Theorem
Robustezza Informatica Un programma per il calcolo degli stipendi che dato un nome restituisce lo stipendio - corretto se calcola lo stipendio esatto - efficiente se impiega poco tempo - facile da usare se addestramento è breve - robusto ????
Robusto .... • nome sbagliato • nome non esistente • allocata meno memoria di quella necessaria • file con nomi non esistente • file con qualifiche non esistente • disco non esistente ....
Quanto robusto .... • è estremamente difficile prevedere tutte le possibili violazioni delle specifiche • robustezza non è una proprietà 0/1 • misura di robustezza = associare ad ogni componente un valore da 0 a 1 • 1 è valore asintotico
Quanto robusto 1 Robustezza Numero dei controlli
Quanto robusto • valore dipende dai controlli che il componente esegue sul proprio ambiente • robustezza tende ad 1 al tendere ad infinito dei controlli • normalmente i controlli sono inutili, ciò limita il numero dei controlli possibili senza danneggiare le prestazioni
Robustezza • è stato provato come controlli anche banali siano in grado di rilevare numerose situazioni anomale • quindi è bene eseguire controlli sofisticati solo dopo quelli semplici • i controlli più significativi sono quelli sull’uso dei dati coerenti con i tipi dichiarati
Robustezza è inutile cercare di essere impenetrabili occorre essere costosi (tempo e danaro ) da penetrare
Sistema Robusto ... • la robustezza di un sistema nasce dalla robustezza dei suoi componenti • è inutile costruire sistemi ove componenti robusti interagiscono con componenti poco robusti • criticità dei sistemi operativi e dei linguaggi di programmazione per la robustezza
Robustezza Globale ... Applicazioni Sistema Operativo Hardware • è inutile, e dannoso, costruire applicazioni robuste su sistemi non robusti è inutile costruire utilizzare la crittografia su sistemi in cui è facile rubare la chiave
Robustezza globale ... • la situazione può essere ancora più critica nel caso di linguaggi di programmazione • un linguaggio poco robusto inficia tutte le applicazioni sviluppate con quel linguaggio un linguaggio con operazioni sui vettori non controllate non può essere robusto
Robustezza globale • esistono molti attacchi a cui sono soggette tutte le applicazioni sviluppate in C • tutti questi attacchi sono possibili perchè il C non controlla che • le operazioni sui dati siano coerenti con il tipo dichiarato • le operazioni sui vettori rispettino i limiti dichiarati per il vettore stesso
Come valutare la robustezza • Caso di interesse : un componente condiviso di un sistema che definisce un insieme di operazioni • le operazioni possono essere invocate da “utenti” che condividono il componente • le operazioni sono fisse ma gli utenti possono variare
Valutazione: primo criterio • esiste una struttura dati che rappresenta i diritti degli utenti sul componente • diritto = operazioni che utente può invocare • assenza di informazioni deve essere interpretata come un divieto • la struttura o è interna al componente o è utilizzata dal sistema operativo
Valutazione: primo criterio • struttura dati complessiva = matrice di protezione • soggetto = può invocare una operazione = utente o altro componente • oggetto = un componente condiviso • controllo degli accessi = controllo dei diritti dei soggetti sugli oggetti
Matrice di protezione oggetti soggetti
Matrice di protezione • i controlli sono eseguiti ogni volta che un soggetto invoca una operazione • riga della matrice = dominio di protezione di un soggetto • non può esistere robustezza senza una qualche rappresentazione di questa struttura • domini non gerarchici
Matrice di protezione • nel caso in cui gli oggetti siano i file di un server ed i soggetti siano gli utenti del server stesso sono necessarie da 10 a 15 ore per rappresentare correttamente la matrice di protezione (stima NSA) • in questo caso i diritti sono semplicemente lettura, scrittura ed esecuzione
Matrice di protezione • sorge il problema della identificazione di un soggetto • password • crittografia • uso di certificati e firma elettronica • ....
Matrice di protezione non sempre questo criterio è applicabile perchè non tutte le risorse sono sotto il controllo del sistema ad esempio non è possibile garantire che nessuno stia monitorando il traffico sulle linee fisiche crittografia
Domini di protezione • è fondamentale poter associare un dominio di protezione ad ogni applicazione • il rispetto del dominio deve essere garantito dal sistema operativo del/dei nodi dove essa è eseguita • questo mandatory access control si affianca a quello dell’applicazione stesso
Tre politiche per la robustezza • il primo criterio evidenzia tre politiche che sono fondamentali per la robustezza • controlli nell’accesso agli oggetti • controlli di identificazione • politiche di crittografia • per l’identificazione dei soggetti • per la confidenzialità dei dati
Valutazione: secondo criterio • per rispecchiare l’avanzamento della computazione i diritti (e quindi la matrice) variano dinamicamente • occorre minimizzare il dominio corrente di ogni soggetto • al diminuire del dominio aumenta la capacità di rilevare comportamenti anomali
Valutazione: secondo criterio • in teoria occorre modificare la matrice per ogni istruzione eseguita • ovviamente questo produce un sistema robusto ma inutile • una granularità più ragionevole è quella delle procedure o dei metodi
Valutazione: secondo criterio • il criterio sottolinea l’importanza di eliminare le funzionalità non necessarie • generalizzazione = la regola KISS Keep è più semplice garantire la It robustezza di un sistema semplice Simple Stupid non si attacca quel che non esiste
Valutazione: secondo criterio • separare i componenti critici dal punto di vista della robustezza dagli altri • possibile aumentare i controlli nei componenti critici per la robustezza • un codice che deve essere commentato è troppo complesso per essere robusto
Valutazione: terzo criterio • non deve essere possibile violare i controlli operando ad un livello diverso da quello considerato • ciò avviene tipicamente se è possibile utilizzare nella stessa applicazione due linguaggi di programmazione con caratteristiche diverse (linguaggio ad alto livello e assembler)
Sistema Robusto Applicazioni Sistema Operativo Assembler Firmware Hardware
Valutazione: quarto criterio • la robustezza aumenta se lo stesso controllo viene ripetuto in componenti diversi • ad esempio il possesso di un diritto viene controllato prima nell’invocante e poi nell’invocato • evitare i punti di caduta catastrofica = sandbox di Java, firewall, ...
Come utilizzare i criteri • un uso paranoico dei criteri può portare a sistemi robusti ma inutilizzabili • questo non sembra comunque un rischio a breve termine • attualmente un pizzico di paranoia non può che essere utile e produttivo
Come utilizzare i criteri • individuare i componenti critici • inserire tutti i controlli che non riducono le prestazioni di tali componenti • spesso il controllo può essere inserito in componenti che interagiscono con quelli ad elevata criticità • bilanciamento del carico • rilevazione veloce di violazioni
Come utilizzare i criteri • stabilire la probabilità di attacco ad ogni punto • aumentare la robustezza di un punto in maniera proporzionale agli attacchi • non comprare un firewall poco robusto • a firewall is a replacement of the unsecurity of the network host (S.Bellovin)