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

1 / 34
About This Presentation
Title:

SITAR: A Scalable Intrusion Tolerant Architecture for Distributed Services

Description:

OASIS 2002 Summer PI Meeting. 4. Progress Status ... Modify SRN to include token color. ... Dynamic HTML: A combination of HTML 4.0, Style Sheets and JavaScript. DHTML ... – PowerPoint PPT presentation

Number of Views:59
Avg rating:3.0/5.0
Slides: 35
Provided by: anr45
Category:

less

Transcript and Presenter's Notes

Title: SITAR: A Scalable Intrusion Tolerant Architecture for Distributed Services


1
SITAR A Scalable Intrusion Tolerant Architecture
for Distributed Services
  • Dr. Feiyi Wang
  • Advanced Networking Research
  • MCNC Research Triangle Park, NC

Dr. Bahrat Madan Electrical Engineer
Department Duke University, NC
2
Service Oriented Solution
Servers
Clients
Servers
3
JavaSpaceTM Based Organization
COTS Servers
Acceptance Monitor
Ballot Monitor
Proxy Server
Server Wrapper
Incoming Requests
Adaptive Reconfiguration
Audit Monitor
4
Progress Status
  • Performance Study (JavaSpace SITAR
    implementation)
  • Adaptive Reconfiguration Simulator
  • Performance Security Modeling
  • Dynamic Content Checking

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
6
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
7
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
8
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
40
30.93
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
9
Adaptive Reconfiguration Simulation
10
ARM Simulation
  • ARM Goals maximum performance (low threat)
    maximum availability (high threat)
  • Simulation Goal examine ARM model and algorithm
    in a controlled environment

11
ARM Model
Run time updates
Assessment
Reconfiguration Directives
Anomaly Events
Allocation Decision
Application Models
New Resource Allocations
Evaluation Results
Evaluation
12
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

13
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

14
Measurement Connection Processing
15
Measurement Threat Level Change
Reconfiguration Period 12 time units (52 - 64)
Reconfiguration Period 8 time units (52 - 60)
16
Measurement Initial Conditions
17
Lesson Learned
  • Ripple effect of reconfiguration
  • Sensitivity of reconfiguration parameter
  • Minimize reconfiguration period
  • Care must be taken to decide when reconfiguration
    happens

18
Performance Modeling
19
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

20
Event timeline for single request
21
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

22
Pure-performance SRN
23
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)

24
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.
25
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.

26
Dynamic Content Verification
27
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

28
Dynamic Content Verification Alternative Choice
29
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
30
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

31
Modularization of SITAR
Capability Profile
Module Configuration
Local Policy (GUI Control)
Running Profile
SITAR Modules
32
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 DSN02 and
    its companion intrusion tolerance workshop

33
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

34
Thank You!
Write a Comment
User Comments (0)
About PowerShow.com