sitar: a scalable intrusion tolerant architecture for distributed services

SITAR: A Scalable Intrusion Tolerant Architecture for Distributed Services

Dr. Feiyi WangAdvanced Networking Research

MCNC Research Triangle Park, NC

Prof. Kishor S. TrivediElectrical Engineer Department

Duke University, NC

3/14/2002 SITAR Project Briefing 2

SITAR Approach Highlights

SITAR intrusion tolerance capability is focused on a generic class of services as the target of protection

Develop ITS architecture by leveraging the basic fault tolerance techniques (redundancy, diversity and acceptance test, dynamic reconfiguration)

Use both model-based and measurement-based approaches to quantitatively evaluate intrusion tolerance capability of this architecture and carry out cost-benefit trade-off studies


SITAR Architecture

COTSServers

AcceptanceMonitors

BallotMonitors

ProxyServers

Pu Bv Am Sn

P2 B2 A2 S2

P1 B1 A1 S1

AuditControl

AdaptiveReconfiguration

requestresponsescontrol

Users/Clients

Protected


Service Oriented Problem

ClientsClients ServersServers


SITAR Community

Service Oriented Solution

ClientsClients

ServersServers

ServersServers


Key Architectural Solutions

Tolerance Through Redundancy Both protected service replication and SITAR

components replication

Failure Detection & Recovery For protected service: (1) Acceptance test (2) Ballot

voting (3) Proactive monitoring For sitar’s own components: Lease, ARM and Audit

Control

Communication and Co-ordination Community-based share-space


JavaSpaceTM Based Organization

Incoming Requests

ProxyServer

ProxyServer

Acceptance Monitor

Acceptance Monitor



BallotMonitor

BallotMonitor

ServerWrapper

ServerWrapper

COTS Servers

AuditMonitor

AuditMonitor


Connection Setup Protocol

Proxy Server

Adaptive Reconfiguration

BallotMonitor

BallotMonitor

AcceptanceMonitor

AcceptanceMonitor

ServerWrappers

ServerWrappers

• Remote/Local Address• Sequence Number• Array of Proxy • Array of Acceptance• Array of Ballot Monitor

• Remote/Local Address• Sequence Number• Array of Proxy • Array of Acceptance• Array of Ballot Monitor

Connection Object

1

2

Worker Inventory Request

• Module Type• Connection ID• Index• Sequence Number

• Module Type• Connection ID• Index• Sequence Number

Work Order Request

5

6

8

• Module Type• Module Name• Connection ID• Index

• Module Type• Module Name• Connection ID• Index

Work Order Acknowledgement

7

4

• Number of allocated acceptance• Number of allocated ballot• Number of allocated wrappers• Number of allocated COTS

• Number of allocated acceptance• Number of allocated ballot• Number of allocated wrappers• Number of allocated COTS

Worker Inventory Response

3


Data Flow Protocol

Proxy Server

Server WrappersServer Wrappers

BallotMonitor

BallotMonitor

AcceptanceMonitor

AcceptanceMonitor

2

2

• Request Sequence Number• Request itself• Connection completed (Boolean) • Request completed (Boolean)

• Request Sequence Number• Request itself• Connection completed (Boolean) • Request completed (Boolean)

Client Request

1 • Most recent request number• Response number• Response itself• Redundancy index number• Connection completed (Boolean)

• Most recent request number• Response number• Response itself• Redundancy index number• Connection completed (Boolean)

Client Response

3

7

6• Redundancy index number• Request number• Begin/End response number• Valid (Boolean)

• Redundancy index number• Request number• Begin/End response number• Valid (Boolean)

Validation Report

5

4

• Response number • Response itself• Response completed (Boolean)• Connection completed (Boolean)• Redundancy index number

• Response number • Response itself• Response completed (Boolean)• Connection completed (Boolean)• Redundancy index number

Chosen Response

9

8


Coordination of Multiple Components

SITARJavaSpace

Heartbeat Monitor

ConfigurationManager

HeartbeatGenerator

Module

1. Register itself by writing an component entry

2. Say hello to ARM by writing a hello entry

3. Notify ARM that new module is online

4. Read component info and update config table

5. Write virtual component entry for this module

6. Register with space to be notified by heartbeat

7. Notified and read virtual component entry by space

8. The module begin to heartbeat periodically


PKI Space

Secure SITAR over Yalta

Jini LookupServices (Reggie)

SITAR service components (eg. ARM, AM, ACM, BM)

JavaSpace service components

Java Virtual Machine (JVM)

Secure Socket Layer (JSSE)

Extended Trust Manager

Java Virtual Machine (JVM)

Secure Socket Layer (JSSE)

Extended Trust Manager

Certificate Revocation Agent

RMI overSSL

Threshold CAYalta Space


Can SITAR Deal With Code Red?

Can we prevent code red attack? No

Can we detect code red attack?Most likely not

Can we tolerate its malicious actions?

Host server defacement

Yes

Propagation to other servers

Yes

SITAR as the ultimate target of DDOS attack

Limited


Cope With DDOS Attack

SITAR Community

SITAR Community

Black Hole Effect


Demonstration Against Code Red

ProxyServer

ProxyServer

Acceptance Monitor

Acceptance Monitor



BallotMonitor

BallotMonitor

ServerWrapper

ServerWrapper

AuditMonitor

AuditMonitor

Outgoing Responses

Acceptance Test: detect unmatched hash value and invalid header

Majority Voting: Detect one faulty node (responses) out of three

Allocating Resources: may not allocate IIS server at all

Performance monitor agent: detect resource depletion

Apache

EmulatedIIS

Apache

Incoming Requests


Status Summary

Delivered preliminary architecture reportDeveloped share-space based framework where different types of components, multiple instances of components can collaborate and provide SITAR services and demostrated basic functionalities Presented 2 papers on IC3N and SMC Information Assurance workshop, both are selected for further journal publicationSubmitted 2 papers to DSN’02 and its companion intrusion tolerance workshop


• It is a practical impossibility to build 100% secure, intrusion proof software or information systems. Alternative is to build intrusion tolerant systems.

• Security should be viewed as a QoS attribute, at par with other QoS attributes of a system.

• For many critical applications, qualitative characterization of security may not be desirable or acceptable.

• Instead, security may have to be quantified in order to meet the contracted levels of security QoS.

Modeling and Quantification of Security Attributes


• Security intrusions cause a system to fail•Security Failure

• Destruction of information• Theft of confidential information• Service may be rendered un-reliable• Denial of Services (DoS)• Lack of safety

• Similarity (as well as differences) between: • Security and reliability• Intrusion tolerance and fault tolerance

Proposed Approach


• Attacker spends effort in its attempt to penetrate security.

• System also has to spend time and effort to respond to an attack • In general, this effort is a random variable.

• P(e) is the distribution function for effort, and 1/is the mean. • Mean effort required to cause a security failure. Similar to the

the notion of MTTF

Related work


• Effort itself may be random function of time. Doubly stochastic situation which we ignore for simplicity.

• Mean-time-to-security-failure (MTTSF).

• A software system has many states, some good and some not some not so good from the security perspective.

• It takes random amount of time to make the system move from one state to another need for stochastic modeling.

Stochastic model


State transition model for security


• Prior studies show that a typically an ensemble of attackers exhibit behavior comprising of three phases:

1. Learning phase2. Standard attack phase3. Innovative phase

• Multiple phase behavior leads to non-exponential distributions, non-Markovian behavior

• The random process describing the state transition behavior is instead a semi-Markov process.

Non-Markovian Behavior


• A semi-Markov process is characterized by:1. Transition probabilities2. Sojourn time distributions in different states

• The security quantification problem can be partitioned into phases1. Stochastic model (SMP)2. Model parameters3. Model analysis and validation4. Result interpretation

X

Semi-Markov Processes (SMP)


SMP Modeling parameters

Parameters:

hG, hV;

a, t,

pa, pu, pm, pg, ps a

t

hG

hV


Available states: {G,V,A}

Availability = G+ V+ A

SMP for the Syn Flood DoS sattack


1. Steady-state probabilities, G ,V …, F

2. Probability of reaching any security failed state

• {UC, FS, GD, F} : security failed states.

• Availability analysis

3. Time to reach any security failed state (MTTSF)

4. At the end of absorption, probabilities of reaching UC, FS, FD or F. Different failed states may imply different type of security compromise.

Security Quantification: Solving the SMP model


What does security failure imply?

• A security failed state may imply compromise of:

•Availability: readiness for system usage.

• Reliability: continuity of services.

• Safety: non-occurrence of catastrophic events.

• Confidentiality: disclosure of sensitive information.

• Integrity: unauthorized data/prog modification/destruction.

• Maintainability: ability to undergo repairs and evolution.

• Different failed states may imply one or more type of security

failure.


Numerical Results

Transition probabilities:

pa = 0.4; pm= 0.3; pu = 0.2; ps = 0.3

Mean sojourn times:

hG = 0.5; hV = 0.5;

at

SMP steady-state probabilities:

G = 0.3386; V = 0.2257; A = 0.1333;

MC = 0.0201; UC = 0.2167; TR = 0.0667;

FS = 0.0200; GD = 0.0406; F = 0.0067;

MTTSF : 3.5595, etc.


Sensitivity to Modeling Errors

• Since it is usually not easy to estimate model parameters

accurately, it is also desirable to figure out the impact on

estimation inaccuracies.

• Sensitivity analysis: tells us the sensitivity of different

measures to different parameter variations.

Ii = |i dM / di |


Where we are?

• Development of an SMP model for security quantification.

• Model suitable for quantifying attributes, such as,

Availability, MTTSF, Absorption probabilities,

Integrity, Privacy, Confidentiality etc.

• Model parameterization remains to be addressed.

• DARPA IA program approach of red teams

• Use available data

• Set up experiments for estimating model parameters.


Future Work

Near term: We are progressing towards delivering final architectural report

Long term: More intelligent ARM algorithm Strengthen space-based security Demonstrate support for other type of services

sitar: a scalable intrusion tolerant architecture for distributed services

Documents

code red attack

virtual component entry

service replication

component info

component entry2

measurementbased approaches

different types of components

iis server