SITAR: A Scalable Intrusion Tolerant Architecture for Distributed Services

1. SITAR: A Scalable Intrusion Tolerant Architecture for Distributed Services Prof. Kishor S. Trivedi Electrical Engineer Department Duke University, NC Dr. Feiyi Wang Advanced Networking Research MCNC Research Triangle Park, NC

2. SITAR Approach Highlights • SITAR intrusion tolerance capability is focused on a generic class of servicesas 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 Project Briefing

3. Proxy Ballot Acceptance COTS Servers Servers Monitors Monitors P B A S 1 1 1 1 Protected P B A S Users/Clients 2 2 2 2 P B A S u v m n Audit Adaptive Control Reconfiguration request responses control SITAR Architecture SITAR Project Briefing

4. Service Oriented Problem Clients Servers SITAR Project Briefing

5. SITAR Community Service Oriented Solution Servers Clients Servers SITAR Project Briefing

6. 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 SITAR Project Briefing

7. JavaSpaceTM Based Organization COTS Servers Acceptance Monitor Ballot Monitor Proxy Server Server Wrapper Incoming Requests Adaptive Reconfiguration Audit Monitor SITAR Project Briefing

8. 6 • Module Type • Module Name • Connection ID • Index Work Order Acknowledgement • Module Type • Connection ID • Index • Sequence Number Work Order Request 5 7 8 • Remote/Local Address • Sequence Number • Array of Proxy • Array of Acceptance • Array of Ballot Monitor • Number of allocated acceptance • Number of allocated ballot • Number of allocated wrappers • Number of allocated COTS Connection Object Worker Inventory Response 1 4 2 3 Worker Inventory Request Connection Setup Protocol Ballot Monitor Acceptance Monitor Proxy Server Server Wrappers Adaptive Reconfiguration SITAR Project Briefing

9. 8 • Response number • Response itself • Response completed (Boolean) • Connection completed (Boolean) • Redundancy index number • Redundancy index number • Request number • Begin/End response number • Valid (Boolean) Validation Report Chosen Response 9 6 7 5 • Request Sequence Number • Request itself • Connection completed (Boolean) • Request completed (Boolean) • Most recent request number • Response number • Response itself • Redundancy index number • Connection completed (Boolean) Client Request Client Response 1 4 2 3 Data Flow Protocol Ballot Monitor Proxy Server Acceptance Monitor Server Wrappers 2 SITAR Project Briefing

10. Heartbeat Generator SITAR JavaSpace Heartbeat Monitor Configuration Manager Module Coordination of Multiple Components 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 SITAR Project Briefing

11. Java Virtual Machine (JVM) Java Virtual Machine (JVM) Secure Socket Layer (JSSE) Secure Socket Layer (JSSE) Extended Trust Manager Extended Trust Manager Secure SITAR over Yalta Jini Lookup Services (Reggie) SITAR service components (eg. ARM, AM, ACM, BM) JavaSpace service components RMI over SSL Certificate Revocation Agent PKI Space Threshold CA Yalta Space SITAR Project Briefing

12. Can SITAR Deal With Code Red? SITAR Project Briefing

13. SITAR Community SITAR Community Cope With DDOS Attack Black Hole Effect SITAR Project Briefing

14. Demonstration Against Code Red Acceptance Test: detect unmatched hash value and invalid header Majority Voting: Detect one faulty node (responses) out of three Acceptance Monitor Apache Ballot Monitor Outgoing Responses Proxy Server Server Wrapper Emulated IIS Incoming Requests Adaptive Reconfiguration Apache Audit Monitor Allocating Resources: may not allocate IIS server at all Performance monitor agent: detect resource depletion SITAR Project Briefing

15. Status Summary • Delivered preliminary architecture report • Developed 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 publication • Submitted 2 papers to DSN’02 and its companion intrusion tolerance workshop SITAR Project Briefing

16. Modeling and Quantification of Security Attributes • 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. SITAR Project Briefing

17. Proposed Approach • 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 SITAR Project Briefing

18. Related work • 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/l is the mean. • Mean effort required to cause a security failure. Similar to the • the notion of MTTF SITAR Project Briefing

19. Stochastic model • 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. SITAR Project Briefing

20. State transition model for security SITAR Project Briefing

21. Non-Markovian Behavior • Prior studies show that a typically an ensemble of attackers • exhibit behavior comprising of three phases: • Learning phase • Standard attack phase • 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. SITAR Project Briefing

22. Semi-Markov Processes (SMP) • A semi-Markov process is characterized by: • Transition probabilities • Sojourn time distributions in different states • The security quantification problem can be partitioned into phases • Stochastic model (SMP) • Model parameters • Model analysis and validation • Result interpretation X SITAR Project Briefing

23. SMP Modeling parameters Parameters: hG, hV; da, a, m, dt, s, g, b pa, pu, pm, pg, ps hG hV da a m s dt g b SITAR Project Briefing

24. SMP for the Syn Flood DoS sattack Available states: {G,V,A} Availability = pG+ pV+ pA SITAR Project Briefing

25. Security Quantification: Solving the SMP model • Steady-state probabilities, pG ,pV …, pF • Probability of reaching any security failed state • {UC, FS, GD, F} : security failed states. • Availability analysis • Time to reach any security failed state (MTTSF) • At the end of absorption, probabilities of reaching UC, FS, FD or F. Different failed states may imply different type of security compromise. SITAR Project Briefing

26. 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. SITAR Project Briefing

27. 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; a-1 =0.25; b-1 = 2; g-1 = 4; m-1 = 0.5; s-1 =0.25; da-1 =0.25; dt-1 =1/6 SMP steady-state probabilities: pG = 0.3386; pV = 0.2257; pA = 0.1333; pMC = 0.0201; pUC = 0.2167; pTR = 0.0667; pFS = 0.0200; pGD = 0.0406; pF = 0.0067; MTTSF : 3.5595, etc. SITAR Project Briefing

28. 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 = |li dM / dli | SITAR Project Briefing

29. 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. SITAR Project Briefing

30. 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 Project Briefing