Page 329 -

312 Chapter 12 Dependability and security specification

At this stage, risks may be eliminated because they are unlikely to arise or
because they cannot be detected by the software (e.g., an allergic reaction to the
sensor in the insulin pump system).
3. Risk decomposition Each risk is analyzed to discover potential root causes of
that risk. Root causes are the reasons why a system may fail. They may be soft-
ware or hardware errors or inherent vulnerabilities that result from system
design decisions.
4. Risk reduction Proposals for ways in which the identified risks may be
reduced or eliminated are made. These contribute to the system dependability
requirements that define the defenses against the risk and how the risk will be
managed.

For large systems, risk analysis may be structured into phases (Leveson, 1995),
where each phase considers different types of risks:

1. Preliminary risk analysis, where major risks from the system’s environment are
identified. These are independent from the technology used for system develop-
ment. The aim of preliminary risk analysis is to develop an initial set of security
and dependability requirements for the system.

2. Life-cycle risk analysis, which takes place during system development and
which is mostly concerned with risks that arise from system design decisions.
Different technologies and system architectures have their own associated
risks. At this stage, you should extend the requirements to protect against
these risks.
3. Operational risk analysis, which is concerned with the system user interface and
risks from operator errors. Again, once decisions have been made on the user
interface design, further protection requirements may have to be added.

These phases are necessary because it is impossible to make all dependability and
security decisions without complete information about the system implementation.
Security and dependability requirements are particularly affected by technology
choices and design decisions. System checks may have to be included to ensure that
third-party components have operated correctly. Security requirements may have to
be modified because they conflict with the security features that are provided by an
off-the-shelf system.
For example, a security requirement may be that users should identify themselves
to a system using a pass phrase rather than a password. Pass phrases are considered
to be more secure than passwords. They are harder for an attacker to guess or to dis-
cover using an automated password cracking system. However, if a decision is made
to use an existing system that only supports password-based authentication, then this
security requirement cannot be supported. It may then be necessary to include addi-
tional functionality in the system to compensate for the increased risks of using
passwords rather than pass phrases.