Presentazione del WP2 Antonio Lioy ( lioy@polito.it ) CISI ‘09 Presentazione del WP2 Antonio Lioy ( lioy@polito.it ) Marco Vallini ( marco.vallini@polito.it ) Politecnico di Torino Dip. Automatica e Informatica (Roma, 12-13 Giugno 2013)

Agenda obiettivi del WP partner coinvolti timetable CISIS ‘09 Agenda obiettivi del WP partner coinvolti timetable proposte/idee di ciascun partner possibili collaborazioni

Obiettivi del WP analisi dei requisiti ed attacchi da WP1 CISIS ‘09 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

Partner coinvolti (1) POLITO (Leader) UNIFI, CNR UNINA CISIS ‘09 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à power grid (UNIFI e CNR) infrastrutture di trasporto (UNINA)

Partner coinvolti (2) CIS-UNIROMA UNIPI: CISIS ‘09 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

CISIS ‘09 Timetable

Timetable dal mese 6 al 36 D2a: consegna entro il mese 18 CISIS ‘09 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 metodologia generica completamento dei modelli di interdipendenza

CISI ‘09 POLITO

Obiettivi modelli security-oriented per sistemi IT CISIS ‘09 Obiettivi modelli security-oriented per sistemi IT componenti specifici di IC linguaggi per esprimere politiche di sicurezza requisiti sicurezza da WP1 focus su progettazione automatica analisi di sicurezza gestione/verifica comportamento di una IC analisi configurazione dei controlli di sicurezza

Modelli security-oriented per sistemi IT CISIS ‘09 Modelli security-oriented per sistemi IT modelli generali per: nodi servizi e capability topologia di rete modelli specifici 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 altri modelli?

Linguaggi per esprimere policy di sicurezza CISIS ‘09 Linguaggi per esprimere policy di sicurezza autenticazione/autorizzazione reachability livello rete quali host possono raggiungere quali host/servizi? modello classico utenti e privilegi per una risorsa modelli specifici per IC PolyOrBAC? protezione traffico protezione di canale protezione di messaggio alcuni modelli disponibili sviluppati in progetto UE POSECCO

Analisi sicurezza determinazione vulnerabilità sistema CISIS ‘09 Analisi sicurezza determinazione vulnerabilità sistema vulnerabilità componenti IT uso di database specifici già disponibili vulnerabilità componenti specifici IC esistono database o altre fonti? determinazione del rischio reale definendo opportune metriche per IC determinazione dello stato del sistema in modo statico in modo dinamico: a runtime eventi accaduti nel sistema, interazione tra componenti e sistemi diversi

Analisi sicurezza – MulVAL (1) CISIS ‘09 Analisi sicurezza – MulVAL (1) framework open source per analisi di sicurezza sfrutta database di vulnerabilità esistenti (es. NVD, CVSS) usa strumenti di analisi (es. OVAL), produce attack graph usa Datalog, linguaggio per specificare bug, descrivere configurazione sistema, permessi/privilegi reasoning rule (possibile definire nuove regole) adotta reasoning engine effettua analisi (db vulnerabilità + dati specificati dall’utente)

Analisi sicurezza – MulVAL (2) CISIS ‘09 Analisi sicurezza – MulVAL (2) Fonte: MulVAL Attack Paths Engine – User and Programmer Guide

Analisi sicurezza – estensione di MulVAL CISIS ‘09 Analisi sicurezza – estensione di MulVAL 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

Analisi configurazioni e controlli di sicurezza CISIS ‘09 Analisi configurazioni e controlli di sicurezza 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?

CISI ‘09 UNIFI, CNR

CISI ‘09 UNINA

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

V&V Effort Distribution CISIS ‘09 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

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

Attack modeling and prevention CISIS ‘09 Attack modeling and prevention Is there a real chance to fully secure a SCADA system? the Stuxnet worm 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)

Security-aware embedded software development Study specific challenges of embedded environments Development of suitable approaches to derive threats models 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 traditional sw domain Apply the above approaches to the TENACE case-study: transportation critical infrastructure and related components

Experimental evaluation of fault/intrusion tolerance CISIS ‘09 Experimental evaluation of fault/intrusion tolerance TODO

CISI ‘09 CIS-UNIROMA

Possibili collaborazioni CISI ‘09 Possibili collaborazioni

Possibili collaborazioni CISIS ‘09 Possibili collaborazioni Prof. Stefan Katzenbeisser – DARMSTADT si occupa di progetto per protezione delle ferrovie in Germania eventuali collaborazioni es. scambio di informazioni

Action point organizzare dei meeting più tecnici per ogni WP CISIS ‘09 Action point organizzare dei meeting più tecnici per ogni WP meeting tecnico ad ottobre? successivamente al meeting di ottobre definire una table of content da discutere information sharing: rendere anonimo in modo distribuito (UNIRC)

Domande? Grazie per l’attenzione!