Information Assurance and Survivability Validation
Framework
For OASIS Program Technologies
Characterization of Project
" Intrusion Tolerance Based on Intelligent
Compensating Middleware (ICM)"
Farooq Anjum
Abhrajit Ghosh
Manish Rathi
Amjad Umar
Rabih Zbib
Telcordia Technologies
445 South Street.
Morristown, New Jersey, 07960
Main Contact: Amjad Umar, Phone: 973-829-3114, email: aumar@telcordia.com
August 30, 2001
1) Technology Description and Information Assurance/Survivability Problem
Addressed.
Most COTS middleware platforms (CORBA, MOM, others) are not
intrusion tolerant (IT). We are developing Intelligent Compensating
Middleware (ICM) technologies that will compensate for the missing IT
capabilities in the existing COTS middleware platforms. Our goal is to build
ICM as a pluggable technology that can be invoked to handle intrusions. We
are attempting to build ICM as a generic technology that extends across all
middleware platforms to:
 Allow applications to adapt to intrusions.
 Allow middleware to adapt to intrusions.
 Allow applications to adapt to loss of data.
 Adapt to situations where message channels may be subject to
snooping.
Additional details about the ICM approach can be found in “ICM External
Architecture”, Data Item: A002, Work Completed under the Project "A
Comprehensive Approach for Intrusion Tolerance Based on Intelligent
Compensating Middleware", BAA00-15, March 2001.
2) Assumptions
A-1) Standard operating environment is assumed.
 We have assumed that we would be operating in a standard datanetworking environment where a shared medium is used to transmit data
between end points.
 All end points make use of IP-based protocols to transmit data.
 These endpoints may have associated stable storage, we make no
assumptions about how this storage may be implemented and accessed.
A-2) Applications that are serviced by ICM are either making use of
middleware platform(s) that have been ICM enabled, i.e. applications are ICM
agnostic or are making use of ICM directly, i.e. they are ICM aware or may be
a combination of the above.
A-3) Middleware platforms provide some hooks that may be used for
providing intrusion tolerant capabilities. These could be hooks that intercept
the manner in which data is transmitted using middleware platform (e.g. Exits
in MQSeries, Interceptors in CORBA). These hooks could also intercept the
manner in which data is stored into stable storage (e.g. Triggers in databases,
Oracle 9i – Protegrity Data Encryption Triggers, etc.)
A-4) Detectable Intrusions



We are assuming that it is possible detecting intrusions and provide this
information to the adaptation logic that invokes ICM.
This information is made available in a timely manner to invoke ICM
before damage is incurred to the system.
If intrusions are difficult to detect, then ICM can be "turned on" at system
startup as a runtime policy. This option does incur system overhead (i.e.,
ICM logic of fragmentation and replication is always executed even when
no intrusions occur). Basically, the system is more efficient if intrusions
can be detected and ICM capabilities can be invoked only when needed.
A-5) Users of the system are assigned “roles” that restrict the amount of
information that is visible to them. A user cannot access more information
than they are authorized to access. (Thus it should be possible to set things up
so that even the “root” user on a system may not know how to reconstruct
fragmented data that they are not authorized to)
A-6) User authentication is done directly at the access point.
A-7) Depending on the kind of FRS algorithm implementation being used,
there may be a requirement to store some components in a secure rather than
fragmented manner (e.g. centrally stored maps). Access to this storage is
assumed to be highly secure [1].
A-8) COTS middleware will continue to grow and will be weak to satisfy
intrusion tolerance needs.
A-9) A small subset of the systems is highly secure (significantly more secure
than the other systems). These highly secure systems are used in specialized
roles (e.g. FRS fragment map storage).
A-10) Subsets of System Administrators are trustable.
A-11) At any point in time, a fraction of the systems will be intact. The
number of servers required to remain intact depends on the specific FRS
scheme.
2a) Residual Risks, Limitations, and Caveats
Limitations and Caveats:
 ICM targets intrusion tolerance at the middleware level of the stack. Our
system does not take into consideration attacks on the network layer of the
stack. For example, the system can still be under attack at the network port
of the Client and the Server machine.
 Even if the network layer is secure, ICM assumes that there are multiple
paths (network nodes) between the client and the server.

ICM would not be able to handle any attacks on the main network hubs or
switches.
Residual Risks:
 Currently we are not assuring intrusion tolerance on the ICM software
components itself.
 The technique ICM uses for Intrusion Tolerance comes along with its own
bag of performance overhead.
 The risks of using alternative methods of communication remains.
3) Vulnerabilities and Attacks
We are dealing with the following types of operation-time attacks.
V-1) Attacks on data servers:
 Attackers attempt to modify/corrupt/destroy data that is required by an
application.
V-2) Attacks on message transmission:
 Attackers attempt to snoop on messages being transmitted between
various applications that are connected via data networks.
 Attackers attempt to modify messages being transmitted between various
applications (corruption/destruction are handled by the transport protocol)
V-3) Attacks on the application binary code:
 Attackers attempts to replace files containing the application code with
those containing malicious code.
 At this point we are dealing with Java Code only.
V-4) Denial of Service attacks on data servers – both for applications and
middleware.
V-5) System policy violations (e.g. login at unusual times, user changes roles,
user A becomes user B)
V-6) Attack on the data which the middleware uses (configuration files, set-up
files, etc.)
V-7) Attacks on the middleware application binary code.
4) Information Assurance and Survivability Attributes
The basic purpose of ICM system is to make sure that the System Availability
(AV) of the COTS Middlewares remains intact for the end user, by providing the
functionality of automatically switching between different middleware platforms.
ICM system makes sure that application deploying any of the middleware remains
available under attacks. In addition to the System Availability, ICM system is also
designed to ensure Information Availability against external attacks. By using
FRS, users of this system can achieve a varying degree (as per their requirements)
of Integrity [I] and Confidentiality [C]. This can be achieved by using encryption
along with FRS.
ICM system does not address the attributes of Authentication [AU] and nonrepudiation [NR] directly.
5) Comparison with Other Systems:
1.1. A Binary Agent Technology for COTS Software Integrity ( InCert Software
Corporation)
This project is oriented towards developing a core binary instrumentation technology
that will allow software functions to be inserted directly into COTS NT binaries at the
deployment site. This is done irrespective of the availability of the source code. We
can take advantage of this to ensure the integrity of the COTS code used by us by
performing runtime execution monitoring.
1.2. Active Trust Management for Autonomous Adaptive Survivable Systems (MIT)
One of the major topics of focus for this project is to develop trust models. These
models determine what resources may be trusted and for what purposes. These
models would be very relevant for us since we would need to determine the
probability of intrusion and compromise of a system.
1.3. Agile Objects: Component-based Inherent Survivability (UCSD)
The three technologies being developed in this project and based on the concepts of
location elusiveness, interface elusiveness and dynamic elusiveness would be of
interest. This is because it seems promising to combine these concepts with our
techniques to give rise to stronger intrusion tolerant systems.
1.4. Computational Resiliency (Syracuse)
This project is exploring techniques for constructing computationally resilient
systems that deliver availability, security, and timeliness through a combination
of techniques, including on-the-fly replication and reconfiguration, resource
management, and camouflage. Combining these techniques with our techniques
such as FRS and use of interceptors is an interesting research area.
1.5. Containment and Integrity for Mobile Code (Cornell)
One of the focus areas of this project is proactive secret sharing. This is relevant
and different from our work as explained earlier.
1.6. Dependable Intrusion Tolerance (SRI )
This project focuses on exploring a synthesis of techniques from intrusion
detection and fault tolerance. The resultant intrusion detection mechanisms
would be of interest to us.
1.7. Integrity Through Mediated Interfaces (ISI)
The techniques from this project that are of interest to us are:

Use of wrappers

Use of integrity marks to detect corruption of data sets
1.8. Intrusion Tolerant Distributed Object Systems (NAI labs)
One of the goals of this project is to build intrusion tolerant CORBA, The project
is developing technologies that are specific to CORBA. It would be interesting to
explore how these technologies can be generalized and included in ICM.
1.9. Intrusion Tolerant Software Architectures
This project is developing a methodology based on architectural concepts for
building intrusion tolerant systems. This is based on the assumption that the
architecture of a system can ensure intrusion tolerance. Thus, we could use the
techniques developed in this project to check the viability of our architecture from
the point of view of intrusion tolerance.
1.10.
ITUA (BBN, UIUC, Boeing)
The techniques from this project that are of interest to us are:
1.11.

Concept of unpredictable adaptation

Group communication

Interface to Intrusion Detection Tool
Intrusion Tolerance Using Masking, Redundancy and Dispersion
The techniques of masking and dispersion being investigated by this project
could be added to the FRS technique to study the strength of the resultant system.
1.12.
Perpetually Available and Secure Information Systems (CMU)
This project is investigating the use of FRS techniques in combination with secret
sharing schemes with respect to file storage (“persistent data”). An interesting
combination could be to compare our FRS schemes (which currently are not coupled
with secret sharing schemes) to the schemes developed in this project.
1.13.
Scaling Proof-Carrying Code to Production Compilers and Security
Policies (Princeton)
COTS manufacturers could use the techniques developed from this project in order to
provide proof that the middleware code does not have a Trojan horse. Thus, this
ensures the integrity of the COTS binary code used by us.
1.14.
Self Protecting Mobile Agents (NAI labs)
The mobile agents that could be used along with dynamic secret sharing schemes
developed by us need to be protected from malicious host computers. Protection of
mobile agents from malicious hosts is indeed the focus of this project.
6) Information Assurance and Survivability Mechanisms
M-1) Use of Interceptors/Exits:
Interceptors are modules that can be used to provide additional capabilities within
the middleware packages as plug-ins. Interceptors facilitate both static and
dynamic plug-ins. The current middleware systems broadly fall into three
categories namely
 No interception capabilities: e.g., DCOM
 Some interceptor capabilities, e.g., Exits in MQ Series
 Good interceptor capabilities: e.g., interceptors in CORBA.
We have found that many implementations of even the best available
specification (CORBA) are not adequate for flexible and powerful plug-ins. For
example, we found that, for many of the widely used implementations, the
CORBA ORB itself is not decomposable. For example, we wanted to change the
CORBA transport but found that we could not invoke the ORB services on the
server side. In addition, there is no easy way to respond back. So the lessons
learnt could be used to develop new interceptor technologies.
M-2) FRS of file storage
Fragmentation-Redundancy-Scattering (FRS) is a technique that can be used to
achieve security and fault tolerance. The FRS technique consists in first cutting
all the sensitive information into several fragments. This has to be done such that
no significant information is contained in any isolated fragment. Encrypting the
confidential data, either before or after fragmentation, can lead to a further gain in
securing the data. Then redundancy might be introduced by copying the
fragments. The purpose of making copies is to tolerate accidental or purposeful
destruction or alteration of fragments. Finally, the fragments along with their
copies are to be scattered amongst the different sites of the distributed system.
Scattering has to be done so that, each computer system contains just a subset of
unrelated fragments. Finally, when the desired data has to be viewed, it is
obtained back from the site(s) where it is located and reconstructed.
This technique has been the subject of study for quite sometime. We are also
considering this and provide different FRS algorithms that could be used by other
projects.
M-3) FRS of messages
In addition to using the FRS technique for file storage, we also propose to use this
technique on messages that have to be exchanged between different machines on
a LAN/WAN. As can be expected, this is expected to result in better security
features of the messages involved.
M-4) Dynamic Secret Sharing
1.1)
Dynamic secret sharing
In dynamic secret sharing the set of participants is not fixed and changes
through addition and deletion of participants. The security requirement asks
that the adversary is not able to get any information about the secret even if
she corrupts a set of unqualified parties -and- the set of parties who
previously left the group. It can be formally showed that for this fact to be
achieved, the secret has to change (this is not a problem for practical
situation when the same secret has to be shared since one can encrypt this
secret using a key and then share this key using the dynamic secret sharing
scheme, in which case this key can always change without compromising the
correctness of the scheme). An additional requirement satisfied by our
notion of dynamic-membership secret sharing, and not met by previous
dynamic notions, is that the communication complexity necessary to deal
with updates such as addition and deletion of participants is much smaller
than that of recreating the scheme from scratch.
Dynamic secret sharing seems to be similar to proactive secret sharing and
hence we next compare the two approaches.
1.2)
Differences with proactive secret sharing
A first difference is in how the set of participants changes: in proactive
secret sharing the set of participants is always the same; in dynamicmembership secret sharing the set of participants changes through additions
and deletions.
A second difference is in how the secret changes: in proactive secret
sharing the secret stays the same after the update at each time period; in
dynamic-membership secret sharing the secret changes typically after each
deletion of participants (as clarified above, this is not a problem for practical
situations where the "real" secret has to stay fixed).
The third difference is the most important: this difference concerns the
adversarial model and clarifies that dynamic-membership secret sharing
tolerates a much stronger adversary. in proactive secret sharing it is
implicitly assumed that an adversary who has gained shares of a participant
will not be able to see the new shares distributed to this participant at the
next time period. Note that in many real-life situations, and typically, like
those that arise from intrusion tolerance questions, the adversary gains
possess of a participant's server at some time and then keeps it for a very
long time (including the next time period in proactive secret sharing, unless
this time period is very big, but this then defeats the purpose of proactive
secret sharing itself). Note that many denial-of-service attacks violate
intrusion tolerance within 1-2 minutes at most.
Therefore, it would seem that proactive secret sharing considers a weaker
adversarial model than the one considered by dynamic-membership secret
sharing.
7) Rationale:
Vulnerability
V1
V2
V3
V4
V5
V6
V7
System
Availability (AV)
M-2, M-4, A-7
M-1, M-3, A-3
M-2, M-4, A-7
M-1, M-2, M-3,
A-3
A-5
M-2, M-4, A-7
M-2, M-4, A-7
Integrity (I)
Confidentiality ©
M-2, M-4
M-1, M-3, A-3
M-2, M-4
-
M-2, M-4
M-1, M-3, A-3
M-2, M-4
-
M-2, A-5
M-2, M-4
M-2, M-4
M2, A-5
M-2, M-4
M-2, M-4
Note:


As discussed in (4), ICM does not address the attributes of Authentication
(AU) and non-repudiation (NR)
Assumptions – A-1, A-2, A-4, A-8, A-9, A-10, A-11 are the core
assumptions for the working of ICM System. Hence they are not included
in the above table.
8) Cost/Benefit Analysis:
a) Cost:
ICM system has a one time cost associated with the development of intrusion
tolerant modules needed for a middleware system and their integration with the
middleware of interest. Since, the solution architecture is expected to be similar
to all the different middleware systems, the development cost will not be very
much. The integration cost will though require understanding the hooks into the
middleware system and integrating the modules with the identified hooks. This is
due to the absence of a standard mechanism for providing interceptors or exits in
the various middleware packages.
During the operation of an ICM system, the costs will be in terms of performance.
Since, ICM system makes use of the FRS algorithms, which entail fragmenting
the data item of interest, and then reconstructing it back when required (after
verifying the fragment), the system performance would be slower when compared
to a system without the ICM modules. We plan to mitigate this performance
overhead by integrating ICM with intrusion detection modules. This will allow
the fragmentation and reconstruction to be done only when an intrusion is
detected. Another way of mitigating this overhead is by developing different FRS
algorithms, each with a different overheads and corresponding strengths.
b) Benefits:
As described throughput, middleware systems that incorporate ICM technology
can survive intrusions both with respect to the persistent ("stored") information as
well as with respect to the messages.
9) Reference:
[1]
A. Ghosh, F. Anjum, R. Zbib, A.Umar and M. Rathi, “On Efficient schemes for
Intrusion Tolerance”, Telcordia Technology Internal Report.