Presentazione del WP2

Antonio Lioy ( lioy@polito.it )Marco Vallini ( marco.vallini@polito.it )

Politecnico di TorinoDip. Automatica e Informatica

(Roma, 12-13 Giugno 2013)

Agenda

– obiettivi del WP– partner coinvolti– timetable– proposte/idee di ciascun partner– possibili collaborazioni

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

Timetable

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

POLITO

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

– 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

– 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• 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)

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

Fonte: MulVAL Attack Paths Engine – User and Programmer Guide

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

– 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?

UNIFI, CNR

UNINA

• 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

Target system

Simulated faults / attacks

System logs,network traces, ...

Detector?

Experimental evaluation of fault/intrusion tolerance

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

1. Prima Fase: caratterizzazione qualitativa delle vulnerabilità nel codice (viste come guasti software)– Mapping con schemi di classificazione di guasti

2. Seconda Fase: caratterizzazione quantitativa– Distribuzione relativa di vari tipi di vulnerabilità nel software

3. Terza Fase: definizione e selezione di metriche del software (method-, class-, file-, component-. Process-level) potenzialmente correlate con la presenza di vulnerabilità.

4. Quarta Fase: selezione di modelli predittivi5. Quinta Fase: definizione indici di vulnerabilità. Definizione

di strategie di allocazione dell’effort di security V&V basata sulla predizione

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)

• 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

Security-aware embedded software development

Experimental evaluation of fault/intrusion tolerance

– TODO

CIS-UNIROMA

Possibili collaborazioni

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