Grand Research Challenges for Cybersecurity of Critical Information and Infrastructures · Grand...

Grand Research Challenges for

Cybersecurity of Critical Information and Infrastructures

Paulo Esteves-VeríssimoUniv. of Luxembourg, FSTC / SnT

[email protected] http://staff.uni.lu/paulo.verissimo

CritiX Lab (Critical and Extreme Security and Dependability)

Distinguished Lectures Series in Cybersecurity, TU Darmstadt, Darmstadt,

May 2018 .

Grand Research Challenges for

Cybersecurity of Critical Information and Infrastructures

Paulo Esteves-VeríssimoUniv. of Luxembourg, FSTC / SnT


CritiX Lab (Critical and Extreme Security and Dependability)

Science of Security Speaker Series, Information Trust Institute, U. Illinois

Urbana/ Champaign, April 2017 .

The world is becoming an immense(interconnected) infrastructure

ISP

ISP

CLOUD COMPUTING AND

COMMUNICATIONS

Internet minute

www.intel.com/.../internet-minute-infographic.html

CritiXresearch

vision

People

Type theory, Programming languages, Proof assistants, Distributed computing

Dr. Vincent Rahli (FR)

Prof. Paulo Esteves-Veríssimo (PT)

Secure and dependable distributed architectures, middleware and algorithms

Dr. Jérémie Decouchant (FR)Distributed systems' performance and fault tolerance, privacy and security, multicore systems, peer-to-peer protocols

Admin. assistant

Natalie Kirf (DE)

Dr. Marcus Völp (DE)Microkernel and microhypervisorOS-level protection, CPS, RTES

Dr. Jiangshan Yu (CN)Design and analysis of crypto protocols, Secure authentication, Post compromise security, Public-ledger applications

Dr. David Kozhaya (LB)Reliable and real-time distributed computing, fault-tolerance in distributed control systems (SCADA/ DCS)

- Critical and Extreme Security and Dependability Research LabResearch enablers for the next generation of protection

• Critical Security and Dependability: – information and infrastructures under advanced

persistent threats• Extreme Computing:

– CSE pushed to the extremes of functional and non-functional properties

• Architecting and designing for resilience: – accidental and malicious faults; protection in an

incremental way; automatic adaptation

Software Defined Networking (SDN)the other face of the problem• ironically, causes of concern lie in SDN's main benefits:

– network programmability and control logic centralization– smaller diversity – new threats that did not exist before or were harder to exploit

[Kreutz et al., ACM HotSDN’13]

Networked Control Systems: no longer closed, proprietary, or dumb

RVRAVR

Feedback Control

FIREWALL Protection

Device

Generator

[Bessani et al., IEEE Sec&Priv Mag.’08]

Chart1

Category 1

Category 2

Category 3

Category 4

Category 5

Category 6

Category 7

Category 8

Category 9

Category 10

Category 11

Category 12

Category 13

Category 14

Category 15

Category 16

Category 17

Category 18

Category 19

Category 20

Category 21

Category 22

Category 23

Category 24

Category 25

Series 1

1.1

1

1.1

1

1.1

1

1.1

0.9

1

1.1

1

2

0.9

1.1

1

0.8

1.2

0.9

1

1.1

1

0.9

1

0.9

1

Sheet1

Series 1

Category 11.1

Category 21

Category 31.1

Category 41

Category 51.1

Category 61

Category 71.1

Category 80.9

Category 91

Category 101.1

Category 111

Category 122

Category 130.9

Category 141.1

Category 151

Category 160.8

Category 171.2

Category 180.9

Category 191

Category 201.1

Category 211

Category 220.9

Category 231

Category 240.9

Category 251

X-by-wire Networked Vehicles: no longer mechanical and isolated

[Lima et al., ACM CPS-SP@CCS’16]

The safety-security gap in vehicle ecosystems

Towards Safe and Secure Autonomous and Cooperative Vehicle Ecosystems. Lima, A; Rocha, F; Volp, M; Verissimo, P. in Proc’s 2nd ACM Workshop on Cyber-Physical Systems Security and Privacy (2016, October) @CCS, Vienna-Austria

Autonomous vehicle ecosystem threat plane

Genomics and Biomedical vs. Big Data

• Next Generation Sequencing dramatically decreased sequencing price

• Amount of data handled will scale up.

• Cloud and big data analytics onto the agenda

Big DataBiomedical

[Verissimo et al., IEEE Sec&Priv Mag.’13]

Privacy- and integrity-preserving data processingThe e-biobanking vision

Alysson Bessani et al., BiobankCloud: a Platform for the Secure Storage, Sharing, and Processing of Large Biomedical Data Sets”, in Proc’s of the 1st Int. Workshop on Data Mgt. and Analytics for Medicine and Healthcare (DMAH 2015), Hawaii, US, Sept. 2015.

http://www.navigators.di.fc.ul.pt/wiki/Publication:Bessani2015biobankcloud-platform

Privacy-preserving (really) distributed DNA alignment!

DNA workflows in an e-biobankingecosystem

19

• Classical DNA workflow does not fit the e-biobanking vision, where data are:• generated and stored in multiple locations• accessible from different locations• processed in distributed way

• (any) DNA workflows must guarantee that DNA data must be protected, with incremental levels according to need, upon:• storage,• computation, • publishing, sharing

Blockchain

• A distributed ledger• Everyone can R/W

• Features (desired…):– Secure: non-changeable history– Available: no single point of failure– Resilient: fault and intrusion tolerant– Transparent: everyone can read– TTP free: no centralised entity to

operate or maintain the ledger.Image source: https://www.catalysts.cc/wp-content/uploads/2017/02/dreamstime_m_83584594.jpg

Blockchain for FinTech and Crypto-currency: challenges• Scalability:

– Currently, the number of records/transactions per second is limited. To makeblockchain useful in financial applications, it is crucial to solve this challenge.

• Security:– Blockchain is vulnerable to attacks such as double spending, selfish mining,

renting, some of which consequence of ambiguous model definitions. We need a more robust and resilient system for critical financial applications.

• Privacy:– Currently, anyone can read the transparent ledger, how to provide user privacy

but still preserve transparency is a key challenge.• Consensus:

– A client can never be guaranteed that a record/transaction is included in theblockchain. Important to provide fast, deterministic, and verifiable guarantees.

Meeting the Challenges ofCritical Dependability and SecurityPEARL project IIS&D - Information Infrastructure Security and DependabilityValue proposal:

CPS infrastruct. and control

Internet and cloud

infrastruct.

Sec&Depof

embedded compon.

Highly sensitive

data privacy and

integrity

Architecting and designing for resilience

• comprehensive approach to those threats,from first principles: “build defence in”

• simultaneously coping with accidental and malicious faults

• provide protection in an incremental way,not all threats are extreme, or all systems critical

• automatically adapt to a dynamic range of severity of threats

• seek unattended and perpetual operation

Is resilience really necessary?

Conventional Software Vulnerabilitiesever increasing

Number of new vulnerabilitiesper year

(Sources: IBM xForce, Symantec, Telexa)

Cyberspace today

• immense, interconnected, interdependent infrastructure

• exposure: pressure to be “on-line”• steadily increasing software

vulnerabilities

• powerful adversary actors and sophisticated exploit tools

• Elevated risk in all cyber components

(Source: Adapted from Lipson, H. F., Tracking and Tracing Cyber-Attacks: Technical Challenges and Global Policy Issues, Special Report CMS/SEI-2002-SR-009, November 2002. (CERT)

High

Low

1980 1985 1990 1995 2000

password guessingself-replicating code

password crackingexploiting known vulnerabilit ies

disabling auditsback doors

hijacking sessions

sweeperssniffers

packet spoofing

GUIautomated probes/ scans

denial of service

www attacks

Attacks

Attackers“stealth” / advanced scanning techniques

burglaries

network mgmt. diagnostics

DDOS attacks

20xx…

Bot Nets

Embedded malicious

code

Required Attacker expertise

AvailableAttack sophistication

TARGETED ATTACKS a.k.a.

ADVANCED PERSISTENT

THREATS

Attack sophistication vs. attacker expertise

Tailored Subversion and Intrusion

A world full of threats?

• targeted attacks and advancedpersistent threats, by nation-stateactors and other powerful agents

• weakening and subversion of comms and computing services

• threats to privacy: mass surveillanceand data collection

• sophisticated automated cyber weapons

• organised crime

Designing and architecting for resilience1. we want systems to operate

through faults and attacks in a seamless manner, in an automatic way

2. we want systems to endure the fact that operating conditions and environments are everyday more uncertain and/or hostile

3. we want systems to be deployed in unattended manner

4. we want systems to attain veryhigh levels of assurance

Preventing and Tolerating Faults and Intrusions

Handling Incremental Threat Severity

Resisting Continued Threats

Validating and Assessing Assumptions and Mechanisms

P Verissimo, M Correia, N Neves, P Sousa, “Intrusion-Resilient Middleware Design and Validation”, in Information Assurance, Security and Privacy Services. Emerald Group Publishing Limited, May 2009, vol. 4.

P Verissimo, N Neves, M Correia, “Intrusion-Tolerant Architectures: Concepts and Design”, in Architecting Dependable Systems, ser. LNCS. Springer-Verlag, Jun. 2003, vol. 2677. Ext. vers. in http://hdl.handle.net/10451/14253

http://www.navigators.di.fc.ul.pt/wiki/Publication:Verissimo09hishttp://www.navigators.di.fc.ul.pt/wiki/Publication:Paulo-verissimo2003intrusion-tolerant-architectures-123http://hdl.handle.net/10451/14253

Designing dependable and secure systems:a brief history

Host A

Designing dependable and secure systemsthe zero-defect goal

Host B

Host C

Host D

Host AHost A

Designing dependable and secure systemszero-defect goal considered infeasible:

NOTES:(i) there will always be vulnerabilities in a fully-fledged system

Host AHost A

Designing dependable and secure systemsreality in real-world systems

Host A

Host BHost C

Host D

NOTES:(i) there will be quite a few vulnerabilities in a real-world system

Attack-Vulnerability-Intrusion composite fault model

NOTES:(i) This model, introduced in the MAFTIA project, will help analyze the situation(ii) state includes data, code, metadata, configuration variables, etc.(iii) “failure” means failure of any security property, when and if perceived by a user 38

AVI fault model: attack + vulnerability→ intrusion → error → failure

Intruder/Designer/Operator

vulnerability(fault)

Intruderattack(fault)

intrusion (fault)

error failure

(ii) state is erroneous

(iii) failure will ensue sooner or

later

[Verissimo et al., IEEE Sec&Priv Mag.’06]

(i) Composite fault: v+a

Classical security: Intrusion prevention


intrusion (fault)

error failure

attack prevention

vulnerabilityprevention

intrusion prevention

vulnerabilityremoval



Intrusion prevention!

Designing dependable and secure systemsreality in real-world systems – optimistic view

Host A

Host B

Host C

Host D

Host AHost AHost A

Host B

Host C

Host D

Host AHost A

Designing dependable and secure systemsreality in real-world systems – optimistic view

Host A

Host B

Host C

Host D

Host A

Host B

Host C

Host D

Host AHost A

Designing dependable and secure systemszero attack-vulnerability-match goal

Host A

Host B

Host C

Host D

Host A

Host B

Host C

Host D

NOTES:(i) Individual vulnerabilities and attacks exist, we try to prevent their successful matches






attack prevention



Indispensable but not perfect ...

Host C


intrusion (fault)

error failure

Host C


Ah, but that’s a residual probability ! riiiiight ?...


intrusion (fault)

error failure

Host C


If it MAY happen, it WILL happen!

Classical security: Intrusion detection





intrusion (fault)

error failure

attack prevention



Intrusiondetection!

Classical security: Intrusion detection





intrusion (fault)

error failure

attack prevention



Which is useful but imprecise, incomplete and slow ...

NOTES:(i) after intrusion, the system is in the path to failure, so incompleteness or slowliness of intrusion

detection and/or ad-hoc processing/mitigation, bears a high risk of failure of a security propertyas perceived by a user

And what’s worse, some individual failures will still occur

Back to the AVI composite fault model

• what remains, as ‘action points’ before failure?

• why not act after errors caused by intrusions, by intrusion tolerance, as in “fault tolerance”?

53





intrusion (fault)

error failure

attack prevention



intrusiondetection

We are here!

Automatic Dependability and Security: intrusion tolerance


intrusion (fault)

error failure

attack prevention

vulnerabilityprevention vulnerabilityremoval


vulnerability(fault) intrusion

preventionintrusiontolerance

P Verissimo, N Neves, M Correia, “Intrusion-Tolerant Architectures: Concepts and Design”, in Architecting Dependable Systems, ser. LNCS. Springer-Verlag, Jun. 2003, vol. 2677. Ext. vers. in http://hdl.handle.net/10451/14253

http://www.navigators.di.fc.ul.pt/wiki/Publication:Paulo-verissimo2003intrusion-tolerant-architectures-123http://hdl.handle.net/10451/14253

What is Intrusion Tolerance?

• The tolerance paradigm in security:– Assumes that systems remain to a certain extent vulnerable– Assumes that attacks on components or sub-systems can happen

and some will be successful– Ensures that the overall system nevertheless remains secure and

operational, preventing “failure”, as failure of a security property, when and if perceived by a user

– Paradigms and techniques can simultaneously cover accidental andmalicious faults (dependability and security)

• In other words:– Faults--- malicious and other--- occur– They generate errors, i.e. component-level security compromises– Error processing mechanisms make sure that system-level security

failure is prevented

55

Design for Resilience

© 2002-08 Paulo Veríssimo - All rights reserved, no unauthorized reproduction in any form 1.56

Some philosophy for a start• What characterizes a dependable system?

– A set of safety and liveness properties• What characterizes a secure system?

– A set of safety and liveness properties• What may impair a dependable system?

– A set of faults -> failure• What may impair a secure system?

– A set of faults (attacks, vulnerabilities, intrusions) -> failure• How do I make a system dependable (normally)?

– Using fault avoidance (prevention, removal) and fault tolerance (error detection, recovery, masking)

• How do I make a system secure (normally)?– Using fault avoidance (attack prevention, vulnerability removal)

– and some bits of fault tolerance (intrusion detection)– Nowadays, increasingly fault tolerance (intrusion detection, recovery,

masking)

Intrusion Tolerance: error processing

• Error detection and recovery techniques:– effective use of intrusion detection: integrated in a principled and

automatic process– system detects errors resulting from intrusions– system either goes back to a previous state known as correct, and

resumes/restarts operation, or reconfigures and proceeds forward to state seeking correct provision of service

57

Recover and resume/restart after intrusion Reconfigure after intrusion

Intrusion Tolerance: error processing

• Error masking techniques– redundancy allows providing correct service without glitch– system masks errors resulting from intrusions– works whilst enough redundancy for number of faults

58

Detection not needed, whatever happens, error is masked

Intrusion Tolerance: error processing techniques• backward recovery:

– system goes back to a previous state known as correct and resumes– system suffers DOS (denial of service) attack, and re-executes the

corrupted operation– system detects corrupted files, pauses, reinstalls them, goes back– system detects corrupted message signature, discards, send nack

59

Redo after attack

Intrusion Tolerance: error processing techniques• forward recovery:

– proceeds forward to state that ensures correct provision of service (evasion, moving target defense)

– system detects intrusion, considers corrupted operations lost and increases security level (threshold/quorums increase, key renewal)

– system detects intrusion, moves to degraded but safer op mode

60

“Plan B” after intrusion

Error processing at work

• backward recovery

• forward recovery

• error masking

61

Redo after attack

“Plan B” after intrusion

Whatever happens...

• slides a seguir:• difer entre prots segur (prevent) mesmo multi-

party, e tolerância (consenso e replicas, SMR)• prots multiparty/multironda portanto• pbft aspecto• poder dos híbridos (aka TEE, but used in

tolerance), simplific: minbft c LTC; ttcb smr c DTC, ainda mais simples

A methodic approach to modular and distributed resilient computing• Fault and intrusion tolerance, or automatic

security and dependability• Handle increasing threat severity• Resist continued threats

• Divide-and-conquer to beat extreme threats• Hybrid models and architectures • Ultra-reliable trusted components• High-confidence vertical verification• Privacy- and integrity-preserving data processing

Fault and Intrusion Tolerance (FIT)Masking: an abstract solution

Tolerating Faults and Intrusions automatically

f+1 out of 2f+1k out of n

f = max. number of faulty replicas (f=1 in this example)

Node

Node

Node

Incomingrequests

Resultsconsolidation

Automatic Dependability and Security: intrusion tolerance


intrusion (fault)

error failure

attack prevention

vulnerabilityprevention vulnerabilityremoval


vulnerability(fault) intrusion

preventionintrusiontolerance

Criticisms to InTol: common-mode failures or fast exhaustion; f+1 syndrome;...

Fault and Intrusion Tolerance (FIT)The fast exhaustion or common-mode failure problem

Node

Node

Node

NodeO.S.xinside!

O.S.xinside!

O.S.xinside!

O.S.xinside!

Incomingrequests


Host AHost A

Designing dependable and secure systemsreality in real-world systems – recap

Host A

Host B

Host C

Host D

Host AHost A

Designing dependable and secure systemsreality in real-world systems – adapting to intrusion tolerance

Host A

Host B

Host C

Host D

Host A

Host B

Host C

Host D

Hardening q.b.

Designing dependable and secure systemsreality in real-world systems – adapting to intrusion tolerance

Diversifying q.b.

Host A

Host B

Host C

Host D

Host A

Host B

Host C

Host D

Fault and Intrusion Tolerance (FIT)Hardening and Diversification - M itigating fast exhaustion

3f+1 diverse replicas (f=1 in this example)

Node

Node

Node

Node

O.S.yinside!

O.S.winside!

O.S.xinside!

O.S.zinside!

Incomingrequests


Host A

Host B

Host C

Host D

Designing dependable and secure systemszero failures goal despite successful intrusions ?

Host A

Host A

Host B

Host C

Host D

Designing dependable and secure systemszero failures goal despite successful intrusions ?

Only until f+1 faults produced ...

Host A

Host A

Fault and Intrusion Tolerance (FIT)The resource exhaustion (or f+1) problem

f = max. number of faulty replicas (f=1 in this example, was exceeded)

Node

Node

Node

Node

f+1 out of 3f+1k out of n

Incomingrequests


Fault and Intrusion Tolerance (FIT)Resisting Continued Threats

Seeking (unattended) perpetual execution

f = max. number of faulty replicas in an interval Tr

Node

Node

Node

Node

RecoverNow!

Recovered!

RecoverNow!

RecoverNow!Recovered!

Recovered!

Incomingrequests


Designing dependable and secure systemszero failures forever goal despite successful intrusions ?

Host AHost AHost A

Host B

Host C

Host D

Host A

Host B

Host C

Host D

Host A

Host B

Host C

Host D

[Sousa et al., DSN 05]

Only if you are faster than the attacker ...

A methodic approach to modular and distributed resilient computing• Fault and intrusion tolerance, or automatic security

and dependability• Handle increasing threat severity• Resist continued threats

• Divide-and-conquer to beat extreme threats• Hybrid models and architectures • Ultra-reliable trusted components• High-confidence vertical verification• Architecture-aware privacy-preserving data processing

Divide-and-conquer I: Hybrid models and architecturesLeveraging power at right place right time

THost B

Just hardened q.b. payload

Ultimately trusted hybrids

NOTES:(i) Trusted components must be trustworthy by construction(ii) But having trusted-trustworthy components is not enough:(iii) We need an computational model that makes payload enjoy their properties


Host A

Host B

Host C

Host D

T

T

T

T

Verified andtamperprooffunctional API

Optionalcontrolnetwork

Payload network, in/out

Hybridisation-awaredistributed algorithms

Replicationfor fault andintrusiontolerance

[Verissimo, Travelling through Wormholes: a new look at Distrib. Sys. Models. SIGACT News, no. 1 ’06.]


Host A

Host B

Host C

Host D

T

T

T

T

Paulo Verissimo, “Travelling through Wormholes: a new look at Distributed Systems Models”, SIGACT News, vol.37, no. 1, Mar. 2006.

Formally definedSecure interfaces

Leveraging trusted-trustworthy components (aka TEE) with the right set of simple functions (failure detectors, monotonic counters, reliable timers and clocks, PRG, signatures, indelible logs, binary cons.

Verified secure control network

http://www.navigators.di.fc.ul.pt/wiki/Publication:Paulo-verissimo2006travelling-through-170

Recursive building of trust & trustworthiness

93

94

Building trustworthiness

• Initial hostile/adverse environment– by (careful) assumption

• Subsystem C designed to be trustworthy– By construction

C1 C2

C3 C4 C5

C6

C1 C2

C3 C4 C5

C6

Trustworthy C (by construction)

95

Building trust

• Initial hostile/adverse environment– by (careful) assumption

• Subsystem C designed to be trustworthy– By construction

• Subsystem C becomes B ’s environment– Properties of C are assumed by B

• B trusts C– a trusted-trustworthy subsystem– to build algorithm B

C1 C2

C3 C4 C5

C6

C1 C2

C3 C4 C5

C6

B3

B5

B4

B2

B1

Trusted C (by B)

96

On coverage and separation of concerns• predicate P holds with a coverage Pr

– we say that we are confident that P has a probability Pr of holding• environmental assumption coverage (Pre)

– set of assumptions (H) about the environment where system will run– Pre = Pr (H | f) f- any fault

• operational assumption coverage (Pro)– the assumptions about how the system/algorithm/mechanism proper (A) will

run, under a given set of environmental assumptions– Pro = Pr (A | H)

Alice Bob

Luisa

PaulAlicePr(A ) = Pro x Pre = Pr (A | H) x Pr (H | f)

99

Architectural support for resilience in the presence of attacks

• research architectural support for application-aware hybrid BFT, diversity and self-healingsolutions at all levels of the hardware/software stack, esp. RTES– application-specific trusted-trustworthy components– improved performance / reduction

replica quorum number

• SGX-based consensus, namely considering:– enclave-to-enclave interaction schemes– SGX enclave availability

10

High-confidence vertical formal verification of critical components

Re-design and partial verification of BFT-SMaRt (ULisboa) One of the few fully-implemented and efficient BFT-SMR protocols We plan on building trustworthy leader change and reconfiguration

components to plug into BFT-SMaRt As mentioned above we will verify these components in Coq (theorem

prover from INRIA)

Verification of MinBFT’s (ULisboa) core trusted-trustworthy component (USIG):

• C implementation of USIG• Coq specification/implementation for verification• Verify that C code satisfies Coq, through VST (Verified

Software Toolchain) • Verify Coq spec satisfies desired safety properties through

Coq• generate target code from C with CompCert (formally verified

C compiler)

10

Threats to blockchain

10

Blockchain

Security: • Double spending attacks• Selfish mining attacks• Flash attacks• ...

Privacy:• Untraceability• Unlinkability• Transaction content/amount privacy

v.s.Transparency

• …

Consensus: • Probabilistic v.s. deterministic• Assumption (f < 1/4 or 1/3 or 1/2)

v.s.Oligopolistic mining pools

• …

Scalabilility:• #TPS is limited• Size of the ledger is ever increasing• ...

10

Solving blockchain problemswith resilience (BFT) mechanisms

Attacks/Features BitCoin BitCoin-NG ByzCoin RepuCoin

Double spending attacks

Selfish mining attack

Bribery/flash attack

Non-forkable chain

Liveness

Throughput 7 tps ? 1,000 tps 10,000 tps

The system is secure against this attack The system is vulnerable to this attack The system can prevent double spending, but its throughput maybe reduced.

Univ. Luxemb.

Science of Security: some

reflections

104

Frameworks for SoSexample goals and motivations

• A nation wishes to process as efficiently and effectively as possible, massive forests of data it somehow has access to:– About legitimate use of systems for ilegitimate purposes– About ilegitimate use of systems for ilegitimate purposes

• A nation wishes to improve prevention/ tolerance against ilegitimate use of systems– Direct attacks (inc. APT) onto systems and infrastructures– Intentional weakening or subversion of security and trust

mechanisms in ICT

105

Frameworks for SoSscope of application of results

1. A nation wishes to interpret as efficiently and effectively as possible, massive forests of data it has access to

2. A nation wishes to protect systems/infrastructures against ilegitimate use

A. IntelligenceB. Information gatheringC. Espionage

D. Infrastruct. SecurityE. Infrastruct. ProtectionF. Infrastruct. ResilienceG. Counter-espionage

106

Motivation (w rap-up)There is no trustworthy data on non-trustworthy systems

ERGO:We need models and algorithms supporting systems

that operate long enough to fulfill their mission, through threats of increasing magnitude, automatically and in an unattended mode

107

As a pre-condition to

Tolerance

• Tolerance Goal: operate correctly as long as at most f faultsof any quality occur

• This well-known formal proposition however, says very little about an important objective:

• will f+1 faults not happen “during my watch”?

108

Resilience

• Resilience Goal: tolerate any quality and quantity of faults over time – as long as the power of the threat is bounded– (i.e. at most f occur within a given interval)

• How to fulfil this formal proposition?– structure (hardening, trusted components)– diversity, randomisation, obfuscation– self-healing, ex. proactive/reactive recovery (PRR)– dynamic reconfiguration, moving target defences 109

110

Paulo Esteves-VeríssimoUniversity of Luxembourg Faculty of Science, Technology and Communication

_ and SnT, the Interdisciplinary Centre for Security, Reliability and Trust _


@SnTCritical and Extreme Security and Dependability

We’re hiring bright PhD students and research associates (post-docs) willing to address these challenges!

Thank you! _

�Grand Research Challenges for Cybersecurity of Critical Information and Infrastructures��Grand Research Challenges for Cybersecurity of Critical Information and Infrastructures��The world is becoming an immense (interconnected) infrastructureInternet minute��CritiX�research�visionPeopleCritiX - Critical and Extreme Security and Dependability Research Lab�Research enablers for the next generation of protectionSoftware Defined Networking (SDN)�the other face of the problemNetworked Control Systems: �no longer closed, proprietary, or dumbX-by-wire Networked Vehicles: �no longer mechanical and isolatedThe safety-security gap in vehicle ecosystemsAutonomous vehicle ecosystem threat planeGenomics and Biomedical vs. Big DataPrivacy- and integrity-preserving data processing�The e-biobanking visionDNA workflows in an e-biobanking ecosystemBlockchainBlockchain for FinTech and Crypto-currency: challengesMeeting the Challenges of �Critical Dependability and SecurityArchitecting and designing for resilienceIs resilience really necessary?Conventional Software Vulnerabilities�ever increasingCyberspace todayAttack sophistication vs. attacker expertiseTailored Subversion and IntrusionA world full of threats?Designing and architecting for resilienceDesigning dependable and secure systems:�a brief historyDesigning dependable and secure systems�the zero-defect goalDesigning dependable and secure systems�zero-defect goal considered infeasible: Designing dependable and secure systems�reality in real-world systemsAttack-Vulnerability-Intrusion composite fault modelClassical security: Intrusion preventionDesigning dependable and secure systems�reality in real-world systems – optimistic viewDesigning dependable and secure systems�reality in real-world systems – optimistic viewDesigning dependable and secure systems�zero attack-vulnerability-match goalClassical security: Intrusion preventionClassical security: Intrusion preventionClassical security: Intrusion preventionClassical security: Intrusion detectionClassical security: Intrusion detectionBack to the AVI composite fault modelAutomatic Dependability and Security: intrusion toleranceWhat is Intrusion Tolerance?Some philosophy for a startIntrusion Tolerance: error processingIntrusion Tolerance: error processingIntrusion Tolerance: error processing techniquesIntrusion Tolerance: error processing techniquesError processing at workSlide Number 62A methodic approach to modular and distributed resilient computingFault and Intrusion Tolerance (FIT)�Masking: an abstract solution�Tolerating Faults and Intrusions automaticallyAutomatic Dependability and Security: intrusion toleranceFault and Intrusion Tolerance (FIT)�The fast exhaustion or common-mode failure problemDesigning dependable and secure systems�reality in real-world systems – recapDesigning dependable and secure systems�reality in real-world systems – adapting to intrusion toleranceDesigning dependable and secure systems�reality in real-world systems – adapting to intrusion toleranceFault and Intrusion Tolerance (FIT)�Hardening and Diversification - Mitigating fast exhaustionDesigning dependable and secure systems�zero failures goal despite successful intrusions ?Designing dependable and secure systems�zero failures goal despite successful intrusions ?Fault and Intrusion Tolerance (FIT)�The resource exhaustion (or f+1) problemFault and Intrusion Tolerance (FIT)�Resisting Continued Threats�Seeking (unattended) perpetual executionDesigning dependable and secure systems�zero failures forever goal despite successful intrusions ? A methodic approach to modular and distributed resilient computingDivide-and-conquer I: Hybrid models and architectures�Leveraging power at right place right timeDivide-and-conquer I: Hybrid models and architectures�Leveraging power at right place right timeDivide-and-conquer I: Hybrid models and architectures�Leveraging power at right place right timeRecursive building of �trust & trustworthinessBuilding trustworthinessBuilding trustOn coverage and separation of concernsArchitectural support for resilience in the presence of attacksHigh-confidence vertical formal verification of critical componentsThreats to blockchainBlockchainSolving blockchain problems�with resilience (BFT) mechanismsScience of Security: some reflectionsFrameworks for SoS�example goals and motivationsFrameworks for SoS�scope of application of resultsMotivation (wrap-up)�There is no trustworthy data on non-trustworthy systemsToleranceResilience�

Date post:	30-Jun-2020
Category:	Documents
Upload:	others
View:	3 times
Download:	0 times

Grand Research Challenges for Cybersecurity of Critical Information and Infrastructures · Grand...

Documents