carnegie mellon university software engineering institute lecture 3a the survivable network analysis...

Carnegie Mellon UniversitySoftware Engineering Institute

Lecture 3a

The Survivable Network Analysis Method: Evaluating Survivability of Critical Systems


Survivability Concepts


Survivability Motivation

• Growing societal dependence on complex, large-scale, networked systems – Sectors: commercial, government, defense, ... – Infrastructure: telecom, transportation, utilities, …– Interdependencies and cascade failures

• Serious consequences of system compromises and failures

• Presidential Commission on Critical Infrastructure Protection


• Expanding network boundaries and connectivity• Blurring of Intranets and Extranets • Heterogeneous mix of participants with varying trust• Lack of central administrative control• Unknown components: COTS, Java, … • Point security solutions: PKI, VPN, IDS, firewalls, ...

The fundamental limitation of security:No amount of security can guarantee a system will not be penetrated

The Changing System Environment


Survivability is the capability of a system to fulfill its mission, in a timely manner, in the presence of attacks, failures, or accidents.

• Focus is on the continuity and recovery of the system mission

• Imperfect defenses are assumed

Survivability Defined I


Survivability Defined II

• Survivability differs from security – Security focuses on static perimeter defenses– Survivability focuses on design and operation to

maintain mission support in adverse environments

• Survivability differs from dependability– Dependability focuses on random faults – Survivability focuses on coordinated attacks by

intelligent adversaries


The “Three R’s” of Survivability

• Resistance– Capability to deter attacks

• Recognition– Capability to recognize attacks and extent of damage

• Recovery– Capability to provide essential services/assets during

attack and recover full services after attack


The Survivable Network Analysis Method


Understand survivability risks– what system services must survive intrusions?– what are effects of intrusions on the mission?

Identify mitigating strategies– what changes can improve survivability?– which changes have highest payoff?

SNA Objectives


• Architecture is – integrating element of large systems– right level of abstraction for survivability analysis

• components, connections, software, traces

• Architecture is focus for system evolution– evolving functional requirements– trend to loosely coupled systems– integration across diverse systems– changes in vendor product architectures

SNA Focus is on Architecture


• Performed on selected system or system component

The four SNA steps:Step 1: Understand the enterprise mission and architectureStep 2: Define essential service scenarios and componentsStep 3: Define intrusion scenarios and componentsStep 4: Analyze survivability and make recommendations

• Performed by SNA team plus client team• Joint working sessions to develop findings • Management briefing on recommendations

The SNA Process


• Identify the business mission supported by the system– Examples

• A government agency: review, select, fund, and monitor government contracts

• An industrial enterprise: support integration of design teams across internal corporate organization, industry partners, and contractors

• All stakeholders must be involved – owners, users, architects, developers, administrators

SNA Step 1: Mission elicitation


• Understand system architecture and environment– network topology and boundaries– hardware and software components– user functions and workflows– critical services and assets– administrative control domains – vendor dependencies – connectivity with other systems– Security components and policies – attack and intrusion experience

SNA Step 1: Architecture Elicitation


SNA Step 2: Preliminaries• What is a usage scenario?

– Defined as the sequence of steps in a system use– A “use” can be thought of as a transaction

Example: A usage scenario for checking mail on AOL– Invoke AOL– logon: enter name and password– after connection, select “new mail”– scroll to end of list– select and read new messages if any– save and delete messages as necessary– logoff


SNA Step 2: Essential Capabilities• Essential services/assets

– System capabilities that support the business mission– Must be available despite intrusions

• Essential service/asset usage scenarios– Steps in essential service/asset usage

• Essential components– Architecture parts required by essential service/asset scenarios– Determined by tracing scenarios through the architecture to

determine the components reached (compositional reasoning)


Essential ServiceScenario

EssentialComponent

EssentialService Trace

CommunicationLink

ArchitectureNode

EssentialServiceScenarioTrace


• “Target of opportunity” profile: non-specific objectives– readily available tools– defense: increased resistance, configuration control, file-

integrity checks

• “Intermediate” profile: specific objectives– greater patience, higher impact on essential services– defense: increased recognition and recovery

• “Sophisticated” profile: very focused objectives– customized tools, compromise internal staff– defense: high probability of success; recognition and

recovery essential

SNA Step 3: Attacker Profiles I


• Create taxonomy of probable attackers and impacts– resources: personnel, skill, finances– time: patience and persistence– tools: access to tools, ability to customize– risk: level of risk aversion – access: internal, Internet– objectives: personal, financial, moral

• Example: government agencies may have attackers with strong political or moral positions who are not risk averse and can be very patient

SNA Step 3: Attacker Profiles II


SNA Step 3: Intrusion Capabilities

• Treat intruders as users

• Intrusion usage scenarios– Steps in attacker usage

• Compromisable components– Architecture parts accessible by intrusion scenarios– Determined by intrusion scenario traces


IntrusionScenario Compromisable

Component

IntrusionTrace

IntrusionScenarioTrace


SNA Step 4: Softspot Components

• Softspot components are architecture parts that are both essential and compromisable


Essential ServiceScenario

IntrusionScenario Softspot Component: both

essential and compromisable

ArchitectureSoftspot Identification


SNA Step 4: Strategies for the “Three Rs”

• Resistance– User authentication, firewalls, software diversification, ...

• Recognition– Intrusion usage pattern detection, internal integrity

checking, ...

• Recovery– Hot spares, redundant facilities, data replication and

reinitialization, alternative service delivery methods,...


SNA Step 4: Survivability Map

• Defines survivability strategies for the three R’s based on intrusion softspots

• Relates the strategies to the architecture

• Makes recommendations for architecture modifications


Survivability Map Template

IntrusionScenario

SoftspotEffects

ArchitectureStrategies for

Resistance Recognition Recovery

Current(Scenario1)

… Recommended

Current(Scenarion)

Recommended

• Roadmap for management evaluation and action


Survivable Network Analysis (SNA) Method

STEP 1 SYSTEM DEFINITION• Mission requirements definition• Architecture definition and elicitation

STEP 2 ESSENTIAL CAPABILITY DEFINITION• Essential service/asset selection/scenarios• Essential component identification

STEP 3 COMPROMISABLE CAPABILITY DEF’N • Intrusion selection/scenarios• Compromisable component identification

STEP 4 SURVIVABILITY ANALYSIS• Softspot component (essential & compromisable) identification• Resistance, recognition, and recovery analysis• Survivability Map development


A Survivability Case Study:The Sentinel Subsystem


The Vigilant Healthcare System

• Large-scale, distributed mental healthcare management system by CarnegieWorks, Inc.

• Many business rules and regulations, many users and stakeholders

• Sentinel subsystem – Maintains patient data, provider teams, goals, actions,

treatment plans, ...– Sentinel prototype was subject of survivability study


Applying the SNA method• Evaluation team/customer meetings

– Sentinel architecture elicited– Essential services/assets selected, scenarios defined– Essential components of architecture traced– Intrusion types selected, scenarios defined– Compromisable components of architecture traced

• Evaluation team sessions– Softspots identified, Survivability Map and architecture impacts

defined

• Customer briefed on findings


ListManager

ReportingEngine

TreatmentPlan

Builder

TreatmentPlan

Validator

ActionTeam Builder

User Interface

Sentinel Application

Sentinel Back End

Business Logic

Common Database

API

OtherSystem

Components

OtherSystem

Components

Original SentinelArchitecture


Initial Analysis

• Essential capabilities identified

– A single service: Treatment plan display on demand

– A single asset: Treatment plans

• Five intrusion scenarios identified


Sentinel Survivability Map -- Intrusion 1

IntrusionScenario

ResistanceStrategy

RecognitionStrategy

RecoveryStrategy

Current:

None. No timeout isspecified, so anyonecan use a vacatedbut logged-interminal.

Current:

None, except forunusual number ofdenied TP accessesas an intruderattempts to locateparticular TPs.

Current:

Can get list ofmodified TPsthrough spoofeduser’s transactionhistory andmanually recovereach one.

An unauthorizeduser employsSentinel to modifyor view TPs byspoofing alegitimate user.

Softspot:

Treatment PlansRecommended:

Add a short logouttimer for terminals inuncontrolled areas.[1]

Recommended:

Add logging, accesscontrol, and illegalaccess thresholds tothe security API. [1]

Recommended:

Develop a recoveryprocedure andsupport it in the UI.[1]


Sentinel Survivability Map -- Intrusion 2

IntrusionScenario

ResistanceStrategy

RecognitionStrategy

RecoveryStrategy

Current:

Security model in DBprotects TPs againstcorruption.

Current:

None, except when aprovider happens torecognize acorrupted TP.

Current:

Locate anuncorrupted backupor reconstruct TPsfrom scratch.

An unauthorizeduser corrupts theDB leading to lossof trust in allvalidated TPs byall providers.

Softspot:

Treatment Plans

Recommended:

Implement livereplicated DBs thatcross check forvalidity (supported bymany DBs) [5]

Recommended:

Add and checkcrypto-checksums onTPs in the DB. [3, 4]

Recommended:

Reduce the backupcycle to quicklyrebuild once acorrupted DB isdetected. [5]


ListManager

ReportingEngine [2]

ActionTeam

Builder

User Interface

Sentinel Application

Sentinel Back End

Business Logic

Common Database - Replicated and Daily Backups [5]

API

OtherSystem

Components

OtherSystem

Components

IsolatedReportingSystem [6]

Modified SentinelArchitecture

TP Buildercrypto-chk

[3]

TP Validatorcrypto-chk

[4]

Security [1]

MinimalUser

Interface

MinimalReporting

Engine/TPs

Security Layer [1]


• Client: A large distributed organization, many legacy systems, major redesigning underway

– Define a security architecture: • integrate directory services• support mix of central and distributed administration• develop common API to security infrastructure• provide architecture support for managing active content

(Javascript, email attachments)

– support architecture evolution: • incorporate security product upgrades • assess survivability of vendor architecture changes

Recommendations: Example I


• Client: administrative unit inside large, diverse organization, heterogeneous user environment (university-like), significant research component – revise security/survivability policies – increase separation between internal components and

components accessed by general public – add internal firewalls to better manage diverse user

community– extend attacker analysis beyond script-kiddies– improve system recovery

Recommendations: Example II


Survivability in the Requirements Phase


System/SurvivabilityRequirements

Usage/IntrusionRequirements

SystemDevelopment/Evolution

Usage ModelDevelopment/Evolution

SystemTesting/Evaluation

SystemOperation/Administration

SurvivabilityOperationsRequirements

Survivability DevelopmentRequirements

SurvivabilityEvolutionRequirements

Legacy/AcquiredSoftware,SurvivabilityStrategies

Survivability Requirements Types

(1)

(2)

(3) (4)

(5)


• Augment traditional system requirements with survivability requirements

– partition system services• essential: maintained during intrusion• non-essential: recovered post-intrusion

– define survivability service requirements• resistance, recognition, recovery

(1) System/Survivability Requirements


• Augment traditional system usage requirements with intruder usage

• Treat intruders as users

– model intrusion scenarios

– specify, design and test systems for correct responses to intrusions

(2) Usage/Intrusion Requirements


• Integrate survivability strategies into specifications and designs • Sound engineering practices are required to develop survivable

systems • Five principles for survivable system development

– specify required functions in all circumstances of use– verify implementation correctness against function

specifications– specify usage in all circumstances of use, including intruder

usage– test and certify fitness based on usage specifications– establish readiness teams for system monitoring and evolution

(3) Survivability Development Requirements


• Staff the survivability mission in the organization

• Define and administer survivability policies

• Apply patches to known intrusion and failure problems

• Maintain readiness teams and conduct readiness drills

(4) Survivability Operations Requirements


• Adapt the system to deal with new intrusions

• Evolve survivability capabilities more rapidly than intruder’s can accumulate system knowledge

• Ensure new system functions include survivability capabilities

(5) Survivability Evolution Requirements

carnegie mellon university software engineering institute lecture 3a the survivable network analysis...

Documents