Engineers are focused on quality, so when they hear about vulnerabilities in software, their immediate reaction is to want to fix them… all of them. Regardless of whose software it is. Regardless of where it’s deployed. In fact, some of them care so much that they go out seeking vulnerabilities simply to fix them. They are the type of people who are great at solving problems, but not at understanding the downstream implications of their actions.

Economists, on the other hand (get it?), look at cause and effect, actions and reactions, and, most importantly, outcomes. The root of the economic problem lay in the ultimate unwanted outcome – the breach.Economics-oriented security pros understand that everything we do is intended to thwart the breach. It is easy to lose track of unwanted outcomes in the face of compliance needs and operational activities, but even those activities are all intended to minimize damages from attacks and exploits.

The engineer correctly believes that fixing vulnerabilities creates high quality (“stronger”) software. If the program starts with 300 vulnerabilities and you fix one, that obviously leaves 299 – one less than when it started. More importantly, if an enterprise has 1,000 systems that all have that same vulnerability and they apply a patch to 500 of them, they have decreased their attack surface by 500 vulnerabilities. From both perspectives, the level of vulnerability is, in fact, reduced.

But the economist knows that fewer vulnerabilities is not the ultimate objective. The ultimate objective is to reduce the likelihood of an incident.

The economist understands that there is a key missing ingredient to the engineer’s scenario – the intelligent adversary, aka the threat. And in pursuit of higher quality software the vulnerability details usually get published, leading to lower attack costs for the adversary. Given the scalability of technology, this typically leads to more attackers connecting to more targets, albeit in a (somewhat) smaller population of targets.

That is the key observation for this discussion – a breach requires both an attacker (threat) and a target (vuln), which manifests itself in the form of a connection between source and destination. Even though the population of targets may be reduced (perhaps even significantly so), if the threat is sufficiently motivated, more connections can be made with the vulnerable targets. The only way to guarantee reduced risk is to bring one of the populations (most likely the vulnerable targets) to zero. History shows us this is not likely with commercial software in enterprises. Interestingly, the increasingly common scenario for cloud-based software (e.g. Software-as-a-Service) may be able to do just that.

And there you have it – given the need for both threats and vulnerabilities, the reduction in one doesn’t force a reduction overall. And if the other element is increased in the process, the marginal difference in each population must be evaluated to truly understand the impact. Historically, this has led to scenarios where the vulnerability is reduced while the risk is simultaneously increased.

For reference:

More Sex is Safer Sex…

1. Application Control / Whitelisting Solutions. Whitelisting solutions change the security approach from one that allows software to install/run unless otherwise specified on a “blacklist” (“default allow”) to one that requires explicit permissions on a “whitelist” for software to be executed (“default deny”).

Clearly, the goal of whitelisting is to reduce the number of malware infections by preventing unidentified software from running thus saving the aforementioned recovery costs. Given the common predisposition for organizations to consider infections separately from incidents, whitelisting solutions also are intended to reduce the likelihood of a bigger incident.

The tradeoff for whitelisting solutions is determining whether costs associated with false positives – legitimate software that is kept from running – will offset these additional benefits. Generally speaking, the more dynamic and decentralized an organization is, the larger the problem. Nowadays, whitelisting solutions have varying ways to deal with this known issue.

2. Sandboxes and Virtual Machines. Perhaps the most varied set of solutions addressing malware these days are the sandboxes and virtual machines. Some sanboxes – primarily on the network – are designed simply to provide an out-of-band (and sometimes near-real-time) environment to execute suspicious software and determine whether it is malware. As with whitelisting, the goal is to identify more malware more quickly, thereby reducing costs.

Other solutions – focused on the endpoint – actually isolate the production operating environment to reduce recovery costs by reducing the downtime associated with re-imaging a solution, and/or reduce the impact by containing malware in an environment separate from other production resources.

There are some tradeoffs in the sandbox/virtual arena depending on the architecture. Network solutions may not see as much traffic in highly mobile environments. Endpoint solutions have performance considerations and/or architectural dependencies to consider.

3. Active Forensics. Recently, a number of solutions have arisen to offer a near-real-time approach to forensics. By recording system calls and/or scanning system state looking for anomalies, their goal is to identify malware infections within shorter time periods than existing methods can.

Active forensics solutions look to reduce the costs of recovery by providing detailed information on changes that were made by malware so a responder can recover more quickly. In addition, the solutions provide comprehensive information so that recovery may be possible without re-imaging. In environments where users can install their own software, this could significantly reduce end-user productivity losses associated with recovery techniques. In addition, active forensics attempt to reduce the time-to-discovery such that further exploit and escalation chances are reduced.

The tradeoff with active forensics is determining whether the detailed information is enough to ensure completeness of recovery so that recovery without re-imaging is a possibility. On the risk side, enterprises must determine whether the new insight provided will lead to a fast enough response time to offset the cost of the solution.

Each of these product categories (as well as others) have a value proposition that may provide benefits to organizations looking to augment their antimalware protection programs. The key is for companies to understand exactly what benefits they provide and decide for themselves which particular type of solution, if any, is likely to have the largest benefit.

Pete Lindstrom is Principal and VP of Research for Spire Security, LLC, a research and advisory firm. Learn more about Advanced Malware Protection by “Drinking from the Firehose” in New York City on 9/17/13. Details at www.regonline.com/AMPFirehoseNYC. Complimentary access for those who qualify. Contact petelind@spiresecurity.com for details.

The first stage of this process is to understand the costs and benefits of your existing program. This is a 4-step process:

1. Determine the probability and (economic) impact of being compromised by malware. This is the overall risk an organization is trying to address with anti-malware solutions.
2. Collect the total cost of ownership of *all* of your anti-malware solutions.
3. Estimate the amount of risk reduced by the current anti-malware solutions in the IT environment.
4. Compare the amount of risk reduced in step 3 to the total cost of ownership in step 2. A simple comparison should show higher benefits than costs (if not, you are doing it wrong). More advanced comparisons (division!) can provide your “risk reduced per unit cost” for your current anti-malware program.

These four steps are notionally simple but TechRisk professionals will recognize that any non-trivial environment will have challenges developing some of the estimates. It may be worth perusing my website or contacting me directly to discuss some useful ways to do this.

Once the assessment of the current situation is complete, it is time to review both the TCO information and the remaining (or “residual”) risk to determine if it is worthwhile to modify the program in any way. Given that there are existing costs to work with, a new solution may provide opportunities to reduce the existing TCO along with the ultimate objective to reduce the residual risk.
To evaluate the value of new solutions, it is beneficial to delve a little deeper into costs and the amount of risk reduced. This is especially true since many solutions shift costs from operating expenses to a capital investment.

Taking a page out of the “activity-based costing” book can help an organization evaluate its cost structure more effectively. To do this, an organization should allocate its costs to a set of identified anti-malware activities. A new solution may help lower these costs by, for example, reducing the number of infections that must be cleaned over time.

On the risk side, new solutions may reduce the likelihood of an infection or incident by identifying more malware prior to infection. They also may provide a means to reduce the impact of an infection by lowering the response and recovery costs or addressing some other aspect of loss.

Understanding risk and costs is a crucial aspect of managing a security program. In addition to recognizing the value provided by an existing anti-malware program, performing this analysis may highlight areas of inefficiency or weakness.

Pete Lindstrom is Principal and VP of Research for Spire Security, LLC, a research and advisory firm. Learn more about Advanced Malware Protection by “Drinking from the Firehose” in New York City on 9/17/13. Details at www.regonline.com/AMPFirehoseNYC. Complimentary access for those who qualify. Contact petelind@spiresecurity.com for details.

1. Need. I choose the word “need” with caution, since, as you will find out below, it does not necessarily mean there is “demand” for a better solution. However, I don’t think techrisk professionals can deny that the malware dropping attack vector is alive and well. It is highlighted as the key to the Aurora attacks that catalyzed the “advanced persistent threat” concern.
2. Varied Solutions. There are a number of vendors that have cropped up through the years with solutions to address the malware problem, and the techniques vary significantly. Whitelisters only allow identified executables to run; sandboxes isolate malware and/or identify actions; and real-time forensics track system calls and/or configured state.
3. Mature Market. Even with an identifiable need and newer interesting solutions, the most powerful security market in the world – antivirus (nee antimalware) – operates in pseudo-commodity mode and dominates in endpoint security.

As an industry analyst, I have had the opportunity to interview over a dozen solution providers and even more enterprise security architects and executives on the state of antimalware in the enterprise. Here are a few of my conclusions:

• Companies are moderately satisfied (and perhaps complacent) with their existing antimalware solutions. They acknowledge that these solutions are not blocking all malware but believe that every solution in the category has similar problems and so are reluctant to switch.
• The only factor that could affect existing signature-base antimalware is price – a lower-cost solution (which many agree is unlikely) could have a strong-enough value proposition. Notably, a few organizations are evaluating Microsoft’s free antimalware solution as one of these alternative options.
• Organizations are looking to gain more benefit from their existing antimalware solutions. Many are still focused on signature-based functionality and are now looking at more advanced capabilities. In addition, organizations are considering and employing new capabilities like Microsoft’s EMET functionality.
• For those times when malware gets through and infects a system, re-imaging is the standard approach, though some organizations are mildly reluctant to do it. Most of these malware infections are not classified as “incidents” per se – there is an ad hoc evaluation process to decide whether any infection should be escalated into being classified as an incident.
• Organizations are looking at architectural changes and not product changes when it comes to endpoint client-side security. This means they are focusing on BYOD and/or VDI (or even dumb terminals) as options in their client security strategies.
• Control over (physical) clients continues to relax, with certain “pockets” of exceptions (kiosks or manufacturing systems). For some, this was after a long period of control strengthening (e.g. finally taking away local administrative rights).

As I mentioned at the start, the market dynamics fascinate me here. I don’t think there is a techrisk professional left that believes signature-based antimalware is “good enough” and yet we see its dampening impact everywhere. At this stage, it has simply become the “checkbox compliant” easiest approach.

As someone extremely interested in cybersecurity economics I am encouraged by the attention being given to the bottom line – organizations should be very careful about cost-benefit in their security programs. While some of the organizations I interviewed had done a comprehensive analysis, it appeared to me that a number of organizations had not undergone a thorough review of their strategies.

I will be addressing these issues at my “Drinking from the AMP Firehose” workshop in New York City in a couple of weeks. The workshop concept was driven by these ideas and aims to break through the logjam brought on by complacency and confusion. Regardless of the conclusions that individual organizations come to, I think the entire field will be better off for it.

Pete Lindstrom is Principal and VP of Research for Spire Security, LLC, a research and advisory firm. Learn more about Advanced Malware Protection by “Drinking from the Firehose” in New York City on 9/17/13. Details at www.regonline.com/AMPFirehoseNYC.

On the protection side of the equation, although antimalware solutions provide a basic (and compliant) level of protection, security professionals are well aware of the limitations of signature-based approaches. Solutions that have been around for a while, such as host intrusion prevention and whitelisting, have gained renewed interest. Other approaches like network or endpoint sandboxes for isolation and/or analysis or active forensics for near-real-time analytics are coming on strong.

The challenge is determining whether the additional cost is worth it, deciding whether a new solution will significantly reduce the problem, and identifying which type of solution(s) are best.

While it is easy for security professionals to claim they will spend “whatever it takes” to address technology-related risk, that assertion is easily deflated through extreme examples (millions? billions? trillions?). While the intentions are valiant (and I get the point), no organization has an unlimited supply of money to spend on security. Therefore, it is crucial to make good decisions about how and where to spend money.

Any business decision is accompanied by some sort of justification, and cybersecurity is no different. In security, we typically evaluate total cost of ownership of the solution and compare it to our notion of how much risk is reduced. At the very least, every purchasing decision is supported by a claim that the spending “is worth it.” At best, a more formal cost-benefit approach should be employed.

Evaluating the cost-benefit of an “advanced malware protection” solution can be extremely challenging. Dropping malware (in the form of viruses and worms) onto systems is one of the oldest methods of attacking and compromising computing environments. Because of this, all enterprises already have controls in place that attempt to protect against malware infection. In addition, there are a number of techniques that can be used to address the problem.

Regardless of the challenge, conducting an economic analysis of newer AMP solutions may lead to some surprising conclusions. Here are six key considerations for conducting your analysis.

1. Ignore the “Advanced” Part of Advanced Malware Protection

The first distinction you should make in reviewing your needs for “advanced” malware protection is that the “advanced” part is extremely nebulous – the bar keeps changing in defining exactly which techniques are advanced and which aren’t advanced. Accordingly, the first takeaway is “evaluate your AMP solutions in concert with all antimalware efforts in your organization.”

This should not be a radical thought.

2. Cover All the Antimalware Bases

Diving a bit deeper into costs, enterprises should consider the costs of all capabilities – the capital investments made on hardware and software, maintenance costs, and personnel costs. The vendor solution (capital investment) side of antimalware protection can include endpoint antimalware, email or gateway-based antimalware, intrusion detection (potentially), and secure web gateways. On the operational expense side, organizations should consider the personnel costs associated with identification, prevention, mitigation, response, and recovery activities associated with malware infections and incidents.

3. Allocate Partial Costs of Broader Solutions

Focusing on the costs associated with one type of threat – in this case, malware – can be challenging. Some solutions, like endpoint antimalware, focus directly on the problem while others provide varying levels of accompanying support. In my research, for example, secure web gateways were cited as a means for detecting malware infections that were undetected by endpoint antimalware solutions, but secure web gateways provide more capability than malware infection detection.

The key in the analysis is to allocate costs based on the proportional value provided by the broader solution. If 10% of the ongoing value of the solution comes from antimalware detection, then 10% of the future costs should be allocated to antimalware.

4. Ignore Sunk Costs

The maturity level of antimalware makes it likely that capital investments to address the problem have already occurred. Any spending that occurred in the past should be excluded from the analysis, though any current and future operational expenses should be included. In contrast, a decision involving a future capital investment should include that amount allocated (either amortized or depreciated) over its lifetime as well as the operational costs.

5. Factor in Employee Productivity

The second economic issue to consider is the productivity of employees. The productivity costs associated with the impacted worker should be considered along with the costs associated with the IT triage person. If it takes four hours to recover an infected system, then four hours of the worker’s lost productivity should be included (nothing fancy here – use a single average number based on salary for all workers).

6. Use a Breakeven Approach

Perhaps a bigger challenge in justifying antimalware spending is in determining the amount of potential losses. That “it is worth it” decision means that the security professional spending $100,000 on a security solution believes the solution will offset at least $100,000 in risk.

While some cringe a bit at the realization that spending reveals the minimum expectation of risk reduction, it also provides an opportunity to conduct a standard financial breakeven analysis. Rather than attempting to figure out the exact amount of financial loss at stake, you need only consider the total amount being spent and determine whether it is less than the potential losses. So as long as you’ve properly accounted for all costs, an appropriate decision can be made.

The AMP solution decision is not an easy one – with a handful of controls at different maturity levels in the organization already and a variety of newer solutions vying for attention. Some organizations may even come to the conclusion they don’t need to augment their existing capabilities. Others will find out they really do. Regardless, enterprises should be conducting the necessary analysis to make the best decision for its needs.

Pete Lindstrom is Principal and VP of Research for Spire Security, LLC, a research and advisory firm. Learn more about Advanced Malware Protection by “Drinking from the Firehose” in New York City on 9/17/13. Details at www.regonline.com/AMPFirehoseNYC.

Key Benefits: 

• Create and use an economic/risk model to justify your need for Advanced Malware Protection (AMP).
• Cut through the confusion of biased vendor presentations to identify the l functional benefits of AMP solutions.
• Evaluate vendors based on an objective model (i.e., your needs) customized to match your requirements.
• Benefit from collaboration and feedback of your peers who face the same challenges at their organizations.

With an economic model in hand, participants will hear from up to 10 vendors (maximum  10 minutes each) as they provide details on how their AMP solutions address current needs and conforms with the requirements in the scorecards. After vendors are excused, participants will discuss and debate capabilities and ultimately assign their own scores. The process is akin to speed-dating, but with group feedback (and no alcohol).

Each participant takes away the proceedings, along with their economic model (a quantitative risk assessment) and vendor scorecard,  that includes their unique values and scores, as well as the group summary scores.

Before I get into this, I should re-acknowledge that I believe there are better methods to measure/evaluate risk, and I fully subscribe to their development. However, I am looking for evolution not revolution – Geoffrey Moore pointed out the challenges of disruptive innovation in “Crossing the Chasm” many years ago and I agree wholeheartedly. Evolution to me means slightly modifying existing approaches in beneficial ways. That is why a few of us are developing the Tech Risk Mgt Maturity Model.

So my goal is, essentially, to be “better than existing practices in techrisk mgt” – I am looking for marginal utility.

I also believe that resources are scarce and that every time infosec/techrisk folks make decisions about allocating them they are revealing preferences that are measurable in very coarse ways. Even though the existing models are seen as “qualitative” we can create control horizons and conduct breakeven analysis in ways to tease out some thresholds at the very least.

Now, to answer the questions:

• Pr(t): Yes, “the probability that a (sufficiently capable) threat actor will attack the system of interest” characterizes my belief well. And since I go out of my way to remind liability-minded folks that the intelligent adversary makes our situation much different from the “acts of god” kinds of hazard, I should acknowledge the non-randomness of the threat… but I am not ready to do that, exactly… for the same reasons as the “random walk down Wall Street” problem – easy to assert non-randomness yet hard to show otherwise.

Here is my thought process:
a) If it isn’t random, it should be predictable; and
b) if it isn’t predictable, then it approximates randomness (especially in the aggregate).
c) Since we can’t predict threat (afaik) then we should be evaluating any model compared to random, so
d) random is a good place to start.

There are many ways to approach how to determine Pr(t) – could be degrees of belief, could be public data (real-time blacklists, etc.), could be based on historical data, could be something else. My favorite application is a simple comparison of two scenarios. I don’t even quantify – just look at the accessibility of the two “systems of interest” and determine which one is higher (compare, say, a bluesnarf attack that requires local proximity to a sql injection that can happen from anywhere; or assess the diff in wi-fi attacks btwn being in the city and in the country). I come up with higher Pr(t) for the latter and the former in my two examples. (It may also be useful to factor in attacker’s costs in the first example).

• Pr(v): This is difficult to characterize, but I think of it more as “the probability that a system of interest will be attacked, and that the attack will succeed [within some time period].” While I agree that any non-trivial system is vulnerable in a theoretical sense, it does not appear that every system is compromised (and I think that “two kinds of orgs – those that are compromised and those that don’t know it yet” *is* closer to nonsense than r=t*v*i). Whether there is an over-abundance of targets, the attacker costs are too high, the control environment is sufficiently strong, or some other reason, not all systems are in a compromised state and so it is worthwhile to measure. It is especially important since the bulk of our defensive efforts revolve around reducing this probability.

Again, estimating Pr(v) can be done in similar ways as Pr(t). In my comparative analysis – I look at things like number of users (as vulns), size of code base, number of open ports, RASQ, etc…

• It is worth discussing why breaking down Pr(event) into Pr(t)*Pr(v) is beneficial. For the most part, I would actually prefer to simply use Pr(event) if we have enough information (historical data). For example, I think we have pretty good data on email-borne attacks and so I wouldn’t be working too hard on assessing ‘t’ and ‘v’ there, though the McColo takedown can show how much of an impact a change in ‘t’ can have.

Maybe the biggest reason is that the respective populations are different and can change drastically. Here are some use cases:

a) One of the better uses is to compare two scenarios/architectures. Banking from smartphone vs. laptop; moving to cloud from internal; determining risk btwn WEP vuln and remote Windows vuln; etc…

b) Acknowledge that if ‘t’ or ‘v’ is 0, then Pr(event) is 0. Though it is hard to conceive of a case where ‘v’ is 0, we can see ‘t’ approaching it in lots of PoCs.

c) Showing the significance of ‘t’ or ‘v’ as its partner approaches 1. I agree that ‘v’ is essentially 1.0 so why do we spend all our time on it? Maybe we should be doing other things… this is also why I think the move towards threat intel is so important.

d) To help folks see how changes in populations of either ‘t’ or ‘v’ might affect each other, and ultimately risk. Like the McColo takedown, bounties (on malware writers and bugs), etc. My favorite use may be pointing out that vuln disclosure does nothing to ‘v’ since it was already there; the impact is on ‘t.’

To round things out, all this is “good enough” at the level of precision we are working at, and “better than” existing practices, IMO.

For our latest debate – Android vs. iOS – there are three sets of numbers that have recently come into play for evaluation:

1. Number of vulnerabilities: A recent blog post on TheVerge.com highlights that iOS and its 238 vulns from 2007-2013 has 8.8x more vulnerabilities than Android’s 27 from 2009-2013.
2. Number of malware samples: In April, a Symantec report [PDF] pointed out that Apple’s 387 vulns in 2012 dwarfs Android’s 13 and yet Android had 103 “mobile threats” (malware) compared with Apple’s 1. Importantly, they also point out that “most mobile threats have not used software vulnerabilities.”
3. Percent of traffic: A paper presented at NDSS ’13 [PDF] monitored actual smartphone traffic and found that a) “The mobile malware found by the research community thus far appears in a minuscule number of devices in the network: 3,492 out of over 380 million (less than 0.0009%)” and b) “users of iOS devices are virtually identically as likely to communicate with known low reputation domains as the owners of other mobile platforms, calling into question the conventional wisdom of one platform demonstrably providing greater security than another“

Now, since we all know that security is the number one priority for IT decisions (heh), the CIO is waiting to hear from us on which platform is more secure. How do you answer?

Here’s my analysis, just using the numbers provided*

First, number of vulnerabilities as a measure is often thought of as a leading indicator of risk even though we all recognize that more vulns found equals fewer vulnerabilities remaining. The perception, however, is that there are actually even more vulns left. Absent of any other information, however, it is worth considering the notion that a higher number here is a measure of stronger security going forward (that is, #vulns is a lagging indicator). It doesn’t help matters that at least one of the sets of numbers inexplicably uses different time periods in its analysis. This measure would be much more useful if we had a way to normalize the numbers across platforms – the two most obvious ways would be with 1) a measure of complexity or size of the code base or 2) a measure of the personhours expended in looking for vulns. While I favor this latter option, it is not very practical.

The second measure, number of malware samples, is interesting because it is closer to the actual compromise. In addition, as Symantec points out many of them don’t exploit software vulnerabilities (this is another knock against using vuln counts). The challenge here is that there is essentially unlimited ability to create more malware samples. Moreover, the notion of a “mobile threat” is fairly broad and not always threatening to the extent that legitimate apps have some similar characteristics. Given the (somewhat) restricted methods for distribution and installation of apps on smartphones, a better measure would be to identify the distribution and accessibility to the population of these malware apps. In this case, getting an understanding of the number of downloads would get significantly closer to understanding the relative risk.

The final measure, compromised smartphones, provides a historical measure of actual infected phones. Aside from the really, really low number, we must decide whether these values are a good reflection of (future) risk or not. Since this number identifies compromised systems, it gets us closest to that which we are trying to prevent, which is useful. Ultimately, I believe this measure is the best of the three in helping us understand “risk” in the mobile world. And right now, it’s a tossup.

A better measure for determining which platform is more secure, in my opinion, would involve a measure of attack surface combined with one of devices sold (as a placeholder for activity volume and popularity).

We have, of course, been around the mountain several times on how to value information. There are at least these:

1. acquisition cost (worth what you paid for it)
2. replacement cost (worth what you would pay for it)
3. opportunity cost (downside when, say, your IP is lost)

There is Pete Lindstrom’s (as I recall) effective minimum:

4. current dollar value of IT budget

I’ll suggest another:

5. paper at (a) says that the optimal amount to invest to protect an information asset is 1/e of its info value at risk, so the value of the information asset, assuming optimality is _not_ being achieved, is greater than or equal to the product [ e*investment ]

Not particularly helpful, but upper/lower bounds are often useful to think about. I know a CISO who justified a rather substantial identity management system by arguing that it would protect reputation of the firm and was a net positive return if the reputation of the firm was worth at least one basis point of the market capitalization. Needless to say, no member of the management committee would say that the reputation of the firm was smaller than one basis point so the investment went through.

There are two aspects of information (and technology valuation) that create the biggest problem for Technology Risk Professionals:

First, the perception of value is not absolute – it can be affected by timing, substitute/alternative options, opportunity cost, etc. Consider the price for Diet Coke is different at grocery store, fast food outlet, convenience store, baseball game, etc. So we negotiate “willingness-to-pay (WTP)” and “willingness-to-accept (WTA)” throughout the course of our lives. Valuation is even more difficult for goods without a large market (e.g. high-end artists’ paintings) and especially difficult for intangible assets like “information.”

Second, the value being driven by technology to an organization is not the same as the possible losses. For example, Coca-Cola does not “lose” the ability to manufacture and sell Diet Coke if somebody steals its proverbial formula. It MAY lose some % of revenue due to the sale of black market Diet Coke, but even that is questionable IMO (much easier to copy the can and approximate the taste, I think). Similarly, Amazon.com is unlikely to lose 1/365th of revenue due to being offline for a day. OTOH, an unrecovered transfer of $10k from one account to another at another entity IS lost. And sometimes a breach can result in greater losses ((at least arguably) than the currently realized value – consider intellectual property associated with undeveloped products, for example.

As echoed in a couple of the workgroups at Metricon 8 this year, organizations are most comfortable reporting losses reflected by direct costs – immediate response, forensic analysis, notification, etc. The enlightened company may include economic costs – e.g. loss of productivity in other areas. It is the truly rare company that can get to the point of quantifying losses in “brand, reputation, etc.” even though losses can only be reflected in its (current and/or future) financials – higher costs, lower revenue, increased liabilities, decreased assets. After all, we are talking about an inanimate entity.

With all of the ambiguity, it could be that we’ll only ever be able to get consensus on value and losses using breakeven approaches to define thresholds and make decisions. On the value side, my assertion holds that the amount spent on IT reflects a minimum valuation but it is only part of the story given the missing relationship between value and loss, which is much more important to techrisk professionals. So we need to modify our breakeven approach accordingly and create a “control horizon”. Things get a bit trickier here.

While a million dollar purchase of IT assets reflects at least a million dollars in value, a hundred thousand dollar purchase of a security solution does not reflect its corresponding loss. We can say that $100k spent on security reflects at least $100k of risk, that is not the same as loss because it has been discounted by its probability of happening. What’s more, this probability also has a lot of associated ambiguity (for a number of reasons).

What we can do, however, is draw a line on a graph using the value pairs of probability and loss (10% of $1m; 1% of $10m; etc). Lo and behold, this creates a “control horizon” on a risk matrix – in essence, a breakeven line. If the initial risk was above the line (or should we say “up and to the right”) and it is completely addressed, then the purchase at least breaks even. Below the line means a bad decision was made somewhere along the line.

The control horizon provides a basic way to determine whether security spending makes sense.

This is an important announcement because it highlights the very real problem of “in-the-wild-exploits of undercover vulnerabilities.” This strain of “0day” is the most significant given that active exploits are already happening when they are discovered. In these scenarios, the threats (malicious actors) and vulnerabilities have already collided in the real world and losses are being actively incurred. Thus, this type of situation is the most important type that technology risk (techrisk) managers must deal with in their environments.

The announcement itself highlights some important, underappreciated aspects of the techrisk profession:

- That exploits/breaches/incidents are the fundamental “unwanted outcome” that we are trying to prevent. It is not uncommon for techrisk pros to focus efforts on software quality, control weaknesses, or compliance violations – all useful intentions to the extent that they address the aforementioned incidents.

- That techrisk professionals can identify attacks even when the vulnerability is unknown. Much of our profession’s focus revolves around the notion that we must find vulnerabilities in order to protect ourselves, yet time and again we succeed in identifying these types of attacks using behavioral analysis and other techniques. With the growth in popularity of forensic archiving, we can now also determine to what extent we have been victims in the past to assist with understanding the risks of the future.

• That much of the profession’s effort associated with vulnerability management is ineffective. Our efforts to identify each vulnerability prior to exploit are simply overwhelmed by scale and can simply be shown through a thought exercise – consider how many vulnerabilities are created every day (in the aggregate) as compared with how many are found. Perhaps more importantly, it is worth noting that the vast majority of vulnerabilities that are found are never known to be actively exploited [pdf].
• That there is a variance in how different types of attacks – namely, targeted vs. opportunistic – manifest themselves online. Google’s primary cited reason for its new policy involves political activists as victims of targeted attacks that may lead to physical harm. The history of infosec and techrisk highlight other scenarios – the NIMDA worm, WMF exploit, WebDAV, etc – that involve opportunistic exploits across a multitude of targets.
• That the most significant way to “move the marker” in security is through the identification of exploits and not vulnerabilities. As with Code Red and Nimda in the Fall of 2001 leading to Bill Gates’ well-known “Trustworthy Computing Memo,” active exploits are the best drivers of change in the techrisk profession.

 While Google’s new policy offers and opportunity to assess the state of security on the Internet overall, it also demonstrates significant deficiencies in its approach:

• The 7-day deadline has no risk basis. With the significant variance in number of affected parties and speed of compromise associated with opportunistic attacks versus targeted ones, the number is an arbitrary one. In the primary example cited (activists at risk of physical harm), speed is highly unlikely to have a significant impact on risk reduction.
• The capabilities of enterprises and/or users to protect themselves can vary significantly. There are many reasons why some parties choose to remain vulnerable to certain types of attacks – system complexities, legacy support needs, lack of technical skill, competitive priorities, etc. Through the years some security researchers (including some employees of Google) have expressed disdain for those that cannot protect themselves. A company the size of Google should be held to a higher standard in its willingness to protect those online that can’t always protect themselves.
•  No consideration of economics. The policy completely ignores tradeoffs like the risk of breaking systems when taking precautionary measures (e.g. patch failures), the well-known increase in exploits that occur after the disclosure of many new vulnerabilities [Arbaugh, McHugh, 2000 pdf; Bilge, Dumitras 2013 pdf], and the opportunity costs associated with new requirements. When Google says, for example, “each day an actively exploited vulnerability remains undisclosed to the public and unpatched, more computers will be compromised” they neglect the significant likelihood that computers will be compromised regardless of the state of disclosure to the public and fall back on the age-old myth that only patches can protect systems.
•  It can lead to even more exploitations and incidents. Anyone paying close attention to the vulnerability research community knows that there is wide variance in how researchers disclose their information and some decisions are made based on annoyance, frustration, spite and sometimes even malice. If a vulnerability will get “noticed” more quickly, researchers may be tempted to “test” it in the wild in order to increase its priority level.

A company with the talent and resources at Google can do better. Here are some opportunities for improving the state of security on the Internet and addressing the real, significant risk associated with actively exploited 0days:

• Encourage and train political activists in obfuscation and evasion techniques. It is challenging to discuss a blanket policy across all scenarios simply by highlighting arguably the most important one – that involving physical harm. It seems highly unlikely that this case is a common one and the best way to discuss the overall implications of the policy itself is to remove this scenario from the discussion as it tends to cause an emotional reaction. As many of us know, there are many ways political activists can protect themselves online that would be much more effective than a 7-day disclosure policy which comes after they have been compromised.
•  Increase focus on actively exploited 0days. Since these are the most important scenarios the techrisk profession has to deal with, Google should be making every effort to identify these exploits and employ or invent new ways to protect against them. Google researchers still participate in random, ineffective vulnerability research that simply distracts from this very real problem.
•  Provide more insight into the “dozens” of 0days identified “through the years” that was mentioned in the blog announcement. If there is one thing Google has, it is great data. As evidenced by past reports [Provos, 2008 pdf], Google could very easily provide more specific evidence on the number of 0days they have identified, the volume of exploits, and their disposition by vendors. The fact that they haven’t yet, especially in the face of this policy announcement, is disappointing and makes it difficult to evaluate the measure.
•  Take a risk-based approach to disclosure. Fast-moving worms do most of their damage in hours and days – in those cases, seven days is too long. Targeted attacks are unlikely to get repeated in a way that demands immediate attention for most environments – in those cases, seven days is too short. A risk-based approach would take into account the frequency of exploit, probability of future exploit within a target population, and impact of the exploit while evaluating the changes to these variables over time – in particular before and after disclosure.
•  Monitor the situation closely. Google’s unique ability to gather data in this regard is worth mentioning again as a function of its ability to assess its own policy. Collecting and publishing data on actual 0days throughout their exploit lifecycle would be a boon to the entire profession.
•  Initiate or participate in discussions to create new ways to address this very real problem. Commercial, community, and government mechanisms already exist for sharing data publicly and privately that could be used as models for minimizing the risks associated with these types of attacks. For example, a (private) process similar to federal wiretap capabilities in secrecy and opportunity may be more effective in addressing targeted attacks. There are countless other approaches that could be leveraged to address this problem.

Make no mistake, the Google 7-day policy announcement sheds light on a real and significant issue in technology-related risk. While it highlights some of the challenges techrisk professionals face on a daily basis, it also demonstrates significant deficiencies in its approach to address the problem. This is a great opportunity to evaluate the existing state of the Internet from a risk and security perspective to determine where inconsistencies or weaknesses lay and map out a risk-based program that has the highest likelihood of success.