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.

When estimating losses, it isn’t entirely unreasonable to do the high-level straight-line math like IT World did here:

“Amazon.com’s latest earnings report showed that the company makes about $10.8 billion per quarter, or about $118 million per day and $4.9 million per hour.”

It’s really quick and dirty – and in a general sense legitimate – but can we do better? There are other ways to look at this that might shed some light on impact assessment. First, the assessment above makes no mention of costs. That might be the biggest weakness since costs are more under the control of Amazon and (probably) don’t fluctuate as much as revenue.

Luckily for us, Amazon just released its quarterly earnings report and this report asserts that its operating margin is about 3%. So right off the bat, we could suggest that Amazon lost 97% of $5 million or $4.85 million in costs. A more conservative estimate might try to determine whether the costs were unrecoverable or not, etc. Hopefully, you get the idea. A cost-oriented approach also works well as an example in infosec since that is often a big piece of the losses we face.

It is important to note here that these costs are additive to the lost revenue estimate – not only did we lose the $4.85 million in operating costs, but also (presumably) we lost that initial $4.9 million in revenue, for a total of (let’s say) $10 million.

Now, let’s look again at that lost revenue estimate. As mentioned earlier, coarse numbers like those used in the calculation above are certainly justifiable but we can probably do better. A quick thought exercise can help here – by creating the experience of an “average customer” of Amazon’s we can better assess the impact of the outage. This is harder than it sounds because we’ll have to second guess our own biases, but let’s try anyway. Let’s call him Joe.

Given that the outage was simply a “denial-of-service” of sorts, the big variable we must evaluate is time. More specifically for our scenario, we need to answer the question “How timely does Joe’s interaction with Amazon need to be, or, how likely is Joe to wait an hour to complete his purchase?” At the very least, we know Joe is willing to wait two days (maybe more – not sure what the average delivery time is for Amazon) to receive whatever goods he purchases. Throw in what we might assume (my bias) about Amazon’s low prices and the corresponding brand loyalty that comes with it and it seems reasonable to conclude that Joe will wait an hour to make the purchase, and therefore the lost revenue is actually only deferred revenue to be recognized in the future.

But not everyone is average (usually nobody is), and so once we cover a generic case, it is useful to consider the impact of the outliers. Now, we can imagine scenarios where even though a customer can wait for delivery, she can’t wait to place the order – too many other things going on in life. Or even a case where the customer would actually lose a full day due to delivery cutoff times. These are the types of cases that warrant more attention. Certainly it is reasonable to factor these cases into a loss scenario. Let’s say this is true 10% of the time.

The goal here is to be conservative in our estimates (even though it is sometimes beneficial for companies to be liberal after the fact – can hide other problems) so we should remember that these scenarios are typically useful in identifying some sort of discount factor to apply to the initial $5 million estimate. Though it is possible to come up with scenarios where there is a multiplier – maybe holiday seasons – it is less common.

Our lost revenue evaluation has led us to conclude that 90% of purchases will still be made in the future, so the remaining 10% of cases will discount our $5 million loss down to $500,000. Add that to our lost costs and we are back to the initial $5 million estimate, though from a different perspective. While it might be attractive to decide all was for nought, it is worth considering the situations where the costs are much lower, or the revenue is more likely to be lost to see the value in the exercise.

Now, some might suggest (essentially) that the above analysis is really not worth it because a loss is a loss. Not only that, but Amazon’sown numbers have shown (?) that there is no discernible uptick in sales in the period following the outage. As mentioned earlier, it is easier to see how costs are fairly static and therefore turn into losses. On the revenue side, however, it is not clear at all.

In assessing lost revenue in this case, one must do two things: first distinguish between necessity and convenience and second evaluate the impact of buyer’s capacity. The purported lack of a noticeable uptick in sales in the short term could easily be explained if purchases are more oriented around convenience than necessity. Measures associated with shopping carts might be of assistance here (I sometimes leave items in my shopping cart for days if not weeks). Again, this information can be factored into the estimates if need be.

It is uncommon to consider a “buyer’s capacity” but especially with convenience purchases, one might decide that the rate of purchase is a determining factor and even though the shopper returns, she will be buying other items, etc. This justification is easier to believe in cases where capacity is high – that is, the shopper is buying at a rate where fitting in the “lost” purchases is unlikely (and when it happens is noticeable in the numbers). My assessment is that this scenario is unlikely; people are more casual in their shopping experience and will therefore wait to make their purchases. (A similar capacity limit could have an effect on the Amazon side, but that is even more farfetched).

My conclusion is that $5 million is a reasonable loss estimate for Amazon’s outage, but not for the reasons initially believed.

Of course, the attackers didn’t use spear-phishing then, but the idea of the “APT”  as an adversary was alive and well (and I am sure there are others that could reasonably trace the adversarial aspect back before computers). Through the years, we’ve heard about (and seen evidence of) things like “blended threats” and the “low and slow attacks” that occur over time. TJ Maxx, Heartland, and many of the other most public attacks can be considered APT in a general sense (though presumably the threat actor doesn’t quite match up). And certainly Google/Aurora was the most prominently identified APT incident that matches up pretty consistently with the RSA attack.

Even the advocates of the APT idea agree that the individual elements of the APT are not particularly new. That begs the question of why do we need a new label to discuss things that are not so new? And the answer is obvious – because those folks that are advocating APT do not believe enough is being done to prevent these types attacks. That is, they think the risk is greater than the effort to mitigate them.

It is not uncommon in the security space for people to latch onto a term and make it mean everything, and therefore nothing. It isn’t necessarily malicious; sometimes it is a result of a weakly defined term or poor choice of words. Sometimes it is a way to shake out some economic doldrums in a time of flat spending even while the market remains competitive.

But the question remains: are we spending less than we should? There is ample evidence in the broader risk management community for two pieces of this puzzle that go hand-in-hand. First, humans are likely to pay less attention to the low frequency, high consequences events. And second, that fear of the unwanted outcome causes people to overestimate the likelihood of an event. So when people use the term “APT” in a manner that some would call FUD, it may actually offset the lower attention and work out in the end.

Ultimately, I think advocates of APT are going to have a hard time convincing others that the risk is higher than we think. Truthfully, it is not clear to me that they are even performing some sort of risk analysis because they themselves are caught up in the “dread” cycle that causes them to overestimate the risk. It would be great for proponents to put together some numbers that assist in measuring frequency and consequences for all those involved so we can better determine our infosec strategy.

Two other observations from the RSA hack that I thought were noteworthy: 1) RSA highlighted that their recommendations were “Security 101″ which I agree with, but that doesn’t fare well when also trying to promote the notion of the APT. We should at least be in Security 102 (second semester ) for APTs, right? Also, 2) I am concerned that we are going to lose sight of what it means to stop an attack “in progress.” AFAIK, RSA has not publicly stated what the duration of the attack was, from the time of initial attack (the spear-phish) to the time of identification and response. The whole notion of catching something “in progress” AFTER data is lost seems somewhat specious to me without a better explanation.

“Recently, our security systems identified an extremely sophisticated cyber attack in progress being mounted against RSA. We took a variety of aggressive measures against the threat to protect our business and our customers, including further hardening of our IT infrastructure”

and

“Our investigation has led us to believe that the attack is in the category of an Advanced Persistent Threat (APT).”

So, surprise, surprise we are getting folks discussing whether this actually fits in the most ambiguous category in the history of infosec – APT, and heck I am going to throw in my literal interpretation for the single word that actually has some specificity associated with it: Persistent. I suppose you could look at it two different ways – persistent in the manner of identifying recurring attacks from the same source, or persistent in its ability to compromise resources and stick around for a while. Neither seem to be the case here.

I feel RSA’s pain, because there is no honor in being hit with your general garden-variety plain old “T” especially if you are a security company. But they should also feel better because as we know both “Ts” and “APTs” use the same techniques… which of course also means that you can’t tell if it was an APT or not unless you have recurring information of correlated attacks or actually find out their motives later.

Seriously, are we really going to be stuck for the rest of our careers deciding what is or isn’t an APT? Let’s hope the term flames out quickly.

I am not clear whether this list of disclosed vulnerabilities is intended to represent vulnerabilities created or fixed (it is neither), but it certainly does its job in highlighting the problem. It is worth first understanding that vulnerabilities can exist in various states after creation – undiscovered/discovered; undisclosed/disclosed (publicly); and unfixed/fixed, giving us 8 different possible state combinations (though 2 are impossible) for vulnerabilities:

undiscovered, undisclosed, unfixed (latent)

undiscovered, undisclosed, fixed (due to code upgrade, for example)

undiscovered, disclosed, unfixed (impossible)

undiscovered, disclosed, fixed (impossible)

discovered, undisclosed, unfixed (true zero day; undercover vulnerability)

Even more interesting in this case is the conflicting interest of World of Warcraft players who can use the stealth capability of Sony’s DRM to hide from WoW’s "DRM" function. So competing priorities will either drive up or down Van Zant’s record sales.

It would be really interesting to know how many albums were bought on either side of the equation – if more albums are bought for the purposes of breaking WoW DRM, then I think that is an indicator that DRM should be used because there are more pirates than benign anti-DRMers. If less are sold, then there are more benign anti-DRMers.

It is alarming how little outrage there is from ordinary PC users. While Register readers are well versed in the restrictions of DRM and the dangers of malware, there’s little sign the public shares this knowledge.

Note to all security professionals: if this is alarming to you, you need to spend a lot more time in the real world. This is very much the rule, not the exception.

The employee went on to say she erased five years of zoning files because Leitch "has never taken care of her computer system. She has had numerous virus(es). No matter what, apparently, she doesn’t feel the need to update and back up her system."

I wonder if she thinks she was doing "the community a service"….

Now, you don’t even need anyone’s permission to become a "contact" – just write a little javascript worm. "samy" did just that on myspace.com and apparently had over a million best friends within a day or so. Read his whole story – on the surface, it is pretty funny.

Of course, my security professional hat knows how painful it must have been for the security folks at myspace.com to recover. I can only imagine the costs involved. Actually, I can estimate them – since Intermix Media did $79 million in its most recent fiscal year (year ended March, 2005), that translates out to about $65k an hour of revenue (assuming all revenue is generated online). Samy says the servers were down for about 2.5 hours for about $160k in lost revenue. I don’t know what their burn rate is, but it is not uncommon for it to be higher than revenue, so I will take the $160k and reduce it by half to account for unrelated costs (I would include IT salaries and IT cost of capital, so I think for an ebusiness, 50% of expenses is reasonable). For a grand "back of the napkin" total of $240k.

The impact on global networks is even more interesting: the more reputation economics, or Whuffies if you like Cory Doctorow, are leveraged for some sort of status, the more important they become to everyone and the more significant the damage.

The technique used is interesting as well. It looks like samy used a lot of obfuscation techniques just to get his script to run. In addition, he leveraged XML-RPC. It isn’t too hard to begin to imagine what could possibly happen in an online marketplace like eBay, for example, if some of these techniques were used. Or B2B marketplaces where thousands or millions of dollars are changing hands. The heck with reputation, now its a money thing…

I am a bit torn in this case. On the one hand, I don’t want security vigilantes running around looking for vulnerabilities, but on the other hand, it doesn’t seem like he had malicious intent. This is what is annoying about our profession – we feed our young to the authorities when they act on the bluster that’s out there about doing good by doing bad. (I really don’t get the whole "police are gonna pay for this" baloney. Sure, the vigilante "security consultants" out there will stay away, but those BT security professionals probably don’t mind at all.)

For discussion:

• What if the defendant (Daniel Cuthbert) were to claim that he actually was phished? Would he have ended up like this lucky guy?
• What good could come from running scripts against a web server involved in a phishing attack? (caveat: it is not completely clear what the technical details are to this story). Either it is run by bad guys in which case it probably would have been gone by the time Cuthbert went back, or it was a compromised legitimate server…but why wouldn’t he have simply looked at his URL history and parsed it out? (I am guessing a cross-site scripting test here) or gone back to the banner ad he clicked on?