Progetto Sicurezza Codice Corretto – Codice Robusto: Metodi formali per la progettazione di codice...

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