Page 349 -

332 Chapter 12 Dependability and security specification

Asset Value Exposure

The information system High. Required to support all High. Financial loss as clinics may
clinical consultations. Potentially have to be canceled. Costs of
safety-critical. restoring system. Possible patient
harm if treatment cannot be
prescribed.

The patient database High. Required to support all High. Financial loss as clinics may
clinical consultations. Potentially have to be canceled. Costs of
safety-critical. restoring system. Possible patient
harm if treatment cannot be
prescribed.

An individual patient record Normally low although may be Low direct losses but possible loss
high for specific high-profile of reputation.
patients.

be requirements for the system infrastructure or the application system (risk
Figure 12.10 Asset
analysis in a reduction).
preliminary risk
assessment report An important input to the risk assessment and management process is the organi-
for the MHC-PMS
zational security policy. An organizational security policy applies to all systems and
should set out what should and what should not be allowed. For example, one aspect
of a military security policy may state ‘Readers may only examine documents whose
classification is the same as or below the reader’s vetting level.’ This means that if a
reader has been vetted to a ‘secret’ level, they may access documents that are classed
as ‘secret,’ ‘confidential,’ or ‘open’ but not documents classed as ‘top secret.’
The security policy sets out conditions that should always be maintained by a
security system and so helps identify threats that might arise. Threats are any-
thing that could threaten business security. In practice, security policies are usu-
ally informal documents that define what is and what isn’t allowed. However,
Bishop (2005) discusses the possibility of expressing security policies in a formal
language and generating automated checks to ensure that the policy is being
followed.
To illustrate this process of security risk analysis, consider the hospital informa-
tion system for mental health care, MHC-PMS. I don’t have space to discuss a com-
plete risk assessment here but rather draw on this system as a source of examples.
I have shown these as a fragment of a report (Figures 12.10 and 12.11) that might be
generated from the preliminary risk assessment process. This preliminary risk analysis
report is used in defining the security requirements.
From the risk analysis for the hospital information system, you can derive secu-
rity requirements. Some examples of these requirements are:

1. Patient information shall be downloaded, at the start of a clinic session, from the
database to a secure area on the system client.