Last week on Twitter, Jeremiah Grossman, Whitehat Security, asked if there was a simple way to perform asset valuation. Since then there have been posts from Russell Cameron Thomas, Andrew Jaquith, and Gunnar Peterson on the subject that have all been very interesting. The answers provided ranged from the simple to the complex.

Before we talk about asset value and Infosec, let’s first discuss some accounting concepts (I always like to get the unpleasantness out of the way as soon as possible).

To begin with, our IT assets usually are utilized in what we might think of as an object-oriented manner. That is, we can model them (from a risk standpoint) as parts of a greater process that generates revenue. Some can be seen as more directly contributing to revenue than others possibly, but they all operate as a whole. Think of an e-commerce order for example, and how many IT assets might be involved in taking that order. Now if we could value that whole process as an asset itself we might be able to break down contributions into sub categories and discuss value that way, but unfortunately, processes aren’t usually classified as *assets* in common accounting statements.

Secondly, there are two categories of assets that our friends in accounting worry about. There are tangible assets and intangible assets. If you’ve ever been involved in a BIA/BCP project, you’re probably very aware of the difference between the two and how significant those differences are. It’s easy to replace tangible hardware assets. The intangible information assets on that hardware? Maybe, maybe not (why we worry about RPOs).

But wait, there’s more! You see, intangible assets break down into “identifiable” and “unidentifiable” (imaginative, I know, but nobody said that the FASB was full of creative types). I think of the distinction between the two as this – identifiable assets can be sold. Unidentifiable assets are things that you can convince the accounting department are useful to the company, but they don’t have a bucket to put them in. We might be familiar with the great boogeyman of quantitative risk analysis and unidentifiable asset, “reputation” (I hope it is of some comfort that they don’t know what to do with reputation damage either).

One last thing on types of assets – how a company is perceived in the marketplace is directly related to those assets. And when we talk about asset valuation, it’s worth noting up front whether we’re talking about book value (made up of primarily tangible, identifiable assets) or market value (all assets, including reputation and market position and other unidentifiable yet important aspects of a company). These distinctions are going to be important when you talk to people in the other LOBs about risk and security because many times they’ll understand the distinction, but we end up waving hands and doing FUD dances about the perceived differences between qualitative and quantitative measures and precision-engineered probabilities.

Finally it’s worth noting that there are different approaches to the purpose of asset valuation. Some people limit computing asset valuation to tangible asset valuation. It’s the value on the books. Others (and we see this commonly in certain risk analysis methodologies) try to tie asset value to the risk equation where impact = loss of asset value plus all sorts of other related tangible and intangible asset values.

ASSET VALUE AND IMPACT

Me? I think that trying to describe asset valuation in the latter sense is somewhat of a red herring. What I have found pragmatic and informative, however, is discussing the probable cash losses (what I would call “impact” in the risk equation) we can expect should an incident arise due to the loss of confidentiality, integrity, and / or availability of an IT asset. Let me see if I can explain why.

ON USING IMPACT

Verizon’s Risk Intelligence group breaks down impact into two categories a’la ISO 27005’s “informative” appendices. When we discuss impact, we use the concept of “direct” impacts (those losses that stem from the actions of the threat agent that created the incident) and “indirect” impacts (losses created by a secondary stakeholder like a regulator, customer, partner, the media, etc).

Now it’s worth noting that one of the possible direct impacts we look for is the cost to replace tangible or identifiable intangible assets, be that money lost due to fraud, the cost to rebuild a customer database, or replacing the hardware/software itself if it is rendered unusable by a threat action. Like I mentioned above, I think there’s value in this. But using impact rather than asset value where asset value is a kitchen sink approach has several certain benefits. With a good ontology of impact sources, we can:

1.) Shift focus from arguing about (sometimes abstract) numbers on the balance sheet to the real pain the LOB is going to feel should probability of Bad Thing ever become “1″. We move the conversation to where the rubber hits the road. We’re no longer wallowing in the mire of accounting philosophies, but very pragmatic about the pain we’re going to feel (and what we might do about it, see below). I’ve found that doughnuts, powerpoint, fluorescent lighting, and the pain of thinking about cash flow out tends to help others in the organization identify the gap between our claims of exposure and their current “tolerance” for risk.

2.) Become consultative (or at least get people thinking) about controls for indirect impacts, even for intangible, unidentifiable assets. Legal costs, reputation damage, intellectual property exposures – by using impact we might even be able to discuss metrics that we might use as shadow indicators of unidentifiable assets. Even better? We can start identifying strategies that would limit the probable amount of indirect impacts.

For example, if we decide that customer churn rates are a symptom of reputation damage, we can talk directly about how sales strategies might be necessary to prevent churn, or talk to sales and marketing about the cost to re-acquire customers if an incident happens (like I mentioned above, nothing like talking about cash and budgets to “calibrate” ones tolerance for risk).

3.) Have an easier time translating that discussion of exposure back to our job – security. The use of impact can help us move away from thinking about assets in isolation, and towards a process-centric approach (above). This ability to think about things in a holistic (sorry) manner better bridges the rationalization for security spending with protection strategies. And we can altogether avoid the curious tendency to classify and value assets as “revenue generating” (and thus, important to keep from threats) and “non-revenue generating” (and thus, relegated to cannon-fodder-for-threats).

So my answer to Jeremiah is to not worry about asset valuation, tangibles and intangibles, and other abstractions of the balance sheet, but rather focus on what the organization will probably lose if that asset has a problem. And while using impact will result in an “estimated guess” (that is hopefully a range of values driven by subject matter expert inputs) it is simpler, and usually easier to derive and more informative to business decisions than the philosophical arguments about quantitative vs. qualitative measures, reputation damage, and the value of an asset (as they say, cash flow is king).

This entry was posted on Thursday, October 29th, 2009 at 3:31 pm and is filed under Analysis. You can follow any responses to this entry through the RSS 2.0 feed. You can leave a response, or trackback from your own site.