Upload
giorgio-monaco
View
220
Download
0
Embed Size (px)
Citation preview
Progetto Sicurezza
Codice Corretto – Codice Robusto: Metodi formali per la progettazione di codice sicuro
Checklist IS Metodi Logico Formali
Protocolli: Punti Deboli Esempi Progettazione Sicura: Suggerimenti
IPv6 Security
Correttezza vs. Robustezza (1)
Non esiste una definizione precisa di codice robusto
Per capire ₩ necessario osservare le differenze che intercorrono tra codice corretto e codice robusto
Un programma si dice corretto se si comporta come previsto dalle specifiche
Correttezza vs. Robustezza (2)
Un programma robusto ₩: Corretto Scritto in modo da controllare che la propria esecuzione
non causi danni
Quindi ₩ necessario inserire dei controlli: Quanti? Quali? Dove?
Non esiste una risposta precisa a tali domande!
Correttezza vs. Robustezza (3)
Nel corso degli ultimi 30 anni sono stati studiati alcuni metodi (pseudo-)formali per la progettazione di software sicuro:
Checklist Software Engineering Metodi Logico - Formali
La semplice applicazione di uno qualsiasi di tali approcci non implica un prodotto finale o un sistema sicuro al 100%
Checklist: Caratteristiche
Metodo pragmatico basato sull'esperienza dei professionisti del campo
Metodo poco formale: Specifiche scritte in linguaggio naturale Assenza di regole e metodi precisi
Assunzioni: Spazio soluzioni limitato Soluzioni a validità universale
Checklist: Pro
Completa analisi di ogni componente possibile del sistema di sicurezza
Indipendenza dal know-how dell'analista
Stile “cookbook”: Presenza di numerosi tools che assistono l'analista
nelle varie fasi del progetto Sistemi esperti per l'analisi dei rischi e della sicurezza
dei sistemi
Checklist: Contro
Modello troppo semplicistico
Non adatto a grandi sistemi informatici
Utilizzo di linguaggio naturale
Difficoltà di manutenzione
Mancanza di metodologie formali: Possibilità di dimenticare qualche particolare Soluzioni obsolete
Software Engineering: Caratteristiche
Modelli di progettazione molto simili a quelli utilizzati in IS per la progettazione e la realizzazione del software
Esempio: modello di Fisher (1984) Inventario dei dati da proteggere Identificazione dei punti deboli del sistema Analisi dei rischi Progettazione dei controlli Analisi costi-benefici
Software Engineering: Assunzioni
Per ogni sistema esiste una soluzione ottima riguardo alla sicurezza
Lo spazio delle soluzioni non ₩ numerabile
La soluzione nasce dall'analisi delle funzionalità di ogni singola componente del sistema
Non ₩ possibile utilizzare controlli generici per qualsiasi tipo di sistema
Documentazione Adeguata + Comprensione del Sistema = Maggiore Efficienza + Facilità di Manutenzione + Sicurezza
Software Engineering: Pro
Concentrazione sugli aspetti tecnici del sistema
Flessibilità: ₩ possibile applicare questi metodi sia a sistemi complessi che a sistemi semplici
Efficienza: non ₩ necessario perdere tempo nella consultazione di checklist per scartare controlli che non sono necessari
Buona documentazione, facile manutenzione
Molto adatto per sistemi informatici complessi e di grandi dimensioni in cui la modifica di una componente influenza tutto il sistema
Software Engineering: Contro
Necessità di un “super-analista” o di un “security team”
Risultati poco soddisfacenti su sistemi già esistenti:
Perdita di alcune features del sistema “Distruzione” del sistema
Il coinvolgimento degli utenti durante la fase di progettazione e analisi dei requisiti di sicurezza porta a sovrastimare i punti deboli del sistema (Farquar 1991)
Metodi Logico – Formali: Caratteristiche
Astrazione dei problemi di sicurezza - Astrazione delle soluzioni
Approccio top-down Assunzioni:
La soluzione può essere creata solo da una conoscenza globale del sistema: l'astrazione ₩ la via maestra
Le soluzioni progettate sull'astrazione dei problemi di sicurezza sono molto più generali e quindi più flessibili e durature nel tempo
L'implementazione dei controlli deve essere eseguita su misura per ogni sistema con cui si ha a che fare
Metodi Logico – Formali: Pro
Flessibilità nelle strutture di controllo
Indipendenza dall'evoluzione della tecnologia
Buona documentazione
Tutto questo porta a... Facilità di manutenzione Riduzione dei costi
Minor conflittualità tra sicurezza e grado di usabilità del sistema informatico
Metodi Logico – Formali: Contro
Difficoltà nella descrizione astratta di problemi, controlli e soluzioni
Difficoltà nel passare dalla soluzione astratta ai dettagli implementativi
Difficoltà nell'integrare le componenti logiche e fisiche di un sistema sicuro
Molto difficile l'applicazione di tali metodi a sistemi già esistenti
Assenza di tool e procedure automatiche
Codice Robusto
A seconda del livello di dettaglio ₩ necessario considerare diverse problematiche e diverse strategie di soluzione
Un software corretto e robusto presenta un numero minore di malfunzionamenti che potrebbero essere sfruttati dai malintenzionati
Vana ₩ la sicurezza senza la robustezza: stack smashing & strcpy
Protocolli: Tipologie di Attacco
Ascolto passivo del canale di comunicazione
Ascolto attivo del canale di comunicazione (modifica delle informazioni che passano attraverso il canale)
Impersonificazione di un capo della comunicazione
Protocolli: Punti Deboli
Dimensioni variabili dei dati trasferiti: Possibilità di attacchi alla “buffer overrun” Esempio: protocollo HTTP, funzione GET
Scelta degli ID di sessione: Lo spazio dei valori possibili deve essere di
dimensioni adeguate
Cheating: la possibilità da parte di un client di collegarsi leggitimamente, ma di sfruttare alcuni difetti del protocollo per ottenere dei vantaggi
Protocolli: Esempi Famosi
Syslog Spoofing dei pacchetti DoS Timestamping non affidabile
DNS [RFC 1034, RFC 1035] Problemi nella gestione degli ID nell'implementazione
di Bind di Microsoft Windows
Progettazione di Protocolli: Hints
Controllare l'integrità dei dati trasmessi Time Stamping
Arbitrated protocols: time stamping authority (TSA) Indipendenza dal supporto fisico Impossibilità di apportare modifiche dopo l'autenticazione Impossibilità di modificare la data di autenticazione
Generazioni di sequenze pseudo-casuali Sequenze numeriche sufficientemente lunghe che
possano considerarsi casuali Sequenze numeriche impredicibili
Progettazione di Protocolli: Integrità dei Dati
A BM, h(M,K)
Una soluzione semplice ₩ l'utilizzo di una funzione di hashing MAC/DAC (Message/Data Authentication Codes)
Se non si sceglie K e h in modo opportuno si rischia di compromettere seriamente questo protocollo
Un altro difetto ₩ che A e B devono conoscere K, quindi ₩ necessaria la presenza di un canale sicuro
IPv6: Obiettivi
Supporto di miliardi di host
Riduzione tabelle di routing
Semplificazione del protocollo & maggiore velocità trasferimento pacchetti
Maggiore sicurezza (autenticazione e privacy)
Servizi in tempo reale
Semplificazione multicasting
Coesistenza con IPv4
IPv6: Preambolo Principale
Priorità: 0-7 pacchetti che possono rallentare; 8-15 traffico in tempo reale
Flow Label (sperimentale): pseudoconnessione sorgente-destinazione
Payload: non include la lunghezza del preambolo
IPv6 vs. IPv4
Non ₩ presente il campo IHL perch₫ il preambolo di IPv6 ha dimensione fissa
Il campo protocol ₩ stato eliminato in quanto il campo Next Header descrive il tipo di dati che segue l'ultimo preambolo IP (per esempio TCP)
Tutti i campi relativi alla frammentazione sono stati eliminati
La dimensione minima del pacchetto IPv6 ₩ di 576 byte
Checksum non presente
IPv6: Extension Headers
IPv6 Header (obbligatorio)
Hop-by-hop Header Destination Option
Header (intermedi) Routing Header
Fragmentation Header Authentication Header Encapsulating Security
Payload Header Destination Options
Header (destinazione)
IPv6: Authentication Header (AH)
A e B devono accordarsi su una o più chiavi segrete che solo loro conoscono
A ogni chiave ₩ associato un codice a 32 bit univoco (campo SPI)
Ogni chiave ha un time stamp
Authentication data: checksum di MD5
IPv6: AH How To (Mitt.)
Costruzione pacchetti IP completo Azzeramento campi variabili (Hop Limit) Padding della chiave e del pacchetto fino a
raggiungere un multiplo di 16 byte (separatamente) Calcolo della checksum della chiave + pacchetto +
chiave L'algoritmo utilizzato per il calcolo della checksum
₩ deciso dagli utenti; quello di default ₩ MD5
IPv6: AH How To (Dest.)
Dal numero di chiave (campo SPI) risale alla chiave Padding della chiave e del pacchetto fino a
raggiungere un multiplo di 16 byte (separatamente) Calcolo della checksum della chiave + pacchetto (in
cui sono stati azzerati i campi variabili) + chiave Confronto delle checksum Nota: i dati sono spediti in chiaro.
IPv6: Encapsulated Security Payload (ESP)
SPI: numero di chiave a 32 bit Algoritmo crittografico: ₩ a
scelta del mittente e del destinatario
Se si utilizza DES-CBC (default):
Payload Data inizia con un vettore di inizializzazione di lungheza multipla di 4 byte
I dati crittografati sono completati a un multiplo di 8 byte
IPv6: ESP Note
Se si utilizza DES-CBC il vettore di inizializzazione ₩ trasmesso in chiaro: questo approccio non ₩ dei più sicuri, ma per gli obiettivi che si propone IPv6 ₩ accettabile
È possibile combinare AH e ESP: ESP prima di AH
Transport mode ESP Tunnel mode ESP
AH prima di ESP (solo tunnel mode): AH ₩ protetto da ESP quindi ₩ più difficile modificare il
messaggio
Bibliografia
Richard Baskerville, “Information System Security Design Methods: Implications for Information Systems Development” - Acm Computing Surveys, Volume 25 Number 4 December 1993
Andrew Stuart Tanenbaum, “Reti di Computer” – Capitolo 5 “Il livello di rete in Internet”, Ed. Italiana 1998
William Stallings, “IPv6: The New Internet Protocol”, First published in IEEE Communications Magazine, July 1996, Volume 34, Number 7
IEEE Communication Society: www.comsoc.org
Antonio Cisternino, “Sicurezza e Robustezza” – DEV, Novembre 2000 N. 79
Alfonso De Gregorio, “Protocolli applicativi: le vulnerabilità più ricorrenti”, “Progettazione di protocolli sicuri” – DEV, Novembre 2000 N. 79
T. A. Linden, “Operating System Structure to Support Security and Reliable Software” – U.S Departement of Commerce / National Bureau of Standards NBS Technical Note 919 August 1976
Informazioni varie sul mondo dell'informatica: www.manuali.net
The UK ITSEC scheme: www.itsec.gov.uk