SITAR: A Scalable Intrusion Tolerant Architecture for Distributed Services

1. SITAR: A Scalable Intrusion Tolerant Architecture for Distributed Services Feiyi Wang, MCNC Kishor Trivedi, Duke University

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

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

4. 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”?

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

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

7. Proposed Architecture

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

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

10. State Transition Diagram for ITS G - good state V - vulnerable state A - active attack state MC - masked compromised state UC - undetected compromised state TR - triage state FS - fail secure state GD - graceful degradation state F - failed state

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

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

13. Case Study: ASP Vulnerability in IIS (cont’d) 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

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

15. Acceptance Monitor Architecture

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

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