Lecture Building reliable component-based systems - Chapter 10: Predicting system trustworthiness

Chapter 10
Predicting System Trustworthiness

Building Reliable Component­based 


Overview
Introduction
What else can be done?
Predicting component interoperability
Summary

Building Reliable Component­based 


Introduction
Functional Composability (FC) and functional
correctness:
FC is concerned with whether f(a) x f(b) = f(a x B) is
true.
These concerns stem from the problem of composing
"ilities".
Reliability
Safety
Security

Building Reliable Component­based 


The Problem
The problem stems from our inability to know a priori,

For example, that the security of a system composed of
two components, A and B, can be determined from
knowledge about the security of A and the security of B.
Why?
Because the security of the composite is based on more
than just the security of the individual components.

Building Reliable Component­based 


An Example
As an example, suppose that:
A is an operating system and B is an intrusion detection
system.
Operating systems have
authentication security.

some

level

of

built-in

Intrusion detection systems have some definition of the
types of event patterns that warn of a possible attack.
Thus, the security of the composition clearly depends
on the security models of the individual components.

Building Reliable Component­based 


The Example Continued
But even if A has a worthless security policy or flawed
implementation, the composite can still be secure.
How?
IF A has poor performance
THEN no one can log in
OR
IF A's security mechanism not reliable
THEN security is increased
While these last 2 examples are clearly not a desirable
way to attain higher levels of system security, both do
actually decrease the likelihood that a system will be
successfully attacked.

Building Reliable Component­based 


Another Example
A as an operating system and B as an intrusion
detection system,
AND We assume that A provides excellent security and
B provides excellent security,
WE MUST still accept the fact that the security of B is
also a function of calendar time.
So the question then comes down to: which "ilities", if
any, are easy to compose?
The answer is that there are no "ilities" easy to compose

and that some are much harder to compose than others.

Building Reliable Component­based 


What Else Can Be Done?
If a piece of software fails only once after 100 tests,
DO NOT calculate quantitative score based on the
result!
DO consider it to be the result of the testing.

Building Reliable Component­based 


Isolating Potential Contributors
Parties that have contributed software functionality
(whether COTS or custom) to the system.
Potential contributors to the system failure include:
Defective software components
Problems with interfaces between components
Problems with assumptions between components
Hidden interfaces and non-functional component
behaviors that cannot be detected at the component
level.

Building Reliable Component­based 


Interface Propagation Analysis
Interface propagation analysis (IPA):

Perturbs the states that propagate through the interfaces
that connect COTS software components to other types
of components.
Note that software fault injection is also a form of
accelerated testing.

Building Reliable Component­based 


Reliability Testing
Operational profile testing  test-cases
Test for defects occuring in operational phase
Many insignificant experiments
Time consuming

Input

Component/System

Building Reliable Component­based 


IPA at Work
To modify the information (states) that components use
for inter-communication
write access to those states is required (in order to
modify the data in those states).
This is obtained by creating a small software routine
named PERTURB which replaces, during system
execution, the original output state with a different

(corrupted) state.

Input

Component A

Component B

Building Reliable Component­based 


PERTURB
An Example using:
double cos(double x)
…
if (cos(a) > THRESHOLD) {do something}
…
if (PERTURB(cos(a)) > THRESHOLD) {do something}
The value added by having a utility such as PERTURB
is, in general, dependent on how well PERTURB mimics
corruptions that the utility under consideration.

Building Reliable Component­based 


Technique 1
The first technique:
Involves the deliberate inversion of the operational
profile originally anticipated by the system designers.
This technique is most beneficial when the description of

the expected profile is accurate.

Inversed
operation
al profile
Input

Component/System

Building Reliable Component­based 


Technique 2
The second technique:
Is simply a combination of the previous technique with
IPA.
Inversed
operation
al profile

Input

This is a situation in which the software is operating in
an unusual input mode while being bombarded with
corrupt information.

Component A

Component B

Building Reliable Component­based 


Summary
Non-functional behaviors are difficult to handle in
composition
Ordinary (reliability) testing is not enough
SWIFI can be used for testing non-functional behaviors
IPA is a technique for predicting interoperability
IPA is not the answer, but a complement to other
(traditional) testing techniques
.

Building Reliable Component­based