Wade Baker (Risk Intel) is on the Commercial security intelligence service providers panel and Andrew Valentine (IR) is on the detection using logs panel. Should be an interesting event.

We hope to see you there.

You can get it here: www.icsalabs.com/whitepaper/report

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).

The most risk-significant event this week was Oracle’s quarterly release of a Critical Patch Update, but none of the vulnerabilities are the target of known attacks. Data breaches dominate the rest of the week’s events with news of medical records off-shored for transcription being sold on India’s information black-market. A NASA scientist was arrested for trying to sell classified information. A former Ford employee was arrested for copying 4,000 proprietary files to an external drive prior to leaving Ford to work for BIAC, the fifth largest automaker in the People’s Republic of China. Point of sale devices were suborned at McDonalds locations in Australia. A security team in Europe reported 1,045 incidents of a compromised ATM “trapping” cards for later criminal use and a payment processor in Belgium reported a breach and at least 1,000 victims with financial losses.

Risk relevant events this week were dominated by security bulletins from Microsoft and Adobe. Infrastructure component vulnerabilities have also been announced, but without widespread reporting and discussion among security professionals. Availability failures disrupted service for T-Mobile Sidekick users, all of Sweden, OS X Snow Leopard users and customers of Google’s Postini mail service. While there was a surge in reports of several different Trojan horses, the malicious code risk environment has become more risky at roughly the same pace we’ve been experiencing over the last several months.

Realizing that our sample set is not randomized, is self-selected, and very small, we can’t draw too much from the results. However, they do roughly follow the pattern I expected to see. The methods described in the article are more widely used than those at the bottom of the list. Though I do see some form of qualitative risk assessment used quite often, I was a bit surprised to see it as the most-selected method. Makes me wish we could dig deeper to see exactly what folks are doing in that regard. The two reports of optimization are interesting. I’ve done some work on a math programming model for optimizing security investments but have found the data “crispness” and high degree of certainty required by that approach a hindrance to its application. The biggest surprise for me, though, was that 2 respondents reported using fuzzy logic for security decisions. I would really like a follow-up on that. I think fuzzy approaches hold promise for our field given the low availability of quality input data (but we’re working on that). Good methods of turning “a lot” and “ouch” into quantitative values would, I think, be well received in the community.

There were several things listed under the “Other” category: failure tree analysis, regulatory requirements (I’d actually put this under the “Adamant Auditor” since the interpretation and application of them is the driver for his adamancy), common sense (tough one – the “Guru” and most others think they’re using this), the VP’s airline magazine (another mark for “Pet Project”), OSSTMM, and my personal favorite, threats and intimidation.

Thanks to all who participated.

Microsoft made their pre-release announcement for October Black Tuesday and 13 bulletins, eight “critical” using their criteria. Patches for the SMB2 and IIS/FTP vulnerabilities are among those expected. Adobe’s advance notice for their quarterly security update to Adobe Acrobat and Reader includes a vulnerability they know is being used in limited, targeted attacks, other vulnerabilities will be patched too. The mass compromise of web mail passwords dominated this week’s news; we agree with ScanSafe’s assessment they were probably the result of malcode infections and not phishing. The scale of this infection/breach is more significant to enterprise security than the web e-mail accounts that were compromised. Reports the FBI director’s spouse refuses to allow on-line banking is a serious indictment of on-line trust and we will be tracking related reports of trust erosion, especially by high-profile individuals, groups and companies.

The URL for the Comments feed is now at at:
http://feeds.feedburner.com/CommentsForVerizonBusinessSecurityBlog

Note:  you can now also get blog posts in email via Feedburner.

Finally, if you do have any difficulties, please let us know in the comments.  Thanks!

http://feeds.feedburner.com/verizonbusiness/tWvQ

If you encounter any difficulties, please let us know in the comments to this post.

Thank You!

As a student of both the fields of Information Technology/Security and Management Science, I often find myself looking at security issues through a “decision-oriented” lens. For the most part, these two disciplines make good bedfellows – especially when one considers that engineers dominate the Information Security field. Please don’t misinterpret this; I have a healthy respect for, and advocate our need of, engineers (I’ve even helped teach and graduate some of them). However, not all of our problems are engineering problems and I do believe that our ability to truly manage information risk is hindered by a shortage of input from other disciplines (though I’ve seen at least some improvement in recent years).

One area where the engineering and management mindset clash is in decision-making. The engineer asks, “What do I need to know to precisely formulate all factors in this decision?” Meanwhile, the management scientist asks “What do I need to know to make a good decision?” In such matters, I side heavily with the management scientist.

The obvious application of this is in evaluating potential security initiatives or projects (“Should we do X, Y, or Z?”). In most cases, it is impossible to precisely formulate all factors in the decision, so we abandon the “scientific” route and revert to some other method of making it (see below). This is where our predominantly engineering mindset hurts us. Instead, we should realize that organizations have always made decisions using varying amounts of information of varying quality. Our dilemma is not new. Valid and vetted approaches exist for structured decision problems with an abundance of precise data and also for unstructured problems with sparse amounts of “fuzzy” data. These approaches are out there and are eagerly waiting for us to apply them to problems in our domain.

Ok, I’m off the soapbox. The main goal of this post is to ask how your company makes “Should we do X, Y, or Z?” decisions. I’ll start the conversation by listing the methods I see used most often. In doing so, I make no judgment on any method’s ability to support good decisions (though it’s clear some have more value than others).

• The “Adamant Auditor” method: You’ve been here. The 22 year old kid shows up 3 months out of the university with his checklist etched in stone. He darn well better be able to check off all those boxes or you’re toast. “But if X does Z and Y does Z, then X=Y… and we’ve done Y” you argue, only to receive blank stares. Good luck with that. Unless you can build a credible risk-based argument, you might as well just do X like he says.
• The “Peer Pressure” method: This is the grown-up equivalent to doing what the cool kids do. “Peers X and Y are doing Z, so we should too” is the justification here. It might be that X and Y have their act together and are great role models. Then again, they might think that alcohol, blindfolds, and a game of high-speed chicken make for a great Friday night. Remember what your Mama said – “If so and so jumped off a cliff, would you?”
• The “WIBeHI” method: If you’ve ever used anything that sounds remotely like “Wouldn’t It Be Horrible If X happened, therefore we should do Y” to justify a security initiative, then you’ve used this method. The potential worst-case scenario (and often some extra FUD for good measure) is the main decision criterion in this approach.
• The “Guru Guidance” method: Every organization has its guru and every guru has his opinion. Just ask him. It might be that nobody understands the technical justification behind what they’re recommending, but he knows his stuff, right? Right?
• The “Poll the Panel” method: Often called the “Delphi Method” but I’ve never thought the name very fitting. No journey to a mystical oracle with secret knowledge is required; you simply gather your smart folks and get them to come to a decision. The assumption is that decisions made by many are better than decisions made by one.
• The “Pet Project” method: Perhaps it was the advertisement in that magazine on the plane. Maybe that analyst report. Who knows why your boss wants that project so badly, but its clear she does. And in this job market, who’s going to argue? If you can get it done while also squeezing in something with actual benefit, there’s a chance you can still put a mark in the Win column.

My tone here is obviously facetious but I am quite serious that I believe these methods (or some form of them) account for the majority of security decisions made in most organizations. Is this your experience as well? We’ve put up a quick, one-question poll on the topic here and would love to hear from you (we’ll share the results later). If any of these methods resonate or if you have some to add, please chime in.

I admit that this is an incomplete thought, but I’d like to share it with you for two reasons:

1.)  At the end of a podcast I was part of recently, one of the other panelists challenged our industry to stop whining about our current state of affairs and do something better.

2.)  To request your feedback on the idea.

So here’s my thought: if we’re going to re-imagine InfoSec standards, as if we could do it all over again, I think there are three basic requirements any standard needs in order to be useful at all:

1.) A standard must provide for its own obsolescence/evolution (falsification and a transparent falsification process must be built in)

2.) A standard must provide means of measurement (both for the outcome of the standard, and to measure the quality of standard adherence)

3.) A standard must reference, and be able to be referenced in, vernacular and in measurement (the language of the standard has to make sense to other standards)

RE-IMAGINING INFOSEC STANDARDS: THEIR NATURE

Digging right in, if we want to re-imagine standards we might start by reviewing the fundamental nature of what a standard is. In a very real sense, our standards are models. As such, any standard is only a hypothesis about how to keep our information confidential and available while maintaining its integrity.  But if we’re going to (finally) acknowledge that InfoSec standards are models/hypotheses, then we need to embrace a fundamental premise behind scientific theory: a model or hypothesis is meant to be tested, falsified, and evolved. As such, our new view of InfoSec standards would require that we keep whoever developed the standard (or its current custodian), accountable for that scientific method.

Science Requires Falsification and Innovation

Now ideally, we’d have two things built into the concept of accountability. These two ideas would mean that the standard would provide for its own obsolescence or evolution, and are the premise behind my first usefulness requirement, “a standard must provide for it’s own obsolescence/evolution  (falsification and a transparent falsification process must be built-in).”

1.)  The InfoSec standard itself should have a falsification process built into them. The standard might describe the pursuit of falsification, what falsification/failures for the standard might look like, and provide us with the means to report a probable failure.

2.)  The standard custodian should provide transparency and reporting about that falsification process. Practitioners would have up to date knowledge about failures so that they can keep an eye out for them in their own environment, and hopefully be able to offer a modification to or alteration of the standard based on new information.  So whether this is just “patching” the standard or if it leads to a whole new hypothesis, we (the InfoSec community) would at least have visibility into a need to “re-secure”.

RE-IMAGINING INFOSEC STANDARDS:  THEIR PURPOSES

Related to our examination of fundamental nature, let’s think about what InfoSec standards are a model *of*. We said that they are models we build to help us with our quest for maintaining the C, I, and A of our business data.  In that regard, we might suggest that they are about Information Security “engineering” and management.  In other words, design and implement practices to ensure C, I, and A and then establish practices to maintain the desired level of C, I, and A.  But if you’re building a control framework or understanding how you should best operate it, both disciplines require the use of measurements. This then necessitates the development, use, and reporting of metrics (indeed, the concept of measurement would be very useful in the scientific method process above).

The Purpose of Standards Requires Measurement

So while we’re re-imagining InfoSec standards, let’s imagine this: standards that tell us not only how to measure the standard’s outcome (secure enough) in a state of nature assessment, but also how to measure the actions that cause “secure enough” – what we might call the quality of standard adherence.  This gives us my second standards usefulness requirement,  “a standard must provide means of measurement (both for the outcome of the standard, and to measure the quality of standard adherence)”.

This way (and only in this way) we might know that by having expended X amount of effort for compliance to the InfoSec Standard, it produced Y amount of outcome.  Then people who implement the standard can discuss how they got Y+n amount of outcome for X-z amount of effort thanks to some new control, or how they are consistently seeing Y amount of outcome from year to year regardless of whether they spent X-1 or X+1 amount of effort, and so on.  But we are at the point, as an industry, where measurement is not just desirable – these days it’s actually necessary.

RE-IMAGINING INFOSEC STANDARS: PLAYING NICELY TOGETHER

Finally, since we’re trying to describe a new way of looking at security standards, maybe we could discuss the creation of a means by which models might be able to contribute information to each other.

You see, my belief is that Information Security, as we’re able to describe it right now, is too complex for one over-arching textbook sized model.  Rather, I believe that we’ll be more effective if we break the big problem up into smaller, more digestible chunks.  So practitioners of the various operational security duties can actually focus on their area of expertise, and not try to be masters of multiple domains (specialization is good, they say).

Standards Must Communicate To Have Aggregate Value

However, if we took the time with a whiteboard to try to paint a picture of all the components of organizational security (talking about the various areas of security specialization in sort of an object oriented sense, if you will), I’m betting we’d see that each area of security needs to be able to share information with others in a meaningful manner.  So Software Development processes need to exchange information with Vulnerability Management, who needs to talk to Intrusion Detection/Prevention, who needs to talk to Incident Response, and so on.  Now if we can establish rationalized metrics for the models (above), then ideally we’d be using a common security taxonomy, or at least using translation documents provided by the standard that would allow us to use one disciplines metrics (prior or posterior) if relevant to another discipline.  This gives us my final standard requirement, “a standard must reference, and be able to be referenced in, vernacular and in measurement (the language of the standard has to make sense to other standards)”.

Carrying that idea forward, it would probably be a great thing to have multiple competing models in any specific field, and wouldn’t it be wonderful if the language and meaning that they used were the same or easily translated (other than measurement models, obviously)?  So we would have an idea of comparative (in)effectiveness between competing models!

MOVING TOWARD A RE-IMAGINING

Yeah, so I’ve described a dream world of candy cane trees, rainbows, and happy unicorns. Sure.  And I know it might take a generation or two of security professionals to get there. But that doesn’t mean we can’t start now, and start with our current standards bodies – especially within the context of the pursuit and transparency of falsification and the development of meaningful metrics. All it takes is the will to try and the willingness to fail. As my co-presenter David Mortman and I said at Black Hat this year, “Models don’t have to be perfect, just ego-less”.

A few months ago C|Net published an article claiming current economic conditions have resulted in greater enterprise use of free and open source technologies.  This sparked an internal discussion about whether the supposed tendency would have an impact on risk to the enterprise.   As such discussions are wont to do, it descended into the quagmire of “how secure is open source”, and eventually died a quiet death after the RISK team grew weary with the topic. I had already half-heartedly begun a blog article framing the debate, but quickly filed it away under ‘do not resuscitate’.

However, three subsequent events brought additional insight to the matter, namely:  an XKCD cartoon, the build-out of a lab test bed, and a team-member’s ailing water heater. These unrelated events convinced me to go ahead and blow the dust off the blog entry and get it posted.

Suppose your enterprise is one of those which are attempting to “do more with less” (as we all are), and further suppose that the task of building, testing, and deploying “something new” falls to the technology group that has expertise in doing “other things.”   It isn’t too much of a leap from here to see where the technology choice for “something new” might be guided by price.  After all, if the CFO’s daughter’s grade school can download a “something new” and make it work then surely the enterprise technology group can do at least as well.  Does this sound familiar?

Returning to our theoretical DIY (do it yourself) technology team, we find them diligently at work deploying and debugging the aforementioned “something new.” As is often the case, something goes awry when following the published documentation. As you are undoubtedly aware, when technologists find themselves in unfamiliar territory they tend to rely on the “wisdom of the collective” to solve problems.  This phenomenon is well expressed in the Tech Support Cheat Sheet published in a recent XKCD.   The prevailing thought goes along these lines, “surely someone else has had the same problem, and was diligent enough to document the experience for the good of the order.”   Therefore, after plugging the salient details into their favorite search engine, the erstwhile tech team awaits the wisdom of the oracle.

What follows are excerpts from  “free advice” to searches related to diverse “something new” deployments on a lab test bed over the past several weeks:

-                       chmod 777 fixes  this

-                       grant all on database.* to  …

-                       allow tcp any  any

-                       community  public

-                       allow tcp  23

-                       do not change the default  password

-                       allow from  any

-                       security  manager=”no”

-                       disable rules which generate  excessive log entries

-                       allow root login:  yes

-                       everyone  fullcontrol

-                       chown -R www-user  *

-                       allow-update { any;  };

In almost every case the first several rounds of online advice included advice to RTxM in various states of  dudgeon, and if reading the fine manual didn’t suffice there was always some  well meaning individual with an expedient (though potentially dangerous) solution: “I did X and it works!”

And what about the water heater? One of the Risk Team members’ water heater died a few weeks ago, and as he had never experienced a water heater replacement in any home, he asked for any advice his colleagues might have to offer.  After much discussion about what sorts of plumbing problems qualify as “DIY” , Bill Murray of the RISK team gave the following advice: “Do it  yourself. You will learn a lot that you will never use again.  You will also learn that even when the pros are not cheaper, they are still worth the difference.  You will use that over and over.”

So, in wrapping this together I would say that one of the significant risks posed to the enterprise by “economically driven DIY” could result from situations where “community advice” might make its way into production without appropriate review and control.  Clearly this is not the problem when the enterprise has “the pro” plumbers on staff or on call.