carnegie mellon university 10/23/2015 survivability analysis via model checking oleg sheyner...

Carnegie Mellon University04/20/23

Survivability Analysis via Model Checking

Oleg SheynerJeannette Wing

Carnegie Mellon University


Model Checking: Overview

Finite Model Property to be Checked

Counterexample

Trace

Model CheckerDoes the model satisfy

the property?

No Yes

• States and Transitions

• Specification Language

• Temporal Logic

• Abstract Automaton

• Explicit State

• Symbolic


Survivability

• A system is survivable if it can continue to provide a acceptable level of service despite the presence of faults.

• Faults– Accidental or malicious– Not necessarily independent

• Acceptable levels of service precisely defined

• Cost must be included in the equation


Survivability Analysis: Overview

Checker

System Model Survivability Property

Phase 1

Scenario Graph

Scenario Set

Analyzer

Reliability Query,Cost Query, etc.

Phase 2

Annotations(e.g., probabilities, cost)

Simple examples done

Initial efforts under way


Phase 1

Network Model =

Survivability Property =

Scenario Graph =

Model Checker = (modified) NuSMV

A set of concurrently executing Finite State Machines.

A predicate in CTL.

A set of related examples.


Model

• Network– hosts– services– connectivity– trust relationships

• Adversary– Knowledge about the

network– Privilege levels on hosts

• Attacks– Preconditions

Local (adversary) Global (network-wide)

– Traces– Effects

Local (adversary) Global (network-wide)

– Different flavors

• Intrusion detection system– Network (inter-host)– Host-based (local)


Phase 1 Example:Multistage Network Penetration

database

adversary

ftp

sshd

firewall router

IDSip1

ip2

ipa

ftp

Attack Arsenal

• Sshd buffer overflow - remotely get root• Ftp .rhosts file - establish trust between hosts• Remote login - exploit trust between hosts• Local buffer overflow - locally get root

Detected

Goal: Root access to host ip2

Number

0123


Scenario-Generating Properties

• These define secure operation - we look for counter examples

• Two cases1) Don’t care about detection

– AG (adversary.privilege[ip2] < root)– along all paths, it is always the case that the privilege of the

adversary is less than root

2) Want stealth

– AG ((adversary.privilege[ip2] < root) or (IDS.detected))– As above or the ids detects the act that leads to privilege

elevation


...

database

adversary

ftp

sshd

firewall router

IDSip1

ip2

ipa

ftp

rootno access

no access

no access

no access

root

Sshd buffer overflow on ip1

root

no access

root

Ftp .rhostson ip2

no access

rootroot

rsh trust

Ftp .rhostson ip2

no access

no access

root

rsh trust

Rsh from ip1 to ip2

user

rootroot

rsh trust

Rsh from ipa to ip2

no access

user

root

rsh trust

!

Local buffer overflow on ip2

no access

root

root

rsh trust

Yeah! root

Local buffer overflow on ip2

root

root

rsh trust

Yeah!


NuSMV Encoding

• Network– 1 attack host, 2 target hosts

with services– 3x3 connectivity matrix

existence of routing path ability to connect to ftp and

ssh services

– 3x3 trust matrix

• Adversary– Privilege levels for each host

• Attacks– 4 attacks– some have multiple flavors

• NuSMV Statistics

82 bits of state (282 states)<40K representation nodes~7000 reachable states

• 2 sec runtime on 1GHz Pentium III

• 8MB of memory used


Goal: Get Root, Avoiding Detection


Issues

• Metrics and Reliability Analysis– What is the worst case probability of failure?– What is the worst case probability that a service will ‘work’?

• Scalability

• Integration in a Vigilant System


Online and Offline Responses

Online

• What is the least restrictive firewall configuration that thwarts the intruder?

Offline

• Where do we install an additional IDS to maximize chances of detection?

• What is the smallest set of vulnerabilities we need to fix to thwart the attacker?


Scalability

• Expanded case study 5 hosts 4 new attacks legitimate users background traffic

high priority low priority

multiple firewall configurations

• NuSMV runtime: 4.5 hours

• ~ 6000 nodes in scenario graph

• Scalability remains a problem

• Would like performance linear in size of the reachable state

• Alternative approach: explicit-state model checking


Tool Support

ModelingScenario

GenerationAnalysis

Compiler

NuSMV

model

PRISM

model

.

.

.

High-Level

Description

Network

spec

(XML)

.

.

.

.

.

Modified

NuSMV

PRISM

.

Raw

Scenario

Graph Decompile

&

Annotate

Analyze

Domain-Specific

Scenario Set

Worst-case

reliability

Most

effective fix

etc.


XML Fragment

<attack name="local_u2r" local="yes"><local_preconditions>

<privilege host="target" eq="user"/></local_preconditions><global_preconditions>

<vulnerability host="target" name="vul_perl"/></global_preconditions><trace></trace><local_effects>

<privilege host="target" value="root"/></local_effects><global_effects></global_effects><detectable mode="both"/>

</attack>


Bottom Line

• Model checking technology can contribute to online vigilance

– Complete graphs describing what can go wrong enable the system to analyze the threat and pick the appropriate response

• Scale is a problem– Model checking cannot do the job alone– Should be part of an integrated system employing multiple

techniques

carnegie mellon university 10/23/2015 survivability analysis via model checking oleg sheyner...

Documents