sitar: a scalable intrusion tolerant architecture for distributed services

Advanced Networking Research, MCNC

SITAR: A Scalable Intrusion Tolerant Architecture for Distributed Services

Feiyi Wang, MCNCKishor Trivedi, Duke University


Project Introduction

• Project kickoff meeting: July 20, 2000• Project duration: 36 months• Collaborator: Duke University• Means of collaboration

– biweekly face-to-face meetings– frequent site visit– joint testbed

• Security clearance: Daniel Stevenson has a top secret clearance, the rest of the team members do not.


SITAR Project Goals

• To design, prototype and evaluate an architecture for building intrusion tolerant systems

– useful for all-new system– useful for creating system out of COTS components– useful for hardening existing system

• To develop new techniques that can be used in constructing high availability services, i.e., certain desirable service level can be maintained regardless of intrusions


Challenges

• How some of the very basic techniques of fault-tolerance (e.g., redundancy and diversity) apply to our target?

• How to deal with external attacks or compromised components which can exhibit unpredictable behaviors?

• How to quantitatively measure the “capability of system to resist attacks”?


SITAR Approach Overview

• SITAR Intrusion tolerance capability is tied to the functions and services provided

• Focus on events that pose a threat to the specific functions or services to be protected. Impact >> Cause

• Leverage well-developed techniques in fault tolerance and dependable systems research


SITAR Innovative Claims

• Focus on a generic class of services provided by COTS components as target of protection

• Deal with both external attacks and threats from internal, compromised components

• Approaches– Utilize the basic techniques of fault tolerance - redundancy

and diversity– Investigate dynamic reconfiguration strategies in this

architecture– 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


Proposed Architecture

Legend

Proxy Servers COTS ServersAcceptanceMonitor

Ballot Monitors

P1

P2 B2

B1 A1

A2

Am

S1

S2

Sn

clientrequest

BvPu

AuditControl

AdaptiveReconfiguration

request

control

serverresponse


Current Focus

• Fault/intrusion and basic ITS model study

• Proxy server and Acceptance monitor using Web server as an example

• Cluster membership management and state information sharing


Basic ITS Model

• We propose a state transition model as a framework for describing dynamic behavior of an intrusion tolerant system

• The system enables multiple intrusion tolerance strategies to exist and supports different levels of security requirements

• More details can be found in paper “Characterizing Intrusion Tolerant Systems Using A State Transition Model”, submitted to DISCEX II, 2001


State Transition Diagram for ITS

G

TR

A

V

F

MC UC

FS GD

enter V state(by accident orpre-attack actions

restoration/reconfiguration/

evolutiontransparentrecovery

detectedbefore attack

recovery withoutdegradation

undetectedbut masked


evolution


evolution

exploit begin

fail-securemeasure degradation

graceful

undetectednon-maskable

system free of thevulnerability

G G - good stateV V - vulnerable stateA A - active attack stateMC MC - masked compromised stateUC UC - undetected compromised stateTR TR - triage stateFS FS - fail secure stateGD GD - graceful degradation stateF F - failed state


ITS Modeling: Case Studies

• We have mapped several vulnerability case studies to the state transition model

• The focus is on the observable impact:– compromise of confidentiality– compromise of data integrity– compromise of user/client authentication– DoS from external entities– DoS by compromising internal entities

• Intrusion tolerance systems emerging from this study will be able to deal with previously unknown attacks as long as they produce similar impacts on our services


Case Study: ASP Vulnerability in IIS

• Sample file showcode.asp is meant for viewing source code of sample application through a web browser

• File showcode.asp doesn’t perform adequate security checking (no test for “..” in URL) so that anyone with a web browser can view any text file on the web server by using URL:

http://target/msadc/Samples/SELECTOR/showcode.asp?source=/path/filename

• Direct impact is compromise of confidentiality, and it

leaves system in vulnerable state.


Case Study: ASP Vulnerability in IIS (cont’d)

G

TR

A

V

F

MC UC

FS GD

showcode.aspis present

transparentrecovery

detectedbefore attack

recovery withoutdegradation

undetectedbut masked

1

fail-securemeasure degradation

graceful

undetectednon-maskable

showcode.aspnot present

22

2

2

1. Malicious input form of http://target/msadc/Samples/SELECTOR/showcode.asp?source=/path/filename

2. Restoration, reconfiguration mechanisms including remove showcode.asp, or restrict access only to /msadc as intended


Acceptance Monitor Model

• In traditional fault tolerance context: an acceptance test is a developer-provided error detection measure for a software module.

• In SITAR project, we perform both reactive and proactive acceptance test

• Reactive tests include:– satisfaction of system requirement– accounting test– reasonableness test


Acceptance Monitor Architecture

AdaptiveReconfiguration

Security PolicyDatabase

S1

S2

Sn

COTS Server

proactive probing

pre-definedacceptance test

responseshared stateinformation space

(with proxy servers)exchange session info

failure/compromisedcomponent trigger

AcceptanceTest Module

Health Monitor(proactiveprobing)


Acceptance Monitor: Example Test

• Probing analysis to COTS server will set up site-specific policy database, which indicates that certain document root

• If a file requested is outside of scope configured, then we will drop this connection and trigger the alarm to re-configuration module to do further situation evaluation

• Noted that we don’t need to know beforehand the showcode.asp vulnerability in this case


FY-2001 Plans

• Develop a model of intrusion tolerance– Threat model– ITS architecture– Analysis/simulation-based tradeoff studies for different

strategies

• Submit preliminary architectural report• Create a prototype intrusion tolerant Web server system• Evaluate the prototype through experimental

measurements/simulation/analytical models

sitar: a scalable intrusion tolerant architecture for distributed services

Documents