Fundamental Concepts of Dependability

1. Fundamental Concepts of Dependability Algirdas Avizienis, UCLA Jean-Claude Laprie, LAAS-CNRS, France Brain Randell, U. of Newcastle upon Tyne, UK Presentation – Lin Tan Information Security Workshop 2000

2. Outline • Highlights • Dependability • Faults, Errors, and Failures • Dependability and Security • Beyond this paper • Interesting Buzzwords • Development failures [Quantitative] • Where do we stand?

3. 18th IFIP World Computer Congress Extensions – From two papers • Dependability and its threats: A taxonomy • Fundamental Concepts of Dependability • Technical report

4. Dependability • Computer systems are characterized by four fundamental properties: • Functionality • Performance • Cost • Dependability

5. Availability Reliability Safety Confidentiality Integrity Maintainability Attributes Fault Prevention Fault Tolerance Fault Removal Fault Forecasting Dependability Means ability to deliver service that can justifiably be trusted Faults Errors Failures Threats

6. Dependability Readiness for usage Continuity of service Absence of catastrophic consequences on the user(s) and the environment Absence of unauthorized disclosure of information Absence of improper system alterations Ability to undergo repairs and evolutions Availability Reliability Safety Confidentiality Integrity Maintainability Dependability: ability to avoid service failures that are more frequent or more severe than is acceptable

7. … … Causation Activation Propagation Causation Errors Failures Faults Failures Faults Availability Reliability Safety Confidentiality Integrity Maintainability Fault Prevention Fault Tolerance Fault Removal Fault Forecasting

8. … … Failure Fault Error Failure Fault Adjudged or hypothesized cause of an error Part of system state that may cause a subsequent service failure Deviation of the delivered service from correct service, i.e., implementing the system function System does not comply with specification Specification does not adequately describe function

9. Fault, Error, Failure - Example • A Fault: • int increment (int x) { x = x+11; // should be x = x +1; } • An Error – fault activated • Y = increment(2); • Can be propagated. • A Failure – Error exposed to interface • Print(Y);

10. Fault Prevention Fault Tolerance Fault Removal Fault Forecasting Preventing the occurrence of faults Avoiding service failures in the presence of faults Reducing the number and severity of faults Estimating the present number, the future incidence, and the likely consequences of faults Dependability Provision Dependability Analysis Fault Avoidance Fault Acceptance

11. Dependability & Security Readiness for usage Continuity of service Absence of catastrophic consequences on the user(s) and the environment Absence of unauthorized disclosure of information Absence of improper system alterations Ability to undergo repairs and evolutions Availability Reliability Safety Confidentiality Integrity Maintainability Authorized actions Security Absence of unauthorized access to, or handling of,system state

12. Outline • Highlights • Dependability • Faults, Errors, and Failures • Dependability and Security • Beyond this paper • Robustness • Malicious logic faults: Logic bomb, Trojan horse, Trapdoor, Zombie • Development failures [Quantitative] • Where do we stand?

13. Buzzwords • Robustness • Characterizes a system reaction to a specific class of faults • Dependability with respect to external faults. • Malicious logic faults • Logic bomb: dormant until a certain time or event occurs • Trojan horse: illegitimate action while looking legitimate • Trapdoor: circumventing access control mechanisms. • Zombie: corrupted malicious logic for a coordinated attack.

14. Incomplete or faulty specifications Excessive number of specification changes Inadequate design wrt functionality or performance Too many development faults Insufficient predicted dependability Faulty estimates of development costs Development failures Development process terminates before the system is accepted for use and placed into service • Partial development failures • Budget or schedule overruns • Downgrading to less functionality, performance, dependability

15. Standish Group (Chaos reports)

16. Where do we stand?

17. Where do we stand?

18. Where do we stand?

19. Where do we stand?

20. Conclusions • Dependability taxonomy • Document a minimum consensus within the community • To enable sharing of ideas and viewpoints.