Page 387 -

370 Chapter 14 Security engineering

costs of security procedures that may reduce these losses. Credit card companies do
this all the time. It is relatively easy to introduce new technology to reduce credit
card fraud. However, it is often cheaper for them to compensate users for their losses
due to fraud than to buy and deploy fraud-reduction technology. As costs drop and
attacks increase, this balance may change. For example, credit card companies are
now encoding information on an on-card chip instead of a magnetic strip. This
makes card copying much more difficult.
Risk management is a business issue rather than a technical issue so software
engineers should not decide what controls should be included in a system. It is up
to senior management to decide whether or not to accept the cost of security or the
exposure that results from a lack of security procedures. Rather, the role of soft-
ware engineers is to provide informed technical guidance and judgment on secu-
rity issues. They are, therefore, essential participants in the risk management
process.
As I explained in Chapter 12, a critical input to the risk assessment and man-
agement process is the organizational security policy. The organizational secu-
rity policy applies to all systems and should set out what should and should not
be allowed. The security policy sets out conditions that should always be main-
tained by a security system and so helps to identify risks and threats that might
arise. The security policy therefore defines what is and what is not allowed.
In the security engineering process, you design the mechanisms to implement
this policy.
Risk assessment starts before the decision to acquire the system has been made
and should continue throughout the system development process and after the sys-
tem has gone into use (Alberts and Dorofee, 2002). I also introduced, in Chapter 12,
the idea that this risk assessment is a staged process:

1. Preliminary risk assessment At this stage, decisions on the detailed system
requirements, the system design, or the implementation technology have not
been made. The aim of this assessment process is to decide if an adequate level
of security can be achieved at a reasonable cost. If this is the case, you can then
derive specific security requirements for the system. You do not have informa-
tion about potential vulnerabilities in the system or the controls that are included
in reused system components or middleware.

2. Life-cycle risk assessment This risk assessment takes place during the system
development life cycle and is informed by the technical system design and
implementation decisions. The results of the assessment may lead to changes to
the security requirements and the addition of new requirements. Known and
potential vulnerabilities are identified and this knowledge is used to inform
decision making about the system functionality and how it is to be implemented,
tested, and deployed.

3. Operational risk assessment After a system has been deployed and put into
use, risk assessment should continue to take account of how the system is