Successfully reported this slideshow.
UNIVERSITÀ DEGLI STUDI DI TRIESTE                             FACOLTÀ DI INGEGNERIA                   Corso di laurea magi...
Contesto preesistente                            Analisi delle vulnerabilità●   Software di analisi delle vulnerabilità in...
Contesto preesistente                            Base di conoscenza●   Schemi da ricercare    ●   spesso con espressioni r...
Contesto preesistente                                    Problemi●   Aggiornamento manuale, difficilmente automatizzabile●...
Obiettivo●   Diminuire la probabilità di errori di aggiornamento●   Strumenti:    ●   campagna di test per validare i nuov...
PARTE PRIMACampagna di test                   6
client                                server                                               Vulnerabilità di app. remote   ...
Vulnerabilità di applicazioni remote                                 Analisi di vulnerabilità●   In pratica, nellanalisi d...
Tipi di test●   Tutti i test riguardano le vulnerabilità di applicazioni remote                                        nel...
Test di integrazione                                       nellanalisi di vulnerabilità●   Solo in alcuni casi noti●   Si ...
Test di integrazione                                  Problematiche●   È necessario riprodurre in locale lo scenario vulne...
lato server                            12lato client
Analisi specifica●   In generale, legame complesso tra risposta e vulnerabilità●   Spesso una vulnerabilità riguarda solta...
Test specifici●   In tre ambiti: banner, contenuto pagina web, numeri di versione●   Per banner e pagine web, si testa lan...
Test specifici                                Test su singoli sistemi●   Si attiva lanalisi di vulnerabilità su alcuni sis...
Test specifici                           Test di coerenza interna XML●   Si analizza ciascun file XML●   Obiettivo ideale:...
Base di conoscenza                                File XML per banner e pagine web         ●   La base di conoscenza è for...
Base di conoscenza                             File XML per numeri di versione     ●   La base di conoscenza è formata da ...
Test specificiTest di coerenza interna XML                               19
Test-driven development●   Ciclo continuo di sviluppo e test:     ●   eventuali errori nella codifica sono individuabili s...
PARTE SECONDAGenerazione di espressioni regolari                                      21
Problema ●       Test precedenti:         ●   la coerenza di unespressione regolare con un commento lascia             tro...
Soluzione ●       Strumento di generazione automatica ●       Aiuto nei nuovi inserimenti                                 ...
Soluzione●   Il risultato:     ●   deve essere conforme a tutte le stringhe di esempio                                    ...
Soluzione     ●   deve riflettere le caratteristiche delle stringhe di esempio                                            ...
Tipi di soluzione●   Gerarchia di tipologie, a livelli successivi di specificità●   cws – common word solution     ●   Rip...
Tipi di soluzione●    ftscw – frequent token solution from cws    ●   .* sostituiti con sottostringhe frequenti●   Si defi...
Tipi di soluzione●   ps – pattern solution    ●   .* sostituiti con sequenze di pattern    ●   Esempio: .* → w+s+w+●    ft...
Workflow                                 Problematiche principali●   Sottosequenza comune più lunga    ●   Per trovare lo ...
Test-driven development●   Per il generatore limplementazione parte da zero●   ≈ ogni funzione ha un proprio file di test●...
PARTE TERZA Conclusioni               31
Conclusioni                                     Campagna di test●   Errori accidentali meno probabili●   Si sono considera...
Conclusioni                        Generatore di espressioni regolari●   In generale, valutare le prestazioni è complesso ...
Upcoming SlideShare
Loading in …5
×

Slide - Tecniche di Test-driven development in ambito sicurezza informatica e rilevazione vulnerabilità

583 views

Published on

  • Be the first to comment

  • Be the first to like this

Slide - Tecniche di Test-driven development in ambito sicurezza informatica e rilevazione vulnerabilità

  1. 1. UNIVERSITÀ DEGLI STUDI DI TRIESTE FACOLTÀ DI INGEGNERIA Corso di laurea magistrale in Ingegneria Informatica Tecniche di Test-driven development in ambito sicurezza informatica e rilevazione vulnerabilitàLaureando RelatoreFederico Cecutti chiar.mo prof. Alberto Bartoli Correlatore Enrico Milanese anno accademico 2011/2012
  2. 2. Contesto preesistente Analisi delle vulnerabilità● Software di analisi delle vulnerabilità informatiche● Vulnerabilità di applicazioni remote● Rilevate interagendo con il servizio remoto ● analisi della prima risposta (banner) ● analisi di contenuti di pagina web ● analisi dei numeri di versione 2
  3. 3. Contesto preesistente Base di conoscenza● Schemi da ricercare ● spesso con espressioni regolari Base di conoscenza● Dati da inviare Continuamente nuove minacce aggiornamento continuo 3
  4. 4. Contesto preesistente Problemi● Aggiornamento manuale, difficilmente automatizzabile● Eventuali errori di aggiornamento hanno conseguenze gravissime: ● non si rileva una vulnerabilità presente ● si dichiara vulnerabile una situazione corretta● Possono esserci conseguenze molto tempo dopo laggiornamento● Espressioni regolari spesso complesse● Errori per nulla evidenti 4
  5. 5. Obiettivo● Diminuire la probabilità di errori di aggiornamento● Strumenti: ● campagna di test per validare i nuovi inserimenti PRIMA FASE DI LAVORO ● generatore di espressioni regolari da esempi SECONDA FASE DI LAVORO● Vincoli: Python 2.4.1, sviluppo test-driven 5
  6. 6. PARTE PRIMACampagna di test 6
  7. 7. client server Vulnerabilità di app. remote Scenario di base Handshake: Apertura della connessione (richiesta del client) ATTORI ● Client (C) e server (S) ● C: conosce la situazione vulnerabile ● C: vuole verificare se il server è vulnerabile r anne n e il b c onti e INTERAZIONE ● C: invia richiesta che scatena lo scenario vulnerabile Handshake:Chiusura della connessione ● S: risponde, rendendo evidente la sua vulnerabilità ● C: ha scoperto che il server è vulnerabile 7
  8. 8. Vulnerabilità di applicazioni remote Analisi di vulnerabilità● In pratica, nellanalisi di vulnerabilità: ● una situazione del genere per ogni vulnerabilità nota ● il client è il sistema di analisi di vulnerabilità ● per ogni vulnerabilità individuata, si memorizzano alcune informazioni rilevanti 8
  9. 9. Tipi di test● Tutti i test riguardano le vulnerabilità di applicazioni remote nellanalisi di vulnerabilità● Due livelli di test: ● Test di integrazione: riproducono linterazione tra gli endpoint ● Test specifici: si limitano ad analizzare un aspetto della risposta● Ogni futuro aggiornamento della base di conoscenza sarà test-driven 9
  10. 10. Test di integrazione nellanalisi di vulnerabilità● Solo in alcuni casi noti● Si testa la corretta individuazione di queste informazioni● Si valida la logica aziendale di rilevazione delle vulnerabilità 10
  11. 11. Test di integrazione Problematiche● È necessario riprodurre in locale lo scenario vulnerabile● Il test deve utilizzare un simulatore del server: ● deve restare in attesa di connessioni dai client ● deve rispondere ai client come un endpoint vulnerabile● Lato client, si utilizza la funzione del sistema di analisi di vulnerabilità● Ma: la funzione utilizza degli oggetti per riportare le vulnerabilità trovate ● necessari oggetti mock con la stessa interfaccia di quelli reali 11
  12. 12. lato server 12lato client
  13. 13. Analisi specifica● In generale, legame complesso tra risposta e vulnerabilità● Spesso una vulnerabilità riguarda soltanto nodi o software con certe caratteristiche● Spesso, fase preliminare di analisi delle caratteristiche ● output: un dizionario consuntivo per ogni endpoint analizzato● Le vulnerabilità sono scoperte in base alle caratteristiche rilevate 13
  14. 14. Test specifici● In tre ambiti: banner, contenuto pagina web, numeri di versione● Per banner e pagine web, si testa lanalisi delle caratteristiche● Alcuni test su singoli sistemi ● verificano la corretta individuazione delle caratteristiche/vulnerabilità● Altri test applicati a tutti i file della base di conoscenza ● verificano la coerenza interna dei file 14
  15. 15. Test specifici Test su singoli sistemi● Si attiva lanalisi di vulnerabilità su alcuni sistemi di interesse● Per banner e pagine web: ● si verifica che il dizionario consuntivo contenga chiavi e valori attesi● Per numeri di versione: ● si testano i casi limite delle espressioni regolari ● asserzioni positive dentro ai range e negative fuori 15
  16. 16. Test specifici Test di coerenza interna XML● Si analizza ciascun file XML● Obiettivo ideale: garantire assenza di alterazioni accidentali e ripetizioni● In pratica: ● Test di correttezza sintattica ● Test di coerenza tra parti 16
  17. 17. Base di conoscenza File XML per banner e pagine web ● La base di conoscenza è formata da file XML con questa struttura: esempio filtro (unico)blocco caratteristica caratteristica input esempio filtro (unico) outputblocco caratteristica funzionamento 17
  18. 18. Base di conoscenza File XML per numeri di versione ● La base di conoscenza è formata da file XML con questa struttura:blocco filtri input 7.0.0blocco filtri Rileva la 18272 e la 18395 output funzionamento 18
  19. 19. Test specificiTest di coerenza interna XML 19
  20. 20. Test-driven development● Ciclo continuo di sviluppo e test: ● eventuali errori nella codifica sono individuabili subito● Strategie per sviluppare i test: ● per stesure successive ● con segnaposto: pass, TestCase.fail ● schema assertivo: pochi metodi, standardizzazione dei messaggi 20
  21. 21. PARTE SECONDAGenerazione di espressioni regolari 21
  22. 22. Problema ● Test precedenti: ● la coerenza di unespressione regolare con un commento lascia troppi gradi di libertà esempioblocco filtro (unico) caratteristica ● Espressioni regolari spesso complesse ● Espressioni regolari inserite a mano 22
  23. 23. Soluzione ● Strumento di generazione automatica ● Aiuto nei nuovi inserimenti esempioblocco filtro (unico) esempi (INPUT) espressione regolare (OUTPUT) 23
  24. 24. Soluzione● Il risultato: ● deve essere conforme a tutte le stringhe di esempio FACILE ● deve riflettere le caratteristiche delle stringhe di esempio DIFFICILE esempi (INPUT) espressione regolare (OUTPUT) 24
  25. 25. Soluzione ● deve riflettere le caratteristiche delle stringhe di esempio DIFFICILE● In pratica: ● si analizza la struttura delle espressioni regolari già presenti ● si generano poche tipologie di soluzioni, simili a quelle presenti ● si lasciano molte scelte alloperatore – in base a considerazioni semantiche, complementari alla struttura delle stringhe 25
  26. 26. Tipi di soluzione● Gerarchia di tipologie, a livelli successivi di specificità● cws – common word solution ● Riporta le parole comuni a tutte le stringhe ● Tra di esse, pattern generico .* ● Esempio: ^.*(?<!w)Print(?!w).*(?<!w)Server(?!w).*$● Nei due tipi di soluzione derivati si riscrivono i .* di cws 26
  27. 27. Tipi di soluzione● ftscw – frequent token solution from cws ● .* sostituiti con sottostringhe frequenti● Si definiscono 4 tipologie di pattern: ● S (spaziature): s+ ● D (cifre): d+ ● W (parola): w+ ● P (punteggiatura): [^sw]+● Ogni stringa è conforme a una sequenza di questi 27
  28. 28. Tipi di soluzione● ps – pattern solution ● .* sostituiti con sequenze di pattern ● Esempio: .* → w+s+w+● ftsp – frequent token solution from ps ● Ogni pattern di ps è sostituito con le sottostringhe frequenti ● Esempio: w+s+w+ → (?:Server|Service|w+) w+ 28
  29. 29. Workflow Problematiche principali● Sottosequenza comune più lunga ● Per trovare lo scheletro di parole comuni a tutte le stringhe ● Risolto con un adattamento dellalgoritmo di Hunt-McIlroy● Corrispondenza ● Le stringhe potrebbero contenere varie occorrenze delle parti comuni ● Quali delle occorrenze sono strutturalmente affini? ● Risolto con un algoritmo progettato ad hoc● Espressione regolare per il singolo pattern ● Per generalizzare parti diverse in corrispondenza ● Risolto con un algoritmo progettato ad hoc 29
  30. 30. Test-driven development● Per il generatore limplementazione parte da zero● ≈ ogni funzione ha un proprio file di test● La codifica di ogni funzionalità è preceduta da quella dei relativi test● Grandi vantaggi: ● errori scopribili subito ● moduli piccoli e semplici ● immediata disponibilità di esempi corretti 30
  31. 31. PARTE TERZA Conclusioni 31
  32. 32. Conclusioni Campagna di test● Errori accidentali meno probabili● Si sono considerati gli errori più tipici● Molti errori dipendono dal significato dei dati dati dimensionali● Allattivazione dei test: ● 104 espressioni regolari scorrette su 1492 analizzate → ca. 6,97% ● soprattutto imprecisioni poco rilevanti ● spesso . invece di .● Possibile misura di valore: rapporto regex modificate / regex totali● Si ipotizza incidenza degli errori tempo-invariante 32
  33. 33. Conclusioni Generatore di espressioni regolari● In generale, valutare le prestazioni è complesso ● troppe variabili da considerare ● molte variabili sono difficili da misurare (ad es. la genericità)● Operatività possibile grazie allintroduzione di schemi per la soluzione● Situazione migliorata per loperatore dati dimensionali● Lavoro svolto già incluso nelloperatività aziendale 33

×