Autonomic Recovery of Enterprise-wide Systems After Attack or Failure with Forward Correction

1. Autonomic Recovery of Enterprise-wide Systems After Attack or Failure with Forward Correction Anup Ghosh & Sushil Jajodia Center for Secure Information Systems George Mason University and Peng Liu Penn State University and Angelos Keromytis, Sal Stolfo, Jason Nieh Columbia University

2. Team George Mason University • Dr. Anup K. Ghosh, GMU • Dr. Sushil Jajodia, GMU • Dr. Angelos Stavrou, GMU • Dr. Yih Huang, GMU • 4 PhD students Penn State University • Dr. Peng Liu, PSU • 4 PhD students Columbia University • Dr. Angelos Keromytis, Columbia University • Dr. Salvatore Stolfo, Columbia University • Dr. Jason Nieh, Columbia University • 4 PhD & 1 MSc students supported by MURI

3. Scientific Objective Objective • Develop self-regenerative enterprise networks that recover and re-constitute themselves after attacks and failures • Develop uninterruptible server systems that provide service through attack • Automatically recover corrupted systems & databases after attack • Automatically regenerate software patches to make systems more robust after attack. Technical Approach: • Develop a layered approach to self-regenerative systems: • application-level resilience using error virtualization and rescue points • system-level resilience using virtualization and transaction semantics for programs to roll back system state to the last known good continuation point • dynamic patching of applications to improve resiliency after attack • roll forward with correction to quarantine tainted processes and files & back-out changes

4. Scientific Foundation Challenges • Software complexity makes perfection unattainable • As a result buggy software is deployed in mission-critical systems • When software flaws are triggered, systems crash or are exploited for malicious gain Foundational Principles • Build secure, reliable systems from imperfect components • Develop mechanisms that allow software to learn from attacks and adapt stronger variants • Provide recovery mechanisms that will auto-recover corrupted systems & data

5. Database Files Enterprise-Wide Attack Resilience Content Anomaly Detection ASSURE Attack Resilient dB Web services Uninterruptible Server DBMS service Application service processes • Document-centric active content protection • Efficient Online recovery after infection

6. Enterprise-Wide Components • Application-level resilience using error virtualization and rescue points (Columbia U) • Uninterruptible server resilience using virtualization and automatic feedback control (GMU) • Server Damage Assessment (PSU) • Self-healing database to track damage, quarantine tainted records, and repair damage (PSU/GMU) • Document-centric active content protection for users (GMU) • Efficient online recovery of infected systems after attack (GMU)

7. The Risk of Active Content • Active content appears like data often from untrusted sources, but executes like programs, usually unbeknownst to the user • Active content is used in Web browsers, Adobe PDF and Flash players, Apple Quicktime videos, Microsoft Office documents • Vulnerabilities in any of these host applications can be exploited by active content to run commands on the host • Active content can compromise other related documents

8. Active Data Frequently Used Web Contents are active for embedded javascripts We don’t use goodold-fashioned textfiles frequently now. Office documentsoften include visual basic macros Many multimedia formatssupport scripting too

9. Approach: Isolation for Active Content Documents • A fundamental principle in traditional OS security: Isolation. • Each process resides in isolated virtual memory space • Inter-process communications, if necessary, must be explicitly setup by programmers • Since active content documents can take actions on its own host processes and documents, we develop a technique to isolate them from each other and the rest of the system.

10. Active Content Isolation Requirements • Each active content document must be processed in its own Virtual Execution Environment (VEE). • If three Office documents are currently opened, there must be three VEEs for each of them, each running its own Office instance • If interactions between active contents are necessary, they must be explicitly granted and setup by users/administrators. • Must be done with minimal additional performance overhead

11. Containment via Lightweight Virtualization for Active Content Documents • Implement lightweight virtualization on a document-centric basis to isolate documents in separate process namespaces • Low overhead approach because of single kernel • Each lightweight VEE, or Container, has its own process, user, IPC namespaces, just like a VM. • Containers are resource efficient --- We are able to launch 100 Firefox containers without causing swapping on a 4GB desktop. • Examples: OpenVZ and VServer on Linux, Solaris Zone, BSD Jail (We use OpenVZ)

12. Seamless User Experience Entire desktopis in a Home Container Common utilities and passive files processed by the Home Container FFX Container Per documentOffice Container Per video clipmplayer container

13. Properties of Solution • Document-centric view for virtualization, rather than OS or application-centric. • Versioning and recovery are provided for local documents • Online active content (e.g., web pages) • Isolated from the rest of the system but not from each other. • Isolating web content from each other is a separate research branch.

14. Document Containers • Created on demand based on a template • Creation time is approximately 1 second. • A Container sees only the files the user wants it to see. • Clicking on an office document, a new container is created. • The container sees only the given file • Unless explicitly set up, containers cannot communicate with each other. • Actually, they don’t even know the existence of others.

15. Prototype Progress • Created a home container running gnome desktop • The X server runs on the host and is considered trusted • Clicking on an active document in the home container will automatically launch a new container granted access to that file only • Internet applications are all executed in separated containers • Firefox, OpenOffice, Thunderbird, Adobe, mplayer containers created. • Opening OpenOffice and PDF files automatically redirect to new containers • Current limit: only one container can use the audio device at a time. • May move to a sound server solution later.

16. Discussion aghosh1@gmu.edu