sitar a scalable intrusion tolerant architecture for distributed services
Download
Skip this Video
Download Presentation
SITAR: A Scalable Intrusion Tolerant Architecture for Distributed Services

Loading in 2 Seconds...

play fullscreen
1 / 34

SITAR: A Scalable Intrusion Tolerant Architecture for Distributed Services - PowerPoint PPT Presentation


  • 62 Views
  • Uploaded on

SITAR: A Scalable Intrusion Tolerant Architecture for Distributed Services. Dr. Bahrat Madan Electrical Engineer Department Duke University, NC. Dr. Feiyi Wang Advanced Networking Research MCNC Research Triangle Park, NC. SITAR Community. Service Oriented Solution. Servers. Clients.

loader
I am the owner, or an agent authorized to act on behalf of the owner, of the copyrighted work described.
capcha
Download Presentation

PowerPoint Slideshow about ' SITAR: A Scalable Intrusion Tolerant Architecture for Distributed Services' - cally-camacho


An Image/Link below is provided (as is) to download presentation

Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.


- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -
Presentation Transcript
sitar a scalable intrusion tolerant architecture for distributed services

SITAR: A Scalable Intrusion Tolerant Architecture for Distributed Services

Dr. Bahrat Madan

Electrical Engineer Department

Duke University, NC

Dr. Feiyi Wang

Advanced Networking Research

MCNC Research Triangle Park, NC

service oriented solution

SITAR Community

Service Oriented Solution

Servers

Clients

Servers

OASIS 2002 Summer PI Meeting

javaspace tm based organization
JavaSpaceTM Based Organization

COTS Servers

Acceptance

Monitor

Ballot

Monitor

Proxy

Server

Server

Wrapper

Incoming Requests

Adaptive

Reconfiguration

Audit

Monitor

OASIS 2002 Summer PI Meeting

progress status
Progress Status
  • Performance Study (JavaSpace & SITAR implementation)
  • Adaptive Reconfiguration Simulator
  • Performance & Security Modeling
  • Dynamic Content Checking

OASIS 2002 Summer PI Meeting

performance impact of entry size

9

8

7

6

5

write

4

read

take

3

2

1

0

1

2

3

4

5

Performance Impact of Entry Size

time (ms)

entry size (K)

90

80

70

60

time (ms)

50

read

40

take

write

30

20

10

entry size (K)

0

0

10

20

30

40

50

60

70

80

90

100

OASIS 2002 Summer PI Meeting

impact of number of entries

4

4

4

4

4

4

4

4

4

4

4

4

4

4

4

4

4

4

4

4

4

4

4

4

4

4

4

4

4

4

4

9

9

9

9

9

9

9

9

9

9

9

9

9

9

9

9

9

9

9

9

9

9

9

9

9

9

9

9

9

9

9

0

0

0

0

0

1

1

1

1

1

2

2

2

2

2

3

3

3

3

3

4

4

4

4

4

5

5

5

5

5

1

3

5

7

9

1

3

5

7

9

1

3

5

7

9

1

3

5

7

9

1

3

5

7

9

1

3

5

7

9

Impact of Number of Entries

65

60

55

50

45

40

35

time (ms)

30

write

25

read

20

take

15

10

5

0

4

4

4

4

4

4

4

4

4

4

4

4

4

4

4

4

4

4

4

9

9

9

9

9

9

9

9

9

9

9

9

9

9

9

9

9

9

9

6

6

6

6

6

7

7

7

7

7

8

8

8

8

8

9

9

9

9

9

1

3

5

7

9

1

3

5

7

9

1

3

5

7

9

1

3

5

7

9

number of entries

OASIS 2002 Summer PI Meeting

impact to sitar system
Impact to SITAR System

225

207.12

200

181.99

175

140.57

150

126.13

125

time (ms)

100

86.11

66.33

75

58.99

52.66

50

23.64

25

0

1.AcptW

2.AcptW

3.Client

4.AcptR

5.Client

6.Client

7.ValRe

8.ValRe

9.Chose

OR wrt

OR

Req

eq wrt

Res wrt

Res

p wrt

p read

nRes

taken

read

read

wrt

SITAR Operational Steps: A Break Down

OASIS 2002 Summer PI Meeting

impact to sitar system persistent worker
Impact to SITAR System (Persistent Worker)

200

Persistent Worker

Improves performance

181.44

180

151.77

160

140

114.39

120

time (ms)

94.68

100

80

69.33

68.01

68.03

60

60

35.46

30.93

40

20

0

1.AcptW

2.AcptW

3-1.

3-2.

4.AcptRe

5.ClientR

6.ClientR

7.ValRep

8.ValRep

9.Chosen

OR wrt

OR taken

ClReq

ClReq

q wrt

es wrt

es read

wrt

read

Res wrt

(before)

(after)

SITAR Operational Steps: A Break Down

OASIS 2002 Summer PI Meeting

arm simulation

Request

Response

Client

BM

PM

WM

AM

Server

ARM Simulation
  • ARM Goals: maximum performance (low threat); maximum availability (high threat)
  • Simulation Goal: examine ARM model and algorithm in a controlled environment

OASIS 2002 Summer PI Meeting

arm model
ARM Model

Run time

updates

Assessment

Reconfiguration

Directives

Anomaly

Events

Allocation

Decision

Application

Models

New Resource

Allocations

Evaluation

Results

Evaluation

OASIS 2002 Summer PI Meeting

simulation framework
Simulation Framework
  • Key definition
    • Resource Container (RC)
    • Resources (RES)
  • Key events
    • Threat level: manual injection or dynamically changes by trigger events
    • Trigger processing (performance, security)
    • Status Change

OASIS 2002 Summer PI Meeting

configurations
Configurations
  • Configuration
    • 0 : 1 PS, 1 WM, 1 AM, 1 BM
    • 1 : 1 PS, 3 WM, 1 AM, 1 BM (not for real system)
    • 2 : 1 PS, 3 WM, 2 AM, 3 BM (not for real system)
    • 3 : 1 PS, 2 WM, 2 AM, 1 BM (alternative to 1 & 2)
    • 4 : 1 PS, 3 WM, 3 AM, 3 BM

OASIS 2002 Summer PI Meeting

measurement threat level change
Measurement: Threat Level Change

Reconfiguration Period: 12 time units (52 - 64)

Reconfiguration Period: 8 time units (52 - 60)

lesson learned
Lesson Learned
  • Ripple effect of reconfiguration
  • Sensitivity of reconfiguration parameter
  • Minimize reconfiguration period
  • Care must be taken to decide when reconfiguration happens

OASIS 2002 Summer PI Meeting

performance security modeling
Performance + Security Modeling
  • Pure Performance
  • Performance in the presence of security threats and security failures
  • Use of analytical models
    • Stochastic Reward Net (SRN)
  • Parameterization of these models
    • Transition rates, branching probabilities, distributions etc

OASIS 2002 Summer PI Meeting

performance variables
Module delays

PM_NewConn_WIReq

ARM_WIReq_WIRsp

PM_WIRsp_WOReq

AM_WOReq_ARE

WM_ARE_CRsp

AM_CRsp_VRep

BM_VRep_ChRsp

PM_ChRsp_Clnt

JavaSpace delays

JSD_PM_ARM_WIReq

JSD_ARM_PM_WIRsp

JSD_PM_AM_WOReq

JSD_AM_WM_ARE

JSD_WM_AM_CRsp

JSD_AM_BM_VRep

JSD_BM_PM_ChRsp

Performance Variables

OASIS 2002 Summer PI Meeting

pure performance srn
Pure-performance SRN

OASIS 2002 Summer PI Meeting

combining performance and security model
Combining performance and security model
  • Current Assumptions
    • One COTS server and one AM
  • Security states in SITAR system
    • UP
    • GD (Graceful Degradation)
    • F (Fail)
    • FS (Fail Safe)
    • UC (Unmasked Compromise)
    • MC (Masked Compromise)

OASIS 2002 Summer PI Meeting

single cots performance security
Single COTS: Performance + security

Performance SRN

1. Security model SRN

2. Places denote security states

3. Transitions model changes in security States.

4. Two models are coupled by the enabling functions.

multiple cots
Multiple COTS
  • Conventional SRN: problem of token matching.
  • Colored Petri net: Different requests are assigned different color.
  • Modify SRN to include token color.
  • ‘Place’ incorporates a FCFS queue that makes possible to combine tokens from the same request.

OASIS 2002 Summer PI Meeting

dynamic content verification what about html
Dynamic Content Verification: What About HTML?
  • A mixture of tags for (1) encoding of format; (2) encoding of layout; (3) encoding of types of information content
  • While HTML can be described using a DTD, the vast majority of HTML on the Web is invalid
  • Fundamental limitation: lack of reliable, semantic encoding

OASIS 2002 Summer PI Meeting

dynamic content verification challenges
Dynamic Content Verification: Challenges
  • Confidentiality -- No one else can access or copy the data
  • Integrity -- The data isn\'t altered as it goes from the sender to the receiver
  • Authentication -- The document actually came from the purported sender
  • Nonrepudiability -- The sender of the data cannot deny that they sent it, and they cannot deny the contents of the data
  • Availability/Tolerance Capability – Continued service even when servers partially failed

SSL

XML

Digital

signature

SITAR

OASIS 2002 Summer PI Meeting

special considerations
Special Considerations
  • Differences that are not semantically significant
    • Order of elements
    • The amount of white space between attributes
    • Whether or not that default values of attribute are included in the source document
  • Solution: using Canonicalizer for preprocessing before digitally signed

OASIS 2002 Summer PI Meeting

modularization of sitar
Modularization of SITAR

Capability

Profile

Module

Configuration

Local Policy

(GUI Control)

Running

Profile

SITAR

Modules

OASIS 2002 Summer PI Meeting

current status summary
Current Status Summary
  • Delivered final architecture report
  • Developed share-space based framework where different types of components, multiple instances of components can collaborate and provide SITAR services and demonstrated basic functionalities
  • Presented 4 papers/fast abstracts to DSN’02 and its companion intrusion tolerance workshop

OASIS 2002 Summer PI Meeting

future work
Future Work
  • Near term
    • Refinement of architecture
    • Intelligent adaptive reconfiguration in action
    • Performance evaluation and improvement
  • Next Phase:
    • More intelligent ARM algorithm
    • Strengthen space-based security
    • Demonstrate support for other type of services

OASIS 2002 Summer PI Meeting

ad