Page 346 -

12.4 Security specification 329

12.4 Security specification

The specification of security requirements for systems has something in common
with safety requirements. It is impractical to specify them quantitatively, and secu-
rity requirements are often ‘shall not’ requirements that define unacceptable system
behavior rather than required system functionality. However, security is a more chal-
lenging problem than safety, for a number of reasons:

1. When considering safety, you can assume that the environment in which the
system is installed is not hostile. No one is trying to cause a safety-related inci-
dent. When considering security, you have to assume that attacks on the system
are deliberate and that the attacker may have knowledge of system weaknesses.
2. When system failures occur that pose a risk to safety, you look for the errors or
omissions that have caused the failure. When deliberate attacks cause system
failures, finding the root cause may be more difficult as the attacker may try to
conceal the cause of the failure.
3. It is usually acceptable to shut down a system or to degrade system services to
avoid a safety-related failure. However, attacks on a system may be so-called
denial of service attacks, which are intended to shut down the system. Shutting
down the system means that the attack has been successful.
4. Safety-related events are not generated by an intelligent adversary. An attacker
can probe a system’s defenses in a series of attacks, modifying the attacks as he
or she learns more about the system and its responses.

These distinctions mean that security requirements usually have to be more exten-
sive than safety requirements. Safety requirements lead to the generation of func-
tional system requirements that provide protection against events and faults that
could cause safety-related failures. They are mostly concerned with checking for
problems and taking actions if these problems occur. By contrast, there are many
types of security requirements that cover the different threats faced by a system.
Firesmith (2003) has identified 10 types of security requirements that may be
included in a system specification:

1. Identification requirements specify whether or not 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.

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.