By Wade Baker
Today, we released a supplement to our 2008 Data Breach Investigations Report (DBIR) that focuses on four major industry groups. As many of you know, the original document compiled four years of data from over 500 cases worked by our Investigative Response team and was intended to be a kind of “state of the union” look at recent security breach and data compromise trends.
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 Russ Cooper
This month gives us numerous Microsoft Office patches (MS08-042, MS08-043, MS08-044 and MS08-051), including at least one (MS08-042) that addresses a vulnerability which has reportedly been used in another highly targeted attack.
We’ve also been given a patch (MS08-041) to address the Access Snapshot Viewer ActiveX control that is being actively targeted by criminals. Luckily, this control is rarely deployed so the actual number of victims is believed to be quite low.
Meanwhile, our concern is with the Cumulative Internet Explorer Update (MS08-045) and the IPsec Policy issue (MS08-047.) In the IE patch is a vulnerability involving memory allocation. This vulnerability cannot be mitigated by disabling Active Scripting, and also affects IE systems configured to run in the Enhanced Security mode. Details of how to exploit this vulnerability have not yet, however, been publicly disclosed so we can only hope that exploits do not arise before the patch can be installed.
As for the IPsec Policy issue, networks that use IPsec and believe they are encrypting their traffic may not in fact be encrypting. The problem is likely to be very rare at this point, given that a requirement is that the client system gets its IPsec policy information from a Windows Server 2008 system. Never-the-less, verifying that traffic you expect to be encrypted is actually encrypted is a good idea.
We have two patches (MS08-044 and MS08-046) pertaining to image format file parsing again. Even with numerous image vulnerabilities in the past we still do not see any exploits of this type, leading us to believe that the risk of attacks against these new ones is low.
Patches for Outlook Express and Windows Mail (MS08-048) normally don’t concern us very much because they’re rarely used in a corporate environment, but this one does cause some concern due to the fact that it involves MIME HTML (MHTML), which can be invoked via IE.
A vulnerability in COM+ Event System (MS08-049) and a Windows Messenger ActiveX control (MS08-050) round out the month’s offerings. Neither is terribly worrisome.
All in all, a busy month, but not really that much to worry about.
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 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.
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…)
