Basic Concepts and Taxonomy of Dependable and Secure Computing - - PDF document

1

Basic Concepts and Taxonomy of Dependable and Secure Computing

Presented By H. Momeni Instructor: Dr. Abdollahi Azgomi

Reliable Software Design Course Iran University of Science and Technology Spring 2007

Reliable Software Design Course Spring 2007 - IUST 2

The Basic Concepts

• System Function, Behavior, Structure, and Service
• The Threats to Dependability and Security
• Dependability, Security, and Their Attributes
• The Means to Attain Dependability and Security

2

Reliable Software Design Course Spring 2007 - IUST 3

System Function

• System is an entity that interacts with its environment (other

systems, hardware, software, humans)

• Systems are characterized by fundamental properties:

functionality, performance, dependability and security, and cost

• The function of a system is what the system is intended

to do and is described by the functional specification

Reliable Software Design Course Spring 2007 - IUST 4

Behavior

• The behavior of a system is what the system does to

implement its function and is described by a sequence of states.

• The total state of a given system is the set of the

following states: computation, communication, stored information, interconnection, and physical condition.

3

Reliable Software Design Course Spring 2007 - IUST 5

Structure

• The structure of a system is what enables it to generate the

behavior

• A system is composed of a set of components bound together

in order to interact

Reliable Software Design Course Spring 2007 - IUST 6

Service

• The service delivered by a system is its behavior as it is

perceived by its users

• A user is another system that receives service from the

provider

• The part of the provider’s total state that is perceivable at the

service interface is its external state.

4

Reliable Software Design Course Spring 2007 - IUST 7

The Threats to Dependability and Security

Concepts

• Correct service is delivered when the service implements the system

function.

• Service failure, is an event that occurs when the delivered service deviates

from correct service

• A service failure is a transition from correct service to incorrect service to

not implementing the system function

• Service outage: the period of delivery of incorrect service
• Service restoration: transition from incorrect service to correct service

Reliable Software Design Course Spring 2007 - IUST 8

Threats

• A service failure means that at least on ore more external state
• f the system deviate from the correct service state.
• The deviation is called an error
• Error is the part of the total state of the system that may lead to

service failure

• The cause of a error is called a fault
• A fault is active when it cause an error, otherwise is dormant

5

Reliable Software Design Course Spring 2007 - IUST 9

Dependability and Security Attributes

• The original definition of dependability is the ability to deliver

service that can justifiably be trusted.

• Dependability attributes:

– availability: readiness for correct service. – reliability: continuity of correct service. – safety: absence of catastrophic consequences on the users and the environment. – integrity: absence of improper system alterations. – maintainability: ability to undergo modifications and repairs.

Reliable Software Design Course Spring 2007 - IUST 10

Dependability and Security Attributes (cont’d)

• Security attributes:

– availability: for authorized action – confidentiality: absence of unauthorized disclosure of information – integrity: absence of unauthorized system alterations.

6

Reliable Software Design Course Spring 2007 - IUST 11

The Means to Attain Dependability and Security

• Fault prevention

– prevent the occurrence or introduction of faults.

• Fault tolerance

– avoid service failures in the presence of faults.

• Fault removal

– reduce the number and severity of faults.

• Fault forecasting

– estimate the present number, the future incidence and the likely consequences of faults.

Reliable Software Design Course Spring 2007 - IUST 12

System Lifecycle

1. Development phase

• System interact with development environment and related faults
• Development environment
• Physical world
• Human developer
• Development tools
• Production and test facilities

7

Reliable Software Design Course Spring 2007 - IUST 13

System Lifecycle (cont’d)

2. Use phase

• Begins when the system is accepted for use and starts the service

delivery

• Three periods:
• Service delivery
• Service outage: service failure
• Service shutdown: intentional halt of service by an authorized entity
• System interacts with its use environment:
• Physical world, administrators, users, providers, infrastructure, intruders

Maintenance may take place during all three periods of the use phase

Reliable Software Design Course Spring 2007 - IUST 14

Maintenance

8

Reliable Software Design Course Spring 2007 - IUST 15

Maintenance vs. fault tolerance

• Distinction between fault tolerance and maintenance:
• Repair is part of fault removal (during the use phase)

maintenance involves the participation of an external agent, e.g., a repairman, test equipment, remote reloading of software

Reliable Software Design Course Spring 2007 - IUST 16

Taxonomy of Faults

• All faults that may affect a system during its life are classified

according to eight basic viewpoints

• If all combinations of the eight elementary fault classes were

possible, there would be 256 different combined fault classes

• 31 faults have been identified

9

Reliable Software Design Course Spring 2007 - IUST 17 Reliable Software Design Course Spring 2007 - IUST 18

Taxonomy of Faults (cont’d)

• All 31 combined faults are categorized to three major
• verlapping groups:

– Development faults : occurring during development – Physical faults: affect hardware – Interaction faults: external faults

10

Reliable Software Design Course Spring 2007 - IUST 19 Reliable Software Design Course Spring 2007 - IUST 20

11

Reliable Software Design Course Spring 2007 - IUST 21

Human made faults

• Two basic classes

1. Nonmalicious faults :introduced without malicious objectives

• nondeliberate faults that are due to mistakes
• deliberate faults that are due to bad decisions
• It is usually considered that both mistakes and bad decisions are accidental.
• Some very harmful mistakes and very bad decisions are made by persons who

lack professional competence to do the job (incompetence)

Reliable Software Design Course Spring 2007 - IUST 22

Human made faults (cont’d)

2. Malicious faults: introduced during either system development with the objective to cause harm to the system during its use

Goals:

– To disrupt or halt service (DoS) – Access confidential information – Improperly modify the system

Classes:

– Malicious logic faults: Trojan horses, logic or timing bombs, viruses, worms,… – Intrusion attempts: power fluctuation, radiation,…

12

Reliable Software Design Course Spring 2007 - IUST 23

Malicious logic faults

Reliable Software Design Course Spring 2007 - IUST 24

Interaction faults

• Occur during the use phase

– Operational faults – External faults – Human made faults

• Reconfiguration faults:
• ccur during configuration changes concurrently with

system operation

A broad class of human-made operational faults are configuration faults, i.e., wrong setting of parameters that can affect security, networking, storage, middleware

13

Reliable Software Design Course Spring 2007 - IUST 25

Failures

1. Service failure

• An event that occurs when the delivered service deviates from

correct service.

2. Development failure

• Be introduced into the system being developed by its environment,

especially by human developers, development tools and production facilities.

3. Dependability and security failures

• ccurs when the given system suffers service failures more

frequently or more severely than acceptable

Reliable Software Design Course Spring 2007 - IUST 26

Service Failures

• The service failures modes characterize according to four

viewpoints:

1. Failure domain 2. Detectability of failures 3. Consistency of failures 4. Consequence of failures on the environment

14

Reliable Software Design Course Spring 2007 - IUST 27

Failure domain viewpoint failure modes

• content failures: service content deviates from implementing the system function
• timing failures: timing of service delivery deviates from implementing the system

function

• halt failures: when the service is halted (silent failure)
• erratic failures: a service delivered but is erratic

Reliable Software Design Course Spring 2007 - IUST 28

Detectability viewpoint failure modes

• The detectability viewpoint addresses the signaling of service failures to the

users

• Signaling at the service interface originates from detecting mechanisms in

the system that check the correctness of the delivered service.

– signaled failures: when the losses are detected and signaled by a warning signal – unsignaled failures: otherwise

• The detecting mechanisms themselves have two failure modes:

– signaled failures :signaling a loss of function when no failure has actually

• ccurred (false alarm)

– unsignaled failures: not signaling a function loss

15

Reliable Software Design Course Spring 2007 - IUST 29

Consistency viewpoint failure modes

• The consistency of failures leads us to distinguish, when a

system has two or more users

– consistent failures: The incorrect service is perceived identically by all system users – inconsistent failures: Some or all system users perceive differently incorrect service and some users may actually perceive correct service (Byzantine failures)

Reliable Software Design Course Spring 2007 - IUST 30

Consequence viewpoint failure modes

• Grading the consequence of the failures upon the system environment

enables failure severities to be defined

• Two levels can be defined:

1. minor failures: the harmful consequences are of similar cost to the benefits provided by correct service delivery 2. catastrophic failures: the cost of harmful consequences is higher than the benefit provided by correct service delivery

16

Reliable Software Design Course Spring 2007 - IUST 31 Reliable Software Design Course Spring 2007 - IUST 32

Fail-System Types

• Fail-controlled systems

– fail only in specific failure modes described in specification

• Fail-halt systems

– a system whose failures are to an acceptable extent halting failure

• Fail-passive systems (fail-silent systems)

– the situation of stuck service and silence

• Fail-safe systems

– all whose failures to an acceptable extent (minor)

17

Reliable Software Design Course Spring 2007 - IUST 33

Development Failures

• Complete development failures: the development process will

be terminated before the use phase

– budget failure – schedule failure

• Partial development failures: lesser severity than project

termination

– downgrading

principle causes: incomplete or faulty specifications, user initiated specification changes, faulty estimates of development costs…

Reliable Software Design Course Spring 2007 - IUST 34

Dependability and Security Failures

• Dependability and security specification identifies the class of

faults that are expected in which the system will operate

• Specification may also require safeguards against dangerous

conditions

• The inclusion of specific fault prevention or fault tolerance

techniques may be required by the user.

18

Reliable Software Design Course Spring 2007 - IUST 35

Errors

• A failure occurs when the error causes the delivered service to

deviate from correct service

• An error is detected if its presence is indicated by an error

message or error signal.

• Errors that are present but not detected are latent errors.

Reliable Software Design Course Spring 2007 - IUST 36

Errors (cont’d)

• An error will actually lead to a service failure or not depends
• n two factors:

– The structure of the system

• nature of any redundancy that exists in it

– The behavior of the system

• the part of the state that contains an error may never be needed for service

– Single errors are errors that affect one component only – multiple related errors are errors that affect more than one component

19

Reliable Software Design Course Spring 2007 - IUST 37

The Pathology of Failure

Reliable Software Design Course Spring 2007 - IUST 38

The Pathology of Failure

The arrows in this chain express a causality relationship between faults, errors and failures

20

Reliable Software Design Course Spring 2007 - IUST 39

Fault Activation Reproducibility

• The ability to identify the activation pattern of a fault that had caused one or

more errors is the fault activation reproducibility

• Faults can be categorized according to their activation reproducibility:

– Solid or Hard faults: faults whose activation is reproducible – Elusive or Soft faults: faults whose activation is not reproducible

Reliable Software Design Course Spring 2007 - IUST 40

Dependability and Security Definition

• The origin definition: the ability to deliver service that can justifiably be

trusted.

• The alternate definition: the ability of a system to avoid service failures that

are more frequent or more severe than is acceptable.

• Security has not been characterized as a single attribute of dependability, it

is combination of confidentiality, integrity and availability.

21

Reliable Software Design Course Spring 2007 - IUST 41

Dependence and Trust

• The dependence of system A on system B represents the extent to

which System A’s dependability is (or would be) affected by that of System B.

• Trust is accepted dependence.
• Total dependence: any failure of B would cause A to fail
• Complete independence: B cannot cause A to fail

Reliable Software Design Course Spring 2007 - IUST 42

The Attributes of Dependability and Security

• Primary attributes

– Availability, integrity, and maintainability are generally required, although to a varying degree depending on the application – Reliability, safety, and confidentiality may or may not be required according to the application

22

Reliable Software Design Course Spring 2007 - IUST 43

• Secondary attributes: The notion of secondary

attributes is especially relevant for security

– Robustness: dependability with respect to external faults – Accountability: availability and integrity of the identity of the person who performed an operation – Authenticity: integrity of a message content and origin, and possibly of some other information, such as the time of emission – Nonrepudiability: availability and integrity of the identity of the sender of a message or of the receiver

Reliable Software Design Course Spring 2007 - IUST 44

Dependability, high confidence, survivability, trustworthiness

23

Reliable Software Design Course Spring 2007 - IUST 45

The Means to Attain Dependability and Security

1. Fault Prevention

– Fault prevention is part of general engineering – Prevention of development faults is an obvious aim for development methodologies – Elimination of the causes of the faults via process modifications

Reliable Software Design Course Spring 2007 - IUST 46

Fault Tolerance

1. Fault tolerance, which is aimed at failure avoidance, is carried out via error detection and system recovery

• Fault handling is followed by corrective maintenance,

aimed at removing faults that were isolated by fault handling

• Rollback and Rollforward are invoked on demand,

after error detection has taken place

• Error handling on demand followed by fault handling

together form system recovery

24

Reliable Software Design Course Spring 2007 - IUST 47 Reliable Software Design Course Spring 2007 - IUST 48

25

Reliable Software Design Course Spring 2007 - IUST 49

Fault tolerance coverage

• The measure of effectiveness of any given fault tolerance technique is

called its coverage

• Fault assumptions that differ from the faults really occurring in operation

Reliable Software Design Course Spring 2007 - IUST 50

Fault Removal

• Fault Removal During Development
• Step 1- verification
• Step 2- diagnosis
• Step 3- correction

26

Reliable Software Design Course Spring 2007 - IUST 51

Testing approaches

Reliable Software Design Course Spring 2007 - IUST 52

• Fault Removal During Use

– corrective or preventive maintenance – Corrective: remove faults that have produced one or more errors and have been reported – Preventive: uncovering and removing faults before they might cause errors

27

Reliable Software Design Course Spring 2007 - IUST 53

Fault Forecasting

• An evaluation of the system behavior with respect to

fault occurrence or activation.

• Evaluation has two aspects:

– qualitative or ordinal evaluation

• Identify, classify and rank the failure modes, e.g. failure mode and

effect analysis

– quantitative or probabilistic evaluation

• evaluate in terms of probabilities the extent to which some of the

attributes are satisfied, e.g. Markov chains and stochastic

• Petri nets

both forms of evaluation can be used, e.g. reliability block diagrams, fault-trees

Reliable Software Design Course Spring 2007 - IUST 54

Probabilistic fault-forecasting

• Two main approaches

1. modeling 2. Testing

– Modeling is composed of two phases:

• construction of a model
• Processing the model to obtain the expressions and the

values of the dependability measures of the system

28

Reliable Software Design Course Spring 2007 - IUST 55

Relation between the means

• Fault avoidance: how to aim for fault-free systems
• Fault acceptance: how to live with systems that are subject to faults
• Dependability and security analysis: reaching confidence in the ability to

deliver a service that can be trusted

• Dependability and security provision: providing the ability to deliver a

service that can be trusted

Reliable Software Design Course Spring 2007 - IUST 56