Design and development of intrusion tolerance mechanisms
The INTERSECTION project aims at developing a resilient platform, which is able to provide a trustworthy service also in the presence of intrusions. It is worth noting that INTERSECTION partners have a valuable experience in designing and implementing high-performance intrusion tolerance systems [64].
Intrusion Tolerance (IT) is a new approach to distributed systems design which has gained impressive momentum during the last few years. IT is based on the notion of handling— react, counteract, recover, mask— intrusions, i.e. intentional and malicious faults, which may lead to failure of the system security properties if proper countermeasures are not taken. IT marks a fundamental shift in direction for systems design.
The main driver for this new approach is the evidence, collected over the years, that the ‘zero-vulnerabilities’ goal taken in many classical security designs is impossible to follow, since modern systems are too complex for the whole design and configuration to be mastered. The IT approach, instead of trying to avoid intrusions altogether, provides the system with mechanisms that prevent intrusions from generating a system failure.
The conceptual framework on which IT is based is the AVI model (Figure 1) [63], which reformulates the fundamental Fault-Error-Failure propagation chain in terms of security concepts. At the start of a security failure there is a security vulnerability, that is a weakness of a system that could be accidentally or intentionally exploited to damage assets. Examples of vulnerabilities are programs with unnecessary privileges or known flaws or weak access control settings on resources.
Vulnerabilities can be due to bad design choices or implementation or to operator mistakes (i.e. misconfigurations). It may also happen that vulnerabilities were previously inserted into the system by intruders (i.e. backdoors or trojan horses). An attacker can exercise a system vulnerability to gain access to, and sometimes control of, a system. If the attack is successful an intrusion is said to happen. The intrusion generates an alteration of the system correct state. This is commonly referred to as an error. Errors may propagate through the system leading it to a security failure.
To avoid security failures (Figure 2) commonly adopted techniques include vulnerability prevention (i.e. secure programming), vulnerability removal (i.e. continuous system update), attack prevention (i.e. firewalling), attack removal (that is disrupting ongoing attacks), and intrusion prevention. All such techniques aim at avoiding vulnerabilities exploitation, or the intruder to take access to the system.

On the other hand Intrusion Tolerance assumes the intruder has
already gained access to the system while it avoids the intrusion to
become a security violation. IT does not substitute the other failures
prevention means. Instead, it can be adopted in addition to them.
The INTERSECTION project will pursue the objective of Reconfigurable
Operation, i.e. in the presence of intrusions, the system undergoes a
reconfiguration procedure, so to guarantee the continuity of crucial
services (typically availability- or integrity-oriented services, such
as transactional databases, web servers, etc.).
The pre-requisite for Reconfigurable Operation is the availability of a
dependable intrusion detection mechanism. The Error symptoms are
processed by the intrusion detection mechanism, which promptly triggers
a reconfiguration procedure that automatically replaces a failed
component by a correct component, and provides the system with a
new configuration, which better suits the circumstances (and in
particular the higher level of threat). For example, if a system
component is attacked and corrupted, it may be replaced by a backup.
During reconfiguration, the service may suffer some performance
degradation, or even be temporarily unavailable. The new configuration
may degrade QoS in trade for resiliency, depending on the specific
policy in use (e.g., it might be necessary to temporarily disable a
service that contains a vulnerability which cannot be removed, or to
switch to a more resilient but slower protocol).
References
[63] Paulo Esteves Verissimo, Nuno Ferreira Neves, Miguel Pupo Correia, Intrusion-Tolerant Architectures: Concepts and Design, in Architecting Dependable Systems, R. Lemos, C. Gacek, A. Romanovsky (eds.), LNCS 2677, Springer Verlag, 2003
[64] G. P. Saggese, C. Basile, L. Romano, Z. Kalbarczyk, R.K Iyer, “Hardware support for high performance, intrusion- and fault-tolerant systems”, Proceedings of the 23rd IEEE International Symposium on Reliable Distributed Systems, 18-20 Oct. 2004 Page(s):195 – 204


Previous: Anomaly detection through signal processing


