Presentazione del WP2
Antonio Lioy ( [email protected] )
Marco Vallini ( [email protected] )
Politecnico di Torino
Dip. 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 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
?
System logs,
network traces, ...
Detector
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-. Processlevel) potenzialmente correlate con la presenza di
vulnerabilità.
4. Quarta Fase: selezione di modelli predittivi
5. 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)
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
– 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!