Intrusion Tolerance has become a reference paradigm for dealing with intrusions and accidental faults, achieving security and dependability in an automatic way, much along the lines of classical fault tolerance. It introduces to the design and validation of intrusion-tolerant middleware and systems. Middleware Design Principles : Architecting intrusion-tolerant systems, to arrive at some notion of intrusion-tolerant middleware for application support, presents multiple challenges. Intrusion tolerance mechanisms can be selectively used at all layers starting with hardware, to build layers of progressively more trusted components and middleware subsystems, from baseline untrusted components (hosts, networks). This leads to an automation of the process of building resilience: for example, at lower layers, basic intrusion tolerance mechanisms are used to construct a trustworthy communication subsystem. This subsystem can then be trusted by higher layer distributed software, to securely communicate amongst participants without bothering about network intrusion threats. Or alternatively, it can be used to build an even more trustworthy higher layer— by incrementally using intrusion tolerance mechanisms— such as a replication management protocol resilient to both network and host intrusions. Tolerating Intrusions : Intrusion-tolerant middleware is usually based on the notion of replication, i.e., in scattering a service in a set of server machines. This section starts by presenting the main intrusion tolerance paradigms in the literature and how they are used to ensure the integrity of a service, i.e., that the latter behaves as expected even if there are intrusions in some of its components (servers and/or clients). Then the section presents how these paradigms can be extended to ensure also the conﬁdentiality of information stored in a replicated service. Finally, some system architectures are presented, showing how the paradigms can be used to build actual systems. Resisting Attacks : Intrusion-tolerant systems may have a long lifetime (e.g., online banking systems) and it should be guaranteed that no more than the maximum number of tolerated faults ever occurs, i.e., InTol systems should be exhaustion-safe. This section starts by presenting a model that allows assessing the exhaustion-safety of a system according to its fault and timing assumptions. Then, it is shown that, in order to meet the exhaustion-safety predicate, InTol systems should be designed with diversity in mind and enhanced with proactive and reactive recovery mechanisms targeting, respectively, stealth/dormant faults and conspicuous attacks. It is also explained how recoveries can eliminate the effects of faults/attacks and how they can randomize certain parts of the system in order that vulnerabilities are somehow changed or removed, and the adversary cannot make use of knowledge learnt before the recovery. Testing Attacks and Vulnerabilities An intrusion can only occur if the system contains vulnerabilities which can be exploited by an attack. This section presents some of the techniques that can be utilized to locate security vulnerabilities and allow their subsequent elimination, both during the testing phases of the development cycle and when the system is in operation. The following techniques are examined: static vulnerability analyzers, fuzzing mechanisms, and attack injection. Vulnerability removal is important because it causes an increase on the effort necessary to compromise a machine. The section also explains how these techniques can be applied to experimentally validate some aspects of the attack model and fault assumptions made during the design of the intrusion-tolerant system. Both aspects contribute to the deployment of cheaper intrusion-tolerant systems.