This chapter presents the following content: 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.
Trang 1Building Reliable Componentbased Systems
Chapter 10 Predicting System Trustworthiness
Chapter 10 Predicting System Trustworthiness
Trang 2Building Reliable Componentbased Systems
Overview
Introduction
What else can be done?
Predicting component interoperability
Summary
Trang 3Building Reliable Componentbased Systems
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
Trang 4Building Reliable Componentbased Systems
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
Trang 5Building Reliable Componentbased Systems
An Example
As an example, suppose that:
A is an operating system and B is an intrusion detection system
Operating systems have some level of built-in authentication security
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.
Trang 6Building Reliable Componentbased Systems
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.
Trang 7Building Reliable Componentbased Systems
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
Trang 8Building Reliable Componentbased Systems
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
Trang 9Building Reliable Componentbased Systems
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
Trang 10Building Reliable Componentbased Systems
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
Trang 11Building Reliable Componentbased Systems
Reliability Testing
Test for defects occuring in operational phase
Many insignificant experiments
Time consuming
Component/System
Input
Trang 12Building Reliable Componentbased Systems
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
Trang 13Building Reliable Componentbased Systems
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
Trang 14Building Reliable Componentbased Systems
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
Component/System
Input
Inversed operation
al profile
Trang 15Building Reliable Componentbased Systems
Technique 2
The second technique:
Is simply a combination of the previous technique with IPA
This is a situation in which the software is operating in
an unusual input mode while being bombarded with corrupt information
Inversed
operation
al profile
Input
Trang 16Building Reliable Componentbased Systems
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