Đang tải... (xem toàn văn)
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.
Chapter 10 Predicting System Trustworthiness Building Reliable Componentbased Overview Introduction What else can be done? Predicting component interoperability Summary Building Reliable Componentbased 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 Componentbased 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 Componentbased 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 Componentbased 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 examples are clearly not a desirable way to attain higher levels of system security, both actually decrease the likelihood that a system will be successfully attacked Building Reliable Componentbased 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 Componentbased 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 Componentbased 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 Componentbased 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 Componentbased Reliability Testing Operational profile testing test-cases Test for defects occuring in operational phase Many insignificant experiments Time consuming Input Component/System Building Reliable Componentbased 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 Componentbased 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 Componentbased Technique 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 Componentbased Technique 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 Componentbased 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 Componentbased ... Component B Building Reliable Componentbased Summary Non-functional behaviors are difficult to handle in composition Ordinary (reliability) testing is not enough SWIFI can be used for testing non-functional... assumptions between components Hidden interfaces and non-functional component behaviors that cannot be detected at the component level Building Reliable Componentbased Interface Propagation Analysis... fault injection is also a form of accelerated testing Building Reliable Componentbased Reliability Testing Operational profile testing test-cases Test for defects occuring in operational phase