DEPENDABILITY

AND SECURITY
SPECIFICATIONS
TOPICS COVERED

▰ Risk-driven requirements specification

▰ Safety specification
▰ Reliability specification
▰ Security specification
▰ Formal specification

2
DEPENDABILITY & SECURITY REQUIREMENTS

▰ Functional requirements which define checking and

recovery facilities that should be included in the system and
features that provide protection against system failures and
external attacks.

▰ Non-functional requirements which define the required

reliability and availability of the system.

3
1
RISK-DRIVEN SPECIFICATION

4
RISK-DRIVEN SPECIFICATION

Risk-driven specification is an approach that has been widely

used in safety and security critical systems.

The aim of the specification process should be to understand the

risks (safety, security, etc.) faced by the system and to define
requirements that reduce these risks.

5
RISK-DRIVEN SPECIFICATION

▰ Safety-critical systems the risks are associated with hazards

that can result in accidents.

▰ Security-critical systems the risks come from insider and

outsider attacks on a system that are intended to exploit
possible vulnerabilities.

6
RISK-DRIVEN SPECIFICATION

Risk identification identify potential risks that may arise.

Risk analysis and classification assess the seriousness of each risk.
Risk decomposition decompose risks to discover their potential root causes.
Risk reduction assessment define how each risk must be taken into eliminated
or reduced when the system is designed.
7
RISK-DRIVEN REQUIREMENTS SPECIFICATION

For large systems, risk analysis may be structured into phases,

where each phase considers different types of risks:
▰ Preliminary risk analysis where major risks from the
system’s environment are identified.
▰ Life-cycle risk analysis which takes place during system
development and which is mostly concerned with risks that
arise from system design decisions.
▰ Operational risk analysis which is concerned with the
system user interface and risks from operator errors.
8
2
SAFETY SPECIFICATION

9
SAFETY SPECIFICATION

The principal concern of safety specification is to identify

protection requirements that ensure that system failures do not
cause injury, death or environmental damage.

10
SAFETY SPECIFICATION

Hazard identification
▰ Identify the hazards that may threaten the system.
▰ Hazard identification may be based on different types of
hazard:
▻ Physical hazards
▻ Electrical hazards
▻ Biological hazards
▻ Service failure hazards
11
▻ Etc.
SAFETY SPECIFICATION

Hazard assessment
▰ the process is concerned with understanding the likelihood
that a risk will arise and the potential consequences if an
accident or incident should occur.
▰ Risks may be categorized as:
▻ Intolerable
▻ As low as reasonably practical (ALARP)
▻ Acceptable
12
SAFETY SPECIFICATION

The risk triangle

The shape of the diagram
reflects the cost of ensuring
risks do not result in incidents.
The cost of system design to
cope with the risk is indicated
by the width of the triangle.

13
SAFETY SPECIFICATION

Hazard analysis
▰ the process of discovering the root causes of hazards in a
safety-critical system. Your aim is to find out what events or
combination of events could cause a system failure that
results in a hazard.
▰ Techniques have been mostly derived from safety-critical
systems and can be:
▻ Deductive, top-down techniques
▻ Inductive, bottom-up techniques
14
SAFETY SPECIFICATION

Fault-tree analysis
▰ A deductive top-down technique

▰ Put the risk or hazard at the root of the tree

and identify the system
states that could lead to
that hazard.

15
SAFETY SPECIFICATION

Risk reduction
▰ The aim of this process is to identify dependability
requirements that specify how the risks should be managed
and ensure that incidents or accidents do not occur.
▰ Three possible strategies:
▻ Hazard avoidance
▻ Hazard detection and removal
▻ Damage limitation
16
3
RELIABILITY SPECIFICATION

17
RELIABILITY SPECIFICATION

Reliability is a measurable system attribute so nonfunctional

reliability requirements may be specified quantitatively. These
define the number of failures that are acceptable during normal
use of the system or the time in which the system must be
available.

18
RELIABILITY SPECIFICATION

Reliability requirements are, therefore, of two kinds:

▰ Non-functional requirements, which define the number
of failures that are acceptable during normal use of the
system, or the time in which the system is unavailable for
use. These are quantitative reliability requirements.
▰ Functional requirements, which define system and
software functions that avoid, detect, or tolerate faults in
the software and so ensure that these faults do not lead to
system failure.
19
RELIABILITY SPECIFICATION

Reliability specification process:

Risk identification
▰ Identify the types of system failure that may lead to
economic losses.

Risk analysis
▰ estimate the costs and consequences of the different types of
software failure.
20
RELIABILITY SPECIFICATION

Risk decomposition
▰ Identify the root causes of system failure

Risk reduction
▰ Generate reliability specifications, including quantitative
requirements defining the acceptable levels of failure.

21
RELIABILITY SPECIFICATION

Reliability metrics
▰ Reliability metrics are units of measurement of system
reliability

▰ System reliability is measured by counting the number of

operational failures and relating these to demands made on
the system and the time that the system has been
operational.

22
RELIABILITY SPECIFICATION

Reliability Metrics
▰ Probability of failure on demand (PROFOD)
▰ Rate of occurrence of failures (ROCOF)
▰ Availability

23
RELIABILITY SPECIFICATION

Probability of failure on demand (PROFOD)

▰ If you use this metric, you define the probability that a
demand for service from a system will result in a system
failure.

So, POFOD=0.001 means that there is a 1/1,000 chance that a

failure will occur when a demand is made.

24
RELIABILITY SPECIFICATION

Rate of occurrence of failures (ROCOF)

▰ This metric sets out the probable number of system
failures that are likely to be observed relative to a certain
time period.
▰ The reciprocal of ROCOF is the mean time to failure
(MTTF), which is sometimes used as a reliability metric.

Therefore, a ROCOF of two failures per hour implies that the

mean time to failure is 30 minutes.
25
RELIABILITY SPECIFICATION

Availability (AVAIL)
▰ The availability of a system reflects its ability to deliver
services when requested. AVAIL is the probability that a
system will be operational when a demand is made for
service.

Therefore, an availability of 0.9999,means that, on average, the

system will be available for 99.99% of the operating time.

26
RELIABILITY SPECIFICATION

Non-functional reliability requirements

▰ quantitative specifications of the required reliability and
availability of a system.

Functional reliability specification

▰ involves identifying requirements that define constraints
and features that contribute to system reliability.

27
RELIABILITY SPECIFICATION

Types of functional reliability requirements for a system:

Checking requirements
▰ identify checks ensuring that incorrect data is detected
before it leads to a failure
Recovery requirements
▰ geared to help the system recover after a failure has
occurred.
Redundancy requirements
▰ specify redundant features of the system to be included 28
4
SECURITY SPECIFICATION

29
SECURITY SPECIFICATION

Security specification has something in common with safety

requirements specification – in both cases, your concern is to
avoid something bad happening.

30
SECURITY SPECIFICATION

Four major differences:

▰ Safety problems are accidental– the software is not
operating in a hostile environment. In security, you must
assume that attackers have knowledge of system
weaknesses.
▰ When safety failures occur, you can look for the root cause
or weakness that led to the failure. When failure results
from a deliberate attack, the attacker may conceal the cause
of the failure.
31
SECURITY SPECIFICATION

▰ Shutting down a system can avoid a safety-related failure.

Causing a shut down may be the aim of an attack.

▰ Safety-related events are not generated from an intelligent

adversary. An attacker can probe defenses over time to
discover weaknesses.

32
SECURITY SPECIFICATION

Firesmith (2003) has identified 10 types of security

requirements that may be included in a system specification:
1. Identification requirements specify whether a system
should identify its users before interacting with them.
2. Authentication requirements specify how users are
identified.
3. Authorization requirements specify the privileges and
access permissions of identified users.

33
SECURITY SPECIFICATION

4. Immunity requirements specify how a system should

protect itself against viruses, worms, and similar threats.
5. Integrity requirements specify how data corruption can
be avoided.
6. Intrusion detection requirements specify what
mechanisms should be used to detect attacks on the
system.
7. Non-repudiation requirements specify that a party in a
transaction cannot deny its involvement in that transaction.
34
SECURITY SPECIFICATION

8. Privacy requirements specify how data privacy is to be

maintained.
9. Security auditing requirements specify how system use
can be audited and checked.
10. System maintenance security requirements specify how
an application can prevent authorized changes from
accidentally defeating its security mechanisms.

35
5
FORMAL SPECIFICATION

36
FORMAL SPECIFICATION

Formal methods of software development rely on a system

specification that is expressed as a mathematical model.
Developing a formal specification has the key benefit of
stimulating a detailed examination and analysis of the system
requirement.

37
KEY POINTS

▰ Risk analysis is an important activity in the specification of

security and dependability requirements. It involves
identifying risks that can result in incidents. System
requirements are then generated to ensure that these risks do
not occur and, if they do, that they do not lead to an
incident.

38
KEY POINTS

▰ A hazard-driven approach may be used to understand the

safety requirements for a system. You identify potential
hazards and decompose these (using methods such as fault
tree analysis) to discover their root causes. You then specify
requirements to avoid or recover from these problems.

39
KEY POINTS

▰ Reliability requirements can be defined quantitatively in the

system requirements specification. Reliability metrics
include probability of failure on demand (POFOD), rate of
occurrence of failure (ROCOF), and availability (AVAIL).

▰ It is important not to overspecify the required system

reliability as this leads to unnecessary additional costs in the
development and validation processes

40
KEY POINTS

▰ Security requirements are more difficult to identify than

safety requirements because a system attacker can use
knowledge of system vulnerabilities to plan a system attack
and can learn about vulnerabilities from unsuccessful
attacks.

▰ To specify security requirements, you should identify the

assets that are to be protected and define how security
techniques and technology should be used to protect these
assets. 41
THANK YOU!

42