La presentazione è in caricamento. Aspetta per favore

La presentazione è in caricamento. Aspetta per favore

Presentazione del WP2 Antonio Lioy ( ) Marco Vallini ( ) Politecnico di Torino Dip. Automatica e Informatica (Roma,

Presentazioni simili


Presentazione sul tema: "Presentazione del WP2 Antonio Lioy ( ) Marco Vallini ( ) Politecnico di Torino Dip. Automatica e Informatica (Roma,"— Transcript della presentazione:

1 Presentazione del WP2 Antonio Lioy ( ) Marco Vallini ( ) Politecnico di Torino Dip. Automatica e Informatica (Roma, Giugno 2013)

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 dellinfrastruttura – 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à – power grid (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 – 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

8 POLITO

9 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

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

11 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

12 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

13 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 dallutente)

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

15 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

16 Analisi configurazioni e controlli di sicurezza – control equivalence es. il regolamento richiede di utilizzare le password per lautenticazione 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 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

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 linsieme migliore di caratteristiche che verificano lipotesi – Usarle per predire tale probabilità nei moduli sotto test – Allocare risorse in base alla predizione

21 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 predittivi 5.Quinta Fase: definizione indici di vulnerabilità. Definizione di strategie di allocazione delleffort di security V&V basata sulla predizione

22 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 Intl Conference on Dependable Systems and Networks (DSN 2013)

23 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

24 Experimental evaluation of fault/intrusion tolerance – TODO

25 CIS-UNIROMA

26 Possibili collaborazioni

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

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

29 Domande? Grazie per lattenzione!


Scaricare ppt "Presentazione del WP2 Antonio Lioy ( ) Marco Vallini ( ) Politecnico di Torino Dip. Automatica e Informatica (Roma,"

Presentazioni simili


Annunci Google