Information Security Risk

This part of the IMS deals with information security risk.

The approach taken is based on the methodology presented by Brewer and List in their paper on "Measuring the effectiveness of an internal control system" (the "time" theory) . In this methodology an event describes how a threat agent might exploit some vulnerability to compromise the security of some asset and cause some impact. The events, threat agents, vulnerabilities, assets and impacts are considered generically in order to maximise the efficiency of the risk analysis process, as the objective of the exercise is to identify what security controls, in particular those listed in the SOA, are required to reduce information security risk to an acceptable level.

Risk is determined in the context of our particular information security objectives, which are defined as part of our IMS Policy; our particular information infrastructure, which is described in terms of our IT and the various threat environments in which our information may be stored, processed and/or communicated.

The risk assessment is performed by taking each event in turn and:

• Identifying the assets, as listed in the Asset Table, that may be effected;
• Identifying the threat agents, as listed in the Threat Table, that might cause the event;
• Identifying the vulnerabilities, as listed in the Vulnerability Table, that might be exploited;
• Identifying the impacts, as listed in the Impact Table, that might then result;
• Estimating the likelihood (or frequency) of the event as it may occur under each of the circumstances listed in the Event Table and the scale of the resultant impact in the absence of any controls;
• Excluding events which are then treated by avoiding the risk;
• Excluding events which are deemed acceptable without mitigation by any control;
• Determining the effect that existing controls (either controls that mitigate or transfer risk) have on modifying the likelihood (or frequency) of the impact and/or the scale of the impact (which is, of course, the residual risk);
• Applying the risk acceptance criteria;
• Deciding on the acceptability (or otherwise) of the residual risk;
• If the risk is unacceptable, or borderline, deciding on what action to take.

The results are presented in the Risk Treatment Plans (RTPs) and, for convenience, a summary of the residual risks is given at the end of this page.

To assist in ensuring that the assessment achieves comparable and reproducible results:

• A standard approach to risk mitigation is used to assess the effect that controls have on reducing the likelihood (or frequency) and scale of an impact;
• The effectiveness of the risk-assessment/risk-treatment processes is verified using the SOA, by justifying each of the 133 controls listed in Annex A to ISO/IEC 27001 as being either non-applicable or required by virtue of at least one IMS Policy statement or RTP. The SOA is also used in cases where the risk is found to be unacceptable for identifying the controls necessary to reduce the risk to an acceptable level.

Information Infrastructure

Information Technology

Summarise in this section your IT infrastructure. The principal component should be a block diagram showing geographic layout and major network components, plus a paragraph of text or so to describe it.

Threat Environments

Describe here, with reference to the block diagram in the previous section, the various threat environments in which information is stored, processed and communicated. Note that there will normally be at least two threat environments as people working in an office environment, usually live somewhere else. Give a name to each environment. You may need to refer to them in the section on events, as some (but not all) conditions are in reality different threat environments.

.

Vulnerabilities

Impacts

We use a five point scale to measure impact:

• Grave () - the impact has grave consequences on the organisation, perhaps leading to cessation of its operations
  
  
• Prejudicial ( ) - the impact is prejudicial to the smooth operations of the organisation, with significant loss of profitability, market share, share price and extraordinary costs
  
  
• Serious ( ) - the impact is serious, with noticeable losses of profitability, market share and share price, and additional costs
  
  
• Embarrassing ( ) - the impact is embarrassing; losses of profitability, market share and share price, and additional costs are nevertheless absorbable
  
  
• Irritating ( ) - the impact is an irritation; losses of profitability, market share and share price, and additional costs are negligible.

Impact ID	Description	Magnitude
I-FRD	Fraud
I-ICB	Inability to carry out some or all of our business
I-LMV	Loss of the monetary value of assets
I-UDI	Undesirable disclosure of information

Consequential impacts

Events

We use a different five point scale to measure the likelihood (or frequency) of an event:

• Extremely likely ( ) - the event occurs, or is likely to occur several times a day or more
  
  
• Very likely ( ) - the event occurs, or is likely to occur every few days
  
  
• Likely ( ) - the event occurs, or is likely to occur about once a month
  
  
• Unlikely ( ) - the event occurs, or is likely to occur about once a year
  
  
• Rarely ( ) - the event occurs, or is likely to occur about once a decade or longer.

Event ID	Description		Circumstance	Likelihood (or frequency)
ES1	Vulnerability exploitation: An attacker exploits a security vulnerability to cause the undesirable disclosure of information, fraud or denial of service ...		SEE ES3 BELOW FOR SOME EXAMPLES OF EVENT CIRCUMSTANCES
ES2	IT failure: Our IT fails because of a hardware or software malfunction ...		SEE ES3 BELOW FOR SOME EXAMPLES OF EVENT CIRCUMSTANCES
ES3	Dispossession: A physical container of information is dispossessed...		Loss Theft (from office premises) Theft (from elsewhere) Damage/ destruction Misappropriation Disposal and reuse

Risk Mitigation

Instructions for Dealing with Unacceptable Risk

Describe the action that is taken if a risk is found to be unacceptable.

As an example, a report may need to be written and submitted to management for approval; the proposed plan may need to identify management action, resources, and include consideration of funding and allocation of roles and responsibilities, etc. It ought also give an indication of what the residual risk would then be.

Note that once an unacceptable risk has been identified, operations that give rise to the event should cease. The instructions should say this.

Risk Treatment Plans (RTPs)

Each RTP presents the overall design of a suite of controls, showing how the individual controls work together to prevent an event, or if that cannot be done or a control fails, how the event can be detected in good time to do something about it, and if that fails how to mitigate and/or recover from the resultant impact. These designs make use of the Brewer-List time theory referred to above, which has been extended in this IMS to cover anticipation of events (i.e., the use of tell-tale signs, based on past experiences, to predict the onset of an event). There is one RTP for each event:

• ES1 - Vulnerability exploitation
• ES2 - IT failure
• ES3 - Dispossession

Summary of Residual Risk

Summarise here the residual risks. Use a table, or perhaps a picture. Highlight any unacceptable risks and reference whatever record there will be having followed the instructions cited above on dealing with unacceptable risk. If there are no unacceptable risks, say so.

The residual risks are determined in the RTPs. The following diagram summarises them and shows the boundary of acceptable risk as determined by our criteria. Complete this section by ensuring the the correct image has the name "../Images/residualRisk.gif" and is located in the Image directory.

All risks are acceptable.