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?
For those of you just returning from vacation, you’ll be pleased to see that there are only four patches this month for your consideration. Verizon Business believes that patch application is something which is done better when you fully understand what the patch is for, what it does, and what risks exist while you’re unpatched. This knowledge and consideration lets you more appropriately schedule patches to avoid business disruption.
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.
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.
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.]
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…)
By Wade Baker
Our 2008 Data Breach Investigations Report presents statistics on the percentage of breaches involving outsiders, insiders and partners (73%, 18%, and 39% respectively). Public reaction to these statistics runs the gamut from revulsion to revelry. This is especially true with respect to the relatively low percentage of breaches tied to insiders. Some seem to think we’ve blasphemed the sacred doctrines of our trade handed down from on high long ago. Others are glad to see their oft-ridiculed beliefs finally vindicated by objective data. Many in the middle are cautious about drawing conclusions, and are unsure what to make of the statistics.
Which reaction is appropriate? We won’t weigh in on that question; we’ll stick to providing data rather than dictating the reactions of others. We would, however, like to address the underlying questions fueling such reactions - whether these statistics are bogus, biased or believable.
(more…)
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.
How much better is it to have a world-class patching process compared to an average one? Could it ever be detrimental to patch too fast? And what does patching have to do with cholera? Two earlier Verizon Business Risk Team Studies shed more light on this subject.
The recently published “Verizon Business 2008 Data Breach Investigations Report” describes characteristics of more than 500 computer crime investigations performed over the past four years. Our data shows that in only 18% of cases in the hacking category (see Figure 11) did the attack have anything to do with a “patchable” vulnerability. Further analysis in the study (Figure 12) showed that 90% of those attacks would have been prevented had patches been applied that were six months in age or older! Significantly, patching more frequently than monthly would have mitigated no additional cases.
At considerable investment in time and resources, Verizon Business began an initiative in 2007 to identify a comprehensive set of metrics to record during each data compromise investigation. As a result of this effort, we pursued a post-mortem examination of over 500 security breach and data compromise engagements between 2004 and 2007 which provided us with the vast amount of factual evidence used to compile this study. This data covers 230 million compromised records. Amongst these are roughly one-quarter of all publicly disclosed data breaches in both 2006 and 2007, including three of the five largest data breaches ever reported.
