Comparison of Intrusion Tolerant System Architectures

This article first appeared in IEEE Security & Privacy magazine and is brought to you by InfoQ & IEEE Computer Society.

With the advancing sophistication of security attacks, protecting open systems is increasingly challenging. Intrusion tolerance should be part of overall in-depth security. This article compares three types of intrusion-tolerant system architectures.

As computer systems become open to large populations of Web service users, protecting systems and users is becoming more daunting. Such systems could expose more system vulnerabilities. In addition, security attacks are becoming more sophisticated. Current intrusion prevention and detection methods simply are inadequate. Any approach to securing computer information systems should incorporate an intrusion tolerance system (ITS). To be more robust, such approaches should borrow from the architectures that we discuss here.

ITS Characteristics and Taxonomy

ITS architectures often are based on fault tolerance. To fend off malicious faults, ITSs employ redundancy, diversity, and reconfiguration of services, components, and servers. Defending against malicious faults ensures that the system will continue to provide services even in the presence of an intrusion. The overall ITS architecture is intended to remove unwanted intrusions and restore the system to its normal state.

For ITS architectures, we propose a simple taxonomy with four categories: detection triggered, algorithm driven, recovery based, and hybrid. Using this approach, we now classify ITS architectures, including several that were part of DARPA's Oasis (Organically Assured and Survivable Information Systems) project. [1]

Detection Triggered

These architectures build multiple levels of defense to increase system survivability. Most of them rely on intrusion detection that triggers recovery mechanisms. Sitar (Scalable Intrusion-Tolerant Architecture) protects services provided by COTS servers against known and unknown external attacks, without modifying the servers.[1] Basically, Sitar detects compromises and adaptively reconfigures the compromised servers. An attack succeeds only if it can bypass three levels of detection and testing.

Dpasa (Designing Protection and Adaptation into a Survivability Architecture) protects assets by using multiple zones and layers to contain external attacks.[2 ]The host managing the security defense is in the innermost zone; proxies are further out to intercept incoming traffic. The architecture also includes network-based intrusion detection systems (IDSs).

The Willow architecture consists of mechanisms that detect malicious faults, analyze system vulnerabilities, and perform reconfiguration in a distributed computing environment.[3] Distributed intrusion-detection sensors monitor application hosts.

Focusing on database systems, Peng Liu and his colleagues proposed schemes to contain, eliminate, and repair damage caused to data by intrusions.1 All these schemes have a detection layer that alerts repairing components.

DIT (Dependable Intrusion Tolerance) is an adaptive architecture composed of a cluster of mediating proxies and a monitoring system that provides intrusion alerts.[4] The cluster also can detect anomalies on the basis of an agreement protocol.

Similarly, Hacqit (Hierarchical Adaptive Control of Quality of Service for Intrusion Tolerance) augments its intrusion detection capability (provided by IDS software packages) with an agreement-protocol variant.[5] ITSI (Intrusion-Tolerant Server Infrastructure) detects intrusions at the network layer.[6]

You measure detection-triggered systems' effectiveness by how difficult it is for an attacker to penetrate undetected multiple defense levels.

Algorithm Driven

These systems employ algorithms such as the voting algorithm, threshold cryptography, and fragmentation redundancy scattering (FRS) to harden their resilience.

Pasis (Perpetually Available and Secure Information Systems) uses a threshold secret-sharing scheme to encode and disperse data in survivable storage systems.[1] Increasing intrusion tolerance requires increasing the number of replicas and threshold numbers.

Maftia (Malicious and Accidental Fault Tolerance for Internet Applications)[7] is more subtle. Although it incorporates IDS sensors, it doesn't focus on IDS capability. Instead, it relies on authority and transaction management services that are developed on a platform of common services that provide voting algorithms and k-threshold cryptography.

Like Maftia, ITUA (Intrusion Tolerance by Unpredictable Adaptation) is middleware that adaptively protects applications at the object level by using protocols for group communications and cryptography.[8] Intrusion tolerance for Corba middleware is based on the principles of FRS, threshold cryptography, and the voting algorithms.[1] ITUA adapts cryptography techniques, challenge-response protocols, and k-security models to provide intrusion tolerance for wireless sensor networks.[9]

Finally, Tao Zhang and his colleagues showed how to secure software by applying secret sharing to compiler techniques.[10]

Recovery Based

Unlike the two previous types of architectures, recovery-based architectures assume that as soon as a system goes online, it's compromised. Periodic restoration to a known good state is necessary.

Khin Aung and her colleagues proposed software rejuvenation to limit the impact of software faults and aging, thus increasing cluster survivability.[11] They demonstrated this approach's benefits and analyzed the rejuvenation rate by using stochastic-process modeling.

SCIT (Self-Cleansing Intrusion Tolerance)[12] employs a group of servers with identical services, which may have some diversity. In this group of servers, round-robin cleansing restores the system to its pristine image. The Forever service removes faults by proactive reconfiguration implemented by robust underlying components.[13] Hans Reiser and Rudiger Kapitza implemented proactive recovery based on hypervisor virtualization.[14]

Hybrid

Paulo Sousa and his colleagues combined periodic system rejuvenation with reactive recovery.[15] Whereas rejuvenation is automatic, recovery occurs when the perceived threat exceeds a tolerable threshold that affects the system's correct functioning. COCA (Cornell Online Certification Authority) combines threshold cryptography and proactive secret sharing.[1]

Other Taxonomies

Other architecture-based taxonomies are possible. For instance, a taxonomy could be based on attack targets protected and hardened by ITSs. Such a target could be an application, middleware, a back-end database system, or a network infrastructure.

Our Qualitative-Analysis Methodology

In the next sections, we compare three representative architectures - Sitar, Maftia, and SCIT - by analyzing qualitatively how they achieve intrusion tolerance. To focus our analysis, we consider an Open Archival Information System (OAIS) with these functional requirements:

• Producers submit electronic records into archival storage.
• Consumers search and access records from archival storage.
• Administrators schedule and monitor record submission, and transform assets for electronic preservation. Asset metadata is stored in databases.
• The system deploys applications and Web services on application servers connected to a backend database and mass storage so that users can access the system through the Internet.

For the analysis, we use these measures and their related scenarios:

• Confidentiality. A hacker tries to gain unauthorized access to privacy data.
• Integrity. A hacker tries to corrupt records or associated metadata.
• Availability. A hacker tries to affect system availability by using an approach such as a denial-of-service (DoS) attack.
• Data exfiltration. A hacker tries to extract massive data from the system. For a large-scale archival system, this compromise is extremely severe.

We evaluate four architecture aspects. The first is how effectively the architecture protects against malicious faults, from the perspectives of the three pillars of information security: confidentiality, integrity, and availability. The second is how each architecture handles intrusion tolerance. The third is the performance impact in terms of latency. The fourth is how easily you can integrate the architecture with applications.

A Detection-Triggered Architecture

Sitar has five components (see Figure 1a): a proxy server, an acceptance monitor, a ballot monitor, an adaptive-reconfiguration module, and audit control. The Sitar components are deployed in front of the protected servers to intercept incoming and outgoing traffic.

(Click on the image to enlarge it)

Figure 1. The system architectures of (a) Sitar (Scalable Intrusion-Tolerant Architecture), (b) Maftia (Malicious and Accidental Fault Tolerance for Internet Applications), and (c) SCIT (Self-Cleansing Intrusion Tolerance). These examples are representative of detection-triggered, algorithm-driven, and recovery-based architectures, respectively.

The proxy server resides between all requesting clients and COTS servers that have the same functionality but different implementations. After passing through the proxies, incoming client requests are validated by the acceptance monitor, in which the test engine determines acceptance in accordance with rules preconfigured in a security policy database. Invalid requests aren't forwarded to the COTS servers; invalid responses from a COTS server trigger its reconfiguration.

On receiving the responses from the acceptance-monitor instances (Figure 1a, step 5), the ballot monitor adjudicates the final, correct response. To do this, it uses either a voting algorithm based on a simple majority or a more sophisticated Byzantine agreement. Before the voting, it calculates the transformations of the responses, using different checksum algorithms, depending on the security level. After the voting, it sends the final response to the proxy (step 6) to forward to the client (step 7).

The adaptive-reconfiguration module is the centralized control that performs adaptive reconfiguration for a given security threat level.

The audit control uses log analytics to facilitate protection of Sitar components against compromises.

Analysis

We must deploy Sitar's components preceding the OAIS so that all requests and responses go through Sitar.

Confidentiality. An unauthorized hacker attempts to access privacy data by using one of three methods.

First, the hacker might obtain a directory listing, a revealed path, or a file disclosure that could lead to privacy data when the hacker exploits software vulnerabilities in Web-based applications.[1] Because these vulnerabilities exhibit known patterns in the malicious requests' URLs, Sitar can incorporate rules to block these attacks.

Second, the hacker might overcome the validation related to the previous method. In this case, the acceptance monitor can check the responses from any Web servers and reject them. It does this by using its access checker [7] to verify the access privilege of a directory or file against the access rules in the security policy database.

Finally, a hacker might impersonate an authorized user by snooping on the communication line or obtaining the access control list stored in the system. However, both techniques require breaking cryptographic keys used in communication and password storage, which are related to prevention and system hardening and fall outside the scope of the Sitar architecture.

Integrity. A hacker can corrupt data in the OAIS by uploading a file into a directory and exploiting URL-related vulnerabilities. In this case, Sitar can stop the attack by using the same testing techniques it uses for the confidentiality scenario.

Assume that a hacker has successfully evaded acceptance testing and uploaded a file. The impact might be Web defacement. If a normal user tries to access the corrupted files, the Web server's response won't pass the acceptance monitor's code testing [1] because the corrupted file's checksum won't match the one in the acceptance monitor.

Availability. The timing test, which is a kind of reasonableness test, can detect a DoS attack.[1] Detection is successful because the Web servers are so overloaded that response times will exceed the expected values.

Data exfiltration. By running reasonableness tests based on a transfer's size, Sitar can detect attempted data exfiltration. We can configure the maximum size of data that the system can transfer out of the data repository. However, this might not prevent data exfiltration with a low rate but a long duration.

Discussion

In general, Sitar effectively helps a system survive malicious faults. The architecture offers three lines of defense: validation of incoming requests, acceptance testing of outgoing responses, and majority balloting. With majority balloting, the system can still function, even when an instance of a COTS server is compromised and undergoes reconfiguration. Balloting helps the system tolerate unknown attacks, whereas acceptance testing detects known intrusion patterns.

As the scenarios show, the architecture relies heavily on the acceptance monitor to detect intrusions. Some acceptance tests, such as the checksum test or timing test, are generic and can be applied to various types of applications. However, other tests such as URL-pattern tests are specific to an application, so implementing them in the security policy database is a challenge. Violation rules must be known in advance. So, maintenance should include monitoring the updates of vulnerability databases-for example, the National Vulnerability Database or BugTraq.

Sitar's tunable parameter is the number of COTS servers with the same functionalities. This number corresponds to that of the acceptance-monitor instances, each of which is configured to test a COTS server.

Reconfiguration occurs automatically through the audit control, which administrates all components in a consistent manner to achieve the desired quality of service (QoS). Reconfiguration can be adapted to the current threat to increase the intrusion tolerance level. The degree of intrusion tolerance is tunable according to a cost-versus-tolerance trade-off.

Because of the introduction of two extra hops and processing between the requests' originator and the application server, the service time incurs additional latency. This latency can increase if the ballot monitor uses more sophisticated hashing algorithms or the acceptance monitor performs more testing.

Integrating Sitar components in a system amounts to fronting it with a kind of proxy. Some network interface configuration is required, but there's no software change on the application side. The major effort lies in provisioning security rules.

An Algorithm-Driven Architecture

Maftia is based on the relationship between trust and trustworthiness. The degree to which component X satisfies the set of properties P is trustworthiness(X). Given components X and Y, X trust Y means that X accepts that failures of Y will compromise X. In a good design, the degree of X trust Y must be less than trustworthiness(X). Using this concept, the architecture builds layers of increasing degrees of trustworthiness, starting with trusted components in hardware hosts and networks.

The Maftia middleware (see Figure 1b) consists of services forming a runtime platform for applications.

Maftia's intrusion tolerance is based mostly on algorithms implemented in these services. Maftia runs on a system's native OS, a Java Virtual Machine, and a tamper-proof appliance board for TTCB (Trusted Timely Computing Base).

At the network level, the multipoint network lets hosts communicate in the trusted control channel.

The communications support services essentially are protocols that ensure secure, robust communication between components. Examples include the Byzantine-agreement protocol and a cryptosystem with secret sharing. The cryptosystem is characterized by a threshold T: the secret is shared between N (N > T) participants, and message decryption requires T + 1 valid shares.

Two important application support services are the authorization service and transaction service. The authorization service provides access control at the macro level, with the authorization server using the reference monitor to control multiple participants and the local host level. The transaction service ensures secure execution of transaction requests because of the collaboration of replicated transaction managers.

Analysis

OAIS applications must be implemented on top of Maftia middleware (in the applications layer in Figure 1b).

Confidentiality. Three scenarios are possible.

First, a hacker might try to exploit Web server vulnerabilities on the basis of URL patterns. This attack won't succeed because the authorization service has an instance of the reference monitor on each host to control resources and objects local to that host.

Second, the hacker might subvert the authorization service that controls macro-level access. However, because of the secret-sharing cryptosystem, the subversion is successful only if k authorization sites and k secret shares are compromised. Below those thresholds, Maftia will detect the attacks, triggering recovery of the compromised components.

Finally, the hacker might impersonate an authorized user by acquiring a smart card and guessing its PIN. However, Paulo Verissimo argued that, because of the trusted Java card, hackers can't subvert host authorization.[7]

Integrity. Two scenarios are possible.

First, the hacker might try to upload a file into a directory to deface the website. As we just discussed, the authorization service can use its local component to prevent the upload.

Second, the hacker might attempt to compromise an ongoing transaction by creating or updating metadata in the OAIS. Because of the redundancy of transaction managers and their secure group-communication service, Maftia will detect the corruption of metadata and restore it to the correct state. The Byzantine-agreement protocol implemented in the transaction managers will help detect compromised instances. In addition, the transaction still can be processed with the correct data, as long as the number of compromises is less than the tolerance threshold.

Availability. The authorization and transaction services aren't designed to fend off a DoS attack. Maftia's authors have proposed a distributed IDS service consisting of redundant sensors that detect DoS attacks.[7]

Data exfiltration. The methods used to detect compromises in the confidentiality scenario also might prevent data exfiltration attacks. However, given the specificity of these attacks, which focus on transferring large amounts of data, how Maftia can detect and contain loss in this scenario isn't clear.

Discussion

Maftia uses two actions to recover from error due to malicious or accidental faults.[7] First, it contains the error so that it can't propagate to other members par­ticipating in a transaction. Second, it recovers the cor­rupted member by reading stable members' states.

Maftia's intrusion tolerance approach is attractive for three reasons. First, because the architecture is based on the relationship between trust and trustworthiness, it can incorporate layers of security services that form a top-to-bottom fortress to protect applications.

Second, the approach offers a complete solution with an entire stack for ITS from local host machines, network devices and protocols, OS extensions, group protocols, and other trusted security services. How­ever, because of the architecture's completeness, you could argue that it's complex.

Finally, for its detection capabilities, Maftia re­lies on distributed protocols for voting and secret sharing. These support protocols are augmented by trusted hardware and the runtime environment at lower layers.

The tunable parameters for a Maftia architecture are the thresholds used in the Byzantine-agreement protocols and the secret-sharing cryptosystem. High­er threshold values increase the system's resilience.

Additional latency in the service time results from using multiple participants in the Byzantine-agreement protocol and secret-sharing cryptosystems.

To use Maftia, an application must be developed on its middleware platform, using its specified APIs and protocols.[7 ] This integration method seems intrusive. The integration cost might be higher than with other architectures, but the result is tighter, more complete integration with a trusted architecture.

A Recovery-Based Architecture

The SCIT model is applicable to servers that are open to the Internet, such as Web and Domain Name Sys­tem servers.[16] Because of round-robin cleansing, at any time, a server in an SCIT cluster can have one of three states: offline cleansing, online primary, and on­line backup. The duration over which an SCIT server is exposed to the Internet is its exposure time.

The architecture is simple and doesn't rely on intrusion detection. Figure 1c depicts the control­ler, with one online node serving incoming transac­tions, one node ready to be put online, and another in cleansing mode. The controller is SCIT's core com­ponent; it manages server rotation in and out of cleansing mode. The server rotation follows an al­gorithm that takes into account the group cardinal­ity, a server's cleansing-cycle time, and the number of required online servers. The controller algorithm's implementation is based on virtualization technology. The interfaces between the controller and the group of servers to be protected are trusted.

Analysis

To protect the OAIS, we must instantiate multiple Web servers and connect them to the controller.

Confidentiality. Because SCIT has no detection component, a pure SCIT-based system isn't hardened for attacks that can affect data confidentiality. However, the server instance's short exposure time limits such an attack's chances.

Integrity. Similarly, it isn't clear how SCIT can protect the system's integrity in a theoretical real-time model, in which attacks arrive in a continuous stream. In reality, intrusions are discrete events, separated by some time interval. Ensuring data integrity in an intrusion-tolerant system means that the system can be restored to pristine data and state. In this case, the system must have tamper-proof storage that plays the role of master data. The master storage is trusted and used to restore corrupted Web servers. Using a time-based signature system whose cycle corresponds with the rotation time makes it more difficult for an intruder to break the cryptosystem to access the data.

Anantha Bangalore and Arun Sood discussed how an SCIT-based Web server can tolerate Web-defacing attacks.16 Conceivably, you could extend their cleans­ing approach to a generic case in which data integrity is at risk. However, the architecture can limit the pos­sibility of a SQL injection attack but can't detect and stop it on the spot.

Availability. It isn't clear how SCIT-based systems can provide services with the required QoS when a DoS attack occurs, notably in the case of a flooding attack. However, a DoS attack's duration is limited to the Web server instance that's online at the time. SCIT recovers from failure every cycle. When self-cleansing starts the peer instance, the DoS attack will no longer be in effect.

Data exfiltration. The time-based paradigm enables SCIT to contain a data-exfiltration compromise. The smaller the exposure window is, the smaller the loss of data due to a data-exfiltration attack will be. This control can be quantified and managed according to a risk-acceptance policy.

Discussion

SCIT differs greatly from Sitar and Maftia in that it has no intrusion detection component. It assumes that a system always will have vulnerabilities and that suc­cessful attacks are inevitable. So, you can't qualitatively analyze its effectiveness in terms of vulnerabilities. In­stead, you must quantitatively evaluate the degree of intrusion tolerance in the context of how much the system can limit damages caused by malicious attacks and how much service availability the system offers users.[17] SCIT's authors have pointed out that nothing prevents an SCIT-based system from adding architec­tural constructs to adapt to an application's particular requirements. You can find examples in papers describ­ing SCIT architectures for DNSs18 and Web servers.[16]

By adding hardware-enforced security, SCIT can achieve incorruptible components to perform intru­sion tolerance and can increase system dependability.[12]

SCIT has three tunable parameters: the exposure time window, the cleansing time, and the total num­ber of nodes in the cluster. These parameters are inter­related. To satisfy a fixed value for the exposure time window, a longer cleansing time will require more nodes available for rotation.

Unlike Sitar and Maftia, SCIT doesn't require any extra hops or processing of an application trans­action. Switching a node from state to state and self-cleansing do require extraneous processing and computing resources. However, these operations occur out of band and don't interfere with the main data flow of the online node serving incoming traf­fic. Testing of an "SCIT-ized" Web server showed only a marginal increase in response time under load conditions.[16]

To SCIT-ize an application system, you must place the application server under the control of the con­troller that handles rotation management. Concep­tually, this integration is analogous to configuring a node under a system management server in the Simple Network-Management Protocol world. From an im­plementation perspective, no changes are required to the OS, application server, or application software. Integration effort should be light, compared to that for Maftia.

Comparison Summary

Table 1 summarizes the functional differences of the three ITS architectures and their efficiency for intru­sion tolerance and survivability.

Table 1. Comparing three intrusion-tolerant system architectures.

Future research on these architectures could focus on three areas:

• Some detection capability can complement SCIT to harden the confidentiality protection.
• Detection-based ITSs such as Sitar can exploit SCIT's self-cleansing approach for their components (proxies, ballot monitors, and acceptance monitors) and COTS servers. Applying SCIT to COTS serv­ers will eliminate the probing used to monitor the server's health.
• ITS architectures can leverage the relationship between trust and trustworthiness. For instance, com­munication between Sitar components can be built on a trusted infrastructure such as Maftia. SCIT's controller can interface with the cluster nodes through a trusted channel.

Researchers could exploit the three approaches' synergetic strengths to design a more comprehensive architecture. We're starting to see hybrid architectures such as the proactive and reactive recovery scheme.[15 ]

Acknowledgments

US National Science Foundation grant 0940922 and US Office of Naval Research grant N00014-10-1-0442 par­tially supported Arun Sood's research.

About the Authors

Quyen L. Nguyen is a system architect in the Systems Engineering Division of the Electronic Records Archives Program Management Office at the US National Archives and Records Administration. His research interests are system architecture, software modeling, and security architecture. Nguyen has an MS in computer science from the University of California, Berkeley. Contact him at qnguyeng@gmu.edu.

Arun Sood is a professor in George Mason University's De­partment of Computer Science and co-director of the uni­versity's International Cyber Center. His research focuses on security strategies that don't rely on previous knowledge of attack methodology. Sood has a PhD in electrical engineer­ing from Carnegie Mellon University. He's a senior member of IEEE. Contact him at asood@gmu.edu.

References

1. J.H. Lala, ed., Proc. Foundations of Intrusion Tolerant Systems (Oasis 03), IEEE CS Press, 2003.

2. P. Pal, F. Webber, and R. Schantz, "The DPASA Survivable JBI-a High-Water Mark in Intrusion- Tolerant Systems,"Proc. 2007 Workshop Recent Advances in Intrusion Tolerant Systems (Wraits 07), 2007; 

3. J. Knight, D. Heimbigner, and A. Wolf, "The Willow Architecture: Comprehensive Survivability for Large- Scale Distributed Applications," Proc. Intrusion Tolerance System Workshop, Supplemental Vol. of the 2002 Int'l Conf. Dependable Systems and Networks, IEEE Press, 2002, pp. C.7.1-C.7.8.

4. A. Valdes et al., "An Architecture for an Adaptive Intrusion-Tolerant Server," Security Protocols, LNCS 2845, Springer, 2003, pp. 569-574.

5. J.C. Reynolds et al., "On-Line Intrusion Detection and Attack Prevention Using Diversity, Generate-and-Test, and Generalization," Proc. 36th Hawaii Int'l Conf. System Sciences (Hiccs 03), IEEE CS Press, 2003, p. 335.2.

6. D. O'Brien et al., "Intrusion Tolerance via Network Layer Controls," Proc. DARPA Information Survivability Conf. and Exposition (Discex), vol. 1, IEEE CS Press, 2003, p. 90.

7. P.E. Veríssimo et al., "Intrusion-Tolerant Middleware: The Road to Automatic Security," IEEE Security & Privacy, vol. 4, no. 4, 2006, pp. 54-62.

8. P. Pal et al., "An Architecture for Adaptive Intrusion- Tolerant Applications," Software: Practice and Experience, vol. 36, nos. 11-12, 2006, pp. 1331-1354.

9. M. Sliti et al., "Intrusion-Tolerant Framework for Heterogeneous Wireless Sensor Networks," Proc. 2009 IEEE/ACS Int'l Conf. Computer Systems and Applications (Aiccsa 09), IEEE CS Press, 2009, pp. 633-636.

10. T. Zhang et al., "Building Intrusion-Tolerant Secure Software," Proc. 2005 Int'l Symp. Code Generation and Optimization (CGO 05), IEEE CS Press, 2005, pp. 255-266.

11. K.M.M. Aung, K. Park, and J.S. Park, "A Rejuvenation Methodology of Cluster Recovery," Proc. 5th IEEE Int'l Symp. Cluster Computing and the Grid (CCGRID 05), vol. 1, IEEE CS Press, 2005, pp. 90-95.

12. Y. Huang, D. Arsenault, and A. Sood, "Secure, Resilient Computing Clusters: Self-Cleansing Intrusion Tolerance with Hardware Enforced Security (SCIT/ HES)," Proc. 2nd Int'l Conf. Availability, Reliability, and Security (ARES 07), IEEE CS Press, 2007, pp. 343-350.

13. P. Sousa et al., "The Forever Service for Fault/Intrusion Removal," Proc. 2nd Workshop Recent Advances Intrusion- Tolerant Systems (Wraits 08), ACM Press, 2008, article 5.

14. H.P. Reiser and R. Kapitza, "Hypervisor-Based Efficient Proactive Recovery," Proc. 26th IEEE Int'l Symp. Reliable Distributed Systems (SRDS 07), IEEE CS Press, 2007, pp. 83-92.

15. P. Sousa et al., "Resilient Intrusion Tolerance through Proactive and Reactive Recovery," Proc. 13th Pacific Rim Int'l Symp. Dependable Computing, IEEE CS Press, 2007, pp. 373-380.

16. A.K. Bangalore and A.K. Sood, "Securing Web Servers Using Self Cleansing Intrusion Tolerance (SCIT)," Proc. 2nd Int'l Conf. Dependability (Depend 09), IEEE CS Press, 2009, pp. 60-65.

17. Q. Nguyen and A. Sood, "Quantitative Approach to Tuning of a Time-Based Intrusion-Tolerant System Architecture," Proc. 3rd Workshop Recent Advances on Intrusion-Tolerant Systems, 2009; http://wraits09.di.fc. ul.pt/wraits09paper2.pdf. 18. Y. Huang, D. Arsenault, and A. Sood, "Securing DNS Services through System Self Cleansing and Hardware Enhancements," Proc. 1st Int'l Conf. Availability, Reliability, and Security (ARES 06), IEEE CS Press, 2006, pp. 132-139.

IEEE Security & Privacy's primary objective is to stimulate and track advances in security, privacy, and dependability and present these advances in a form that can be useful to a broad cross-section of the professional community - ranging from academic researchers to industry practitioners.