1 / 37

Sicurezza delle reti informatiche: come, dove e perchè

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

amory
Download Presentation

Sicurezza delle reti informatiche: come, dove e perchè

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  1. Sicurezza delle reti informatiche: come, dove e perchè F.Baiardi *, S.Suin+, C.Telmon* *Dipartimento di Informatica, +Centro SerRA Università di Pisa

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

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

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

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

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

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

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

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

  10. Quanto robusto 1 Robustezza Numero dei controlli

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

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

  13. Robustezza è inutile cercare di essere impenetrabili occorre essere costosi (tempo e danaro ) da penetrare

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

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

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

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

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

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

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

  21. Matrice di protezione oggetti soggetti

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

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

  24. Matrice di protezione • sorge il problema della identificazione di un soggetto • password • crittografia • uso di certificati e firma elettronica • ....

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

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

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

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

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

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

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

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

  33. Sistema Robusto Applicazioni Sistema Operativo Assembler Firmware Hardware

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

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

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

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

More Related