Progetto Sicurezza Codice Corretto – Codice Robusto: Metodi formali per la progettazione di codice sicuro Checklist IS Metodi Logico Formali Protocolli:

Presentazione sul tema: "Progetto Sicurezza Codice Corretto – Codice Robusto: Metodi formali per la progettazione di codice sicuro Checklist IS Metodi Logico Formali Protocolli:"— Transcript della presentazione:

1 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

2 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

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

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

5 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

6 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

7 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

8 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

9 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

10 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

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

12 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

13 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

14 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

15 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

16 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

17 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

18 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

19 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

20 Progettazione di Protocolli: Integrità dei Dati AB M, 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

21 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

22 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

23 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

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

25 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

26 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

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

28 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

29 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

30 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.orgwww.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.netwww.manuali.net The UK ITSEC scheme: www.itsec.gov.ukwww.itsec.gov.uk