Presentazione del WP2

1. Presentazione del WP2 Antonio Lioy ( lioy@polito.it ) Marco Vallini ( marco.vallini@polito.it ) Politecnico di TorinoDip. Automatica e Informatica (Roma, 12-13 Giugno2013)

2. Agenda • obiettivi del WP • partner coinvolti • timetable • proposte/idee di ciascun partner • possibili collaborazioni

3. Obiettivi del WP • analisi dei requisiti ed attacchi da WP1 • definizione di politiche formali di sicurezza • metodologie per valutare il livello di resiliency • specifiche per IC • generali • definizione di modelli di interdipendenza • relazioni tra componenti dell’infrastruttura • per identificare vulnerabilità • sviluppo framework per valutare • soluzioni di protezione e sicurezza proposte in WP3/WP4

4. Partner coinvolti (1) • POLITO (Leader) • definire politiche formali di sicurezza per la progettazione automatica • gestione e la verifica del comportamento delle IC • UNIFI, CNR • modellazione ed analisi delle interdipendenze tra IC • UNINA • modelli per il miglioramento delle strategie di prevenzione attraverso la previsione di guasti/vulnerabilità • powergrid (UNIFI e CNR) • infrastrutture di trasporto (UNINA)

5. Partner coinvolti (2) • CIS-UNIROMA • integrazione attività degli altri partner • problemi di sicurezza specifici dell'ambiente finanziario • contributo per la definizione di un framework generico • metodologie information sharing • orizzontale (diverse infrastrutture) • UNIPI: • todo

6. Timetable

7. Timetable • dal mese 6 al 36 • D2a: consegna entro il mese 18 • metodologie definite per ogni specifica IC • lavoro preliminare sui modelli di interdipendenza • D2b: consegna entro il mese 36 • metodologiagenerica • completamento dei modelli di interdipendenza

8. POLITO

9. Obiettivi • modelli security-oriented per sistemi IT • componentispecificidi IC • linguaggi per esprimerepolitichedisicurezza • requisitisicurezzada WP1 • focus suprogettazioneautomatica • analisidisicurezza • gestione/verificacomportamentodiuna IC • analisiconfigurazionedeicontrollidisicurezza

10. Modelli security-oriented per sistemi IT • modelligenerali per: • nodi • servizi e capability • topologiadirete • modellispecifici per componenti IC • asset IC • sensori, attuatori, … • stato? • modello POLITO (System Description Language) • sviluppato in progetti UE POSITIF e DESEREC • estendere SDL per componenti IC • altrimodelli?

11. Linguaggi per esprimere policy disicurezza • autenticazione/autorizzazione • reachabilitylivellorete • quali host possonoraggiungerequali host/servizi? • modelloclassico • utenti e privilegi per unarisorsa • modellispecifici per IC • PolyOrBAC? • protezionetraffico • protezionedicanale • protezionedimessaggio • alcunimodellidisponibilisviluppati in progetto UE POSECCO

12. Analisisicurezza • determinazionevulnerabilitàsistema • vulnerabilitàcomponenti IT • usodi database specificigiàdisponibili • vulnerabilitàcomponentispecifici IC • esistono database o altrefonti? • determinazione del rischioreale • definendo opportune metriche per IC • determinazionedellostato del sistema • in modostatico • in mododinamico: a runtime • eventiaccadutinelsistema, interazionetracomponenti e sistemidiversi

13. Analisisicurezza – MulVAL (1) • framework open source per analisi di sicurezza • sfrutta database di vulnerabilità esistenti (es. NVD, CVSS) • usa strumenti di analisi (es. OVAL), produce attackgraph • usa Datalog, linguaggio per • specificare bug, descrivere configurazione sistema, permessi/privilegi • reasoningrule (possibile definire nuove regole) • adotta reasoningengine • effettua analisi (db vulnerabilità + dati specificati dall’utente)

14. Analisisicurezza – MulVAL (2) Fonte: MulVAL Attack Paths Engine – User and Programmer Guide

15. Analisisicurezza – estensionediMulVAL • aggiungere supporto per componenti IC • sensori, attuatori, … • modellazione ed integrazione rischi reali • generali per IT • specifici per IC • definizione di regole specifiche per attacchi ad IC • sfruttando il linguaggio esistente (DATALOG) • integrazione delle vulnerabilità specifiche per IC • sfruttando modelli simili a quelli per IT

16. Analisiconfigurazioni e controllidisicurezza • control equivalence • es. il regolamento richiede di utilizzare le password per l’autenticazione degli utenti ed il meccanismo configurato adotta i certificati digitali, possiamo considerarlo equivalente? • non-enforceability/partial-enforceability • controlli insufficienti: es. installare regole relative al metodo GET (protocollo HTTP) in dispositivi che non supportano L7 filtering • … oppure non disponibili (configurabili/installati): es. configurazione di un controllo gestita da terza parte • soluzioni: spostare la risorsa? Installare nuovi controlli? … • richiede utilizzo di best-practice e strategie • disponibilità? • definizione/estensione?

17. UNIFI, CNR

18. UNINA

19. Experimental evaluation of fault/intrusion tolerance • Experimental fault tolerance evaluation • Injection of invalid inputs and faults in software systems • Incorrect inputs from users/external systems, faulty hardware/software components, ... • Experimental intrusion tolerance evaluation • Injection of code to force a malicious behavior of software processes in a given CI under evaluation • Forcing accesses to system files, data transmission to external hosts, attacks to other processes in the CI, ... • The goal is to systematically test the effectiveness of IDSs ? Simulated faults / attacks Target system Detector System logs, network traces, ...

20. V&V Effort Distribution • Obiettivo: ridurrei costi delle attività di V&V dedicate a migliorare la sicurezza (ad es. analisi statica/dinamica del codice, vulnerability/penetration test) • Dedicare maggiore effort di V&V a moduli che più probabilmente contengono vulnerabilità • Strategia di distribuzione delle risorse di V&V basata sulla predizione del grado di vulnerabilità in diversi moduli SW • Congettura: la probabilità che un modulo software abbia vulnerabilità nel codice dipende dalle caratteristiche del modulo e/o del suo processo di sviluppo • Strategia: • Identificare l’insieme migliore di caratteristiche che verificano l’ipotesi • Usarle per predire tale probabilità nei moduli sotto test • Allocare risorse in base alla predizione

21. V&V Effort Distribution: steps • Prima Fase: caratterizzazione qualitativa delle vulnerabilità nel codice (viste come guasti software) • Mapping con schemi di classificazione di guasti • Seconda Fase: caratterizzazione quantitativa • Distribuzione relativa di vari tipi di vulnerabilità nel software • Terza Fase: definizione e selezione di metriche del software (method-, class-, file-, component-. Process-level) potenzialmente correlate con la presenza di vulnerabilità. • Quarta Fase: selezione di modelli predittivi • Quinta Fase: definizione indici di vulnerabilità. Definizione di strategie di allocazione dell’effort di security V&V basata sulla predizione

22. Attack modeling and prevention • Is there a real chance to fully secure a SCADA system? • the Stuxnetworm emphasizes the strong technical advances achieved by the attackers’ community • Diversity can be leveraged to secure a SCADA system*. D.Cotroneo, A.Pecchia, S.Russo, “Towards secure monitoring and control systems: diversify!” Suppl. Proceedings of the Int’l Conference on Dependable Systems and Networks (DSN 2013)

23. Security-aware embedded software development • Studyspecificchallenges of embeddedenvironments • Development of suitableapproaches to derivethreatsmodels • consider the events that would impact the Confidentiality, Integrity, or Availability of each asset (CIA method) • define suitable attack trees and exploit them to identify vulnerabilities systematically • Propose novel approaches to automate some parts of the above process • static, automated source code analysis (SCA) • penetration tests • borrow and adapt approaches from the traditionalsw domain • Apply the above approaches to the TENACE case-study: • transportation critical infrastructure and related components

24. Experimental evaluation of fault/intrusion tolerance • TODO

25. CIS-UNIROMA

26. Possibilicollaborazioni

27. Possibilicollaborazioni • Prof. Stefan Katzenbeisser – DARMSTADT • si occupa di progetto per protezione delle ferrovie in Germania • eventuali collaborazioni • es. scambio di informazioni

28. Action point • organizzaredei meeting piùtecnici per ogni WP • meeting tecnico ad ottobre? • successivamente al meeting diottobredefinireuna table of content dadiscutere • information sharing: • rendereanonimo in mododistribuito (UNIRC)

29. Domande? Grazie per l’attenzione!