DARPA OASIS PI Meeting – Santa Fe – July 24-27, 2001Slide 1 Aegis Research Corporation Not for Public Release Survivability Validation Framework for Intrusion Tolerance Using Masking, Redundancy and Dispersion DARPA OASIS PI Meeting – Santa Fe – July 24-27, 2001 Janet Lepanto William Weinstein The Charles Stark Draper Laboratory, Inc. Aegis Research Corporation ® Aegis Research Corporation

DARPA OASIS PI Meeting – Santa Fe – July 24-27, 2001Slide 2 Aegis Research Corporation Not for Public Release Overview Technology description and survivability problem addressed Assumptions Impairments: threats, attacks, vulnerabilities –Design/implementation –Configuration/operation Survivability attributes Comparison with other systems Survivability mechanisms Rationale –Goal vs. impairment matrix –Verification techniques Residual risks, limitations, caveats Cost/benefit analysis

DARPA OASIS PI Meeting – Santa Fe – July 24-27, 2001Slide 3 Aegis Research Corporation Not for Public Release Technology Description and Survivability Problem Addressed Apply fault-tolerant design concepts to provide intrusion tolerance for a “service” site that supports external clients with web-based access to information, databases, and applications services Minimize loss of data confidentiality and integrity in the face of a successful attack on one of the servers Tolerate attacks whose specific signatures are not known a priori Employ only a small set of trusted components to protect a large set of untrusted unmodified COTS servers and databases Employ redundancy for both intrusion tolerance and performance

DARPA OASIS PI Meeting – Santa Fe – July 24-27, 2001Slide 4 Aegis Research Corporation Not for Public Release Nominal Site Configuration External WAN External Firewall Data Base Transaction Mediator Gateway Switched IP Server (1) Server (N) Server (2) Configuration Manager Authenti- cation Server Switched IP COTS Trusted Other

DARPA OASIS PI Meeting – Santa Fe – July 24-27, 2001Slide 5 Aegis Research Corporation Not for Public Release Technical Approach Mask fingerprints of gateway and origin servers so that an attacker cannot probe over network to determine –OS of gateway, or origin servers –Implementation of any origin server Distribute each client’s transactions among origin servers such that the client cannot predict which server will handle a transaction Periodically inspect each origin server for configuration anomalies that might indicate that attack transactions have occurred –Reconfigure server to “clean” state if anomalies are detected Log transactions to back-end database so that data written by a compromised origin server can be reconstructed

DARPA OASIS PI Meeting – Santa Fe – July 24-27, 2001Slide 6 Aegis Research Corporation Not for Public Release Assumptions

DARPA OASIS PI Meeting – Santa Fe – July 24-27, 2001Slide 7 Aegis Research Corporation Not for Public Release Impairments: Threats, Attacks, Vulnerabilities

DARPA OASIS PI Meeting – Santa Fe – July 24-27, 2001Slide 8 Aegis Research Corporation Not for Public Release Survivability Attributes Protects the confidentiality (C) and integrity (I) of site data from stealthy attacks emanating from an external network Does not address authentication (AU) Does not address non-repudiation (NR) DoS attack considerations –Redundancy of Origin Servers provides a second order benefit –Taking servers off-line when an anomaly is detected creates a potential vulnerability (which is mitigated by smart configuration management)

DARPA OASIS PI Meeting – Santa Fe – July 24-27, 2001Slide 9 Aegis Research Corporation Not for Public Release Comparison with Other Systems Existing systems/practices –Address known threats, attack profiles and vulnerabilities to achieve confidentiality, integrity, authentication and non-repudiation –Require significant/costly modifications to COTS systems, (e. g., operating system modifications, special network cards) –Do not address vulnerabilities or attacks that are unknown a priori

DARPA OASIS PI Meeting – Santa Fe – July 24-27, 2001Slide 10 Aegis Research Corporation Not for Public Release Survivability Mechanisms

DARPA OASIS PI Meeting – Santa Fe – July 24-27, 2001Slide 11 Aegis Research Corporation Not for Public Release Survivability Mechanisms (cont’d)

DARPA OASIS PI Meeting – Santa Fe – July 24-27, 2001Slide 12 Aegis Research Corporation Not for Public Release Rationale: Goal vs. Impairment Matrix

DARPA OASIS PI Meeting – Santa Fe – July 24-27, 2001Slide 13 Aegis Research Corporation Not for Public Release Rationale: Verification Verification techniques Subjecting the system to known scanning tools to determine if the mechanisms to thwart those scans are implemented properly Subjecting the system to known attacks to evaluate how it reacts to various types of attacks (e. g., measuring the relative time to success for an attack directly on server X vs. the same attack on server X operating in our OASIS architecture). Subjecting the system to modifications of known attacks developed to exploit knowledge of the architecture and operation of the system Metrics –Impact of Draper-Aegis OASIS mechanisms on resistance to attack –Relative time to achieve successful attacks

DARPA OASIS PI Meeting – Santa Fe – July 24-27, 2001Slide 14 Aegis Research Corporation Not for Public Release Residual Risks, Limitations, Caveats Forms-based HTML provides external client access to back-end database, and also can move files between clients and back-end file systems, and support interactions between clients and back-end applications –S ignificant system functionality and flexibility can be provided by the HTTP protocol –Utility of dispersion w.r.t. other protocols is TBD Need to evaluate if/to what extent Gateway and the Transaction Mediator could be bottlenecks for high performance sites If rollback is done only for transactions from compromised server, no guarantee that information in the database will remain self-consistent

DARPA OASIS PI Meeting – Santa Fe – July 24-27, 2001Slide 15 Aegis Research Corporation Not for Public Release Cost/Benefit Analysis Time –Attacker is delayed –Attacker must complete exploit within bounded window to avoid detection Development –One-time development cost of trusted elements and agent software for origin server platforms Implementation –Acquisition and implementation incur cost of redundant origin servers and trusted elements (compared to cost of functionally equivalent site without our mechanisms) Operation –Maintenance cost of maintaining redundant origin servers and trusted elements scales with number of redundant versions Functionality Impact –Development cost to accommodate additional protocols Responsiveness of system –Transaction delays induced by proxy operations have negligible impact due to hardware speed