Risk management: Calculated risk

Sociologists claim that the element of risk is disappearing from our everyday lives, and that this is forcing increasing numbers of people to take up "extreme" sports. But business risk is a less-publicised issue, and information risk is playing an increasingly central role in this area. It's becoming a major part of compliance measurement and will soon be coming to an IT department near you - so what do you need to know about information risk management (IRM)?

The first step is conducting a risk assessment. "The trouble with risk management is that a lot of people see it as being just a mass of buzzwords and lose sight of what they're actually doing," says David Cole, academy team leader at risk consultancy DNV. "This is all about fundamentals, you're essentially looking to reduce the number of bad events that affect your business. Risk management is about taking care of adverse events so that positive aspects can flourish."

Bill Rann, global head of governance practice for BT Global Services, believes that risk assessment often gets unwarranted bad press. "It is often perceived as being about the loss of something, but I think that is the wrong way of looking at it," he says. "It's all about opportunity and cost. It's usually very textbook stuff, there's a lot of common sense in it. It's when common sense gets lost that you're in trouble - keep it simple."

The central theory of information risk management is to define the levels of risk your business has, and thus how much effort and detail you need to go into. A company that exists almost exclusively online, stores customer information and has a transactional element, such as eBay, for example, will need a far more detailed plan than a regional distributor of IT equipment.

"The fundamental business requirement for information risk management is to enable appropriately authorised and accountable people to make informed decisions and take effective steps to control business risks," says Robin Hollington, director of consulting at Global Secure Systems. "This can only be achieved by identifying what information assets are valuable to the organisation, conducting a risk analysis to determine what may threaten those assets and then making informed and authorised decisions regarding the level of risk that can be accepted, coupled with control measures to mitigate those risks to an acceptable level.

"For example, in an IT context, it's often the case that a company will be sold the 'next best thing' - maybe a spam filter - without really thinking about the risk aspect. Is spam really a threat to your business? How big a risk is it? This will give an indication of how much to spend on mitigating it."

The next step is to define your methodology. "Risk analysis is more than 15 years old, so there's a huge range of methodologies around," claims Andrew Wilson, a senior research consultant at the Information Security Forum (ISF). "Getting the right one is vital." The ISF's latest methodology, IRAM, consists of three key phases: business impact assessment; threat and vulnerability assessment; and control selection. Each phase addresses a key part of the information risk-analysis process. Individually they enable information risk to be analysed at different levels of detail, depending on the requirement.

Whatever methodology you choose, it's important that it is repeatable, easy to understand and simple to apply. "The methodology is critical, and some get it very wrong in my opinion," Robin says. "For example, there is a government methodology that uses monetary values to determine what represents the greatest risk. However, in the world of IT, it's a good idea to ask how the most expensive resource is accessed - if a £1 million-database is accessed solely through a £50,000-widget, then the widget is your greatest risk area."

Having defined your methodology, another key step is looking at metrics, not only from a measurement point of view, but also for the sake of reporting. "Of course, your IRM must be useable, the control measures must be realistic, and it's a great mistake to get too granular," says Cole. "If you're reacting to each new 'threat' on an individual level, for example, you're going to be too busy. Equally, taking a very high-level view of this will result in missing key risks. The best method is to define your metrics properly from the outset."

Common metrics for severity range from one to five, with one representing a small effect on the business and five the company going out of business. The idea is that the standardised bands allow the assessment of threats and vulnerabilities, as well as the straightforward presentation of issues to senior management.

A particularly effective approach to express and analyse risk is to create a risk matrix for each of the important business functions. This would have severity versus frequency on the axes, with events colour-coded from red to green, Cole explains. "It's very straightforward to present this to non-technical board members and others," he adds. "It's all very visual and transparent. It also speeds the process along - meetings move from asking what the issues are to what mitigation can be done much more rapidly. Plus, the comparison of cost versus risk is very easy to grasp."

Robin agrees: "The key here is keeping things simple, but not too generalised. Some matrixes rate events from one to three, but this doesn't give you any granularity at all. Others try to score out of 100, but this ends up being hard to compare - what's worse, a 78 or a 79?"

Risk events are judged according to frequency, severity, likelihood and impact, and there are limited responses to a defined risk: accept it, transfer it somewhere else, mitigate it or reduce it. Robin is emphatic on this point: "There are only four responses possible to a risk once it's defined, and if you don't understand that, get someone in who does. The biggest error I see on a regular basis is not defining exactly what is being assessed."

Another primary concern is to ensure that people are in place. Board-level consensus is critical before any kind of assessment can even be started. Best practice in IRM calls for risk managers to have an excellent overall grasp of the company structure and responsibilities within it. They also need to know every system and application. "You really have to go through and look at issues system by system, because this is where controls that will mitigate your risk can be applied," Wilson points out. "And remember, it's not just IT systems - are there any other information sources that should be included, such as written data? It's vital that everything is taken into account, otherwise your results will be contaminated and worthless."

There are several standards companies can refer to, such as ISO17799, and BS7799-3:2005 (see box). Although they can supply a convenient starting point for research and provide a solid platform to begin from, Cole doesn't recommend they are taken up wholesale. "The standards aren't perfect, although they are useful. The British Standard provides a good overview of the basic theory. A problem with the standards in this area is that they don't move as fast as the industry does," he cautions. "The current ones are unlikely to see an update before 2009."

Once an assessment has been conducted, it is essential that it is refreshed at agreed points in time, and that a formalised reporting structure is set up. "Risk monitoring needs to be fairly dynamic, and something like a dashboard display should be considered," suggests Wilson. "Also, a decision needs to be taken about the frequency and reach of reporting - weekly, monthly or whatever period reflects the level of risk the company is undertaking." The use of automated tools can make this ongoing monitoring much easier, and this section of the task can become the remit of the IT department in smaller businesses. "Although it's tempting to outsource IRM and ongoing management of the process, it's critical that businesses have a clear understanding of the report and the methods used to get the result - the company needs to really own both the data and the process," says Cole. "There's a big load of work at the outset, but if the process is properly calculated to begin with, it can easily be automated to soak up much of the data work. It's useful to use an automated tool to rate and track known threats easily. However, I wouldn't advise businesses to rush into buying tools - try at least three or four different ones before deciding."

Some of the technicalities behind calculating risk can get extremely mathematically complex, but the central plank of IRM is based on common sense and prosaic information management issues. Although some companies can lose their way and end up with either too simplistic or overly complex assessments, starting with first principles is the key to a successful approach.

SOME DEFINITIONS

The use and definition of the word "risk" can be ambiguous and is subject to a variety of interpretations. There are also words familiar from information security management used in conjunction with risk, such as threat, vulnerability and security requirement, which can lead to confusion.

Here's SC Magazine's guide to the definition of the major terminology of risk:

Risk is the probability of a threat succeeding in causing damage to your organisation. There are three basic elements of risk from an IT perspective: asset, threat and vulnerability.

Asset: An IT infrastructure component or an item of value to an organisation. IT assets may include workstations, operating systems, software, networking hardware, telecoms systems, IT infrastructure and intellectual property.

Threat: A circumstance that may cause loss or damage to an IT asset, such as the deployment of a virus or illegal network penetration. A threat can include malware, hacker activity, stolen, lost or degraded data and DDoS attacks.

Vulnerability: A weakness in the IT infrastructure or its components that may be exploited, compromising an IT asset. A vulnerability may be discovered in the system design, software development or the implementation of an operational procedure.

Matrix: A risk matrix is a method of expressing and analysing risk. It usually contains an expression of each information system relied upon by a business function; a breakdown of potential information security issues associated with that system; and an expression of the impact that each such issue might have on distinct elements of the business function.

Methodology: A particular procedure or procedures used to describe the overall IRM project.

Metrics: The way in which all aspects of the project will be measured. Choosing suitable metrics is key when defining a methodology.

TOOLS OF THE TRADE

The simplest types of risk assessment take little in the way of tools, but a working knowledge of current standards is an excellent place to start.

The ISO/IEC 17799:2005 Code of Practice for Information Security Management sets out, in practical terms, how the implementation of an IRM system can enable information risk to be managed to an acceptable level, provide the desired level of assurance and underpin legal and regulatory compliance. Additionally, the British Standards Organisation has also published a Standard guide to risk management in the form of BS7799-3:2005. Both are suggested reading before beginning the search for tools to automate the risk management process.

Organisations such as the Information Security Forum (ISF) have not only published their own methodologies, but have launched complimentary tools such as:

BIA Assistant - enables the information risk analyst to assess the possible business impact that could arise as a result of the compromise of information in a system.

T&VA Assistant - enables the information risk analyst to assess threats and vulnerabilities, determine the likelihood of information incidents and the key information risks in a system.

CS Assistant - allows the information risk analyst to identify, evaluate and select controls to mitigate information risk (controls are currently taken from the ISF's Security Healthcheck tool).

There are a host of vendor software packages and tools to help automate the process of IRM, including:

CRAMM - A toolkit based on the UK Government's preferred risk assessment methodology.

OCTAVE - short for operationally critical threat, asset, and vulnerability evaluation - is a risk-based strategic assessment and planning technique for security.