Home	About Gamma	Tour our Web Site	Events	White Papers	Services	Visitors' Book	How to contact us
				IMS	Internal Control	ISMS	Smart Cards	Common Criteria

In this section we propose a methodology for generating Risk Treatment Plans, which makes use of the fundamental theory which we have just discussed. 

We have used the methodology extensively in the information security arena.  We have taught senior managers/risk owners how to use it in various parts of the world and they have been able to apply it, not only in the context of information security but also to other business/governance concerns.  We therefore believe that this methodology works and is teachable, repeatable and reproducible.

We start by saying a little more about events and impacts on which the methodology is founded.

Events

Impacts

Risk Treatment Plans

Risk treatment is an ISO term that is means the "treatment process of selection and implementation of measures to modify risk [ISO Guide 73]".  We can use this concept to develop a simple methodology for applying our fundamental theory.  Figure 10 shows a fragment from our stylised form of a BS7799-2:2002 Risk Treatment Plan (RTP).

Figure 10: A fragment of a stylised Risk Treatment Plan

The process of producing the RTPs can be described in terms of a series of steps.

Step 1 - identify the events

Name the event and briefly describe it.  Our usual approach is to start with the standard events described above and augment them with client specific concerns.

Step 2 - identify the assets

We usually start with a generic list that includes such things as:

• Buildings and contents
• IT hardware and networks
• Infrastructure and application software
• Computerised data concerning the organisation's business
• Paper documents and records concerning the organisation's business
• Supporting data, documentation and records.

We will add to this list and otherwise modify it as necessary, the idea ultimately being to derive the assets that require protection from the analysis, rather than the other way round (which unfortunately seems to be the conventional way of carrying out a risk assessment).

Step 3 - identify the impacts

Our usual approach is to start with the standard impacts described above and augment them with client specific impacts as required.

Step 4 - identify the threats

We usually start with a generic list of threat agents that includes such entries as:

• Fire, flood and other forms of “natural disaster”
• Power and other utility failure
• Customers and suppliers
• Disaffected staff
• Spies
• Thieves
• Vandals and terrorists
• Hackers
• Errors and mistakes.

We will add to this list and otherwise modify it as necessary.

Step 5 - produce the RTPs

This step is repeated for each event.

First (see Figure 10), write down the description of the event and list the assets that are affected.  Augment/modify the asset inventory if there is an asset that we wish to refer to that is not already in the list.

Second, document the applicable impacts and order them in the priority they are to receive.  Record if any are to receive equal priority treatment.

Third, list the applicable threats.

Fourth, repeat the steps 5a - 5d below until all the impacts have been dealt with.  If the impacts are listed in priority order, take them in that order.  If two or more have the same priority, take them together.

Note also that:

• In practice the analysis for a given event-impact pair will break down into a number of "threads". Each thread takes some particular starting point to its logical conclusion, which is a statement of acceptable or unacceptable residual risk. 

• A useful starting point (which we illustrate in Step 5a below) is to consider some way in which a given threat agent can cause, in the context of the event, the impact under consideration.  Once this thread has been considered, the next thread would consider some other way in which the threat agent can cause the same impact. Finally, we should include a thread for which the threat agent is unknown.

• Quite often RTPs become repetitive.  We obviate this as much as possible through the order in which we deal with the events and through cross references between RTPs, where the procedures are the same albeit dealing with another thread or event/impact pair.

Step 5a - identify the risks leading to a particular impact (or impacts if the impacts have the same priority) for known threats

Consider the event and the impact(s).

The first question to ask is "what is being done about it already? ".

Unless we are really starting from a clean sheet of paper (which we might be doing in the case of a new system), there will already be procedures and technology in place to deal with the event-impact.  Even if we are considering something new, there may be policies that we are obliged to follow that dictate what procedures and technology we must put in place. If not, then we are free to identify what we need. In all three cases we will assume for the purpose of describing this methodology that those procedures/ technology are (or will be) documented.

We then ask, what do these procedures and technology accomplish in terms of this particular event-impact? and write down the answer.  We find it best to tell it like a story.  Say how a threat agent, in the context of this event, could bring about the impact under consideration, e.g. "A hacker could bring about the inability of the organisation to carry out some or all of its business by mounting a denial of service (DoS) attack on the network."  You then write down, in as few words as possible, what the (established) procedures and technology will do about this, e.g. "The first line of defence against such an attack is the firewall." Note that this is a Class 1 control.

We then document the risk, e.g. "Our ISP provides this firewall as a managed service.  We do not therefore know whether this firewall is always correctly configured, or if is under attack." Note that this is tantamount to saying "what if the first control does not work?".

We then ask if this risk is acceptable or not. If it is acceptable, say so and say why, e.g. "Nevertheless, this lack of knowledge is considered to be an acceptable risk because there is a second line of defence, which lies in hardening the network components in accordance with the IT policy for “Hotfix and service pack upgrades". Note in this example the introduction of another control to address the failure of the first.

The analysis proceeds in this way until all of the controls that are used (or are to be used) and their effects have been documented, e.g. following on from the previous example the RTP might say "However (a) Currently the internal network IP addresses are public addresses.  This presents an unacceptable risk and therefore we need to convert these addresses to private addresses; (b) There is a risk that a hacker could still exploit some known vulnerability for which the Hotfix had not yet been applied or exploit some other yet unreported vulnerability for which there is currently no Hotfix.  At present, this is an acceptable risk because of the low profile of our web site and those that it hosts for our customers."

Note that this "thread" terminates with both an unacceptable residual risk and an acceptable residual risk.

The next thread might consider hostile code insertion.

Step 5b - identify the risks leading to a particular impact for unknown threats

It is prudent to ensure that appropriate controls are in place to deal with the situation where the event has occurred for some unanticipated reason, i.e., the threat agent and/or the attack method was not known or anticipated at the time the analysis is performed.  It is possible that these will have already been identified during Step 5a, in which case Step 5b merely identifies what they are and explains how their workings are independent of threat agent and/or attack method.  If the controls identified in the Step 5a threads are not suitable, check whether others exist in the ICS that are suitable and document them.  If none can be found decide whether the residual risk is acceptable or not.

Step 5c - dealing with unacceptable residual risks

If a thread terminates with an unacceptable residual risk we need to do something about it.  We usually approach this by having a "To-Do-List".  We decide what needs to be done about the unacceptable risk - which at the very least will be to investigate the options - and append it to the To-Do-List. It is then a question of project managing the To-Do-List.  Of course, whilst a particular problem is being resolved, we are running an unacceptable risk.  It is possible that we cannot do anything about that apart from keeping our fingers crossed.  Otherwise, it would be appropriate to introduce some short-term measure.

Step 5d - optimising the ICS

The RTP thus far describes the control structure that exists and, via the To-Do-List, also that which is planned for the future. 

Identify the class (1-7) for each control. Sometimes we also find it useful to draw the Venn diagrams to show how the controls interact along a given thread.

Use the event and impact data and Table 4  to determine whether a different class for a particular control would be more appropriate.  Make your decisions in the context of the other controls, in particular the other controls in the same thread.

If we are dealing with a real life situation, the decision to change the control structure is recorded by making the appropriate entries in the To-Do-List.  We refer to such changes as "improvements".

If we are dealing with a future system (for example, if we are in the process of working out the ICS requirements for a new IT system) then we would merely change the control structure and iterate steps 5a - 5d.

Step 6 - tidy up

Once all the risk treatment plans have been developed, there may be a certain amount of tidying up to do.

First, check that all the assets in the asset inventory have be used.  If any are left over, ensure that that is not because of some oversight and, if not, remove them from the inventory. Note that new ones, not present in the initial list, may have been defined on the fly. Ensure that all the RTPs that ought to refer to these additional assets do so. Note that in this way we use the original list merely as a starting position.  Following augmentation and tidy-up we effectively finish with a list that is derived from the risk assessment.  In other words we identify those assets that require protection in order to ensure acceptability of risk rather than assume what needs protection and use the risk assessment to identify how they should be protected.

Second, check that all the impacts in the impact list have been dealt with.  If there are any discrepancies, or additional impacts have been added on the  fly, proceed as in the case of tidying up the assets.

Third, check that all the threat agents in the threat list have been dealt with. If there are any discrepancies, or additional impacts have been added on the  fly, proceed as in the case of tidying up the assets and impacts.

Fourth, ensure that all event-impact pairs have been dealt with.

Fifth, check that all threads end in a statement of acceptable/unacceptable risk.

Sixth, check that all control failures have been considered.

Finally, check that the To-Do-List entries remedy all unacceptable residual risks and implement all identified improvements.