Post on 16-Jan-2016
description
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!