Archive for the ‘Analysis’ Category

“Never attribute to malice that which can adequately be explained by Stupidity.”

Wednesday, October 15th, 2008

by Dave Kennedy

We humans introduce risk regardless of our good intentions.  We security types tend to be a paranoid lot, thinking every unfortunate event is evidence someone is out to get us.  Yet we are regularly reminded of Hanlon’s Razor, quoted above.  Recently, we have two high-profile “oopsies” which demonstrate the premise of Hanlon’s Razor, namely that not all bad outcomes have an evil-doer involved.

Last week, a colleague at Verizon Business wanted to inform his customers and colleagues that we had published a supplement to our Data Breach Investigations Report. He crafted an e-mail message and used a list of addresses from a public (non-Verizon) website for the “To:” line in Outlook.  Oops.  He had intended to use the blind carbon copy (BCC) address line to ensure privacy of the recipients, but this did not happen. Certainly, in this case, his actions counted more than intentions.  Of course, he knows this is an easy-to-make error and thus one to guard against.  The earliest instance I’ve found of this bcc mishap dates back to 2001, but we can be pretty sure this mistake is older than that.

(more…)

Security ROI - Time to Think Differently

Friday, September 26th, 2008

How many times have you been asked about the Return On Investment (ROI) for some security product you were thinking of purchasing? For most of you, it’s probably a great deal. And determining ROI has likely not been easy either. How much productivity might be lost due to a breach? How do I count the time? Do I base it on wages, lost sales, reputation, or damage?

(more…)

Do the Findings of the 2008 Data Breach Investigations Report Differ Among Industries?

Wednesday, August 20th, 2008

By Wade Baker

Since releasing the 2008 Data Breach Investigations Report (DBIR) in June, we’ve frequently been asked some form of the following question: “Do the findings presented in the report differ among industries?” It’s a good question, and one we’re working on answering at length in a supplemental report contrasting the four most frequently breached industries (Financial Services, Tech Services, Retail, and Food & Beverage) using the original dataset. We plan to release the report sometime next month, but would like to give you a sneak peak in this post.

You may remember that the 2008 DBIR considered three main sources, or origins, of data breaches: external, internal and partner. The upcoming supplemental report naturally adopts this same trio of sources. Based on Verizon Business caseload from 2004 through 2007, the figure below depicts the percentage of breaches attributed to internal, external and partner sources for each industry group.

(more…)

Risk Management Skills

Friday, August 8th, 2008

By Mark Zimmerman

We all cringe when we see a member of the executive management heading in our direction clutching a trade magazine with the latest WIBHI (Wouldn’t it be Horrible If) article highlighted. In order to help address this situation, we’ll discuss a topic that is, unfortunately, still only largely written about or discussed more than actually understood and/or implemented within the Information Technology department—Risk Analysis.

I’m talking about Risk Analysis skills at the day-to-day, rubber-meets-the-road implementation level, versus that once a year frantic exercise done a half hour before the auditor arrives. You know, the guy (or gal) who freaks everyone out by setting himself up in the conference room and calling people in to ask them to describe their job functions.

(more…)

DNS Facts and Scenarios

Friday, July 25th, 2008

By Peter Tippett and Russ Cooper

There is a huge amount of angst, discussion, testing and endless worry about the “new DNS vulnerability” whose existence was published a few weeks ago concurrent with a coordinated patch release. Its dastardly “vulnerability” or “threat scenario” will be disclosed in full in early August. The worry is that, once fully disclosed, the unprepared world will be at risk—or at least large portions will be—and whole new categories of exploit will suddenly be possible…or something like that.

Let’s get out a few facts, and then discuss some hypothetical attacks. We’ll assume the extremes and see just how a very old and well-understood vulnerability might behave differently if, for example, a simple cache poisoning attack tool or technique were released. [For a primer on DNS look here. For a primer on DNS Cache Poisoning look here.]

(more…)

DNS Vulnerability Is Important, but There’s No Reason to Panic

Tuesday, July 15th, 2008

by Dave Kennedy

Implementations of the Domain Name Servers (DNS) protocol may leave systems vulnerable to DNS cache poisoning attacks. Last week many incident response teams, along with software and hardware vendors, issued security bulletins and patches to reduce this risk. Cache poisoning attacks are almost as old as the DNS system itself. Enterprises already protect and monitor their DNS systems to prevent and detect cache-poisoning attacks. There has been no increase in reports of cache poisoning attacks and no reports of attacks on this specific vulnerability. DNS is infrastructure. Infrastructure must be trusted, and it must be perceived as trustworthy. (more…)

Patch Management - Speed Is of the Essence

Tuesday, July 1st, 2008

Symantec’s Hon Lau recently published a blog post titled “Patch Management – Speed is of the Essence.” You may know that we also recently published a blog post titled “Patching Conundrum”, in which we discussed how our studies had convinced us that patching too fast can be a “bad thing™.”

Hon Lau said, “It is this gap between the availability of patches and their application that is creating a window of opportunity for would-be attackers.”

Well, really, it isn’t. The “window of opportunity” begins when the vulnerable version of whatever is actually installed and/or implemented, and lasts until a non-vulnerable version is installed, or until the product stops being used. Nothing terribly significant occurs once a patch is released, unless you fear “Automatic Patch-Based Exploit Generation” (APEG). Hon Lau seems to.

(more…)

Dampened Countermeasure Effectiveness

Monday, June 23rd, 2008

By Peter Tippett and Wade Baker

Studies are useful to help us to learn what works and what does not. Studies of other’s experiences, such as The Verizon Business 2008 Data Breach Investigations Report, are especially instructive. But most of us crave to actually understand why events play out as they do, and to be able to accurately predict what the results of those studies will be. Risk models can be very useful in driving our understanding.

(more…)

On Cattle Guns and Business Partners

Thursday, June 19th, 2008

By Wade Baker

After a long working session on the “Data Breach Investigations Report”, my co-authors and I decided a lunch break was in order. Mealtime conversation meandered through a diverse range of topics and eventually settled on the recent movie “No Country for Old Men.” Dave, a bit more of film connoisseur than Andrew or I, gave it five stars. Although I appreciated the cinematography and acting, I didn’t think it lived up to all the hype it received. I believe Andrew’s sentiments were similar. We did, however, unanimously agree on one thing: if a stranger walks up to you with a tank of compressed air and tries to press a strange metal apparatus to your forehead, it’s best not to just stare blankly and let that happen.

Although they rarely look so freakishly suspicious, findings from the report remind us that a dose of healthy caution when dealing with business partners might not be a bad idea either. (more…)

What Do We Mean by “Reasonable Controls?”

Thursday, June 19th, 2008

One of the more commonly referenced findings from our “2008 Data Breach Investigations Report” is that 87% of breaches could have been avoided if “reasonable security controls” had been in place at the time of the incident. As this statistic filters through the press and blogs, some are suggesting our use of the term “reasonable” has legal implications, or refers to controls that are “extravagantly hard” to implement. Such interpretation is simply not justified, and we’d like to set the record straight.
(more…)