CS 5032 L6 reliability and security specification 2013

Dependability and Security Specification

Lecture 2

Reliability and security specification, 2013 Slide 1

Reliability specification

• Reliability can be measured so non-functional reliability
requirements may be specified quantitatively.
• Non-functional reliability requirements define the number
of failures that are acceptable during normal use of the
system or the time in which the system must be available.

• Functional reliability requirements 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.
• Software reliability requirements may also be
included to cope with hardware failure or operator
error.

The reliability specification process
Identify the types of system failure that
may lead to economic losses.
Risk identification

Estimate the costs
and consequences of Risk analysis
the different types of
software failure

Identify the root causes Risk
of system failure decomposition

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

Types of system failure

Failure type Description

Loss of service The system is unavailable and cannot deliver its
services to users. You may separate this into loss of
critical services and loss of non-critical services, where
the consequences of a failure in non-critical services
are less than the consequences of critical service
failure.

Incorrect service delivery The system does not deliver a service correctly to
users. Again, this may be specified in terms of minor
and major errors or errors in the delivery of critical and
non-critical services.

System/data corruption The failure of the system causes damage to the system
itself or its data. This will usually but not necessarily be
in conjunction with other types of failures.


Reliability metrics
• Reliability metrics
are units of
measurement of
system reliability.
• System reliability is
measured by
counting the number
of operational
failures and, where
appropriate, relating
these to the
demands made on
the system and the
time that the system
has been
Metrics operational.
* Probability of failure on demand
•
* Rate of occurrence of failures/Mean time to failure A long-term
* Availability measurement
programme is
required to assess
Reliability and security specification, 2013
the reliability of Slide 5
critical systems.

Probability of failure on demand
(POFOD)
• The probability that the
system will fail when a
request for service is
made.
• Used when demands for
service are intermittent
and relatively infrequent.
• Appropriate for protection
Protection system at Sizewell B power station systems where services
are demanded
Shuts down reactor if problems detected
occasionally and where
there are serious
consequence if the Slide 6

Rate of fault occurrence (ROCOF)

• Reflects the rate of
occurrence of failure in the
system.
– ROCOF of 0.002 means 2
failures are likely in each
1000 operational time units
e.g. 2 failures per 1000
hours of operation
• Relevant for systems where the
system has to process a large
number of similar requests in a
defined time period
– Credit card processing system,
supermarket checkout system.


Mean time to failure

• Reciprocal of ROCOF is
Mean time to Failure (MTTF)
– Relevant for systems with long
transactions i.e. where system
processing takes a long time (e.g.
CAD systems).

• MTTF should be longer than
expected transaction length
so that the system does not
normally fail during a session
or transaction


Availability

• Measure of the fraction of the
time that the system is
available for use.
• Takes repair and restart time
into account
• Availability of 0.998 means
software is available for 998
out of 1000 time units.
• Relevant for non-stop,
continuously running systems
– telephone switching systems,
railway signalling systems, e-
commerce systems, etc.

Availability specification

Availability Explanation

0.9 The system is available for 90% of the time. This means that,
in a 24-hour period (1,440 minutes), the system will be
unavailable for 144 minutes.

0.99 In a 24-hour period, the system is unavailable for 14.4
minutes.

0.999 The system is unavailable for 84 seconds in a 24-hour period.

0.9999 The system is unavailable for 8.4 seconds in a 24-hour
period. Roughly, one minute per week.


Failure consequences

• When specifying reliability, it is
not just the number of system
failures that matter but the
consequences of these failures.
• Failures that have serious
consequences are clearly more
damaging than those where
repair and recovery is
straightforward.
• In some cases, therefore,
different reliability specifications
for different types of failure may
be defined.

Over-specification of reliability

• Over-specification of reliability means that a high-
level of reliability is specified but it is not cost-
effective to achieve this.
• In many cases, it is cheaper to accept and deal with
failures rather than avoid them occurring.
• To avoid over-specification
– Specify reliability requirements for different types of failure.
Minor failures may be acceptable.
– Specify requirements for different services separately.
Critical services should have the highest reliability
requirements.
– Decide whether or not high reliability is really required or if
dependability goals can be achieved in some other way.

Steps to a reliability specification
For each sub-system,
analyse the
consequences of
possible system
failures. From the system failure Different metrics may be
analysis, partition used for different reliability
failures into appropriate requirements
classes
For each failure class
identified, set out the
reliability using an
appropriate metric
Identify functional
reliability requirements
to reduce the chances
of critical failures


Insulin pump specification
• Probability of failure (POFOD) is the
most appropriate metric.
– Relatively infrequent demands (10s
per day).
• Transient failures that can be repaired
by user actions such as recalibration of
the machine. A relatively low value of
POFOD is acceptable (say 0.002) –
one failure may occur in every 500
demands.
• Permanent failures require the
software to be re-installed by the
manufacturer. This should occur no
more than once per year. POFOD for
this situation should be less than Slide 14
0.00002.

Functional reliability requirements

• Checking requirements that identify checks to ensure
that incorrect data is detected before it leads to a
failure.
• Recovery requirements that are geared to help the
system recover after a failure has occurred.
• Redundancy requirements that specify redundant
features of the system to be included.
• Process requirements for reliability which specify the
development process to be used may also be
included.


Examples of functional reliability
requirements for MHC-PMS

RR1: A pre-defined range for all operator inputs shall be defined
and the system shall check that all operator inputs fall within this
pre-defined range. (Checking)
RR2: Copies of the patient database shall be maintained on two
separate servers that are not housed in the same building.
(Recovery, redundancy)
RR3: N-version programming shall be used to implement the
braking control system. (Redundancy)
RR4: The system must be implemented in a safe subset of Ada
and checked using static analysis. (Process)


Security specification

• Security specification has something in common with safety
requirements specification – in both cases, your concern is to
avoid something bad happening.
• 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.
– 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.

Security policy
• An organizational security policy applies
to all systems and sets out what should
and should not be allowed.
• For example, a military policy might be:
– Readers may only examine
documents whose classification is the
same as or below the readers vetting
level.
• A security policy sets out the conditions
that must be maintained by a security
system and so helps identify system
security requirements.


The preliminary risk assessment
process for security requirements


Security risk assessment
Identify the key
system assets (or
services) that have to
be protected.
Asset identification Estimate the value of the
identified assets

Asset value
assessment Assess the potential
losses associated with
each asset
Exposure
assessment

Threat identification

Identify the most
probable threats to
Reliability and security specification, 2013 the system assets Slide 20

Security risk assessment
Decompose threats
into possible attacks
on the system and the
ways that these may
occur
Attack assessment Propose the controls that
may be put in place to
protect an asset

Control Assess the technical
identification feasibility and cost of
the controls

Feasibility
assessment
Security
requirements
definition
Security requirements can be
infrastructure or application
Reliability and security specification, 2013 system requirements Slide 21

Asset analysis in a preliminary risk assessment report
for the MHC-PMS

Asset Value Exposure

The information system High. Required to support all High. Financial loss as
clinical consultations. clinics may have to be
Potentially safety-critical. canceled. Costs of restoring
system. Possible patient
harm if treatment cannot be
prescribed.

The patient database High. Required to support all High. Financial loss as
clinical consultations. clinics may have to be
Potentially safety-critical. canceled. Costs of restoring
system. Possible patient
harm if treatment cannot be
prescribed.

An individual patient record Normally low although may Low direct losses but
be high for specific high- possible loss of reputation.
profile patients.


Threat and control analysis in a
preliminary risk assessment report

Threat Probability Control Feasibility

Unauthorized user Low Only allow system Low cost of implementation
gains access as management from but care must be taken with
system manager specific locations key distribution and to
and makes system that are physically ensure that keys are
unavailable secure. available in the event of an
emergency.

Unauthorized user High Require all users to Technically feasible but
gains access as authenticate high-cost solution. Possible
system user and themselves using a user resistance.
accesses biometric
confidential mechanism. Simple and transparent to
information implement and also
Log all changes to supports recovery.
patient information to
track system usage.


Security requirements for the MHC-PMS

• Patient information shall be downloaded at the start
of a clinic session to a secure area on the system
client that is used by clinical staff.
• All patient information on the system client shall be
encrypted.
• Patient information shall be uploaded to the database
after a clinic session has finished and deleted from
the client computer.
• A log on a separate computer from the database
server must be maintained of all changes made to the
system database.

Formal methods and specification


Formal methods and critical systems

• Formal specification is part of a more general
collection of techniques that are known as ‘formal
methods’.
• These are all based on mathematical representation
and analysis of software.
• Formal methods include
– Formal specification;
– Specification analysis and proof;
– Transformational development;
– Program verification.


Use of formal methods

• The principal benefits of formal
methods are in reducing the
number of faults in systems.
• Consequently, their main area of
applicability is in critical systems
engineering. There have been
several successful projects where
formal methods have been used
in this area.
• In this area, the use of formal
methods is most likely to be cost-
effective because high system
failure costs must be avoided.

Specification in the software process

• Specification and design are inextricably
intermingled.
• Architectural design is essential to structure a
specification and the specification process.
• Formal specifications are expressed in a
mathematical notation with precisely defined
vocabulary, syntax and semantics.


Formal specification in a plan-based
software process


Benefits of formal specification

• Developing a formal specification requires the system
requirements to be analyzed in detail. This helps to detect
problems, inconsistencies and incompleteness in the
requirements.
• As the specification is expressed in a formal language, it
can be automatically analyzed to discover inconsistencies
and incompleteness.
• If you use a formal method such as the B method, you can
transform the formal specification into a ‘correct’ program.
• Program testing costs may be reduced if the program is
formally verified against its specification.


Acceptance of formal methods

• Formal methods have had limited impact on practical
software development:
– Problem owners cannot understand a formal specification
and so cannot assess if it is an accurate representation of
their requirements.
– It is easy to assess the costs of developing a formal
specification but harder to assess the benefits. Managers
may therefore be unwilling to invest in formal methods.
– Software engineers are unfamiliar with this approach and are
therefore reluctant to propose the use of FM.
– Formal methods are still hard to scale up to large systems.
– Formal specification is not really compatible with agile
development methods.


Key points

• Reliability requirements can be defined quantitatively. They
include probability of failure on demand (POFOD), rate of
occurrence of failure (ROCOF) and availability (AVAIL).
• 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.
• Formal methods of software development rely on a system
specification that is expressed as a mathematical model. The
use of formal methods avoids ambiguity in a critical systems
specification.

CS 5032 L6 reliability and security specification 2013

More Related Content

What's hot (20)

Viewers also liked (15)

Similar to CS 5032 L6 reliability and security specification 2013 (20)

More from Ian Sommerville (13)

Recently uploaded (20)

CS 5032 L6 reliability and security specification 2013