Page 397 -

380 Chapter 14 Security engineering

application has one absolute requirement to maintain the confidentiality of a large
database and another requirement for very fast access to that data. A high level of
protection suggests that layers of protection are required, which means that there
must be communications between the system layers. This has an inevitable perform-
ance overhead, thus will slow down access to the data. If an alternative architecture
is used, then implementing protection and guaranteeing confidentiality may be more
difficult and expensive. In such a situation, you have to discuss the inherent conflicts
with the system client and agree on how these are to be resolved.

14.2.2 Design guidelines

There are no hard and fast rules about how to achieve system security. Different
types of systems require different technical measures to achieve a level of security
that is acceptable to the system owner. The attitudes and requirements of different
groups of users profoundly affect what is and is not acceptable. For example, in a
bank, users are likely to accept a higher level of security, and hence more intrusive
security procedures than, say, in a university.
However, there are general guidelines that have wide applicability when design-
ing system security solutions, which encapsulate good design practice for secure
systems engineering. General design guidelines for security, such as those discussed,
below, have two principal uses:

1. They help raise awareness of security issues in a software engineering team.
Software engineers often focus on the short-term goal of getting the software
working and delivered to customers. It is easy for them to overlook security
issues. Knowledge of these guidelines can mean that security issues are consid-
ered when software design decisions are made.

2. They can be used as a review checklist that can be used in the system validation
process. From the high-level guidelines discussed here, more specific questions
can be derived that explore how security has been engineered into a system.

The 10 design guidelines, summarized in Figure 14.6, have been derived from a
range of different sources (Schneier, 2000; Viega and McGraw, 2002; Wheeler,
2003). I have focused here on guidelines that are particularly applicable to the soft-
ware specification and design processes. More general principles, such as ‘Secure
the weakest link in a system’, ‘Keep it simple’, and ‘Avoid security through obscu-
rity’ are also important but are less directly relevant to engineering decision making.

Guideline 1: Base security decisions on an explicit security policy
A security policy is a high-level statement that sets out fundamental security condi-
tions for an organization. It defines the ‘what’ of security rather than the ‘how’, so
the policy should not define the mechanisms to be used to provide and enforce secu-
rity. In principle, all aspects of the security policy should be reflected in the system