Security specification Software Engineering 9th ed (intro txt) I. Sommerville (Pearson, 2011)
330 Chapter 12
■
Dependability and security specification
6. Intrusion detection requirements specify what mechanisms should be used to
detect attacks on the system. 7.
Non-repudiation requirements specify that a party in a transaction cannot deny its involvement in that transaction.
8. Privacy requirements specify how data privacy is to be maintained.
9. Security auditing requirements specify how system use can be audited and
checked. 10. System maintenance security requirements specify how an application can pre-
vent authorized changes from accidentally defeating its security mechanisms. Of course, you will not see all of these types of security requirements in every
system. The particular requirements depend on the type of system, the situation of use, and the expected users.
The risk analysis and assessment process discussed in Section 12.1 may be used to identify system security requirements. As I discussed, there are three stages to this
process: 1.
Preliminary risk analysis At this stage, decisions on the detailed system require- ments, the system design, or the implementation technology have not been
made. The aim of this assessment process is to derive security requirements for the system as a whole.
2. Life-cycle risk analysis This risk assessment takes place during the system
development life cycle after design choices have been made. The additional security requirements take account of the technologies used in building the sys-
tem and system design and implementation decisions.
3. Operational risk analysis This risk assessment considers the risks posed by
malicious attacks on the operational system by users, with or without insider knowledge of the system.
The risk assessment and analysis processes used in security requirements specifi- cation are variants of the generic risk-driven specification process discussed in
Security risk management Safety is a legal issue and businesses cannot decide to opt out of producing safe systems. However, some
aspects of security are business issues—a business can decide not to implement some security measures and to cover the losses that may result from this decision. Risk management is the process of deciding what assets
must be protected and how much can be spent on protecting them.
http:www.SoftwareEngineering-9.comWebSecurityRiskMan.html
12.4
■
Security specification 331
Section 12.1. A risk-driven security requirements process is shown in Figure 12.9. This may appear to be different from the risk-driven process in Figure 12.1, but
I indicate how each stage corresponds to stages in the generic process by including the generic process activity in brackets. The process stages are:
1. Asset identification, where the system assets that may require protection are
identified. The system itself or particular system functions may be identified as assets as well as the data associated with the system risk identification.
2. Asset value assessment, where you estimate the value of the identified assets
risk analysis. 3.
Exposure assessment, where you assess the potential losses associated with each asset. This should take into account direct losses such as the theft of infor-
mation, the costs of recovery, and the possible loss of reputation risk analysis.
4. Threat identification, where you identify the threats to system assets risk
analysis. 5.
Attack assessment, where you decompose each threat into attacks that might be made on the system and the possible ways in which these attacks may occur.
You may use attack trees Schneier, 1999 to analyze the possible attacks. These are similar to fault trees as you start with a threat at the root of the tree and iden-
tify possible causal attacks and how these might be made risk decomposition.
6. Control identification, where you propose the controls that might be put in place
to protect an asset. The controls are the technical mechanisms, such as encryp- tion, that you can use to protect assets risk reduction.
7. Feasibility assessment, where you assess the technical feasibility and the costs
of the proposed controls. It is not worth having expensive controls to protect assets that don’t have a high value risk reduction.
8. Security requirements definition, where knowledge of the exposure, threats, and
control assessments is used to derive system security requirements. These may
Asset Identification
Asset Value Assessment
Threat Identification
Attack Assessment
Exposure Assessment
Security Req. Definition
Control Identification
Feasibility Assessment
Figure 12.9 The
preliminary risk assessment process
for security requirements
332 Chapter 12
■
Dependability and security specification
be requirements for the system infrastructure or the application system risk reduction.
An important input to the risk assessment and management process is the organi- 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.
Figure 12.10 Asset
analysis in a preliminary risk
assessment report for the MHC-PMS
Asset Value
Exposure
The information system High. Required to support all
clinical consultations. Potentially safety-critical.
High. Financial loss as clinics may have to be canceled. Costs of
restoring system. Possible patient harm if treatment cannot be
prescribed.
The patient database High. Required to support all
clinical consultations. Potentially safety-critical.
High. Financial loss as clinics may have to be canceled. Costs of
restoring system. Possible patient harm if treatment cannot be
prescribed.
An individual patient record Normally low although may be
high for specific high-profile patients.
Low direct losses but possible loss of reputation.
12.5
■
Formal specification 333
2. All patient information on the system client shall be encrypted.
3. Patient information shall be uploaded to the database when a clinic session is
over and deleted from the client computer. 4.
A log of all changes made to the system database and the initiator of these changes shall be maintained on a separate computer from the database server.
The first two requirements are related—patient information is downloaded to a local machine so that consultations may continue if the patient database server is
attacked or becomes unavailable. However, this information must be deleted so that later users of the client computer cannot access the information. The fourth require-
ment is a recovery and auditing requirement. It means that changes can be recovered by replaying the change log and that it is possible to discover who has made the
changes. This accountability discourages misuse of the system by authorized staff.