Page 354 -

Chapter 12 Exercises 337

It is important not to overspecify the required system reliability as this leads to unnecessary
additional costs in the development and validation processes.

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. Developing a formal specification has the key benefit of stimulating a
detailed examination and analysis of the system requirements.

FURTHER RE ADING

Safeware: System Safety and Computers. This is a thorough discussion of all aspects of safety-
critical systems. It is particularly strong in its description of hazard analysis and the derivation of
requirements from this. (N. Leveson, Addison-Wesley, 1995.)
‘Security Use Cases.’ A good article, available on the Web, that focuses on how use cases can be
used in security specification. The author also has a number of good articles on security
specification that are referenced in this article. (D. G. Firesmith, Journal of Object Technology, 2 (3),
May–June 2003.) http://www.jot.fm/issues/issue_2003_05/column6/.
‘Ten Commandments of Formal Methods . . .Ten Years Later.’ This is a set of guidelines for the use of
formal methods that was first proposed in 1996 and which are revisited in this paper. It is a good
summary of the practical issues around the use of formal methods. (J. P. Bowen and M. G. Hinchey,
IEEE Computer, 39 (1), January 2006.) http://dx.doi.org/10.1109/MC.2006.35.
‘Security Requirements for the Rest of Us: A Survey.’ A good starting point for reading about security
requirements specification. The authors focus on lightweight rather than formal approaches. (I. A.
Tøndel, M. G. Jaatun, and P. H. Meland, IEEE Software, 25 (1), January/February 2008.)
http://dx.doi.org/10.1109/MS.2008.19.

E XERCISES

12.1. Explain why the boundaries in the risk triangle shown in Figure 12.12 are liable to change with
time and changing social attitudes.
12.2. Explain why the risk-based approach is interpreted in different ways when specifying safety
and security.