Page 392 -

14.2 Design for security 375

quickly after they have been set up, and action can then be taken to ensure that users
change their password.
The second and third requirements mean that all users will always access the sys-
tem through the same browser. You can decide what is the most secure browser when
the system is deployed and install that on all client computers. Security updates are
simplified because there is no need to update different browsers when security vul-
nerabilities are discovered and fixed.

14.1.2 Operational risk assessment
Security risk assessment should continue throughout the lifetime of the system to
identify emerging risks and system changes that may be required to cope with these
risks. This process is called operational risk assessment. New risks may emerge
because of changing system requirements, changes in the system infrastructure, or
changes in the environment in which the system is used.
The process of operational risk assessment is similar to the life-cycle risk assess-
ment process, but with the addition of further information about the environment in
which the system is used. The environment is important because characteristics of
the environment can lead to new risks to the system. For example, say a system is
being used in an environment in which users are frequently interrupted. A risk is that
the interruption will mean that the user has to leave their computer unattended. It
may then be possible for an unauthorized person to gain access to the information in
the system. This could then generate a requirement for a password-protected screen
saver to be run after a short period of inactivity.

14.2 Design for security

It is generally true that it is very difficult to add security to a system after it has been
implemented. Therefore, you need to take security issues into account during the
systems design process. In this section, I focus primarily on issues of system design,
because this topic isn’t given the attention it deserves in computer security books.
Implementation issues and mistakes also have a major impact on security but these
are often dependent on the specific technology used. I recommend Viega and
McGraw’s book (2002) as a good introduction to programming for security.
Here, I focus on a number of general, application-independent issues relevant to
secure systems design:

1. Architectural design—how do architectural design decisions affect the security
of a system?

2. Good practice—what is accepted good practice when designing secure systems?
3. Design for deployment—what support should be designed into systems to avoid
the introduction of vulnerabilities when a system is deployed for use?