No organisation can prevent every possible incursion, so risk management is becoming the de facto way to protect an organisation's data. Rob Buckley takes you through the strategy and tactics of an approach used even in ancient Rome.
Every organisation in the world faces some kind of risk – and one with an IT infrastructure faces even more risks. Whether it's someone deliberately trying to break in, systems accidentally exposed to viruses or employees leaving data on USB drives, an organisation of any size is going to face potential disruption and losses as a result of IT-related security incidents. One response is to try to prevent every single incursion, but with limited budgets and the ways that security can be breached increasing every day, no organisation has the time, staff and money to do that. And so, risk management is becoming the de facto way to protect an organisation's data.
In theory, risk management is a simple concept. Instead of trying to prevent every single threat, you work out which threats are the ones you have to be worried about. These might not necessarily be the ones most likely to occur: a virus outbreak might be very likely to occur in the next two years, but may only cost £100 to fix the damage it causes. That won't be as concerning as a threat only half as likely to occur, but which needs millions of pounds to fix.
Assessment: theory and practice
To implement a risk management strategy, you must first perform a risk assessment, to work out what the potential risks to the organisation are, how likely they are to occur, what effect they will have to the organisation if they do occur, how much it will cost to fix the damage caused and how much it will cost to reduce the risk of them happening to acceptable levels. With some simple maths, you can rank these risks to prioritise their mitigation through technology or processes – or a combination of the two. Then repeat this risk assessment at regular intervals, both on your existing infrastructure and also when new projects are started, to ensure that any new risks are accounted for.
That's the theory. The practice, however, is somewhat different. Identifying risks can be difficult, particularly across large, geographically distributed organisations with data potentially spread throughout the enterprise on multiple devices and systems that may or may not be under the control of the security team. Assets might be managed by many different managers, some of whom might not want to cooperate or who might want to overplay or underplay the risks. Actually putting numbers to risks is far harder than it would be in an industry such as life assurance, where actuarial tables are readily available and risks change only slowly. Continuing to keep the organisation aware of the importance of risk management and thinking about risk in daily life require effort – as does getting people interested in risk management in the first place. Then there's coordinating all that effort and putting everything on an equal footing in a way that management will support, while dodging internal politics.
Go for clarity
The first stage of any information security risk management strategy is to get a clear idea of what's going to be involved in the process. If there are likely to be big changes to the organisation, rather than a simple alteration of approach by the information security function, board-level support will be necessary to help push through the changes and to ensure continued adherence to the strategy. Without such backing, any strategy is highly unlikely to succeed.
However, with top-level support, an initial risk assessment can begin. Firstly, standard definitions of risk need to be determined. In many cases, it will often be hard to quantify risk – what is the exact percentage chance that either a hacker might breach the CRM system within the next two years or a member of the HR department lose their laptop? However, there are ways of calculating these risks. In some cases, commercially available risk management software includes data on standard risks; some organisations, such as the Information Security Forum (ISF) or the Information Risk Awareness project (http://inforiskawareness.co.uk/), can also provide advice. Simon Oxley, founder and MD of risk software developer Citicus, says organisations can often use their own data: “If you look at the history of incidents in your own organisation, there's real evidence that shows a strong correlation between minor incidents and the likelihood of major incidents.”
Nevertheless, it might be preferable to create metrics that rank risks in categories such as high, medium or low, corresponding to particular ranges of likelihood. This approach also works well with other metrics, such as impact on the business and cost of fixing any damage.
Get colleagues onside
Another reason for creating range-based metrics is that frequently it won't be the security team which will be ranking risks that pertain to a business process or human risk: the manager of the relevant department will be more likely to be able to judge the risks, as well as the impact on the business if an incident occurs. This will not only require liaison with the manager, it might bring in other people to perform the assessment. So explaining the reason for the adoption of strategy is even more important, in order to get managers and staff onside.
Often a good method to determine the risks is for ISPs to interview staff and managers and ask them to describe the steps involved in particular business processes and the IT assets used. However, not all assets are hardware or software – corporate information that must be protected and not lost is equally important, if not more so.
Don't miss important elements
“Many organisations know where their key assets are, but they miss important elements,” says Floris van den Dool, executive director for Accenture Technology Consulting's security business in Europe, Africa and Latin America. “Do they include PowerPoint presentations on laptops? CRM data on BlackBerries? The biggest risk is at the unstructured level – so you should get a business manager to describe the business processes involved in a sales cycle or preparing a proposal and what gets exposed. Then you go back to the business process and the user data to see what IT assets get used, then break down the threats.”
Although there need to be ‘triviality' rules to avoid risks such as including ‘the router being unplugged accidentally' in the risk assessment, these rules need to be set with caution, warns Deloitte partner, enterprise risk services, Mark Carter. “You may have a generic rule such as ‘Every laptop over £100 should be captured', but the risk is when a £50 laptop that's very important to business operations is left out.”
There may already be asset registries as a result of previous audits and compliance programmes, so these should be consulted. Business continuity programmes will also provide a clear idea of what assets are most vital to the organisation and in need of protection.
To locate other assets either missed by these programmes or that have since been introduced to the enterprise, existing security tools can be used, such as vulnerability scanners and patch management software, advises Gidi Cohen, founder and CEO of Skybox Security. Data loss prevention tools are available that can scan for particular types of information, typically by keyword.
However, processes themselves may also expose the organisation to risk, says Simon Marvell, MD of Acuity Risk Management. “How quickly are you patching flaws? What proportions of contractors have signed your policies? These kinds of data are important.”
Once the initial risk assessment is done, compiling the information gathered and creating a suitable priority list and strategy list is the next step. This should be a simple bit of maths, requiring nothing more than an Excel spreadsheet. However, internal politics often cause risks to be prioritised in a more subjective way – or to at least be re-evaluated.
Some managers would rather that their work not be considered a risk to the organisation, out of fear of being punished. “There can be lots of lobbying going on,” says Citicus's Oxley. “When you are reporting risk and there's red on your charts, that can be unpalatable. The problem comes from compliance, a lot of which is couched in terms of ‘We can't have failures'.
The reality is there will be red, organisations do have gaps and sometimes that has been papered over. They need to get over that attitude and admit when something isn't perfect and that we need to fix problems.” Others may actually want to be considered high-risk. Says van den Dool: “Typically, business owners don't disagree if there's a high risk put on them. It means they're important, so they talk up the risk and say that the impact of losing data is ‘humongous' – depending on who ends up paying to mitigate it, of course.”
However, while re-evaluating risks objectively rather than simply taking business managers at their word might seem simple, the risk management project needs the cooperation of managers to succeed, so it may be that a certain amount of give and take is necessary when formulating the final ranking to get their backing.
Actions – and costs
The next step is to determine what needs to be done to mitigate each risk and how much it will cost to be done, which should be no different from any other security project. The resulting report, however, will have to be accessible to others and written in a language the board and potentially the rest of the business can understand.
There are two reactions people should avoid when presenting their report to the board, according to Craig Carpenter, VP marketing at Recommind: “The first is that they pooh-pooh something that has a risk of, say, 0.01 per cent occurring and say nothing needs to be done. It may seem that way, but if the risk is in the billions, you need to pay attention. The second is that they add all the bad things up and decide that something is definitely going to happen and we're all going to die a horrible death tomorrow, so there's no point doing anything – or, alternatively, you have to do everything. These people can't parse nuance.”
This reaction might often be the case in organisations with no history of risk management, such as those that were working in lightly regulated areas, but are now moving into new areas that are more heavily regulated. Making sure risk is well understood in advance can mitigate this problem. The board can then decide which risks it is willing to take, which ones it isn't and what budget needs to be allocated to the project to mitigate the risks. As with any security project implementation, a mixture of technology and training will undoubtedly be needed, with staff educated about any changes to their information technology infrastructures that they need to know about and any processes that affect them.
A risk management strategy won't ensure that absolutely nothing happens to the enterprise. It just ensures that the events most likely to cause the most damage are mitigated. Then if something does happen, in all likelihood it either won't cause much damage or the damage it causes is easily fixable.
Risks do not stay constant, however. Further threats emerge all the time. Organisations take on new projects, expand, acquire other companies and change their business processes in response to regulation, the market, other organisations or improved technology. They may start using outsourced services or cloud providers that need to be incorporated into the risk strategy. So a risk management strategy cannot stay constant for too long. Depending on the risks and the kind of organisation, various aspects of the strategy and IT assets will have to be monitored and altered when appropriate. A financial services company, for instance, might have to monitor its risk strategy with almost every transaction, while others may need to adapt policies only every six months or once a year.
Update, but not too often
If possible, says Carter, incidents should be used to update policy. However, “few organisations are able to successfully link real incidents that they suffer back to the risk management process. It's a missed opportunity for a feedback loop.”
Skybox Security's Cohen warns against updating the policy too often, though. “Staff are a vital part of risk management. Every time you make a change, you have to retrain them and you don't want to have to do that too often.”
Keeping staff and management onside also involves reminding them of the importance of what's being done, says Carpenter. “It's tough, but the best way to do it is to pick up a paper on a daily basis and show each group that vigilance is important.” Having an ‘information risk champion', such as the CSO or someone in the security organisation, to keep risk ‘on the radar' is something that Marvell recommends as well.
Risk management as applied to information security is not a panacea, nor is it an absolute science, but it potentially provides a more objective, more transparent way of dealing with the risks an organisation faces. If implemented well, it can also save money.
Case study: Ian Beale at Inchcape
Ian Beale joined international automotive retailer Inchcape in May 2007 as its director of risk and audit. His aim was to move the company from an audit-based approach to security and compliance to one based on risk management principles.
“Risk management is nothing more than good business management,” says Beale, who has since left Inchcape to join consultants Corporate Executive Board. “A large part of what I was trying to do was work with operational line management to understand, manage, mitigate and respond to risks.” Previously, the company's nine-strong audit team had focused more on compliance than risk, but under Beale's management and with the strong support and backing of Inchcape's CFO and CEO, the company and its operating companies “moved from a checklist approach, based on self-assessment or someone coming on site internally to see how well a unit was managing risk. We switched to working with them to take on board a much more active, risk management approach, in which risk was viewed as part of normal business and a natural part of any new project.”
The approach Beale took worked both at the operating company level and across the whole company. Beale and his team worked with MDs and FDs, as well as the various departments to understand how they were assessing the risk they faced, what they were doing about it and how well various departments were interacting with regards to risk. With the IT directors, he worked to identify the key risks to the organisation, determine what controls he expected to see and assessed how well the businesses were meeting each of those areas.
As well as auditing the systems, Beale, his team and the IT directors looked at several key areas. “System access in any company is going to be a critical risk, but data privacy – particularly personal data – is also key. It is important that it is kept secure in a legally compliant way.”
Because of the existing compliance regime, the company already had a good grasp of what assets it owned. However, the move to a risk management approach across the organisation required three metrics to be created. “I put some framework around risk to help management teams when discussing and debating risks,” explains Beale. “If you're trying to judge risk, frequency and impact are important.” For frequency, managers could look at questions such as whether something had occurred that year or whether it was likely to occur in the next two years. For impact, he provided guidance on the different kinds of possible impact, such as how it would affect a subsidiary's ability to hit annual targets or the resources required to fix an incident if it occurred. He would break these down into ranges to make it easier for managers to gauge the severity and to compare them across businesses.
Ensuring that risk management reporting worked consistently across all the operating companies and divisions was also something Beale worked hard to achieve. “If one team reviewed an area and gauged it on a scale from one to five and another did the same, you had to ask each team, ‘Is one good on your scale? What does five mean?' If two threats are reported red, green and orange, what does orange actually mean in both cases? If you're reporting to the same management, you need to be consistent about which is good and which is bad, to get a sensible view of risk across the business.”
With risks ranked and prioritised, the operating companies could then mitigate them. Beale's team of auditors not only made sure they understood how the risks were being identified, but that the right risks were identified. They also monitored the operating companies to ensure that what they said was happening was actually happening and that the controls being put in place were adequate.
To ensure that risk assessment and management remained as priorities, Beale got managers to include updating of risk portfolios in the bi-annual planning cycle. “That way they weren't considering just the economic external environment, their goals and how they were going to achieve them, but also the risks the company would be open to while trying to achieve those goals.” Having support, right down to his CFO “visibly reading material” about risk, also helped considerably.
Initially, the companies used simple Word documents to analyse and compare risk. However, that didn't allow the companies to do ‘What if…?' analysis of the data and the risks. So Beale invested in risk management software from Flexeye that would allow them to analyse risk and map it over time. “We needed something that would be as easy to use for the key personnel in subsidiaries as filling in Word documents: if it was more complicated in the early stages, we felt they wouldn't do it.” Once adopted, the software also allowed the managers in subsidiaries to look across at their peers and if there was a common risk see what others were doing to mitigate it.
After adopting a risk management strategy, Inchcape still faced incidents, but, says Beale, the strategy meant “people could see why we had the strategies and processes in place that we did”.
Viewpoints: Critical knowledge
While risk management might at first seem like just another approach to IT security management, it is increasingly being seen as a vital skill on an ISP's CV. Chris Petch of the Information Security Forum (ISF) says that “if you search for risk management in a job database, it pops up more than it used to”, but Brian Barnier, principal at ValueBridge Advisors and a member of the Risk IT development team at the Information Systems Audit and Control Association (ISACA), says that knowledge of risk management is now “critical for anyone who seeks to advance in a role in management. ISACA, CoBIT, the Office of Government Commerce, British Standards and ISO all embrace the principles of risk management and how to reduce the likelihood of incidents. It would be difficult to get promoted without a risk management background now.”
The reason for the increase in interest in risk management is an appreciation that no business can be truly secure. “If I want zero risk, I have to shut down life and stay in the house,” says Barnier. “If I shut down business by locking the door, can I actually operate?” Only by embracing risks – such as allowing partners to access specific IT resources – can businesses achieve higher returns. Equally, says Barnier, “if you want to be the one giving direction, you need to be able to determine people's priorities – you need to be able to do more than just firewall rules and encryption.”
The compliance approach, says Petch, is more a box-checking exercise. “You may have ticked all the boxes, but have you missed something? And typically it's horrendously expensive. Risk management reduces the magnitude, frequency and impact of incidents.”
Barnier also argues that risk management is increasingly being seen in the US and other countries as improving the performance of organisations.
There are few specific qualifications in risk management as it relates to information security, but both ISF and ISACA offer training in it. Indeed, since 2002, 22 per cent of ISACA's Certified Information Security Manager (CISM) qualification has involved risk management training and the organisation's risk management events have seen considerable interest.
For example, some 2,000 ISACA members from all over the world attended a recent web event it organised. “It exceeded our capacity. We had the same experience three weeks ago, with a bumper attendance – we're getting big demand from a variety of organisations.”
ISF's training courses are seeing similar interest. “Our members run workshops to train those who attend,” says Petch. “In the past two years, 1,000 people have taken part.” A variety of skills are taught at these workshops. “They look at risk analysis, monitoring, how to set up a risk analysis capability and implementation, alongside the basic science.” Included in that science is the ability to put figures to incident risks. “In the past, it used to be more of a dark art than a science. There'd be values in the boxes, but you didn't know why they came out the way they did.” Equally important are people skills. “A lot of it is about facilitation and getting the right people in the room together.”
In both ISACA's and ISF's risk management training, skills development is important. “With insurance actuaries, the data stays the same,” says Petch. “In IT security, nothing stays the same.” And ISACA's CISM qualification, which attracts some of the highest pay premiums of any certification, has a continuing professional development (CPD) component. “You need to do your own reading and work to get CPD training credits” to keep your certification, says Barnier.
Nevertheless, despite the recent interest in risk management, it's an old science that goes back a long way, Barnier believes. “Roman shipping operators used it. It has always been important.”