SITAR: A Scalable Intrusion Tolerant Architecture for Distributed Services

1. 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

2. SITAR Community Service Oriented Solution Servers Clients Servers OASIS 2002 Summer PI Meeting

3. JavaSpaceTM Based Organization COTS Servers Acceptance Monitor Ballot Monitor Proxy Server Server Wrapper Incoming Requests Adaptive Reconfiguration Audit Monitor OASIS 2002 Summer PI Meeting

4. Progress Status • Performance Study (JavaSpace & SITAR implementation) • Adaptive Reconfiguration Simulator • Performance & Security Modeling • Dynamic Content Checking OASIS 2002 Summer PI Meeting

5. 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

6. 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

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 OASIS 2002 Summer PI Meeting

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

9. Adaptive Reconfiguration Simulation

10. 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

11. 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

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 OASIS 2002 Summer PI Meeting

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 OASIS 2002 Summer PI Meeting

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 OASIS 2002 Summer PI Meeting

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 OASIS 2002 Summer PI Meeting

20. Event timeline for single request

21. 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

22. Pure-performance SRN OASIS 2002 Summer PI Meeting

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) OASIS 2002 Summer PI Meeting

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. OASIS 2002 Summer PI Meeting

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 OASIS 2002 Summer PI Meeting

28. Dynamic Content Verification: Alternative Choice OASIS 2002 Summer PI Meeting

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 OASIS 2002 Summer PI Meeting

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 OASIS 2002 Summer PI Meeting

31. Modularization of SITAR Capability Profile Module Configuration Local Policy (GUI Control) Running Profile SITAR Modules OASIS 2002 Summer PI Meeting

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 DSN’02 and its companion intrusion tolerance workshop OASIS 2002 Summer PI Meeting

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 OASIS 2002 Summer PI Meeting

34. Thank You!