Why risk management fails in IT

It is frustrating to see the amount of budget allocated to compliance when you consider that most of the money goes to documenting security controls, not improving defenses. One of the biggest reasons is that risk management, a carry-over from the bigger world of business, does not work in IT security.

While few small businesses have formal risk management programs, most large business do. They even have risk committees that are drawn from the board of directors, often headed up by the CFO. The goal is to identify risks and either reduce their potential impact with compensating controls or purchase insurance to further reduce the business risk.

For example, a large airline, thanks to its risk management program, may recognize rising fuel prices could hurt its competitiveness and decide to hedge fuel on the open market, or a car manufacturer that has gone too far down the path of Just-In-Time supply may start to warehouse critical components in case a supplier in Thailand is wiped out by a flood.

But try to translate risk management theories to IT and you run into troubles. Every risk management program starts with the dictate to identify all IT assets and weight them based on their criticality to business operations. That leads to the first big problem.

1. It is expensive and almost impossible to identify all IT assets.

While at first glance identifying assets appears to be a simple problem, it is actually extremely complex; almost fractally complex. IT assets include every computer (desktop, laptop, server, print server), every application (database, email, ERP), every data set (customer lists, earth resources data, product pricing guide), all email, all documents in all versions, al identities and all communications.

Now, add in the proliferation of devices coming in with consumerization -- smartphones, iPads, even e-readers -- and the data that reside on them. Then add in the dynamic nature of the cloud, where servers can be in a constant state of flux as load is elastically met with more or fewer virtual machines. Like I said, it's complicated.

The next big problem?

2. It is impossible to assign value to IT assets.

The concept behind risk management is that you assign a value to each asset. There are many algorithms for doing so. It usually involves a cross-functional team meeting and making at least high-level determinations. But it is obviously impossible to assign a dollar value to each IT asset. Is it the cost of replacing the asset? That might work for a lumberyard, but an email server might have a replacement value of $2,000 while the potential damage to a company from losing access to email for an extended period could be millions of dollars in terms of lost productivity.

What about the value of each email? How much is one email worth? Ten cents? Zero? What about the internal email between the CFO and the CEO on the last day of the fiscal year warning that they missed their targets? Its dollar value is zero, but the risk from that email getting into the wrong hands could be the loss of billions in market capitalization.

Most organizations give up on the dollar value asset ranking and come up with low-medium-high valuations. Try to picture a team of IT asset managers in a room and one of them agreeing that his job is to manage servers that have little or no value. If there is no value to an IT asset, it has long since been replaced or eliminated. Every IT asset is of high value. So why bother classifying them all?

In the late '90s the automotive industry attempted to apply risk management techniques to product design. The method of choice was a huge spreadsheet template labeled Design Failure Mode Effects Analysis (DFMEA). The product engineers (me) would sit in a room for several days and look at every component -- every fastener, every stamping, every piece of cloth in a car seat -- and decide every possible way each component could fail in the federally mandated tests.

We would generate a huge list of possible failures -- stripped bolt, fatigue crack, buckling, worn nap -- and submit it to upper management who would never look at it. Of course we failed to predict the failures that actually happened in production. You remember the recliner failures on the Saturn car seats?

Another example: A giant financial services data center located on the Gulf Coast of Florida used risk management techniques. Among the usual list -- power failure, Internet outage, fire -- was a line item for a hurricane with a storm surge of greater than 20 feet (the level above sea level of the data center). Because there had not been a single such storm in 100 years this received a risk rating of 9 out of 10, with 10 being the least likely. An FDIC auditor pointed out that in that particular year there had been four such storm surges to hit the Gulf Coast. The data center risk profile had never been revisited to reflect a changing environment.

It is the changing nature of risk that is impacting risk regimes today. IT assets that were not of interest to a pimple-faced 13-year-old hacker in Canada in 1999 can be of extreme interest to a cybercriminal operation in Eastern Europe or a nation-state looking to leapfrog a Western competitor. It is impossible to know beforehand which IT assets will be of interest to an attacker.

4. Risk management devolves to "protect everything."

For risk management to work it has to be comprehensive. So comprehensive protections are deployed. Firewalls, IPS, and AV everywhere and vulnerability management VM systems deployed to check the exposure of every single device on the network. Vulnerability management has to be continuous because new vulnerabilities are announced every month for just about every application, OS and device.

A patch management system is then used to ensure that every application has the latest patch. Risk management methodologies strive for that golden state when no vulnerabilities exist anywhere. And, failing that, the desire is to minimize the total exposure time to new vulnerabilities. Organizations spend an inordinate amount of time and money on these protections. Of course, they still succumb to targeted attacks which use previously unknown vulnerabilities.

What to do? Use threat management techniques, not risk management.

Consider if the U.S. president's morning intelligence briefing was focused on risk management.

It would have to take into account the 40 or so U.S. facilities that are involved in the production of nuclear weapons, then there may be the 250 or so diplomatic missions around the world, and of course the U.S. military bases (you count them), and maybe a breakdown of the 17 designated critical infrastructure sectors, not forgetting national monuments.

Ridiculous, of course, because a true risk management report would summarize all of that information into a simple score. A vast army of risk auditors would be engaged to come up with a uniform scoring system and every "asset" would be given a score which would be weighted and rolled up into a dashboard that gave a single-pane-of-glass view into overall risk every day.

But if such a thing were even possible, what would it have shown the day before the USS Cole was attacked? Or on Sept. 10, 2001?

Of course an intelligence briefing is not about assets; it is about threat actors. Intelligence is gathered about their intentions, capabilities and movements. Decisions are made based on threats. Real and present dangers are identified and resources are deployed to gather further intelligence (detect), deny, disrupt, delay, degrade, deceive or destroy the threat actors.

That is the basis of threat management, an approach that is proving to be much more effective at reducing the losses from targeted attacks.

Stiennon is chief research analyst at IT-Harvest. He recently launched IT-Harvest Press to publish nonfiction books. The first in a series of books on the analyst business, "UP and to the RIGHT: Strategy and Tactics of Analyst Influence," was published in July to great acclaim. A new book, "Wide Open Privacy," will be published in November 2012.

Cyber resilience will be particularly important as Australian organisations face increased pressure to quickly detect, respond to, and manage the repercussions of breaches in the wake of 2018’s Notifiable Data Breaches (NDB) scheme.

Copyright 2018 IDG Communications. ABN 14 001 592 650. All rights reserved. Reproduction in whole or in part in any form or medium without express written permission of IDG Communications is prohibited.